From owen at delong.com Tue Feb 1 00:03:49 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 31 Jan 2011 22:03:49 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> Message-ID: <5D2659F3-5853-4C1C-A26D-D6EB5AA75195@delong.com> On Jan 31, 2011, at 9:35 PM, eric clark wrote: > Figure I'll throw my 2 cents into this. > > The way I read the RFCs, IPv6 is not IP space. Its network space. Unless I > missed it last time I read through them, the RFCs do not REQUIRE > hardware/software manufacturers to support VLSM beyond /64. Autoconfigure > the is the name of the game for the IPv6 guys. > You misread them. SLAAC is not supported beyond /64. VLSM support for static configuration is required. > Subsequently, while using longer prefixes is possible currently, I'd never > deploy it because it could be removed from code without mention. > Correct... Just because you can does not mean it is a good idea. > Because of the AutoConfigure piece, I consider IPv6 to be NETWORK Space, > rather than IP Space like IPv4. I'm issued a /48 which can be comprised of > 65536 /64 networks, not some silly number of hosts, which can't exist > because they are all duplicates of each other (MAC address = host > identifier) > There is a valid point in that you should not be using autoconfigure or ND on point-to-point links. > Anyway, that's how I see the question that started this whole thing, I'd > suggest using link local and RFC 4193 for internal routing and your public > space for things that need public access or need to be accessed publicly. > Link Local is not routable, even internally. It's LINK local. In my opinion, RFC 4193 is just a bad idea and there's no benefit to it vs. GUA. Just put a good stateful firewall in front of your GUA. I mean, really, how many things do you have that don't need access to/from the internet. Maybe your printers and a couple of appliances. The rest... All those TiVOs, Laptops, Desktops, iPads, etc. all need public addresses anyway, so, why bother with the ULA? > Just because they SAY there's infinite space (like they said about IPv4) > doesn't mean we have to be stupid and wasteful with our space. > Supplying every end site with a /48 of global address space is neither stupid or wasteful. It's a good design with some nice future-proofing and some very nice features available if people take better advantage of the capabilities offered as we move forward. Just because it's more than you can imagine using today does not mean that it is more than you will ever imagine using. I'm very happy that I have a /48 at home and I look forward to making better use of it as the Consumer Electronics vendors start to catch on that the internet is being restored to full functionality for end users. Owen From bensons at queuefull.net Tue Feb 1 00:10:03 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Tue, 1 Feb 2011 00:10:03 -0600 Subject: Verizon acquiring Terremark In-Reply-To: References: <6EFFEFBAC68377459A2E972105C759EC03539A93@EXVBE005-2.exch005intermedia.net> Message-ID: <4C6F4853-0997-4691-AB73-31B4E655301D@queuefull.net> On Jan 31, 2011, at 10:25 PM, Jimmy Hess wrote: > >> What does neutral really mean anyways? Terremark has sold, is selling and > > It is the same concept as network neutrality. > An example of a non-neutral IP network is one where a competitor's website or > service is blocked by the network operator. > > A facility is carrier neutral if it is operated by an independent organization. > An example of a non-neutral exchange is one that only allows specific > tenants to connect to other tenants; other tenants besides the chosen ones > are forbidden from connecting to anyone besides a preferred tenant, > or have to pay higher rates for each connection to another provider who > is not a 'preferred' tenant. I don't know - it's an oversimplification. Even the "independent organization" is still trying to pull in revenue. Given the opportunity to make money on interconnections, they do so. And the idea of "neutral" is pretty hard to define, when you mix together all of the participants' different business relationships and incentives, operating margins and price variations, etc. They'll say: "Sure you can connect to anybody you want. As long as you pay a monthly cross-connect fee. And as long as the other party is paying for a presence in my facility, too." But do you know who pays how much? In the end, are you sure that a carrier "neutral" facility offers a better price than a non-neutral facility, for any given connectivity? I'd suggest that "carrier neutrality" is subjective and isn't really the metric you need in a colo / datacenter facility. Cheers, -Benson From wavetossed at googlemail.com Tue Feb 1 00:26:21 2011 From: wavetossed at googlemail.com (Michael Dillon) Date: Mon, 31 Jan 2011 22:26:21 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <5D2659F3-5853-4C1C-A26D-D6EB5AA75195@delong.com> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <5D2659F3-5853-4C1C-A26D-D6EB5AA75195@delong.com> Message-ID: > In my opinion, RFC 4193 is just a bad idea and there's no benefit to it vs. > GUA. Just put a good stateful firewall in front of your GUA. > > I mean, really, how many things do you have that don't need access > to/from the internet. Maybe your printers and a couple of appliances. > > The rest... All those TiVOs, Laptops, Desktops, iPads, etc. all need > public addresses anyway, so, why bother with the ULA? Because the ULA addressing is free, not that hard, and provides an extra layer of protection to prevent vandals from using up your printer ink or turning your fridge on defrost during the night. And some networks will have a lot more stuff that could use an extra layer of protection like that, for instance SCADA networks. > Supplying every end site with a /48 of global address space is neither > stupid or wasteful. It's a good design with some nice future-proofing and > some very nice features available if people take better advantage of the > capabilities offered as we move forward. > > Just because it's more than you can imagine using today does not mean > that it is more than you will ever imagine using. I'm very happy that I have > a /48 at home and I look forward to making better use of it as the > Consumer Electronics vendors start to catch on that the internet is > being restored to full functionality for end users. Agreed. /48 is good for even the smallest home user living in a one bedroom apartment. They may not fully exploit it, but at the same time, they should not be treated as second class citizens when there is enough IPv6 address wealth to share around. --Michael Dillon From gbonser at seven.com Tue Feb 1 00:27:44 2011 From: gbonser at seven.com (George Bonser) Date: Mon, 31 Jan 2011 22:27:44 -0800 Subject: quietly.... In-Reply-To: References: Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13774@RWC-EX1.corp.seven.com> > Not to mention the software updates required to make it functional > would exceed the > software updates necessary for IPv6 _AND_ it has no lasting future. Part one of that statement goes for v6 in a lot of places. The whole NAT444 allocation argument would go away with this. Maybe we need both. It might be easier to teach a v4-only device to use that space than to teach it to use v6. Part 2 is dead on in that it has no "lasting future" ... but what if it does? What if "Outer Slobovia" decides to simply number their nation using the entire v4 /0. Everyone can talk with each other inside the country just fine. $PROVIDER wants to provide services there? Well, they will just need to get an allocation out of Outer Slobovia's address space and NAT that to their services using either NAT44 or a stateless NAT64/DNS64 (Tayga or something). Outer Slobovia gets mad at the world? They just black hole the block set aside for foreign assignments and connectivity is instantly cut off. No v6 and no v4 leaks outside the country. I suspect we will see countries do just that. From gbonser at seven.com Tue Feb 1 00:43:52 2011 From: gbonser at seven.com (George Bonser) Date: Mon, 31 Jan 2011 22:43:52 -0800 Subject: quietly.... In-Reply-To: References: Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13776@RWC-EX1.corp.seven.com> > > 3. Busting out 16 more /8s only delays the IPv4 endgame by about a > year. > > jms If used for general assignment, sure. But if used for what people have been begging for NAT444 middle-4 space. Well, that might work. Code update on the CPE is all it would take. The systems involved would never see it. From owen at delong.com Tue Feb 1 00:45:43 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 31 Jan 2011 22:45:43 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <5D2659F3-5853-4C1C-A26D-D6EB5AA75195@delong.com> Message-ID: On Jan 31, 2011, at 10:26 PM, Michael Dillon wrote: >> In my opinion, RFC 4193 is just a bad idea and there's no benefit to it vs. >> GUA. Just put a good stateful firewall in front of your GUA. >> >> I mean, really, how many things do you have that don't need access >> to/from the internet. Maybe your printers and a couple of appliances. >> >> The rest... All those TiVOs, Laptops, Desktops, iPads, etc. all need >> public addresses anyway, so, why bother with the ULA? > > Because the ULA addressing is free, not that hard, and provides an > extra layer of protection to prevent vandals from using up your printer > ink or turning your fridge on defrost during the night. > Well, 2 out of 3 isn't bad, I suppose, but, do you really get even that? ULA addressing is free, except for the costs imposed by using it instead of GUA in most circumstances. I'll give you 0.5 for this one. ULA addressing is not that hard. Neither is GUA. In fact they both pose exactly the same difficulty. So, though I have to grant that it isn't that hard, you failed to show how this fact gives it any advantage over GUA. Additionally, it does create additional difficulties since you now need to maintain two address spaces instead of just one. So, since it's harder than GUA, but, still not that hard, I'll give you 0.5 for that one, too. The last one is specious at best. The stateful firewall provides all the protection there. The ULA doesn't really provide any because if the FW is compromised, you just bounce the print requests off of one of the hosts that has GUA+ULA. Sorry, 0 points here. So, let's see... 0.5+0.5+0 = 1.0 -- Nope, not even 2 out of 3. > And some networks will have a lot more stuff that could use an > extra layer of protection like that, for instance SCADA networks. > If there were an extra layer of protection, sure, but, since there actually isn't, no joy there. If you want to isolate your SCADA network so it doesn't have anything on it that talks to the internet, then, ULA could be just fine, but, in that case, GUA or Link Local may be equally fine with all the same protections and less hassle if you decide to change the policy later. >> Supplying every end site with a /48 of global address space is neither >> stupid or wasteful. It's a good design with some nice future-proofing and >> some very nice features available if people take better advantage of the >> capabilities offered as we move forward. >> >> Just because it's more than you can imagine using today does not mean >> that it is more than you will ever imagine using. I'm very happy that I have >> a /48 at home and I look forward to making better use of it as the >> Consumer Electronics vendors start to catch on that the internet is >> being restored to full functionality for end users. > > Agreed. /48 is good for even the smallest home user living in a one bedroom > apartment. They may not fully exploit it, but at the same time, they should not > be treated as second class citizens when there is enough IPv6 address wealth > to share around. > Well, I'd give /48s even to studios, small lofts, dorm rooms, and any internet- connected janitorial closets in multi-tenant buildings. I see no reason to draw the line at one-bedroom apartments. Owen From joelja at bogus.com Tue Feb 1 01:11:55 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 31 Jan 2011 23:11:55 -0800 Subject: quietly.... In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13776@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13776@RWC-EX1.corp.seven.com> Message-ID: <4D47B23B.4080105@bogus.com> On 1/31/11 10:43 PM, George Bonser wrote: >> >> 3. Busting out 16 more /8s only delays the IPv4 endgame by about a >> year. >> >> jms > > If used for general assignment, sure. But if used for what people have > been begging for NAT444 middle-4 space. Well, that might work. Code > update on the CPE is all it would take. The systems involved would > never see it. except when the tried to determine their external ip. and of course one of the big applications for cgnat is mobile where the cpe are the end systems... There are negligible benefits as far as I can tell from the vantage points of end systems to creating new private scope ipv4 regions at this late date. network operators see some but frankly each one comes with additional support costs as does using rfc1918... the difference is we've got a lot of experience with the latter even in nat444 envirnments. > > > From gbonser at seven.com Tue Feb 1 01:41:56 2011 From: gbonser at seven.com (George Bonser) Date: Mon, 31 Jan 2011 23:41:56 -0800 Subject: quietly.... In-Reply-To: <4D47B23B.4080105@bogus.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13776@RWC-EX1.corp.seven.com> <4D47B23B.4080105@bogus.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13778@RWC-EX1.corp.seven.com> > There are negligible benefits as far as I can tell from the vantage > points of end systems to creating new private scope ipv4 regions at > this > late date. > Here, yes. In other places, maybe there are other factors. I am not saying I favor such a thing, just going through the exercise of thinking through how to deal with one when/if it appears and recognizing that such a thing could happen. Imagine The Repressive Republic of Slobovia wants to absolutely control who talks to whom over that country's internet infrastructure (or, more accurately, who doesn't talk to whom). That is a fairly easy way of doing it. They absolutely control the entire addressing spectrum and if desired, nothing leaks. Now that isn't to say people don't find ways out, as they always will. From mpetach at netflight.com Tue Feb 1 01:48:19 2011 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 31 Jan 2011 23:48:19 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <4D461D6F.1010508@gont.com.ar> References: <4D3FBEA3.6040404@gont.com.ar> <4D461D6F.1010508@gont.com.ar> Message-ID: On Sun, Jan 30, 2011 at 6:24 PM, Fernando Gont wrote: > Hi, Matthew, > > On 30/01/2011 08:17 p.m., Matthew Petach wrote: >>>> The problem I see is the opening of a new, simple, DoS/DDoS scenario. >>>> By repetitively sweeping a targets /64 you can cause EVERYTHING in >>>> that /64 to stop working by overflowing the ND/ND cache, depending on >>>> the specific ND cache implementation and how big it is/etc. >>> >>> That depends on the ND implementation being broken enough by not >>> limiting the number of neighbor cache entries that are in the INCOMPLETE >>> state. (I'm not saying those broken implementations don't exist, though). >> >> Even without completely overflowing the ND cache, informal lab testing >> shows that a single laptop on a well-connected network link can send >> sufficient packets at a very-large-scale backbone router's connected /64 >> subnet to keep the router CPU at 90%, sustained, for as long as you'd >> like. ?So, while it's not a direct denial of service (the network keeps >> functioning, albeit under considerable pain), it's enough to impact the >> ability of the network to react to other dynamic loads. ?:/ > > This is very interesting data. Are you talking about Ciscos? Any > specific model? Uh, I've gotten into some trouble in the past for mentioning router vendors by name before in public forums, so I'm going to avoid public mention of names; but it seems that others in this thread are able to speak up with specific details, if that helps answer your question in a slightly more roundabout way. ^_^; > I guess that a possible mitigation technique (implementation-based) > would be to limit the number of ongoing addresses in address resolution. > (i.e., once you have X ongoing ND resolutions, the router should not be > engaged in ND for other addresses) -- note that addresses that the > router had already resolved in the past would not suffer from this > penalty, as their corresponding entries would be in states other than > INCOMPLETE. > > Thoughts? > > Thanks, That's been one of the areas that's ripe for development, yes; have the control plane take some preferential actions to avoid harming established connectivity under stressful circumstances like that; potentially taking steps to avoid aging out older, potentially still valid entries if there may not be sufficient resources to safely re-learn them, for example. Matt From randy at psg.com Tue Feb 1 02:02:27 2011 From: randy at psg.com (Randy Bush) Date: Tue, 01 Feb 2011 17:02:27 +0900 Subject: ipv4's last graph Message-ID: with the iana free pool run-out, i guess we won't be getting those nice graphs any more. might we have one last one for the turnstiles? :-)/2 and would you mind doing the curves now for each of the five rirs? gotta give us all something to repeat endlessly on lists and in presos. randy From fred at cisco.com Tue Feb 1 02:10:58 2011 From: fred at cisco.com (Fred Baker) Date: Tue, 1 Feb 2011 08:10:58 +0000 Subject: quietly.... In-Reply-To: References: Message-ID: On Feb 1, 2011, at 4:31 AM, Jeremy wrote: > Has there been any discussion about allocating the Class E blocks? If this > doesn't count as "future use" what does? (Yes, I realize this doesn't *fix* > the problem here) yes. The bottom line is that it only gives you a few more /8s, and every host and router in the net has to be updated to accept them. Doesn't actually solve the problem. From adrian at creative.net.au Tue Feb 1 02:10:59 2011 From: adrian at creative.net.au (Adrian Chadd) Date: Tue, 1 Feb 2011 16:10:59 +0800 Subject: ipv4's last graph In-Reply-To: References: Message-ID: <20110201081059.GD16558@skywalker.creative.net.au> On Tue, Feb 01, 2011, Randy Bush wrote: > with the iana free pool run-out, i guess we won't be getting those nice > graphs any more. might we have one last one for the turnstiles? :-)/2 > > and would you mind doing the curves now for each of the five rirs? > gotta give us all something to repeat endlessly on lists and in presos. I think having a graph that reached full and stays there will be quite powerful. :) Adrian From tony at lava.net Tue Feb 1 02:27:18 2011 From: tony at lava.net (Antonio Querubin) Date: Mon, 31 Jan 2011 22:27:18 -1000 (HST) Subject: ipv4's last graph In-Reply-To: <20110201081059.GD16558@skywalker.creative.net.au> References: <20110201081059.GD16558@skywalker.creative.net.au> Message-ID: On Tue, 1 Feb 2011, Adrian Chadd wrote: > I think having a graph that reached full and stays there will be quite > powerful. :) Headline material - IPv4 flatlines ... the world as we know it will come to an end :) Antonio Querubin e-mail/xmpp: tony at lava.net From surfer at mauigateway.com Tue Feb 1 04:20:04 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 1 Feb 2011 02:20:04 -0800 Subject: good night v4 Message-ID: <20110201022004.D28AB216@resin17.mta.everyone.net> I know there're a gazillion counters out there, but one many have watched for a long time is potaroo's (http://www.potaroo.net/tools/ipv4). I was having fun watching it run out tonight. Here's a snapshot with only 1090 routes left: http://mauigateway.com/~surfer/goodnight-v4.png It turns out to be a timer counting down to midnight on the selected day, so everyone saw it goto zero at different times. However, since Hawaii is the last major population in "the world's day" (last one before the International date line) and the counter here hit zero does that mean I will wake up tomorrow to a shiny new internet? scott apologies, it's late and I just couldn't help it... >:-) -- evil grin From bmanning at vacation.karoshi.com Tue Feb 1 04:46:33 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 1 Feb 2011 10:46:33 +0000 Subject: ipv4's last graph In-Reply-To: <20110201081059.GD16558@skywalker.creative.net.au> References: <20110201081059.GD16558@skywalker.creative.net.au> Message-ID: <20110201104633.GB7266@vacation.karoshi.com.> On Tue, Feb 01, 2011 at 04:10:59PM +0800, Adrian Chadd wrote: > On Tue, Feb 01, 2011, Randy Bush wrote: > > with the iana free pool run-out, i guess we won't be getting those nice > > graphs any more. might we have one last one for the turnstiles? :-)/2 > > > > and would you mind doing the curves now for each of the five rirs? > > gotta give us all something to repeat endlessly on lists and in presos. > > I think having a graph that reached full and stays there will be quite > powerful. :) > > Adrian perhaps of more interest would be to see what the injection rate is ... there has been some speculation that holes/more specifics would become more prevalent. but that might be someone elses research... --bill From cowie at renesys.com Tue Feb 1 04:59:00 2011 From: cowie at renesys.com (Jim Cowie) Date: Tue, 1 Feb 2011 05:59:00 -0500 Subject: good night v4 In-Reply-To: <20110201022004.D28AB216@resin17.mta.everyone.net> References: <20110201022004.D28AB216@resin17.mta.everyone.net> Message-ID: I believe I still have a daguerreotype of the steam-powered brass-and-ivory countdown clock that used to live in the Smithsonian. You remember: the one that counted down the days until "United States Real Estate Exhaustion Day" in 1898. The day when all the free land grants ended, and nobody would be able to get space to build a house on any more, or graze their cattle. No more land grants? What will we do?! How will the United States sustain its insane economic growth curve in the 20th century when all the land has been given away? Of course, just in time, President McKinley launched his ambitious program to tear down American society street by street and rebuild it on the Moon, where there's no shortage of free land and colonists willing to stake a claim. And then .. oh, never mind. --jim On Tue, Feb 1, 2011 at 5:20 AM, Scott Weeks wrote: > > > I know there're a gazillion counters out there, but one many have watched > for a long time is potaroo's (http://www.potaroo.net/tools/ipv4). I was > having fun watching it run out tonight. Here's a snapshot with only 1090 > routes left: http://mauigateway.com/~surfer/goodnight-v4.png > > It turns out to be a timer counting down to midnight on the selected day, > so everyone saw it goto zero at different times. However, since Hawaii is > the last major population in "the world's day" (last one before the > International date line) and the counter here hit zero does that mean I will > wake up tomorrow to a shiny new internet? > > scott > apologies, it's late and I just couldn't help it... >:-) -- evil grin > > From iljitsch at muada.com Tue Feb 1 05:18:17 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 1 Feb 2011 12:18:17 +0100 Subject: quietly.... In-Reply-To: References: Message-ID: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> On 1 feb 2011, at 4:55, Jimmy Hess wrote: > IPv4's not dead yet; even the first RIR exhaustion probable in 3 - > 6 months doesn't end the IPv4 ride. IPv4 is very dead in the sense that it's not going to go anywhere in the future. The rest is just procrastination. From iljitsch at muada.com Tue Feb 1 05:31:27 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 1 Feb 2011 12:31:27 +0100 Subject: ipv4's last graph In-Reply-To: References: Message-ID: On 1 feb 2011, at 9:02, Randy Bush wrote: > with the iana free pool run-out, i guess we won't be getting those nice > graphs any more. might we have one last one for the turnstiles? :-)/2 Enjoy this while it lasts then: http://www.bgpexpert.com/ianaglobalpool2.php From rmacharia at gmail.com Tue Feb 1 05:46:02 2011 From: rmacharia at gmail.com (Raymond Macharia) Date: Tue, 1 Feb 2011 14:46:02 +0300 Subject: ipv4's last graph In-Reply-To: References: Message-ID: All manner of dooms day-like stories and headlines tomorrow..I dare predict :-) http://www.cio.co.ke/Top-Stories/address-allocation-kicks-off-ipv4-endgame.html Raymond Macharia On Tue, Feb 1, 2011 at 2:31 PM, Iljitsch van Beijnum wrote: > On 1 feb 2011, at 9:02, Randy Bush wrote: > > > with the iana free pool run-out, i guess we won't be getting those nice > > graphs any more. might we have one last one for the turnstiles? :-)/2 > > Enjoy this while it lasts then: > > http://www.bgpexpert.com/ianaglobalpool2.php > > > From owen at delong.com Tue Feb 1 05:45:50 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 1 Feb 2011 03:45:50 -0800 Subject: quietly.... In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13776@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13776@RWC-EX1.corp.seven.com> Message-ID: <7E73A94E-BF1E-4F48-9243-448F69784016@delong.com> On Jan 31, 2011, at 10:43 PM, George Bonser wrote: >> >> 3. Busting out 16 more /8s only delays the IPv4 endgame by about a >> year. >> >> jms > > If used for general assignment, sure. But if used for what people have > been begging for NAT444 middle-4 space. Well, that might work. Code > update on the CPE is all it would take. The systems involved would > never see it. > > If they could do code updates on the CPE, then, they could use RFC-1918. The problem is that code-updating that much CPE is, well, impractical to say the least. Owen From bmanning at vacation.karoshi.com Tue Feb 1 05:53:15 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 1 Feb 2011 11:53:15 +0000 Subject: quietly.... In-Reply-To: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> Message-ID: <20110201115315.GC7266@vacation.karoshi.com.> On Tue, Feb 01, 2011 at 12:18:17PM +0100, Iljitsch van Beijnum wrote: > On 1 feb 2011, at 4:55, Jimmy Hess wrote: > > > IPv4's not dead yet; even the first RIR exhaustion probable in 3 - > > 6 months doesn't end the IPv4 ride. > > IPv4 is very dead in the sense that it's not going to go anywhere in the future. > > The rest is just procrastination. taking the long view - your statement applies equally to IPv6. of course YMMV --bill From owen at delong.com Tue Feb 1 05:48:47 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 1 Feb 2011 03:48:47 -0800 Subject: quietly.... In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13778@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13776@RWC-EX1.corp.seven.com> <4D47B23B.4080105@bogus.com> <5A6D953473350C4B9995546AFE9939EE0BC13778@RWC-EX1.corp.seven.com> Message-ID: On Jan 31, 2011, at 11:41 PM, George Bonser wrote: >> There are negligible benefits as far as I can tell from the vantage >> points of end systems to creating new private scope ipv4 regions at >> this >> late date. >> > > Here, yes. In other places, maybe there are other factors. I am not > saying I favor such a thing, just going through the exercise of thinking > through how to deal with one when/if it appears and recognizing that > such a thing could happen. > > Imagine The Repressive Republic of Slobovia wants to absolutely control > who talks to whom over that country's internet infrastructure (or, more > accurately, who doesn't talk to whom). That is a fairly easy way of > doing it. They absolutely control the entire addressing spectrum and if > desired, nothing leaks. Now that isn't to say people don't find ways > out, as they always will. > > > > That's a really good reason NOT to provide this ability. There's no advantage to the global internet for facilitating such a thing. Owen From carlosm3011 at gmail.com Tue Feb 1 06:01:21 2011 From: carlosm3011 at gmail.com (Carlos M. Martinez) Date: Tue, 01 Feb 2011 10:01:21 -0200 Subject: quietly.... In-Reply-To: <7E73A94E-BF1E-4F48-9243-448F69784016@delong.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13776@RWC-EX1.corp.seven.com> <7E73A94E-BF1E-4F48-9243-448F69784016@delong.com> Message-ID: <4D47F611.9000406@gmail.com> I think the ship has sailed for the class E /8s. Using them will require significant effort and that effort, both time and money, is better spent on deploying IPv6. regards Carlos On 2/1/11 9:45 AM, Owen DeLong wrote: > On Jan 31, 2011, at 10:43 PM, George Bonser wrote: > >>> 3. Busting out 16 more /8s only delays the IPv4 endgame by about a >>> year. >>> >>> jms >> If used for general assignment, sure. But if used for what people have >> been begging for NAT444 middle-4 space. Well, that might work. Code >> update on the CPE is all it would take. The systems involved would >> never see it. >> >> > If they could do code updates on the CPE, then, they could use RFC-1918. > > The problem is that code-updating that much CPE is, well, impractical to > say the least. > > Owen From owen at delong.com Tue Feb 1 06:01:47 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 1 Feb 2011 04:01:47 -0800 Subject: quietly.... In-Reply-To: <20110201115315.GC7266@vacation.karoshi.com.> References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com.> Message-ID: <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> On Feb 1, 2011, at 3:53 AM, bmanning at vacation.karoshi.com wrote: > On Tue, Feb 01, 2011 at 12:18:17PM +0100, Iljitsch van Beijnum wrote: >> On 1 feb 2011, at 4:55, Jimmy Hess wrote: >> >>> IPv4's not dead yet; even the first RIR exhaustion probable in 3 - >>> 6 months doesn't end the IPv4 ride. >> >> IPv4 is very dead in the sense that it's not going to go anywhere in the future. >> >> The rest is just procrastination. > > > taking the long view - your statement applies equally to IPv6. > > of course YMMV > > --bill I disagree. I think there is little, if any, innovation that will continue to be put into IPv4 hence forth. I think there will be much innovation in IPv6 in the coming years. Owen From iljitsch at muada.com Tue Feb 1 06:16:32 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 1 Feb 2011 13:16:32 +0100 Subject: quietly.... In-Reply-To: <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com.> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> Message-ID: <34265331-F8BD-4A49-BBF9-3E5BEB376DCC@muada.com> On 1 feb 2011, at 13:01, Owen DeLong wrote: >>> IPv4 is very dead in the sense that it's not going to go anywhere in the future. >> taking the long view - your statement applies equally to IPv6. IPv6 has many places to go in the future. Of course the future is long, and there will be a point when IPv6 is no longer what's needed. But we're nowhere close to that point now. > I disagree. I think there is little, if any, innovation that will continue to be put > into IPv4 hence forth. I think there will be much innovation in IPv6 in the > coming years. I'm afraid it may be the other way around: lots of IPv4 innovation just so IPv6 can be avoided a few more years. From adrian at creative.net.au Tue Feb 1 06:39:18 2011 From: adrian at creative.net.au (Adrian Chadd) Date: Tue, 1 Feb 2011 20:39:18 +0800 Subject: quietly.... In-Reply-To: <34265331-F8BD-4A49-BBF9-3E5BEB376DCC@muada.com> References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com.> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> <34265331-F8BD-4A49-BBF9-3E5BEB376DCC@muada.com> Message-ID: <20110201123918.GE16558@skywalker.creative.net.au> s/IPv6/ATM/g Just saying... Adrian On Tue, Feb 01, 2011, Iljitsch van Beijnum wrote: > On 1 feb 2011, at 13:01, Owen DeLong wrote: > > >>> IPv4 is very dead in the sense that it's not going to go anywhere in the future. > > >> taking the long view - your statement applies equally to IPv6. > > IPv6 has many places to go in the future. Of course the future is long, and there will be a point when IPv6 is no longer what's needed. But we're nowhere close to that point now. > > > I disagree. I think there is little, if any, innovation that will continue to be put > > into IPv4 hence forth. I think there will be much innovation in IPv6 in the > > coming years. > > I'm afraid it may be the other way around: lots of IPv4 innovation just so IPv6 can be avoided a few more years. -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA - From marka at isc.org Tue Feb 1 06:59:46 2011 From: marka at isc.org (Mark Andrews) Date: Tue, 01 Feb 2011 23:59:46 +1100 Subject: quietly.... In-Reply-To: Your message of "Tue, 01 Feb 2011 00:00:08 CDT." References: Message-ID: <20110201125946.D4B1F963C18@drugs.dv.isc.org> In message , Mart in Millnert writes: > Jeremy, > > I have not heard of any IP stack that is built to accept 240/4. > Neither Linux 2.6.37 nor Windows 7 accepts it, and let's not think > about all routers, including CPE:s, out there. > The logic goes: > You are many orders of magnitudes more likely to get v6 off the > ground, than 240/4 or 224/4 as unicast IPv4. 224/3 will never be very > usable as public v4 space since every non-upgraded host on the > Internet will be unable to send packets to them, eg, for every > additional host you introduce with these addresses the worse the > reachability situation becomes for the v4 Internet. Notably, this is > the inverse of what happens when you introduce more hosts with native, > proper IPv6, in the IPv6-Internet. > > Cheers, > Martin The lines of code to make 240/4 work as unicast << loc to add IPv6 and will usually fit into the amount of flash already on the CPE box. It's a surgical change rather than add a whole new stack. It might even be possible to convice the CPE vendors to make new images for old hardware. You also don't need to make it work with the whole world. Just between the CPE and the LSN and/or 6rd border router. 15 /8's (leave 255 alone) is a lot of space for a ISP to use. The CPE would signal support (e.g. a DHCP option) and the ISP would only return class E addresses if it was sure the path was clean. Those that need a public address would clear the option. It would default on. With luck the asic will support unicast in 240/4 space so you get fast path for IPv6 using 6rd on IPv4 only routers. This model also allows it to be deployed incrementally. This is a software upgrade rather than a hardware upgrade. If you constrain the problem space it becomes more managable problem. The question is do you want to have to deploy the same address space multiple times or is it worth a little bit of co-ordinated effort to do this. IPv4 + IPv6 [NAT/6RD] E space + public IP4 [NAT/6RD] RFC 1918 space + IPv6 It can also be used to deliver IPv6 only over 6rd. IPv4 + IPv6 [AFTR/6RD] E space [B4/6RD] RFC 1918 + IPv6 (double encap) IPv4 + IPv6 [NAT64/6RD] E space [6RD] IPv6 (single encap) Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jcurran at arin.net Tue Feb 1 07:23:53 2011 From: jcurran at arin.net (John Curran) Date: Tue, 1 Feb 2011 13:23:53 +0000 Subject: =?Windows-1252?Q?Significant_Announcement_(re:_IPv4)__3_February_=96_Watc?= =?Windows-1252?Q?h_it_Live!?= References: <4D47F7DE.6040102@arin.net> Message-ID: <34AA4613-61BD-4C3F-8480-6E10EE6309AE@corp.arin.net> FYI - Some people in this community may want to watch this event (either in person or via webcast) /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN > Date: February 1, 2011 7:09:02 AM EST To: > Subject: [arin-announce] Significant Announcement 3 February ? Watch it Live! On Thursday, 3 February 2011, at 9:30 AM Eastern Standard Time (EST), the Number Resource Organization (NRO), along with the Internet Corporation for Assigned Names and Numbers, the Internet Society (ISOC) and the Internet Architecture Board (IAB) will be holding a ceremony and press conference to make a significant announcement and to discuss the global transition to the next generation of Internet addresses. Much has been written in the international media over the last few weeks about the dwindling pool of Internet addresses using the original Internet protocol, called IPv4 (Internet Protocol version 4), and this topic will be addressed at the event. We invite all interested community members to view the webcast of this event at: http://www.nro.net/news/icann-nro-live-stream In the event you happen to be at the Intercontinental Hotel in Miami on Thursday, there will be limited public seating available to attend (with press receiving seating priority) in Room ?Concourse II? at 9:30 AM EST for the ceremony and 10:00 AM for press conference which follows. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From the76posse at gmail.com Tue Feb 1 07:54:47 2011 From: the76posse at gmail.com (Steve Danelli) Date: Tue, 1 Feb 2011 08:54:47 -0500 Subject: Connectivity to Brazil Message-ID: <4F3DD62E-4007-4ED2-94D6-8405E1C1546E@gmail.com> Hello all!!! First post here Some carrier, somewhere between us and the service provider is selectively dropping the IKE packets originating from our VPN gateway and destined for our Brazil gateway. Other traffic is able to pass, as are the IKE packets coming back from Brazil to us. This is effectively preventing us from establishing the IPSEC tunnel between our gateways. Also something else is awry, for two given hosts on the same subnet (x.y.z.52 and x.y.z.53), they take two wildly divergent paths: For dest x.y.x.52 16 ms 3 ms 3 ms xe-2-3-0.cr1.lga5.us.above.net [64.125.31.34] 2 ms 2 ms 2 ms xe-0-1-0.er1.lga5.us.above.net [64.125.27.61] 12 ms 3 ms 13 ms e2-4-10000m.ar9.nyc1.gblx.net [208.178.58.197] 117 ms 118 ms 118 ms te3-4-10g.asr1.gru1.gblx.net [67.16.142.238] 136 ms 137 ms 136 ms ctbc-multimidia-data-net-s-a.gigabitethernet1-2.ar5.gru1.gblx.net [207.138.94.102] 157 ms 136 ms 138 ms xe-3-2-0-0.core-b.ula001.ctbc.com.br [201.48.44.165] 132 ms 132 ms 141 ms ge-3-0-0-0.core-b.spo511.ctbc.com.br [201.48.44.14] 135 ms 133 ms 134 ms ae1-0.edge-a.spo511.ctbc.com.br [201.48.44.93] For dest x.y.x.53 3 ms 2 ms 3 ms xe-2-3-0.cr1.lga5.us.above.net [64.125.31.34] 2 ms 2 ms 2 ms xe-1-1-0.er1.lga5.us.above.net [64.125.26.162] 19 ms 3 ms 12 ms e2-4-10000m.ar9.nyc1.gblx.net [208.178.58.197] 117 ms 117 ms 117 ms te3-4-10g.asr1.gru1.gblx.net [67.16.142.238] 117 ms 117 ms 118 ms 64.209.106.170 118 ms 118 ms 118 ms ae1-0.edge-a.spo511.ctbc.com.br [201.48.44.93] Anyone have any insight on to what may be occurring? Sent from my iPhone From isabeldias1 at yahoo.com Tue Feb 1 08:10:38 2011 From: isabeldias1 at yahoo.com (isabel dias) Date: Tue, 1 Feb 2011 06:10:38 -0800 (PST) Subject: Connectivity to Brazil In-Reply-To: <4F3DD62E-4007-4ED2-94D6-8405E1C1546E@gmail.com> References: <4F3DD62E-4007-4ED2-94D6-8405E1C1546E@gmail.com> Message-ID: <311170.10596.qm@web121603.mail.ne1.yahoo.com> who are you? ________________________________ From: Steve Danelli To: "nanog at nanog.org" Sent: Tue, February 1, 2011 1:54:47 PM Subject: Connectivity to Brazil Hello all!!!? First post here? Some carrier, somewhere between us and the service provider is selectively dropping the IKE packets originating from our VPN gateway and destined for our Brazil gateway. Other traffic is able to pass, as are the IKE packets coming back from Brazil to us. This is effectively preventing us from establishing the IPSEC tunnel between our gateways. Also something else is awry, for two given hosts on the same subnet (x.y.z.52 and x.y.z.53), they take two wildly divergent paths: For dest? x.y.x.52 ? 16 ms? ? 3 ms? ? 3 ms? xe-2-3-0.cr1.lga5.us.above.net [64.125.31.34] ? 2 ms? ? 2 ms? ? 2 ms? xe-0-1-0.er1.lga5.us.above.net [64.125.27.61] ? 12 ms? ? 3 ms? ? 13 ms? e2-4-10000m.ar9.nyc1.gblx.net [208.178.58.197] ? 117 ms? 118 ms? 118 ms? te3-4-10g.asr1.gru1.gblx.net [67.16.142.238] ? 136 ms? 137 ms? 136 ms? ctbc-multimidia-data-net-s-a.gigabitethernet1-2.ar5.gru1.gblx.net [207.138.94.102] ? 157 ms? 136 ms? 138 ms? xe-3-2-0-0.core-b.ula001.ctbc.com.br [201.48.44.165] ? 132 ms? 132 ms? 141 ms? ge-3-0-0-0.core-b.spo511.ctbc.com.br [201.48.44.14] ? 135 ms? 133 ms? 134 ms? ae1-0.edge-a.spo511.ctbc.com.br [201.48.44.93] For dest? x.y.x.53 ? 3 ms? ? 2 ms? ? 3 ms? xe-2-3-0.cr1.lga5.us.above.net [64.125.31.34] ? 2 ms? ? 2 ms? ? 2 ms? xe-1-1-0.er1.lga5.us.above.net [64.125.26.162] ? 19 ms? ? 3 ms? ? 12 ms? e2-4-10000m.ar9.nyc1.gblx.net [208.178.58.197] ? 117 ms? 117 ms? 117 ms? te3-4-10g.asr1.gru1.gblx.net [67.16.142.238] ? 117 ms? 117 ms? 118 ms? 64.209.106.170 ? 118 ms? 118 ms? 118 ms? ae1-0.edge-a.spo511.ctbc.com.br [201.48.44.93] Anyone have any insight on to what may be occurring? Sent from my iPhone From kevin.hodle at gmail.com Tue Feb 1 08:16:28 2011 From: kevin.hodle at gmail.com (Kevin Hodle) Date: Tue, 1 Feb 2011 15:16:28 +0100 Subject: Connectivity to Brazil In-Reply-To: <311170.10596.qm@web121603.mail.ne1.yahoo.com> References: <4F3DD62E-4007-4ED2-94D6-8405E1C1546E@gmail.com> <311170.10596.qm@web121603.mail.ne1.yahoo.com> Message-ID: OMG !!!...l know this sounds weird and you wouldn't believe me...Yes, am really stuck out here in the UK and it's so devastating at the moment i really need your help l wish l could cal but l don't have access to phone at the moment , I really need your help to get myself out of this mess. The hotel management has been kind to let have an access to a library to get across to anybody to help me since my luggage was also taken away.Hope to hear from you soon ___ Kelvin On Tue, Feb 1, 2011 at 3:10 PM, isabel dias wrote: > who are you? > > > > > ________________________________ > From: Steve Danelli > To: "nanog at nanog.org" > Sent: Tue, February 1, 2011 1:54:47 PM > Subject: Connectivity to Brazil > > Hello all!!!? First post here > > Some carrier, somewhere between us and the service provider is selectively > dropping the IKE packets originating from our VPN gateway and destined for our > Brazil gateway. Other traffic is able to pass, as are the IKE packets coming > back from Brazil to us. This is effectively preventing us from establishing the > IPSEC tunnel between our gateways. > > Also something else is awry, for two given hosts on the same subnet (x.y.z.52 > and x.y.z.53), they take two wildly divergent paths: > > > For dest? x.y.x.52 > > ? 16 ms? ? 3 ms? ? 3 ms? xe-2-3-0.cr1.lga5.us.above.net [64.125.31.34] > ? 2 ms? ? 2 ms? ? 2 ms? xe-0-1-0.er1.lga5.us.above.net [64.125.27.61] > ? 12 ms? ? 3 ms? ? 13 ms? e2-4-10000m.ar9.nyc1.gblx.net [208.178.58.197] > ? 117 ms? 118 ms? 118 ms? te3-4-10g.asr1.gru1.gblx.net [67.16.142.238] > ? 136 ms? 137 ms? 136 ms > ctbc-multimidia-data-net-s-a.gigabitethernet1-2.ar5.gru1.gblx.net > [207.138.94.102] > ? 157 ms? 136 ms? 138 ms? xe-3-2-0-0.core-b.ula001.ctbc.com.br [201.48.44.165] > ? 132 ms? 132 ms? 141 ms? ge-3-0-0-0.core-b.spo511.ctbc.com.br [201.48.44.14] > ? 135 ms? 133 ms? 134 ms? ae1-0.edge-a.spo511.ctbc.com.br [201.48.44.93] > > > For dest? x.y.x.53 > > ? 3 ms? ? 2 ms? ? 3 ms? xe-2-3-0.cr1.lga5.us.above.net [64.125.31.34] > ? 2 ms? ? 2 ms? ? 2 ms? xe-1-1-0.er1.lga5.us.above.net [64.125.26.162] > ? 19 ms? ? 3 ms? ? 12 ms? e2-4-10000m.ar9.nyc1.gblx.net [208.178.58.197] > ? 117 ms? 117 ms? 117 ms? te3-4-10g.asr1.gru1.gblx.net [67.16.142.238] > ? 117 ms? 117 ms? 118 ms? 64.209.106.170 > ? 118 ms? 118 ms? 118 ms? ae1-0.edge-a.spo511.ctbc.com.br [201.48.44.93] > > Anyone have any insight on to what may be occurring? > > > > Sent from my iPhone > > > > -- Cheers, Kevin ================================================================ ?:: :: Kevin Hodle | http://www.linkedin.com/in/kevinhodle ?:: :: PGP Key ID? | fingerprint ?:: :: 0x803F24BE? | 1094 FB06 837F 2FAB C86B E4BE 4680 3679 803F 24BE "Elegance is not a dispensable luxury but a factor that decides between success and failure. " -Edsgar Dijkstra ================================================================ From the76posse at gmail.com Tue Feb 1 08:21:37 2011 From: the76posse at gmail.com (Steve Danelli) Date: Tue, 1 Feb 2011 09:21:37 -0500 Subject: Connectivity to Brazil In-Reply-To: <311170.10596.qm@web121603.mail.ne1.yahoo.com> References: <4F3DD62E-4007-4ED2-94D6-8405E1C1546E@gmail.com> <311170.10596.qm@web121603.mail.ne1.yahoo.com> Message-ID: <2E01B739-4BA6-4B0F-986C-6F8BD798B6FA@gmail.com> Isabel - I am a network engineer working for a small financial firm outside Philadelphia. Can you offer any insight? On Feb 1, 2011, at 9:10 AM, isabel dias wrote: > who are you? > > From: Steve Danelli > To: "nanog at nanog.org" > Sent: Tue, February 1, 2011 1:54:47 PM > Subject: Connectivity to Brazil > > Hello all!!! First post here > > Some carrier, somewhere between us and the service provider is selectively dropping the IKE packets originating from our VPN gateway and destined for our Brazil gateway. Other traffic is able to pass, as are the IKE packets coming back from Brazil to us. This is effectively preventing us from establishing the IPSEC tunnel between our gateways. > > Also something else is awry, for two given hosts on the same subnet (x.y.z.52 and x.y.z.53), they take two wildly divergent paths: > > > For dest x.y.x.52 > > 16 ms 3 ms 3 ms xe-2-3-0.cr1.lga5.us.above.net [64.125.31.34] > 2 ms 2 ms 2 ms xe-0-1-0.er1.lga5.us.above.net [64.125.27.61] > 12 ms 3 ms 13 ms e2-4-10000m.ar9.nyc1.gblx.net [208.178.58.197] > 117 ms 118 ms 118 ms te3-4-10g.asr1.gru1.gblx.net [67.16.142.238] > 136 ms 137 ms 136 ms ctbc-multimidia-data-net-s-a.gigabitethernet1-2.ar5.gru1.gblx.net [207.138.94.102] > 157 ms 136 ms 138 ms xe-3-2-0-0.core-b.ula001.ctbc.com.br [201.48.44.165] > 132 ms 132 ms 141 ms ge-3-0-0-0.core-b.spo511.ctbc.com.br [201.48.44.14] > 135 ms 133 ms 134 ms ae1-0.edge-a.spo511.ctbc.com.br [201.48.44.93] > > > For dest x.y.x.53 > > 3 ms 2 ms 3 ms xe-2-3-0.cr1.lga5.us.above.net [64.125.31.34] > 2 ms 2 ms 2 ms xe-1-1-0.er1.lga5.us.above.net [64.125.26.162] > 19 ms 3 ms 12 ms e2-4-10000m.ar9.nyc1.gblx.net [208.178.58.197] > 117 ms 117 ms 117 ms te3-4-10g.asr1.gru1.gblx.net [67.16.142.238] > 117 ms 117 ms 118 ms 64.209.106.170 > 118 ms 118 ms 118 ms ae1-0.edge-a.spo511.ctbc.com.br [201.48.44.93] > > Anyone have any insight on to what may be occurring? > > > > Sent from my iPhone > From kevin.hodle at gmail.com Tue Feb 1 08:27:41 2011 From: kevin.hodle at gmail.com (Kevin Hodle) Date: Tue, 1 Feb 2011 15:27:41 +0100 Subject: Connectivity to Brazil In-Reply-To: <2E01B739-4BA6-4B0F-986C-6F8BD798B6FA@gmail.com> References: <4F3DD62E-4007-4ED2-94D6-8405E1C1546E@gmail.com> <311170.10596.qm@web121603.mail.ne1.yahoo.com> <2E01B739-4BA6-4B0F-986C-6F8BD798B6FA@gmail.com> Message-ID: I just need you to help me with some cash just till i get back home On Tue, Feb 1, 2011 at 3:21 PM, Steve Danelli wrote: > Isabel - I am a network engineer working for a small financial firm outside Philadelphia. > > Can you offer any insight? > > > On Feb 1, 2011, at 9:10 AM, isabel dias wrote: > >> who are you? >> >> From: Steve Danelli >> To: "nanog at nanog.org" >> Sent: Tue, February 1, 2011 1:54:47 PM >> Subject: Connectivity to Brazil >> >> Hello all!!! ?First post here >> >> Some carrier, somewhere between us and the service provider is selectively dropping the IKE packets originating from our VPN gateway and destined for our Brazil gateway. Other traffic is able to pass, as are the IKE packets coming back from Brazil to us. This is effectively preventing us from establishing the IPSEC tunnel between our gateways. >> >> Also something else is awry, for two given hosts on the same subnet (x.y.z.52 and x.y.z.53), they take two wildly divergent paths: >> >> >> For dest ?x.y.x.52 >> >> ? 16 ms ? ?3 ms ? ?3 ms ?xe-2-3-0.cr1.lga5.us.above.net [64.125.31.34] >> ? 2 ms ? ?2 ms ? ?2 ms ?xe-0-1-0.er1.lga5.us.above.net [64.125.27.61] >> ? 12 ms ? ?3 ms ? ?13 ms ?e2-4-10000m.ar9.nyc1.gblx.net [208.178.58.197] >> ? 117 ms ?118 ms ?118 ms ?te3-4-10g.asr1.gru1.gblx.net [67.16.142.238] >> ? 136 ms ?137 ms ?136 ms ?ctbc-multimidia-data-net-s-a.gigabitethernet1-2.ar5.gru1.gblx.net [207.138.94.102] >> ? 157 ms ?136 ms ?138 ms ?xe-3-2-0-0.core-b.ula001.ctbc.com.br [201.48.44.165] >> ? 132 ms ?132 ms ?141 ms ?ge-3-0-0-0.core-b.spo511.ctbc.com.br [201.48.44.14] >> ? 135 ms ?133 ms ?134 ms ?ae1-0.edge-a.spo511.ctbc.com.br [201.48.44.93] >> >> >> For dest ?x.y.x.53 >> >> ? 3 ms ? ?2 ms ? ?3 ms ?xe-2-3-0.cr1.lga5.us.above.net [64.125.31.34] >> ? 2 ms ? ?2 ms ? ?2 ms ?xe-1-1-0.er1.lga5.us.above.net [64.125.26.162] >> ? 19 ms ? ?3 ms ? ?12 ms ?e2-4-10000m.ar9.nyc1.gblx.net [208.178.58.197] >> ? 117 ms ?117 ms ?117 ms ?te3-4-10g.asr1.gru1.gblx.net [67.16.142.238] >> ? 117 ms ?117 ms ?118 ms ?64.209.106.170 >> ? 118 ms ?118 ms ?118 ms ?ae1-0.edge-a.spo511.ctbc.com.br [201.48.44.93] >> >> Anyone have any insight on to what may be occurring? >> >> >> >> Sent from my iPhone >> > -- Cheers, Kevin ================================================================ ?:: :: Kevin Hodle | http://www.linkedin.com/in/kevinhodle ?:: :: PGP Key ID? | fingerprint ?:: :: 0x803F24BE? | 1094 FB06 837F 2FAB C86B E4BE 4680 3679 803F 24BE "Elegance is not a dispensable luxury but a factor that decides between success and failure. " -Edsgar Dijkstra ================================================================ From rdobbins at arbor.net Tue Feb 1 08:40:47 2011 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 1 Feb 2011 21:40:47 +0700 Subject: 2010 Worldwide Infrastructure Security Report available for download. Message-ID: [Apologies for any duplication if you've seen this notification on other lists.] We've just posted the 2010 Worldwide Infrastructure Security Report for download at this URL: This year's WWISR contains responses and data from the broadest cross-section of SPs to date, including mobile operators and IDC operators in all major geographical regions. The WWISR is based upon input from the global operational community, and as such, is unique in its focus on the operational security aspects of public-facing networks. Many of you contributed to the survey which forms the foundation of the report; as always, we're grateful for your insight and participation, and welcome your feedback and comments. Thanks much! ------------------------------------------------------------------------ Roland Dobbins // From jbates at brightok.net Tue Feb 1 08:50:44 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 01 Feb 2011 08:50:44 -0600 Subject: quietly.... In-Reply-To: References: Message-ID: <4D481DC4.4060606@brightok.net> On 1/31/2011 10:29 PM, Owen DeLong wrote: > 1. Layering NAT beyond 2 deep (one provider, one subscriber) > doesn't help. yep > > 2. NAT444 will break lots of things that work in current NAT44. > To be honest, ds-lite, despite being single layer still breaks most things that a NAT44 with upnp won't. > 3. Users subjected to this environment after experiencing the > limited brokenness of NAT44 or full access to the internet > will not be happy. Neither would an engineer, which is why we have real IPs at our house. :) > 4. Maintaining NAT444 environments will be a support headache > and a costly arms race of deployments and management. Even maintaining dual stack is costly. NAT444 just makes it worse. > > 5. IPv6 will cost a lot less than NAT444 as soon as they can > get their subscribers fully deployed and is a much more > desirable alternative. Yep. Once the NSPs get their stuff done and we have decent routing paths, the eyeballs will either already be done or quickly behind them, and then the content can start switching over without the fears they currently have. Jack From jared at puck.nether.net Tue Feb 1 08:53:59 2011 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 1 Feb 2011 09:53:59 -0500 Subject: quietly.... In-Reply-To: <4D481DC4.4060606@brightok.net> References: <4D481DC4.4060606@brightok.net> Message-ID: <300A32C2-E06F-4DFE-8FEE-82DF47C23269@puck.nether.net> On Feb 1, 2011, at 9:50 AM, Jack Bates wrote: > On 1/31/2011 10:29 PM, Owen DeLong wrote: >> 1. Layering NAT beyond 2 deep (one provider, one subscriber) >> doesn't help. > yep >> >> 2. NAT444 will break lots of things that work in current NAT44. >> > To be honest, ds-lite, despite being single layer still breaks most things that a NAT44 with upnp won't. > >> 3. Users subjected to this environment after experiencing the >> limited brokenness of NAT44 or full access to the internet >> will not be happy. > Neither would an engineer, which is why we have real IPs at our house. :) >> 4. Maintaining NAT444 environments will be a support headache >> and a costly arms race of deployments and management. > Even maintaining dual stack is costly. NAT444 just makes it worse. >> >> 5. IPv6 will cost a lot less than NAT444 as soon as they can >> get their subscribers fully deployed and is a much more >> desirable alternative. > > Yep. Once the NSPs get their stuff done and we have decent routing paths, the eyeballs will either already be done or quickly behind them, and then the content can start switching over without the fears they currently have. Honestly, if you can't get native wholesale IP, you are buying from the wrong carriers. - Jared From jbates at brightok.net Tue Feb 1 08:57:47 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 01 Feb 2011 08:57:47 -0600 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: References: <4D3FBEA3.6040404@gont.com.ar> Message-ID: <4D481F6B.8070708@brightok.net> On 1/31/2011 11:02 PM, Mikael Abrahamsson wrote: > Guess XR is the way to go if one wants to keep it for a few more years... Or XE (lower end ASR uses XE I believe). Jack From jbates at brightok.net Tue Feb 1 09:04:01 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 01 Feb 2011 09:04:01 -0600 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <5D2659F3-5853-4C1C-A26D-D6EB5AA75195@delong.com> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <5D2659F3-5853-4C1C-A26D-D6EB5AA75195@delong.com> Message-ID: <4D4820E1.20600@brightok.net> On 2/1/2011 12:03 AM, Owen DeLong wrote: > The rest... All those TiVOs, Laptops, Desktops, iPads, etc. all need > public addresses anyway, so, why bother with the ULA? > I think ULA is still useful for home networks. If the home router guys properly generate the ULA dynamically, it should stop conflicts within home networking. There's something to be said for internal services which ULA can be useful for, even when you do fall off the net. Jack From tme at americafree.tv Tue Feb 1 09:13:34 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Tue, 1 Feb 2011 10:13:34 -0500 Subject: quietly.... In-Reply-To: <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com.> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> Message-ID: <03B2CC80-BFD3-4EFB-A008-8C8349F01F75@americafree.tv> On Feb 1, 2011, at 7:01 AM, Owen DeLong wrote: > > On Feb 1, 2011, at 3:53 AM, bmanning at vacation.karoshi.com wrote: > >> On Tue, Feb 01, 2011 at 12:18:17PM +0100, Iljitsch van Beijnum wrote: >>> On 1 feb 2011, at 4:55, Jimmy Hess wrote: >>> >>>> IPv4's not dead yet; even the first RIR exhaustion probable in 3 - >>>> 6 months doesn't end the IPv4 ride. >>> >>> IPv4 is very dead in the sense that it's not going to go anywhere in the future. >>> >>> The rest is just procrastination. >> >> >> taking the long view - your statement applies equally to IPv6. >> >> of course YMMV >> >> --bill > > I disagree. I think there is little, if any, innovation that will continue to be put > into IPv4 hence forth. I think there will be much innovation in IPv6 in the > coming years. I think that this is what will finally drive true v6 adaptation (as opposed to having it as some sort of super NAT). As v6 innovation continues, v4 will be seen as something obsolete that needs constant work (and v4 innovation will be more and more about patching it to work and keep up with v6). Regards Marshall > > Owen > > > From jbates at brightok.net Tue Feb 1 09:21:19 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 01 Feb 2011 09:21:19 -0600 Subject: quietly.... In-Reply-To: <03B2CC80-BFD3-4EFB-A008-8C8349F01F75@americafree.tv> References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com.> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> <03B2CC80-BFD3-4EFB-A008-8C8349F01F75@americafree.tv> Message-ID: <4D4824EF.2060801@brightok.net> On 2/1/2011 9:13 AM, Marshall Eubanks wrote: > As v6 innovation continues, v4 will be seen as something obsolete > that needs constant work (and v4 innovation will be more and more > about patching it to work and keep up with v6). If it continues. The sad thing is, transition would have been a lot smoother if not for IETF politics. "You can't have these features! It's not IPv4! They would work perfectly fine, but we don't want you to do that!" I still know a LOT of people who have no desire to switch. They are holding out until vendors implement the features they want. NAPTv6, default router in DHCPv6, etc, etc. Jack From tim at pelican.org Tue Feb 1 09:23:24 2011 From: tim at pelican.org (Tim Franklin) Date: Tue, 1 Feb 2011 15:23:24 +0000 (GMT) Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <22200733.31296573696794.JavaMail.root@jennyfur.pelican.org> Message-ID: <9175394.51296573804403.JavaMail.root@jennyfur.pelican.org> > I think ULA is still useful for home networks. If the home router guys > properly generate the ULA dynamically, it should stop conflicts within > home networking. There's something to be said for internal services > which ULA can be useful for, even when you do fall off the net. I really, *really* expect my CPE router *not* to remove global addresses from the LAN interface(s) when the link to the Internet goes down. My internal services should go on working with their global addresses. This is how my tunneled IPv6 works today. Am I being an unreasonable engineer in this respect? Regards, Tim. From jbates at brightok.net Tue Feb 1 09:43:47 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 01 Feb 2011 09:43:47 -0600 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <9175394.51296573804403.JavaMail.root@jennyfur.pelican.org> References: <9175394.51296573804403.JavaMail.root@jennyfur.pelican.org> Message-ID: <4D482A33.8010100@brightok.net> On 2/1/2011 9:23 AM, Tim Franklin wrote: > I really,*really* expect my CPE router*not* to remove global > addresses from the LAN interface(s) when the link to the Internet > goes down. My internal services should go on working with their > global addresses. This is how my tunneled IPv6 works today. > > Am I being an unreasonable engineer in this respect? This depends. Will you have a static assignment? What will be the lifetime values issued by your ISP? Granted, You should be able to maintain them at least 2 hours, though in a multiple router scenario, I'm not sure how well they'll take to routing unpreferred prefixes. ULA isn't a bad thing. It also doesn't interfere with your GUA. There's really no reason NOT to have ULA in CPE devices. If your DSL is down for a day or two, do you really want to worry about addressing? Do you want to connect to the Internet before you can have addressing? Jack From jbates at brightok.net Tue Feb 1 10:01:01 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 01 Feb 2011 10:01:01 -0600 Subject: quietly.... In-Reply-To: <300A32C2-E06F-4DFE-8FEE-82DF47C23269@puck.nether.net> References: <4D481DC4.4060606@brightok.net> <300A32C2-E06F-4DFE-8FEE-82DF47C23269@puck.nether.net> Message-ID: <4D482E3D.4070805@brightok.net> On 2/1/2011 8:53 AM, Jared Mauch wrote: > Honestly, if you can't get native wholesale IP, you are buying from the wrong carriers. I agree. I did up the $5 million budget to light dwdm ring with 8x10GE to Dallas where I could connect to any provider I wanted, but it was unfortunately declined. However, that's not the point. The point is that IPv6 routing paths through the largest networks are not the same as IPv4 routing paths. There are still many unoptimized routes and even a lack of peering. General latency and bandwidth availability for IPv6 is a QOS nightmare compared to IPv4. The weirdest one I came across is that, at one point, I had the best connectivity with limelight (for netflix streams) by sending packets out L3, and having them return via a HE tunnel. It was, of course, well below IPv4 standards. Jack From isabeldias1 at yahoo.com Tue Feb 1 10:16:42 2011 From: isabeldias1 at yahoo.com (isabel dias) Date: Tue, 1 Feb 2011 08:16:42 -0800 (PST) Subject: Connectivity to Brazil In-Reply-To: References: <4F3DD62E-4007-4ED2-94D6-8405E1C1546E@gmail.com> <311170.10596.qm@web121603.mail.ne1.yahoo.com> <2E01B739-4BA6-4B0F-986C-6F8BD798B6FA@gmail.com> Message-ID: <70930.68036.qm@web121601.mail.ne1.yahoo.com> I still don't know where you are and the simulation you are doing .....can you be more specific ? ________________________________ From: Kevin Hodle To: Steve Danelli Cc: isabel dias ; "nanog at nanog.org" Sent: Tue, February 1, 2011 2:27:41 PM Subject: Re: Connectivity to Brazil I just need you to help me with some cash just till i get back home On Tue, Feb 1, 2011 at 3:21 PM, Steve Danelli wrote: > Isabel - I am a network engineer working for a small financial firm outside >Philadelphia. > > Can you offer any insight? > > > On Feb 1, 2011, at 9:10 AM, isabel dias wrote: > >> who are you? >> >> From: Steve Danelli >> To: "nanog at nanog.org" >> Sent: Tue, February 1, 2011 1:54:47 PM >> Subject: Connectivity to Brazil >> >> Hello all!!! ?First post here >> >> Some carrier, somewhere between us and the service provider is selectively >>dropping the IKE packets originating from our VPN gateway and destined for our >>Brazil gateway. Other traffic is able to pass, as are the IKE packets coming >>back from Brazil to us. This is effectively preventing us from establishing the >>IPSEC tunnel between our gateways. >> >> Also something else is awry, for two given hosts on the same subnet (x.y.z.52 >>and x.y.z.53), they take two wildly divergent paths: >> >> >> For dest ?x.y.x.52 >> >> ? 16 ms ? ?3 ms ? ?3 ms ?xe-2-3-0.cr1.lga5.us.above.net [64.125.31.34] >> ? 2 ms ? ?2 ms ? ?2 ms ?xe-0-1-0.er1.lga5.us.above.net [64.125.27.61] >> ? 12 ms ? ?3 ms ? ?13 ms ?e2-4-10000m.ar9.nyc1.gblx.net [208.178.58.197] >> ? 117 ms ?118 ms ?118 ms ?te3-4-10g.asr1.gru1.gblx.net [67.16.142.238] >> ? 136 ms ?137 ms ?136 ms >>?ctbc-multimidia-data-net-s-a.gigabitethernet1-2.ar5.gru1.gblx.net >>[207.138.94.102] >> ? 157 ms ?136 ms ?138 ms ?xe-3-2-0-0.core-b.ula001.ctbc.com.br [201.48.44.165] >> ? 132 ms ?132 ms ?141 ms ?ge-3-0-0-0.core-b.spo511.ctbc.com.br [201.48.44.14] >> ? 135 ms ?133 ms ?134 ms ?ae1-0.edge-a.spo511.ctbc.com.br [201.48.44.93] >> >> >> For dest ?x.y.x.53 >> >> ? 3 ms ? ?2 ms ? ?3 ms ?xe-2-3-0.cr1.lga5.us.above.net [64.125.31.34] >> ? 2 ms ? ?2 ms ? ?2 ms ?xe-1-1-0.er1.lga5.us.above.net [64.125.26.162] >> ? 19 ms ? ?3 ms ? ?12 ms ?e2-4-10000m.ar9.nyc1.gblx.net [208.178.58.197] >> ? 117 ms ?117 ms ?117 ms ?te3-4-10g.asr1.gru1.gblx.net [67.16.142.238] >> ? 117 ms ?117 ms ?118 ms ?64.209.106.170 >> ? 118 ms ?118 ms ?118 ms ?ae1-0.edge-a.spo511.ctbc.com.br [201.48.44.93] >> >> Anyone have any insight on to what may be occurring? >> >> >> >> Sent from my iPhone >> > -- Cheers, Kevin ================================================================ ?:: :: Kevin Hodle | http://www.linkedin.com/in/kevinhodle ?:: :: PGP Key ID? | fingerprint ?:: :: 0x803F24BE? | 1094 FB06 837F 2FAB C86B E4BE 4680 3679 803F 24BE "Elegance is not a dispensable luxury but a factor that decides between success and failure. " -Edsgar Dijkstra ================================================================ From alh-ietf at tndh.net Tue Feb 1 10:18:38 2011 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 1 Feb 2011 08:18:38 -0800 Subject: ipv4's last graph In-Reply-To: References: Message-ID: <135901cbc22b$b88705f0$299511d0$@net> The individual RIR graphs won't be around long enough to be worth the effort... ;) FWIW: the Jan. 2011 global burn rate (outbound from the RIRs) for /24-equivlents was 18.97 seconds. At the Jan. rate, APnic won't last to June and Ripe might make to the end of August, then chaos ensues. Is there really any value in trying to distribute graphs that will all be flat before the end of the year? Tony > -----Original Message----- > From: Randy Bush [mailto:randy at psg.com] > Sent: Tuesday, February 01, 2011 12:02 AM > To: Geoff Huston > Cc: NANOG Operators' Group > Subject: ipv4's last graph > > with the iana free pool run-out, i guess we won't be getting those nice > graphs any more. might we have one last one for the turnstiles? :-)/2 > > and would you mind doing the curves now for each of the five rirs? > gotta give us all something to repeat endlessly on lists and in presos. > > randy From isabeldias1 at yahoo.com Tue Feb 1 10:22:12 2011 From: isabeldias1 at yahoo.com (isabel dias) Date: Tue, 1 Feb 2011 08:22:12 -0800 (PST) Subject: Connectivity to Brazil In-Reply-To: <70930.68036.qm@web121601.mail.ne1.yahoo.com> References: <4F3DD62E-4007-4ED2-94D6-8405E1C1546E@gmail.com> <311170.10596.qm@web121603.mail.ne1.yahoo.com> <2E01B739-4BA6-4B0F-986C-6F8BD798B6FA@gmail.com> <70930.68036.qm@web121601.mail.ne1.yahoo.com> Message-ID: <694637.31012.qm@web121606.mail.ne1.yahoo.com> normally address to service providers that sit behind a block of addresses and are able to provide visibility from their networks ,? looking glasses are as usefull but if you need someone to be as cleaver as the ones on?training at Holloway just be more specific as there are plenty of options around the world and also in the UK ......:-) ________________________________ From: isabel dias To: Kevin Hodle ; Steve Danelli Cc: "nanog at nanog.org" Sent: Tue, February 1, 2011 4:16:42 PM Subject: Re: Connectivity to Brazil I still don't know where you are and the simulation you are doing .....can you be more specific ? ________________________________ From: Kevin Hodle To: Steve Danelli Cc: isabel dias ; "nanog at nanog.org" Sent: Tue, February 1, 2011 2:27:41 PM Subject: Re: Connectivity to Brazil I just need you to help me with some cash just till i get back home On Tue, Feb 1, 2011 at 3:21 PM, Steve Danelli wrote: > Isabel - I am a network engineer working for a small financial firm outside >Philadelphia. > > Can you offer any insight? > > > On Feb 1, 2011, at 9:10 AM, isabel dias wrote: > >> who are you? >> >> From: Steve Danelli >> To: "nanog at nanog.org" >> Sent: Tue, February 1, 2011 1:54:47 PM >> Subject: Connectivity to Brazil >> >> Hello all!!! ?First post here >> >> Some carrier, somewhere between us and the service provider is selectively >>dropping the IKE packets originating from our VPN gateway and destined for our >>Brazil gateway. Other traffic is able to pass, as are the IKE packets coming >>back from Brazil to us. This is effectively preventing us from establishing the > >>IPSEC tunnel between our gateways. >> >> Also something else is awry, for two given hosts on the same subnet (x.y.z.52 >>and x.y.z.53), they take two wildly divergent paths: >> >> >> For dest ?x.y.x.52 >> >> ? 16 ms ? ?3 ms ? ?3 ms ?xe-2-3-0.cr1.lga5.us.above.net [64.125.31.34] >> ? 2 ms ? ?2 ms ? ?2 ms ?xe-0-1-0.er1.lga5.us.above.net [64.125.27.61] >> ? 12 ms ? ?3 ms ? ?13 ms ?e2-4-10000m.ar9.nyc1.gblx.net [208.178.58.197] >> ? 117 ms ?118 ms ?118 ms ?te3-4-10g.asr1.gru1.gblx.net [67.16.142.238] >> ? 136 ms ?137 ms ?136 ms >>?ctbc-multimidia-data-net-s-a.gigabitethernet1-2.ar5.gru1.gblx.net >>[207.138.94.102] >> ? 157 ms ?136 ms ?138 ms ?xe-3-2-0-0.core-b.ula001.ctbc.com.br [201.48.44.165] >> ? 132 ms ?132 ms ?141 ms ?ge-3-0-0-0.core-b.spo511.ctbc.com.br [201.48.44.14] >> ? 135 ms ?133 ms ?134 ms ?ae1-0.edge-a.spo511.ctbc.com.br [201.48.44.93] >> >> >> For dest ?x.y.x.53 >> >> ? 3 ms ? ?2 ms ? ?3 ms ?xe-2-3-0.cr1.lga5.us.above.net [64.125.31.34] >> ? 2 ms ? ?2 ms ? ?2 ms ?xe-1-1-0.er1.lga5.us.above.net [64.125.26.162] >> ? 19 ms ? ?3 ms ? ?12 ms ?e2-4-10000m.ar9.nyc1.gblx.net [208.178.58.197] >> ? 117 ms ?117 ms ?117 ms ?te3-4-10g.asr1.gru1.gblx.net [67.16.142.238] >> ? 117 ms ?117 ms ?118 ms ?64.209.106.170 >> ? 118 ms ?118 ms ?118 ms ?ae1-0.edge-a.spo511.ctbc.com.br [201.48.44.93] >> >> Anyone have any insight on to what may be occurring? >> >> >> >> Sent from my iPhone >> > -- Cheers, Kevin ================================================================ ?:: :: Kevin Hodle | http://www.linkedin.com/in/kevinhodle ?:: :: PGP Key ID? | fingerprint ?:: :: 0x803F24BE? | 1094 FB06 837F 2FAB C86B E4BE 4680 3679 803F 24BE "Elegance is not a dispensable luxury but a factor that decides between success and failure. " -Edsgar Dijkstra ================================================================ From kmedcalf at dessus.com Tue Feb 1 10:33:40 2011 From: kmedcalf at dessus.com (kmedcalf at dessus.com) Date: Tue, 01 Feb 2011 11:33:40 -0500 Subject: OT: Anyone have PDF Manual for Nortel/BayStack 425-24T Switch Message-ID: Does anyone happen to have PDF Manuals (not the sales literature, but the switch software command references) for this switch? We have one in a production network and know nothing about it nor how to manage it. Nortel does not make any of the manuals available anymore, at least not in the interwebs (that I can find) nor does googling turn up anything very useful. Any help would be appreciated. If nothing can be found this will probably be discarded and replaced with appropriately supported product. Now, back to your regularly scheduled programming ... ---- #include From aservin at lacnic.net Tue Feb 1 10:53:48 2011 From: aservin at lacnic.net (Arturo Servin) Date: Tue, 1 Feb 2011 11:53:48 -0500 Subject: ipv4's last graph In-Reply-To: <135901cbc22b$b88705f0$299511d0$@net> References: <135901cbc22b$b88705f0$299511d0$@net> Message-ID: <70931B35-09A5-4FC3-BF5E-5A7139DD5BE9@lacnic.net> We have been doing it for a few months. http://www.lacnic.net/en/registro/espacio-disponible-ipv4.html We are working in a new model to forecast the available space over time and in providing the data so anybody can do their own graphs. Also APNIC has some very useful data: http://www.apnic.net/community/ipv4-exhaustion/graphical-information Regards, -as On 1 Feb 2011, at 11:18, Tony Hain wrote: > The individual RIR graphs won't be around long enough to be worth the > effort... ;) > > FWIW: the Jan. 2011 global burn rate (outbound from the RIRs) for > /24-equivlents was 18.97 seconds. At the Jan. rate, APnic won't last to June > and Ripe might make to the end of August, then chaos ensues. Is there really > any value in trying to distribute graphs that will all be flat before the > end of the year? > > Tony > > >> -----Original Message----- >> From: Randy Bush [mailto:randy at psg.com] >> Sent: Tuesday, February 01, 2011 12:02 AM >> To: Geoff Huston >> Cc: NANOG Operators' Group >> Subject: ipv4's last graph >> >> with the iana free pool run-out, i guess we won't be getting those nice >> graphs any more. might we have one last one for the turnstiles? :-)/2 >> >> and would you mind doing the curves now for each of the five rirs? >> gotta give us all something to repeat endlessly on lists and in presos. >> >> randy > From dredd at megacity.org Tue Feb 1 11:09:23 2011 From: dredd at megacity.org (Derek J. Balling) Date: Tue, 1 Feb 2011 12:09:23 -0500 Subject: OT: Anyone have PDF Manual for Nortel/BayStack 425-24T Switch In-Reply-To: References: Message-ID: On Feb 1, 2011, at 11:33 AM, kmedcalf at dessus.com wrote: > If nothing can be found this will probably be discarded and replaced with appropriately supported product. Is this code for "Please don't reply with 'I've got that file!'"? :-) Cheers, D From kmedcalf at dessus.com Tue Feb 1 11:14:28 2011 From: kmedcalf at dessus.com (kmedcalf at dessus.com) Date: Tue, 01 Feb 2011 12:14:28 -0500 Subject: Thanks for the Info! (was: Anyone have PDF Manual for Nortel/BayStack 425-24T Switch) In-Reply-To: References: Message-ID: Thanks for the reply's. A User Guide was forwarded which should enable access to this switch. On Tue, 01 Feb 2011 11:33:40 -0500, "kmedcalf at dessus.com" wrote: > Does anyone happen to have PDF Manuals (not the sales literature, >but the switch software command references) for this switch? We have >one in a production network and know nothing about it nor how to >manage it. Nortel does not make any of the manuals available >anymore, at least not in the interwebs (that I can find) nor does >googling turn up anything very useful. Any help would be >appreciated. If nothing can be found this will probably be discarded >and replaced with appropriately supported product. ---- #include From morrowc.lists at gmail.com Tue Feb 1 11:14:47 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 1 Feb 2011 12:14:47 -0500 Subject: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database) In-Reply-To: References: Message-ID: On Sun, Jan 30, 2011 at 2:55 PM, Martin Millnert wrote: > Here be dragons, > It should be fairly obvious, by most recently what's going on in > Egypt, why allowing a government to control the Internet is a Really > Bad Idea. > how is the egypt thing related to rPKI? How is the propsed rPKI work related to gov't control? > architecturally/technologically *impossible* for a entity from country > A to via-the-hierarchical-trust-model block a prefix assigned to some > entity in country B, that is assigned by B's RIR and in full > accordance with the RIR policies and in no breach of any contract. countries do not have RIR's, countries have NIR's... regions have RIR's. From owen at delong.com Tue Feb 1 11:29:43 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 1 Feb 2011 09:29:43 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <4D4820E1.20600@brightok.net> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <5D2659F3-5853-4C1C-A26D-D6EB5AA75195@delong.com> <4D4820E1.20600@brightok.net> Message-ID: <077208EB-39DF-4F51-B263-E1BEB0BCE75A@delong.com> On Feb 1, 2011, at 7:04 AM, Jack Bates wrote: > > > On 2/1/2011 12:03 AM, Owen DeLong wrote: >> The rest... All those TiVOs, Laptops, Desktops, iPads, etc. all need >> public addresses anyway, so, why bother with the ULA? >> > > I think ULA is still useful for home networks. If the home router guys properly generate the ULA dynamically, it should stop conflicts within home networking. There's something to be said for internal services which ULA can be useful for, even when you do fall off the net. > > > Jack I prefer persistent GUA over ULA for that. Owen From jbates at brightok.net Tue Feb 1 11:39:22 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 01 Feb 2011 11:39:22 -0600 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <077208EB-39DF-4F51-B263-E1BEB0BCE75A@delong.com> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <5D2659F3-5853-4C1C-A26D-D6EB5AA75195@delong.com> <4D4820E1.20600@brightok.net> <077208EB-39DF-4F51-B263-E1BEB0BCE75A@delong.com> Message-ID: <4D48454A.1090807@brightok.net> On 2/1/2011 11:29 AM, Owen DeLong wrote: > > I prefer persistent GUA over ULA for that. > I do too, though for simple zeroconf devices, I'd prefer ULA over link local. Given that it's not an either or situation, I fully support ULA existing. Jack From wade.peacock at sunwave.net Tue Feb 1 12:35:55 2011 From: wade.peacock at sunwave.net (Wade Peacock) Date: Tue, 01 Feb 2011 10:35:55 -0800 Subject: Akamai - Timouts (TCP Stalls) at the SIX In-Reply-To: <4D472951.90806@gmail.com> References: <4D472951.90806@gmail.com> Message-ID: <4D48528B.9060900@sunwave.net> We've been experiencing issue with content coming from Akamai servers located in Seattle since Thursday January 27, 2011. Our upstream peers directly with Akamai as the SIX (Seattle Internet Exchange). We've been seeing timeouts/partial loads for sites with content delivered from IP block 96.17.8.0/24. Known impacted site for our customers: www.cbc.ca www.ebay.ca www.westjet.ca(redirect to www.westjet.com) We've opened tickets with our upstream and Akamai, but we are curious if others are experiencing the same issues. Wade Peacock Network Administrator Sun Country Cablevision Ltd Sunwave Internet Department Tel: (250) 832-9711 or (250) 546-9667 Dir: (250) 832-5123 x 220 Web: http://www.sunwave.net Email: wade.peacock at sunwave.net Support Email: support at sunwave.net From mpetach at netflight.com Tue Feb 1 12:36:38 2011 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 1 Feb 2011 10:36:38 -0800 Subject: 2011.02.01 NANOG51 day2 morning session notes posted Message-ID: (sorry about the delay, had to hop on a vendor call right as lunch break started) Morning session notes have been posted to http://kestrel3.netflight.com/2011.02.01-NANOG51-morning-notes.txt for those following along remotely. Very nice handoff and signing ceremony this morning by Steve Feldman and Don Welch--congratulations, newNOG, new owners of the NANOG name! Matt From rodrick.brown at gmail.com Tue Feb 1 12:41:21 2011 From: rodrick.brown at gmail.com (Rodrick Brown) Date: Tue, 1 Feb 2011 13:41:21 -0500 Subject: Last of ipv4 /8's allocated Message-ID: <8B6687A8-F4DB-4E98-BCFE-772B48EFCC06@gmail.com> http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml Sent from my iPhone 4. From nanog at rhemasound.org Tue Feb 1 12:49:02 2011 From: nanog at rhemasound.org (Brian Christopher Raaen) Date: Tue, 1 Feb 2011 13:49:02 -0500 Subject: Last of ipv4 /8's allocated In-Reply-To: <8B6687A8-F4DB-4E98-BCFE-772B48EFCC06@gmail.com> References: <8B6687A8-F4DB-4E98-BCFE-772B48EFCC06@gmail.com> Message-ID: <201102011349.02921.nanog@rhemasound.org> On Tuesday, February 01, 2011 01:41:21 pm Rodrick Brown wrote: > http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml > > Sent from my iPhone 4. Not quite, I still show 102/8, 103/8, 104/8, 179/8, and 185/8 as "UNALLOCATED". I don't know when the hand out the last 5 /8's policy takes affect, but they haven't handed them out yet. --- Brian Raaen Network Architech From daodennis at gmail.com Tue Feb 1 13:04:05 2011 From: daodennis at gmail.com (Dennis) Date: Tue, 1 Feb 2011 11:04:05 -0800 Subject: Akamai - Timouts (TCP Stalls) at the SIX In-Reply-To: <4D48528B.9060900@sunwave.net> References: <4D472951.90806@gmail.com> <4D48528B.9060900@sunwave.net> Message-ID: On Tue, Feb 1, 2011 at 10:35 AM, Wade Peacock wrote: > We've opened tickets with our upstream and Akamai, but we are curious if > others are experiencing the same issues. > Confirmed. We also peer with them at the SIX and have seen issues since Friday. > > From justin.horstman at gorillanation.com Tue Feb 1 13:07:21 2011 From: justin.horstman at gorillanation.com (Justin Horstman) Date: Tue, 1 Feb 2011 11:07:21 -0800 Subject: Last of ipv4 /8's allocated In-Reply-To: <201102011349.02921.nanog@rhemasound.org> References: <8B6687A8-F4DB-4E98-BCFE-772B48EFCC06@gmail.com> <201102011349.02921.nanog@rhemasound.org> Message-ID: <8C164D3BAF7C7F41B9B286385037B1311909D817ED@lax-exch-fe-01.gorillanation.local> > -----Original Message----- > From: Brian Christopher Raaen [mailto:nanog at rhemasound.org] > Sent: Tuesday, February 01, 2011 10:49 AM > To: nanog at nanog.org > Subject: Re: Last of ipv4 /8's allocated > > On Tuesday, February 01, 2011 01:41:21 pm Rodrick Brown wrote: > > http://www.iana.org/assignments/ipv4-address-space/ipv4-address- > space.xml > > > > Sent from my iPhone 4. > > Not quite, I still show 102/8, 103/8, 104/8, 179/8, and 185/8 as > "UNALLOCATED". I don't know when the hand out the last 5 /8's policy > takes > affect, but they haven't handed them out yet. > > --- > Brian Raaen > Network Architech As noted in the "quietly" thread...(very good thread btw), the last 5 will be automatically allocated across the rirs "shortly". ~J From dot at dotat.at Tue Feb 1 13:22:20 2011 From: dot at dotat.at (Tony Finch) Date: Tue, 1 Feb 2011 19:22:20 +0000 Subject: Last of ipv4 /8's allocated In-Reply-To: <201102011349.02921.nanog@rhemasound.org> References: <8B6687A8-F4DB-4E98-BCFE-772B48EFCC06@gmail.com> <201102011349.02921.nanog@rhemasound.org> Message-ID: On Tue, 1 Feb 2011, Brian Christopher Raaen wrote: > > Not quite, I still show 102/8, 103/8, 104/8, 179/8, and 185/8 as > "UNALLOCATED". I don't know when the hand out the last 5 /8's policy takes > affect, but they haven't handed them out yet. I expect it'll happen on Thursday. http://www.nro.net/news/icann-nro-live-stream Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. From morrowc.lists at gmail.com Tue Feb 1 13:53:26 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 1 Feb 2011 14:53:26 -0500 Subject: Last of ipv4 /8's allocated In-Reply-To: <201102011349.02921.nanog@rhemasound.org> References: <8B6687A8-F4DB-4E98-BCFE-772B48EFCC06@gmail.com> <201102011349.02921.nanog@rhemasound.org> Message-ID: On Tue, Feb 1, 2011 at 1:49 PM, Brian Christopher Raaen wrote: > On Tuesday, February 01, 2011 01:41:21 pm Rodrick Brown wrote: >> http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml >> >> Sent from my iPhone 4. > > Not quite, I still show 102/8, 103/8, 104/8, 179/8, and 185/8 as > "UNALLOCATED". ?I don't know when the hand out the last 5 /8's policy takes > affect, but they haven't handed them out yet. cron is your friend: ~$ wget -O - -q http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt | grep UNALLOCATED | grep '^ * [1234567890]' | wc -l 5 From iljitsch at muada.com Tue Feb 1 13:57:23 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 1 Feb 2011 20:57:23 +0100 Subject: quietly.... In-Reply-To: <4D4824EF.2060801@brightok.net> References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com.> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> <03B2CC80-BFD3-4EFB-A008-8C8349F01F75@americafree.tv> <4D4824EF.2060801@brightok.net> Message-ID: On 1 feb 2011, at 16:21, Jack Bates wrote: > I still know a LOT of people who have no desire to switch. They are holding out until vendors implement the features they want. NAPTv6, default router in DHCPv6, etc, etc. What's the point of switching to IPv6 if it repeats all the IPv4 mistakes only with bigger addresses? If you like NAT IPv4 is the place to be, it'll only get more and more. From davei at otd.com Tue Feb 1 14:03:26 2011 From: davei at otd.com (Dave Israel) Date: Tue, 01 Feb 2011 15:03:26 -0500 Subject: quietly.... In-Reply-To: References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com.> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> <03B2CC80-BFD3-4EFB-A008-8C8349F01F75@americafree.tv> <4D4824EF.2060801@brightok.net> Message-ID: <4D48670E.2040505@otd.com> On 2/1/2011 2:57 PM, Iljitsch van Beijnum wrote: > On 1 feb 2011, at 16:21, Jack Bates wrote: > >> I still know a LOT of people who have no desire to switch. They are holding out until vendors implement the features they want. NAPTv6, default router in DHCPv6, etc, etc. > What's the point of switching to IPv6 if it repeats all the IPv4 mistakes only with bigger addresses? Bigger addresses. People want to engineer their networks they way they want to. Let them. If their way is stupid, then they'll have the stupidly engineered network they wanted. Telling them they have to do it your way because their way is stupid is just going to keep them from changing and increases a chance of a NATernet. -Dave From drais at icantclick.org Tue Feb 1 14:08:22 2011 From: drais at icantclick.org (david raistrick) Date: Tue, 1 Feb 2011 15:08:22 -0500 (EST) Subject: quietly.... In-Reply-To: References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com.> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> <03B2CC80-BFD3-4EFB-A008-8C8349F01F75@americafree.tv> <4D4824EF.2060801@brightok.net> Message-ID: On Tue, 1 Feb 2011, Iljitsch van Beijnum wrote: > What's the point of switching to IPv6 if it repeats all the IPv4 > mistakes only with bigger addresses? > > If you like NAT IPv4 is the place to be, it'll only get more and more. It's argument like this that has lead to this moment. Instead of discussing "how can the next generation addressing scheme support the needs of Internet consumers today and tomorrow" we tell people "if you don't like it, use v4" Guess what? We're still using v4. ..david -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From rcarpen at network1.net Tue Feb 1 14:10:43 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Tue, 1 Feb 2011 15:10:43 -0500 (EST) Subject: quietly.... In-Reply-To: <4D48670E.2040505@otd.com> Message-ID: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> ----- Original Message ----- > On 2/1/2011 2:57 PM, Iljitsch van Beijnum wrote: > > On 1 feb 2011, at 16:21, Jack Bates wrote: > > > >> I still know a LOT of people who have no desire to switch. They are > >> holding out until vendors implement the features they want. NAPTv6, > >> default router in DHCPv6, etc, etc. > > What's the point of switching to IPv6 if it repeats all the IPv4 > > mistakes only with bigger addresses? > > Bigger addresses. People want to engineer their networks they way they > want to. Let them. If their way is stupid, then they'll have the > stupidly engineered network they wanted. Telling them they have to do > it your way because their way is stupid is just going to keep them > from > changing and increases a chance of a NATernet. > > -Dave So, we should just have no rules or standards at all, and just let people do whatever they want. How well would that work? -Randy From gih at apnic.net Tue Feb 1 14:11:39 2011 From: gih at apnic.net (Geoff Huston) Date: Wed, 2 Feb 2011 07:11:39 +1100 Subject: ipv4's last graph In-Reply-To: References: Message-ID: <876F9BFF-4807-49A5-9D76-9FC067CCC645@apnic.net> On 01/02/2011, at 7:02 PM, Randy Bush wrote: > with the iana free pool run-out, i guess we won't be getting those nice > graphs any more. might we have one last one for the turnstiles? :-)/2 > > and would you mind doing the curves now for each of the five rirs? > gotta give us all something to repeat endlessly on lists and in presos. but of course. http://www.potaroo.net/tools/ipv4/rir.jpg This is a different graph - it is a probabilistic graph that shows the predicted month when the RIR will be down to its last /8 policy (whatever that policy may be), and the relative probability that the event will occur in that particular month. The assumption behind this graph is that the barricades will go up across the regions and each region will work from its local address pools and service only its local client base, and that as each region gets to its last /8 policy the applicants will not transfer their demand to those regions where addresses are still available. Its not possible to quantify how (in)accurate this assumption may be, so beyond the prediction of the first exhaustion point (which is at this stage looking more likely to occur in July 2011 than not) the predictions for the other RIRs are highly uncertain. Geoff From Valdis.Kletnieks at vt.edu Tue Feb 1 14:19:53 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 01 Feb 2011 15:19:53 -0500 Subject: Connectivity to Brazil In-Reply-To: Your message of "Tue, 01 Feb 2011 08:54:47 EST." <4F3DD62E-4007-4ED2-94D6-8405E1C1546E@gmail.com> References: <4F3DD62E-4007-4ED2-94D6-8405E1C1546E@gmail.com> Message-ID: <33104.1296591593@localhost> On Tue, 01 Feb 2011 08:54:47 EST, Steve Danelli said: > Some carrier, somewhere between us and the service provider is selectively > dropping the IKE packets originating from our VPN gateway and destined for > our Brazil gateway. Other traffic is able to pass, as are the IKE packets coming > back from Brazil to us. This is effectively preventing us from establishing > the IPSEC tunnel between our gateways. Has IKE been known to work to that location before? Or is this something new? My first guess is some chucklehead banana-eater at the service provider either fat-fingered the firewall config, or semi-intentionally blocked it because it was "traffic on a protocol/port number they didn't understand so it must be evil". > Also something else is awry, for two given hosts on the same subnet (x.y.z.52 > and x.y.z.53), they take two wildly divergent paths: > Anyone have any insight on to what may be occurring? The paths appear to diverge at 67.16.142.238. I wonder if that's gear trying to do some load-balancing across 2 paths, and it's using the source IP as a major part of the selector function ("route to round-robin interface source-IP mod N" or similar?). The other possibility is your two traceroutes happened to catch a routing flap in progress (obviously not the case if the two routes are remaining stable). Sorry I can't be more helpful than that... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From davei at otd.com Tue Feb 1 14:24:47 2011 From: davei at otd.com (Dave Israel) Date: Tue, 01 Feb 2011 15:24:47 -0500 Subject: quietly.... In-Reply-To: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> Message-ID: <4D486C0F.7050804@otd.com> On 2/1/2011 3:10 PM, Randy Carpenter wrote: > ----- Original Message ----- >> On 2/1/2011 2:57 PM, Iljitsch van Beijnum wrote: >>> On 1 feb 2011, at 16:21, Jack Bates wrote: >>> >>>> I still know a LOT of people who have no desire to switch. They are >>>> holding out until vendors implement the features they want. NAPTv6, >>>> default router in DHCPv6, etc, etc. >>> What's the point of switching to IPv6 if it repeats all the IPv4 >>> mistakes only with bigger addresses? >> Bigger addresses. People want to engineer their networks they way they >> want to. Let them. If their way is stupid, then they'll have the >> stupidly engineered network they wanted. Telling them they have to do >> it your way because their way is stupid is just going to keep them >> from >> changing and increases a chance of a NATernet. >> >> -Dave > So, we should just have no rules or standards at all, and just let people do whatever they want. How well would that work? We should, and do, have rules and standards for how networks communicate with each other. We can, and should, publish advice on how a network can be built to work properly, internally and externally. We should not say, you must run your internals the way we think a network should be run internally. Every network operator's network is their concern, and making it work is their responsibility. If they want to use DHCPv6, or NAT, or Packet over Avian Carrier to achieve that, let them. If using them causes them problems, then they should not use them. It really isn't the community's place to force people not to use tools they find useful because we do not like them. -Dave From paul at paulgraydon.co.uk Tue Feb 1 14:27:45 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Tue, 01 Feb 2011 10:27:45 -1000 Subject: quietly.... In-Reply-To: References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com.> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> <03B2CC80-BFD3-4EFB-A008-8C8349F01F75@americafree.tv> <4D4824EF.2060801@brightok.net> Message-ID: <4D486CC1.1020602@paulgraydon.co.uk> On 02/01/2011 10:08 AM, david raistrick wrote: > On Tue, 1 Feb 2011, Iljitsch van Beijnum wrote: > >> What's the point of switching to IPv6 if it repeats all the IPv4 >> mistakes only with bigger addresses? >> >> If you like NAT IPv4 is the place to be, it'll only get more and more. > > It's argument like this that has lead to this moment. Instead of > discussing "how can the next generation addressing scheme support the > needs of Internet consumers today and tomorrow" we tell people "if you > don't like it, use v4" > > > Guess what? We're still using v4. > > ..david > We're still using v4 because we can, because there has been no compelling business case to justify spending time on something that isn't necessary just right now, especially given the not insignificant changes between v4 and v6. There is nothing on line that isn't accessible over IPv4 so there has been no critical app outside the infrastructure to spur such changes yet either. We can all sit here and say "Hey we're running out of addresses, we must switch" but until we've run out you're not going to convince the large majority of operators, who lets face it are traditionally lazy^W^W cautious people , to do anything. Paul From tme at americafree.tv Tue Feb 1 14:30:53 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Tue, 1 Feb 2011 15:30:53 -0500 Subject: Connectivity status for Egypt In-Reply-To: <5EEA5622-9EDA-4FD6-B4BE-F4E2C812A271@americafree.tv> References: <33496563.960.1296250642067.JavaMail.franck@franck-martins-macbook-pro.local> <5EEA5622-9EDA-4FD6-B4BE-F4E2C812A271@americafree.tv> Message-ID: <86D21E41-69F3-4F3C-994F-BBED3619E5DC@americafree.tv> On Jan 31, 2011, at 5:14 PM, Marshall Eubanks wrote: > As an update, BGP for Noor.net has been withdrawn. Even the Egyptian stock exchange - egyptse.com - now appears to be off the Internet. > I have been told that the Egyptian Prime Minister has publicly announced that the Internet would be restored soon, but at present neither my monitoring nor http://stat.ripe.net/egypt/ confirms this. Regards Marshall > DNS for egyptse.com also appears to be down, but Noor.net is definitely withdrawn : > > dig www.noor.net > > ; <<>> DiG 9.6.0-APPLE-P2 <<>> www.noor.net > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15709 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;www.noor.net. IN A > > ;; ANSWER SECTION: > www.noor.net. 503 IN CNAME noor.net. > noor.net. 503 IN A 217.139.227.20 > > show ip bgp 217.139.227.20 > % Network not in table > > > Marshall > > > > On Jan 28, 2011, at 4:37 PM, Franck Martin wrote: > >> If I'm correct, in 2000 in Fiji, the main fiber optic cable from the national provider to the international provider was sabotaged, cutting all communications. Fortunately an Alcatel team was on the island (SCC commissioning) with the right tools and could splice it back in a few hours, otherwise Fiji would have gone dark for days... >> >> ----- Original Message ----- >> From: "Joe Abley" >> To: "Marshall Eubanks" >> Cc: nanog at nanog.org >> Sent: Saturday, 29 January, 2011 7:32:07 AM >> Subject: Re: Connectivity status for Egypt >> >> >> On 2011-01-28, at 11:33, Marshall Eubanks wrote: >> >>> On Jan 28, 2011, at 11:24 AM, Jared Mauch wrote: >>> >>>> I have seen nation state disconnects where light is lost. >>> >>> I believe that was the case for Burma, for example. >> >> It was not the case in Nepal in 2005 though, if I remember correctly. In that case connectivity to the outside was maintained, but access to that connectivity by people inside the country was curtailed. >> >> >> Joe >> >> >> > > > From iljitsch at muada.com Tue Feb 1 14:32:43 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 1 Feb 2011 21:32:43 +0100 Subject: quietly.... In-Reply-To: <4D48670E.2040505@otd.com> References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com.> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> <03B2CC80-BFD3-4EFB-A008-8C8349F01F75@americafree.tv> <4D4824EF.2060801@brightok.net> <4D48670E.2040505@otd.com> Message-ID: On 1 feb 2011, at 21:03, Dave Israel wrote: > People want to engineer their networks they way they want to. Let them. If their way is stupid, then they'll have the stupidly engineered network they wanted. The problem is that their stupidity impacts ME. If I want to talk to Microsoft from behind a < 1500 byte MTU link: too bad, not going to happen. They stupidly send packets with DF=1 but filter incoming packet too big messages. So I'm all in favor of the IETF blocking stupidity whenever possible. From msa at latt.net Tue Feb 1 14:32:51 2011 From: msa at latt.net (Majdi S. Abbas) Date: Tue, 1 Feb 2011 13:32:51 -0700 Subject: quietly.... In-Reply-To: <4D486CC1.1020602@paulgraydon.co.uk> References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com.> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> <03B2CC80-BFD3-4EFB-A008-8C8349F01F75@americafree.tv> <4D4824EF.2060801@brightok.net> <4D486CC1.1020602@paulgraydon.co.uk> Message-ID: <20110201203251.GF65077@puck.nether.net> On Tue, Feb 01, 2011 at 10:27:45AM -1000, Paul Graydon wrote: > insignificant changes between v4 and v6. There is nothing on line > that isn't accessible over IPv4 so there has been no critical app > outside the infrastructure to spur such changes yet either. Paul, You're speaking for yourself here, as some of us have hosts with no A record. If your business requires connectivity, you're not going to have a choice, so you might as well get with the program. It's less about making a business case for v6, and more about risk management at this point. It's not as if we haven't had 15 years to get it together... Cheers, --msa From drais at icantclick.org Tue Feb 1 14:36:03 2011 From: drais at icantclick.org (david raistrick) Date: Tue, 1 Feb 2011 15:36:03 -0500 (EST) Subject: quietly.... In-Reply-To: <4D486C0F.7050804@otd.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> Message-ID: On Tue, 1 Feb 2011, Dave Israel wrote: > responsibility. If they want to use DHCPv6, or NAT, or Packet over Avian > Carrier to achieve that, let them. If using them causes them problems, then > they should not use them. It really isn't the community's place to force > people not to use tools they find useful because we do not like them. Not to mention that when you take tools -away- from people that solve an existing problem, you'll get a lot of pushback. -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From millnert at gmail.com Tue Feb 1 14:39:48 2011 From: millnert at gmail.com (Martin Millnert) Date: Tue, 1 Feb 2011 15:39:48 -0500 Subject: quietly.... In-Reply-To: <20110201203251.GF65077@puck.nether.net> References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com.> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> <03B2CC80-BFD3-4EFB-A008-8C8349F01F75@americafree.tv> <4D4824EF.2060801@brightok.net> <4D486CC1.1020602@paulgraydon.co.uk> <20110201203251.GF65077@puck.nether.net> Message-ID: On Tue, Feb 1, 2011 at 3:32 PM, Majdi S. Abbas wrote: > ? ? ? ?If your business requires connectivity, you're not going to > have a choice, so you might as well get with the program. ?It's > less about making a business case for v6, and more about risk > management at this point. +1 Regards, Martin From davei at otd.com Tue Feb 1 14:44:40 2011 From: davei at otd.com (Dave Israel) Date: Tue, 01 Feb 2011 15:44:40 -0500 Subject: quietly.... In-Reply-To: References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com.> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> <03B2CC80-BFD3-4EFB-A008-8C8349F01F75@americafree.tv> <4D4824EF.2060801@brightok.net> <4D48670E.2040505@otd.com> Message-ID: <4D4870B8.4010809@otd.com> On 2/1/2011 3:32 PM, Iljitsch van Beijnum wrote: > On 1 feb 2011, at 21:03, Dave Israel wrote: > >> People want to engineer their networks they way they want to. Let them. If their way is stupid, then they'll have the stupidly engineered network they wanted. > The problem is that their stupidity impacts ME. If I want to talk to Microsoft from behind a< 1500 byte MTU link: too bad, not going to happen. They stupidly send packets with DF=1 but filter incoming packet too big messages. > > So I'm all in favor of the IETF blocking stupidity whenever possible. > I completely agree that, when interoperating, you have to follow the rules, and I would (naively) hope that "customers cannot reach me because of my configuration choice" is sufficient incentive to fix the problem for the majority of network operators. But what I am arguing against was the stance some people take against DHCPv6, or prefix lengths longer than /64, or other internal-to-my-network, why-should-you-care choices I might make. Telling me it is dumb is fine; implementing software/hardware/protocols such that I can't do it simply because you think it is dumb is a problem. -Dave From streiner at cluebyfour.org Tue Feb 1 10:51:42 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 1 Feb 2011 11:51:42 -0500 (EST) Subject: quietly.... In-Reply-To: <4D4870B8.4010809@otd.com> References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com.> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> <03B2CC80-BFD3-4EFB-A008-8C8349F01F75@americafree.tv> <4D4824EF.2060801@brightok.net> <4D48670E.2040505@otd.com> <4D4870B8.4010809@otd.com> Message-ID: On Tue, 1 Feb 2011, Dave Israel wrote: > I completely agree that, when interoperating, you have to follow the rules, > and I would (naively) hope that "customers cannot reach me because of my > configuration choice" is sufficient incentive to fix the problem for the > majority of network operators. But what I am arguing against was the stance > some people take against DHCPv6, or prefix lengths longer than /64, or other > internal-to-my-network, why-should-you-care choices I might make. Telling me > it is dumb is fine; implementing software/hardware/protocols such that I > can't do it simply because you think it is dumb is a problem. DHCPv6 can have a very valid and useful place in the overall scheme of things, in terms of managing address assignments. I've been somewhat disappointed that it's taken this long to see the light of day. jms From the76posse at gmail.com Tue Feb 1 14:57:10 2011 From: the76posse at gmail.com (Steve Danelli) Date: Tue, 1 Feb 2011 15:57:10 -0500 Subject: Connectivity to Brazil In-Reply-To: <33104.1296591593@localhost> References: <4F3DD62E-4007-4ED2-94D6-8405E1C1546E@gmail.com> <33104.1296591593@localhost> Message-ID: <80F3BEC5-89AA-4D54-95EA-976AC3292E60@gmail.com> Thanks for the response. Ike had worked great up until Monday. The provider did a local test and our box saw the Ike packets so it appears to lie somewhere upstream. (GLBX may be a good guess) Also - the paths are stable and we are sourcing from the same ip - very strange behaivor. Hope someone from GLBX or CTBC (or someone who had experienced an issue like this) can assist Thanks to all for their feedback so far. SD On Feb 1, 2011, at 3:19 PM, Valdis.Kletnieks at vt.edu wrote: > On Tue, 01 Feb 2011 08:54:47 EST, Steve Danelli said: > >> Some carrier, somewhere between us and the service provider is selectively >> dropping the IKE packets originating from our VPN gateway and destined for >> our Brazil gateway. Other traffic is able to pass, as are the IKE packets coming >> back from Brazil to us. This is effectively preventing us from establishing >> the IPSEC tunnel between our gateways. > > Has IKE been known to work to that location before? Or is this something new? > My first guess is some chucklehead banana-eater at the service provider either > fat-fingered the firewall config, or semi-intentionally blocked it because it > was "traffic on a protocol/port number they didn't understand so it must be > evil". > >> Also something else is awry, for two given hosts on the same subnet (x.y.z.52 >> and x.y.z.53), they take two wildly divergent paths: > >> Anyone have any insight on to what may be occurring? > > The paths appear to diverge at 67.16.142.238. I wonder if that's gear trying > to do some load-balancing across 2 paths, and it's using the source IP as a > major part of the selector function ("route to round-robin interface source-IP > mod N" or similar?). > > The other possibility is your two traceroutes happened to catch a routing flap in > progress (obviously not the case if the two routes are remaining stable). > > Sorry I can't be more helpful than that... From randy at psg.com Tue Feb 1 15:08:13 2011 From: randy at psg.com (Randy Bush) Date: Wed, 02 Feb 2011 06:08:13 +0900 Subject: ipv4's last graph In-Reply-To: <135901cbc22b$b88705f0$299511d0$@net> References: <135901cbc22b$b88705f0$299511d0$@net> Message-ID: > FWIW: the Jan. 2011 global burn rate (outbound from the RIRs) for > /24-equivlents was 18.97 seconds. At the Jan. rate, APnic won't last > to June and Ripe might make to the end of August, then chaos ensues. this is not the murdoch press or fox news. i very much doubt chaos will ensue. our job is to see that chaos does not ensue. you will learn to love nat444 :) > Is there really any value in trying to distribute graphs that will all > be flat before the end of the year? we're ops, often stick in the mud traditionalists and even somewhat supersitious. we've had ipv4 graphs for over 15 years. we like them. geoff is mr graph. we like his grphs. heck, you have even used them. randy From Valdis.Kletnieks at vt.edu Tue Feb 1 15:08:32 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 01 Feb 2011 16:08:32 -0500 Subject: quietly.... In-Reply-To: Your message of "Tue, 01 Feb 2011 10:27:45 -1000." <4D486CC1.1020602@paulgraydon.co.uk> References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> <03B2CC80-BFD3-4EFB-A008-8C8349F01F75@americafree.tv> <4D4824EF.2060801@brightok.net> <4D486CC1.1020602@paulgraydon.co.uk> Message-ID: <35392.1296594512@localhost> On Tue, 01 Feb 2011 10:27:45 -1000, Paul Graydon said: > We're still using v4 because we can, because there has been no > compelling business case to justify spending time on something that > isn't necessary just right now, especially given the not insignificant > changes between v4 and v6. There is nothing on line that isn't > accessible over IPv4 so there has been no critical app outside the > infrastructure to spur such changes yet either. And if you're not working on deploying IPv6 now, will you be able to survive the delay when something critical *does* come online and you need 18 months or whatever to deploy? Heck - we started deploying in Feb 1997 or so, and as I write this, MRTG is reporting that about 5% of our off-campus traffic is via IPv6 - probably due to the fact that we hit Google and Youtube that way. But we *still* have gear and software that doesn't play nice (though almost all of that is our own internal headaches and not very visible to end users - their connectivity works). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From owen at delong.com Tue Feb 1 15:14:13 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 1 Feb 2011 13:14:13 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <4D482A33.8010100@brightok.net> References: <9175394.51296573804403.JavaMail.root@jennyfur.pelican.org> <4D482A33.8010100@brightok.net> Message-ID: <73720109-B8E1-4FBA-86A7-C2D16E72C91D@delong.com> On Feb 1, 2011, at 7:43 AM, Jack Bates wrote: > > > On 2/1/2011 9:23 AM, Tim Franklin wrote: >> I really,*really* expect my CPE router*not* to remove global >> addresses from the LAN interface(s) when the link to the Internet >> goes down. My internal services should go on working with their >> global addresses. This is how my tunneled IPv6 works today. >> >> Am I being an unreasonable engineer in this respect? > > This depends. Will you have a static assignment? What will be the lifetime values issued by your ISP? Granted, You should be able to maintain them at least 2 hours, though in a multiple router scenario, I'm not sure how well they'll take to routing unpreferred prefixes. > > ULA isn't a bad thing. It also doesn't interfere with your GUA. There's really no reason NOT to have ULA in CPE devices. If your DSL is down for a day or two, do you really want to worry about addressing? Do you want to connect to the Internet before you can have addressing? > ULA is a bad thing. There are multiple problems likely to be caused by it. There really are reasons NOT to put ULA in CPE devices. There are better solutions to the downed internet connection than ULA. Owen > > Jack From bensons at queuefull.net Tue Feb 1 15:23:17 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Tue, 1 Feb 2011 15:23:17 -0600 Subject: ipv4's last graph In-Reply-To: References: <135901cbc22b$b88705f0$299511d0$@net> Message-ID: <3912E787-774E-4DC0-B8BC-D1DF237C706A@queuefull.net> On Feb 1, 2011, at 3:08 PM, Randy Bush wrote: > >> Is there really any value in trying to distribute graphs that will all >> be flat before the end of the year? > > we're ops, often stick in the mud traditionalists and even somewhat > supersitious. we've had ipv4 graphs for over 15 years. we like them. > geoff is mr graph. we like his grphs. heck, you have even used them. If you're standing near the edge of a cliff, the difference between 1 inch and 6 inches is significant. Vendors are watching from the distance, saying "he's at the edge of the cliff!". But to the guy standing there, it matters. Plus, I like graphs. Cheers, -Benson From owen at delong.com Tue Feb 1 15:23:40 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 1 Feb 2011 13:23:40 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <4D48454A.1090807@brightok.net> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <5D2659F3-5853-4C1C-A26D-D6EB5AA75195@delong.com> <4D4820E1.20600@brightok.net> <077208EB-39DF-4F51-B263-E1BEB0BCE75A@delong.com> <4D48454A.1090807@brightok.net> Message-ID: On Feb 1, 2011, at 9:39 AM, Jack Bates wrote: > On 2/1/2011 11:29 AM, Owen DeLong wrote: >> >> I prefer persistent GUA over ULA for that. >> > > I do too, though for simple zeroconf devices, I'd prefer ULA over link local. Given that it's not an either or situation, I fully support ULA existing. > > > Jack Given the vast probability for abuse of ULA becoming de facto GUA later, I don't support ULA existing as the benefits are vastly overwhelmed by the potential for abouse. From owen at delong.com Tue Feb 1 15:20:37 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 1 Feb 2011 13:20:37 -0800 Subject: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database) In-Reply-To: References: Message-ID: <35655C23-B950-4F5B-A63A-0CCAB7442859@delong.com> On Feb 1, 2011, at 9:14 AM, Christopher Morrow wrote: > On Sun, Jan 30, 2011 at 2:55 PM, Martin Millnert wrote: >> Here be dragons, > >> It should be fairly obvious, by most recently what's going on in >> Egypt, why allowing a government to control the Internet is a Really >> Bad Idea. >> > > how is the egypt thing related to rPKI? > How is the propsed rPKI work related to gov't control? > RPKI is a big knob governments might be tempted to turn. >> architecturally/technologically *impossible* for a entity from country >> A to via-the-hierarchical-trust-model block a prefix assigned to some >> entity in country B, that is assigned by B's RIR and in full >> accordance with the RIR policies and in no breach of any contract. > > countries do not have RIR's, countries have NIR's... regions have RIR's. RIRs live in countries with governments. RIRs are unlikely to mount a successful challenge against an organization with tanks and mortars. Owen From paul at paulgraydon.co.uk Tue Feb 1 15:24:57 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Tue, 01 Feb 2011 11:24:57 -1000 Subject: quietly.... In-Reply-To: <20110201203251.GF65077@puck.nether.net> References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com.> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> <03B2CC80-BFD3-4EFB-A008-8C8349F01F75@americafree.tv> <4D4824EF.2060801@brightok.net> <4D486CC1.1020602@paulgraydon.co.uk> <20110201203251.GF65077@puck.nether.net> Message-ID: <4D487A29.3000003@paulgraydon.co.uk> On 02/01/2011 10:32 AM, Majdi S. Abbas wrote: > On Tue, Feb 01, 2011 at 10:27:45AM -1000, Paul Graydon wrote: >> insignificant changes between v4 and v6. There is nothing on line >> that isn't accessible over IPv4 so there has been no critical app >> outside the infrastructure to spur such changes yet either. > Paul, > > You're speaking for yourself here, as some of us have > hosts with no A record. > > If your business requires connectivity, you're not going to > have a choice, so you might as well get with the program. It's > less about making a business case for v6, and more about risk > management at this point. > > It's not as if we haven't had 15 years to get it together... > > Cheers, > > --msa I should emphasise I'm a sysadmin rather than a service provider, and I'm mostly speaking generically based on conversations with a number of sysadmins. I've been trying to get my service provider to sort out IPv6 for a while now (they tell me their infrastructure is ready, but they're being lazy about getting blocks sorted out) and already done as much preparation as I can with my infrastructure to ensure its ready for it. That said there are no services we use that are IPv6 only, nor are there likely to be for a while that I can tell as none of our service partners are talking about it, and nor are we getting reports of anyone unable to access our services due to lack of IPv6 on the front end. I know how ugly that sounds, I really do, but that's the way most people will see it. You have to provide incentive to make a change, and "It's better" rarely is enough. "People won't be able to access our site" sure helps but being unable to put a date on it still reduces incentive (especially when Management get involved, and especially if there is a financial outlay involving firewalls etc.). People bury their heads in the sand and will continue to pretend there is nothing wrong until they're /forced/ to change. As much as it was a hideous and inaccurate article, that Fox news story that was posted on list the other day came up was great for fighting for change. The grossly inaccurate end-of-the-world text provides a good hook for getting the lumbering beast moving in the right direction. The White House's push for IPv6 amongst federal agencies is currently my best guess at what will probably see the first thing to transition to it from my perspective at work, though I sincerely hope we'll be on IPv6 long before that happens. As for when we'll switch internally? No idea.. all machines have IPv6 so some local traffic probably uses it, but most are still based on IPv4 and until I have time / money to make some other infrastructure changes will remain that way (our office environment equipment can't handle IPv6, unlike our production environment) I'm sure there are some cases with IPv6, yourself as an example, and I know an ISP I worked for in the UK had a customer several years ago who had a critical need for it, but that's still in the minority. In every case as soon as there is a business reason for it and its compelling enough people will take the time to make the transition. Paul From randy at psg.com Tue Feb 1 15:25:18 2011 From: randy at psg.com (Randy Bush) Date: Wed, 02 Feb 2011 06:25:18 +0900 Subject: ipv4's last graph In-Reply-To: <876F9BFF-4807-49A5-9D76-9FC067CCC645@apnic.net> References: <876F9BFF-4807-49A5-9D76-9FC067CCC645@apnic.net> Message-ID: > http://www.potaroo.net/tools/ipv4/rir.jpg > > This is a different graph - it is a probabilistic graph that shows the > predicted month when the RIR will be down to its last /8 policy > (whatever that policy may be), and the relative probability that the > event will occur in that particular month. brilliant! and damned useful! there's a reason you get the big bucks. thanks. really appreciated. randy From bensons at queuefull.net Tue Feb 1 15:29:53 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Tue, 1 Feb 2011 15:29:53 -0600 Subject: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database) In-Reply-To: References: Message-ID: On Feb 1, 2011, at 11:14 AM, Christopher Morrow wrote: > On Sun, Jan 30, 2011 at 2:55 PM, Martin Millnert wrote: >> Here be dragons, > >> It should be fairly obvious, by most recently what's going on in >> Egypt, why allowing a government to control the Internet is a Really >> Bad Idea. >> > > how is the egypt thing related to rPKI? > How is the propsed rPKI work related to gov't control? In theory at least, entities closer to the RPKI root (RIRs, IANA) could invalidate routes for any sort of policy reasons. This might provide leverage to certain governments, perhaps even offering the ability to control routing beyond their jurisdiction. As an example, it's imaginable that the US government could require IANA or ARIN to delegate authority to the NSA for a Canadian ISP's routes. Feel free to replace the RIR/LIR and country names, to suit your own example. Cheers, -Benson From mpetach at netflight.com Tue Feb 1 15:32:47 2011 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 1 Feb 2011 13:32:47 -0800 Subject: 2011.02.01 NANOG51 day 2 afternoon session notes Message-ID: I've posted the afternoon notes from today's session at http://kestrel3.netflight.com/2011.02.01-NANOG51-afternoon-notes.txt Definitely not as happy with the flash video stream as I was with the hi-def VLC video stream that was provided at NANOG49. :( Lots of player problems and audio stuttering/loss on the flash stream for me. Any chance of the hi-def VLC stream coming back for future NANOGs, or was the bandwidth requirement too high to be feasible? Thanks! Matt From m.hallgren at free.fr Tue Feb 1 15:33:19 2011 From: m.hallgren at free.fr (Michael Hallgren) Date: Tue, 01 Feb 2011 22:33:19 +0100 Subject: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database) In-Reply-To: References: Message-ID: <1296595999.16035.6.camel@home> Le mardi 01 f?vrier 2011 ? 12:14 -0500, Christopher Morrow a ?crit : > On Sun, Jan 30, 2011 at 2:55 PM, Martin Millnert wrote: > > Here be dragons, > > > It should be fairly obvious, by most recently what's going on in > > Egypt, why allowing a government to control the Internet is a Really > > Bad Idea. > > > > how is the egypt thing related to rPKI? > How is the propsed rPKI work related to gov't control? > > > architecturally/technologically *impossible* for a entity from country > > A to via-the-hierarchical-trust-model block a prefix assigned to some > > entity in country B, that is assigned by B's RIR and in full > > accordance with the RIR policies and in no breach of any contract. > > countries do not have RIR's, countries have NIR's... regions have RIR's. In this context, at least, perhaps the NIR should be considered superfluous or redundant? What is the operational rationale behind the NIR level? Wouldn't a flatter RIR-LIR structure do just fine? mh > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From townsley at cisco.com Tue Feb 1 15:34:11 2011 From: townsley at cisco.com (Mark Townsley) Date: Tue, 1 Feb 2011 22:34:11 +0100 Subject: ipv4's last graph In-Reply-To: <876F9BFF-4807-49A5-9D76-9FC067CCC645@apnic.net> References: <876F9BFF-4807-49A5-9D76-9FC067CCC645@apnic.net> Message-ID: <94F16748-9FBA-4CFE-A398-EAE210E6FBB0@cisco.com> On Feb 1, 2011, at 9:11 PM, Geoff Huston wrote: > > On 01/02/2011, at 7:02 PM, Randy Bush wrote: > >> with the iana free pool run-out, i guess we won't be getting those nice >> graphs any more. might we have one last one for the turnstiles? :-)/2 >> >> and would you mind doing the curves now for each of the five rirs? >> gotta give us all something to repeat endlessly on lists and in presos. > > but of course. > > http://www.potaroo.net/tools/ipv4/rir.jpg I can almost hear the cutting and pasting going on across the globe with this. - Mark > > This is a different graph - it is a probabilistic graph that shows the predicted month when the RIR will be down to its last /8 policy (whatever that policy may be), and the relative probability that the event will occur in that particular month. > > The assumption behind this graph is that the barricades will go up across the regions and each region will work from its local address pools and service only its local client base, and that as each region gets to its last /8 policy the applicants will not transfer their demand to those regions where addresses are still available. Its not possible to quantify how (in)accurate this assumption may be, so beyond the prediction of the first exhaustion point (which is at this stage looking more likely to occur in July 2011 than not) the predictions for the other RIRs are highly uncertain. > > Geoff > > From owen at delong.com Tue Feb 1 15:28:44 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 1 Feb 2011 13:28:44 -0800 Subject: Last of ipv4 /8's allocated In-Reply-To: <201102011349.02921.nanog@rhemasound.org> References: <8B6687A8-F4DB-4E98-BCFE-772B48EFCC06@gmail.com> <201102011349.02921.nanog@rhemasound.org> Message-ID: <51DD0000-7F12-45A5-91B5-711012C8D956@delong.com> On Feb 1, 2011, at 10:49 AM, Brian Christopher Raaen wrote: > On Tuesday, February 01, 2011 01:41:21 pm Rodrick Brown wrote: >> http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml >> >> Sent from my iPhone 4. > > Not quite, I still show 102/8, 103/8, 104/8, 179/8, and 185/8 as > "UNALLOCATED". I don't know when the hand out the last 5 /8's policy takes > affect, but they haven't handed them out yet. > > --- > Brian Raaen > Network Architech Ceremony is scheduled for 9:30 AM Thursday Local Time in Miami, FL. Owen From marka at isc.org Tue Feb 1 15:35:15 2011 From: marka at isc.org (Mark Andrews) Date: Wed, 02 Feb 2011 08:35:15 +1100 Subject: quietly.... In-Reply-To: Your message of "Tue, 01 Feb 2011 15:44:40 CDT." <4D4870B8.4010809@otd.com> References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com.> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> <03B2CC80-BFD3-4EFB-A008-8C8349F01F75@americafree.tv> <4D4824EF.2060801@brightok.net> <4D48670E.2040505@otd.com> <4D4870B8.4010809@otd.com> Message-ID: <20110201213515.72CB1966BF6@drugs.dv.isc.org> In message <4D4870B8.4010809 at otd.com>, Dave Israel writes: > On 2/1/2011 3:32 PM, Iljitsch van Beijnum wrote: > > On 1 feb 2011, at 21:03, Dave Israel wrote: > > > >> People want to engineer their networks they way they want to. Let them. If > their way is stupid, then they'll have the stupidly engineered network they wa > nted. > > The problem is that their stupidity impacts ME. If I want to talk to Microsof > t from behind a< 1500 byte MTU link: too bad, not going to happen. They stupid > ly send packets with DF=1 but filter incoming packet too big messages. > > > > So I'm all in favor of the IETF blocking stupidity whenever possible. > > > > I completely agree that, when interoperating, you have to follow the > rules, and I would (naively) hope that "customers cannot reach me > because of my configuration choice" is sufficient incentive to fix the > problem for the majority of network operators. But what I am arguing > against was the stance some people take against DHCPv6, or prefix > lengths longer than /64, or other internal-to-my-network, > why-should-you-care choices I might make. Telling me it is dumb is > fine; implementing software/hardware/protocols such that I can't do it > simply because you think it is dumb is a problem. > > -Dave It just doesn't work with Microsoft, ATT, AOL, .... They make up their own rules and you have to figure them out. Microsoft set TC on DNS replies but doesn't have DNS open on TCP. Then there is the anti-spam measures which break RFC compliance. Or all the people that have GLB's that don't give correct answers to AAAA queries. How had is it to return the SOA record of the delegated zone rather than the parent zone. Some GLB vendors documentation gets this wrong. The Alexa top 1000000 has a 1.4% failure rate on AAAA queries (SERVFAIL, TIMEOUT to the client when NOERROR or NXDOMAIN is returned for A). Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From m.hallgren at free.fr Tue Feb 1 15:36:37 2011 From: m.hallgren at free.fr (Michael Hallgren) Date: Tue, 01 Feb 2011 22:36:37 +0100 Subject: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database) In-Reply-To: <35655C23-B950-4F5B-A63A-0CCAB7442859@delong.com> References: <35655C23-B950-4F5B-A63A-0CCAB7442859@delong.com> Message-ID: <1296596197.16035.9.camel@home> Le mardi 01 f?vrier 2011 ? 13:20 -0800, Owen DeLong a ?crit : > On Feb 1, 2011, at 9:14 AM, Christopher Morrow wrote: > > > On Sun, Jan 30, 2011 at 2:55 PM, Martin Millnert wrote: > >> Here be dragons, > > > >> It should be fairly obvious, by most recently what's going on in > >> Egypt, why allowing a government to control the Internet is a Really > >> Bad Idea. > >> > > > > how is the egypt thing related to rPKI? > > How is the propsed rPKI work related to gov't control? > > > RPKI is a big knob governments might be tempted to turn. > > >> architecturally/technologically *impossible* for a entity from country > >> A to via-the-hierarchical-trust-model block a prefix assigned to some > >> entity in country B, that is assigned by B's RIR and in full > >> accordance with the RIR policies and in no breach of any contract. > > > > countries do not have RIR's, countries have NIR's... regions have RIR's. > > RIRs live in countries with governments. > RIRs are unlikely to mount a successful challenge against an organization > with tanks and mortars. Yes, right. But RIR is (at least supposed to be) regional, so (hopefully) more stable from a policy point of view (since the number of national "stake holders" need to agree on a common policy). In theory, at least... mh > > Owen > > From owen at delong.com Tue Feb 1 15:34:34 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 1 Feb 2011 13:34:34 -0800 Subject: quietly.... In-Reply-To: References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com.> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> <03B2CC80-BFD3-4EFB-A008-8C8349F01F75@americafree.tv> <4D4824EF.2060801@brightok.net> Message-ID: <93FDC643-D434-4D3B-9E01-3FE5FB1080F9@delong.com> On Feb 1, 2011, at 12:08 PM, david raistrick wrote: > On Tue, 1 Feb 2011, Iljitsch van Beijnum wrote: > >> What's the point of switching to IPv6 if it repeats all the IPv4 mistakes only with bigger addresses? >> >> If you like NAT IPv4 is the place to be, it'll only get more and more. > > It's argument like this that has lead to this moment. Instead of discussing "how can the next generation addressing scheme support the needs of Internet consumers today and tomorrow" we tell people "if you don't like it, use v4" > > > Guess what? We're still using v4. > > ..david Enjoy that. Let's see how that goes in 5-7 years. If you're determined to destroy IPv6 by bringing the problems of NAT forward with you, then, I'm fine with you remaining in your IPv4 island. I'm willing to bet that most organizations will embrace an internet unencumbered by the brokenness that is NAT and move forward. I do not think that lack of NAT has been a significant barrier to IPv6 adoption, nor do I think it will be. Owen From arturo.servin at gmail.com Tue Feb 1 15:43:43 2011 From: arturo.servin at gmail.com (Arturo Servin) Date: Tue, 1 Feb 2011 16:43:43 -0500 Subject: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database) In-Reply-To: References: Message-ID: <26844B7B-7B84-4066-9651-D4375055986F@gmail.com> Is it really a better alternative? Do we want to pay the cost of a fully distributed RPKI architecture? Or do we just abandon the idea of protecting the routing infrastructure? There is no free-lunch, we just need to select the price that we want to pay. -as On 1 Feb 2011, at 16:29, Benson Schliesser wrote: > > On Feb 1, 2011, at 11:14 AM, Christopher Morrow wrote: > >> On Sun, Jan 30, 2011 at 2:55 PM, Martin Millnert wrote: >>> Here be dragons, >> >>> It should be fairly obvious, by most recently what's going on in >>> Egypt, why allowing a government to control the Internet is a Really >>> Bad Idea. >>> >> >> how is the egypt thing related to rPKI? >> How is the propsed rPKI work related to gov't control? > > In theory at least, entities closer to the RPKI root (RIRs, IANA) could invalidate routes for any sort of policy reasons. This might provide leverage to certain governments, perhaps even offering the ability to control routing beyond their jurisdiction. > > As an example, it's imaginable that the US government could require IANA or ARIN to delegate authority to the NSA for a Canadian ISP's routes. Feel free to replace the RIR/LIR and country names, to suit your own example. > > Cheers, > -Benson > > From owen at delong.com Tue Feb 1 15:38:44 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 1 Feb 2011 13:38:44 -0800 Subject: quietly.... In-Reply-To: References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> Message-ID: <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> On Feb 1, 2011, at 12:36 PM, david raistrick wrote: > On Tue, 1 Feb 2011, Dave Israel wrote: > >> responsibility. If they want to use DHCPv6, or NAT, or Packet over Avian Carrier to achieve that, let them. If using them causes them problems, then they should not use them. It really isn't the community's place to force people not to use tools they find useful because we do not like them. > > Not to mention that when you take tools -away- from people that solve an existing problem, you'll get a lot of pushback. > NAT solves exactly one problem. It provides a way to reduce address consumption to work around a shortage of addresses. It does not solve any other problem(s). As such, taking it away when giving you a large enough address space that there is no longer a shortage doesn't strike me as taking away a tool that solves a problem. It strikes me as giving you a vastly superior tool that solves rather than working around a problem. Owen From owen at delong.com Tue Feb 1 15:48:18 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 1 Feb 2011 13:48:18 -0800 Subject: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database) In-Reply-To: <1296596197.16035.9.camel@home> References: <35655C23-B950-4F5B-A63A-0CCAB7442859@delong.com> <1296596197.16035.9.camel@home> Message-ID: <81B5906E-520D-4A7C-AF19-114DE3F979B4@delong.com> On Feb 1, 2011, at 1:36 PM, Michael Hallgren wrote: > Le mardi 01 f?vrier 2011 ? 13:20 -0800, Owen DeLong a ?crit : >> On Feb 1, 2011, at 9:14 AM, Christopher Morrow wrote: >> >>> On Sun, Jan 30, 2011 at 2:55 PM, Martin Millnert wrote: >>>> Here be dragons, >>> >>>> It should be fairly obvious, by most recently what's going on in >>>> Egypt, why allowing a government to control the Internet is a Really >>>> Bad Idea. >>>> >>> >>> how is the egypt thing related to rPKI? >>> How is the propsed rPKI work related to gov't control? >>> >> RPKI is a big knob governments might be tempted to turn. >> >>>> architecturally/technologically *impossible* for a entity from country >>>> A to via-the-hierarchical-trust-model block a prefix assigned to some >>>> entity in country B, that is assigned by B's RIR and in full >>>> accordance with the RIR policies and in no breach of any contract. >>> >>> countries do not have RIR's, countries have NIR's... regions have RIR's. >> >> RIRs live in countries with governments. >> RIRs are unlikely to mount a successful challenge against an organization >> with tanks and mortars. > > Yes, right. But RIR is (at least supposed to be) regional, so > (hopefully) more stable from a policy point of view (since the number of > national "stake holders" need to agree on a common policy). In theory, > at least... > There is not a single RIR that is not physically located in a country. You can hope they are more stable from a policy point of view, but, the reality is that if someone shows up at the front door with tanks and mortars, my money is not on the RIR. Owen From millnert at gmail.com Tue Feb 1 15:54:34 2011 From: millnert at gmail.com (Martin Millnert) Date: Tue, 1 Feb 2011 16:54:34 -0500 Subject: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database) In-Reply-To: <1296596197.16035.9.camel@home> References: <35655C23-B950-4F5B-A63A-0CCAB7442859@delong.com> <1296596197.16035.9.camel@home> Message-ID: On Tue, Feb 1, 2011 at 4:36 PM, Michael Hallgren wrote: > But RIR is (at least supposed to be) regional, so > (hopefully) more stable from a policy point of view (since the number of > national "stake holders" need to agree on a common policy). In theory, > at least... For Europe and RIPE, the EU commission at your service... Regards, Martin From alexb at ripe.net Tue Feb 1 15:57:45 2011 From: alexb at ripe.net (Alex Band) Date: Tue, 1 Feb 2011 22:57:45 +0100 Subject: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database) In-Reply-To: <35655C23-B950-4F5B-A63A-0CCAB7442859@delong.com> References: <35655C23-B950-4F5B-A63A-0CCAB7442859@delong.com> Message-ID: <62092E89-6460-4240-B6F8-FDF9D161A018@ripe.net> On 1 Feb 2011, at 22:20, Owen DeLong wrote: > > On Feb 1, 2011, at 9:14 AM, Christopher Morrow wrote: > >> On Sun, Jan 30, 2011 at 2:55 PM, Martin Millnert wrote: >>> Here be dragons, >> >>> It should be fairly obvious, by most recently what's going on in >>> Egypt, why allowing a government to control the Internet is a Really >>> Bad Idea. >>> >> >> how is the egypt thing related to rPKI? >> How is the propsed rPKI work related to gov't control? >> > RPKI is a big knob governments might be tempted to turn. Of course we looked into this, cause we're running our service from Amsterdam, the Netherlands. The possibilities for law enforcement agencies to take measures against the Resource Certification service run by the RIPE NCC are extremely limited. Under Dutch law, the process of certification, as well as resource certificates themselves, do not qualify as goods that are capable of being confiscated. Then of course, the decision making process always lies in the hands of the network operator. Only if a government would mandate an ISP to respect an invalid ROA and drop the route, it would be effective. So *both* these things would have to happen before there is an operational issue. Like you've seen in Egypt, pulling the plug is easier... YMMV on your side of the pond. Alex Band Product Manager, RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1728 bytes Desc: not available URL: From mpetach at netflight.com Tue Feb 1 16:00:08 2011 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 1 Feb 2011 14:00:08 -0800 Subject: Last of ipv4 /8's allocated In-Reply-To: <51DD0000-7F12-45A5-91B5-711012C8D956@delong.com> References: <8B6687A8-F4DB-4E98-BCFE-772B48EFCC06@gmail.com> <201102011349.02921.nanog@rhemasound.org> <51DD0000-7F12-45A5-91B5-711012C8D956@delong.com> Message-ID: On Tue, Feb 1, 2011 at 1:28 PM, Owen DeLong wrote: > > On Feb 1, 2011, at 10:49 AM, Brian Christopher Raaen wrote: > >> On Tuesday, February 01, 2011 01:41:21 pm Rodrick Brown wrote: >>> http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml >>> >>> Sent from my iPhone 4. >> >> Not quite, I still show 102/8, 103/8, 104/8, 179/8, and 185/8 as >> "UNALLOCATED". ?I don't know when the hand out the last 5 /8's policy takes >> affect, but they haven't handed them out yet. >> >> --- >> Brian Raaen >> Network Architech > > Ceremony is scheduled for 9:30 AM Thursday Local Time in Miami, FL. > > Owen I can't wait to see who gets 179/8; I would *so* love to be able to use 179.179.179.179 as a BGP route collection box. ^_^ Perhaps whomever gets it could donate the box to team Cymru? :D Matt From m.hallgren at free.fr Tue Feb 1 16:03:28 2011 From: m.hallgren at free.fr (Michael Hallgren) Date: Tue, 01 Feb 2011 23:03:28 +0100 Subject: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database) In-Reply-To: References: <35655C23-B950-4F5B-A63A-0CCAB7442859@delong.com> <1296596197.16035.9.camel@home> Message-ID: <1296597808.16035.14.camel@home> Le mardi 01 f?vrier 2011 ? 16:54 -0500, Martin Millnert a ?crit : > On Tue, Feb 1, 2011 at 4:36 PM, Michael Hallgren wrote: > > But RIR is (at least supposed to be) regional, so > > (hopefully) more stable from a policy point of view (since the number of > > national "stake holders" need to agree on a common policy). In theory, > > at least... > > For Europe and RIPE, the EU commission at your service... Yeah, good point... ... as was Owen's... :) So, what's next hop forward? mh > > Regards, > Martin From paul at paulgraydon.co.uk Tue Feb 1 16:04:54 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Tue, 01 Feb 2011 12:04:54 -1000 Subject: quietly.... In-Reply-To: <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> Message-ID: <4D488386.50101@paulgraydon.co.uk> On 02/01/2011 11:38 AM, Owen DeLong wrote: > On Feb 1, 2011, at 12:36 PM, david raistrick wrote: > >> On Tue, 1 Feb 2011, Dave Israel wrote: >> >>> responsibility. If they want to use DHCPv6, or NAT, or Packet over Avian Carrier to achieve that, let them. If using them causes them problems, then they should not use them. It really isn't the community's place to force people not to use tools they find useful because we do not like them. >> Not to mention that when you take tools -away- from people that solve an existing problem, you'll get a lot of pushback. >> > NAT solves exactly one problem. It provides a way to reduce address consumption to work around a shortage of addresses. > > It does not solve any other problem(s). > > As such, taking it away when giving you a large enough address space that there is no longer a shortage doesn't > strike me as taking away a tool that solves a problem. It strikes me as giving you a vastly superior tool that solves > rather than working around a problem. > Don't forget the security benefits!!!1111oneone *runs* From randy at psg.com Tue Feb 1 16:04:58 2011 From: randy at psg.com (Randy Bush) Date: Wed, 02 Feb 2011 07:04:58 +0900 Subject: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database) In-Reply-To: <1296595999.16035.6.camel@home> References: <1296595999.16035.6.camel@home> Message-ID: > In this context, at least, perhaps the NIR should be considered > superfluous or redundant? What is the operational rationale behind the > NIR level? Wouldn't a flatter RIR-LIR structure do just fine? and then, by inference, what is the use of the RIR level? randy From bensons at queuefull.net Tue Feb 1 16:05:42 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Tue, 1 Feb 2011 16:05:42 -0600 Subject: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database) In-Reply-To: <26844B7B-7B84-4066-9651-D4375055986F@gmail.com> References: <26844B7B-7B84-4066-9651-D4375055986F@gmail.com> Message-ID: <444B2A97-5503-4DA3-A92B-CDB8C01693BA@queuefull.net> On Feb 1, 2011, at 3:43 PM, Arturo Servin wrote: > Is it really a better alternative? Do we want to pay the cost of a fully distributed RPKI architecture? > > Or do we just abandon the idea of protecting the routing infrastructure? > > There is no free-lunch, we just need to select the price that we want to pay. > I agree there is no free-lunch. Randy Bush addressed the problem, in a recent email, by contrasting his "security" personality against his mistrust of authority. (That's my summary, not his words.) And I think that's exactly what I'm struggling with. I want to secure the routing infrastructure, but I don't completely trust centralized regimes. At their best, they're a target for exploitation - at their worst, they're authoritarian. Randy was kind enough to point me toward http://tools.ietf.org/html/draft-ietf-sidr-ltamgmt-00 which I'm in the process of reading. Perhaps there is a way to balance between "fully distributed" and "centralized", e.g. by supporting multiple roots and different trust domains. Cheers, -Benson > On 1 Feb 2011, at 16:29, Benson Schliesser wrote: > >> >> On Feb 1, 2011, at 11:14 AM, Christopher Morrow wrote: >> >>> On Sun, Jan 30, 2011 at 2:55 PM, Martin Millnert wrote: >>>> Here be dragons, >>> >>>> It should be fairly obvious, by most recently what's going on in >>>> Egypt, why allowing a government to control the Internet is a Really >>>> Bad Idea. >>>> >>> >>> how is the egypt thing related to rPKI? >>> How is the propsed rPKI work related to gov't control? >> >> In theory at least, entities closer to the RPKI root (RIRs, IANA) could invalidate routes for any sort of policy reasons. This might provide leverage to certain governments, perhaps even offering the ability to control routing beyond their jurisdiction. >> >> As an example, it's imaginable that the US government could require IANA or ARIN to delegate authority to the NSA for a Canadian ISP's routes. Feel free to replace the RIR/LIR and country names, to suit your own example. >> >> Cheers, >> -Benson >> >> > > From drais at icantclick.org Tue Feb 1 16:03:51 2011 From: drais at icantclick.org (david raistrick) Date: Tue, 1 Feb 2011 17:03:51 -0500 (EST) Subject: quietly.... In-Reply-To: <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> Message-ID: On Tue, 1 Feb 2011, Owen DeLong wrote: > NAT solves exactly one problem. It provides a way to reduce address > consumption to work around a shortage of addresses. > > It does not solve any other problem(s). Sure it does. It obfuscates internal addressing. This wasn't the original goal, but it's a "feature" that some groups of users have come to require. -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From bensons at queuefull.net Tue Feb 1 16:09:17 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Tue, 1 Feb 2011 16:09:17 -0600 Subject: quietly.... In-Reply-To: <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> Message-ID: <6DF2D154-7AD0-4C9B-BE62-197711E21E80@queuefull.net> On Feb 1, 2011, at 3:38 PM, Owen DeLong wrote: > NAT solves exactly one problem. It provides a way to reduce address consumption to work around a shortage of addresses. > > It does not solve any other problem(s). In all fairness, that's not really true. It just doesn't solve other problems in an optimal way. Also, NAT44 implies address oversubscription while NAT66 doesn't necessarily have such a requirement. Not that I love NAT66, but let's at least be honest about it. Cheers, -Benson From carlosm3011 at gmail.com Tue Feb 1 16:15:19 2011 From: carlosm3011 at gmail.com (Carlos M. Martinez) Date: Tue, 1 Feb 2011 20:15:19 -0200 Subject: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database) In-Reply-To: <1296595999.16035.6.camel@home> References: <1296595999.16035.6.camel@home> Message-ID: <86E7306B-CA23-4500-B97F-2071EBA294D2@gmail.com> Although I support Rpki as a technology, there are legitimate concerns that it could be abused. I now believe that Rpki needs work in this area at IETF level so the concerns are adressed. I imagine some form of secret sharing among different parties or sme form of key escrow. I am sure that it is not an easy problem, but maybe some progress can be made in this direction. Regards Carlos On Feb 1, 2011, at 7:33 PM, Michael Hallgren wrote: > Le mardi 01 f?vrier 2011 ? 12:14 -0500, Christopher Morrow a ?crit : >> On Sun, Jan 30, 2011 at 2:55 PM, Martin Millnert wrote: >>> Here be dragons, >> >>> It should be fairly obvious, by most recently what's going on in >>> Egypt, why allowing a government to control the Internet is a Really >>> Bad Idea. >>> >> >> how is the egypt thing related to rPKI? >> How is the propsed rPKI work related to gov't control? >> >>> architecturally/technologically *impossible* for a entity from country >>> A to via-the-hierarchical-trust-model block a prefix assigned to some >>> entity in country B, that is assigned by B's RIR and in full >>> accordance with the RIR policies and in no breach of any contract. >> >> countries do not have RIR's, countries have NIR's... regions have RIR's. > > In this context, at least, perhaps the NIR should be considered > superfluous or redundant? What is the operational rationale behind the > NIR level? Wouldn't a flatter RIR-LIR structure do just fine? > > mh > >> > > From iljitsch at muada.com Tue Feb 1 16:25:13 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 1 Feb 2011 23:25:13 +0100 Subject: quietly.... In-Reply-To: References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> Message-ID: <9B61E17B-EFAA-4B70-8FA5-99946DBDBB3A@muada.com> On 1 feb 2011, at 23:03, david raistrick wrote: > It obfuscates internal addressing. > This wasn't the original goal, but it's a "feature" that some groups of users have come to require. Creating a new random address every 24 hours (or more often if needed, I assume) goes a long way towards that, too. There's still proxies with IPv6, those also make everything nice and obscure, also hide your TCP seqnums and IP IDs etc. From rcarpen at network1.net Tue Feb 1 16:33:16 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Tue, 1 Feb 2011 17:33:16 -0500 (EST) Subject: Last of ipv4 /8's allocated In-Reply-To: Message-ID: <238182428.1509.1296599596109.JavaMail.root@zimbra.network1.net> My guesses as to who gets what: 102/8 - APNIC 103/8 - LACNIC 104/8 - AfriNIC 179/8 - RIPE NCC 185/8 - ARIN That's how I would do it. With the exception of LACNIC, each one neighbors a block that is already allocated to that RIR. And in the case of AfriNIC, RIPC, and ARIN, they would make an aggregatable /7. Not that that really means anything, but is nice for organization ;-) -Randy -- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1 ---- ----- Original Message ----- > On Tue, Feb 1, 2011 at 1:28 PM, Owen DeLong wrote: > > > > On Feb 1, 2011, at 10:49 AM, Brian Christopher Raaen wrote: > > > >> On Tuesday, February 01, 2011 01:41:21 pm Rodrick Brown wrote: > >>> http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml > >>> > >>> Sent from my iPhone 4. > >> > >> Not quite, I still show 102/8, 103/8, 104/8, 179/8, and 185/8 as > >> "UNALLOCATED". I don't know when the hand out the last 5 /8's > >> policy takes > >> affect, but they haven't handed them out yet. > >> > >> --- > >> Brian Raaen > >> Network Architech > > > > Ceremony is scheduled for 9:30 AM Thursday Local Time in Miami, FL. > > > > Owen > > I can't wait to see who gets 179/8; I would *so* love to be able to > use > 179.179.179.179 as a BGP route collection box. ^_^ > > Perhaps whomever gets it could donate the box to team Cymru? :D > > Matt From rubensk at gmail.com Tue Feb 1 16:40:29 2011 From: rubensk at gmail.com (Rubens Kuhl) Date: Tue, 1 Feb 2011 20:40:29 -0200 Subject: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database) In-Reply-To: <81B5906E-520D-4A7C-AF19-114DE3F979B4@delong.com> References: <35655C23-B950-4F5B-A63A-0CCAB7442859@delong.com> <1296596197.16035.9.camel@home> <81B5906E-520D-4A7C-AF19-114DE3F979B4@delong.com> Message-ID: > There is not a single RIR that is not physically located in a country. > You can hope they are more stable from a policy point of view, but, the > reality is that if someone shows up at the front door with tanks and > mortars, my money is not on the RIR. But they might choose a country in that region that is less likely to mess with the RIR. For instance, ARIN would probably be a lot safer in Canada than in the US... RIPE could relocate to Swiss or Sweden (although I think Holland is not that much of a risk), for instance. LACNIC in Uruguay seems a good choice to me, the same with AfriNIC in Mauritius. Rubens From thegameiam at yahoo.com Tue Feb 1 16:43:35 2011 From: thegameiam at yahoo.com (David Barak) Date: Tue, 1 Feb 2011 14:43:35 -0800 (PST) Subject: quietly.... In-Reply-To: <93FDC643-D434-4D3B-9E01-3FE5FB1080F9@delong.com> References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com.> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> <03B2CC80-BFD3-4EFB-A008-8C8349F01F75@americafree.tv> <4D4824EF.2060801@brightok.net> <93FDC643-D434-4D3B-9E01-3FE5FB1080F9@delong.com> Message-ID: <318049.99548.qm@web31804.mail.mud.yahoo.com> ________________________________ From: Owen DeLong David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com >If you're determined to destroy IPv6 by bringing the problems of NAT forward >with you, then, I'm fine with you remaining in your >IPv4 island. I'm willing to >bet that most organizations will embrace an internet unencumbered by the >brokenness that is NAT and >move forward. I do not think that lack of NAT has >been a significant barrier to IPv6 adoption, nor do I think it will be. Lack of NAT may or may not continue to be a barrier to IPv6 adoption.? However, it certainly *has* been a barrier to IPv6 adoption - I have had customers tell me that explicitly, and I have no reason to doubt them. From iljitsch at muada.com Tue Feb 1 16:44:16 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 1 Feb 2011 23:44:16 +0100 Subject: Last of ipv4 /8's allocated In-Reply-To: <238182428.1509.1296599596109.JavaMail.root@zimbra.network1.net> References: <238182428.1509.1296599596109.JavaMail.root@zimbra.network1.net> Message-ID: <230156B7-B9F7-4A24-A3A6-E981110F68AC@muada.com> On 1 feb 2011, at 23:33, Randy Carpenter wrote: > That's how I would do it. With the exception of LACNIC, each one neighbors a block that is already allocated to that RIR. But if they wanted to do that, why give 106/8 to APNIC? My suspicion is that IANA is playing a game of battleship with the RIRs and thursday we'll see who's won. Colored in for your convenience: http://www.bgpexpert.com/ianaglobalpool.php From owen at delong.com Tue Feb 1 16:46:54 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 1 Feb 2011 14:46:54 -0800 Subject: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database) In-Reply-To: References: <35655C23-B950-4F5B-A63A-0CCAB7442859@delong.com> <1296596197.16035.9.camel@home> <81B5906E-520D-4A7C-AF19-114DE3F979B4@delong.com> Message-ID: On Feb 1, 2011, at 2:40 PM, Rubens Kuhl wrote: >> There is not a single RIR that is not physically located in a country. > > >> You can hope they are more stable from a policy point of view, but, the >> reality is that if someone shows up at the front door with tanks and >> mortars, my money is not on the RIR. > > But they might choose a country in that region that is less likely to > mess with the RIR. For instance, ARIN would probably be a lot safer in > Canada than in the US... RIPE could relocate to Swiss or Sweden > (although I think Holland is not that much of a risk), for instance. > LACNIC in Uruguay seems a good choice to me, the same with AfriNIC in > Mauritius. > > > > Rubens Great theory, but: ARIN (and IANA for that matter) are _IN_ the US. RIPE _IS_ in the Netherlands. APNIC _IS_ in Australia. Where would you put it? I notice you didn't list it above. Even Canada has their occasional bouts of wanting to censor the internet in strange ways. Government policies change over time and counting on governments to remain sane has its perils. Owen From owen at delong.com Tue Feb 1 16:51:21 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 1 Feb 2011 14:51:21 -0800 Subject: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database) In-Reply-To: <62092E89-6460-4240-B6F8-FDF9D161A018@ripe.net> References: <35655C23-B950-4F5B-A63A-0CCAB7442859@delong.com> <62092E89-6460-4240-B6F8-FDF9D161A018@ripe.net> Message-ID: <4FFCC086-EA14-4864-9594-911B6BEF2B86@delong.com> On Feb 1, 2011, at 1:57 PM, Alex Band wrote: > > On 1 Feb 2011, at 22:20, Owen DeLong wrote: > >> >> On Feb 1, 2011, at 9:14 AM, Christopher Morrow wrote: >> >>> On Sun, Jan 30, 2011 at 2:55 PM, Martin Millnert wrote: >>>> Here be dragons, >>> >>>> It should be fairly obvious, by most recently what's going on in >>>> Egypt, why allowing a government to control the Internet is a Really >>>> Bad Idea. >>>> >>> >>> how is the egypt thing related to rPKI? >>> How is the propsed rPKI work related to gov't control? >>> >> RPKI is a big knob governments might be tempted to turn. > > Of course we looked into this, cause we're running our service from Amsterdam, the Netherlands. The possibilities for law enforcement agencies to take measures against the Resource Certification service run by the RIPE NCC are extremely limited. Under Dutch law, the process of certification, as well as resource certificates themselves, do not qualify as goods that are capable of being confiscated. > Confiscated isn't the only possible issue. Being ordered to revoke a ROA or sign an alternate ROA isn't necessarily confiscation. It's court-ordered behavior. I'm not familiar enough with Dutch law to know if this is possible or not, but, regardless of the law today, the certificate issue remains after the law is changed. No country has immutable laws. Even the US Constitution can be (and has been) changed. > Then of course, the decision making process always lies in the hands of the network operator. Only if a government would mandate an ISP to respect an invalid ROA and drop the route, it would be effective. > If the RIR is signing the "invalid" ROA, how does one distinguish the invalid from the valid? > So *both* these things would have to happen before there is an operational issue. Like you've seen in Egypt, pulling the plug is easier... > Today, pulling the plug is easier. In an automated RPKI environment where a revocation or alternate signed record can cause service impacts, > YMMV on your side of the pond. > > Alex Band > Product Manager, RIPE NCC With the mere passage of a law, so could the mileage on your side of the pond. Owen From john at sackheads.org Tue Feb 1 16:56:59 2011 From: john at sackheads.org (John Payne) Date: Tue, 1 Feb 2011 17:56:59 -0500 Subject: quietly.... In-Reply-To: <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> Message-ID: On Feb 1, 2011, at 4:38 PM, Owen DeLong wrote: > NAT solves exactly one problem. It provides a way to reduce address consumption to work around a shortage of addresses. > > It does not solve any other problem(s). That's a bold statement. Especially as you said NAT and not PAT. From jbates at brightok.net Tue Feb 1 16:58:00 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 01 Feb 2011 16:58:00 -0600 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <5D2659F3-5853-4C1C-A26D-D6EB5AA75195@delong.com> <4D4820E1.20600@brightok.net> <077208EB-39DF-4F51-B263-E1BEB0BCE75A@delong.com> <4D48454A.1090807@brightok.net> Message-ID: <4D488FF8.4010106@brightok.net> On 2/1/2011 3:23 PM, Owen DeLong wrote: > Given the vast probability for abuse of ULA becoming de facto GUA later, I don't support ULA existing as the benefits are vastly overwhelmed by the potential for abouse. If the world wants ULA to become the de facto GUA, no amount of arm twisting and bulling will stop it. There are many cases where ULA is a perfect fit, and to work around it seems silly and reduces the full capabilities of IPv6. I fully expect to see protocols and networks within homes which will take full advantage of ULA. I also expect to see hosts which don't talk to the public internet directly and never need a GUA. Jack From morrowc.lists at gmail.com Tue Feb 1 17:01:59 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 1 Feb 2011 18:01:59 -0500 Subject: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database) In-Reply-To: <1296595999.16035.6.camel@home> References: <1296595999.16035.6.camel@home> Message-ID: On Tue, Feb 1, 2011 at 4:33 PM, Michael Hallgren wrote: > Le mardi 01 f?vrier 2011 ? 12:14 -0500, Christopher Morrow a ?crit : >> countries do not have RIR's, countries have NIR's... regions have RIR's. > > In this context, at least, perhaps the NIR should be considered > superfluous or redundant? What is the operational rationale behind the > NIR level? Wouldn't a flatter RIR-LIR structure do just fine? some parts of the world are invested in the NIR ocncept... not my part, but I do admit other folks like it. (and I didn't want to leave someone out of the mix) From jbates at brightok.net Tue Feb 1 17:02:51 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 01 Feb 2011 17:02:51 -0600 Subject: quietly.... In-Reply-To: <20110201203251.GF65077@puck.nether.net> References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com.> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> <03B2CC80-BFD3-4EFB-A008-8C8349F01F75@americafree.tv> <4D4824EF.2060801@brightok.net> <4D486CC1.1020602@paulgraydon.co.uk> <20110201203251.GF65077@puck.nether.net> Message-ID: <4D48911B.10105@brightok.net> On 2/1/2011 2:32 PM, Majdi S. Abbas wrote: > It's not as if we haven't had 15 years to get it together... And failed to do so properly. jack From dongting.yu at cl.cam.ac.uk Tue Feb 1 17:13:35 2011 From: dongting.yu at cl.cam.ac.uk (Dongting Yu) Date: Tue, 1 Feb 2011 23:13:35 +0000 Subject: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database) In-Reply-To: References: <1296595999.16035.6.camel@home> Message-ID: Since we are already talking about RIRs, I am curious, who will sign the legacy blocks in RPKI? Dongting From jbates at brightok.net Tue Feb 1 17:13:49 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 01 Feb 2011 17:13:49 -0600 Subject: quietly.... In-Reply-To: <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> Message-ID: <4D4893AD.8040509@brightok.net> On 2/1/2011 3:38 PM, Owen DeLong wrote: > As such, taking it away when giving you a large enough address space that there is no longer a shortage doesn't > strike me as taking away a tool that solves a problem. It strikes me as giving you a vastly superior tool that solves > rather than working around a problem. > Interestingly enough, there is a draft for NAT66, specifically NPTv6, but no draft for NAPTv6. So someone though it was okay to start allowing some NAT66, but everyone's still trying to fight NAPTv6, as businesses might use it. Oh noes. The other concern was perhaps home routers, but let's be honest. There is a v6-cpe-router draft, and it easily could forbid the use of NAPTv6. It's already missing most of the stuff required to make home networks work in v6 the same way they do in v4 (prefix delegation added new problems that NAT didn't have, which they still haven't solved). Jack From owen at delong.com Tue Feb 1 17:11:57 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 1 Feb 2011 15:11:57 -0800 Subject: quietly.... In-Reply-To: <318049.99548.qm@web31804.mail.mud.yahoo.com> References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com.> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> <03B2CC80-BFD3-4EFB-A008-8C8349F01F75@americafree.tv> <4D4824EF.2060801@brightok.net> <93FDC643-D434-4D3B-9E01-3FE5FB1080F9@delong.com> <318049.99548.qm@web31804.mail.mud.yahoo.com> Message-ID: On Feb 1, 2011, at 2:43 PM, David Barak wrote: > > ________________________________ > > From: Owen DeLong > > > David Barak > Need Geek Rock? Try The Franchise: > http://www.listentothefranchise.com > >> If you're determined to destroy IPv6 by bringing the problems of NAT forward >> with you, then, I'm fine with you remaining in your >IPv4 island. I'm willing to >> bet that most organizations will embrace an internet unencumbered by the >> brokenness that is NAT and >move forward. I do not think that lack of NAT has >> been a significant barrier to IPv6 adoption, nor do I think it will be. > > Lack of NAT may or may not continue to be a barrier to IPv6 adoption. However, > it certainly *has* been a barrier to IPv6 adoption - I have had customers tell > me that explicitly, and I have no reason to doubt them. > > > I'm sure there are a few isolated places where IPv6 might have been adopted if it hadn't been for the fact that nobody has educated them on the alternatives. However, I'm not convinced there are very many of them. Most of the people I have had more detailed conversations with go something like this: X: We con't implement IPv6 because there's no NAT and we depend on NAT. O: Why do you depend on NAT? All it does is conserve addresses? X: We use it for address obfuscation and security. We have to meet PCI-DSS and other audit criteria. O: Well, the latest PCI-DSS doesn't require NAT. Additionally, you can get better address obfuscation with privacy addresses. All the security in NAT comes from stateful inspection. You can still do that in IPv6, you just don't rewrite the address in the packet. X: You've got an answer for everything, don't you? O: Well, I've been doing IPv6 for a few years now. It works pretty well for me and I'm really glad I don't have to deal with the problems caused by NAT. X: Well, OK, but, even if we ignore NAT, we're still not ready to do IPv6. Then we discuss their real issues stopping them from going to IPv6. So... I think there are a lot more people using NAT as an excuse than there are people that would actually implement IPv6 if we just gave them NAT. In any case, I think as they find their NATv4 environment becoming an island disconnected from the internet, they'll probably reconsider that decision. I'm OK with waiting until that time for those people to connect to IPv6. Owen From owen at delong.com Tue Feb 1 17:15:22 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 1 Feb 2011 15:15:22 -0800 Subject: quietly.... In-Reply-To: References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> Message-ID: <437F22E3-154B-4DD2-B37B-8BC54D116B40@delong.com> On Feb 1, 2011, at 2:56 PM, John Payne wrote: > > > On Feb 1, 2011, at 4:38 PM, Owen DeLong wrote: > >> NAT solves exactly one problem. It provides a way to reduce address consumption to work around a shortage of addresses. >> >> It does not solve any other problem(s). > > > That's a bold statement. Especially as you said NAT and not PAT. NAT, PAT, whatever... I'm willing to back it up. Owen From owen at delong.com Tue Feb 1 17:16:58 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 1 Feb 2011 15:16:58 -0800 Subject: quietly.... In-Reply-To: <6DF2D154-7AD0-4C9B-BE62-197711E21E80@queuefull.net> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <6DF2D154-7AD0-4C9B-BE62-197711E21E80@queuefull.net> Message-ID: <5D2524AA-58F1-439E-BC3C-F2B729CA233A@delong.com> On Feb 1, 2011, at 2:09 PM, Benson Schliesser wrote: > > On Feb 1, 2011, at 3:38 PM, Owen DeLong wrote: > >> NAT solves exactly one problem. It provides a way to reduce address consumption to work around a shortage of addresses. >> >> It does not solve any other problem(s). > > In all fairness, that's not really true. It just doesn't solve other problems in an optimal way. > > Also, NAT44 implies address oversubscription while NAT66 doesn't necessarily have such a requirement. > > Not that I love NAT66, but let's at least be honest about it. > > Cheers, > -Benson Perhaps a better way to put it is: There are better solutions in IPv6 to any of the problems NAT44 is alleged to solve, regardless of whether you are talking about overloaded NAT44 (which some people refer to as PAT) or any other form of NAT. Owen From owen at delong.com Tue Feb 1 17:14:57 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 1 Feb 2011 15:14:57 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <4D488FF8.4010106@brightok.net> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <5D2659F3-5853-4C1C-A26D-D6EB5AA75195@delong.com> <4D4820E1.20600@brightok.net> <077208EB-39DF-4F51-B263-E1BEB0BCE75A@delong.com> <4D48454A.1090807@brightok.net> <4D488FF8.4010106@brightok.net> Message-ID: <8998E21B-14FB-45A8-A849-D1416E946505@delong.com> On Feb 1, 2011, at 2:58 PM, Jack Bates wrote: > On 2/1/2011 3:23 PM, Owen DeLong wrote: >> Given the vast probability for abuse of ULA becoming de facto GUA later, I don't support ULA existing as the benefits are vastly overwhelmed by the potential for abouse. > If the world wants ULA to become the de facto GUA, no amount of arm twisting and bulling will stop it. > Right... It's a toxic chemical. No matter how much we may end up wishing we could, we probably can't uninvent it at this point. Regardless, I won't encourage and will actively discourage its use. > There are many cases where ULA is a perfect fit, and to work around it seems silly and reduces the full capabilities of IPv6. I fully expect to see protocols and networks within homes which will take full advantage of ULA. I also expect to see hosts which don't talk to the public internet directly and never need a GUA. > I guess we can agree to disagree about this. I haven't seen one yet. Owen From owen at delong.com Tue Feb 1 17:18:39 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 1 Feb 2011 15:18:39 -0800 Subject: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database) In-Reply-To: References: <1296595999.16035.6.camel@home> Message-ID: <5280B681-83C3-4F0C-8B5B-DCFF7956F3B8@delong.com> On Feb 1, 2011, at 3:01 PM, Christopher Morrow wrote: > On Tue, Feb 1, 2011 at 4:33 PM, Michael Hallgren wrote: >> Le mardi 01 f?vrier 2011 ? 12:14 -0500, Christopher Morrow a ?crit : > >>> countries do not have RIR's, countries have NIR's... regions have RIR's. >> >> In this context, at least, perhaps the NIR should be considered >> superfluous or redundant? What is the operational rationale behind the >> NIR level? Wouldn't a flatter RIR-LIR structure do just fine? > > some parts of the world are invested in the NIR ocncept... not my > part, but I do admit other folks like it. (and I didn't want to leave > someone out of the mix) I don't believe the NIRs would be part of the RPKI chain if I understand it correctly. Owen From bensons at queuefull.net Tue Feb 1 17:23:06 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Tue, 1 Feb 2011 17:23:06 -0600 Subject: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database) In-Reply-To: References: <1296595999.16035.6.camel@home> Message-ID: <2DAD089D-6AE8-44C8-95B3-ADFADF941873@queuefull.net> On Feb 1, 2011, at 5:13 PM, Dongting Yu wrote: > Since we are already talking about RIRs, I am curious, who will sign > the legacy blocks in RPKI? Since they pre-exist the RIR, it's not clear that any one RIR has authority until asked. (For a discussion of rights, authority, etc, see http://ciara.fiu.edu/publications/Rubi%20-%20Property%20Rights%20in%20IP%20Numbers.pdf) Thus, I think the legacy address holders will have to request "services" from an RIR. Or from a trusted third party. (For instance, see http://www.circleid.com/posts/competition_to_regional_internet_registries_rir_for_post_allocation_service/) Cheers, -Benson From owen at delong.com Tue Feb 1 17:21:33 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 1 Feb 2011 15:21:33 -0800 Subject: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database) In-Reply-To: References: <1296595999.16035.6.camel@home> Message-ID: On Feb 1, 2011, at 3:13 PM, Dongting Yu wrote: > Since we are already talking about RIRs, I am curious, who will sign > the legacy blocks in RPKI? > > Dongting I suspect that if you want RPKI, you'll need to sign an agreement with the RIR. In ARIN region, this would be the LRSA or the RSA. Owen From jbates at brightok.net Tue Feb 1 17:25:01 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 01 Feb 2011 17:25:01 -0600 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <8998E21B-14FB-45A8-A849-D1416E946505@delong.com> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <5D2659F3-5853-4C1C-A26D-D6EB5AA75195@delong.com> <4D4820E1.20600@brightok.net> <077208EB-39DF-4F51-B263-E1BEB0BCE75A@delong.com> <4D48454A.1090807@brightok.net> <4D488FF8.4010106@brightok.net> <8998E21B-14FB-45A8-A849-D1416E946505@delong.com> Message-ID: <4D48964D.3070109@brightok.net> On 2/1/2011 5:14 PM, Owen DeLong wrote: > I guess we can agree to disagree about this. I haven't seen one yet. If my coffee maker did have an IP address, I expect it to get all it's updates from a central house store, not directly from the manufacturer over the net. I see no reason my appliances need global access; just access to their local controller. And yes, I am working on building my IPv6 coffee maker. :P jack From brandon at rd.bbc.co.uk Tue Feb 1 17:36:48 2011 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Tue, 1 Feb 2011 23:36:48 GMT Subject: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database) Message-ID: <201102012336.XAA27613@sunf10.rd.bbc.co.uk> So a possible road to ruin I was thinking of when I mentioned my unease is, to state the obvious, - Some large ISPs do RPKI as it's secure and their government contract says they have to be secure, keep the terrists out, so all directly attached ISP have to do it too kicking off a domino Other large customers will see the government lead and choose the same to meet the corporate governance rules so smaller ISP they use start to fall in line. It'll escalate like the MD5 frenzy, goes global and at some point hits critical mass where some ISP decide the unsigned routes are a risk and they can afford to drop them, like some do with deaggregates now. You get to the state of either you sign or your upstream signs (like L3 IRR proxy entries just a bit harder) or you don't exist. Some other event, like with UK anti CP filters, will happen where it becomes a legal requirement to let someone fiddle and make a kill switch to be used in certain circumstances. Later it gets used in unintended circumstances Our trade of control for security has given us neither. Of course more likely the key renewal will get spam filtered and I'll not notice until we fall off the net, or we forget to pay the RIR invoice on time and get cut off, causing a long outage that I can't fix as quickly as rolling back a router config change. I also wonder about emergency use, post a katrina have we made something that's too hard to bootstrap quickly. Drive slow. brandon From cra at WPI.EDU Tue Feb 1 17:38:46 2011 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 1 Feb 2011 18:38:46 -0500 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <8998E21B-14FB-45A8-A849-D1416E946505@delong.com> References: <1296089078.6522.194.camel@karl> <5D2659F3-5853-4C1C-A26D-D6EB5AA75195@delong.com> <4D4820E1.20600@brightok.net> <077208EB-39DF-4F51-B263-E1BEB0BCE75A@delong.com> <4D48454A.1090807@brightok.net> <4D488FF8.4010106@brightok.net> <8998E21B-14FB-45A8-A849-D1416E946505@delong.com> Message-ID: <20110201233846.GV13890@angus.ind.WPI.EDU> On Tue, Feb 01, 2011 at 03:14:57PM -0800, Owen DeLong wrote: > On Feb 1, 2011, at 2:58 PM, Jack Bates wrote: > > There are many cases where ULA is a perfect fit, and to work > > around it seems silly and reduces the full capabilities of IPv6. I > > fully expect to see protocols and networks within homes which will > > take full advantage of ULA. I also expect to see hosts which don't > > talk to the public internet directly and never need a GUA. > > > I guess we can agree to disagree about this. I haven't seen one yet. What would your recommended solution be then for disconnected networks? Every home user and enterprise user requests GUA directly from their RIR/NIR/LIR at a cost of hunderds of dollars per year or more? From kauer at biplane.com.au Tue Feb 1 17:41:50 2011 From: kauer at biplane.com.au (Karl Auer) Date: Wed, 02 Feb 2011 10:41:50 +1100 Subject: quietly.... In-Reply-To: <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> Message-ID: <1296603710.12449.19.camel@karl> On Tue, 2011-02-01 at 13:38 -0800, Owen DeLong wrote: > NAT solves exactly one problem. It provides a way to reduce address > consumption to work around a shortage of addresses. Devil's advocate hat on: NAT (in its most common form) also permits internal addressing to be independent of external addressing. The side effects of that are not necessarily desirable (loss of end-to-end connectivity, performance issues, limitations on simultaneous connections etc etc). It seems to me that it is this property of NAT that people are most loath to lose. And why ULA looks tantalisingly delicious. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From rcarpen at network1.net Tue Feb 1 17:39:29 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Tue, 1 Feb 2011 18:39:29 -0500 (EST) Subject: Last of ipv4 /8's allocated In-Reply-To: <230156B7-B9F7-4A24-A3A6-E981110F68AC@muada.com> Message-ID: <1716829011.1561.1296603569640.JavaMail.root@zimbra.network1.net> ----- Original Message ----- > On 1 feb 2011, at 23:33, Randy Carpenter wrote: > > > That's how I would do it. With the exception of LACNIC, each one > > neighbors a block that is already allocated to that RIR. > > But if they wanted to do that, why give 106/8 to APNIC? I assume you mean 102/8, and because it is right next to 101/8, which they already have. Doesn't make a nice /7, but there are no other unallocated blocks that are next to any APNIC blocks. > My suspicion is that IANA is playing a game of battleship with the > RIRs and thursday we'll see who's won. Colored in for your > convenience: > > http://www.bgpexpert.com/ianaglobalpool.php Doesn't really matter who gets what, because no one is going to route anything larger than a /8 anyway, particularly the RIR allocations. Just kinda fun to think about :-) -Randy From m.hallgren at free.fr Tue Feb 1 17:47:42 2011 From: m.hallgren at free.fr (Michael Hallgren) Date: Wed, 02 Feb 2011 00:47:42 +0100 Subject: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database) In-Reply-To: References: <1296595999.16035.6.camel@home> Message-ID: <1296604062.16035.69.camel@home> Le mercredi 02 f?vrier 2011 ? 07:04 +0900, Randy Bush a ?crit : > > In this context, at least, perhaps the NIR should be considered > > superfluous or redundant? What is the operational rationale behind the > > NIR level? Wouldn't a flatter RIR-LIR structure do just fine? > > and then, by inference, what is the use of the RIR level? A meeting point for communities, potentially able to reflect a consensus view of policies and moderate "NIR" and other might be more unilateral initiatives. If one individual of a community goes "insane", enable the remaing ones to modrate. > > randy mh From randy at psg.com Tue Feb 1 17:48:58 2011 From: randy at psg.com (Randy Bush) Date: Wed, 02 Feb 2011 08:48:58 +0900 Subject: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database) In-Reply-To: <1296604062.16035.69.camel@home> References: <1296595999.16035.6.camel@home> <1296604062.16035.69.camel@home> Message-ID: >>> In this context, at least, perhaps the NIR should be considered >>> superfluous or redundant? What is the operational rationale behind the >>> NIR level? Wouldn't a flatter RIR-LIR structure do just fine? >> >> and then, by inference, what is the use of the RIR level? > > A meeting point for communities, potentially able to reflect a consensus > view of policies and moderate "NIR" and other might be more unilateral > initiatives. If one individual of a community goes "insane", enable the > remaing ones to modrate. and then, by inference, you can see how people justify the NIRs randy From kauer at biplane.com.au Tue Feb 1 17:53:15 2011 From: kauer at biplane.com.au (Karl Auer) Date: Wed, 02 Feb 2011 10:53:15 +1100 Subject: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database) In-Reply-To: <4FFCC086-EA14-4864-9594-911B6BEF2B86@delong.com> References: <35655C23-B950-4F5B-A63A-0CCAB7442859@delong.com> <62092E89-6460-4240-B6F8-FDF9D161A018@ripe.net> <4FFCC086-EA14-4864-9594-911B6BEF2B86@delong.com> Message-ID: <1296604395.12449.25.camel@karl> On Tue, 2011-02-01 at 14:51 -0800, Owen DeLong wrote: > If the RIR is signing the "invalid" ROA, how does one distinguish the > invalid from the valid? In systems where the outputs from a computer system are very, very critical, a sort of "consensus" takes place (I think they did this in some space flights too) - two of three independent systems have to agree that the information is correct before it can be acted upon. Perhaps there is room at the top level for some such mechanism in RPKI? That is, treat "the top" not as being one RIR, but as a confederation of RIRs, possibly all with the SAME key. If different keys start appearing, the one that comes from the most RIRs is considered correct, and the other(s) as mavericks. But I'm speaking from a very deep well of ignorance about RPKI. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From m.hallgren at free.fr Tue Feb 1 17:51:26 2011 From: m.hallgren at free.fr (Michael Hallgren) Date: Wed, 02 Feb 2011 00:51:26 +0100 Subject: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database) In-Reply-To: References: <1296595999.16035.6.camel@home> Message-ID: <1296604286.16035.73.camel@home> Le mardi 01 f?vrier 2011 ? 18:01 -0500, Christopher Morrow a ?crit : > On Tue, Feb 1, 2011 at 4:33 PM, Michael Hallgren wrote: > > Le mardi 01 f?vrier 2011 ? 12:14 -0500, Christopher Morrow a ?crit : > > >> countries do not have RIR's, countries have NIR's... regions have RIR's. > > > > In this context, at least, perhaps the NIR should be considered > > superfluous or redundant? What is the operational rationale behind the > > NIR level? Wouldn't a flatter RIR-LIR structure do just fine? > > some parts of the world are invested in the NIR ocncept... not my > part, but I do admit other folks like it. (and I didn't want to leave > someone out of the mix) Neither do I, but I think it's a good thing to discuss. Any NIR rep's around? mh From lee at asgard.org Tue Feb 1 17:54:48 2011 From: lee at asgard.org (Lee Howard) Date: Tue, 1 Feb 2011 18:54:48 -0500 Subject: quietly.... In-Reply-To: <4D487A29.3000003@paulgraydon.co.uk> References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com.> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> <03B2CC80-BFD3-4EFB-A008-8C8349F01F75@americafree.tv> <4D4824EF.2060801@brightok.net> <4D486CC1.1020602@paulgraydon.co.uk> <20110201203251.GF65077@puck.nether.net> <4D487A29.3000003@paulgraydon.co.uk> Message-ID: <005101cbc26b$69699f10$3c3cdd30$@org> > "People won't be able to access our site" > sure helps but being unable to put a date on it still reduces incentive > (especially when Management get involved, and especially if there is a > financial outlay involving firewalls etc.). Geoff generously provided a probabilistic sense for RIR runout: http://www.potaroo.net/tools/ipv4/rir.jpg Pick your RIR and plot its runout date. If it's ARIN, then the first ISP is out of IPv4 addresses at most three months later (since ARIN now allocates for three months' need). Of course, if demand increases, these dates might change. Will users be unable to reach your content on $RIR_runout_date + 3? They might have to get there through large-scale NAT. That might bother management if you rely on IP geo-location, or need to initiate connections downstream, or rate limit per IP address, or have anti-DOS techniques measuring hits per source IP address, or have employees VPN in, or need to report intrusions, or any of the many problems widely documented. Oh, and when I said to pick your RIR, I meant the RIR of users who access your content. Lee From randy at psg.com Tue Feb 1 17:55:39 2011 From: randy at psg.com (Randy Bush) Date: Wed, 02 Feb 2011 08:55:39 +0900 Subject: Last of ipv4 /8's allocated In-Reply-To: <1716829011.1561.1296603569640.JavaMail.root@zimbra.network1.net> References: <230156B7-B9F7-4A24-A3A6-E981110F68AC@muada.com> <1716829011.1561.1296603569640.JavaMail.root@zimbra.network1.net> Message-ID: > Doesn't really matter who gets what but conjecturebation is a key role of this mailing list > because no one is going to route anything larger than a /8 anyway, i have seen /7s routed. some folk on this list will remember an exciting day back in about 2000. randy From cb.list6 at gmail.com Tue Feb 1 17:58:00 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Tue, 1 Feb 2011 15:58:00 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <20110201233846.GV13890@angus.ind.WPI.EDU> References: <1296089078.6522.194.camel@karl> <5D2659F3-5853-4C1C-A26D-D6EB5AA75195@delong.com> <4D4820E1.20600@brightok.net> <077208EB-39DF-4F51-B263-E1BEB0BCE75A@delong.com> <4D48454A.1090807@brightok.net> <4D488FF8.4010106@brightok.net> <8998E21B-14FB-45A8-A849-D1416E946505@delong.com> <20110201233846.GV13890@angus.ind.WPI.EDU> Message-ID: On Tue, Feb 1, 2011 at 3:38 PM, Chuck Anderson wrote: > On Tue, Feb 01, 2011 at 03:14:57PM -0800, Owen DeLong wrote: >> On Feb 1, 2011, at 2:58 PM, Jack Bates wrote: >> > There are many cases where ULA is a perfect fit, and to work >> > around it seems silly and reduces the full capabilities of IPv6. I >> > fully expect to see protocols and networks within homes which will >> > take full advantage of ULA. I also expect to see hosts which don't >> > talk to the public internet directly and never need a GUA. >> > >> I guess we can agree to disagree about this. I haven't seen one yet. > > What would your recommended solution be then for disconnected > networks? ?Every home user and enterprise user requests GUA directly > from their RIR/NIR/LIR at a cost of hunderds of dollars per year or > more? > You might be asking the wrong person for advice or reasoning. Horses for courses. ULAs have a place. Cameron From millnert at gmail.com Tue Feb 1 17:58:17 2011 From: millnert at gmail.com (Martin Millnert) Date: Tue, 1 Feb 2011 18:58:17 -0500 Subject: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database) In-Reply-To: <86E7306B-CA23-4500-B97F-2071EBA294D2@gmail.com> References: <1296595999.16035.6.camel@home> <86E7306B-CA23-4500-B97F-2071EBA294D2@gmail.com> Message-ID: On Tue, Feb 1, 2011 at 5:15 PM, Carlos M. Martinez wrote: > Although I support Rpki as a technology, there are legitimate concerns that it could be abused. I now believe that Rpki needs work in this area at IETF level so the concerns are adressed. > > I imagine some form of secret sharing among different parties or sme form of key escrow. I am sure that it is not an easy problem, but maybe some progress can be made in this direction. Right. To preserve the integrity of the system it is rather necessary that multiple parties must agree to do some changes to it. This is in many ways of course a very hard thing to do, but there are a lot of good people out there with a much better understanding of cryptography and real information security than I, who definitely should look into this. Unless there already is a problem statement covering this problem, perhaps we should make one. Perhaps it is impossible to combine an easily managed system with a totally secure and robust routing infrastructure. At any rate, I consider censorship a failure of information routing. Any secure and robust routing infrastructure will not invite more censorship. Regards, Martin From surfer at mauigateway.com Tue Feb 1 17:58:07 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 1 Feb 2011 15:58:07 -0800 Subject: ipv4's last graph Message-ID: <20110201155807.D2854728@resin05.mta.everyone.net> --- townsley at cisco.com wrote: From: Mark Townsley On Feb 1, 2011, at 9:11 PM, Geoff Huston wrote: > On 01/02/2011, at 7:02 PM, Randy Bush wrote: >> graphs any more. might we have one last one for the turnstiles? :-)/2 >> >> and would you mind doing the curves now for each of the five rirs? >> gotta give us all something to repeat endlessly on lists and in presos. > > but of course. > > http://www.potaroo.net/tools/ipv4/rir.jpg I can almost hear the cutting and pasting going on across the globe with this. ------------------------------------------------------- Yes... :-) I did my share of cut-n-paste over here in an effort to pull folks' head out of their...uhhh...the sand. scott From rcarpen at network1.net Tue Feb 1 18:03:22 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Tue, 1 Feb 2011 19:03:22 -0500 (EST) Subject: Last of ipv4 /8's allocated In-Reply-To: Message-ID: <204826787.1569.1296605002710.JavaMail.root@zimbra.network1.net> ----- Original Message ----- > > Doesn't really matter who gets what > > but conjecturebation is a key role of this mailing list I literally LOLed at that. That single word more succinctly describes a concept than most I have seen. > > because no one is going to route anything larger than a /8 anyway, > > i have seen /7s routed. some folk on this list will remember an > exciting day back in about 2000. Aye. I think there have been worse routing snafus that routing a /7, though. -Randy From millnert at gmail.com Tue Feb 1 18:10:34 2011 From: millnert at gmail.com (Martin Millnert) Date: Tue, 1 Feb 2011 19:10:34 -0500 Subject: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database) In-Reply-To: <62092E89-6460-4240-B6F8-FDF9D161A018@ripe.net> References: <35655C23-B950-4F5B-A63A-0CCAB7442859@delong.com> <62092E89-6460-4240-B6F8-FDF9D161A018@ripe.net> Message-ID: Alex, On Tue, Feb 1, 2011 at 4:57 PM, Alex Band wrote: > On 1 Feb 2011, at 22:20, Owen DeLong wrote: >> RPKI is a big knob governments might be tempted to turn. > > Of course we looked into this, cause we're running our service from Amsterdam, the Netherlands. The possibilities for law enforcement agencies to take measures against the Resource Certification service run by the RIPE NCC are extremely limited. Under Dutch law, the process of certification, as well as resource certificates themselves, do not qualify as goods that are capable of being confiscated. > > Then of course, the decision making process always lies in the hands of the network operator. Only if a government would mandate an ISP to respect an invalid ROA and drop the route, it would be effective. > > So *both* these things would have to happen before there is an operational issue. Like you've seen in Egypt, pulling the plug is easier... > > YMMV on your side of the pond. > > Alex Band > Product Manager, RIPE NCC As others pointed out, and as we especially have seen the past 10 and a half years, laws can easily change. I too believe it is somewhat necessary to have 'control' over the IPv4 prefix distribution in order for the RIRs to continue being Registries. I understand and share the RIRs concern regarding this. I also do believe we can expend at least two years (just to put a number out there) more to make a system that is robust also against censorship, that everybody can feel comfortable to trust. Operational impact and cost, I believe, will be quite minor during this time. In fact, I believe it is an investment that apart from being necessary (IMO), will actually pay off, because only with a system that people trust, will most network operators enable it by their free will, which ought to be the goal for *everybody* involved. (Lest the dystopian future takes hold, of course.) Once a reliable system exists, I would be the first one to enable it on my routers, and wouldn't shed a tear if illegitimately acquired or traded routing information was lost at that time. And to be extremely clear, nobody is suggesting that they do not trust the people working at RIPE or any other RIR to do a good job here but at the same time, "we are all human". We have a, in my opinion, very big responsibility towards future generations in (re-)designing the Internet in a way that continues to keep it open and robust towards failures of various sorts. Even that of a single RIR. Regards, Martin From randy at psg.com Tue Feb 1 18:12:15 2011 From: randy at psg.com (Randy Bush) Date: Wed, 02 Feb 2011 09:12:15 +0900 Subject: quietly.... In-Reply-To: <005101cbc26b$69699f10$3c3cdd30$@org> References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> Message-ID: > Pick your RIR and plot its runout date. If it's ARIN, then the first > ISP is out of IPv4 addresses at most three months later no. arin is out, not an isp > Will users be unable to reach your content on $RIR_runout_date + 3? yes, of course randy From shacolby at bluejeansnet.com Tue Feb 1 18:19:43 2011 From: shacolby at bluejeansnet.com (Shacolby Jackson) Date: Tue, 1 Feb 2011 16:19:43 -0800 Subject: netflow analysis for jitter and packet loss? Message-ID: What tools are people most happy with? Specifically I'm hoping to mirror a port and later see if I can detect any inbound jitter or possibly even out of order udp datagrams. At first glance it doesn't look like ntop or plixer can provide that level of detail. Any suggestions? -shac From Andy.Litzinger at theplatform.com Tue Feb 1 18:27:44 2011 From: Andy.Litzinger at theplatform.com (Andy Litzinger) Date: Tue, 1 Feb 2011 16:27:44 -0800 Subject: AS numbers and multiple site best practices Message-ID: <52AAD98E43AFC64AA04AF3AC4B8B64F701CB565729@tpmail03.corp.theplatform.com> Are there any best practices or guidelines surrounding whether or not one should use the same or unique AS numbers when advertising via BGP from 2 or more physically separate locations? Each location would be advertising at least their own unique /24. My specific scenario is that we are moving our QA Lab to a datacenter that we will multi-home with two providers via BGP. We also plan to multi-home our corporate office with two providers (not likely to be the same providers) also via BGP. We currently have an AS that is in use for our multi-homed production data center. In the interest of keeping production totally segregated from QA/corp I would prefer to not use our production datacenter AS for our QA Lab or corporate network, but I've had trouble finding any technical reason not to use it. ARIN is asking for a detailed technical explanation to justify my request. Thanks in advance, -andy From nathan at atlasnetworks.us Tue Feb 1 18:46:22 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Wed, 2 Feb 2011 00:46:22 +0000 Subject: AS numbers and multiple site best practices In-Reply-To: <52AAD98E43AFC64AA04AF3AC4B8B64F701CB565729@tpmail03.corp.theplatform.com> References: <52AAD98E43AFC64AA04AF3AC4B8B64F701CB565729@tpmail03.corp.theplatform.com> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B34F040@ex-mb-1.corp.atlasnetworks.us> > I've had trouble finding any technical reason not to use it. What is important to you about having QA and Corporate use separate AS numbers? Does using the same AS number result in a reduction of separation? Nathan From rubensk at gmail.com Tue Feb 1 18:49:02 2011 From: rubensk at gmail.com (Rubens Kuhl) Date: Tue, 1 Feb 2011 22:49:02 -0200 Subject: ipv4's last graph In-Reply-To: <876F9BFF-4807-49A5-9D76-9FC067CCC645@apnic.net> References: <876F9BFF-4807-49A5-9D76-9FC067CCC645@apnic.net> Message-ID: On Tue, Feb 1, 2011 at 6:11 PM, Geoff Huston wrote: > > On 01/02/2011, at 7:02 PM, Randy Bush wrote: > >> with the iana free pool run-out, i guess we won't be getting those nice >> graphs any more. ?might we have one last one for the turnstiles? ?:-)/2 >> >> and would you mind doing the curves now for each of the five rirs? >> gotta give us all something to repeat endlessly on lists and in presos. > > but of course. > > http://www.potaroo.net/tools/ipv4/rir.jpg > > This is a different graph - it is a probabilistic graph that shows the predicted month when the RIR will be down to its last /8 policy (whatever that policy may be), and the relative probability that the event will occur in that particular month. > > The assumption behind this graph is that the barricades will go up across the regions and each region will work from its local address pools and service only its local client base, and that as each region gets to its last /8 policy the applicants will not transfer their demand to those regions where addresses are still available. Its not possible to quantify how (in)accurate this assumption may be, so beyond the prediction of the first exhaustion point (which is at this stage looking more likely to occur in July 2011 than not) the predictions for the other RIRs are highly uncertain. Geoff, Very nice work! In order to further enhance it, LACNIC exhaustion policy specifies /12 instead of /8, as specified in http://lacnic.net/en/politicas/manual11.html, so it will probably take a few more months to such a policy be in force. Rubens From rcarpen at network1.net Tue Feb 1 18:50:03 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Tue, 1 Feb 2011 19:50:03 -0500 (EST) Subject: AS numbers and multiple site best practices In-Reply-To: <52AAD98E43AFC64AA04AF3AC4B8B64F701CB565729@tpmail03.corp.theplatform.com> Message-ID: <1590052852.1577.1296607803426.JavaMail.root@zimbra.network1.net> I would say that the specifics you provide in your email are sufficient for ARIN to issue you a second ASN. There is really no other feasible way to deal with 2 separate multi-home sites that I can think of. -Randy -- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1 ---- ----- Original Message ----- > Are there any best practices or guidelines surrounding whether or not > one should use the same or unique AS numbers when advertising via BGP > from 2 or more physically separate locations? Each location would be > advertising at least their own unique /24. > > My specific scenario is that we are moving our QA Lab to a datacenter > that we will multi-home with two providers via BGP. We also plan to > multi-home our corporate office with two providers (not likely to be > the same providers) also via BGP. We currently have an AS that is in > use for our multi-homed production data center. In the interest of > keeping production totally segregated from QA/corp I would prefer to > not use our production datacenter AS for our QA Lab or corporate > network, but I've had trouble finding any technical reason not to use > it. ARIN is asking for a detailed technical explanation to justify my > request. > > Thanks in advance, > -andy From leen at consolejunkie.net Tue Feb 1 19:06:26 2011 From: leen at consolejunkie.net (Leen Besselink) Date: Wed, 02 Feb 2011 02:06:26 +0100 Subject: Last of ipv4 /8's allocated In-Reply-To: <1716829011.1561.1296603569640.JavaMail.root@zimbra.network1.net> References: <1716829011.1561.1296603569640.JavaMail.root@zimbra.network1.net> Message-ID: <4D48AE12.90805@consolejunkie.net> > Doesn't really matter who gets what, because no one is going to route anything larger than a /8 anyway, particularly the RIR allocations. Just kinda fun to think about :-) > > -Randy > > How about when HP/Compay/DEC buys Apple or the other way around ? ;-) They could do so in theory anyway. From javier at liendo.net Tue Feb 1 19:18:46 2011 From: javier at liendo.net (Javier Liendo) Date: Tue, 1 Feb 2011 19:18:46 -0600 Subject: netflow analysis for jitter and packet loss? In-Reply-To: References: Message-ID: has it to be netflow? if you are using cisco gear have you tried ip sla? http://www.cisco.com/en/US/products/ps6602/products_ios_protocol_group_home.html regards, javier On Tue, Feb 1, 2011 at 6:19 PM, Shacolby Jackson wrote: > What tools are people most happy with? Specifically I'm hoping to mirror a > port and later see if I can detect any inbound jitter or possibly even out > of order udp datagrams. At first glance it doesn't look like ntop or plixer > can provide that level of detail. Any suggestions? > > -shac > From nonobvious at gmail.com Tue Feb 1 19:37:55 2011 From: nonobvious at gmail.com (Bill Stewart) Date: Tue, 1 Feb 2011 17:37:55 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <20110201233846.GV13890@angus.ind.WPI.EDU> References: <1296089078.6522.194.camel@karl> <5D2659F3-5853-4C1C-A26D-D6EB5AA75195@delong.com> <4D4820E1.20600@brightok.net> <077208EB-39DF-4F51-B263-E1BEB0BCE75A@delong.com> <4D48454A.1090807@brightok.net> <4D488FF8.4010106@brightok.net> <8998E21B-14FB-45A8-A849-D1416E946505@delong.com> <20110201233846.GV13890@angus.ind.WPI.EDU> Message-ID: On 2/1/11, Chuck Anderson wrote: > What would your recommended solution be then for disconnected > networks? Every home user and enterprise user requests GUA directly > from their RIR/NIR/LIR at a cost of hunderds of dollars per year or > more? A typical home user will have a /56 of GUA, or maybe a /48 with some ISPs. Anybody who knows enough to figure out how to set a ULA can figure out a /64 from their GUA space that's not being auto-assigned by one of their various home routers. So if that's the way you want to do things, it won't cost you or your ISP anything. If your ISP is only assigning you a /64 of GUA, that's another story. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From rcarpen at network1.net Tue Feb 1 19:52:49 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Tue, 1 Feb 2011 20:52:49 -0500 (EST) Subject: Last of ipv4 /8's allocated In-Reply-To: <4D48AE12.90805@consolejunkie.net> Message-ID: <580612789.1585.1296611569925.JavaMail.root@zimbra.network1.net> ----- Original Message ----- > > Doesn't really matter who gets what, because no one is going to > > route anything larger than a /8 anyway, particularly the RIR > > allocations. Just kinda fun to think about :-) > > > > -Randy > > > > > How about when HP/Compay/DEC buys Apple or the other way around ? ;-) > > They could do so in theory anyway. Touch?! That could theoretically happen. I think Apple should buy HPQDEC just so they can announce 16/7 :-) None of the RIR blocks are going to be routed that way on purpose, though :-) -Randy From owen at delong.com Tue Feb 1 19:52:26 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 1 Feb 2011 17:52:26 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <4D48964D.3070109@brightok.net> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <5D2659F3-5853-4C1C-A26D-D6EB5AA75195@delong.com> <4D4820E1.20600@brightok.net> <077208EB-39DF-4F51-B263-E1BEB0BCE75A@delong.com> <4D48454A.1090807@brightok.net> <4D488FF8.4010106@brightok.net> <8998E21B-14FB-45A8-A849-D1416E946505@delong.com> <4D48964D.3070109@brightok.net> Message-ID: <42D3DBAA-9110-4ECF-B8D5-CE18DE20D069@delong.com> On Feb 1, 2011, at 3:25 PM, Jack Bates wrote: > On 2/1/2011 5:14 PM, Owen DeLong wrote: >> I guess we can agree to disagree about this. I haven't seen one yet. > > If my coffee maker did have an IP address, I expect it to get all it's updates from a central house store, not directly from the manufacturer over the net. I see no reason my appliances need global access; just access to their local controller. > Again, we can agree to disagree. I want GUA even for the things that don't need global access because I can change my mind later. There's no advantage to building that decision into the address, rather than making it in the filter policy of the routers and/or firewalls on the network. > And yes, I am working on building my IPv6 coffee maker. :P > Someone has to, I suppose. Owen From morrowc.lists at gmail.com Tue Feb 1 19:55:51 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 1 Feb 2011 20:55:51 -0500 Subject: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database) In-Reply-To: References: <1296595999.16035.6.camel@home> Message-ID: On Tue, Feb 1, 2011 at 6:13 PM, Dongting Yu wrote: > Since we are already talking about RIRs, I am curious, who will sign > the legacy blocks in RPKI? my recollection is that IANA COULD do that... (presuming a single root of the tree not 5 roots) -chris From owen at delong.com Tue Feb 1 20:03:38 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 1 Feb 2011 18:03:38 -0800 Subject: quietly.... In-Reply-To: <1296603710.12449.19.camel@karl> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> Message-ID: On Feb 1, 2011, at 3:41 PM, Karl Auer wrote: > On Tue, 2011-02-01 at 13:38 -0800, Owen DeLong wrote: >> NAT solves exactly one problem. It provides a way to reduce address >> consumption to work around a shortage of addresses. > > Devil's advocate hat on: NAT (in its most common form) also permits > internal addressing to be independent of external addressing. > Which is a bug, not a feature. > The side effects of that are not necessarily desirable (loss of > end-to-end connectivity, performance issues, limitations on simultaneous > connections etc etc). > Exactly. > It seems to me that it is this property of NAT that people are most > loath to lose. And why ULA looks tantalisingly delicious. > Yeah, but, if we take a step back and look for what they actually want that they are willing to give up everything else to get, it usually boils down to two things: 1. Obfuscation of host addresses 2. Ability to move an entire topology from one number space to another without reconfiguring the topology. IPv6 solves 1 with privacy addresses. These are horrible and I hope nobody really uses them, but, they're better than NAT. The solution to number 2 depends again on the circumstance. IPv6 offers a variety of tools for this problem, but, I have yet to see an environment where the other tools can't offer a better solution than NAT. Owen From owen at delong.com Tue Feb 1 19:59:45 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 1 Feb 2011 17:59:45 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <20110201233846.GV13890@angus.ind.WPI.EDU> References: <1296089078.6522.194.camel@karl> <5D2659F3-5853-4C1C-A26D-D6EB5AA75195@delong.com> <4D4820E1.20600@brightok.net> <077208EB-39DF-4F51-B263-E1BEB0BCE75A@delong.com> <4D48454A.1090807@brightok.net> <4D488FF8.4010106@brightok.net> <8998E21B-14FB-45A8-A849-D1416E946505@delong.com> <20110201233846.GV13890@angus.ind.WPI.EDU> Message-ID: On Feb 1, 2011, at 3:38 PM, Chuck Anderson wrote: > On Tue, Feb 01, 2011 at 03:14:57PM -0800, Owen DeLong wrote: >> On Feb 1, 2011, at 2:58 PM, Jack Bates wrote: >>> There are many cases where ULA is a perfect fit, and to work >>> around it seems silly and reduces the full capabilities of IPv6. I >>> fully expect to see protocols and networks within homes which will >>> take full advantage of ULA. I also expect to see hosts which don't >>> talk to the public internet directly and never need a GUA. >>> >> I guess we can agree to disagree about this. I haven't seen one yet. > > What would your recommended solution be then for disconnected > networks? Every home user and enterprise user requests GUA directly > from their RIR/NIR/LIR at a cost of hunderds of dollars per year or > more? For a completely disconnected network, I don't care what you do, use whatever number you want. There's no need to coordinate that with the internet in any way. For a network connected to a connected network, either get GUA from an RIR or get GUA from the network you are connected to or get GUA from some other ISP/LIR. There are lots of options. I'd like to see RIR issued GUA get a lot cheaper. I'd much rather see cheap easy to get RIR issued GUA than see ULA get widespread use. Owen From owen at delong.com Tue Feb 1 20:07:24 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 1 Feb 2011 18:07:24 -0800 Subject: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database) In-Reply-To: <1296604395.12449.25.camel@karl> References: <35655C23-B950-4F5B-A63A-0CCAB7442859@delong.com> <62092E89-6460-4240-B6F8-FDF9D161A018@ripe.net> <4FFCC086-EA14-4864-9594-911B6BEF2B86@delong.com> <1296604395.12449.25.camel@karl> Message-ID: On Feb 1, 2011, at 3:53 PM, Karl Auer wrote: > On Tue, 2011-02-01 at 14:51 -0800, Owen DeLong wrote: >> If the RIR is signing the "invalid" ROA, how does one distinguish the >> invalid from the valid? > > In systems where the outputs from a computer system are very, very > critical, a sort of "consensus" takes place (I think they did this in > some space flights too) - two of three independent systems have to agree > that the information is correct before it can be acted upon. > > Perhaps there is room at the top level for some such mechanism in RPKI? > That is, treat "the top" not as being one RIR, but as a confederation of > RIRs, possibly all with the SAME key. If different keys start appearing, > the one that comes from the most RIRs is considered correct, and the > other(s) as mavericks. > > But I'm speaking from a very deep well of ignorance about RPKI. > Indeed... The key is how you identify the signature, essentially. So, if the bodies all share the same key, then, any one of them can sign anything and it is indistinguishable from something signed by the others. What would be needed would be a triple signature with different keys (like bank checks that require more than one signature). However, the usual process for getting something signed through that system would probably be that A does the authentication process and then asks B and C to "witness" their signature. If A has a gun to their head, they're still going to likely be able to get B and C to "witness" that signature, so, you're still in a fix. This really isn't an easy problem to solve. Until it is solved, there are serious questions about RPKI doing more harm than good. Owen From jeroen at mompl.net Tue Feb 1 20:10:11 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Tue, 01 Feb 2011 18:10:11 -0800 Subject: Last of ipv4 /8's allocated In-Reply-To: <580612789.1585.1296611569925.JavaMail.root@zimbra.network1.net> References: <580612789.1585.1296611569925.JavaMail.root@zimbra.network1.net> Message-ID: <4D48BD03.5000008@mompl.net> Randy Carpenter wrote: > Touch?! That could theoretically happen. I think Apple should buy HPQDEC just so they can announce 16/7 :-) Nah, one should buy the other just so they can hand over a /7 to APNIC. -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From owen at delong.com Tue Feb 1 20:11:08 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 1 Feb 2011 18:11:08 -0800 Subject: quietly.... In-Reply-To: <005101cbc26b$69699f10$3c3cdd30$@org> References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com.> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> <03B2CC80-BFD3-4EFB-A008-8C8349F01F75@americafree.tv> <4D4824EF.2060801@brightok.net> <4D486CC1.1020602@paulgraydon.co.uk> <20110201203251.GF65077@puck.nether.net> <4D487A29.3000003@paulgraydon.co.uk> <005101cbc26b$69699f10$3c3cdd30$@org> Message-ID: On Feb 1, 2011, at 3:54 PM, Lee Howard wrote: >> "People won't be able to access our site" >> sure helps but being unable to put a date on it still reduces incentive >> (especially when Management get involved, and especially if there is a >> financial outlay involving firewalls etc.). > > Geoff generously provided a probabilistic sense for RIR runout: > http://www.potaroo.net/tools/ipv4/rir.jpg > Pick your RIR and plot its runout date. If it's ARIN, then the first > ISP is out of IPv4 addresses at most three months later (since ARIN > now allocates for three months' need). Of course, if demand increases, > these dates might change. > > Will users be unable to reach your content on $RIR_runout_date + 3? > They might have to get there through large-scale NAT. That might > bother management if you rely on IP geo-location, or need to > initiate connections downstream, or rate limit per IP address, or > have anti-DOS techniques measuring hits per source IP address, > or have employees VPN in, or need to report intrusions, or any of > the many problems widely documented. > > Oh, and when I said to pick your RIR, I meant the RIR of users > who access your content. > > Lee > I think there is a key problem with Geoff's graph. I think it fails to take into account the transitive probability of requests among the largest 3 regions. I agree that APNIC will probably run just about exactly as he predicts. I think, however, that the runout at APNIC will create a higher demand in ARIN and RIPE. Once that happens, their runout dates will get moved up much closer to the runout date of APNIC. As soon as the second of the three runs out, the remaining one will get another burst of acceleration. It does not appear to me that this probability is accounted for in the plots. Owen (Including Geoff because it's not fair to criticize his work behind his back) From bensons at queuefull.net Tue Feb 1 20:18:27 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Tue, 1 Feb 2011 20:18:27 -0600 Subject: Last of ipv4 /8's allocated In-Reply-To: <4D48BD03.5000008@mompl.net> References: <580612789.1585.1296611569925.JavaMail.root@zimbra.network1.net> <4D48BD03.5000008@mompl.net> Message-ID: <52042F45-93D8-495D-A7F8-4E38F57041B2@queuefull.net> On Feb 1, 2011, at 8:10 PM, Jeroen van Aart wrote: > Randy Carpenter wrote: >> Touch?! That could theoretically happen. I think Apple should buy HPQDEC just so they can announce 16/7 :-) > > Nah, one should buy the other just so they can hand over a /7 to APNIC. How would they justify that to their shareholders? (I mean turning over the addresses - the merger itself would be a more challenging question.) -Benson From owen at delong.com Tue Feb 1 20:16:07 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 1 Feb 2011 18:16:07 -0800 Subject: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database) In-Reply-To: References: <1296595999.16035.6.camel@home> <86E7306B-CA23-4500-B97F-2071EBA294D2@gmail.com> Message-ID: On Feb 1, 2011, at 3:58 PM, Martin Millnert wrote: > On Tue, Feb 1, 2011 at 5:15 PM, Carlos M. Martinez > wrote: >> Although I support Rpki as a technology, there are legitimate concerns that it could be abused. I now believe that Rpki needs work in this area at IETF level so the concerns are adressed. >> >> I imagine some form of secret sharing among different parties or sme form of key escrow. I am sure that it is not an easy problem, but maybe some progress can be made in this direction. > > Right. To preserve the integrity of the system it is rather necessary > that multiple parties must agree to do some changes to it. This is > in many ways of course a very hard thing to do, but there are a lot of > good people out there with a much better understanding of cryptography > and real information security than I, who definitely should look into > this. Unless there already is a problem statement covering this > problem, perhaps we should make one. > > Perhaps it is impossible to combine an easily managed system with a > totally secure and robust routing infrastructure. > > At any rate, I consider censorship a failure of information routing. > Any secure and robust routing infrastructure will not invite more > censorship. > > Regards, > Martin Multiple parties alone, however is not sufficient. It needs to be multiple parties that are unlikely to be unduly influenced by the same group of governments or alliance of governments under any possible circumstance. The existing RIRs may or may not be an adequate way to spread this out. Certainly there is risk in the fact that IANA is in the US and subject by itself to US government whims. The fact that IANA and ARIN are both in the US is of particular concern because it means even combined there is no check and balance between them, either ad both can be usurped by the same power. Owen From owen at delong.com Tue Feb 1 20:23:29 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 1 Feb 2011 18:23:29 -0800 Subject: Last of ipv4 /8's allocated In-Reply-To: <4D48AE12.90805@consolejunkie.net> References: <1716829011.1561.1296603569640.JavaMail.root@zimbra.network1.net> <4D48AE12.90805@consolejunkie.net> Message-ID: <4E36A52B-82AA-4713-B8C9-AD1A854E86EB@delong.com> On Feb 1, 2011, at 5:06 PM, Leen Besselink wrote: > >> Doesn't really matter who gets what, because no one is going to route anything larger than a /8 anyway, particularly the RIR allocations. Just kinda fun to think about :-) >> >> -Randy >> >> > How about when HP/Compay/DEC buys Apple or the other way around ? ;-) > > They could do so in theory anyway. > At this point, IPv4 could be done before the regulatory process completed. Owen From cmadams at hiwaay.net Tue Feb 1 20:24:56 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 1 Feb 2011 20:24:56 -0600 Subject: quietly.... In-Reply-To: References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> Message-ID: <20110202022456.GA3142@hiwaay.net> Once upon a time, Owen DeLong said: > On Feb 1, 2011, at 3:41 PM, Karl Auer wrote: > > Devil's advocate hat on: NAT (in its most common form) also permits > > internal addressing to be independent of external addressing. > > > Which is a bug, not a feature. That is an opinion (and not a unversally held opinion), not a fact. I tend to agree with you, but you keep stating your opinion as fact. Telling people "I'm right, you're wrong" over and over again leads to them going away and ignoring IPv6. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From paul at paulgraydon.co.uk Tue Feb 1 20:27:40 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Tue, 01 Feb 2011 16:27:40 -1000 Subject: quietly.... In-Reply-To: References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com.> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> <03B2CC80-BFD3-4EFB-A008-8C8349F01F75@americafree.tv> <4D4824EF.2060801@brightok.net> <4D486CC1.1020602@paulgraydon.co.uk> <20110201203251.GF65077@puck.nether.net> <4D487A29.3000003@paulgraydon.co.uk> <005101cbc26b$69699f10$3c3cdd30$@org> Message-ID: <4D48C11C.2060402@paulgraydon.co.uk> On 02/01/2011 04:11 PM, Owen DeLong wrote: > On Feb 1, 2011, at 3:54 PM, Lee Howard wrote: > >>> "People won't be able to access our site" >>> sure helps but being unable to put a date on it still reduces incentive >>> (especially when Management get involved, and especially if there is a >>> financial outlay involving firewalls etc.). >> Geoff generously provided a probabilistic sense for RIR runout: >> http://www.potaroo.net/tools/ipv4/rir.jpg >> Pick your RIR and plot its runout date. If it's ARIN, then the first >> ISP is out of IPv4 addresses at most three months later (since ARIN >> now allocates for three months' need). Of course, if demand increases, >> these dates might change. >> >> Will users be unable to reach your content on $RIR_runout_date + 3? >> They might have to get there through large-scale NAT. That might >> bother management if you rely on IP geo-location, or need to >> initiate connections downstream, or rate limit per IP address, or >> have anti-DOS techniques measuring hits per source IP address, >> or have employees VPN in, or need to report intrusions, or any of >> the many problems widely documented. >> >> Oh, and when I said to pick your RIR, I meant the RIR of users >> who access your content. >> >> Lee >> > I think there is a key problem with Geoff's graph. > > I think it fails to take into account the transitive probability of requests > among the largest 3 regions. I agree that APNIC will probably run > just about exactly as he predicts. I think, however, that the runout > at APNIC will create a higher demand in ARIN and RIPE. Once that > happens, their runout dates will get moved up much closer to > the runout date of APNIC. As soon as the second of the three > runs out, the remaining one will get another burst of acceleration. > > It does not appear to me that this probability is accounted for in the > plots. > > Owen > > (Including Geoff because it's not fair to criticize his work behind his back) Are there any expectations of a Gold Rush for the remaining addresses? I would expect to see at least see some kind of escalation. Paul From owen at delong.com Tue Feb 1 20:27:47 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 1 Feb 2011 18:27:47 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: References: <1296089078.6522.194.camel@karl> <5D2659F3-5853-4C1C-A26D-D6EB5AA75195@delong.com> <4D4820E1.20600@brightok.net> <077208EB-39DF-4F51-B263-E1BEB0BCE75A@delong.com> <4D48454A.1090807@brightok.net> <4D488FF8.4010106@brightok.net> <8998E21B-14FB-45A8-A849-D1416E946505@delong.com> <20110201233846.GV13890@angus.ind.WPI.EDU> Message-ID: <7382F315-CDBF-471F-AAC6-3E5B61E5ED4B@delong.com> On Feb 1, 2011, at 5:37 PM, Bill Stewart wrote: > On 2/1/11, Chuck Anderson wrote: >> What would your recommended solution be then for disconnected >> networks? Every home user and enterprise user requests GUA directly >> from their RIR/NIR/LIR at a cost of hunderds of dollars per year or >> more? > > A typical home user will have a /56 of GUA, or maybe a /48 with some > ISPs. Anybody who knows enough to figure out how to set a ULA can > figure out a /64 from their GUA space that's not being auto-assigned > by one of their various home routers. So if that's the way you want > to do things, it won't cost you or your ISP anything. > > If your ISP is only assigning you a /64 of GUA, that's another story. > If your ISP assigns you less than a /48, ask them to fix it. If they refuse, get a new ISP or use that ISP to connect a tunnel to someone who will give you a /48. Owen From jeroen at mompl.net Tue Feb 1 20:29:59 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Tue, 01 Feb 2011 18:29:59 -0800 Subject: Last of ipv4 /8's allocated In-Reply-To: <52042F45-93D8-495D-A7F8-4E38F57041B2@queuefull.net> References: <580612789.1585.1296611569925.JavaMail.root@zimbra.network1.net> <4D48BD03.5000008@mompl.net> <52042F45-93D8-495D-A7F8-4E38F57041B2@queuefull.net> Message-ID: <4D48C1A7.2070109@mompl.net> Benson Schliesser wrote: > On Feb 1, 2011, at 8:10 PM, Jeroen van Aart wrote: >> Nah, one should buy the other just so they can hand over a /7 to APNIC. > How would they justify that to their shareholders? Free advertising, increased goodwill? ;-) -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From owen at delong.com Tue Feb 1 20:29:34 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 1 Feb 2011 18:29:34 -0800 Subject: Last of ipv4 /8's allocated In-Reply-To: <4D48BD03.5000008@mompl.net> References: <580612789.1585.1296611569925.JavaMail.root@zimbra.network1.net> <4D48BD03.5000008@mompl.net> Message-ID: <8E87EEBB-B91D-43E9-AF4F-37CC6DF28814@delong.com> On Feb 1, 2011, at 6:10 PM, Jeroen van Aart wrote: > Randy Carpenter wrote: >> Touch?! That could theoretically happen. I think Apple should buy HPQDEC just so they can announce 16/7 :-) > > Nah, one should buy the other just so they can hand over a /7 to APNIC. > Neither of them could do that. Both are in the ARIN region. Owen From owen at delong.com Tue Feb 1 20:33:43 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 1 Feb 2011 18:33:43 -0800 Subject: quietly.... In-Reply-To: <20110202022456.GA3142@hiwaay.net> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> Message-ID: On Feb 1, 2011, at 6:24 PM, Chris Adams wrote: > Once upon a time, Owen DeLong said: >> On Feb 1, 2011, at 3:41 PM, Karl Auer wrote: >>> Devil's advocate hat on: NAT (in its most common form) also permits >>> internal addressing to be independent of external addressing. >>> >> Which is a bug, not a feature. > > That is an opinion (and not a unversally held opinion), not a fact. I > tend to agree with you, but you keep stating your opinion as fact. > Telling people "I'm right, you're wrong" over and over again leads to > them going away and ignoring IPv6. > Using this definition of bug from Wikipedia: A software bug is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways. I argue that breaking the end-to-end model which is a documented fundamental tenant of the internet protocol and the internet addressing system is, by definition, within the definition above. Q.E.D. it is, in fact, a bug, not merely my opinion. Others are welcome to consider said bug to be a feature, but, it is, by definition, factually, a bug. Owen From kevin at steadfast.net Tue Feb 1 20:39:35 2011 From: kevin at steadfast.net (Kevin Stange) Date: Tue, 01 Feb 2011 20:39:35 -0600 Subject: quietly.... In-Reply-To: <4D48C11C.2060402@paulgraydon.co.uk> References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com.> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> <03B2CC80-BFD3-4EFB-A008-8C8349F01F75@americafree.tv> <4D4824EF.2060801@brightok.net> <4D486CC1.1020602@paulgraydon.co.uk> <20110201203251.GF65077@puck.nether.net> <4D487A29.3000003@paulgraydon.co.uk> <005101cbc26b$69699f10$3c3cdd30$@org> <4D48C11C.2060402@paulgraydon.co.uk> Message-ID: <4D48C3E7.6010807@steadfast.net> On 02/01/2011 08:27 PM, Paul Graydon wrote: > Are there any expectations of a Gold Rush for the remaining addresses? > I would expect to see at least see some kind of escalation. I've heard that it's already started at ARIN. -- Kevin Stange Chief Technology Officer Steadfast Networks http://steadfast.net Phone: 312-602-2689 x203 Fax: 312-602-2688 Cell: 312-320-5867 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From cb.list6 at gmail.com Tue Feb 1 20:44:37 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Tue, 1 Feb 2011 18:44:37 -0800 Subject: quietly.... In-Reply-To: <20110202022456.GA3142@hiwaay.net> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> Message-ID: On Tue, Feb 1, 2011 at 6:24 PM, Chris Adams wrote: > Once upon a time, Owen DeLong said: >> On Feb 1, 2011, at 3:41 PM, Karl Auer wrote: >> > Devil's advocate hat on: NAT (in its most common form) also permits >> > internal addressing to be independent of external addressing. >> > >> Which is a bug, not a feature. > > That is an opinion (and not a unversally held opinion), not a fact. ?I > tend to agree with you, but you keep stating your opinion as fact. > Telling people "I'm right, you're wrong" over and over again leads to > them going away and ignoring IPv6. > +1 Somebody should probably get a blog instead of sending, *39 and counting*, emails to this list in one day. From jcurran at arin.net Tue Feb 1 21:09:50 2011 From: jcurran at arin.net (John Curran) Date: Wed, 2 Feb 2011 03:09:50 +0000 Subject: quietly.... In-Reply-To: <4D48C3E7.6010807@steadfast.net> References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> <03B2CC80-BFD3-4EFB-A008-8C8349F01F75@americafree.tv> <4D4824EF.2060801@brightok.net> <4D486CC1.1020602@paulgraydon.co.uk> <20110201203251.GF65077@puck.nether.net> <4D487A29.3000003@paulgraydon.co.uk> <005101cbc26b$69699f10$3c3cdd30$@org> <4D48C11C.2060402@paulgraydon.co.uk> <4D48C3E7.6010807@steadfast.net> Message-ID: <2CCB13E7-2430-4641-A76D-E5255F834F56@arin.net> On Feb 1, 2011, at 9:39 PM, Kevin Stange wrote: > On 02/01/2011 08:27 PM, Paul Graydon wrote: >> Are there any expectations of a Gold Rush for the remaining addresses? >> I would expect to see at least see some kind of escalation. > > I've heard that it's already started at ARIN. We had a small ramp up in December (about 25% increase) but that is within reasonable variation. Today was a little different, though, with 4 times the normal request rate... that would be a "rush". FYI, /John John Curran President and CEO ARIN From rdobbins at arbor.net Tue Feb 1 21:38:50 2011 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 2 Feb 2011 10:38:50 +0700 Subject: netflow analysis for jitter and packet loss? In-Reply-To: References: Message-ID: <2F668318-F2AC-483D-8C0C-6A926044355D@arbor.net> On Feb 2, 2011, at 7:19 AM, Shacolby Jackson wrote: > Any suggestions? Flow telemetry is extremely useful, but it isn't really suited for looking at things like jitter and delay, and out-of-order packets. It can be used to identify loss in many instances, as well as communications relationships, bps/pps, source/destination distribution, macro-level application behaviors, statistical and behavioral anomalies, DDoS attacks, et. al., but you really need packet-level classification/inspection to get the level of detail you mention. ------------------------------------------------------------------------ Roland Dobbins // From Valdis.Kletnieks at vt.edu Tue Feb 1 21:47:31 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 01 Feb 2011 22:47:31 -0500 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: Your message of "Tue, 01 Feb 2011 17:37:55 PST." References: <1296089078.6522.194.camel@karl> <5D2659F3-5853-4C1C-A26D-D6EB5AA75195@delong.com> <4D4820E1.20600@brightok.net> <077208EB-39DF-4F51-B263-E1BEB0BCE75A@delong.com> <4D48454A.1090807@brightok.net> <4D488FF8.4010106@brightok.net> <8998E21B-14FB-45A8-A849-D1416E946505@delong.com> <20110201233846.GV13890@angus.ind.WPI.EDU> Message-ID: <53692.1296618451@localhost> On Tue, 01 Feb 2011 17:37:55 PST, Bill Stewart said: > A typical home user will have a /56 of GUA, or maybe a /48 with some > ISPs. Anybody who knows enough to figure out how to set a ULA can > figure out a /64 from their GUA space that's not being auto-assigned > by one of their various home routers. So if that's the way you want > to do things, it won't cost you or your ISP anything. Your local home network topology may not allow easy choice of a /64, if you have multiple actual subnets - if it all fit into one /64, why did you need/want that /56 or /48 in the first place?) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Tue Feb 1 21:46:50 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 01 Feb 2011 22:46:50 -0500 Subject: quietly.... In-Reply-To: Your message of "Wed, 02 Feb 2011 03:09:50 GMT." <2CCB13E7-2430-4641-A76D-E5255F834F56@arin.net> References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> <03B2CC80-BFD3-4EFB-A008-8C8349F01F75@americafree.tv> <4D4824EF.2060801@brightok.net> <4D486CC1.1020602@paulgraydon.co.uk> <20110201203251.GF65077@puck.nether.net> <4D487A29.3000003@paulgraydon.co.uk> <005101cbc26b$69699f10$3c3cdd30$@org> <4D48C11C.2060402@paulgraydon.co.uk> <4D48C3E7.6010807@steadfast.net> <2CCB13E7-2430-4641-A76D-E5255F834F56@arin.net> Message-ID: <53646.1296618410@localhost> On Wed, 02 Feb 2011 03:09:50 GMT, John Curran said: > We had a small ramp up in December (about 25% increase) but that is within > reasonable variation. Today was a little different, though, with 4 times > the normal request rate... that would be a "rush". Any trending on the rate of requests for IPv6 prefixes? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From davei at otd.com Tue Feb 1 21:51:22 2011 From: davei at otd.com (Dave Israel) Date: Tue, 01 Feb 2011 22:51:22 -0500 Subject: quietly.... In-Reply-To: References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> Message-ID: <4D48D4BA.5010005@otd.com> On 2/1/2011 9:33 PM, Owen DeLong wrote: > On Feb 1, 2011, at 6:24 PM, Chris Adams wrote: > >> Once upon a time, Owen DeLong said: >>> On Feb 1, 2011, at 3:41 PM, Karl Auer wrote: >>>> Devil's advocate hat on: NAT (in its most common form) also permits >>>> internal addressing to be independent of external addressing. >>>> >>> Which is a bug, not a feature. >> That is an opinion (and not a unversally held opinion), not a fact. I >> tend to agree with you, but you keep stating your opinion as fact. >> Telling people "I'm right, you're wrong" over and over again leads to >> them going away and ignoring IPv6. >> > Using this definition of bug from Wikipedia: > > A software bug is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways. > > I argue that breaking the end-to-end model which is a documented fundamental tenant of the internet protocol and the internet addressing system is, by definition, within the definition above. > > Q.E.D. it is, in fact, a bug, not merely my opinion. Others are welcome to > consider said bug to be a feature, but, it is, by definition, factually, a bug. I apologize in advance for the strong wording, and will apologize for it in person (with a beer) at some point. But: A NATed client connects to a server, and they speak end to end. A NATed server receives connections directly from clients. It is more or less end to end, communications-wise, and so it is the same or less of a "bug," by your definition, than a proxy server, or a web cache, or ipv4 anycast DNS, or inspecting/fixup capable firewalls. And those are all things people want. If you are advocating that IPv6 should not be capable of performing tasks people want it to perform, then you are advocating for IPv6 to follow the path of the OSI protocols as a "could have been the new Internet" protocol, and you are pushing the world toward the NATernet, and you are actually, unintentionally, one of IPv6's worst enemies. Look back across all the big arguments over the years that had people turning purple and calling each other names and declaring that IPv6 was broken. They are all about features in IPv6 that operators did not want, because directly or indirectly, they either disabled features people use now, or they told people how hey had to build their networks. They were features dreamed up by academics, theoreticians, and purists, and opposed by operators. You can blame sloth, ignorance, and heads in the sand all you want for the long wait for IPv6 adoption, but the insistence by IPv6 evangelists that IPv4-think is necessarily evil and that they are going to force everybody to conform to their perfect paradigm is also a big factor. And this isn't just a perception issue, or rebellion at being told what to do. Part of what made IPv4 so successful was that its simplicity made it inherently flexible, and even operators who are wrong about what things like NAT give them are right to rebel against restricting flexibility to meet certain people's perception of what network purity means today. -Dave From frnkblk at iname.com Tue Feb 1 22:10:15 2011 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 1 Feb 2011 22:10:15 -0600 Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed In-Reply-To: <20110131155108.GC4714@dan.olp.net> References: <3D53E591D3EF17409FA82C5C0F8FC6BACE8072@sbs.B2B2Cinc.local> <4D46D405.8050201@b2b2c.ca> <4D46D513.7090609@brightok.net> <20110131155108.GC4714@dan.olp.net> Message-ID: <00e701cbc28f$191f3aa0$4b5dafe0$@iname.com> We've sold routers for years, but make it clear to our customer that we are doing this as a convenience to the customer and that we are not responsible for it. It's worked for hardware failure, and since we end up providing initial support for home wireless routers, having a model we're familiar with makes it easier. Frank -----Original Message----- From: Dan White [mailto:dwhite at olp.net] Sent: Monday, January 31, 2011 9:51 AM To: Jack Bates Cc: nanog at nanog.org Subject: Re: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed On 31/01/11?09:28?-0600, Jack Bates wrote: > > >On 1/31/2011 9:23 AM, Chris Conn wrote: >>As for the DIR-615, it should, but it doesn't...At least, the E3/E4 >>revisions I had. I contacted D-LINK support and was able to get a beta >>build that seems promising. But DHCP-PD over PPPoE works relatively >>well, minus a couple of little "features". I am hoping to have that >>hammered out soon, as the 615 is a capable little sub-50$ home CPE. But >>D-Link engineering seems receptive to my observations. > >My concern as an ISP is the fact that we provide our own CPE, but >customers often buy off shelf CPE. This will lead to serious >interoperability issues if the whole market doesn't get their act >together. There's a fine line we're trying to hold with what we support. We want to establish a recommended list of residential grade routers for our customers (where appropriate), that they can purchase themselves off the shelf, without having to deal with the inevitable "you sold me this router, so you need to make it work with my Wii and I don't feel that I should have to pay you" type of headaches, if we were to actually sell the routers ourselves. That rules out 3rd party firmware like dd-wrt, since the customer is unlikely to get support when calling the vendor. At this point, I'd be happy with two good options (two different vendors) to recommend. So far, D-link is looking good. -- Dan White From george.herbert at gmail.com Tue Feb 1 22:05:25 2011 From: george.herbert at gmail.com (George Herbert) Date: Tue, 1 Feb 2011 20:05:25 -0800 Subject: quietly.... In-Reply-To: <53646.1296618410@localhost> References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> <03B2CC80-BFD3-4EFB-A008-8C8349F01F75@americafree.tv> <4D4824EF.2060801@brightok.net> <4D486CC1.1020602@paulgraydon.co.uk> <20110201203251.GF65077@puck.nether.net> <4D487A29.3000003@paulgraydon.co.uk> <005101cbc26b$69699f10$3c3cdd30$@org> <4D48C11C.2060402@paulgraydon.co.uk> <4D48C3E7.6010807@steadfast.net> <2CCB13E7-2430-4641-A76D-E5255F834F56@arin.net> <53646.1296618410@localhost> Message-ID: On Tue, Feb 1, 2011 at 7:46 PM, wrote: > On Wed, 02 Feb 2011 03:09:50 GMT, John Curran said: >> We had a small ramp up in December (about 25% increase) but that is within >> reasonable variation. Today was a little different, though, with 4 times >> the normal request rate... that would be a "rush". > > Any trending on the rate of requests for IPv6 prefixes? More interesting would be re-requests - organizations exhausting an initial allocation and requiring more. People asking for the first one just indicates initial adoption rates. Other than experimental blocks, I am generally under the impression that IPv6 allocations are designed to avoid that being necessary for an extended period of time. If that is not true, then that's a flag. -- -george william herbert george.herbert at gmail.com From jcurran at arin.net Tue Feb 1 22:17:18 2011 From: jcurran at arin.net (John Curran) Date: Wed, 2 Feb 2011 04:17:18 +0000 Subject: quietly.... In-Reply-To: <53646.1296618410@localhost> References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> <03B2CC80-BFD3-4EFB-A008-8C8349F01F75@americafree.tv> <4D4824EF.2060801@brightok.net> <4D486CC1.1020602@paulgraydon.co.uk> <20110201203251.GF65077@puck.nether.net> <4D487A29.3000003@paulgraydon.co.uk> <005101cbc26b$69699f10$3c3cdd30$@org> <4D48C11C.2060402@paulgraydon.co.uk> <4D48C3E7.6010807@steadfast.net> <2CCB13E7-2430-4641-A76D-E5255F834F56@arin.net> <53646.1296618410@localhost> Message-ID: On Feb 1, 2011, at 10:46 PM, Valdis.Kletnieks at vt.edu wrote: > On Wed, 02 Feb 2011 03:09:50 GMT, John Curran said: >> We had a small ramp up in December (about 25% increase) but that is within >> reasonable variation. Today was a little different, though, with 4 times >> the normal request rate... that would be a "rush". > > Any trending on the rate of requests for IPv6 prefixes? A quick review shows no significant change in IPv6 request rate January through today, although I would point out that the second of half of 2010 had a fairly significant ramp up in IPv6 requests (both assignments and allocations). You can view all the 2010 charts are online here: https://www.arin.net/knowledge/statistics/index.html. FYI, /John John Curran President and CEO ARIN From jcurran at arin.net Tue Feb 1 22:19:50 2011 From: jcurran at arin.net (John Curran) Date: Wed, 2 Feb 2011 04:19:50 +0000 Subject: quietly.... In-Reply-To: References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> <03B2CC80-BFD3-4EFB-A008-8C8349F01F75@americafree.tv> <4D4824EF.2060801@brightok.net> <4D486CC1.1020602@paulgraydon.co.uk> <20110201203251.GF65077@puck.nether.net> <4D487A29.3000003@paulgraydon.co.uk> <005101cbc26b$69699f10$3c3cdd30$@org> <4D48C11C.2060402@paulgraydon.co.uk> <4D48C3E7.6010807@steadfast.net> <2CCB13E7-2430-4641-A76D-E5255F834F56@arin.net> <53646.1296618410@localhost> Message-ID: <0958C15C-FF67-4F1A-B6CB-B28D972F5013@arin.net> On Feb 1, 2011, at 11:05 PM, George Herbert wrote: > > More interesting would be re-requests - organizations exhausting an > initial allocation and requiring more. People asking for the first > one just indicates initial adoption rates. > > Other than experimental blocks, I am generally under the impression > that IPv6 allocations are designed to avoid that being necessary for > an extended period of time. If that is not true, then that's a flag. I don't believe we've had an IPv6 "additional" request yet (but I look forward to it happening at some point :-). I will check and get back to the list with the definitive answer. /John John Curran President and CEO ARIN From source_route at yahoo.com Tue Feb 1 22:22:45 2011 From: source_route at yahoo.com (Philip Lavine) Date: Tue, 1 Feb 2011 20:22:45 -0800 (PST) Subject: Bovespa Message-ID: <173163.67681.qm@web30807.mail.mud.yahoo.com> 1. Does anyone know where the Bovespa is located and if colocation is a possibility at that datacenter/s. 2. What is?a good?Internet (DS3? or ethernet)?carrier in Sao Paolo thank you Philip From Skeeve at eintellego.net Tue Feb 1 22:32:24 2011 From: Skeeve at eintellego.net (Skeeve Stevens) Date: Wed, 2 Feb 2011 15:32:24 +1100 Subject: quietly.... In-Reply-To: Message-ID: Not necessarily. There was a proposal passed at ARIN and I have a similar one proposed for APNIC where you can request a second allocation should you need it for a variety of justification. For example: disparate non-connected networks under a different AS's. This is the one that is bothering me at the moment. ...Skeeve -- Skeeve Stevens, CEO eintellego Pty Ltd - The Networking Specialists skeeve at eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- eintellego - The Experts that the Experts call - Juniper - HP Networking - Cisco - Brocade - Arista - On 2/02/11 3:05 PM, "George Herbert" wrote: >On Tue, Feb 1, 2011 at 7:46 PM, wrote: >> On Wed, 02 Feb 2011 03:09:50 GMT, John Curran said: >>> We had a small ramp up in December (about 25% increase) but that is >>>within >>> reasonable variation. Today was a little different, though, with 4 >>>times >>> the normal request rate... that would be a "rush". >> >> Any trending on the rate of requests for IPv6 prefixes? > >More interesting would be re-requests - organizations exhausting an >initial allocation and requiring more. People asking for the first >one just indicates initial adoption rates. > >Other than experimental blocks, I am generally under the impression >that IPv6 allocations are designed to avoid that being necessary for >an extended period of time. If that is not true, then that's a flag. > > >-- >-george william herbert >george.herbert at gmail.com > From morrowc.lists at gmail.com Tue Feb 1 22:36:03 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 1 Feb 2011 23:36:03 -0500 Subject: quietly.... In-Reply-To: References: Message-ID: On Tue, Feb 1, 2011 at 11:32 PM, Skeeve Stevens wrote: > Not necessarily. > > There was a proposal passed at ARIN and I have a similar one proposed for (I think you mean, or the one dave farmer's been working on for a time now) -chris From jbates at brightok.net Tue Feb 1 23:02:16 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 01 Feb 2011 23:02:16 -0600 Subject: quietly.... In-Reply-To: <4D48D4BA.5010005@otd.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> Message-ID: <4D48E558.7070805@brightok.net> On 2/1/2011 9:51 PM, Dave Israel wrote: > They were features dreamed up by academics, theoreticians, and > purists, and opposed by operators. You mean like the lack of Default Router in DHCPv6? Don't get me wrong. I love RA. However, it is NOT a universal tool, and there are cases where Default Router via DHCPv6 would be more appropriate and easier to manage. Case in point. If I hand out IA_NA or IA_TA to directly connected DSL hosts or CPEs, I have no need of RA. In addition, the load on my router is increased by having to send RA to 3000+ interfaces, something that is absolutely not necessary in my deployment. I would even go as far to say that Default Router would be a good stateless option to hand out along with the DNS servers when customers do SLAAC with me. I have also now seen 2 different vendor DSL modems which when not using PPPoE require a manually entered default router (ie, no RA support). Jack From jbates at brightok.net Tue Feb 1 23:04:50 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 01 Feb 2011 23:04:50 -0600 Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed In-Reply-To: <00e701cbc28f$191f3aa0$4b5dafe0$@iname.com> References: <3D53E591D3EF17409FA82C5C0F8FC6BACE8072@sbs.B2B2Cinc.local> <4D46D405.8050201@b2b2c.ca> <4D46D513.7090609@brightok.net> <20110131155108.GC4714@dan.olp.net> <00e701cbc28f$191f3aa0$4b5dafe0$@iname.com> Message-ID: <4D48E5F2.2050309@brightok.net> On 2/1/2011 10:10 PM, Frank Bulk wrote: > We've sold routers for years, but make it clear to our customer that we are > doing this as a convenience to the customer and that we are not responsible > for it. I agree with you, but I also know my telco's. It would go horribly wrong. :) Jack From jbates at brightok.net Tue Feb 1 23:10:49 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 01 Feb 2011 23:10:49 -0600 Subject: quietly.... In-Reply-To: <0958C15C-FF67-4F1A-B6CB-B28D972F5013@arin.net> References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> <03B2CC80-BFD3-4EFB-A008-8C8349F01F75@americafree.tv> <4D4824EF.2060801@brightok.net> <4D486CC1.1020602@paulgraydon.co.uk> <20110201203251.GF65077@puck.nether.net> <4D487A29.3000003@paulgraydon.co.uk> <005101cbc26b$69699f10$3c3cdd30$@org> <4D48C11C.2060402@paulgraydon.co.uk> <4D48C3E7.6010807@steadfast.net> <2CCB13E7-2430-4641-A76D-E5255F834F56@arin.net> <53646.1296618410@localhost> <0958C15C-FF67-4F1A-B6CB-B28D972F5013@arin.net> Message-ID: <4D48E759.4070508@brightok.net> On 2/1/2011 10:19 PM, John Curran wrote: > I don't believe we've had an IPv6 "additional" request yet (but I look > forward to it happening at some point:-). I will check and get back > to the list with the definitive answer. > I believe that the changing of IPv6 policy leads to "redo's", and I expect to see expansions again if current proposals are accepted. I don't believe enough eyeballs have been assigned address space yet with current policy to draw necessity yet. Further expansions would likely reduce that necessity even further. Jack From randy at psg.com Tue Feb 1 23:40:26 2011 From: randy at psg.com (Randy Bush) Date: Wed, 02 Feb 2011 14:40:26 +0900 Subject: quietly.... In-Reply-To: References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> Message-ID: > Somebody should probably get a blog instead of sending, *39 and > counting*, emails to this list in one day. procmail is your friend From vinny at abellohome.net Wed Feb 2 00:21:09 2011 From: vinny at abellohome.net (Vinny Abello) Date: Wed, 02 Feb 2011 01:21:09 -0500 Subject: Connectivity to Brazil In-Reply-To: <80F3BEC5-89AA-4D54-95EA-976AC3292E60@gmail.com> References: <4F3DD62E-4007-4ED2-94D6-8405E1C1546E@gmail.com> <33104.1296591593@localhost> <80F3BEC5-89AA-4D54-95EA-976AC3292E60@gmail.com> Message-ID: We saw similar issues with IKE through Global Crossing (as odd as that sounds) out of the NYC market at the same time. We routed around them and problem solved. Still scratching our heads on that one... In my experiences, GLBX has numerous odd issues to the point where it's become a bad joke anytime something breaks with connectivity... we blame them. It's kind of not funny though because it's almost always true. Taking them out of the equation usually fixes the problem. One of our customers who is frequently affected by GBLX problems jumps to the (often correct) conclusion that they are causing problems. :-/ -Vinny On Feb 1, 2011, at 3:57 PM, Steve Danelli wrote: > Thanks for the response. > > Ike had worked great up until Monday. The provider did a local test and our box saw the Ike packets so it appears to lie somewhere upstream. (GLBX may be a good guess) > > Also - the paths are stable and we are sourcing from the same ip - very strange behaivor. Hope someone from GLBX or CTBC (or someone who had experienced an issue like this) can assist > > > Thanks to all for their feedback so far. > > SD > > On Feb 1, 2011, at 3:19 PM, Valdis.Kletnieks at vt.edu wrote: > >> On Tue, 01 Feb 2011 08:54:47 EST, Steve Danelli said: >> >>> Some carrier, somewhere between us and the service provider is selectively >>> dropping the IKE packets originating from our VPN gateway and destined for >>> our Brazil gateway. Other traffic is able to pass, as are the IKE packets coming >>> back from Brazil to us. This is effectively preventing us from establishing >>> the IPSEC tunnel between our gateways. >> >> Has IKE been known to work to that location before? Or is this something new? >> My first guess is some chucklehead banana-eater at the service provider either >> fat-fingered the firewall config, or semi-intentionally blocked it because it >> was "traffic on a protocol/port number they didn't understand so it must be >> evil". >> >>> Also something else is awry, for two given hosts on the same subnet (x.y.z.52 >>> and x.y.z.53), they take two wildly divergent paths: >> >>> Anyone have any insight on to what may be occurring? >> >> The paths appear to diverge at 67.16.142.238. I wonder if that's gear trying >> to do some load-balancing across 2 paths, and it's using the source IP as a >> major part of the selector function ("route to round-robin interface source-IP >> mod N" or similar?). >> >> The other possibility is your two traceroutes happened to catch a routing flap in >> progress (obviously not the case if the two routes are remaining stable). >> >> Sorry I can't be more helpful than that... > From drc at virtualized.org Wed Feb 2 00:22:20 2011 From: drc at virtualized.org (David Conrad) Date: Tue, 1 Feb 2011 20:22:20 -1000 Subject: Last of ipv4 /8's allocated In-Reply-To: <230156B7-B9F7-4A24-A3A6-E981110F68AC@muada.com> References: <238182428.1509.1296599596109.JavaMail.root@zimbra.network1.net> <230156B7-B9F7-4A24-A3A6-E981110F68AC@muada.com> Message-ID: On Feb 1, 2011, at 12:44 PM, Iljitsch van Beijnum wrote: > My suspicion is that IANA is playing a game of battleship with the RIRs and thursday we'll see who's won. Colored in for your convenience: IANA instituted a variation of RFC 2777 some time ago to do /8 allocations to the RIRs. I'd be surprised if they deviated from that process for the last 5 /8s. Regards, -drc From joelja at bogus.com Wed Feb 2 00:27:14 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 01 Feb 2011 22:27:14 -0800 Subject: ipv4's last graph In-Reply-To: References: <135901cbc22b$b88705f0$299511d0$@net> Message-ID: <4D48F942.6000807@bogus.com> On 2/1/11 1:08 PM, Randy Bush wrote: >> FWIW: the Jan. 2011 global burn rate (outbound from the RIRs) for >> /24-equivlents was 18.97 seconds. At the Jan. rate, APnic won't last >> to June and Ripe might make to the end of August, then chaos ensues. > > this is not the murdoch press or fox news. i very much doubt chaos will > ensue. our job is to see that chaos does not ensue. you will learn to > love nat444 :) the aportionment of scarce resources though market signals whether direct or indirect is actually something humans are rather good at despite the occasional failure. the engineer is the person who given the available resources comes with a workable solution. >> Is there really any value in trying to distribute graphs that will all >> be flat before the end of the year? > > we're ops, often stick in the mud traditionalists and even somewhat > supersitious. we've had ipv4 graphs for over 15 years. we like them. > geoff is mr graph. we like his grphs. heck, you have even used them. the prboability distribution with the error bars is a pretty useful tool to throw over the wall to management so that they know how long they have to get their affairs in order. > randy > From randy at psg.com Wed Feb 2 00:30:02 2011 From: randy at psg.com (Randy Bush) Date: Wed, 02 Feb 2011 15:30:02 +0900 Subject: ipv4's last graph In-Reply-To: <4D48F942.6000807@bogus.com> References: <135901cbc22b$b88705f0$299511d0$@net> <4D48F942.6000807@bogus.com> Message-ID: > the prboability distribution with the error bars is a pretty useful > tool to throw over the wall to management so that they know how long > they have to get their affairs in order. i suspect it's more like most folk should save a gif so they can say "i warned you," when they need a bunch of money to bail the deaf management's asses out in a year. rndy From vixie at isc.org Wed Feb 2 00:38:07 2011 From: vixie at isc.org (Paul Vixie) Date: Wed, 02 Feb 2011 06:38:07 +0000 Subject: Verizon acquiring Terremark In-Reply-To: (Jeffrey Lyon's message of "Mon, 31 Jan 2011 16:42:58 -0500") References: <6EFFEFBAC68377459A2E972105C759EC03539A93@EXVBE005-2.exch005intermedia.net> Message-ID: <2838.1296628687@nsa.vix.com> Jeffrey Lyon writes: > One cannot be owned by a carrier and remain carrier neutral. > > My two cents, my experience running PAIX when it was owned by MFN was not like you're saying. -- Paul Vixie KI6YSY From sj_hznm at hotmail.com Wed Feb 2 00:40:23 2011 From: sj_hznm at hotmail.com (Joe) Date: Wed, 2 Feb 2011 06:40:23 +0000 Subject: DHCP server fail-over and accounting Message-ID: hi, we plan to implement DHCP server farm in our network. Currently , there are there problems burning my head. could anybody do some help? 1. How to set up DHCP server farm with high availability? It's required to set up DHCP server with 99.999% available. To our experience, this needs to set up DHCP server on two sites and syncronize their content in real time. Beside this , we hope there should be as less modification as possible on edge router when one DHCP server is down. should anycast architecture helpful ? or should we just set up two dhcp servers on two sites and sync. with ISC DHCPD? is there any other method for fail-over and high availability? 2. How to set up accouting and authentication with DHCP? Regulation and content based pricing is demanded. So, we plan to authenticate customer and accouting on their usage. In previous list post, someone said Juniper could do radius before DHCP. Does this mean Juniper could authenticate user with radius (username/password) before DHCP ? Is there anyway to collect user traffic under DHCP ? 3. Someone said PPPOE is not good for customer looking for long time online , DHCP is an good option. But, to my understanding DHCP is just good for those looking for easy-transfer to IPv6 , because pppoe could also make user on line as long as possible. Is there any reference on DHCP server consideration on 4-to-6 migration? Joe From gih at apnic.net Wed Feb 2 00:45:12 2011 From: gih at apnic.net (Geoff Huston) Date: Wed, 2 Feb 2011 17:45:12 +1100 Subject: quietly.... In-Reply-To: References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com.> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> <03B2CC80-BFD3-4EFB-A008-8C8349F01F75@americafree.tv> <4D4824EF.2060801@brightok.net> <4D486CC1.1020602@paulgraydon.co.uk> <20110201203251.GF65077@puck.nether.net> <4D487A29.3000003@paulgraydon.co.uk> <005101cbc26b$69699f10$3c3cdd30$@org> Message-ID: <4504BB02-4D7C-4019-88C3-66B4CAEF2CAC@apnic.net> On 02/02/2011, at 1:11 PM, Owen DeLong wrote: > > On Feb 1, 2011, at 3:54 PM, Lee Howard wrote: > >>> "People won't be able to access our site" >>> sure helps but being unable to put a date on it still reduces incentive >>> (especially when Management get involved, and especially if there is a >>> financial outlay involving firewalls etc.). >> >> Geoff generously provided a probabilistic sense for RIR runout: >> http://www.potaroo.net/tools/ipv4/rir.jpg >> Pick your RIR and plot its runout date. If it's ARIN, then the first >> ISP is out of IPv4 addresses at most three months later (since ARIN >> now allocates for three months' need). Of course, if demand increases, >> these dates might change. >> >> Will users be unable to reach your content on $RIR_runout_date + 3? >> They might have to get there through large-scale NAT. That might >> bother management if you rely on IP geo-location, or need to >> initiate connections downstream, or rate limit per IP address, or >> have anti-DOS techniques measuring hits per source IP address, >> or have employees VPN in, or need to report intrusions, or any of >> the many problems widely documented. >> >> Oh, and when I said to pick your RIR, I meant the RIR of users >> who access your content. >> >> Lee >> > > I think there is a key problem with Geoff's graph. > > I think it fails to take into account the transitive probability of requests > among the largest 3 regions. I agree that APNIC will probably run > just about exactly as he predicts. I think, however, that the runout > at APNIC will create a higher demand in ARIN and RIPE. Once that > happens, their runout dates will get moved up much closer to > the runout date of APNIC. As soon as the second of the three > runs out, the remaining one will get another burst of acceleration. > > It does not appear to me that this probability is accounted for in the > plots. > > Owen > > (Including Geoff because it's not fair to criticize his work behind his back) Yes - a certain (X) percent of demand will shift out from a region once that region's stocks are depleted. What value X realistically takes is not something I can factor into these models, nor can I predict where this unmet demand may surface in the remaining regions. The future of IPv4 contains many uncertainties. Geoff From tore.anderson at redpill-linpro.com Wed Feb 2 02:16:10 2011 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Wed, 02 Feb 2011 09:16:10 +0100 Subject: ipv4's last graph In-Reply-To: <876F9BFF-4807-49A5-9D76-9FC067CCC645@apnic.net> References: <876F9BFF-4807-49A5-9D76-9FC067CCC645@apnic.net> Message-ID: <4D4912CA.2000308@redpill-linpro.com> * Geoff Huston > http://www.potaroo.net/tools/ipv4/rir.jpg Ohh, very nice, Geoff! Thank you! A few questions, though: 1) The graph shows the most probable APNIC depletion date to be in July. However your site at says 25-Sep-2011. What's the reason for this discrepancy? 2) Do you intend to update the graph daily? I noticed that it didn't change this morning along with all your other graphs. 3) May I copy it into my own presentations about IPv4 and IPv6? Regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From iljitsch at muada.com Wed Feb 2 02:16:59 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 2 Feb 2011 09:16:59 +0100 Subject: quietly.... In-Reply-To: <4D48D4BA.5010005@otd.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> Message-ID: <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> On 2 feb 2011, at 4:51, Dave Israel wrote: > They were features dreamed up by academics, theoreticians, and purists, and opposed by operators. Contrary to popular belief, the IETF listens to operators and wants them to participate. Few do. For instance, I don't seem to remember your name from any IETF mailinglists. (I could be mistaken, though.) There is a fundamental difference between designing something and using something. Both inform the other. But letting users with no design experience create something is a short road to failure. (Letting designers run stuff isn't much better.) I always like to say the internet is an infinite universe. In an infinite universe, everything that's possible exist. Same in the internet. Think of some way to do something, however ill-informed, and someone is doing it that way. Example: if you give administrators the option of putting a router address in a DHCP option, they will do so and some fraction of the time, this will be the wrong address and things don't work. If you let routers announce their presence, then it's virtually impossible that something goes wrong because routers know who they are. A clear win. Of course it does mean that people have to learn something new when adopting IPv6. From iljitsch at muada.com Wed Feb 2 02:20:56 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 2 Feb 2011 09:20:56 +0100 Subject: Last of ipv4 /8's allocated In-Reply-To: <1716829011.1561.1296603569640.JavaMail.root@zimbra.network1.net> References: <1716829011.1561.1296603569640.JavaMail.root@zimbra.network1.net> Message-ID: <16034AAF-7095-4149-BF65-A3FEDBE705D2@muada.com> On 2 feb 2011, at 0:39, Randy Carpenter wrote: >>> That's how I would do it. With the exception of LACNIC, each one >>> neighbors a block that is already allocated to that RIR. >> But if they wanted to do that, why give 106/8 to APNIC? > I assume you mean 102/8 No, I was talking about monday's allocations: http://www.apnic.net/publications/news/2011/delegation From jeffrey.lyon at blacklotus.net Wed Feb 2 02:22:39 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Wed, 2 Feb 2011 03:22:39 -0500 Subject: Verizon acquiring Terremark In-Reply-To: <2838.1296628687@nsa.vix.com> References: <6EFFEFBAC68377459A2E972105C759EC03539A93@EXVBE005-2.exch005intermedia.net> <2838.1296628687@nsa.vix.com> Message-ID: Paul, I'm sure everything will be fine in practice as others have indicated, I was merely making a point of the inherent conflict of interest. Best regards, Jeff On Wed, Feb 2, 2011 at 1:38 AM, Paul Vixie wrote: > Jeffrey Lyon writes: > >> One cannot be owned by a carrier and remain carrier neutral. >> >> My two cents, > > my experience running PAIX when it was owned by MFN was not like you're saying. > -- > Paul Vixie > KI6YSY > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From mehmet at icann.org Wed Feb 2 03:00:09 2011 From: mehmet at icann.org (Mehmet Akcin) Date: Wed, 2 Feb 2011 01:00:09 -0800 Subject: Verizon acquiring Terremark In-Reply-To: References: <6EFFEFBAC68377459A2E972105C759EC03539A93@EXVBE005-2.exch005intermedia.net> <2838.1296628687@nsa.vix.com> Message-ID: <4798287A-CDFF-470A-B9EF-8D796438FE6F@icann.org> On Feb 2, 2011, at 3:22 AM, Jeffrey Lyon wrote: >>> One cannot be owned by a carrier and remain carrier neutral. One does NOT have to be carrier neutral to provide good service.. I am sure those who have experienced great Terremark service will stick to them. mehmet From gih at apnic.net Wed Feb 2 03:29:09 2011 From: gih at apnic.net (Geoff Huston) Date: Wed, 2 Feb 2011 20:29:09 +1100 Subject: quietly.... In-Reply-To: <4D48C11C.2060402@paulgraydon.co.uk> References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com.> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> <03B2CC80-BFD3-4EFB-A008-8C8349F01F75@americafree.tv> <4D4824EF.2060801@brightok.net> <4D486CC1.1020602@paulgraydon.co.uk> <20110201203251.GF65077@puck.nether.net> <4D487A29.3000003@paulgraydon.co.uk> <005101cbc26b$69699f10$3c3cdd30$@org> <4D48C11C.2060402@paulgraydon.co.uk> Message-ID: <607FD0A3-4B1A-48AD-A299-F82FFE28F375@apnic.net> > Are there any expectations of a Gold Rush for the remaining addresses? I would expect to see at least see some kind of escalation. > This question probably calls for another picture. Here is a plot of 2009 and 2010 in terms of the average number of IPv4 addresses allocated on a daily basis, across all 5 RIRs. I've used a smoothing function across the allocation data in order to clearly show the trend pattern over the two year period. http://www.potaroo.net/tools/ipv4/daily-allocs.jpg Geoff From jna at retina.net Wed Feb 2 03:38:48 2011 From: jna at retina.net (John Adams) Date: Wed, 2 Feb 2011 01:38:48 -0800 Subject: DHCP server fail-over and accounting In-Reply-To: References: Message-ID: 2011/2/1 Joe : > > hi, > > ? ?we plan to implement DHCP server farm in our network. ? Currently , there are there ?problems burning my head. could anybody You're making this way, way too complicated. Run two DHCP servers. Allocate two different netblocks to each server. For Example, if your network is a /24, allocate a couple of /26's. Both will answer on a request. The client will ack to whatever address it decides to accept. Full redundancy. > ? ? ? To our experience, this needs to set up ?DHCP ?server on two sites and syncronize their content in real time. > ? ? ?Beside this , ?we hope ?there should be as less modification as possible ?on edge router when one DHCP ?server is down. > ? ? ?should anycast architecture helpful ? ? or should we just set up two dhcp servers on two sites and ?sync. with ISC DHCPD? Don't even bother with the syncing, and anycast is the wrong protocol here. > ?2. How to set up accouting and authentication with DHCP? That's the wrong place to do it. 802.1X is better here, or PPPOE/ACLs that need RADIUS auth to get past. > 3. ?Someone said PPPOE is not good for customer looking for long time online , ?DHCP is an good option. ?But, to my understanding That's funny, because many major ISPs (like telcos) have done this for years. -j From mpetach at netflight.com Wed Feb 2 03:45:59 2011 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 2 Feb 2011 01:45:59 -0800 Subject: quietly.... In-Reply-To: <607FD0A3-4B1A-48AD-A299-F82FFE28F375@apnic.net> References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com.> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> <03B2CC80-BFD3-4EFB-A008-8C8349F01F75@americafree.tv> <4D4824EF.2060801@brightok.net> <4D486CC1.1020602@paulgraydon.co.uk> <20110201203251.GF65077@puck.nether.net> <4D487A29.3000003@paulgraydon.co.uk> <005101cbc26b$69699f10$3c3cdd30$@org> <4D48C11C.2060402@paulgraydon.co.uk> <607FD0A3-4B1A-48AD-A299-F82FFE28F375@apnic.net> Message-ID: On Wed, Feb 2, 2011 at 1:29 AM, Geoff Huston wrote: >> Are there any expectations of a Gold Rush for the remaining addresses? ?I would expect to see at least see some kind of escalation. >> > > This question probably calls for another picture. > > Here is a plot of 2009 and 2010 in terms of the average number of IPv4 addresses allocated on a daily basis, across all 5 RIRs. I've used a smoothing function across the allocation data in order to clearly show the trend pattern over the two year period. > > http://www.potaroo.net/tools/ipv4/daily-allocs.jpg > > ?Geoff Oh master of the awesome graphingness...can you do a corresponding slide for v6 allocation rates, so we can see if the runout is helping inspire additional interest for networks in perhaps investigating v6 more seriously? Thanks! Matt From nicolas at ncartron.org Wed Feb 2 03:48:51 2011 From: nicolas at ncartron.org (Nicolas CARTRON) Date: Wed, 2 Feb 2011 10:48:51 +0100 Subject: DHCP server fail-over and accounting In-Reply-To: References: Message-ID: Hi, On Wed, Feb 2, 2011 at 10:38 AM, John Adams wrote: > 2011/2/1 Joe : > > > > hi, > > > > we plan to implement DHCP server farm in our network. Currently , > there are there problems burning my head. could anybody > > > You're making this way, way too complicated. > > Run two DHCP servers. Allocate two different netblocks to each server. > For Example, if your network is a /24, allocate a couple of /26's. > Both will answer on a request. > The client will ack to whatever address it decides to accept. Full > redundancy. > Well, it also depends on the constraints: having such a configuration implies that every scope will have to be declared twice, as well as the DHCP options. Plus, if the server who issued the lease is down, the client will get a new DHCP lease - which maybe an issue for some people. > > > To our experience, this needs to set up DHCP server on two sites > and syncronize their content in real time. > > Beside this , we hope there should be as less modification as > possible on edge router when one DHCP server is down. > > should anycast architecture helpful ? or should we just set up two > dhcp servers on two sites and sync. with ISC DHCPD? > > Don't even bother with the syncing, and anycast is the wrong protocol here. Agree, anycast makes no sense. ISC DHCPd sync works well, provided you know it and configured it correctly. From wilhelm at ripe.net Wed Feb 2 04:57:43 2011 From: wilhelm at ripe.net (Rene Wilhelm) Date: Wed, 02 Feb 2011 11:57:43 +0100 Subject: quietly.... In-Reply-To: <607FD0A3-4B1A-48AD-A299-F82FFE28F375@apnic.net> References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com.> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> <03B2CC80-BFD3-4EFB-A008-8C8349F01F75@americafree.tv> <4D4824EF.2060801@brightok.net> <4D486CC1.1020602@paulgraydon.co.uk> <20110201203251.GF65077@puck.nether.net> <4D487A29.3000003@paulgraydon.co.uk> <005101cbc26b$69699f10$3c3cdd30$@org> <4D48C11C.2060402@paulgraydon.co.uk> <607FD0A3-4B1A-48AD-A299-F82FFE28F375@apnic.net> Message-ID: <4D4938A7.5060307@ripe.net> On 2/2/11 10:29 AM, Geoff Huston wrote: >> Are there any expectations of a Gold Rush for the remaining addresses? I would expect to see at least see some kind of escalation. >> > This question probably calls for another picture. > > Here is a plot of 2009 and 2010 in terms of the average number of IPv4 addresses allocated on a daily basis, across all 5 RIRs. I've used a smoothing function across the allocation data in order to clearly show the trend pattern over the two year period. > > http://www.potaroo.net/tools/ipv4/daily-allocs.jpg > > > Geoff We published a similar graph on RIPE Labs last friday. It shows the 6 months rolling average allocation rate for each RIR (in units of /8s per month). APNIC's allocation rate has been on a steady rise since 2008. After coming down in 2009/2010, the average rates in ARIN and RIPE have gone up again recently. Could be the first signs of a gold rush, or just a coincidence. https://labs.ripe.net/Members/wilhelm/images/IPv4RatesPerRIR.png -- Rene From owen at delong.com Wed Feb 2 04:59:51 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 2 Feb 2011 02:59:51 -0800 Subject: quietly.... In-Reply-To: References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> <03B2CC80-BFD3-4EFB-A008-8C8349F01F75@americafree.tv> <4D4824EF.2060801@brightok.net> <4D486CC1.1020602@paulgraydon.co.uk> <20110201203251.GF65077@puck.nether.net> <4D487A29.3000003@paulgraydon.co.uk> <005101cbc26b$69699f10$3c3cdd30$@org> <4D48C11C.2060402@paulgraydon.co.uk> <4D48C3E7.6010807@steadfast.net> <2CCB13E7-2430-4641-A76D-E5255F834F56@arin.net> <53646.1296618410@localhost> Message-ID: <6A7DD465-755B-4156-9012-A78F259EC782@delong.com> On Feb 1, 2011, at 8:05 PM, George Herbert wrote: > On Tue, Feb 1, 2011 at 7:46 PM, wrote: >> On Wed, 02 Feb 2011 03:09:50 GMT, John Curran said: >>> We had a small ramp up in December (about 25% increase) but that is within >>> reasonable variation. Today was a little different, though, with 4 times >>> the normal request rate... that would be a "rush". >> >> Any trending on the rate of requests for IPv6 prefixes? > > More interesting would be re-requests - organizations exhausting an > initial allocation and requiring more. People asking for the first > one just indicates initial adoption rates. > > Other than experimental blocks, I am generally under the impression > that IPv6 allocations are designed to avoid that being necessary for > an extended period of time. If that is not true, then that's a flag. > There are definitely policy changes needed in order to make this true. I doubt that there are many network operators that have deployed enough IPv6 to be up against that wall yet. I know of only one. ARIN Policy Proposal 121 is intended to improve that situation significantly and also reduce the probability for human-factors related outages in the future in IPv6. Owen From teoruiz at gmail.com Wed Feb 2 05:17:41 2011 From: teoruiz at gmail.com (Teo Ruiz) Date: Wed, 2 Feb 2011 12:17:41 +0100 Subject: Connectivity status for Egypt In-Reply-To: <86D21E41-69F3-4F3C-994F-BBED3619E5DC@americafree.tv> References: <33496563.960.1296250642067.JavaMail.franck@franck-martins-macbook-pro.local> <5EEA5622-9EDA-4FD6-B4BE-F4E2C812A271@americafree.tv> <86D21E41-69F3-4F3C-994F-BBED3619E5DC@americafree.tv> Message-ID: On Tue, Feb 1, 2011 at 21:30, Marshall Eubanks wrote: > On Jan 31, 2011, at 5:14 PM, Marshall Eubanks wrote: > >> As an update, BGP for Noor.net has been withdrawn. Even the Egyptian stock exchange - egyptse.com - now appears to be off the Internet. > > I have been told that the Egyptian Prime Minister has publicly announced that the Internet would be restored soon, but at present neither my Looks like it's coming back: http://stat.ripe.net/egypt ~2500 prefixes being announced now. -- teo - http://www.teoruiz.com "Res publica non dominetur" From owen at delong.com Wed Feb 2 05:18:01 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 2 Feb 2011 03:18:01 -0800 Subject: quietly.... In-Reply-To: <4D48E558.7070805@brightok.net> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <4D48E558.7070805@brightok.net> Message-ID: <2FD9EDE7-E28C-48E7-B6FB-8386773EF98E@delong.com> On Feb 1, 2011, at 9:02 PM, Jack Bates wrote: > On 2/1/2011 9:51 PM, Dave Israel wrote: >> They were features dreamed up by academics, theoreticians, and purists, and opposed by operators. > > You mean like the lack of Default Router in DHCPv6? > The whole SLAAC vs. DHCPv6 argument is a complete debacle. What IETF should have done there is provide two complete protocols that operators could make the choice or combination of choices that worked best for them. Instead, the two camps spent so much time and energy disrupting the other protocol that instead, we have two completely incomplete protocols and you need to use a weird combination of the two just to get basic functionality. There is ongoing work to complete them both now that operators have noticed, but, it is unfortunate this was so badly delayed. > Don't get me wrong. I love RA. However, it is NOT a universal tool, and there are cases where Default Router via DHCPv6 would be more appropriate and easier to manage. > Yep. This is an example of a missing feature. I'm in complete agreement. NAT66 is different. NAT66 breaks things in ways that impact sites outside of the site choosing to deploy NAT. Owen From cowie at renesys.com Wed Feb 2 05:23:39 2011 From: cowie at renesys.com (Jim Cowie) Date: Wed, 2 Feb 2011 06:23:39 -0500 Subject: Connectivity status for Egypt In-Reply-To: References: <33496563.960.1296250642067.JavaMail.franck@franck-martins-macbook-pro.local> <5EEA5622-9EDA-4FD6-B4BE-F4E2C812A271@americafree.tv> <86D21E41-69F3-4F3C-994F-BBED3619E5DC@americafree.tv> Message-ID: On Wed, Feb 2, 2011 at 6:17 AM, Teo Ruiz wrote: > On Tue, Feb 1, 2011 at 21:30, Marshall Eubanks wrote: > > On Jan 31, 2011, at 5:14 PM, Marshall Eubanks wrote: > > > >> As an update, BGP for Noor.net has been withdrawn. Even the Egyptian > stock exchange - egyptse.com - now appears to be off the Internet. > > > > I have been told that the Egyptian Prime Minister has publicly announced > that the Internet would be restored soon, but at present neither my > > Looks like it's coming back: http://stat.ripe.net/egypt > > ~2500 prefixes being announced now. > -- > teo - http://www.teoruiz.com > > "Res publica non dominetur" > Yes, confirmed from 09:29 UTC. Basically all major providers are back, full status quo ante (modulo reagg), major sites are up. http://www.renesys.com/blog/2011/02/egypt-returns-to-the-internet.shtml Good thoughts go out to the guys in the EG NOCs this morning. Nanog wants to hear your war stories some day over a cup of tea. --jim From bortzmeyer at nic.fr Wed Feb 2 05:30:45 2011 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 2 Feb 2011 12:30:45 +0100 Subject: Connectivity status for Egypt In-Reply-To: References: <33496563.960.1296250642067.JavaMail.franck@franck-martins-macbook-pro.local> <5EEA5622-9EDA-4FD6-B4BE-F4E2C812A271@americafree.tv> <86D21E41-69F3-4F3C-994F-BBED3619E5DC@americafree.tv> Message-ID: <20110202113045.GA1309@nic.fr> On Wed, Feb 02, 2011 at 06:23:39AM -0500, Jim Cowie wrote a message of 29 lines which said: > Yes, confirmed from 09:29 UTC. Basically all major providers are > back, full status quo ante (modulo reagg), major sites are up. EUN (the academic network, which includes the primary name server for .EG) is still unreachable (1130 UTC). From bortzmeyer at nic.fr Wed Feb 2 05:37:47 2011 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 2 Feb 2011 12:37:47 +0100 Subject: Connectivity status for Egypt In-Reply-To: <20110202113045.GA1309@nic.fr> References: <33496563.960.1296250642067.JavaMail.franck@franck-martins-macbook-pro.local> <5EEA5622-9EDA-4FD6-B4BE-F4E2C812A271@americafree.tv> <86D21E41-69F3-4F3C-994F-BBED3619E5DC@americafree.tv> <20110202113045.GA1309@nic.fr> Message-ID: <20110202113747.GA2822@nic.fr> On Wed, Feb 02, 2011 at 12:30:45PM +0100, Stephane Bortzmeyer wrote a message of 10 lines which said: > EUN (the academic network, which includes the primary name server for > .EG) is still unreachable (1130 UTC). It works now (1137 UTC). BGP was a bit slow. From owen at delong.com Wed Feb 2 05:39:14 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 2 Feb 2011 03:39:14 -0800 Subject: quietly.... In-Reply-To: <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> Message-ID: On Feb 2, 2011, at 12:16 AM, Iljitsch van Beijnum wrote: > On 2 feb 2011, at 4:51, Dave Israel wrote: > >> They were features dreamed up by academics, theoreticians, and purists, and opposed by operators. > > Contrary to popular belief, the IETF listens to operators and wants them to participate. Few do. For instance, I don't seem to remember your name from any IETF mailinglists. (I could be mistaken, though.) > > There is a fundamental difference between designing something and using something. Both inform the other. But letting users with no design experience create something is a short road to failure. (Letting designers run stuff isn't much better.) > > I always like to say the internet is an infinite universe. In an infinite universe, everything that's possible exist. Same in the internet. Think of some way to do something, however ill-informed, and someone is doing it that way. > > Example: if you give administrators the option of putting a router address in a DHCP option, they will do so and some fraction of the time, this will be the wrong address and things don't work. If you let routers announce their presence, then it's virtually impossible that something goes wrong because routers know who they are. A clear win. Of course it does mean that people have to learn something new when adopting IPv6. I would point to 6to4 and the RAs coming from Windows Laptops that think they are routers because someone clicked on an ICS checkbox as a counter example that letting things that think they are routers announce their presence is, in fact, proof that it is not only possible that something goes wrong, but, commonplace. So, your clear win has proven to be a rather large lose in a number of environments. Owen From gourmetcisco at hotmail.com Wed Feb 2 06:14:30 2011 From: gourmetcisco at hotmail.com (Matt Disuko) Date: Wed, 2 Feb 2011 07:14:30 -0500 Subject: Connectivity to Brazil In-Reply-To: References: <4F3DD62E-4007-4ED2-94D6-8405E1C1546E@gmail.com>, <33104.1296591593@localhost>, <80F3BEC5-89AA-4D54-95EA-976AC3292E60@gmail.com>, Message-ID: Very interesting. I have had similar issues with connectivity to my Brazil office, and oddly enough it involved GBLX and CTBC (now called Algar Telecom). I also vastly divergent paths to a couple hosts in the same subnet. I ended up communicating with GBLX via email (who were actually really great in corresponding with me)...the engineer pointed to some sort of link capacity issue...i'll dig up the thread... > Date: Wed, 2 Feb 2011 01:21:09 -0500 > From: vinny at abellohome.net > Subject: Re: Connectivity to Brazil > To: the76posse at gmail.com > CC: nanog at nanog.org > > We saw similar issues with IKE through Global Crossing (as odd as that sounds) out of the NYC market at the same time. We routed around them and problem solved. Still scratching our heads on that one... In my experiences, GLBX has numerous odd issues to the point where it's become a bad joke anytime something breaks with connectivity... we blame them. It's kind of not funny though because it's almost always true. Taking them out of the equation usually fixes the problem. One of our customers who is frequently affected by GBLX problems jumps to the (often correct) conclusion that they are causing problems. :-/ > > -Vinny > > On Feb 1, 2011, at 3:57 PM, Steve Danelli wrote: > > > Thanks for the response. > > > > Ike had worked great up until Monday. The provider did a local test and our box saw the Ike packets so it appears to lie somewhere upstream. (GLBX may be a good guess) > > > > Also - the paths are stable and we are sourcing from the same ip - very strange behaivor. Hope someone from GLBX or CTBC (or someone who had experienced an issue like this) can assist > > > > > > Thanks to all for their feedback so far. > > > > SD > > > > On Feb 1, 2011, at 3:19 PM, Valdis.Kletnieks at vt.edu wrote: > > > >> On Tue, 01 Feb 2011 08:54:47 EST, Steve Danelli said: > >> > >>> Some carrier, somewhere between us and the service provider is selectively > >>> dropping the IKE packets originating from our VPN gateway and destined for > >>> our Brazil gateway. Other traffic is able to pass, as are the IKE packets coming > >>> back from Brazil to us. This is effectively preventing us from establishing > >>> the IPSEC tunnel between our gateways. > >> > >> Has IKE been known to work to that location before? Or is this something new? > >> My first guess is some chucklehead banana-eater at the service provider either > >> fat-fingered the firewall config, or semi-intentionally blocked it because it > >> was "traffic on a protocol/port number they didn't understand so it must be > >> evil". > >> > >>> Also something else is awry, for two given hosts on the same subnet (x.y.z.52 > >>> and x.y.z.53), they take two wildly divergent paths: > >> > >>> Anyone have any insight on to what may be occurring? > >> > >> The paths appear to diverge at 67.16.142.238. I wonder if that's gear trying > >> to do some load-balancing across 2 paths, and it's using the source IP as a > >> major part of the selector function ("route to round-robin interface source-IP > >> mod N" or similar?). > >> > >> The other possibility is your two traceroutes happened to catch a routing flap in > >> progress (obviously not the case if the two routes are remaining stable). > >> > >> Sorry I can't be more helpful than that... > > > > From nick at foobar.org Wed Feb 2 06:25:33 2011 From: nick at foobar.org (Nick Hilliard) Date: Wed, 02 Feb 2011 12:25:33 +0000 Subject: quietly.... In-Reply-To: <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> Message-ID: <4D494D3D.2040800@foobar.org> On 02/02/2011 08:16, Iljitsch van Beijnum wrote: > Contrary to popular belief, the IETF listens to operators and wants them > to participate. Few do. For instance, I don't seem to remember your name > from any IETF mailinglists. (I could be mistaken, though.) Regardless of the stated opinion of the IETF and its participants, there is a culture in the IETF of resistance to operational opinion. The DHCPv6 vs RA debacle is a direct consequence of this and a good example of both the problem and the serious consequences which ensue when one side doesn't listen. Nick From randy at psg.com Wed Feb 2 06:33:52 2011 From: randy at psg.com (Randy Bush) Date: Wed, 02 Feb 2011 21:33:52 +0900 Subject: quietly.... In-Reply-To: <4D494D3D.2040800@foobar.org> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <4D494D3D.2040800@foobar.org> Message-ID: > Regardless of the stated opinion of the IETF and its participants, > there is a culture in the IETF of resistance to operational opinion. > The DHCPv6 vs RA debacle is a direct consequence of this and a good > example of both the problem and the serious consequences which ensue > when one side doesn't listen. some ietf ops participants have been fighting this for years, not always successfully. but recently, the ops within the ietf community have been banding together a bit more. the win rate is not a lot higher, but at least we can share the pain. :) your characterization of the dhcpv6 issue as a debacle is understated. it's flat out st00pid and insane, and loses ipv6 non-trivial market share. the religious fools have moved to the mentality that v4 scarcity will force ipv6 deployment and they don't have to compromise their ivory tower zealotry. they are bringing nats of all flavors on themselves. this would be fine if the rest of us did not also get the dren. randy From jcurran at arin.net Wed Feb 2 06:37:54 2011 From: jcurran at arin.net (John Curran) Date: Wed, 2 Feb 2011 12:37:54 +0000 Subject: quietly.... In-Reply-To: <0958C15C-FF67-4F1A-B6CB-B28D972F5013@arin.net> References: <58A6EB9C-DCB5-40B9-A831-42F11FD141ED@muada.com> <20110201115315.GC7266@vacation.karoshi.com> <3A05D51F-6792-497A-82A5-71DAA986772E@delong.com> <03B2CC80-BFD3-4EFB-A008-8C8349F01F75@americafree.tv> <4D4824EF.2060801@brightok.net> <4D486CC1.1020602@paulgraydon.co.uk> <20110201203251.GF65077@puck.nether.net> <4D487A29.3000003@paulgraydon.co.uk> <005101cbc26b$69699f10$3c3cdd30$@org> <4D48C11C.2060402@paulgraydon.co.uk> <4D48C3E7.6010807@steadfast.net> <2CCB13E7-2430-4641-A76D-E5255F834F56@arin.net> <53646.1296618410@localhost> <0958C15C-FF67-4F1A-B6CB-B28D972F5013@arin.net> Message-ID: <6C7F2B53-E1AA-444F-B712-28CDF47E439A@corp.arin.net> On Feb 1, 2011, at 11:19 PM, John Curran wrote: > On Feb 1, 2011, at 11:05 PM, George Herbert wrote: >> >> More interesting would be re-requests - organizations exhausting an >> initial allocation and requiring more. People asking for the first >> one just indicates initial adoption rates. >> >> Other than experimental blocks, I am generally under the impression >> that IPv6 allocations are designed to avoid that being necessary for >> an extended period of time. If that is not true, then that's a flag. > > I don't believe we've had an IPv6 "additional" request yet (but I look > forward to it happening at some point :-). I will check and get back > to the list with the definitive answer. It turns out we've had a handful of ISPs come back for additional IPv6 blocks but it was the result of an better understanding of their evolving address allocation requirements pre-deployment. FYI, /John John Curran President and CEO ARIN From iljitsch at muada.com Wed Feb 2 06:50:01 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 2 Feb 2011 13:50:01 +0100 Subject: quietly.... In-Reply-To: References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> Message-ID: On 2 feb 2011, at 12:39, Owen DeLong wrote: > I would point to 6to4 and the RAs coming from Windows Laptops that think they are routers because someone clicked on an ICS checkbox as a counter example that letting things that think they are routers announce their presence is, in fact, proof that it is not only possible that something goes wrong, but, commonplace. I didn't say they were necessarily good routers. The issue of rogue routers and DHCP servers is a separate one. Obviously if you have rogue RAs but no rogue DHCPv6 then it helps if you can ignore the RAs and put all the info in DHCPv6. But the same bad practices that created rogue RAs can just as easily create rogue DHCPv6 servers so this is not a real solution, just very limited managing of symptoms. But there's so much wrong with DHCPv6 that trying to fix it is pretty much useless, we need to abandon DHCP and start from scratch. Good thing IPv6 works just fine without DHCPv6. From brandon at rd.bbc.co.uk Wed Feb 2 06:54:23 2011 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Wed, 2 Feb 2011 12:54:23 GMT Subject: quietly.... Message-ID: <201102021254.MAA06459@sunf10.rd.bbc.co.uk> > Example: if you give administrators the option of putting a router > address in a DHCP option, they will do so and some fraction of the > time, this will be the wrong address and things don't work. They cause themselves a problem then they fix it. > If you let routers announce their presence, then it's virtually > impossible that something goes wrong s/impossible/certain > because routers know who they are It doesn't mean they're right. If I choose DHCP I've made the choice to define how this network works. I then want it to carry on like that, not depend on others not screwing up too. > A clear win. Of course it does mean that people have to > learn something new when adopting IPv6. It means all administrators now have to guard against trivial errors by all end users. Lot larger fail surface It's not about dislike of new, it's dislike of pointless risk brandon From the76posse at gmail.com Wed Feb 2 07:07:14 2011 From: the76posse at gmail.com (Steve Danelli) Date: Wed, 2 Feb 2011 08:07:14 -0500 Subject: Connectivity to Brazil In-Reply-To: References: <4F3DD62E-4007-4ED2-94D6-8405E1C1546E@gmail.com> <33104.1296591593@localhost> <80F3BEC5-89AA-4D54-95EA-976AC3292E60@gmail.com> Message-ID: <267BE993-2BBF-4392-A588-60D087269A86@gmail.com> That thread detail would be very interesting to me. Thanks for the heads up. Sent from my iPhone On Feb 2, 2011, at 7:14 AM, Matt Disuko wrote: > Very interesting. I have had similar issues with connectivity to my Brazil office, and oddly enough it involved GBLX and CTBC (now called Algar Telecom). I also vastly divergent paths to a couple hosts in the same subnet. I ended up communicating with GBLX via email (who were actually really great in corresponding with me)...the engineer pointed to some sort of link capacity issue...i'll dig up the thread... > > > Date: Wed, 2 Feb 2011 01:21:09 -0500 > > From: vinny at abellohome.net > > Subject: Re: Connectivity to Brazil > > To: the76posse at gmail.com > > CC: nanog at nanog.org > > > > We saw similar issues with IKE through Global Crossing (as odd as that sounds) out of the NYC market at the same time. We routed around them and problem solved. Still scratching our heads on that one... In my experiences, GLBX has numerous odd issues to the point where it's become a bad joke anytime something breaks with connectivity... we blame them. It's kind of not funny though because it's almost always true. Taking them out of the equation usually fixes the problem. One of our customers who is frequently affected by GBLX problems jumps to the (often correct) conclusion that they are causing problems. :-/ > > > > -Vinny > > > > On Feb 1, 2011, at 3:57 PM, Steve Danelli wrote: > > > > > Thanks for the response. > > > > > > Ike had worked great up until Monday. The provider did a local test and our box saw the Ike packets so it appears to lie somewhere upstream. (GLBX may be a good guess) > > > > > > Also - the paths are stable and we are sourcing from the same ip - very strange behaivor. Hope someone from GLBX or CTBC (or someone who had experienced an issue like this) can assist > > > > > > > > > Thanks to all for their feedback so far. > > > > > > SD > > > > > > On Feb 1, 2011, at 3:19 PM, Valdis.Kletnieks at vt.edu wrote: > > > > > >> On Tue, 01 Feb 2011 08:54:47 EST, Steve Danelli said: > > >> > > >>> Some carrier, somewhere between us and the service provider is selectively > > >>> dropping the IKE packets originating from our VPN gateway and destined for > > >>> our Brazil gateway. Other traffic is able to pass, as are the IKE packets coming > > >>> back from Brazil to us. This is effectively preventing us from establishing > > >>> the IPSEC tunnel between our gateways. > > >> > > >> Has IKE been known to work to that location before? Or is this something new? > > >> My first guess is some chucklehead banana-eater at the service provider either > > >> fat-fingered the firewall config, or semi-intentionally blocked it because it > > >> was "traffic on a protocol/port number they didn't understand so it must be > > >> evil". > > >> > > >>> Also something else is awry, for two given hosts on the same subnet (x.y.z.52 > > >>> and x.y.z.53), they take two wildly divergent paths: > > >> > > >>> Anyone have any insight on to what may be occurring? > > >> > > >> The paths appear to diverge at 67.16.142.238. I wonder if that's gear trying > > >> to do some load-balancing across 2 paths, and it's using the source IP as a > > >> major part of the selector function ("route to round-robin interface source-IP > > >> mod N" or similar?). > > >> > > >> The other possibility is your two traceroutes happened to catch a routing flap in > > >> progress (obviously not the case if the two routes are remaining stable). > > >> > > >> Sorry I can't be more helpful than that... > > > > > > > From nick at foobar.org Wed Feb 2 07:03:25 2011 From: nick at foobar.org (Nick Hilliard) Date: Wed, 02 Feb 2011 13:03:25 +0000 Subject: quietly.... In-Reply-To: References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> Message-ID: <4D49561D.3050209@foobar.org> On 02/02/2011 12:50, Iljitsch van Beijnum wrote: > But there's so much wrong with DHCPv6 that trying to fix it is pretty > much useless, we need to abandon DHCP and start from scratch. Good thing > IPv6 works just fine without DHCPv6. I rest my case. Nick From the76posse at gmail.com Wed Feb 2 07:08:50 2011 From: the76posse at gmail.com (Steve Danelli) Date: Wed, 2 Feb 2011 08:08:50 -0500 Subject: Connectivity to Brazil In-Reply-To: References: <4F3DD62E-4007-4ED2-94D6-8405E1C1546E@gmail.com> <33104.1296591593@localhost> <80F3BEC5-89AA-4D54-95EA-976AC3292E60@gmail.com> Message-ID: Thanks Vinny - how did you route around? There seems to be one path from the US to Brazil via GBLX and CTBC. Are you leveraging leased connectivity? Thanks for the info!! SD Sent from my iPhone On Feb 2, 2011, at 1:21 AM, Vinny Abello wrote: > We saw similar issues with IKE through Global Crossing (as odd as that sounds) out of the NYC market at the same time. We routed around them and problem solved. Still scratching our heads on that one... In my experiences, GLBX has numerous odd issues to the point where it's become a bad joke anytime something breaks with connectivity... we blame them. It's kind of not funny though because it's almost always true. Taking them out of the equation usually fixes the problem. One of our customers who is frequently affected by GBLX problems jumps to the (often correct) conclusion that they are causing problems. :-/ > > -Vinny > > On Feb 1, 2011, at 3:57 PM, Steve Danelli wrote: > >> Thanks for the response. >> >> Ike had worked great up until Monday. The provider did a local test and our box saw the Ike packets so it appears to lie somewhere upstream. (GLBX may be a good guess) >> >> Also - the paths are stable and we are sourcing from the same ip - very strange behaivor. Hope someone from GLBX or CTBC (or someone who had experienced an issue like this) can assist >> >> >> Thanks to all for their feedback so far. >> >> SD >> >> On Feb 1, 2011, at 3:19 PM, Valdis.Kletnieks at vt.edu wrote: >> >>> On Tue, 01 Feb 2011 08:54:47 EST, Steve Danelli said: >>> >>>> Some carrier, somewhere between us and the service provider is selectively >>>> dropping the IKE packets originating from our VPN gateway and destined for >>>> our Brazil gateway. Other traffic is able to pass, as are the IKE packets coming >>>> back from Brazil to us. This is effectively preventing us from establishing >>>> the IPSEC tunnel between our gateways. >>> >>> Has IKE been known to work to that location before? Or is this something new? >>> My first guess is some chucklehead banana-eater at the service provider either >>> fat-fingered the firewall config, or semi-intentionally blocked it because it >>> was "traffic on a protocol/port number they didn't understand so it must be >>> evil". >>> >>>> Also something else is awry, for two given hosts on the same subnet (x.y.z.52 >>>> and x.y.z.53), they take two wildly divergent paths: >>> >>>> Anyone have any insight on to what may be occurring? >>> >>> The paths appear to diverge at 67.16.142.238. I wonder if that's gear trying >>> to do some load-balancing across 2 paths, and it's using the source IP as a >>> major part of the selector function ("route to round-robin interface source-IP >>> mod N" or similar?). >>> >>> The other possibility is your two traceroutes happened to catch a routing flap in >>> progress (obviously not the case if the two routes are remaining stable). >>> >>> Sorry I can't be more helpful than that... >> > From jamie at photon.com Wed Feb 2 07:11:57 2011 From: jamie at photon.com (Jamie Bowden) Date: Wed, 2 Feb 2011 08:11:57 -0500 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <20110201233846.GV13890@angus.ind.WPI.EDU> References: <1296089078.6522.194.camel@karl><5D2659F3-5853-4C1C-A26D-D6EB5AA75195@delong.com><4D4820E1.20600@brightok.net><077208EB-39DF-4F51-B263-E1BEB0BCE75A@delong.com><4D48454A.1090807@brightok.net><4D488FF8.4010106@brightok.net><8998E21B-14FB-45A8-A849-D1416E946505@delong.com> <20110201233846.GV13890@angus.ind.WPI.EDU> Message-ID: <5C836A1A98186142A6BEC393FD5E2A8601578D@hal.photon.com> Our classified networks aren't ever going to be connected to anything but themselves either, and they need sane local addressing. Some of them are a single room with a few machines, some of them are entire facilities with hundreds of machines, but none of them are going to be talking to a router or anything upstream, as neither of those exist on said networks. Jamie -----Original Message----- From: Chuck Anderson [mailto:cra at WPI.EDU] Sent: Tuesday, February 01, 2011 6:39 PM To: nanog at nanog.org Subject: Re: Using IPv6 with prefixes shorter than a /64 on a LAN On Tue, Feb 01, 2011 at 03:14:57PM -0800, Owen DeLong wrote: > On Feb 1, 2011, at 2:58 PM, Jack Bates wrote: > > There are many cases where ULA is a perfect fit, and to work > > around it seems silly and reduces the full capabilities of IPv6. I > > fully expect to see protocols and networks within homes which will > > take full advantage of ULA. I also expect to see hosts which don't > > talk to the public internet directly and never need a GUA. > > > I guess we can agree to disagree about this. I haven't seen one yet. What would your recommended solution be then for disconnected networks? Every home user and enterprise user requests GUA directly from their RIR/NIR/LIR at a cost of hunderds of dollars per year or more? From owen at delong.com Wed Feb 2 07:10:20 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 2 Feb 2011 05:10:20 -0800 Subject: quietly.... In-Reply-To: References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> Message-ID: On Feb 2, 2011, at 4:50 AM, Iljitsch van Beijnum wrote: > On 2 feb 2011, at 12:39, Owen DeLong wrote: > >> I would point to 6to4 and the RAs coming from Windows Laptops that think they are routers because someone clicked on an ICS checkbox as a counter example that letting things that think they are routers announce their presence is, in fact, proof that it is not only possible that something goes wrong, but, commonplace. > > I didn't say they were necessarily good routers. > No, you said the router always knows better than the DHCP server. This is an example of a common case where it does not. > The issue of rogue routers and DHCP servers is a separate one. Obviously if you have rogue RAs but no rogue DHCPv6 then it helps if you can ignore the RAs and put all the info in DHCPv6. But the same bad practices that created rogue RAs can just as easily create rogue DHCPv6 servers so this is not a real solution, just very limited managing of symptoms. > It really isn't. If the DHCP server on a subnet could override the rogue routers RA messages by policy, then, it would actually make it fairly trivial to address this issue. Unfortunately because administrators don't have that option, we're stuck. > But there's so much wrong with DHCPv6 that trying to fix it is pretty much useless, we need to abandon DHCP and start from scratch. Good thing IPv6 works just fine without DHCPv6. This is a clear example of the myopia in the IETF that has operators so frustrated. Owen From tme at americafree.tv Wed Feb 2 07:25:42 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Wed, 2 Feb 2011 08:25:42 -0500 Subject: Connectivity status for Egypt In-Reply-To: References: <33496563.960.1296250642067.JavaMail.franck@franck-martins-macbook-pro.local> <5EEA5622-9EDA-4FD6-B4BE-F4E2C812A271@americafree.tv> <86D21E41-69F3-4F3C-994F-BBED3619E5DC@americafree.tv> Message-ID: On Feb 2, 2011, at 6:23 AM, Jim Cowie wrote: > > > On Wed, Feb 2, 2011 at 6:17 AM, Teo Ruiz wrote: > On Tue, Feb 1, 2011 at 21:30, Marshall Eubanks wrote: > > On Jan 31, 2011, at 5:14 PM, Marshall Eubanks wrote: > > > >> As an update, BGP for Noor.net has been withdrawn. Even the Egyptian stock exchange - egyptse.com - now appears to be off the Internet. > > > > I have been told that the Egyptian Prime Minister has publicly announced that the Internet would be restored soon, but at present neither my > > Looks like it's coming back: http://stat.ripe.net/egypt > > ~2500 prefixes being announced now. > -- > teo - http://www.teoruiz.com > > "Res publica non dominetur" > > Yes, confirmed from 09:29 UTC. Basically all major providers are back, full status quo ante (modulo reagg), major sites are up. > > http://www.renesys.com/blog/2011/02/egypt-returns-to-the-internet.shtml It's not just BGP - DNS (based on the samples I have been testing) seems to be fully back too. Regards Marshall > > Good thoughts go out to the guys in the EG NOCs this morning. Nanog wants to hear your war stories some day over a cup of tea. > > --jim > From the76posse at gmail.com Wed Feb 2 07:27:04 2011 From: the76posse at gmail.com (Steve Danelli) Date: Wed, 2 Feb 2011 08:27:04 -0500 Subject: Bovespa In-Reply-To: <173163.67681.qm@web30807.mail.mud.yahoo.com> References: <173163.67681.qm@web30807.mail.mud.yahoo.com> Message-ID: <2307EDF6-5DCA-4A99-A2A0-193DB7ECC40C@gmail.com> Where are you connecting from? Sent from my iPhone On Feb 1, 2011, at 11:22 PM, Philip Lavine wrote: > 1. Does anyone know where the Bovespa is located and if colocation is a > possibility at that datacenter/s. > 2. What is a good Internet (DS3? or ethernet) carrier in Sao Paolo > > > thank you > > Philip > > > > From rubensk at gmail.com Wed Feb 2 07:48:51 2011 From: rubensk at gmail.com (Rubens Kuhl) Date: Wed, 2 Feb 2011 11:48:51 -0200 Subject: Bovespa In-Reply-To: <173163.67681.qm@web30807.mail.mud.yahoo.com> References: <173163.67681.qm@web30807.mail.mud.yahoo.com> Message-ID: On Wed, Feb 2, 2011 at 2:22 AM, Philip Lavine wrote: > 1. Does anyone know where the Bovespa is located and if colocation is a > possibility at that datacenter/s. Sao Paulo downtown, although it is unclear at this time if it will stay there or not. They do not provide colocation at their datacenter, but there is one a few steps from it, Alog. (http://www.alog.com.br). Other SP metro area datacenters include Locaweb (http://www.locaweb.com.br), UOL Host (http://www.uolhost.com.br) and Global Crossing. UOL Host newest facility is also at downtown. Bovespa recently chose Diveo (http://www.diveo.com, acquired by UOL Host) for their contingency site, located about 30 km from Bovespa current location. > 2. What is?a good?Internet (DS3? or ethernet)?carrier in Sao Paolo Ethernet carriers are prevalent in Sao Paulo. My first pick is AES Atimus (http://www.aesatimus.com.br). Algar (http://www.algartelecom.com.br), Global Crossing coming second; you can also lease Internet capacity from the datacenter you end up colocating at, usually with good prices and quality. Rubens From rubensk at gmail.com Wed Feb 2 08:15:05 2011 From: rubensk at gmail.com (Rubens Kuhl) Date: Wed, 2 Feb 2011 12:15:05 -0200 Subject: Connectivity to Brazil In-Reply-To: References: <4F3DD62E-4007-4ED2-94D6-8405E1C1546E@gmail.com> <33104.1296591593@localhost> <80F3BEC5-89AA-4D54-95EA-976AC3292E60@gmail.com> Message-ID: CTBC has capacity from GBLX, TIWS and SEABONE, although not all prefixes are announced to all providers. TIWS usual path in the US is thru Level 3, so steering the traffic to Level 3 might do the trick. Rubens On Wed, Feb 2, 2011 at 11:08 AM, Steve Danelli wrote: > Thanks Vinny - how did you route around? ? There seems to be one path from the US to Brazil via GBLX and CTBC. ? ?Are you leveraging leased connectivity? ? Thanks for the info!! > > SD > > Sent from my iPhone > > On Feb 2, 2011, at 1:21 AM, Vinny Abello wrote: > >> We saw similar issues with IKE through Global Crossing (as odd as that sounds) out of the NYC market at the same time. We routed around them and problem solved. Still scratching our heads on that one... In my experiences, GLBX has numerous odd issues to the point where it's become a bad joke anytime something breaks with connectivity... we blame them. It's kind of not funny though because it's almost always true. Taking them out of the equation usually fixes the problem. One of our customers who is frequently affected by GBLX problems jumps to the (often correct) conclusion that they are causing problems. :-/ >> >> -Vinny >> >> On Feb 1, 2011, at 3:57 PM, Steve Danelli wrote: >> >>> Thanks for the response. >>> >>> Ike had worked great up until Monday. ?The provider did a local test and our box saw the Ike packets so it appears to lie somewhere upstream. ?(GLBX may be a good guess) >>> >>> Also - the paths are stable and we are sourcing from the same ip - very strange behaivor. ? ?Hope someone from GLBX or CTBC (or someone who had experienced an issue like this) can assist >>> >>> >>> Thanks to all for their feedback so far. >>> >>> SD >>> >>> On Feb 1, 2011, at 3:19 PM, Valdis.Kletnieks at vt.edu wrote: >>> >>>> On Tue, 01 Feb 2011 08:54:47 EST, Steve Danelli said: >>>> >>>>> Some carrier, somewhere between us and the service provider is selectively >>>>> dropping the IKE packets originating from our VPN gateway and destined for >>>>> our Brazil gateway. Other traffic is able to pass, as are the IKE packets coming >>>>> back from Brazil to us. This is effectively preventing us from establishing >>>>> the IPSEC tunnel between our gateways. >>>> >>>> Has IKE been known to work to that location before? Or is this something new? >>>> My first guess is some chucklehead banana-eater at the service provider either >>>> fat-fingered the firewall config, or semi-intentionally blocked it because it >>>> was "traffic on a protocol/port number they didn't understand so it must be >>>> evil". >>>> >>>>> Also something else is awry, for two given hosts on the same subnet (x.y.z.52 >>>>> and x.y.z.53), they take two wildly divergent paths: >>>> >>>>> Anyone have any insight on to what may be occurring? >>>> >>>> The paths appear to diverge at 67.16.142.238. ?I wonder if that's gear trying >>>> to do some load-balancing across 2 paths, and it's using the source IP as a >>>> major part of the selector function ("route to round-robin interface source-IP >>>> mod N" or similar?). >>>> >>>> The other possibility is your two traceroutes happened to catch a routing flap in >>>> progress (obviously not the case if the two routes are remaining stable). >>>> >>>> Sorry I can't be more helpful than that... >>> >> > > From ml at kenweb.org Wed Feb 2 08:15:34 2011 From: ml at kenweb.org (ML) Date: Wed, 02 Feb 2011 09:15:34 -0500 Subject: Strange L2 failure In-Reply-To: <4D44D596.3070707@brightok.net> References: <4D4485A6.3040203@brightok.net> <4D44D15C.90106@kenweb.org> <4D44D596.3070707@brightok.net> Message-ID: <4D496706.8040600@kenweb.org> On 1/29/2011 10:05 PM, Jack Bates wrote: > On 1/29/2011 8:47 PM, ML wrote: >> I just ran into something like this yesterday. A Belkin router with a >> MAC of 9444.52dc.XXXX was properly learned at the IDF switch but the >> upstream agg switch/router wouldn't learn it. I even tried to static >> the MAC into the CAM..router refused. > > That's what really tripped me out, was that the router actually did > place an ARP entry and pretended like everything should be working. > Scheduling some more direct tests with packet sniffers next week when I > get back in the office. > > I'm curious now if IOS has the issue or the line card, so we'll test off > different cards direct and monitor results. > > Jack > Turns out I ran out of space in the CAM..embarrassing. What didn't happen was frame flooding. Since this device was part of the ME34xx product line I'd wager Cisco thought it better to drop frames than leak data. I upgraded the IOS to 12.2(50)SE5 from 12.2(25)SEG. Somehow there is more space in the TCAM for unicast MACs between software versions. From iljitsch at muada.com Wed Feb 2 08:17:14 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 2 Feb 2011 15:17:14 +0100 Subject: quietly.... In-Reply-To: References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> Message-ID: On 2 feb 2011, at 14:10, Owen DeLong wrote: >> I didn't say they were necessarily good routers. > No, you said the router always knows better than the DHCP server. This is an example of a common case where > it does not. If someone turns their box into a router they can also turn it into a DHCP server. This is what happens with IPv4. The solution is to filter these packets from fake routers in the switches. So ask your switch vendor for that feature in IPv6. > It really isn't. If the DHCP server on a subnet could override the rogue routers RA messages by policy, then, it would actually make it fairly trivial to address this issue. And who overrides the rogue DHCPv6 messages? Or is it turtles all the way down? >> But there's so much wrong with DHCPv6 that trying to fix it is pretty much useless, we need to abandon DHCP and start from scratch. Good thing IPv6 works just fine without DHCPv6. > This is a clear example of the myopia in the IETF that has operators so frustrated. I can assure you that I'm quite alone within the IETF with that view. I'm not talking about the interaction between DHCPv6 and RAs here, just about how bad DHCPv6 is on its own terms. For instance, there's no client identifier or using MAC addresses to identify clients, this is now done with a DUID. Unfortunately, administrators have no way of knowing what DUID a given client is going to use so having a DHCPv6 server set up with information tailored to a specific client is really hard. There's also stateful and stateless DHCPv6, but it's the client that has to choose between them, while the server knows whether it's going to return stateful or stateless information. There's no prefix length in DHCPv6, so this needs to be learned from RAs. (Although it can be argued that because routers need to know this info anyway, having the prefix length there doesn't buy you anything.) The problem with DHCP in general is that there is a continuous influx of new options but they all need to be encoded into a binary format inside a small packet. This info should be in an XML file on a HTTP server instead, rather than be overloaded into the connectivity bootstrapping. The problem with RA / DHCP is that RAs were built with some vague notion of what DHCP would do some day and then when DHCPv6 was developed half a decade later the evolving ideas didn't fit with the shape of the hole left in RAs anymore but that problem wasn't addressed at this time. Fixing that now (hopefully fixing it well, not doing stupid things like making DHCPv6 an IPv4 DHCP clone with all the IPv4 DHCP problems that we all suffer every day) means that we'll end up with three types of systems: - no DHCPv6 - legacy DHCPv6 - new DHCPv6 Good luck trying to come up with a combination of RA and DHCP settings that make all three work well. Even without new DHCPv6, there's already 12 ways to set up RAs and DHCP and only a few combinations produce useful results. From vixie at isc.org Wed Feb 2 08:20:08 2011 From: vixie at isc.org (Paul Vixie) Date: Wed, 02 Feb 2011 14:20:08 +0000 Subject: Verizon acquiring Terremark In-Reply-To: Your message of "Wed, 02 Feb 2011 03:22:39 EST." References: <6EFFEFBAC68377459A2E972105C759EC03539A93@EXVBE005-2.exch005intermedia.net> <2838.1296628687@nsa.vix.com> Message-ID: <27665.1296656408@nsa.vix.com> > Date: Wed, 2 Feb 2011 03:22:39 -0500 > From: Jeffrey Lyon > > I'm sure everything will be fine in practice as others have indicated, > I was merely making a point of the inherent conflict of interest. ah. if you mean "it's unusual" or "it's difficult" rather than "it cannot be" then i have no arguments. the reason PAIX got traction at all, coming late to the game (1995-ish) as we did, was because MFS was then able to charge circuit prices for many forms of cross connect down at MAE West. and i did face continuous pressure from MFN to go after a share of PAIX's carrier's circuit revenue. (which i never did and which none of my successors have done either.) noting, the game as moved on. if verizon behaves badly as terremark's owner then the presence of equinix in the market will act as a relief valve. i think the "neutral and commercial" model is very well established and that verizon will not want to be the only carrier in those facilities nor have their circuit-holders be the only customers for the real estate. it's an awful lot of space to use just as colo, and it's both over- and underbuilt for colo (vs. an IX). re: > On Wed, Feb 2, 2011 at 1:38 AM, Paul Vixie wrote: > > Jeffrey Lyon writes: > > > >> One cannot be owned by a carrier and remain carrier neutral. > >> > >> My two cents, > > > > my experience running PAIX when it was owned by MFN was not > > like you're saying. From labovit at gmail.com Wed Feb 2 08:21:32 2011 From: labovit at gmail.com (Craig Labovitz) Date: Wed, 2 Feb 2011 09:21:32 -0500 Subject: Connectivity status for Egypt In-Reply-To: References: <33496563.960.1296250642067.JavaMail.franck@franck-martins-macbook-pro.local> <5EEA5622-9EDA-4FD6-B4BE-F4E2C812A271@americafree.tv> <86D21E41-69F3-4F3C-994F-BBED3619E5DC@americafree.tv> Message-ID: <64E09509-49CE-4692-B02A-712616B94CFF@gmail.com> Good to see the traffic back. Graphs visualizing return of Egyptian traffic volumes below. Week view: http://www.monkey.org/~labovit/egypt_back_week.png Today: http://www.monkey.org/~labovit/egypt_returns.png - Craig ------------------------ Craig Labovitz | Chief Scientist, Arbor Networks | http://www.monkey.org/~labovit On Feb 2, 2011, at 8:25 AM, Marshall Eubanks wrote: > It's not just BGP - DNS (based on the samples I have been testing) seems to be fully back too. > > Regards > Marshall From dot at dotat.at Wed Feb 2 08:22:31 2011 From: dot at dotat.at (Tony Finch) Date: Wed, 2 Feb 2011 14:22:31 +0000 Subject: quietly.... In-Reply-To: <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> Message-ID: On Wed, 2 Feb 2011, Iljitsch van Beijnum wrote: > > Example: if you give administrators the option of putting a router > address in a DHCP option, they will do so and some fraction of the time, > this will be the wrong address and things don't work. If you let routers > announce their presence, then it's virtually impossible that something > goes wrong because routers know who they are. A clear win. Counterexample: rogue RAs from Windows boxes running 6to4 or Teredo and Internet Connection Sharing. This is a lot harder to fix than a misconfigured DHCP server. http://malc.org.uk/6doom Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. From gourmetcisco at hotmail.com Wed Feb 2 08:22:59 2011 From: gourmetcisco at hotmail.com (Matt Disuko) Date: Wed, 2 Feb 2011 09:22:59 -0500 Subject: Connectivity to Brazil Message-ID: Algar looking Glass: http://lg.ctbc.com.br/lg/ I found the response from the GC engineer. It won't mean much cut&pasted verbatim and out of context, so I'll just summarize. Basically, I was seeing vastly different response times to given hosts in the same subnet on CTBC's network. My source ip was the same. Traceroute revealed to me the packets taking different paths, after hitting a particular GLBX router. The GC engineer said CTBC is a customer that hangs off of this particular router, and that traffic was hitting an interface and hair-pinning back out to the customer's segment. He pointed to possible congestion on CTBCs switching fabric as the cause for the varied response times (conceivable) and different routes (um...ok maybe some kind of load-balancing at play). I managed to call CTBC (Algar) and confirmed they were experiencing congestion issues and they had a scheduled circuit capacity upgrade with GLBX in a few weeks. As a network admin, i find it sometimes sadly humorous how we can poke and prod at a problem, go through various carrier support channels and scratch our heads for hours/days when all it would normally take is a RO userid on a couple routers in the path to figure things out. that's not too much to ask, right? ;) -matt > CC: vinny at abellohome.net; nanog at nanog.org > From: the76posse at gmail.com > Subject: Re: Connectivity to Brazil > Date: Wed, 2 Feb 2011 08:07:14 -0500 > To: gourmetcisco at hotmail.com > > That thread detail would be very interesting to me. Thanks for the heads up. > > Sent from my iPhone > > On Feb 2, 2011, at 7:14 AM, Matt Disuko wrote: > > > Very interesting. I have had similar issues with connectivity to my Brazil office, and oddly enough it involved GBLX and CTBC (now called Algar Telecom). I also vastly divergent paths to a couple hosts in the same subnet. I ended up communicating with GBLX via email (who were actually really great in corresponding with me)...the engineer pointed to some sort of link capacity issue...i'll dig up the thread... > > > > > Date: Wed, 2 Feb 2011 01:21:09 -0500 > > > From: vinny at abellohome.net > > > Subject: Re: Connectivity to Brazil > > > To: the76posse at gmail.com > > > CC: nanog at nanog.org > > > > > > We saw similar issues with IKE through Global Crossing (as odd as that sounds) out of the NYC market at the same time. We routed around them and problem solved. Still scratching our heads on that one... In my experiences, GLBX has numerous odd issues to the point where it's become a bad joke anytime something breaks with connectivity... we blame them. It's kind of not funny though because it's almost always true. Taking them out of the equation usually fixes the problem. One of our customers who is frequently affected by GBLX problems jumps to the (often correct) conclusion that they are causing problems. :-/ > > > > > > -Vinny > > > > > > On Feb 1, 2011, at 3:57 PM, Steve Danelli wrote: > > > > > > > Thanks for the response. > > > > > > > > Ike had worked great up until Monday. The provider did a local test and our box saw the Ike packets so it appears to lie somewhere upstream. (GLBX may be a good guess) > > > > > > > > Also - the paths are stable and we are sourcing from the same ip - very strange behaivor. Hope someone from GLBX or CTBC (or someone who had experienced an issue like this) can assist > > > > > > > > > > > > Thanks to all for their feedback so far. > > > > > > > > SD > > > > > > > > On Feb 1, 2011, at 3:19 PM, Valdis.Kletnieks at vt.edu wrote: > > > > > > > >> On Tue, 01 Feb 2011 08:54:47 EST, Steve Danelli said: > > > >> > > > >>> Some carrier, somewhere between us and the service provider is selectively > > > >>> dropping the IKE packets originating from our VPN gateway and destined for > > > >>> our Brazil gateway. Other traffic is able to pass, as are the IKE packets coming > > > >>> back from Brazil to us. This is effectively preventing us from establishing > > > >>> the IPSEC tunnel between our gateways. > > > >> > > > >> Has IKE been known to work to that location before? Or is this something new? > > > >> My first guess is some chucklehead banana-eater at the service provider either > > > >> fat-fingered the firewall config, or semi-intentionally blocked it because it > > > >> was "traffic on a protocol/port number they didn't understand so it must be > > > >> evil". > > > >> > > > >>> Also something else is awry, for two given hosts on the same subnet (x.y.z.52 > > > >>> and x.y.z.53), they take two wildly divergent paths: > > > >> > > > >>> Anyone have any insight on to what may be occurring? > > > >> > > > >> The paths appear to diverge at 67.16.142.238. I wonder if that's gear trying > > > >> to do some load-balancing across 2 paths, and it's using the source IP as a > > > >> major part of the selector function ("route to round-robin interface source-IP > > > >> mod N" or similar?). > > > >> > > > >> The other possibility is your two traceroutes happened to catch a routing flap in > > > >> progress (obviously not the case if the two routes are remaining stable). > > > >> > > > >> Sorry I can't be more helpful than that... > > > > > > > > > > From dot at dotat.at Wed Feb 2 08:25:06 2011 From: dot at dotat.at (Tony Finch) Date: Wed, 2 Feb 2011 14:25:06 +0000 Subject: quietly.... In-Reply-To: References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> Message-ID: On Wed, 2 Feb 2011, Iljitsch van Beijnum wrote: > > But there's so much wrong with DHCPv6 that trying to fix it is pretty > much useless, we need to abandon DHCP and start from scratch. Good thing > IPv6 works just fine without DHCPv6. Yeah, no-one needs to dynamically find out their local recursive name server or NTP server or network boot server. Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. From jbates at brightok.net Wed Feb 2 08:25:30 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 02 Feb 2011 08:25:30 -0600 Subject: quietly.... In-Reply-To: <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> Message-ID: <4D49695A.7050305@brightok.net> On 2/2/2011 2:16 AM, Iljitsch van Beijnum wrote: > If you let routers announce their presence, then it's virtually > impossible that something goes wrong because routers know who they > are. A clear win. Of course it does mean that people have to > learn something new when adopting IPv6. Unfortunately, a PE router with large numbers of interfaces will have to duplicate the announcement periodically across every interface. The win isn't so clear. Jack From jbates at brightok.net Wed Feb 2 08:43:23 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 02 Feb 2011 08:43:23 -0600 Subject: quietly.... In-Reply-To: References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> Message-ID: <4D496D8B.7020601@brightok.net> On 2/2/2011 8:22 AM, Tony Finch wrote: > Counterexample: rogue RAs from Windows boxes running 6to4 or Teredo and > Internet Connection Sharing. This is a lot harder to fix than a > misconfigured DHCP server. CounterCounterexample: rogue DHCPv6 servers from windows boxes or improperly connected CPEs. Both DHCP(4 or 6) and RA require careful filtering to keep rogues from jacking things up. Though M$ has a nice deployment for authorizing DHCP4 servers in corporate environments. Jack From cmadams at hiwaay.net Wed Feb 2 08:49:57 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 2 Feb 2011 08:49:57 -0600 Subject: quietly.... In-Reply-To: References: <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> Message-ID: <20110202144957.GB26121@hiwaay.net> Once upon a time, Iljitsch van Beijnum said: > If someone turns their box into a router they can also turn it into a DHCP server. This is what happens with IPv4. The solution is to filter these packets from fake routers in the switches. So ask your switch vendor for that feature in IPv6. The difference is that in the widest-used desktop OS, "turn me into a router" is a single checkbox, while "turn me into a DHCP server" requires installing software. The first is an accident waiting to happen (and then a support nightmare), while the second is not a common problem. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jml at packetpimp.org Wed Feb 2 08:54:17 2011 From: jml at packetpimp.org (Jason LeBlanc) Date: Wed, 02 Feb 2011 09:54:17 -0500 Subject: Verizon acquiring Terremark In-Reply-To: <27665.1296656408@nsa.vix.com> References: <6EFFEFBAC68377459A2E972105C759EC03539A93@EXVBE005-2.exch005intermedia.net> <2838.1296628687@nsa.vix.com> <27665.1296656408@nsa.vix.com> Message-ID: <4D497019.7030808@packetpimp.org> I wonder if the price point will change. Having been in PAIX/S&D/Equinix facilities for several years things have certainly changed with regard to contract negotiations and pricing. Equinix is not very flexible. The shuffle of techs has also resulted in a much less helpful group to work with. On 02/02/2011 09:20 AM, Paul Vixie wrote: >> Date: Wed, 2 Feb 2011 03:22:39 -0500 >> From: Jeffrey Lyon >> >> I'm sure everything will be fine in practice as others have indicated, >> I was merely making a point of the inherent conflict of interest. > ah. if you mean "it's unusual" or "it's difficult" rather than "it > cannot be" then i have no arguments. the reason PAIX got traction > at all, coming late to the game (1995-ish) as we did, was because MFS > was then able to charge circuit prices for many forms of cross connect > down at MAE West. and i did face continuous pressure from MFN to go > after a share of PAIX's carrier's circuit revenue. (which i never did > and which none of my successors have done either.) > > noting, the game as moved on. if verizon behaves badly as terremark's > owner then the presence of equinix in the market will act as a relief > valve. i think the "neutral and commercial" model is very well > established and that verizon will not want to be the only carrier in > those facilities nor have their circuit-holders be the only customers > for the real estate. it's an awful lot of space to use just as colo, > and it's both over- and underbuilt for colo (vs. an IX). > > re: > >> On Wed, Feb 2, 2011 at 1:38 AM, Paul Vixie wrote: >>> Jeffrey Lyon writes: >>> >>>> One cannot be owned by a carrier and remain carrier neutral. >>>> >>>> My two cents, >>> my experience running PAIX when it was owned by MFN was not >>> like you're saying. From matt.addison at lists.evilgeni.us Wed Feb 2 08:57:37 2011 From: matt.addison at lists.evilgeni.us (Matt Addison) Date: Wed, 2 Feb 2011 09:57:37 -0500 Subject: quietly.... In-Reply-To: <20110202144957.GB26121@hiwaay.net> References: <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <20110202144957.GB26121@hiwaay.net> Message-ID: On Wed, Feb 2, 2011 at 09:49, Chris Adams wrote: > The difference is that in the widest-used desktop OS, "turn me into a > router" is a single checkbox, while "turn me into a DHCP server" > requires installing software. Turning on Internet Connection Sharing also (helpfully) enables and configures a DHCP server on the ICS host. ~Matt From owen at delong.com Wed Feb 2 09:00:44 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 2 Feb 2011 07:00:44 -0800 Subject: quietly.... In-Reply-To: References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> Message-ID: <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> On Feb 2, 2011, at 6:17 AM, Iljitsch van Beijnum wrote: > On 2 feb 2011, at 14:10, Owen DeLong wrote: > >>> I didn't say they were necessarily good routers. > >> No, you said the router always knows better than the DHCP server. This is an example of a common case where >> it does not. > > If someone turns their box into a router they can also turn it into a DHCP server. This is what happens with IPv4. The solution is to filter these packets from fake routers in the switches. So ask your switch vendor for that feature in IPv6. > Turns out that this is A LOT less common and when it does happen, it's easier to find and eliminate. >> It really isn't. If the DHCP server on a subnet could override the rogue routers RA messages by policy, then, it would actually make it fairly trivial to address this issue. > > And who overrides the rogue DHCPv6 messages? Or is it turtles all the way down? > Turns out to be quite a bit easier to isolate and remove the rogue DHCP server. Also turns out that there isn't a single-checkbox way to accidentally create a DHCP server, unlike a rogue RA. >>> But there's so much wrong with DHCPv6 that trying to fix it is pretty much useless, we need to abandon DHCP and start from scratch. Good thing IPv6 works just fine without DHCPv6. > >> This is a clear example of the myopia in the IETF that has operators so frustrated. > > I can assure you that I'm quite alone within the IETF with that view. > Then you have had impressive success at blocking useful development for a lone individual. > I'm not talking about the interaction between DHCPv6 and RAs here, just about how bad DHCPv6 is on its own terms. For instance, there's no client identifier or using MAC addresses to identify clients, this is now done with a DUID. Unfortunately, administrators have no way of knowing what DUID a given client is going to use so having a DHCPv6 server set up with information tailored to a specific client is really hard. There's also stateful and stateless DHCPv6, but it's the client that has to choose between them, while the server knows whether it's going to return stateful or stateless information. There's no prefix length in DHCPv6, so this needs to be learned from RAs. (Although it can be argued that because routers need to know this info anyway, having the prefix length there doesn't buy you anything.) > I agree that there is much that needs to be improved in DHCPv6. The lack of a default router, however, is the broken part that causes the most difficulty in modern operations. > The problem with DHCP in general is that there is a continuous influx of new options but they all need to be encoded into a binary format inside a small packet. This info should be in an XML file on a HTTP server instead, rather than be overloaded into the connectivity bootstrapping. The problem with RA / DHCP is that RAs were built with some vague notion of what DHCP would do some day and then when DHCPv6 was developed half a decade later the evolving ideas didn't fit with the shape of the hole left in RAs anymore but that problem wasn't addressed at this time. Fixing that now (hopefully fixing it well, not doing stupid things like making DHCPv6 an IPv4 DHCP clone with all the IPv4 DHCP problems that we all suffer every day) means that we'll end up with three types of systems: > We can agree to disagree about that. While it's true that there is a large number of options and the DHCP packet needs to remain relatively small, the reality is that no site uses all of them. They large number of options represents a superset of the differing needs of various sites. XML on HTTP is too much overhead for things a system needs to know at boot time to download its kernel. Operationally, DHCPv4 is just fine and is meeting the needs today. There's no reason we shouldn't have at least equivalent functionality in DHCPv6. > - no DHCPv6 > - legacy DHCPv6 > - new DHCPv6 > > Good luck trying to come up with a combination of RA and DHCP settings that make all three work well. Even without new DHCPv6, there's already 12 ways to set up RAs and DHCP and only a few combinations produce useful results. Yes... It really would be better if both SLAAC and DHCPv6 provided complete solutions and the operator could pick the single solution that worked best for them. Unfortunately, instead of looking at how things are used in the real world, IETF pursued some sort of theoretical purity exercise and we have two half-protocols that can't possibly provide a complete solution in either one. SLAAC fails because you can't get information about DNS, NTP, or anything other than a list of prefixes and a router that MIGHT actually be able to default-route your packets. DHCP fails because you can't get a default router out of it. Owen From owen at delong.com Wed Feb 2 09:04:13 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 2 Feb 2011 07:04:13 -0800 Subject: quietly.... In-Reply-To: <4D496D8B.7020601@brightok.net> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <4D496D8B.7020601@brightok.net> Message-ID: <56C77463-63CB-4304-9687-C53CC27D4065@delong.com> On Feb 2, 2011, at 6:43 AM, Jack Bates wrote: > > > On 2/2/2011 8:22 AM, Tony Finch wrote: >> Counterexample: rogue RAs from Windows boxes running 6to4 or Teredo and >> Internet Connection Sharing. This is a lot harder to fix than a >> misconfigured DHCP server. > > CounterCounterexample: rogue DHCPv6 servers from windows boxes or improperly connected CPEs. > > Both DHCP(4 or 6) and RA require careful filtering to keep rogues from jacking things up. Though M$ has a nice deployment for authorizing DHCP4 servers in corporate environments. > It's a lot easier to find and eliminate a rogue DHCP server than a rogue RA. Owen From kauer at biplane.com.au Wed Feb 2 09:19:57 2011 From: kauer at biplane.com.au (Karl Auer) Date: Thu, 03 Feb 2011 02:19:57 +1100 Subject: quietly.... In-Reply-To: <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> Message-ID: <1296659997.12449.240.camel@karl> On Wed, 2011-02-02 at 07:00 -0800, Owen DeLong wrote: > SLAAC fails because you can't get information about DNS, NTP, or > anything other than a list of prefixes and a router that MIGHT > actually be able to default-route your packets. > > DHCP fails because you can't get a default router out of it. That said, there appear to be efforts under way to add DNS server information to RA and to add a default router option to DHCPv6. Well, last time I looked, anyway... Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From iljitsch at muada.com Wed Feb 2 09:23:28 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 2 Feb 2011 16:23:28 +0100 Subject: quietly.... In-Reply-To: <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> Message-ID: <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> On 2 feb 2011, at 16:00, Owen DeLong wrote: > SLAAC fails because you can't get information about DNS, NTP, or anything other than a list of prefixes and a router that MIGHT actually be able to default-route your packets. Who ever puts NTP addresses in DHCP? That doesn't make any sense. I'd rather use a known NTP server that keeps correct time. For DNS in RA, see RFC 6106. But all of this could easily have been avoided: why are we _discovering_ DNS addresses in the first place? Simply host them on well known addresses and you can hardcode those addresses, similar to the 6to4 gateway address. But no, no rough consensus on something so simple. > DHCP fails because you can't get a default router out of it. If you consider that wrong, I don't want to be right. From james.cutler at consultant.com Wed Feb 2 09:27:53 2011 From: james.cutler at consultant.com (Cutler James R) Date: Wed, 2 Feb 2011 10:27:53 -0500 Subject: quietly.... In-Reply-To: <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> Message-ID: <178095B3-4238-40C7-85D1-CDFF5D7B895B@consultant.com> On Feb 2, 2011, at 10:23 AM, Iljitsch van Beijnum wrote: > Who ever puts NTP addresses in DHCP? That doesn't make any sense. I'd rather use a known NTP server that keeps correct time. Been there. Done that. Made perfect business sense. The NTP servers were ours and kept excellent time. Oh, we also included the default route. James R. Cutler james.cutler at consultant.com From jloiacon at csc.com Wed Feb 2 09:35:59 2011 From: jloiacon at csc.com (Joe Loiacono) Date: Wed, 2 Feb 2011 10:35:59 -0500 Subject: netflow analysis for jitter and packet loss? In-Reply-To: References: Message-ID: If you're considering actual 'netflow' data, I'm not really sure it will help with your requirements. The smallest unit is the 'flow' which could include many UDP packets and has only *flow* start and end times. Cisco's IP SLA might help. See: http://www.cisco.com/en/US/docs/ios/12_4/ip_sla/configuration/guide/hsjitter.html Joe From: Shacolby Jackson To: nanog at nanog.org Date: 02/01/2011 07:21 PM Subject: netflow analysis for jitter and packet loss? What tools are people most happy with? Specifically I'm hoping to mirror a port and later see if I can detect any inbound jitter or possibly even out of order udp datagrams. At first glance it doesn't look like ntop or plixer can provide that level of detail. Any suggestions? -shac From nanog at phaze.org Wed Feb 2 09:35:45 2011 From: nanog at phaze.org (Greg Estabrooks) Date: Wed, 02 Feb 2011 11:35:45 -0400 Subject: quietly.... In-Reply-To: <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> Message-ID: <4D4979D1.4000104@phaze.org> Hi, > But all of this could easily have been avoided: why are we _discovering_ DNS addresses in the first place? Simply host them on well known addresses and you can hardcode So, when I take my laptop from Home to work, to the airport, to some random cyber cafe I should have to manually alter my DNS servers assuming I can find someone in the location who can tell me what they are ?? Or let me guess, I should hardcode some public DNS servers which I can hopefully reach from where I am, hopefully is not down or having issues and hopefully I don't have poor latency to? And here I always thought the D in DHCP stood for Dynamic. From matt.addison at lists.evilgeni.us Wed Feb 2 09:41:35 2011 From: matt.addison at lists.evilgeni.us (Matt Addison) Date: Wed, 2 Feb 2011 10:41:35 -0500 Subject: quietly.... In-Reply-To: <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> Message-ID: On Wed, Feb 2, 2011 at 10:23, Iljitsch van Beijnum wrote: > But all of this could easily have been avoided: why are we _discovering_ > DNS addresses in the first place? Simply host them on well known addresses > and you can hardcode those addresses, similar to the 6to4 gateway address. > But no, no rough consensus on something so simple. > I'll admit right now that I don't know nearly enough about the IETF process, but it looks like there have been 2 separate attempts at this: draft-lee-dnsop-resolver-wellknown-ipv6addr - ID, expired draft-ohta-preconfigured-dns - ID, expired Until one of those is revived (or a similar draft is written), and makes it through IETF to reach RFC status, and there are assigned addresses from IANA, there are no well known addresses for anyone hardcode. ~Matt From jbates at brightok.net Wed Feb 2 09:42:55 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 02 Feb 2011 09:42:55 -0600 Subject: quietly.... In-Reply-To: <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> Message-ID: <4D497B7F.9050401@brightok.net> On 2/2/2011 9:23 AM, Iljitsch van Beijnum wrote: > Who ever puts NTP addresses in DHCP? That doesn't make any sense. I'd > rather use a known NTP server that keeps correct time. > Most corporate networks do, as it is more critical for the workstations to be in sync with the servers than to actually have the correct time. Though ideally, the servers have their time synced in one form or another. > But all of this could easily have been avoided: why are we > _discovering_ DNS addresses in the first place? Simply host them on > well known addresses and you can hardcode those addresses, similar > to the 6to4 gateway address. But no, no rough consensus on something > so simple. Administrative control. Utilizing well known addresses and anycasting DNS servers is considered a BAD thing. Anycasting in this way means you always use the nearest DNS server, which may NOT be the correct DNS server for your machine. >> DHCP fails because you can't get a default router out of it. > > If you consider that wrong, I don't want to be right. It is wrong in many situations. Case in point. As an ISP, RA does not gain me anything but increases router load and bandwidth utilization as it spits out to 3000+ interfaces periodically. Default Router in DHCPv6 reduces this load and traffic. Another case: What is the authentication model on RAs? M$ is very good at authenticating their DHCP servers to insure rogues don't interfere. Jack From iljitsch at muada.com Wed Feb 2 09:52:46 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 2 Feb 2011 16:52:46 +0100 Subject: quietly.... In-Reply-To: <4D4979D1.4000104@phaze.org> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <4D4979D1.4000104@phaze.org> Message-ID: <70C15FD9-CF85-4664-B913-3EBE4271C7F5@muada.com> On 2 feb 2011, at 16:35, Greg Estabrooks wrote: >> But all of this could easily have been avoided: why are we _discovering_ DNS addresses in the first place? Simply host them on well known addresses and you can hardcode > So, when I take my laptop from Home to work, to the airport, to some random cyber cafe I should have to manually alter my DNS servers assuming I can find someone in the location who can tell me what they are ?? No, the point is that DNS resolvers in different places all use the same addresses. So at the cyber cafe 3003::3003 is the cyber cafe DNS but at the airport 3003::3003 is the airport DNS. (Or in both cases, if they don't run a DNS server, one operated by their ISP.) I understand people use DHCP for lots of stuff today. But that's mainly because DHCP is there, not because it's the best possible way to get that particular job done. From sethm at rollernet.us Wed Feb 2 09:58:22 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 02 Feb 2011 07:58:22 -0800 Subject: quietly.... In-Reply-To: <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> Message-ID: <4D497F1E.4050100@rollernet.us> On 2/2/11 7:23 AM, Iljitsch van Beijnum wrote: > On 2 feb 2011, at 16:00, Owen DeLong wrote: > >> SLAAC fails because you can't get information about DNS, NTP, or anything other than a list of prefixes and a router that MIGHT actually be able to default-route your packets. > > Who ever puts NTP addresses in DHCP? That doesn't make any sense. I'd rather use a known NTP server that keeps correct time. > Me, because I have better things to do than to manually enter NTP servers (and other various boot settings) into all of my IP phones by hand. Configure DHCP, plug them in, and it just works. ~Seth From tim at pelican.org Wed Feb 2 09:59:37 2011 From: tim at pelican.org (Tim Franklin) Date: Wed, 2 Feb 2011 15:59:37 +0000 (GMT) Subject: quietly.... In-Reply-To: <32373432.01296662190908.JavaMail.root@jennyfur.pelican.org> Message-ID: <27601723.21296662377292.JavaMail.root@jennyfur.pelican.org> > So, when I take my laptop from Home to work, to the airport, to some > random cyber cafe I should have to manually alter my DNS servers > assuming I can find someone in the location who can tell me what they > are ?? Or let me guess, I should hardcode some public DNS servers > which I can hopefully reach from where I am, hopefully is not down or > having issues and hopefully I don't have poor latency to? You could always run your own recursive server on your laptop, instead of a stub, and remove your dependancy on anyone but the roots. *ducks* Regards, Tim. From tme at americafree.tv Wed Feb 2 10:08:58 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Wed, 2 Feb 2011 11:08:58 -0500 Subject: Fwd: Connectivity status for Egypt (update from Egypt) References: <16B49BAC3F8C7A43A0682EC3F96A5D7619AC41@XMB-AMS-201.cisco.com> Message-ID: Begin forwarded message: > From: "Ahmed Maged (amaged)" > Date: February 2, 2011 11:03:23 AM EST > To: > Subject: FW: Connectivity status for Egypt (update from Egypt) > > Please forward to nanog. > > -----Original Message----- > From: nanog-owner at nanog.org [mailto:nanog-owner at nanog.org] > Sent: Wednesday, February 02, 2011 04:50 PM W. Europe Standard Time > To: Ahmed Maged (amaged) > Subject: Re: Connectivity status for Egypt (update from Egypt) > > You are not allowed to post to this mailing list, and your message has > been automatically rejected. If you think that your messages are > being rejected in error, contact the mailing list owner at > nanog-owner at nanog.org. > > > > From: "Ahmed Maged (amaged)" > Date: February 2, 2011 10:51:08 AM EST > To: "Marshall Eubanks" , "Jim Cowie" > Cc: > Subject: Re: Connectivity status for Egypt (update from Egypt) > > > Hi Guys, > > I read most of the thread and I'll try to confirm what I can. > > Obviously, we are back online and yes it was decided by the government to > take the country offline. > > They first started blocking twitter and rate limited/blocked facebook but > later they just decided, everything must go. > > Two days ago, Google and Twitter came up with a way to help people tweet > using land lines. > > Some international WAN links are functioning and that's because of how the > switch was killed. International links go to the same place in either Cairo > or Alexandria (Telco Exchange). > > We do have a couple of IXs, but there is just no real interesting local > traffic, everyone wants facebook and twitter. Which is all international > > Everyone just stayed home because of Army imposed Curfew so the internet and > business was just on PAUSE and still is. > > Mobile phones were also off for two days but later they were brought back. > > The reason why they decided to do that is because the whole protest was > organized on Facebook initially, people agreed to go to Tahrir square > (liberation square) downtown together and a lot followed the groups > invitation. > > Later on, people joined despite all the attempts to block the internet and > communication. > > Some consider this act as a crime because they cut the tongues of people > this way and the government sees it as a step to stop the demonstrations. > > Huge businesses will be affected, one small example is international call > centers. > > You will all see clearly that we have bad bad aggregation, if you can > analyze this and write a note about it, I'll be able to pass it to the right > people when we get life back in order. > > In case things go bad again, we will really need international dial up so if > you can help setting this up, it will be appreciated. > > I have to go now to stand in front of my building to protect it (as > everyone) because thugs and thieves were let loose on the streets (by the > government). > > Regards, > Ahmed Maged > > > From: Marshall Eubanks > > Date: Wed, 2 Feb 2011 08:25:42 -0500 > > To: Jim Cowie > > Cc: > > Subject: Re: Connectivity status for Egypt > > > > > > On Feb 2, 2011, at 6:23 AM, Jim Cowie wrote: > > > >> > >> > >> On Wed, Feb 2, 2011 at 6:17 AM, Teo Ruiz wrote: > >> On Tue, Feb 1, 2011 at 21:30, Marshall Eubanks wrote: > >>> On Jan 31, 2011, at 5:14 PM, Marshall Eubanks wrote: > >>> > >>>> As an update, BGP for Noor.net has been withdrawn. Even the Egyptian stock > >>>> exchange - egyptse.com - now appears to be off the Internet. > >>> > >>> I have been told that the Egyptian Prime Minister has publicly announced > >>> that the Internet would be restored soon, but at present neither my > >> > >> Looks like it's coming back: http://stat.ripe.net/egypt > >> > >> ~2500 prefixes being announced now. > >> -- > >> teo - http://www.teoruiz.com > >> > >> "Res publica non dominetur" > >> > >> Yes, confirmed from 09:29 UTC. Basically all major providers are back, full > >> status quo ante (modulo reagg), major sites are up. > >> > >> http://www.renesys.com/blog/2011/02/egypt-returns-to-the-internet.shtml > > > > It's not just BGP - DNS (based on the samples I have been testing) seems to be > > fully back too. > > > > Regards > > Marshall > > > >> > >> Good thoughts go out to the guys in the EG NOCs this morning. Nanog wants > >> to hear your war stories some day over a cup of tea. > >> > >> --jim > >> > > > > > > > > > From dot at dotat.at Wed Feb 2 10:09:59 2011 From: dot at dotat.at (Tony Finch) Date: Wed, 2 Feb 2011 16:09:59 +0000 Subject: quietly.... In-Reply-To: <27601723.21296662377292.JavaMail.root@jennyfur.pelican.org> References: <27601723.21296662377292.JavaMail.root@jennyfur.pelican.org> Message-ID: On Wed, 2 Feb 2011, Tim Franklin wrote: > > You could always run your own recursive server on your laptop, instead > of a stub, and remove your dependancy on anyone but the roots. *ducks* Especially because this is the only secure way to do DNSSEC validation. Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. From jbates at brightok.net Wed Feb 2 10:13:24 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 02 Feb 2011 10:13:24 -0600 Subject: quietly.... In-Reply-To: <70C15FD9-CF85-4664-B913-3EBE4271C7F5@muada.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <4D4979D1.4000104@phaze.org> <70C15FD9-CF85-4664-B913-3EBE4271C7F5@muada.com> Message-ID: <4D4982A4.4030002@brightok.net> On 2/2/2011 9:52 AM, Iljitsch van Beijnum wrote: > I understand people use DHCP for lots of stuff today. But that's > mainly because DHCP is there, not because it's the best possible way > to get that particular job done. I don't disagree that an anycast well known address would be nice for say RA + SLAAC. However, DHCP has many uses and requirements. It has versatility that RA + SLAAC doesn't have, especially when dealing with policies for specific devices (which I understand DHCPv6 is missing some of this logic). This includes DNS servers. When I am connected to certain parts of our network, the DNS servers I receive are not the same as everyone around me. This applies to VPN connections as well (though I realize in VPN I could actually setup for the prefix to go via the VPN). DHCP is about giving hosts information based on policies. The simpler use of DHCP could easily be replaced, but the more common corporate uses cannot. Currently, much of the functionality of DHCP is not included in DHCPv6, which is a serious operations issue. Jack From davei at otd.com Wed Feb 2 10:14:04 2011 From: davei at otd.com (Dave Israel) Date: Wed, 02 Feb 2011 11:14:04 -0500 Subject: quietly.... In-Reply-To: <70C15FD9-CF85-4664-B913-3EBE4271C7F5@muada.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <4D4979D1.4000104@phaze.org> <70C15FD9-CF85-4664-B913-3EBE4271C7F5@muada.com> Message-ID: <4D4982CC.7060100@otd.com> On 2/2/2011 10:52 AM, Iljitsch van Beijnum wrote: > No, the point is that DNS resolvers in different places all use the same addresses. So at the cyber cafe 3003::3003 is the cyber cafe DNS but at the airport 3003::3003 is the airport DNS. (Or in both cases, if they don't run a DNS server, one operated by their ISP.) > > I understand people use DHCP for lots of stuff today. But that's mainly because DHCP is there, not because it's the best possible way to get that particular job done. So what if I want to assign different people to different resolvers by policy? What if I want to use non-/64 subnets with a resolver on each one? What if I round-robin amongst more or less resolvers than there are well-known addresses assigned to? What if, in 1/2/5/10/20/50 years, we need to do things differently? Why intentionally burden a protocol with something that screams "I am going to be a depreciated legacy problem someday!" -Dave From thegameiam at yahoo.com Wed Feb 2 10:14:58 2011 From: thegameiam at yahoo.com (David Barak) Date: Wed, 2 Feb 2011 08:14:58 -0800 (PST) Subject: quietly.... In-Reply-To: <70C15FD9-CF85-4664-B913-3EBE4271C7F5@muada.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <4D4979D1.4000104@phaze.org> <70C15FD9-CF85-4664-B913-3EBE4271C7F5@muada.com> Message-ID: <661120.5066.qm@web31810.mail.mud.yahoo.com> From: Iljitsch van Beijnum >I understand people use DHCP for lots of stuff today. But that's mainly because >DHCP is there, not because it's the best possible way >to get that particular >job done. I don't particularly care whether DHCP is the *best* way to get some particular job done; I care that it is a well-known, well-understood way of *getting* the job done, and lots of operational work, development, and process has gone into making DHCP do this well, reliably, and scalably.? The problem with DHCPv6 is that it doesn't do nearly enough when compared to DHCPv4, and there are not in fact any good alternatives.? The insistence on RA,?along with?a handwaving dismissal of all of those folks who have a high reliance on DHCP has done a tremendous disservice to the uptake of IPv6. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com From hag at linnaean.org Wed Feb 2 10:19:06 2011 From: hag at linnaean.org (Daniel Hagerty) Date: 02 Feb 2011 11:19:06 -0500 Subject: quietly.... In-Reply-To: Matt Addison's message of "Wed, 2 Feb 2011 10:41:35 -0500" References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> Message-ID: Matt Addison writes: > I'll admit right now that I don't know nearly enough about the IETF process, > but it looks like there have been 2 separate attempts at this: > draft-lee-dnsop-resolver-wellknown-ipv6addr - ID, expired > draft-ohta-preconfigured-dns - ID, expired > > Until one of those is revived (or a similar draft is written), and makes it > through IETF to reach RFC status, and there are assigned addresses from > IANA, there are no well known addresses for anyone hardcode. Several microsoft OSes will automatically use fec0:0:0:ffff::1, 2, and 3 if there is a nameserver there. From JDuffy at nww.com Wed Feb 2 10:20:15 2011 From: JDuffy at nww.com (JDuffy at nww.com) Date: Wed, 2 Feb 2011 11:20:15 -0500 Subject: Egypt Message-ID: <2DB499DF412E434C9F2E2917BA54017123946607CE@USMACCR01.idgone.int> Hi again from Network World... We're now looking into a story on how Egypt may have restored service -- did they bring up all routes at once? Stagger the re-introduction of routes so as not to overwhelm routers? Any specific ISPs brought up before others and why? ie, Noor and the stock exchange brought up before any others, etc. Any thoughts from NANOG on how best -- or worst -- to restore Internet service following, reportedly, the largest government-mandated blackout ever? Also, are any of you in touch with any Egyptian ISPs and sharing this type of information? Or hearing any "war stories" from over there? Thanks again, and best regards, Jim Duffy Network World From vinny at abellohome.net Wed Feb 2 10:27:53 2011 From: vinny at abellohome.net (Vinny Abello) Date: Wed, 02 Feb 2011 11:27:53 -0500 Subject: Connectivity to Brazil In-Reply-To: References: <4F3DD62E-4007-4ED2-94D6-8405E1C1546E@gmail.com> <33104.1296591593@localhost> <80F3BEC5-89AA-4D54-95EA-976AC3292E60@gmail.com> Message-ID: <4D498609.9040704@abellohome.net> Very simply. :) We chose to stop accepting prefixes from and announcing prefixes to them. You could attempt this in more elaborate and less forceful ways if you're in the right position, but we encounter issues like this too much and it affects critical clients that cannot afford any downtime, and we have plenty of other transit connections. We are in a position where we have direct connectivity with them (which based on our track record won't be much longer), so it might be much easier for us. Otherwise you'd have to hope your upstream is the one connected to them and has communities available to tinker with to withdraw your tagged prefixes from being announced to them, and just change the local preference or however you prefer to do it on the inbound routes from your upstream, or better yet filter on as-path. -Vinny On 2/2/2011 8:08 AM, Steve Danelli wrote: > Thanks Vinny - how did you route around? There seems to be one path from the US to Brazil via GBLX and CTBC. Are you leveraging leased connectivity? Thanks for the info!! > > SD > > Sent from my iPhone > > On Feb 2, 2011, at 1:21 AM, Vinny Abello wrote: > >> We saw similar issues with IKE through Global Crossing (as odd as that sounds) out of the NYC market at the same time. We routed around them and problem solved. Still scratching our heads on that one... In my experiences, GLBX has numerous odd issues to the point where it's become a bad joke anytime something breaks with connectivity... we blame them. It's kind of not funny though because it's almost always true. Taking them out of the equation usually fixes the problem. One of our customers who is frequently affected by GBLX problems jumps to the (often correct) conclusion that they are causing problems. :-/ >> >> -Vinny >> >> On Feb 1, 2011, at 3:57 PM, Steve Danelli wrote: >> >>> Thanks for the response. >>> >>> Ike had worked great up until Monday. The provider did a local test and our box saw the Ike packets so it appears to lie somewhere upstream. (GLBX may be a good guess) >>> >>> Also - the paths are stable and we are sourcing from the same ip - very strange behaivor. Hope someone from GLBX or CTBC (or someone who had experienced an issue like this) can assist >>> >>> >>> Thanks to all for their feedback so far. >>> >>> SD >>> >>> On Feb 1, 2011, at 3:19 PM, Valdis.Kletnieks at vt.edu wrote: >>> >>>> On Tue, 01 Feb 2011 08:54:47 EST, Steve Danelli said: >>>> >>>>> Some carrier, somewhere between us and the service provider is selectively >>>>> dropping the IKE packets originating from our VPN gateway and destined for >>>>> our Brazil gateway. Other traffic is able to pass, as are the IKE packets coming >>>>> back from Brazil to us. This is effectively preventing us from establishing >>>>> the IPSEC tunnel between our gateways. >>>> Has IKE been known to work to that location before? Or is this something new? >>>> My first guess is some chucklehead banana-eater at the service provider either >>>> fat-fingered the firewall config, or semi-intentionally blocked it because it >>>> was "traffic on a protocol/port number they didn't understand so it must be >>>> evil". >>>> >>>>> Also something else is awry, for two given hosts on the same subnet (x.y.z.52 >>>>> and x.y.z.53), they take two wildly divergent paths: >>>>> Anyone have any insight on to what may be occurring? >>>> The paths appear to diverge at 67.16.142.238. I wonder if that's gear trying >>>> to do some load-balancing across 2 paths, and it's using the source IP as a >>>> major part of the selector function ("route to round-robin interface source-IP >>>> mod N" or similar?). >>>> >>>> The other possibility is your two traceroutes happened to catch a routing flap in >>>> progress (obviously not the case if the two routes are remaining stable). >>>> >>>> Sorry I can't be more helpful than that... From lowen at pari.edu Wed Feb 2 10:38:14 2011 From: lowen at pari.edu (Lamar Owen) Date: Wed, 2 Feb 2011 11:38:14 -0500 Subject: quietly.... In-Reply-To: <70C15FD9-CF85-4664-B913-3EBE4271C7F5@muada.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> Message-ID: <201102021138.14987.lowen@pari.edu> On Wednesday, February 02, 2011 10:52:46 am Iljitsch van Beijnum wrote: > No, the point is that DNS resolvers in different places all use the same addresses. So at the cyber cafe 3003::3003 is the cyber cafe DNS but at the airport 3003::3003 is the airport DNS. (Or in both cases, if they don't run a DNS server, one operated by their ISP.) Hrmph. Shades of 47.007900000000000000000000.00A03E000001.00 and all that that implies, here. Well, different syntatic sugar, but, anyway.... Haven't we withdrawn from this ATM before? From mpetach at netflight.com Wed Feb 2 10:52:00 2011 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 2 Feb 2011 08:52:00 -0800 Subject: 2011.02.02 NANOG51 day 3 morning session notes Message-ID: Final set of notes for NANOG51 have been posted up at http://kestrel3.netflight.com/2011.02.02-NANOG51-morning-notes.txt (not that many people will see them, as everyone is clearing out of the room and heading for flights at this point. ^_^; ) Thanks again to Josh and Terremark for hosting another successful conference; would have loved to be able to join the party, but alas, lack of budget ruled that out this time around. Thanks also to all the presenters and speakers, and to the technical crew who provide the online streams; in spite of my grumblings about the occasional spottiness this time around, it really is awesome to be able to follow along remotely. :) Thanks! Matt From iljitsch at muada.com Wed Feb 2 10:55:53 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 2 Feb 2011 17:55:53 +0100 Subject: quietly.... In-Reply-To: <4D4982CC.7060100@otd.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <4D4979D1.4000104@phaze.org> <70C15FD9-CF85-4664-B913-3EBE4271C7F5@muada.com> <4D4982CC.7060100@otd.com> Message-ID: <01B5A647-AB05-4435-88FE-2F7535A644B2@muada.com> On 2 feb 2011, at 17:14, Dave Israel wrote: >> I understand people use DHCP for lots of stuff today. But that's mainly because DHCP is there, not because it's the best possible way to get that particular job done. > So what if I want to assign different people to different resolvers by policy? For the record: I'm not saying that DHCPv6 is never useful. DHCPv6 is intended as a stateful configuration provisioning tool, i.e., to give different hosts different configurations. If that's what you need then DHCP fits the bill. However, in most small scale environments this is not what's needed so DHCP doesn't fit the bill. Also, the examples mentioned are about enterprise networks with stable systems. Here, DHCP works well. However, with systems that connect to different networks, things don't always work so well. I may want to use the DHCP-provided NTP servers at work, but syncing with a random NTP server when I connect to a wifi hotspot is not such a great idea. From lowen at pari.edu Wed Feb 2 11:00:17 2011 From: lowen at pari.edu (Lamar Owen) Date: Wed, 2 Feb 2011 12:00:17 -0500 Subject: quietly.... In-Reply-To: <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> Message-ID: <201102021200.17407.lowen@pari.edu> On Wednesday, February 02, 2011 10:23:28 am Iljitsch van Beijnum wrote: > Who ever puts NTP addresses in DHCP? That doesn't make any sense. I'd rather use a known NTP server that keeps correct time. We do, for multiple reasons. And we have some stringent timing requirements. From adam at leff.co Wed Feb 2 11:02:14 2011 From: adam at leff.co (Adam Leff) Date: Wed, 2 Feb 2011 12:02:14 -0500 Subject: OT: References for i/o Phoenix Datacenter Message-ID: My company is considering taking space in the i/o "Phoenix One" datacenter in Arizona. If anyone has any feedback of this facility in general or any of i/o's facilities, good or bad, I would certainly appreciate an off-list reply. As you would expect, the company you're intending to do business with is never going to give you a negative reference. :) Thanks everyone and my apologies for the quick off-topic distraction. Adam From alh-ietf at tndh.net Wed Feb 2 11:01:34 2011 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 2 Feb 2011 09:01:34 -0800 Subject: ipv4's last graph In-Reply-To: <876F9BFF-4807-49A5-9D76-9FC067CCC645@apnic.net> References: <876F9BFF-4807-49A5-9D76-9FC067CCC645@apnic.net> Message-ID: <161a01cbc2fa$eb5e00d0$c21a0270$@net> So in the interest of 'second opinions never hurt', and I just can't get my head around "APnic sitting at 3 /8's, burning 2.3 /8's in the last 2 months and the idea of a 50% probability that their exhaustion event occurs Aug. 2011", here are a couple other graphs to consider. http://www.tndh.net/~tony/ietf/IPv4-rir-pools.pdf http://www.tndh.net/~tony/ietf/IPv4-rir-pools-zoom.pdf Tony > -----Original Message----- > From: Geoff Huston [mailto:gih at apnic.net] > Sent: Tuesday, February 01, 2011 12:12 PM > To: Randy Bush > Cc: NANOG Operators' Group > Subject: Re: ipv4's last graph > > > On 01/02/2011, at 7:02 PM, Randy Bush wrote: > > > with the iana free pool run-out, i guess we won't be getting those > nice > > graphs any more. might we have one last one for the turnstiles? :- > )/2 > > > > and would you mind doing the curves now for each of the five rirs? > > gotta give us all something to repeat endlessly on lists and in > presos. > > but of course. > > http://www.potaroo.net/tools/ipv4/rir.jpg > > This is a different graph - it is a probabilistic graph that shows the > predicted month when the RIR will be down to its last /8 policy > (whatever that policy may be), and the relative probability that the > event will occur in that particular month. > > The assumption behind this graph is that the barricades will go up > across the regions and each region will work from its local address > pools and service only its local client base, and that as each region > gets to its last /8 policy the applicants will not transfer their > demand to those regions where addresses are still available. Its not > possible to quantify how (in)accurate this assumption may be, so beyond > the prediction of the first exhaustion point (which is at this stage > looking more likely to occur in July 2011 than not) the predictions for > the other RIRs are highly uncertain. > > Geoff From drais at icantclick.org Wed Feb 2 11:05:02 2011 From: drais at icantclick.org (david raistrick) Date: Wed, 2 Feb 2011 12:05:02 -0500 (EST) Subject: quietly.... In-Reply-To: References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> Message-ID: On Tue, 1 Feb 2011, Cameron Byrne wrote: >> Telling people "I'm right, you're wrong" over and over again leads to >> them going away and ignoring IPv6. >> > > +1 > > Somebody should probably get a blog instead of sending, *39 and > counting*, emails to this list in one day. It's a discussion list. We're having a discussion. Admittedly, Owen hasn't presented any solutions to my actual problems, but.. ;) Owen said: > The solution to number 2 depends again on the circumstance. IPv6 > offers a variety of tools for this problem, but, I have yet to see an > environment where the other tools can't offer a better solution than > NAT. Which is a complete non-answer. NAT provides a nice "solution" - even with it's problems - for small consumers and large enterprises, who have much higher percentages of devices that need (or even -require-) no inbound connectivity. Why should I (or my IT department) have to renumber the 5,000 desktop PCs in this office (a large percentage of which have static IP addresses due to the failings of dynamic DNS and software that won't support DNS (I'm looking at you, Unity.) just because we've changed providers? Why should we have to renumber devices at my mom's house just because she switched from cable to dsl? -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From mpetach at netflight.com Wed Feb 2 11:22:13 2011 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 2 Feb 2011 09:22:13 -0800 Subject: ipv4's last graph In-Reply-To: <161a01cbc2fa$eb5e00d0$c21a0270$@net> References: <876F9BFF-4807-49A5-9D76-9FC067CCC645@apnic.net> <161a01cbc2fa$eb5e00d0$c21a0270$@net> Message-ID: On Wed, Feb 2, 2011 at 9:01 AM, Tony Hain wrote: > So in the interest of 'second opinions never hurt', and I just can't get my > head around "APnic sitting at 3 /8's, burning 2.3 /8's in the last 2 months > and the idea of a 50% probability that their exhaustion event occurs Aug. > 2011", here are a couple other graphs to consider. > http://www.tndh.net/~tony/ietf/IPv4-rir-pools.pdf > http://www.tndh.net/~tony/ietf/IPv4-rir-pools-zoom.pdf > > Tony Two things: 1) you'll get better uptake of your graph if it's visible as a simple image, rather than requiring a PDF download. :/ 2) labelling the Y axis would help; I'm not sure what the scale of 1-8 represents, unless it's perhaps the number of slices of pizza consumed per staff member per address allocation request? But I do agree with what seems to be your driving message, which is that Geoff could potentially be considered "optimistic". ^_^; Matt From Andy.Litzinger at theplatform.com Wed Feb 2 11:24:42 2011 From: Andy.Litzinger at theplatform.com (Andy Litzinger) Date: Wed, 2 Feb 2011 09:24:42 -0800 Subject: AS numbers and multiple site best practices In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B34F040@ex-mb-1.corp.atlasnetworks.us> References: <52AAD98E43AFC64AA04AF3AC4B8B64F701CB565729@tpmail03.corp.theplatform.com> <8C26A4FDAE599041A13EB499117D3C286B34F040@ex-mb-1.corp.atlasnetworks.us> Message-ID: <52AAD98E43AFC64AA04AF3AC4B8B64F701CB5657B4@tpmail03.corp.theplatform.com> > > I've had trouble finding any technical reason not to use it. > > What is important to you about having QA and Corporate use separate AS > numbers? Does using the same AS number result in a reduction of > separation? For my part it's mostly a desire to make sure that changes to QA or Corp BGP configs could never impact BGP for our Production datacenter. So far it looks like it may just be a fear of the unknown on my part as I can't think of a good example of how one might actually affect one BGP installation by making changes to another BGP installation purely based on sharing an AS number (clearly you could have impact if you are advertising the same space from both locations). From drais at icantclick.org Wed Feb 2 11:28:54 2011 From: drais at icantclick.org (david raistrick) Date: Wed, 2 Feb 2011 12:28:54 -0500 (EST) Subject: quietly.... In-Reply-To: <70C15FD9-CF85-4664-B913-3EBE4271C7F5@muada.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <4D4979D1.4000104@phaze.org> <70C15FD9-CF85-4664-B913-3EBE4271C7F5@muada.com> Message-ID: On Wed, 2 Feb 2011, Iljitsch van Beijnum wrote: > No, the point is that DNS resolvers in different places all use the same > addresses. So at the cyber cafe 3003::3003 is the cyber cafe DNS but at > the airport 3003::3003 is the airport DNS. (Or in both cases, if they > don't run a DNS server, one operated by their ISP.) Because no one has ever had a need to coexist with other DNS servers on the same subnet, right? After all, there should only ever be 1 authorative source of information, and there's no way we would ever want to have an exception for that. ...david (who manages his own authorative and recursive DNS servers that are used specificly for our group's purposes that have to coexist with IT-managed servers) -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From matt.addison at lists.evilgeni.us Wed Feb 2 11:43:26 2011 From: matt.addison at lists.evilgeni.us (Matt Addison) Date: Wed, 2 Feb 2011 12:43:26 -0500 Subject: quietly.... In-Reply-To: References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <4D4979D1.4000104@phaze.org> <70C15FD9-CF85-4664-B913-3EBE4271C7F5@muada.com> Message-ID: On Wed, Feb 2, 2011 at 12:28, david raistrick wrote: > On Wed, 2 Feb 2011, Iljitsch van Beijnum wrote: > > No, the point is that DNS resolvers in different places all use the same >> addresses. So at the cyber cafe 3003::3003 is the cyber cafe DNS but at the >> airport 3003::3003 is the airport DNS. (Or in both cases, if they don't run >> a DNS server, one operated by their ISP.) >> > > Because no one has ever had a need to coexist with other DNS servers on the > same subnet, right? After all, there should only ever be 1 authorative > source of information, and there's no way we would ever want to have an > exception for that. > Why do they have to be mutually exclusive? What's wrong with having default well known (potentially anycasted) resolver addresses, which can then be overridden by RA/DHCP/static configuration? ~Matt From jhary at unsane.co.uk Wed Feb 2 11:44:05 2011 From: jhary at unsane.co.uk (Vincent Hoffman) Date: Wed, 02 Feb 2011 17:44:05 +0000 Subject: ipv4's last graph In-Reply-To: References: <876F9BFF-4807-49A5-9D76-9FC067CCC645@apnic.net> <161a01cbc2fa$eb5e00d0$c21a0270$@net> Message-ID: <4D4997E5.20309@unsane.co.uk> On 02/02/2011 17:22, Matthew Petach wrote: > On Wed, Feb 2, 2011 at 9:01 AM, Tony Hain wrote: >> So in the interest of 'second opinions never hurt', and I just can't get my >> head around "APnic sitting at 3 /8's, burning 2.3 /8's in the last 2 months >> and the idea of a 50% probability that their exhaustion event occurs Aug. >> 2011", here are a couple other graphs to consider. >> http://www.tndh.net/~tony/ietf/IPv4-rir-pools.pdf >> http://www.tndh.net/~tony/ietf/IPv4-rir-pools-zoom.pdf >> >> Tony > Two things: > > 1) you'll get better uptake of your graph if it's visible as a simple > image, rather than requiring a PDF download. :/ Not wishing to advertise google but http://docs.google.com/viewer?url=http://www.tndh.net/~tony/ietf/IPv4-rir-pools.pdf and http://docs.google.com/viewer?url=http://www.tndh.net/~tony/ietf/IPv4-rir-pools-zoom.pdf works for me without needing to download a pdf viewer Vince > 2) labelling the Y axis would help; I'm not sure what the scale > of 1-8 represents, unless it's perhaps the number of slices of > pizza consumed per staff member per address allocation request? > > But I do agree with what seems to be your driving message, which > is that Geoff could potentially be considered "optimistic". ^_^; > > Matt From tony at lava.net Wed Feb 2 11:45:46 2011 From: tony at lava.net (Antonio Querubin) Date: Wed, 2 Feb 2011 07:45:46 -1000 (HST) Subject: quietly.... In-Reply-To: <01B5A647-AB05-4435-88FE-2F7535A644B2@muada.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <4D4979D1.4000104@phaze.org> <70C15FD9-CF85-4664-B913-3EBE4271C7F5@muada.com> <4D4982CC.7060100@otd.com> <01B5A647-AB05-4435-88FE-2F7535A644B2@muada.com> Message-ID: On Wed, 2 Feb 2011, Iljitsch van Beijnum wrote: > different networks, things don't always work so well. I may want to use > the DHCP-provided NTP servers at work, but syncing with a random NTP > server when I connect to a wifi hotspot is not such a great idea. It's not "random" if the network operator is providing it via DHCP is it? Antonio Querubin e-mail/xmpp: tony at lava.net From nick at foobar.org Wed Feb 2 11:49:04 2011 From: nick at foobar.org (Nick Hilliard) Date: Wed, 02 Feb 2011 17:49:04 +0000 Subject: quietly.... In-Reply-To: References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <4D4979D1.4000104@phaze.org> <70C15FD9-CF85-4664-B913-3EBE4271C7F5@muada.com> Message-ID: <4D499910.4020001@foobar.org> On 02/02/2011 17:43, Matt Addison wrote: > Why do they have to be mutually exclusive? What's wrong with having default > well known (potentially anycasted) resolver addresses, which can then be > overridden by RA/DHCP/static configuration? because that increases the complexity of the system, and complexity leads to more failure modes. If you model how this would work on a state diagram, you'll see that there are several inherent ways that this will cause serious problems when people start doing things like removing the well known addresses (because they don't use them), and so forth. This is a well-examined problem: well known unicast listener addresses are a bad, bad idea. Nick From alh-ietf at tndh.net Wed Feb 2 12:11:48 2011 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 2 Feb 2011 10:11:48 -0800 Subject: ipv4's last graph In-Reply-To: <4D4997E5.20309@unsane.co.uk> References: <876F9BFF-4807-49A5-9D76-9FC067CCC645@apnic.net> <161a01cbc2fa$eb5e00d0$c21a0270$@net> <4D4997E5.20309@unsane.co.uk> Message-ID: <164501cbc304$aa7b6490$ff722db0$@net> > -----Original Message----- > From: Vincent Hoffman [mailto:jhary at unsane.co.uk] > Sent: Wednesday, February 02, 2011 9:44 AM > To: nanog at nanog.org > Subject: Re: ipv4's last graph > > On 02/02/2011 17:22, Matthew Petach wrote: > > On Wed, Feb 2, 2011 at 9:01 AM, Tony Hain wrote: > >> So in the interest of 'second opinions never hurt', and I just can't > get my > >> head around "APnic sitting at 3 /8's, burning 2.3 /8's in the last 2 > months > >> and the idea of a 50% probability that their exhaustion event occurs > Aug. > >> 2011", here are a couple other graphs to consider. > >> http://www.tndh.net/~tony/ietf/IPv4-rir-pools.pdf > >> http://www.tndh.net/~tony/ietf/IPv4-rir-pools-zoom.pdf > >> > >> Tony > > Two things: > > > > 1) you'll get better uptake of your graph if it's visible as a simple > > image, rather than requiring a PDF download. :/ > Not wishing to advertise google but > > http://docs.google.com/viewer?url=http://www.tndh.net/~tony/ietf/IPv4- > rir-pools.pdf > and > http://docs.google.com/viewer?url=http://www.tndh.net/~tony/ietf/IPv4- > rir-pools-zoom.pdf > > > works for me without needing to download a pdf viewer For some reason that viewer didn't work here, so I added jpg's to the site. http://www.tndh.net/~tony/ietf/IPv4-rir-pools.jpg http://www.tndh.net/~tony/ietf/IPv4-rir-pools-zoom.jpg > > Vince > > > > > 2) labelling the Y axis would help; I'm not sure what the scale > > of 1-8 represents, unless it's perhaps the number of slices of > > pizza consumed per staff member per address allocation request? I thought about leaving it off completely, but figured I would be asked for scale. It is /8's remaining until they drop into their 'last allocation' policy. I will see if I can figure out how to fit that into something readable. > > > > But I do agree with what seems to be your driving message, which > > is that Geoff could potentially be considered "optimistic". ^_^; Geoff has always been the optimist ... ;0 > > > > Matt From mickster4470 at gmail.com Wed Feb 2 12:15:55 2011 From: mickster4470 at gmail.com (The Mickster) Date: Wed, 2 Feb 2011 10:15:55 -0800 Subject: AS numbers and multiple site best practices In-Reply-To: <52AAD98E43AFC64AA04AF3AC4B8B64F701CB5657B4@tpmail03.corp.theplatform.com> References: <52AAD98E43AFC64AA04AF3AC4B8B64F701CB565729@tpmail03.corp.theplatform.com> <8C26A4FDAE599041A13EB499117D3C286B34F040@ex-mb-1.corp.atlasnetworks.us> <52AAD98E43AFC64AA04AF3AC4B8B64F701CB5657B4@tpmail03.corp.theplatform.com> Message-ID: It seems to me that the issues (in terms of causing failures) are all related to how the prefixes are announced, and not what ASN they are announced from. However if there ARE issues caused by how the prefixes are announced, it may (or may not) be easier to troubleshoot the problem if the announcements are from different ASNs. I go back to the definition of an Autonomous System - a network or group of networks under a common administrative control. Are the networks at the datacenter and the networks at the corporate office under a common administrative control or not? >From a certain "purist" perspective, if the corp office networks aren't run by the same people who run the datacenter, then the prefixes should be announced from different ASNs with different points of contact. In this case, in theory, if the corp office prefixes are being announced from both that location AND the datacenter, then you should BGP peer the corp office with the datacenter, so that the data center announces them with the same origin ASN that you are using at the corp office location, and the data center ASN is next in the list as a provider. Of course that may have the affect of tending to steer all or most of the corp office traffic away from the datacenter (or not depending on peering), which may or may not be what you intend. Of course in spite of all of that, I have to ask if another ASN is really NEEDED - i.e. do the people who run the data center network and the people who run the corp office network talk to each other? Are the data center network folks smart enough to figure out if a problem might be related to announcements from the corp office, and friendly enough to be able to work together with the other group to resolve the issue (and the other way around)? If you all get along, I have to ask if you need to add another ASN to the routers of everyone in the world... Mickster On Wed, Feb 2, 2011 at 9:24 AM, Andy Litzinger < Andy.Litzinger at theplatform.com> wrote: > > > > I've had trouble finding any technical reason not to use it. > > > > What is important to you about having QA and Corporate use separate AS > > numbers? Does using the same AS number result in a reduction of > > separation? > > For my part it's mostly a desire to make sure that changes to QA or Corp > BGP configs could never impact BGP for our Production datacenter. So far it > looks like it may just be a fear of the unknown on my part as I can't think > of a good example of how one might actually affect one BGP installation by > making changes to another BGP installation purely based on sharing an AS > number (clearly you could have impact if you are advertising the same space > from both locations). > > From mehmet at akcin.net Wed Feb 2 12:33:38 2011 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 2 Feb 2011 13:33:38 -0500 Subject: 2011.02.02 NANOG51 day 3 morning session notes In-Reply-To: References: Message-ID: <8C7FA3C1-BA5C-4618-88FE-4A0235BAE5BF@akcin.net> On Feb 2, 2011, at 11:52 AM, Matthew Petach wrote: > Thanks again to Josh and Terremark for hosting another > successful conference; would have loved to be able to > join the party, but alas, lack of budget ruled that out > this time around. +1 Josh / Bill , amazing job with hosting nanog. Mehmet From ken at sizone.org Wed Feb 2 12:43:58 2011 From: ken at sizone.org (Ken Chase) Date: Wed, 2 Feb 2011 13:43:58 -0500 Subject: ipv4's last graph In-Reply-To: <164501cbc304$aa7b6490$ff722db0$@net> References: <876F9BFF-4807-49A5-9D76-9FC067CCC645@apnic.net> <161a01cbc2fa$eb5e00d0$c21a0270$@net> <4D4997E5.20309@unsane.co.uk> <164501cbc304$aa7b6490$ff722db0$@net> Message-ID: <20110202184358.GL5923@sizone.org> On Wed, Feb 02, 2011 at 10:11:48AM -0800, Tony Hain said: >For some reason that viewer didn't work here, so I added jpg's to the site. >http://www.tndh.net/~tony/ietf/IPv4-rir-pools.jpg >http://www.tndh.net/~tony/ietf/IPv4-rir-pools-zoom.jpg 13:13 < dec0de> africa is where it's at 13:15 < moebius_> Dear Sirs, I am the son of the deposed Prime Minister of Nigeria. We are in possession of 93,208,512 IP addresses and wish to request your assistance... /kc -- Ken Chase - ken at heavycomputing.ca skype:kenchase23 +1 416 897 6284 Toronto Canada Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From richard.barnes at gmail.com Wed Feb 2 12:43:58 2011 From: richard.barnes at gmail.com (Richard Barnes) Date: Wed, 2 Feb 2011 13:43:58 -0500 Subject: ipv4's last graph In-Reply-To: <164501cbc304$aa7b6490$ff722db0$@net> References: <876F9BFF-4807-49A5-9D76-9FC067CCC645@apnic.net> <161a01cbc2fa$eb5e00d0$c21a0270$@net> <4D4997E5.20309@unsane.co.uk> <164501cbc304$aa7b6490$ff722db0$@net> Message-ID: Note that the ARIN, APNIC, and RIPE lines should all basically level out to asymptotes after they hit 1 /8 left, due to the "soft run out" policies in place [1][2][3]. Either that, or just consider arriving at 1 /8 left as depletion. Geoff: How are your graphs dealing with these policies? [1] [2] [3] On Wed, Feb 2, 2011 at 1:11 PM, Tony Hain wrote: >> -----Original Message----- >> From: Vincent Hoffman [mailto:jhary at unsane.co.uk] >> Sent: Wednesday, February 02, 2011 9:44 AM >> To: nanog at nanog.org >> Subject: Re: ipv4's last graph >> >> On 02/02/2011 17:22, Matthew Petach wrote: >> > On Wed, Feb 2, 2011 at 9:01 AM, Tony Hain wrote: >> >> So in the interest of 'second opinions never hurt', and I just can't >> get my >> >> head around "APnic sitting at 3 /8's, burning 2.3 /8's in the last 2 >> months >> >> and the idea of a 50% probability that their exhaustion event occurs >> Aug. >> >> 2011", here are a couple other graphs to consider. >> >> http://www.tndh.net/~tony/ietf/IPv4-rir-pools.pdf >> >> http://www.tndh.net/~tony/ietf/IPv4-rir-pools-zoom.pdf >> >> >> >> Tony >> > Two things: >> > >> > 1) you'll get better uptake of your graph if it's visible as a simple >> > ? ? ?image, rather than requiring a PDF download. ?:/ >> Not wishing to advertise google but >> >> http://docs.google.com/viewer?url=http://www.tndh.net/~tony/ietf/IPv4- >> rir-pools.pdf >> and >> http://docs.google.com/viewer?url=http://www.tndh.net/~tony/ietf/IPv4- >> rir-pools-zoom.pdf >> >> >> works for me without needing to download a pdf viewer > > For some reason that viewer didn't work here, so I added jpg's to the site. > http://www.tndh.net/~tony/ietf/IPv4-rir-pools.jpg > http://www.tndh.net/~tony/ietf/IPv4-rir-pools-zoom.jpg > > >> >> Vince >> >> >> >> > 2) labelling the Y axis would help; I'm not sure what the scale >> > of 1-8 represents, unless it's perhaps the number of slices of >> > pizza consumed per staff member per address allocation request? > > I thought about leaving it off completely, but figured I would be asked for > scale. It is /8's remaining until they drop into their 'last allocation' > policy. I will see if I can figure out how to fit that into something > readable. > > >> > >> > But I do agree with what seems to be your driving message, which >> > is that Geoff could potentially be considered "optimistic". ?^_^; > > Geoff has always been the optimist ... ?;0 > > >> > >> > Matt > > > > From alh-ietf at tndh.net Wed Feb 2 13:01:56 2011 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 2 Feb 2011 11:01:56 -0800 Subject: ipv4's last graph In-Reply-To: References: <876F9BFF-4807-49A5-9D76-9FC067CCC645@apnic.net> <161a01cbc2fa$eb5e00d0$c21a0270$@net> <4D4997E5.20309@unsane.co.uk> <164501cbc304$aa7b6490$ff722db0$@net> Message-ID: <168801cbc30b$b46007c0$1d201740$@net> > -----Original Message----- > From: Richard Barnes [mailto:richard.barnes at gmail.com] > Sent: Wednesday, February 02, 2011 10:44 AM > To: Tony Hain > Cc: Vincent Hoffman; nanog at nanog.org > Subject: Re: ipv4's last graph > > Note that the ARIN, APNIC, and RIPE lines should all basically level > out to asymptotes after they hit 1 /8 left, due to the "soft run out" > policies in place [1][2][3]. Either that, or just consider arriving > at 1 /8 left as depletion. The /8 that applies to those policies has not been allocated yet ... ask again tomorrow. Would it make more sense to mark the graph at 1 with an asterisk, or just leave those out of this graph all together? If you care about how well the policy is managing the end of the pool, then marking 1 is the right thing, while if you only care about when 'old policy' stops then it makes more sense to just leave them off. Tony > > Geoff: How are your graphs dealing with these policies? > > [1] > [2] > [3] > > > > On Wed, Feb 2, 2011 at 1:11 PM, Tony Hain wrote: > >> -----Original Message----- > >> From: Vincent Hoffman [mailto:jhary at unsane.co.uk] > >> Sent: Wednesday, February 02, 2011 9:44 AM > >> To: nanog at nanog.org > >> Subject: Re: ipv4's last graph > >> > >> On 02/02/2011 17:22, Matthew Petach wrote: > >> > On Wed, Feb 2, 2011 at 9:01 AM, Tony Hain > wrote: > >> >> So in the interest of 'second opinions never hurt', and I just > can't > >> get my > >> >> head around "APnic sitting at 3 /8's, burning 2.3 /8's in the > last 2 > >> months > >> >> and the idea of a 50% probability that their exhaustion event > occurs > >> Aug. > >> >> 2011", here are a couple other graphs to consider. > >> >> http://www.tndh.net/~tony/ietf/IPv4-rir-pools.pdf > >> >> http://www.tndh.net/~tony/ietf/IPv4-rir-pools-zoom.pdf > >> >> > >> >> Tony > >> > Two things: > >> > > >> > 1) you'll get better uptake of your graph if it's visible as a > simple > >> > ? ? ?image, rather than requiring a PDF download. ?:/ > >> Not wishing to advertise google but > >> > >> > http://docs.google.com/viewer?url=http://www.tndh.net/~tony/ietf/IPv4- > >> rir-pools.pdf > >> and > >> > http://docs.google.com/viewer?url=http://www.tndh.net/~tony/ietf/IPv4- > >> rir-pools-zoom.pdf > >> > >> > >> works for me without needing to download a pdf viewer > > > > For some reason that viewer didn't work here, so I added jpg's to the > site. > > http://www.tndh.net/~tony/ietf/IPv4-rir-pools.jpg > > http://www.tndh.net/~tony/ietf/IPv4-rir-pools-zoom.jpg > > > > > >> > >> Vince > >> > >> > >> > >> > 2) labelling the Y axis would help; I'm not sure what the scale > >> > of 1-8 represents, unless it's perhaps the number of slices of > >> > pizza consumed per staff member per address allocation request? > > > > I thought about leaving it off completely, but figured I would be > asked for > > scale. It is /8's remaining until they drop into their 'last > allocation' > > policy. I will see if I can figure out how to fit that into something > > readable. > > > > > >> > > >> > But I do agree with what seems to be your driving message, which > >> > is that Geoff could potentially be considered "optimistic". ?^_^; > > > > Geoff has always been the optimist ... ?;0 > > > > > >> > > >> > Matt > > > > > > > > From randy at psg.com Wed Feb 2 13:07:52 2011 From: randy at psg.com (Randy Bush) Date: Thu, 03 Feb 2011 04:07:52 +0900 Subject: quietly.... In-Reply-To: <4D49695A.7050305@brightok.net> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <4D49695A.7050305@brightok.net> Message-ID: the problem is not whether RA is worth a damn, produces more erronious results, is harder to filter bad guys/gals, ... the problem is folk have *large* dhcp deployments. they look at going to ipv6 and say "wtf? i have to revamp my operation because of some religious nuts. rfc1918 is my friend. whew!" randy From owen at delong.com Wed Feb 2 13:09:26 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 2 Feb 2011 11:09:26 -0800 Subject: ipv4's last graph In-Reply-To: References: <876F9BFF-4807-49A5-9D76-9FC067CCC645@apnic.net> <161a01cbc2fa$eb5e00d0$c21a0270$@net> <4D4997E5.20309@unsane.co.uk> <164501cbc304$aa7b6490$ff722db0$@net> Message-ID: <5F7F5AF2-CD0F-405F-AA8B-081C3A8EE325@delong.com> Currently there is no policy in ARIN that would do that short of the last /10, so, the line should change at 1/4 of the last /8. Owen On Feb 2, 2011, at 10:43 AM, Richard Barnes wrote: > Note that the ARIN, APNIC, and RIPE lines should all basically level > out to asymptotes after they hit 1 /8 left, due to the "soft run out" > policies in place [1][2][3]. Either that, or just consider arriving > at 1 /8 left as depletion. > > Geoff: How are your graphs dealing with these policies? > > [1] > [2] > [3] > > > > On Wed, Feb 2, 2011 at 1:11 PM, Tony Hain wrote: >>> -----Original Message----- >>> From: Vincent Hoffman [mailto:jhary at unsane.co.uk] >>> Sent: Wednesday, February 02, 2011 9:44 AM >>> To: nanog at nanog.org >>> Subject: Re: ipv4's last graph >>> >>> On 02/02/2011 17:22, Matthew Petach wrote: >>>> On Wed, Feb 2, 2011 at 9:01 AM, Tony Hain wrote: >>>>> So in the interest of 'second opinions never hurt', and I just can't >>> get my >>>>> head around "APnic sitting at 3 /8's, burning 2.3 /8's in the last 2 >>> months >>>>> and the idea of a 50% probability that their exhaustion event occurs >>> Aug. >>>>> 2011", here are a couple other graphs to consider. >>>>> http://www.tndh.net/~tony/ietf/IPv4-rir-pools.pdf >>>>> http://www.tndh.net/~tony/ietf/IPv4-rir-pools-zoom.pdf >>>>> >>>>> Tony >>>> Two things: >>>> >>>> 1) you'll get better uptake of your graph if it's visible as a simple >>>> image, rather than requiring a PDF download. :/ >>> Not wishing to advertise google but >>> >>> http://docs.google.com/viewer?url=http://www.tndh.net/~tony/ietf/IPv4- >>> rir-pools.pdf >>> and >>> http://docs.google.com/viewer?url=http://www.tndh.net/~tony/ietf/IPv4- >>> rir-pools-zoom.pdf >>> >>> >>> works for me without needing to download a pdf viewer >> >> For some reason that viewer didn't work here, so I added jpg's to the site. >> http://www.tndh.net/~tony/ietf/IPv4-rir-pools.jpg >> http://www.tndh.net/~tony/ietf/IPv4-rir-pools-zoom.jpg >> >> >>> >>> Vince >>> >>> >>> >>>> 2) labelling the Y axis would help; I'm not sure what the scale >>>> of 1-8 represents, unless it's perhaps the number of slices of >>>> pizza consumed per staff member per address allocation request? >> >> I thought about leaving it off completely, but figured I would be asked for >> scale. It is /8's remaining until they drop into their 'last allocation' >> policy. I will see if I can figure out how to fit that into something >> readable. >> >> >>>> >>>> But I do agree with what seems to be your driving message, which >>>> is that Geoff could potentially be considered "optimistic". ^_^; >> >> Geoff has always been the optimist ... ;0 >> >> >>>> >>>> Matt >> >> >> >> From john at sackheads.org Wed Feb 2 13:30:23 2011 From: john at sackheads.org (John Payne) Date: Wed, 2 Feb 2011 14:30:23 -0500 Subject: quietly.... In-Reply-To: <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> Message-ID: <5CB621E0-1873-47DC-B4EE-A5E2D6E5D5B4@sackheads.org> On Feb 2, 2011, at 3:16 AM, Iljitsch van Beijnum wrote: > On 2 feb 2011, at 4:51, Dave Israel wrote: > >> They were features dreamed up by academics, theoreticians, and purists, and opposed by operators. > > Contrary to popular belief, the IETF listens to operators and wants them to participate. Few do. For instance, I don't seem to remember your name from any IETF mailinglists. (I could be mistaken, though.) From personal experience, the only reason die-hard IETF folk want operators to participate on IETF lists is so that they can tell them that they're wrong on IETF mailing lists as opposed to operator mailing lists. > Example: if you give administrators the option of putting a router address in a DHCP option, they will do so and some fraction of the time, this will be the wrong address and things don't work. If you let routers announce their presence, then it's virtually impossible that something goes wrong because routers know who they are. A clear win. Of course it does mean that people have to learn something new when adopting IPv6. Is anyone else reading this and the word "condescending" _not_ popping into their heads? From john at sackheads.org Wed Feb 2 13:37:35 2011 From: john at sackheads.org (John Payne) Date: Wed, 2 Feb 2011 14:37:35 -0500 Subject: quietly.... In-Reply-To: <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> Message-ID: <53820806-5EF6-4E8D-900C-CDBEDB097E2E@sackheads.org> On Feb 2, 2011, at 10:23 AM, Iljitsch van Beijnum wrote: > On 2 feb 2011, at 16:00, Owen DeLong wrote: > >> SLAAC fails because you can't get information about DNS, NTP, or anything other than a list of prefixes and a router that MIGHT actually be able to default-route your packets. > > Who ever puts NTP addresses in DHCP? That doesn't make any sense. I'd rather use a known NTP server that keeps correct time. > > For DNS in RA, see RFC 6106. > > But all of this could easily have been avoided: why are we _discovering_ DNS addresses in the first place? Simply host them on well known addresses and you can hardcode those addresses, similar to the 6to4 gateway address. But no, no rough consensus on something so simple. > >> DHCP fails because you can't get a default router out of it. > > If you consider that wrong, I don't want to be right. Hey, I thought you wanted ops input... Here you are getting it, and look, here all you are doing is saying that its wrong. From john at sackheads.org Wed Feb 2 13:40:50 2011 From: john at sackheads.org (John Payne) Date: Wed, 2 Feb 2011 14:40:50 -0500 Subject: quietly.... In-Reply-To: <2FD9EDE7-E28C-48E7-B6FB-8386773EF98E@delong.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <4D48E558.7070805@brightok.net> <2FD9EDE7-E28C-48E7-B6FB-8386773EF98E@delong.com> Message-ID: <9689E83C-048A-4D72-946B-978FB3C315A4@sackheads.org> On Feb 2, 2011, at 6:18 AM, Owen DeLong wrote: > NAT66 is different. NAT66 breaks things in ways that impact sites outside of the site choosing to deploy NAT. Examples? From Valdis.Kletnieks at vt.edu Wed Feb 2 13:42:14 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 02 Feb 2011 14:42:14 -0500 Subject: quietly.... In-Reply-To: Your message of "Wed, 02 Feb 2011 07:45:46 -1000." References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <4D4979D1.4000104@phaze.org> <70C15FD9-CF85-4664-B913-3EBE4271C7F5@muada.com> <4D4982CC.7060100@otd.com> <01B5A647-AB05-4435-88FE-2F7535A644B2@muada.com> Message-ID: <25893.1296675734@localhost> On Wed, 02 Feb 2011 07:45:46 -1000, Antonio Querubin said: > On Wed, 2 Feb 2011, Iljitsch van Beijnum wrote: > > > different networks, things don't always work so well. I may want to use > > the DHCP-provided NTP servers at work, but syncing with a random NTP > > server when I connect to a wifi hotspot is not such a great idea. > > It's not "random" if the network operator is providing it via DHCP is it? If you're connecting at a Starbuck's, and you care more than "hopefully somebody will tell me the right time within a minute", yes, it *is* essentially random. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Wed Feb 2 13:42:23 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 02 Feb 2011 14:42:23 -0500 Subject: quietly.... In-Reply-To: Your message of "Wed, 02 Feb 2011 14:30:23 EST." <5CB621E0-1873-47DC-B4EE-A5E2D6E5D5B4@sackheads.org> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <5CB621E0-1873-47DC-B4EE-A5E2D6E5D5B4@sackheads.org> Message-ID: <25915.1296675743@localhost> On Wed, 02 Feb 2011 14:30:23 EST, John Payne said: > On Feb 2, 2011, at 3:16 AM, Iljitsch van Beijnum wrote: > > Example: if you give administrators the option of putting a router > > address in a DHCP option, they will do so and some fraction of the time, > > this will be the wrong address and things don't work. If you let routers > > announce their presence, then it's virtually impossible that something > > goes wrong because routers know who they are. A clear win. Of course it > > does mean that people have to learn something new when adopting > > IPv6. > Is anyone else reading this and the word "condescending" _not_ popping > into their heads? The only other charitable conclusion I can draw is "Somebody hasn't spent time chasing down people with misconfigured laptops on the wireless who are squawking RA's for 2002:" There's a *big* operational difference between "all authorized and properly configured routers know who they are" and "all nodes that think they're routers (deluded though they may be) know who they are". -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From john at sackheads.org Wed Feb 2 13:48:14 2011 From: john at sackheads.org (John Payne) Date: Wed, 2 Feb 2011 14:48:14 -0500 Subject: quietly.... In-Reply-To: <437F22E3-154B-4DD2-B37B-8BC54D116B40@delong.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <437F22E3-154B-4DD2-B37B-8BC54D116B40@delong.com> Message-ID: On Feb 1, 2011, at 6:15 PM, Owen DeLong wrote: > > On Feb 1, 2011, at 2:56 PM, John Payne wrote: > >> >> >> On Feb 1, 2011, at 4:38 PM, Owen DeLong wrote: >> >>> NAT solves exactly one problem. It provides a way to reduce address consumption to work around a shortage of addresses. >>> >>> It does not solve any other problem(s). >> >> >> That's a bold statement. Especially as you said NAT and not PAT. > > NAT, PAT, whatever... I'm willing to back it up. NAT provides a solution to, lets call it, enterprise multihoming. Remote office with a local Internet connection, but failover through the corporate network. In IPv4 this would likely be done with PAT, but I'm looking forward to being able to do something similar with NAT66 (or whatever it ends up being called) without blowing out my internal policies or having to maintain multiple addresses on each end point. From jeff-kell at utc.edu Wed Feb 2 13:58:00 2011 From: jeff-kell at utc.edu (Jeff Kell) Date: Wed, 02 Feb 2011 14:58:00 -0500 Subject: quietly.... In-Reply-To: <25915.1296675743@localhost> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <5CB621E0-1873-47DC-B4EE-A5E2D6E5D5B4@sackheads.org> <25915.1296675743@localhost> Message-ID: <4D49B748.5060105@utc.edu> On 2/2/2011 2:42 PM, Valdis.Kletnieks at vt.edu wrote: > The only other charitable conclusion I can draw is "Somebody hasn't spent time > chasing down people with misconfigured laptops on the wireless who are squawking > RA's for 2002:" > > There's a *big* operational difference between "all authorized and properly configured > routers know who they are" and "all nodes that think they're routers (deluded though > they may be) know who they are". Amen to that, and add "all mischievous nodes that would /*love*/ to be your router / DNS / default gateway / etc" Jeff From owen at delong.com Wed Feb 2 13:54:01 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 2 Feb 2011 11:54:01 -0800 Subject: quietly.... In-Reply-To: <9689E83C-048A-4D72-946B-978FB3C315A4@sackheads.org> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <4D48E558.7070805@brightok.net> <2FD9EDE7-E28C-48E7-B6FB-8386773EF98E@delong.com> <9689E83C-048A-4D72-946B-978FB3C315A4@sackheads.org> Message-ID: On Feb 2, 2011, at 11:40 AM, John Payne wrote: > > On Feb 2, 2011, at 6:18 AM, Owen DeLong wrote: > >> NAT66 is different. NAT66 breaks things in ways that impact sites outside of the site choosing to deploy NAT. > > Examples? SIP Network enabled Video Games Peer to Peer services of various forms etc. Owen From compuwizz at gmail.com Wed Feb 2 14:03:32 2011 From: compuwizz at gmail.com (Jared Geiger) Date: Wed, 2 Feb 2011 15:03:32 -0500 Subject: Primus Canada AS 6407 Contact needed Message-ID: Hi, I'm seeking a contact at AS6407 to help troubleshoot a huge spike in latency I'm seeing to them. Thanks, Jared From iljitsch at muada.com Wed Feb 2 14:12:12 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 2 Feb 2011 21:12:12 +0100 Subject: quietly.... In-Reply-To: <53820806-5EF6-4E8D-900C-CDBEDB097E2E@sackheads.org> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <53820806-5EF6-4E8D-900C-CDBEDB097E2E@sackheads.org> Message-ID: On 2 feb 2011, at 20:37, John Payne wrote: >>> DHCP fails because you can't get a default router out of it. >> If you consider that wrong, I don't want to be right. > Hey, I thought you wanted ops input... Here you are getting it, and look, here all you are doing is saying that its wrong. I said the IETF wants input. In case you hadn't noticed, I'm not the IETF. I don't represent them in any way. I'm not even a working group chair. I've gone to a bunch of meetings, spent way too much time on IETF mailinglists and co-wrote all of one RFCs. I read some great writing advice once. It applies to much more than just writing. It goes like this: whenever a reader tells you that there's something wrong with your book, there is something wrong with your book. But if they tell you how to fix it, they're pretty much always wrong. I'm not part of the DHC working group and I'm not a big DHCP user myself, so I don't claim to know the issues that exist with DHCPv6 in the operational community. But I'm sure there are some valid issues there. However, I'm equally sure that adding IPv4-DHCP-style router addresses to DHCPv6 is a big mistake that will create a lot of operational problems. Maybe not in the networks of the people that want this feature, but the problems will be there. Coming to the IETF to have your solution rubberstamped invariably leads to disappointment. Go there to tell them about your problem. That works much better. But sending _me_ your input doesn't seem to make either of us happier. From john at sackheads.org Wed Feb 2 14:13:21 2011 From: john at sackheads.org (John Payne) Date: Wed, 2 Feb 2011 15:13:21 -0500 Subject: quietly.... In-Reply-To: References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <4D48E558.7070805@brightok.net> <2FD9EDE7-E28C-48E7-B6FB-8386773EF98E@delong.com> <9689E83C-048A-4D72-946B-978FB3C315A4@sackheads.org> Message-ID: <3CD3A697-8D3C-4EDE-8E4E-53C0E103E12C@sackheads.org> On Feb 2, 2011, at 2:54 PM, Owen DeLong wrote: > > On Feb 2, 2011, at 11:40 AM, John Payne wrote: > >> >> On Feb 2, 2011, at 6:18 AM, Owen DeLong wrote: >> >>> NAT66 is different. NAT66 breaks things in ways that impact sites outside of the site choosing to deploy NAT. >> >> Examples? > > SIP > Network enabled Video Games > Peer to Peer services of various forms > etc. I chose NAT66. How does that affect you or any other site? Note that I have already blocked games and peer to peer either technically or via policy.... and I have no SIP end points that have any business talking outside the enterprise. Just rephrasing you slightly. NAT66 will break applications that many enterprises will already have blocked at their perimeters. From george.herbert at gmail.com Wed Feb 2 14:15:01 2011 From: george.herbert at gmail.com (George Herbert) Date: Wed, 2 Feb 2011 12:15:01 -0800 Subject: quietly.... In-Reply-To: <01B5A647-AB05-4435-88FE-2F7535A644B2@muada.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <4D4979D1.4000104@phaze.org> <70C15FD9-CF85-4664-B913-3EBE4271C7F5@muada.com> <4D4982CC.7060100@otd.com> <01B5A647-AB05-4435-88FE-2F7535A644B2@muada.com> Message-ID: On Wed, Feb 2, 2011 at 8:55 AM, Iljitsch van Beijnum wrote: > On 2 feb 2011, at 17:14, Dave Israel wrote: > >>> I understand people use DHCP for lots of stuff today. But that's mainly because DHCP is there, not because it's the best possible way to get that particular job done. > >> So what if I want to assign different people to different resolvers by policy? > > For the record: I'm not saying that DHCPv6 is never useful. DHCPv6 is intended as a stateful configuration provisioning tool, i.e., to give different hosts different configurations. If that's what you need then DHCP fits the bill. However, in most small scale environments this is not what's needed so DHCP doesn't fit the bill. There are all sized enivronments. Political battles having partly crippled DHCPv6 in ways that end up significantly limiting IPv6 uptake into large enterprise organizations ... it's hard to describe how frustrating this is without resorting to thrown fragile objects against hard walls. As an active consultant to medium and large enterprises, this is driving me nuts. This single item is in my estimation contributing at least 6, perhaps 12 months to the worldwide average delay in IPv6 uptake. I know several organizations that would have been there six months ago had DHCPv6 not had this flaw. They're currently 6-12 months from getting there. This was predicted. That the right people didn't believe it suggests that perhaps the right people are the wrong people. > Also, the examples mentioned are about enterprise networks with stable systems. Here, DHCP works well. However, with systems that connect to different networks, things don't always work so well. I may want to use the DHCP-provided NTP servers at work, but syncing with a random NTP server when I connect to a wifi hotspot is not such a great idea. That's a problem with insufficiently configurable network location profiles on your OS (not having a "listen to DHCP NTP here, but not elsewhere" button). -- -george william herbert george.herbert at gmail.com From john at sackheads.org Wed Feb 2 14:18:55 2011 From: john at sackheads.org (John Payne) Date: Wed, 2 Feb 2011 15:18:55 -0500 Subject: quietly.... In-Reply-To: References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <53820806-5EF6-4E8D-900C-CDBEDB097E2E@sackheads.org> Message-ID: <9E196E91-4086-4081-B7DC-D30C1589D9FC@sackheads.org> On Feb 2, 2011, at 3:12 PM, Iljitsch van Beijnum wrote: > On 2 feb 2011, at 20:37, John Payne wrote: > >>>> DHCP fails because you can't get a default router out of it. > >>> If you consider that wrong, I don't want to be right. > >> Hey, I thought you wanted ops input... Here you are getting it, and look, here all you are doing is saying that its wrong. > > I said the IETF wants input. > > In case you hadn't noticed, I'm not the IETF. I don't represent them in any way. I'm not even a working group chair. I've gone to a bunch of meetings, spent way too much time on IETF mailinglists and co-wrote all of one RFCs. You may not represent the IETF, but you are representative of the attitude of the IETF. > > I read some great writing advice once. It applies to much more than just writing. It goes like this: whenever a reader tells you that there's something wrong with your book, there is something wrong with your book. But if they tell you how to fix it, they're pretty much always wrong. There's something wrong with your attitude towards operators. There's a lot wrong with the IETF attitude towards operators, but you're here :) > I'm not part of the DHC working group and I'm not a big DHCP user myself, so I don't claim to know the issues that exist with DHCPv6 in the operational community. But I'm sure there are some valid issues there. However, I'm equally sure that adding IPv4-DHCP-style router addresses to DHCPv6 is a big mistake that will create a lot of operational problems. Maybe not in the networks of the people that want this feature, but the problems will be there. Having machines listen to any RA they receive is _today_ a cause of a lot of operational problems. Why do we need mommy-IETF telling us no for default routes in DHCP but letting RAs run wild? Why does the mere mention of NAT cause daddy-IETF to round up the troops and insist that everyone is wrong? From pscanlon at arbor.net Wed Feb 2 14:22:19 2011 From: pscanlon at arbor.net (Scanlon, Paul) Date: Wed, 2 Feb 2011 20:22:19 +0000 Subject: 2011.02.02 NANOG51 day 3 morning session notes In-Reply-To: <8C7FA3C1-BA5C-4618-88FE-4A0235BAE5BF@akcin.net> References: <8C7FA3C1-BA5C-4618-88FE-4A0235BAE5BF@akcin.net> Message-ID: <6987F4EC-3BA5-4FFF-A718-3D931828A9CC@arbornetworks.com> Josh ++ Geek Circus sets the bar. On Feb 2, 2011, at 1:34 PM, Mehmet Akcin wrote: > > On Feb 2, 2011, at 11:52 AM, Matthew Petach wrote: > >> Thanks again to Josh and Terremark for hosting another >> successful conference; would have loved to be able to >> join the party, but alas, lack of budget ruled that out >> this time around. > > > +1 Josh / Bill , amazing job with hosting nanog. > > Mehmet > From owen at delong.com Wed Feb 2 14:18:44 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 2 Feb 2011 12:18:44 -0800 Subject: quietly.... In-Reply-To: <25893.1296675734@localhost> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <4D4979D1.4000104@phaze.org> <70C15FD9-CF85-4664-B913-3EBE4271C7F5@muada.com> <4D4982CC.7060100@otd.com> <01B5A647-AB05-4435-88FE-2F7535A644B2@muada.com> <25893.1296675734@localhos! t> Message-ID: On Feb 2, 2011, at 11:42 AM, Valdis.Kletnieks at vt.edu wrote: > On Wed, 02 Feb 2011 07:45:46 -1000, Antonio Querubin said: >> On Wed, 2 Feb 2011, Iljitsch van Beijnum wrote: >> >>> different networks, things don't always work so well. I may want to use >>> the DHCP-provided NTP servers at work, but syncing with a random NTP >>> server when I connect to a wifi hotspot is not such a great idea. >> >> It's not "random" if the network operator is providing it via DHCP is it? > > If you're connecting at a Starbuck's, and you care more than "hopefully > somebody will tell me the right time within a minute", yes, it *is* essentially > random. While that is true, the people that are asking for the ability to advertise NTP servers in DHCP are not running the networks at Starbucks. Owen From john at sackheads.org Wed Feb 2 14:24:42 2011 From: john at sackheads.org (John Payne) Date: Wed, 2 Feb 2011 15:24:42 -0500 Subject: quietly.... In-Reply-To: References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <4D4979D1.4000104@phaze.org> <70C15FD9-CF85-4664-B913-3EBE4271C7F5@muada.com> <4D4982CC.7060100@otd.com> <01B5A647-AB05-4435-88FE-2F7535A644B2@muada.com> Message-ID: <09C9D1B8-F003-4932-ABC1-7299F81F1C29@sackheads.org> On Feb 2, 2011, at 3:15 PM, George Herbert wrote: > On Wed, Feb 2, 2011 at 8:55 AM, Iljitsch van Beijnum wrote: >> On 2 feb 2011, at 17:14, Dave Israel wrote: >> >>>> I understand people use DHCP for lots of stuff today. But that's mainly because DHCP is there, not because it's the best possible way to get that particular job done. >> >>> So what if I want to assign different people to different resolvers by policy? >> >> For the record: I'm not saying that DHCPv6 is never useful. DHCPv6 is intended as a stateful configuration provisioning tool, i.e., to give different hosts different configurations. If that's what you need then DHCP fits the bill. However, in most small scale environments this is not what's needed so DHCP doesn't fit the bill. > > There are all sized enivronments. Political battles having partly > crippled DHCPv6 in ways that end up significantly limiting IPv6 uptake > into large enterprise organizations ... it's hard to describe how > frustrating this is without resorting to thrown fragile objects > against hard walls. As an active consultant to medium and large > enterprises, this is driving me nuts. > > This single item is in my estimation contributing at least 6, perhaps > 12 months to the worldwide average delay in IPv6 uptake. I know > several organizations that would have been there six months ago had > DHCPv6 not had this flaw. They're currently 6-12 months from getting > there. Well, to be fair... In my "decent sized" enterprise, DHCPv6 and the lack of default route is irritating but not the blocker. The second largest OS we have doesn't support DHCPv6 at all, so its not like fixing the default route option is a magic bullet. So, we're going to have DHCP for IPv4 and SLAAC for IPv6 for now. DNS, NTP, etc will be done over IPv4 - no way around that. We have vendor struggles. The current pain is the lack of good support for VRRPv3. RA guard is another. However, IPv6 on the enterprise network will continue to be seen as an after thought until and unless we get parity. From lowen at pari.edu Wed Feb 2 14:36:52 2011 From: lowen at pari.edu (Lamar Owen) Date: Wed, 2 Feb 2011 15:36:52 -0500 Subject: quietly.... In-Reply-To: <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> Message-ID: <201102021536.53234.lowen@pari.edu> On Wednesday, February 02, 2011 03:16:59 am Iljitsch van Beijnum wrote: > A clear win. Of course it does mean that people have to learn something new when adopting IPv6. Ever hear of intellectual inertia? The more that has to be learned to go a new path, the less likely that path will be chosen if another path still works, or can be made work with incremental changes. There's already too much new to learn, and not as many available hours or people to learn it. What I want is to add an IPv6 subnet or subnets to my already tuned DHCP server config, add IPv6 addresses to the addresses handed out (in the same config clause as the IPv4 addresses are stored, preferably), update the DHCP server software to IPv6-capability, restart the DHCP server, and both IPv4 and IPv6 clients get what they need, through the same already locked down channels, with no other upgrades required. Takes what, thirty minutes per DHCP server if you're slow? Instead, I'll have to completely relearn how dynamic allocation works, learn about and protect against a new attack vector, learn about and deploy new hardware and software more than likely, and in general pull my hair out debugging new code and new platforms.... and so I'll be inclined to keep what works and bandaid it until it cannot be bandaided any more. Sorry, but those are the operational facts of life. IPv6's uptake has been slow because it is too different, IMO, and thus intellectual inertia (in the complete Newtonian physics sense of the word) kicks in. IPv4 is a huge mass moving at a large velocity, and the delta force vector to adjust course is too great for many to swallow. It doesn't seem that different until you add all those pesky little details up. Try that exercise one day, and add up *all* the differences that operators have to know and implement to go IPv6, and balance that against smaller staffs and smaller budgets. From iljitsch at muada.com Wed Feb 2 14:55:30 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 2 Feb 2011 21:55:30 +0100 Subject: quietly.... In-Reply-To: <9E196E91-4086-4081-B7DC-D30C1589D9FC@sackheads.org> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <53820806-5EF6-4E8D-900C-CDBEDB097E2E@sackheads.org> <9E196E91-4086-4081-B7DC-D30C1589D9FC@sackheads.org> Message-ID: <1397B616-F7F5-4212-B055-C0DFE1A99E3C@muada.com> On 2 feb 2011, at 21:18, John Payne wrote: > Having machines listen to any RA they receive is _today_ a cause of a lot of operational problems. You should have come to the IETF 10 or even 5 years ago. It's too late now, one day before the global pool of IPv4 addresses runs out. IPv6 is what it is. There will be more tinkering but if you think there's enough time to wait for your pet feature to be standardized and implemented widely, you're sorely mistaken. > Why do we need mommy-IETF telling us no for default routes in DHCP but letting RAs run wild? > Why does the mere mention of NAT cause daddy-IETF to round up the troops and insist that everyone is wrong? Because IPv4-style DHCP often breaks because the DHCP server points to the wrong router address and because NAT breaks end-to-end connectivity so severe workaround in applications become necessary. But you knew that. On 2 feb 2011, at 21:15, George Herbert wrote: > it's hard to describe how > frustrating this is without resorting to thrown fragile objects > against hard walls. Ok, I know I'm going to regret this, but: Can you explain what exactly the problems with DHCPv6 are that you're running into that are inherent to DHCP and/or IPv6 host configuration and won't be fixed by bringing IPv4 ethernet switch features to IPv6? On 2 feb 2011, at 21:18, Owen DeLong wrote: >> If you're connecting at a Starbuck's, and you care more than "hopefully >> somebody will tell me the right time within a minute", yes, it *is* essentially >> random. > While that is true, the people that are asking for the ability to advertise > NTP servers in DHCP are not running the networks at Starbucks. But whatever the IETF comes up with needs to work at Starbucks as well as enterprise networks, everything else you can think of and then some you can't. On 2 feb 2011, at 21:36, Lamar Owen wrote: > > What I want is to add an IPv6 subnet or subnets to my already tuned DHCP server config, add IPv6 addresses to the addresses handed out (in the same config clause as the IPv4 addresses are stored, preferably), update the DHCP server software to IPv6-capability, restart the DHCP server, and both IPv4 and IPv6 clients get what they need, through the same already locked down channels, with no other upgrades required. You can do that today. For instance, this is what I have in a test setup. (However, the ISC dhcpd can only do either v4 or v6, not both at the same time.) subnet6 2001:960:7bf:d::/64 { option dhcp6.name-servers 2001:1af8:2:5::2; option dhcp6.domain-search "bonjour.muada.nl"; range6 2001:960:7bf:d::1000 2001:960:7bf:d::1fff; } Of course there are some subtleties such as the fact that some IPv6 systems don't support DHCPv6 so you also need stateless autoconfig if you want to be able to use those, and some (all?) routers automatically enable stateless autoconfig and don't tell hosts to use DHCP. But that can be fixed with two lines of config. > Instead, I'll have to completely relearn how dynamic allocation works, learn about and protect against a new attack vector You also get to stop worrying about a few old ones. > It doesn't seem that different until you add all those pesky little details up. Try that exercise one day, and add up *all* the differences that operators have to know and implement to go IPv6, and balance that against smaller staffs and smaller budgets. I did this for routing. I can explain everything you need to know about how to run IPv6 BGP, RIP and OSPF in an hour and a half. Did that at a RIPE meeting some years ago. Setting up Apache to use IPv6 is one line of config. BIND two or three (not counting IPv6 reverse zones). There are some good books on running IPv6, you know. :-) From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Feb 2 15:06:57 2011 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 3 Feb 2011 07:36:57 +1030 Subject: quietly.... In-Reply-To: <9E196E91-4086-4081-B7DC-D30C1589D9FC@sackheads.org> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <53820806-5EF6-4E8D-900C-CDBEDB097E2E@sackheads.org> <9E196E91-4086-4081-B7DC-D30C1589D9FC@sackheads.org> Message-ID: <20110203073657.2f616986@opy.nosense.org> On Wed, 2 Feb 2011 15:18:55 -0500 John Payne wrote: > > On Feb 2, 2011, at 3:12 PM, Iljitsch van Beijnum wrote: > > > On 2 feb 2011, at 20:37, John Payne wrote: > > > >>>> DHCP fails because you can't get a default router out of it. > > > >>> If you consider that wrong, I don't want to be right. > > > >> Hey, I thought you wanted ops input... Here you are getting it, and look, here all you are doing is saying that its wrong. > > > > I said the IETF wants input. > > > > In case you hadn't noticed, I'm not the IETF. I don't represent them in any way. I'm not even a working group chair. I've gone to a bunch of meetings, spent way too much time on IETF mailinglists and co-wrote all of one RFCs. > > You may not represent the IETF, but you are representative of the attitude of the IETF. > And I'm afraid you're representative of the "IPv4 thinking" attitude, that seems to believe that the past IPv4 ways are not just the only ways of solving a problem but are also naturally the best. They also seem assume that the way IPv6 is going to be used is exactly the same as IPv4, so the IPv4 methods will be perfect in all IPv6 applications. It's a bit of a shame that people who've gotten into networking in the last 10 to 15 years haven't studied or worked with anything more than IPv4. They've missed out on seeing a variety of different ways to solve the same types of problems and therefore been exposed to the various benefits and trade-offs of the different methods. With that sort of exposure, people may find out that there are other better ways to solve problems, but IPv4's limitations and constraints prevented them being possible. > > > > I read some great writing advice once. It applies to much more than just writing. It goes like this: whenever a reader tells you that there's something wrong with your book, there is something wrong with your book. But if they tell you how to fix it, they're pretty much always wrong. > > There's something wrong with your attitude towards operators. > There's a lot wrong with the IETF attitude towards operators, but you're here :) > > > > I'm not part of the DHC working group and I'm not a big DHCP user myself, so I don't claim to know the issues that exist with DHCPv6 in the operational community. But I'm sure there are some valid issues there. However, I'm equally sure that adding IPv4-DHCP-style router addresses to DHCPv6 is a big mistake that will create a lot of operational problems. Maybe not in the networks of the people that want this feature, but the problems will be there. > > Having machines listen to any RA they receive is _today_ a cause of a lot of operational problems. Why do we need mommy-IETF telling us no for default routes in DHCP but letting RAs run wild? > Why does the mere mention of NAT cause daddy-IETF to round up the troops and insist that everyone is wrong? > > From bicknell at ufp.org Wed Feb 2 15:13:12 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 2 Feb 2011 13:13:12 -0800 Subject: quietly.... In-Reply-To: <1397B616-F7F5-4212-B055-C0DFE1A99E3C@muada.com> References: <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <53820806-5EF6-4E8D-900C-CDBEDB097E2E@sackheads.org> <9E196E91-4086-4081-B7DC-D30C1589D9FC@sackheads.org> <1397B616-F7F5-4212-B055-C0DFE1A99E3C@muada.com> Message-ID: <20110202211312.GA92881@ussenterprise.ufp.org> In a message written on Wed, Feb 02, 2011 at 09:55:30PM +0100, Iljitsch van Beijnum wrote: > On 2 feb 2011, at 21:18, John Payne wrote: > > Having machines listen to any RA they receive is _today_ a cause of a lot of operational problems. > > You should have come to the IETF 10 or even 5 years ago. It's too late now, one day before the global pool of IPv4 addresses runs out. IPv6 is what it is. There will be more tinkering but if you think there's enough time to wait for your pet feature to be standardized and implemented widely, you're sorely mistaken. I went to the IETF ~5 years and argued about the problems with RA's and the lack of things like a default route in DHCP. I had working group chairs tell me "You're an operator, you don't know what you're talking about, and clearly don't understand IPv6". After a few months of bashing my head against that abuse I gave up. This problem will now be solved by vendors, when operators put up cash. The solutions will be far uglier than if it was designed properly, and the IETF will fade even further into irrevelance. > Because IPv4-style DHCP often breaks because the DHCP server points to the wrong router address and because NAT breaks end-to-end connectivity so severe workaround in applications become necessary. But you knew that. FUD, plain and simple. DHCP does not "often break", it's used by probably hundreds of millions of devices every day, mostly without problem. In fact, in my short time with IPv6 I've had several orders of magnitude more breakage with RA's than with DHCP. Actual operational experience. Try telling that to IETF folks though, and they are convinced you're just an idiot rather than trying to understand what happens when the rubber meets the road. > Can you explain what exactly the problems with DHCPv6 are that you're running into that are inherent to DHCP and/or IPv6 host configuration and won't be fixed by bringing IPv4 ethernet switch features to IPv6? I love this question, because it basically admits the protocol is broken. To make RA's even remotely palitable, you need "RA Guard" on the switches. This feature does not exist, but if we bring features like DHCP guard forward into the IPv6 world, it's the logical solution and solves the problem. However, to the IETF people who think this, they just don't understand how many networks are built and run. Let's split the problem space. Ther are folks who say run hotel or dorm networks and need to protect from bad, bad users. For them DHCP guard, RA guard, BotNet guard, and all sorts of other features need to be in the switches. However, there are a lot of corporate network users where there really is no rogue DHCP server. Perhaps they are even using 802.1x on end user ports, so there are no rogue users at all. However, they do need a robust networking configuration. I'll give the simple scenario I've done to myself twice. Went to a remote site. Replaced the router with a new router. Took the old router back to the office and plugged it in so I could upgrade the code. IPv6 stopped working instantly. IPv4 kept working just fine, forever. Why? Well, the router from the other site sends out RA's as soon as it is plugged in, and all the hosts believe it and sink traffic to it. On the IPv4 side it was a DHCP HELPER. Let me repeat that, it's the part the IETF folks always miss. IT WAS A DHCP HELPER. A box on the network goes to do a DHCP request. It goes to the actual router, and to this "rogue" remote office router. However, being not configured correctly the rogue router's DHCP helper points to a default route out a WAN interface that is down, and the packet is dropped. No response, the host gets a response from the real router and all is well. The mere act of plugging in a old router takes down IPv6, but leaves IPv4 working just fine. I'd say that's a LOT less robust. Rather than give me IPv6 DHCP that works like IPv4, and thus would be just as robust, the IVTF, the vendors making the decisions, want me to deploy RA guard, which ooops, isn't on any of the old switches so you'll have to replace all of them. Basically, as an operator, the vendors got together, developed a broken protocol, figured out a work-around that requires me to replace everything. Or in short, the vendors figured out how to make me replace everything. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From drais at icantclick.org Wed Feb 2 15:09:26 2011 From: drais at icantclick.org (david raistrick) Date: Wed, 2 Feb 2011 16:09:26 -0500 (EST) Subject: quietly.... In-Reply-To: <1397B616-F7F5-4212-B055-C0DFE1A99E3C@muada.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <53820806-5EF6-4E8D-900C-CDBEDB097E2E@sackheads.org> <9E196E91-4086-4081-B7DC-D30C1589D9FC@sackheads.org> <1397B616-F7F5-4212-B055-C0DFE1A99E3C@muada.com> Message-ID: On Wed, 2 Feb 2011, Iljitsch van Beijnum wrote: > IPv6 is what it is. There will be more tinkering but if you think > there's enough and yet it still isn't ready and standardly supported by OSes, routers, switches, software.... seems to me it's in the same mode it always has been. > Because IPv4-style DHCP often breaks because the DHCP server points to Really? Never had that happen if I didn't configure it to happen... (and yes, I've done some pretty deep dhcp setups over the years, particular for WISP setups) > the wrong router address and because NAT breaks end-to-end connectivity > so severe workaround in applications become necessary. But you knew > that. On the NAT subject, I'll point out a recent change that I wasn't aware of, and a bit of history around it. It might help less people feel the "need" for NAT. At least in ARIN territory, if you're multihomed, and you can show in-1-year use of 50% of a (v4) /24, you qualify for a PI v6 /48. Which means that a lot of the shops I've worked for over the years can get PI space where they couldn't before, and one of the heavy uses of NAT (renumbering sanity) disappears. (if you're singlehomed, 50% of /20..) For the history, v6 was originally pushed as -NO ONE- (who isn't an LIR or RIR) -EVER- gets PI space, you should use insert-magic-of-the-week-here. That's changed. We can now get PI space, and we can use it. So those of you who were thinking of using NAT with v6, how does that effect your plans? -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Feb 2 15:23:45 2011 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 3 Feb 2011 07:53:45 +1030 Subject: quietly.... In-Reply-To: <56C77463-63CB-4304-9687-C53CC27D4065@delong.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <4D496D8B.7020601@brightok.net> <56C77463-63CB-4304-9687-C53CC27D4065@delong.com> Message-ID: <20110203075345.081a4bb5@opy.nosense.org> On Wed, 2 Feb 2011 07:04:13 -0800 Owen DeLong wrote: > > On Feb 2, 2011, at 6:43 AM, Jack Bates wrote: > > > > > > > On 2/2/2011 8:22 AM, Tony Finch wrote: > >> Counterexample: rogue RAs from Windows boxes running 6to4 or Teredo and > >> Internet Connection Sharing. This is a lot harder to fix than a > >> misconfigured DHCP server. > > > > CounterCounterexample: rogue DHCPv6 servers from windows boxes or improperly connected CPEs. > > > > Both DHCP(4 or 6) and RA require careful filtering to keep rogues from jacking things up. Though M$ has a nice deployment for authorizing DHCP4 servers in corporate environments. > > > It's a lot easier to find and eliminate a rogue DHCP server than a rogue RA. > How is that the case? The next hop for the default gateway that the rogue RA installs is the link local address, you look up the neighbor cache if the link local address doesn't have a MAC address in it, and then use layer 2 information to identify where it is attached. That's also the usual technique for finding and disabling a rogue DHCP server, so how is it any harder? Mark From matt.addison at lists.evilgeni.us Wed Feb 2 15:26:53 2011 From: matt.addison at lists.evilgeni.us (Matt Addison) Date: Wed, 2 Feb 2011 16:26:53 -0500 Subject: quietly.... In-Reply-To: <20110202211312.GA92881@ussenterprise.ufp.org> References: <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <53820806-5EF6-4E8D-900C-CDBEDB097E2E@sackheads.org> <9E196E91-4086-4081-B7DC-D30C1589D9FC@sackheads.org> <1397B616-F7F5-4212-B055-C0DFE1A99E3C@muada.com> <20110202211312.GA92881@ussenterprise.ufp.org> Message-ID: On Wed, Feb 2, 2011 at 16:13, Leo Bicknell wrote: > I love this question, because it basically admits the protocol is > broken. To make RA's even remotely palitable, you need "RA Guard" on > the switches. This feature does not exist, but if we bring features > like DHCP guard forward into the IPv6 world, it's the logical solution > and solves the problem. RA Guard has been described in RFC 6105 (still draft, but standards track), so that particular problem should be taken care of once vendors start shipping code. It doesn't even require SeND- although it does accomodate it. ~Matt From owen at delong.com Wed Feb 2 15:28:06 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 2 Feb 2011 13:28:06 -0800 Subject: quietly.... In-Reply-To: <1397B616-F7F5-4212-B055-C0DFE1A99E3C@muada.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <53820806-5EF6-4E8D-900C-CDBEDB097E2E@sackheads.org> <9E196E91-4086-4081-B7DC-D30C1589D9FC@sackheads.org> <1397B616-F7F5-4212-B055-C0DFE1A99E3C@muada.com> Message-ID: >> Why do we need mommy-IETF telling us no for default routes in DHCP but letting RAs run wild? >> Why does the mere mention of NAT cause daddy-IETF to round up the troops and insist that everyone is wrong? > > Because IPv4-style DHCP often breaks because the DHCP server points to the wrong router address and because NAT breaks end-to-end connectivity so severe workaround in applications become necessary. But you knew that. > IPv4 style DHCP occasionally (not often) breaks things because the DHCP server points to the wrong router address. On NAT, I actually agree with you. > On 2 feb 2011, at 21:15, George Herbert wrote: > >> it's hard to describe how >> frustrating this is without resorting to thrown fragile objects >> against hard walls. > > Ok, I know I'm going to regret this, but: > > Can you explain what exactly the problems with DHCPv6 are that you're running into that are inherent to DHCP and/or IPv6 host configuration and won't be fixed by bringing IPv4 ethernet switch features to IPv6? > The lack of default router capabilities in DHCPv6 is a major disappointment. Yes, there are ways to work around this limitation in most environments, but, it is problematic to have this limitation. > On 2 feb 2011, at 21:18, Owen DeLong wrote: > >>> If you're connecting at a Starbuck's, and you care more than "hopefully >>> somebody will tell me the right time within a minute", yes, it *is* essentially >>> random. > >> While that is true, the people that are asking for the ability to advertise >> NTP servers in DHCP are not running the networks at Starbucks. > > But whatever the IETF comes up with needs to work at Starbucks as well as enterprise networks, everything else you can think of and then some you can't. > Which is why the IETF should build an assortment of complete solutions that allow operators to choose the one that best meets their needs. It is absurd to limit the entire industry to a solution which cannot possibly be broken by misconfiguration by a barista. What we needed was RA/SLAAC with a way to specify DNS, NTP, and Next Server and DHCP with the ability to specify a default router. If we had these two complete solutions, operators would be able to choose whichever one fit best in each environment. Unfortunately, instead, what we got was two half-solutions that have to be combined to produce a suboptimal solution that sort of mostly works in most environments, mostly. > On 2 feb 2011, at 21:36, Lamar Owen wrote: > >> >> What I want is to add an IPv6 subnet or subnets to my already tuned DHCP server config, add IPv6 addresses to the addresses handed out (in the same config clause as the IPv4 addresses are stored, preferably), update the DHCP server software to IPv6-capability, restart the DHCP server, and both IPv4 and IPv6 clients get what they need, through the same already locked down channels, with no other upgrades required. > > You can do that today. For instance, this is what I have in a test setup. (However, the ISC dhcpd can only do either v4 or v6, not both at the same time.) > Which means you can't do what he said, but... > subnet6 2001:960:7bf:d::/64 > { > option dhcp6.name-servers 2001:1af8:2:5::2; > option dhcp6.domain-search "bonjour.muada.nl"; > range6 2001:960:7bf:d::1000 2001:960:7bf:d::1fff; > } > Where's the default router? Right... No feature parity. > Of course there are some subtleties such as the fact that some IPv6 systems don't support DHCPv6 so you also need stateless autoconfig if you want to be able to use those, and some (all?) routers automatically enable stateless autoconfig and don't tell hosts to use DHCP. But that can be fixed with two lines of config. > Exactly. >> Instead, I'll have to completely relearn how dynamic allocation works, learn about and protect against a new attack vector > > You also get to stop worrying about a few old ones. > Not so much. >> It doesn't seem that different until you add all those pesky little details up. Try that exercise one day, and add up *all* the differences that operators have to know and implement to go IPv6, and balance that against smaller staffs and smaller budgets. > > I did this for routing. I can explain everything you need to know about how to run IPv6 BGP, RIP and OSPF in an hour and a half. Did that at a RIPE meeting some years ago. Setting up Apache to use IPv6 is one line of config. BIND two or three (not counting IPv6 reverse zones). > > There are some good books on running IPv6, you know. :-) I have to agree here... The conversion to dual-stack is not that hard in most situations. OWen From lists at internetpolicyagency.com Wed Feb 2 15:37:01 2011 From: lists at internetpolicyagency.com (Roland Perry) Date: Wed, 2 Feb 2011 21:37:01 +0000 Subject: quietly.... In-Reply-To: References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <437F22E3-154B-4DD2-B37B-8BC54D116B40@delong.com> Message-ID: <9F2mjoD95cSNFAI6@perry.co.uk> In article , John Payne writes >NAT provides a solution to, lets call it, enterprise multihoming. >Remote office with a local Internet connection, but failover through >the corporate network. And for home (/homeworker) networks ... eg I have a NAT box with a default connection to my ADSL provider and an automatic failover to 3G (completely separate supplier). Almost everything inside my network doesn't notice when it switches over. Now, if only I could get it to automatically revert to ADSL when it reappears - I wouldn't have to worry so much about the 3G bill. -- Roland Perry Nottingham, UK From george.herbert at gmail.com Wed Feb 2 15:49:15 2011 From: george.herbert at gmail.com (George Herbert) Date: Wed, 2 Feb 2011 13:49:15 -0800 Subject: quietly.... In-Reply-To: <20110202211312.GA92881@ussenterprise.ufp.org> References: <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <53820806-5EF6-4E8D-900C-CDBEDB097E2E@sackheads.org> <9E196E91-4086-4081-B7DC-D30C1589D9FC@sackheads.org> <1397B616-F7F5-4212-B055-C0DFE1A99E3C@muada.com> <20110202211312.GA92881@ussenterprise.ufp.org> Message-ID: On Wed, Feb 2, 2011 at 1:13 PM, Leo Bicknell wrote: > In a message written on Wed, Feb 02, 2011 at 09:55:30PM +0100, Iljitsch van Beijnum wrote: >> Can you explain what exactly the problems with DHCPv6 are that you're running into that are inherent to DHCP and/or IPv6 host configuration and won't be fixed by bringing IPv4 ethernet switch features to IPv6? > > I love this question, because it basically admits the protocol is > broken. ?To make RA's even remotely palitable, you need "RA Guard" on > the switches. ?This feature does not exist, but if we bring features > like DHCP guard forward into the IPv6 world, it's the logical solution > and solves the problem. > > However, to the IETF people who think this, they just don't understand > how many networks are built and run. > > Let's split the problem space. ?Ther are folks who say run hotel or dorm > networks and need to protect from bad, bad users. ?For them DHCP guard, > RA guard, BotNet guard, and all sorts of other features need to be in > the switches. > > However, there are a lot of corporate network users where there really > is no rogue DHCP server. ?Perhaps they are even using 802.1x on end user > ports, so there are no rogue users at all. ?However, they do need a > robust networking configuration. > > I'll give the simple scenario I've done to myself twice. ?Went to a > remote site. ?Replaced the router with a new router. ?Took the old > router back to the office and plugged it in so I could upgrade the code. > > IPv6 stopped working instantly. > IPv4 kept working just fine, forever. > > Why? ?Well, the router from the other site sends out RA's as soon as it > is plugged in, and all the hosts believe it and sink traffic to it. ?On > the IPv4 side it was a DHCP HELPER. > > Let me repeat that, it's the part the IETF folks always miss. > > IT WAS A DHCP HELPER. > > A box on the network goes to do a DHCP request. ?It goes to the > actual router, and to this "rogue" remote office router. ?However, being > not configured correctly the rogue router's DHCP helper points to a > default route out a WAN interface that is down, and the packet is > dropped. ?No response, the host gets a response from the real router and > all is well. > > The mere act of plugging in a old router takes down IPv6, but leaves > IPv4 working just fine. ?I'd say that's a LOT less robust. ?Rather than > give me IPv6 DHCP that works like IPv4, and thus would be just as > robust, the IVTF, the vendors making the decisions, want me to deploy RA > guard, which ooops, isn't on any of the old switches so you'll have to > replace all of them. > > Basically, as an operator, the vendors got together, developed a > broken protocol, figured out a work-around that requires me to replace > everything. ?Or in short, the vendors figured out how to make me replace > everything. +1 Owen DeLong wrote, in response to the same query: >The lack of default router capabilities in DHCPv6 is a major disappointment. >Yes, there are ways to work around this limitation in most environments, but, it is problematic to have this limitation. +1 These seemingly minor features being absent caused 2 enterprises I consulted with in the medium-large size range (5,000-ish servers) to reject IPv6 for the time being. I could not figure out how to glue around the deficiency without fundamentally modifying how they manage and build and operate their server networks. They have several million end users of their services, probably approaching 10 million. -- -george william herbert george.herbert at gmail.com From marka at isc.org Wed Feb 2 15:51:45 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 03 Feb 2011 08:51:45 +1100 Subject: quietly.... In-Reply-To: Your message of "Wed, 02 Feb 2011 14:25:06 -0000." References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> Message-ID: <20110202215145.1FB5D96FFCC@drugs.dv.isc.org> In message , Tony Fi nch writes: > On Wed, 2 Feb 2011, Iljitsch van Beijnum wrote: > > > > But there's so much wrong with DHCPv6 that trying to fix it is pretty > > much useless, we need to abandon DHCP and start from scratch. Good thing > > IPv6 works just fine without DHCPv6. > > Yeah, no-one needs to dynamically find out their local recursive name > server or NTP server or network boot server. > > Tony. DHCP was supposed to be use *with* RA's. Whether the network used managed address assignment or used SLAAC. The two were designed to complement each other. DNS and NTP server details were always supposed to be learned via DHCP. Similarly you were supposed to remember the prefix length before when kicking off the dhcp client with a managed network. Most of the problems seen are the result of not properly integrating the two parts. Somewhere along the way this was forgotten. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From owen at delong.com Wed Feb 2 15:49:41 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 2 Feb 2011 13:49:41 -0800 Subject: quietly.... In-Reply-To: <9F2mjoD95cSNFAI6@perry.co.uk> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <437F22E3-154B-4DD2-B37B-8BC54D116B40@delong.com> <9F2mjoD95cSNFAI6@perry.co.uk> Message-ID: <5A055785-D55E-47A3-87B0-58B0DE81F60E@delong.com> On Feb 2, 2011, at 1:37 PM, Roland Perry wrote: > In article , John Payne writes > >> NAT provides a solution to, lets call it, enterprise multihoming. >> Remote office with a local Internet connection, but failover through >> the corporate network. > > And for home (/homeworker) networks ... eg I have a NAT box with a default connection to my ADSL provider and an automatic failover to 3G (completely separate supplier). > > Almost everything inside my network doesn't notice when it switches over. > > Now, if only I could get it to automatically revert to ADSL when it reappears - I wouldn't have to worry so much about the 3G bill. > > -- > Roland Perry > Nottingham, UK In this case in IPv6, the better choice is to have addresses on each host from both providers. When a provider goes away, the router should invalidate the prefix in the RAs. If the hosts have proper address selection policies, they will actually go back to the ADSL prefix as soon as it reappears. Owen From jeffrey.lyon at blacklotus.net Wed Feb 2 15:56:35 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Wed, 2 Feb 2011 16:56:35 -0500 Subject: Verizon acquiring Terremark In-Reply-To: <4D497019.7030808@packetpimp.org> References: <6EFFEFBAC68377459A2E972105C759EC03539A93@EXVBE005-2.exch005intermedia.net> <2838.1296628687@nsa.vix.com> <27665.1296656408@nsa.vix.com> <4D497019.7030808@packetpimp.org> Message-ID: On Wed, Feb 2, 2011 at 9:54 AM, Jason LeBlanc wrote: > I wonder if the price point will change. ?Having been in PAIX/S&D/Equinix > facilities for several years things have certainly changed with regard to > contract negotiations and pricing. ?Equinix is not very flexible. ?The > shuffle of techs has also resulted in a much less helpful group to work > with. > > On 02/02/2011 09:20 AM, Paul Vixie wrote: >>> >>> Date: Wed, 2 Feb 2011 03:22:39 -0500 >>> From: Jeffrey Lyon >>> >>> I'm sure everything will be fine in practice as others have indicated, >>> I was merely making a point of the inherent conflict of interest. >> >> ah. ?if you mean "it's unusual" or "it's difficult" rather than "it >> cannot be" then i have no arguments. ?the reason PAIX got traction >> at all, coming late to the game (1995-ish) as we did, was because MFS >> was then able to charge circuit prices for many forms of cross connect >> down at MAE West. ?and i did face continuous pressure from MFN to go >> after a share of PAIX's carrier's circuit revenue. ?(which i never did >> and which none of my successors have done either.) >> >> noting, the game as moved on. ?if verizon behaves badly as terremark's >> owner then the presence of equinix in the market will act as a relief >> valve. ?i think the "neutral and commercial" model is very well >> established and that verizon will not want to be the only carrier in >> those facilities nor have their circuit-holders be the only customers >> for the real estate. ?it's an awful lot of space to use just as colo, >> and it's both over- and underbuilt for colo (vs. an IX). >> >> re: >> >>> On Wed, Feb 2, 2011 at 1:38 AM, Paul Vixie ?wrote: >>>> >>>> Jeffrey Lyon ?writes: >>>> >>>>> One cannot be owned by a carrier and remain carrier neutral. >>>>> >>>>> My two cents, >>>> >>>> my experience running PAIX when it was owned by MFN was not >>>> like you're saying. > > You might try TelX, we've had good luck with them. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From sthaug at nethelp.no Wed Feb 2 15:58:05 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 02 Feb 2011 22:58:05 +0100 (CET) Subject: quietly.... In-Reply-To: <20110203073657.2f616986@opy.nosense.org> References: <9E196E91-4086-4081-B7DC-D30C1589D9FC@sackheads.org> <20110203073657.2f616986@opy.nosense.org> Message-ID: <20110202.225805.74740442.sthaug@nethelp.no> > It's a bit of a shame that people who've gotten into networking in the > last 10 to 15 years haven't studied or worked with anything more than > IPv4. They've missed out on seeing a variety of different ways to solve > the same types of problems and therefore been exposed to the various > benefits and trade-offs of the different methods. With that sort of > exposure, people may find out that there are other better ways to > solve problems, but IPv4's limitations and constraints prevented them > being possible. Then there are some of us who *have* worked with other networking technologies (e.g. DECnet, XNS, Appletalk, X.25, etc) and *still* think that IPv6 is in many ways a horrible mess. IPv6 is at the same time both too much and not enough. It is "too much" because it is too different from IPv4, significantly slowing deployment and learning time. It is "not enough" because it really only solves one problem, namely address exhaustion - and not, for instance, the routing table explosion problem. (And don't get me started on the *claimed* advantages of IPv6, like "mandatory IPsec", "more efficient header processing" etc.) Steinar Haug, Nethelp consulting, sthaug at nethelp.no From marka at isc.org Wed Feb 2 16:04:33 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 03 Feb 2011 09:04:33 +1100 Subject: quietly.... In-Reply-To: Your message of "Wed, 02 Feb 2011 07:00:44 -0800." <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> Message-ID: <20110202220433.E0D1A9700A5@drugs.dv.isc.org> In message <9271A508-9B5E-4919-AC14-487B8C8E8617 at delong.com>, Owen DeLong write s: > > On Feb 2, 2011, at 6:17 AM, Iljitsch van Beijnum wrote: > > > On 2 feb 2011, at 14:10, Owen DeLong wrote: > >=20 > >>> I didn't say they were necessarily good routers. > >=20 > >> No, you said the router always knows better than the DHCP server. = > This is an example of a common case where > >> it does not. > >=20 > > If someone turns their box into a router they can also turn it into a = > DHCP server. This is what happens with IPv4. The solution is to filter = > these packets from fake routers in the switches. So ask your switch = > vendor for that feature in IPv6. > >=20 > Turns out that this is A LOT less common and when it does happen, it's = > easier to find and eliminate. > > >> It really isn't. If the DHCP server on a subnet could override the = > rogue routers RA messages by policy, then, it would actually make it = > fairly trivial to address this issue. > >=20 > > And who overrides the rogue DHCPv6 messages? Or is it turtles all the = > way down? > >=20 > Turns out to be quite a bit easier to isolate and remove the rogue DHCP = > server. > Also turns out that there isn't a single-checkbox way to accidentally = > create a DHCP server, unlike a rogue RA. > > >>> But there's so much wrong with DHCPv6 that trying to fix it is = > pretty much useless, we need to abandon DHCP and start from scratch. = > Good thing IPv6 works just fine without DHCPv6. > >=20 > >> This is a clear example of the myopia in the IETF that has operators = > so frustrated. > >=20 > > I can assure you that I'm quite alone within the IETF with that view. > >=20 > Then you have had impressive success at blocking useful development for = > a lone individual. > > > I'm not talking about the interaction between DHCPv6 and RAs here, = > just about how bad DHCPv6 is on its own terms. For instance, there's no = > client identifier or using MAC addresses to identify clients, this is = > now done with a DUID. Unfortunately, administrators have no way of = > knowing what DUID a given client is going to use so having a DHCPv6 = > server set up with information tailored to a specific client is really = > hard. There's also stateful and stateless DHCPv6, but it's the client = > that has to choose between them, while the server knows whether it's = > going to return stateful or stateless information. There's no prefix = > length in DHCPv6, so this needs to be learned from RAs. (Although it can = > be argued that because routers need to know this info anyway, having the = > prefix length there doesn't buy you anything.) > >=20 > I agree that there is much that needs to be improved in DHCPv6. The lack = > of a default router, however, is the broken part that causes the most = > difficulty in modern operations. > > > The problem with DHCP in general is that there is a continuous influx = > of new options but they all need to be encoded into a binary format = > inside a small packet. This info should be in an XML file on a HTTP = > server instead, rather than be overloaded into the connectivity = > bootstrapping. The problem with RA / DHCP is that RAs were built with = > some vague notion of what DHCP would do some day and then when DHCPv6 = > was developed half a decade later the evolving ideas didn't fit with the = > shape of the hole left in RAs anymore but that problem wasn't addressed = > at this time. Fixing that now (hopefully fixing it well, not doing = > stupid things like making DHCPv6 an IPv4 DHCP clone with all the IPv4 = > DHCP problems that we all suffer every day) means that we'll end up with = > three types of systems: > >=20 > We can agree to disagree about that. While it's true that there is a = > large number of options and the DHCP packet needs to remain relatively = > small, the reality is that no site uses all of them. They large number = > of options represents a superset of the differing needs of various = > sites. > > XML on HTTP is too much overhead for things a system needs to know at = > boot time to download its kernel. > > Operationally, DHCPv4 is just fine and is meeting the needs today. = > There's no reason we shouldn't have > at least equivalent functionality in DHCPv6. > > > - no DHCPv6 > > - legacy DHCPv6 > > - new DHCPv6 > >=20 > > Good luck trying to come up with a combination of RA and DHCP settings = > that make all three work well. Even without new DHCPv6, there's already = > 12 ways to set up RAs and DHCP and only a few combinations produce = > useful results. > > Yes... It really would be better if both SLAAC and DHCPv6 provided = > complete solutions and the operator could pick the single solution that = > worked best for them. > > Unfortunately, instead of looking at how things are used in the real = > world, IETF pursued some sort of theoretical purity exercise and we have = > two half-protocols that can't possibly provide a complete solution in = > either one. > > SLAAC fails because you can't get information about DNS, NTP, or = > anything other than a list of prefixes and a router that MIGHT actually = > be able to default-route your packets. > > DHCP fails because you can't get a default router out of it. > > Owen They didn't fail. They were designed to complement each other. It just that somewhere along the way people forgot that. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Wed Feb 2 16:18:25 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 03 Feb 2011 09:18:25 +1100 Subject: quietly.... In-Reply-To: Your message of "Wed, 02 Feb 2011 14:42:23 CDT." <25915.1296675743@localhost> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <5CB621E0-1873-47DC-B4EE-A5E2D6E5D5B4@sackheads.org> <25915.1296675743@localhost> Message-ID: <20110202221825.9EF3A970315@drugs.dv.isc.org> In message <25915.1296675743 at localhost>, Valdis.Kletnieks at vt.edu writes: > --==_Exmh_1296675743_5545P > Content-Type: text/plain; charset=us-ascii > > On Wed, 02 Feb 2011 14:30:23 EST, John Payne said: > > On Feb 2, 2011, at 3:16 AM, Iljitsch van Beijnum wrote: > > > Example: if you give administrators the option of putting a router > > > address in a DHCP option, they will do so and some fraction of the time, > > > this will be the wrong address and things don't work. If you let routers > > > announce their presence, then it's virtually impossible that something > > > goes wrong because routers know who they are. A clear win. Of course it > > > does mean that people have to learn something new when adopting > > > IPv6. > > > Is anyone else reading this and the word "condescending" _not_ popping > > into their heads? > > The only other charitable conclusion I can draw is "Somebody hasn't spent tim > e > chasing down people with misconfigured laptops on the wireless who are squawk > ing > RA's for 2002:" > > There's a *big* operational difference between "all authorized and properly c > onfigured > routers know who they are" and "all nodes that think they're routers (deluded > though > they may be) know who they are". Or you just filter them out in the laptop. With the proper tools you just ignore and RA's containing 2002:. Done that for years now. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From nick at foobar.org Wed Feb 2 16:21:05 2011 From: nick at foobar.org (Nick Hilliard) Date: Wed, 02 Feb 2011 22:21:05 +0000 Subject: quietly.... In-Reply-To: References: <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <53820806-5EF6-4E8D-900C-CDBEDB097E2E@sackheads.org> <9E196E91-4086-4081-B7DC-D30C1589D9FC@sackheads.org> <1397B616-F7F5-4212-B055-C0DFE1A99E3C@muada.com> <20110202211312.GA92881@ussenterprise.ufp.org> Message-ID: <4D49D8D1.80809@foobar.org> On 02/02/2011 21:26, Matt Addison wrote: > RA Guard has been described in RFC 6105 (still draft, but standards track), > so that particular problem should be taken care of once vendors start > shipping code. It doesn't even require SeND- although it does accomodate it. wonderful. In the interim, it is sheer lunacy to enable ipv6 on a large flat network if you can't synthesise ra guard with ipv6 packet filters. yes, there are some switches out there which do it already. They are very much in the minority. Nick From marka at isc.org Wed Feb 2 16:28:08 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 03 Feb 2011 09:28:08 +1100 Subject: quietly.... In-Reply-To: Your message of "Wed, 02 Feb 2011 14:48:14 CDT." References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <437F22E3-154B-4DD2-B37B-8BC54D116B40@delong.com> Message-ID: <20110202222808.7F0F4970371@drugs.dv.isc.org> In message , John Payne wri tes: > > On Feb 1, 2011, at 6:15 PM, Owen DeLong wrote: > > >=20 > > On Feb 1, 2011, at 2:56 PM, John Payne wrote: > >=20 > >>=20 > >>=20 > >> On Feb 1, 2011, at 4:38 PM, Owen DeLong wrote: > >>=20 > >>> NAT solves exactly one problem. It provides a way to reduce address = > consumption to work around a shortage of addresses. > >>>=20 > >>> It does not solve any other problem(s). > >>=20 > >>=20 > >> That's a bold statement. Especially as you said NAT and not PAT. > > > > NAT, PAT, whatever... I'm willing to back it up. > > NAT provides a solution to, lets call it, enterprise multihoming. = > Remote office with a local Internet connection, but failover through the = > corporate network. > In IPv4 this would likely be done with PAT, but I'm looking forward to = > being able to do something similar with NAT66 (or whatever it ends up = > being called) without blowing out my internal policies or having to = > maintain multiple addresses on each end point.= Or you could give them all two addresses and set the address selection policy so that when the local connection is up those addresses are used and when it is down the other addresses are used to source traffic. The router just send a RA with a prefix lifetime of zero when it looses upstream connectivity for that prefix putting all addresses on that prefix into deprecated state. Yes this is different to IPv4 and it doesn't require NAT66 to work. Just something to think about. IPv6 is different to IPv4. It has different capabilities. It offers different solutions to old problems. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From lowen at pari.edu Wed Feb 2 16:40:12 2011 From: lowen at pari.edu (Lamar Owen) Date: Wed, 2 Feb 2011 17:40:12 -0500 Subject: quietly.... In-Reply-To: <1397B616-F7F5-4212-B055-C0DFE1A99E3C@muada.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> Message-ID: <201102021740.12357.lowen@pari.edu> On Wednesday, February 02, 2011 03:55:30 pm Iljitsch van Beijnum wrote: > You can do that today. For instance, this is what I have in a test setup. (However, the ISC dhcpd can only do either v4 or v6, not both at the same time.) First, thanks for taking the time to reply. That is appreciated. With the op hat on...... I want to dual-stack DHCP with complete feature parity, and it be done with one DHCP server. The only thing I should, speaking as an operator, have to do is add the IPv6 stanzas to the working v4 config, restart, and dualstack DHCP Just Works. If I have to hack the code myself to do it..... (and, while I might not, someone will, standards or no standards. "If it don't work, make it work."). > > Instead, I'll have to completely relearn how dynamic allocation works, learn about and protect against a new attack vector > > You also get to stop worrying about a few old ones. As long as there's a dual stack, the vectors for v4 will work against the v4 portion of the stack. So, no, it ends up adding things to an already crowded plate. > I did this for routing. I can explain everything you need to know about how to run IPv6 BGP, RIP and OSPF in an hour and a half. Did that at a RIPE meeting some years ago. Setting up Apache to use IPv6 is one line of config. BIND two or three (not counting IPv6 reverse zones). Now, taking the op hat off for a moment, and stepping down from the soapbox, this is something that could be useful; has this talk been recorded and/or transcribed? If so, that's a useful resource, and, an hour and a half of relevant material is much easier to swallow than some of the books out there. If a book like Geoff Huston's excellent 'ISP Survival Guide' but for IPv6 (Hey, Geoff, is there an IPv6 version of your book?) were out there..... I know my 1999 edition of that book has seen plenty of use, mostly by people I loaned it out to when they asked me 'how does this thing called the Internet work?' A point-by-point "here's how you do in v6 that you're doing in v4" and "how to overlay your v6 subnets on RFC1918 NATted addresses without forklift upgrades in 12 easy steps" you might have an audience, as long as the first line of the book isn't "Everything you know is wrong." Even papers on how to rework your IPv4 network to more easily transition to dual-stack would be helpful (and those are probably out there; anybody got a cluepon page set up yet for those resources?) > There are some good books on running IPv6, you know. :-) I know. My book budget got cut almost completely out last year, as well as the budget for more bookshelves and floor space, so I'll have to finance those by selling off old ones. Anybody want a CiscoPress ATM book or ten? :-) From bjohnson at drtel.com Wed Feb 2 16:42:06 2011 From: bjohnson at drtel.com (Brian Johnson) Date: Wed, 2 Feb 2011 22:42:06 +0000 Subject: quietly.... In-Reply-To: <3CD3A697-8D3C-4EDE-8E4E-53C0E103E12C@sackheads.org> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <4D48E558.7070805@brightok.net> <2FD9EDE7-E28C-48E7-B6FB-8386773EF98E@delong.com> <9689E83C-048A-4D72-946B-978FB3C315A4@sackheads.org> , <3CD3A697-8D3C-4EDE-8E4E-53C0E103E12C@sackheads.org> Message-ID: I must have missed something. Why would u do NAT in IPv6? John Payne wrote: On Feb 2, 2011, at 2:54 PM, Owen DeLong wrote: > > On Feb 2, 2011, at 11:40 AM, John Payne wrote: > >> >> On Feb 2, 2011, at 6:18 AM, Owen DeLong wrote: >> >>> NAT66 is different. NAT66 breaks things in ways that impact sites outside of the site choosing to deploy NAT. >> >> Examples? > > SIP > Network enabled Video Games > Peer to Peer services of various forms > etc. I chose NAT66. How does that affect you or any other site? Note that I have already blocked games and peer to peer either technically or via policy.... and I have no SIP end points that have any business talking outside the enterprise. Just rephrasing you slightly. NAT66 will break applications that many enterprises will already have blocked at their perimeters. From jfbeam at gmail.com Wed Feb 2 16:53:48 2011 From: jfbeam at gmail.com (Ricky Beam) Date: Wed, 02 Feb 2011 17:53:48 -0500 Subject: quietly.... In-Reply-To: <20110202220433.E0D1A9700A5@drugs.dv.isc.org> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <20110202220433.E0D1A9700A5@drugs.dv.isc.org> Message-ID: On Wed, 02 Feb 2011 17:04:33 -0500, Mark Andrews wrote: > They didn't fail. They were designed to complement each other. It > just that somewhere along the way people forgot that. No. They failed. In all respects. The political agendas within IPng were anti-NAT and anti-DHCP. So they designed a system without either completely ignoring the way the real world works. NAT certainly has it's place, but I won't go on any crusades for it. DHCP, however, is an integral part of most networks today. And that's been the case for many years (decades even.) RA is the IPv6 version of stupidity we've forgotten existed in IPv4 -- ICMP router discovery. The idiots that dreamed up RA/SLAAC completely ignored the necessities of modern networking... hostnames, domain names, DNS resolvers, netboot information, ... In the first days, SLAAC looked great because you had IPv4 DHCP filling in everything else, and an IPv4 stack providing support for all that. Now we're seeing DHCPv6 bolted on after the fact. And it's a peicemeal band-aid after band-aid, instead of the logical process of taking DHCPv4 and making all the address fields bigger. If you did, then in one *poof* DHCPv6 would be able to deliver IPv6 addresses for *EVERYTHING* DHCPv4 can. But you still have to have that awefull RA spewed into your network to tell systems to use DHCPv6. --Ricky From jfbeam at gmail.com Wed Feb 2 16:58:48 2011 From: jfbeam at gmail.com (Ricky Beam) Date: Wed, 02 Feb 2011 17:58:48 -0500 Subject: quietly.... In-Reply-To: <20110202221825.9EF3A970315@drugs.dv.isc.org> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <5CB621E0-1873-47DC-B4EE-A5E2D6E5D5B4@sackheads.org> <25915.1296675743@localhost> <20110202221825.9EF3A970315@drugs.dv.isc.org> Message-ID: On Wed, 02 Feb 2011 17:18:25 -0500, Mark Andrews wrote: > Or you just filter them out in the laptop. With the proper tools you > just ignore and RA's containing 2002:. Done that for years now. Get back to me when you control every network device in the world. That may work for you. In your network. On devices you control. However, the brokenness is still there. --Ricky From lowen at pari.edu Wed Feb 2 17:03:06 2011 From: lowen at pari.edu (Lamar Owen) Date: Wed, 2 Feb 2011 18:03:06 -0500 Subject: quietly.... In-Reply-To: <20110202220433.E0D1A9700A5@drugs.dv.isc.org> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> Message-ID: <201102021803.06478.lowen@pari.edu> On Wednesday, February 02, 2011 05:04:33 pm Mark Andrews wrote: > They didn't fail. They were designed to complement each other. It > just that somewhere along the way people forgot that. My engineer brain looks at it this way: "The better is the enemy of the good." (Voltaire: "Le mieux est l'ennemi du bien."). I remember thinking back in my NetWare 2.x days that this thing called IP just needed the simplicity of IPX, with its native Layer 3 use of the MAC address..... boy, was I naive back then. Bridged ethernet across 56K leased lines with NetWare servers at the other end.... 3Com NetBuilders, and Vitalink's TransLAN III Bridges, I think. Been a long time. The TransLAN III device did the AUI interface to the 10Base5 LAN segments, IIRC. From owen at delong.com Wed Feb 2 17:52:37 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 2 Feb 2011 15:52:37 -0800 Subject: quietly.... In-Reply-To: <20110202221825.9EF3A970315@drugs.dv.isc.org> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <5CB621E0-1873-47DC-B4EE-A5E2D6E5D5B4@sackheads.org> <25915.1296675743@localhost> <20110202221825.9EF3A970315@drugs.dv.isc.org> Message-ID: <1FD74020-14CE-449C-A7C6-C6E9C9752E57@delong.com> On Feb 2, 2011, at 2:18 PM, Mark Andrews wrote: > > In message <25915.1296675743 at localhost>, Valdis.Kletnieks at vt.edu writes: >> --==_Exmh_1296675743_5545P >> Content-Type: text/plain; charset=us-ascii >> >> On Wed, 02 Feb 2011 14:30:23 EST, John Payne said: >>> On Feb 2, 2011, at 3:16 AM, Iljitsch van Beijnum wrote: >>>> Example: if you give administrators the option of putting a router >>>> address in a DHCP option, they will do so and some fraction of the time, >>>> this will be the wrong address and things don't work. If you let routers >>>> announce their presence, then it's virtually impossible that something >>>> goes wrong because routers know who they are. A clear win. Of course it >>>> does mean that people have to learn something new when adopting >>>> IPv6. >> >>> Is anyone else reading this and the word "condescending" _not_ popping >>> into their heads? >> >> The only other charitable conclusion I can draw is "Somebody hasn't spent tim >> e >> chasing down people with misconfigured laptops on the wireless who are squawk >> ing >> RA's for 2002:" >> >> There's a *big* operational difference between "all authorized and properly c >> onfigured >> routers know who they are" and "all nodes that think they're routers (deluded >> though >> they may be) know who they are". > > Or you just filter them out in the laptop. With the proper tools you just > ignore and RA's containing 2002:. Done that for years now. > That works when you're one technician on one laptop. Now, scale that solution to 10,000 $END_USERS on 12,000 laptops running at least 4 versions of at least 3 different operating systems (12 combinations minimum). Really? Owen From marka at isc.org Wed Feb 2 18:25:59 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 03 Feb 2011 11:25:59 +1100 Subject: quietly.... In-Reply-To: Your message of "Wed, 02 Feb 2011 15:13:21 CDT." <3CD3A697-8D3C-4EDE-8E4E-53C0E103E12C@sackheads.org> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <4D48E558.7070805@brightok.net> <2FD9EDE7-E28C-48E7-B6FB-8386773EF98E@delong.com> <9689E83C-048A-4D72-946B-978FB3C315A4@sackheads.org> <3CD3A697-8D3C-4EDE-8E4E-53C0E103E12C@sackheads.org> Message-ID: <20110203002559.D404E9715BC@drugs.dv.isc.org> In message <3CD3A697-8D3C-4EDE-8E4E-53C0E103E12C at sackheads.org>, John Payne writes: > > On Feb 2, 2011, at 2:54 PM, Owen DeLong wrote: > > >=20 > > On Feb 2, 2011, at 11:40 AM, John Payne wrote: > >=20 > >>=20 > >> On Feb 2, 2011, at 6:18 AM, Owen DeLong wrote: > >>=20 > >>> NAT66 is different. NAT66 breaks things in ways that impact sites = > outside of the site choosing to deploy NAT. > >>=20 > >> Examples? > >=20 > > SIP > > Network enabled Video Games > > Peer to Peer services of various forms > > etc. > > I chose NAT66. How does that affect you or any other site? > > Note that I have already blocked games and peer to peer either = > technically or via policy.... and I have no SIP end points that have any = > business talking outside the enterprise. Today you don't. Tomorrow you might. > Just rephrasing you slightly. NAT66 will break applications that many = > enterprises will already have blocked at their perimeters. And it makes applications they do use (current and future) more complicated as they have to deal with all the issues that arise from using a NAT'd address. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Wed Feb 2 18:39:00 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 03 Feb 2011 11:39:00 +1100 Subject: quietly.... In-Reply-To: Your message of "Wed, 02 Feb 2011 15:24:42 CDT." <09C9D1B8-F003-4932-ABC1-7299F81F1C29@sackheads.org> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <4D4979D1.4000104@phaze.org> <70C15FD9-CF85-4664-B913-3EBE4271C7F5@muada.com> <4D4982CC.7060100@otd.com> <01B5A647-AB05-4435-88FE-2F7535A644B2@muada.com> <09C9D1B8-F003-4932 -ABC1-7299F81F1C29@sackheads.org> Message-ID: <20110203003900.181C69716F0@drugs.dv.isc.org> In message <09C9D1B8-F003-4932-ABC1-7299F81F1C29 at sackheads.org>, John Payne writes: > > On Feb 2, 2011, at 3:15 PM, George Herbert wrote: > > > On Wed, Feb 2, 2011 at 8:55 AM, Iljitsch van Beijnum = > wrote: > >> On 2 feb 2011, at 17:14, Dave Israel wrote: > >>=20 > >>>> I understand people use DHCP for lots of stuff today. But that's = > mainly because DHCP is there, not because it's the best possible way to = > get that particular job done. > >>=20 > >>> So what if I want to assign different people to different resolvers = > by policy? > >>=20 > >> For the record: I'm not saying that DHCPv6 is never useful. DHCPv6 is = > intended as a stateful configuration provisioning tool, i.e., to give = > different hosts different configurations. If that's what you need then = > DHCP fits the bill. However, in most small scale environments this is = > not what's needed so DHCP doesn't fit the bill. > >=20 > > There are all sized enivronments. Political battles having partly > > crippled DHCPv6 in ways that end up significantly limiting IPv6 uptake > > into large enterprise organizations ... it's hard to describe how > > frustrating this is without resorting to thrown fragile objects > > against hard walls. As an active consultant to medium and large > > enterprises, this is driving me nuts. > >=20 > > This single item is in my estimation contributing at least 6, perhaps > > 12 months to the worldwide average delay in IPv6 uptake. I know > > several organizations that would have been there six months ago had > > DHCPv6 not had this flaw. They're currently 6-12 months from getting > > there. > > Well, to be fair... In my "decent sized" enterprise, DHCPv6 and the lack = > of default route is irritating but not the blocker. > The second largest OS we have doesn't support DHCPv6 at all, so its not = > like fixing the default route option is a magic bullet. So complain to the OS vendor. DHCPv6 should be there. DHCPv6 is many years old now. It's been part of the configuration model for a node for over a decade. > So, we're going to have DHCP for IPv4 and SLAAC for IPv6 for now. DNS, = > NTP, etc will be done over IPv4 - no way around that. > > We have vendor struggles. The current pain is the lack of good support = > for VRRPv3. RA guard is another.=20 > > However, IPv6 on the enterprise network will continue to be seen as an = > after thought until and unless we get parity.= -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Wed Feb 2 18:45:12 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 03 Feb 2011 11:45:12 +1100 Subject: quietly.... In-Reply-To: Your message of "Wed, 02 Feb 2011 21:55:30 BST." <1397B616-F7F5-4212-B055-C0DFE1A99E3C@muada.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <53820806-5EF6-4E8D-900C-CDBEDB097E2E@sackheads.org> <9E196E91-4086-4081-B7DC-D30C1589D9FC@sackheads.org> <1397B616-F7F5-4212-B055-C0DFE1A99E3C@muada.com> Message-ID: <20110203004512.47ED697176F@drugs.dv.isc.org> In message <1397B616-F7F5-4212-B055-C0DFE1A99E3C at muada.com>, Iljitsch van Beijnum write s: > On 2 feb 2011, at 21:36, Lamar Owen wrote: > > > > > What I want is to add an IPv6 subnet or subnets to my already tuned = > DHCP server config, add IPv6 addresses to the addresses handed out (in = > the same config clause as the IPv4 addresses are stored, preferably), = > update the DHCP server software to IPv6-capability, restart the DHCP = > server, and both IPv4 and IPv6 clients get what they need, through the = > same already locked down channels, with no other upgrades required. > > You can do that today. For instance, this is what I have in a test = > setup. (However, the ISC dhcpd can only do either v4 or v6, not both at = > the same time.) Which is a limitation that we intend to address. It was more time sensitive to get a DHCPv6 server out there than a integrated DHCPv4/DHCPv6 server. No date has been set for this yet. > subnet6 2001:960:7bf:d::/64 > { > option dhcp6.name-servers 2001:1af8:2:5::2; > option dhcp6.domain-search "bonjour.muada.nl"; > range6 2001:960:7bf:d::1000 2001:960:7bf:d::1fff; > } Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From owenc at hubris.net Wed Feb 2 18:56:10 2011 From: owenc at hubris.net (Chris Owen) Date: Wed, 2 Feb 2011 18:56:10 -0600 Subject: quietly.... In-Reply-To: References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <53820806-5EF6-4E8D-900C-CDBEDB097E2E@sackheads.org> <9E196E91-4086-4081-B7DC-D30C1589D9FC@sackheads.org> <1397B616-F7F5-4212-B055-C0DFE1A99E3C@muada.com> Message-ID: On Feb 2, 2011, at 3:09 PM, david raistrick wrote: > At least in ARIN territory, if you're multihomed, and you can show in-1-year use of 50% of a (v4) /24, you qualify for a PI v6 /48. One of the things I find frustrating about this is the cost of the space. We're a very small shop and to add IPv6 addresses for testing now we're looking at paying another $2,200 a year ($1,700 in the first year) when it will probably be some time before we actually _need_ the addresses. The waivers a few years were a nice start but why does the cost need to double ever? It isn't like ARIN needs the money, they have more than they can spend. Once we are a "member" and have IPv4 space, the marginal cost to ARIN of assigning the equivalent in IPv6 space is pretty close to zero. Maybe some sort of NRC but doubling the annual cost just doesn't make sense. At least with IPv4 you can make the argument that the cost is artificially high to control usage but with IPv6 there are no more scarcity issues. I'd love to add IPv6 to the network but it just rubs me the wrong way to have to pay $2,220 a year to do so for something that essentially has no cost. I can't imagine having to justify it to a bean counter. Chris -- ------------------------------------------------------------------------- Chris Owen - Garden City (620) 275-1900 - Lottery (noun): President - Wichita (316) 858-3000 - A stupidity tax Hubris Communications Inc www.hubris.net ------------------------------------------------------------------------- From drais at icantclick.org Wed Feb 2 19:03:28 2011 From: drais at icantclick.org (david raistrick) Date: Wed, 2 Feb 2011 20:03:28 -0500 (EST) Subject: quietly.... In-Reply-To: References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <53820806-5EF6-4E8D-900C-CDBEDB097E2E@sackheads.org> <9E196E91-4086-4081-B7DC-D30C1589D9FC@sackheads.org> <1397B616-F7F5-4212-B055-C0DFE1A99E3C@muada.com> Message-ID: On Wed, 2 Feb 2011, Chris Owen wrote: > On Feb 2, 2011, at 3:09 PM, david raistrick wrote: > >> At least in ARIN territory, if you're multihomed, and you can show >> in-1-year use of 50% of a (v4) /24, you qualify for a PI v6 /48. > One of the things I find frustrating about this is the cost of the > space. We're a very small shop and to add IPv6 addresses for testing > now we're looking at paying another $2,200 a year ($1,700 in the first Ooof. I didn't get that far - and hadn't realized the waiver was expired. That's a pretty signficant barrier to entry. :( -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From carlosm3011 at gmail.com Wed Feb 2 19:07:03 2011 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Wed, 2 Feb 2011 23:07:03 -0200 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: References: <1296089078.6522.194.camel@karl> <5D2659F3-5853-4C1C-A26D-D6EB5AA75195@delong.com> <4D4820E1.20600@brightok.net> <077208EB-39DF-4F51-B263-E1BEB0BCE75A@delong.com> <4D48454A.1090807@brightok.net> <4D488FF8.4010106@brightok.net> <8998E21B-14FB-45A8-A849-D1416E946505@delong.com> <20110201233846.GV13890@angus.ind.WPI.EDU> Message-ID: Disconnected networks have a bothersome tendency to get connected at some point ( I have been severely bitten by this in the past ), so while I agree that there is no need to coordinate anything globally, then a RFC 1918-like definition would be nice (if we are not going to use ULAs, that is) cheers! Carlos On Tue, Feb 1, 2011 at 11:59 PM, Owen DeLong wrote: > > On Feb 1, 2011, at 3:38 PM, Chuck Anderson wrote: > >> On Tue, Feb 01, 2011 at 03:14:57PM -0800, Owen DeLong wrote: >>> On Feb 1, 2011, at 2:58 PM, Jack Bates wrote: >>>> There are many cases where ULA is a perfect fit, and to work >>>> around it seems silly and reduces the full capabilities of IPv6. I >>>> fully expect to see protocols and networks within homes which will >>>> take full advantage of ULA. I also expect to see hosts which don't >>>> talk to the public internet directly and never need a GUA. >>>> >>> I guess we can agree to disagree about this. I haven't seen one yet. >> >> What would your recommended solution be then for disconnected >> networks? ?Every home user and enterprise user requests GUA directly >> from their RIR/NIR/LIR at a cost of hunderds of dollars per year or >> more? > > For a completely disconnected network, I don't care what you do, > use whatever number you want. There's no need to coordinate that > with the internet in any way. > > For a network connected to a connected network, either get GUA from > an RIR or get GUA from the network you are connected to or get > GUA from some other ISP/LIR. > > There are lots of options. > > I'd like to see RIR issued GUA get a lot cheaper. I'd much rather see > cheap easy to get RIR issued GUA than see ULA get widespread use. > > Owen > > > -- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net ========================= From brandon at rd.bbc.co.uk Wed Feb 2 19:10:48 2011 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Thu, 3 Feb 2011 01:10:48 GMT Subject: quietly.... Message-ID: <201102030110.BAA19803@sunf10.rd.bbc.co.uk> > > You can do that today. For instance, this is what I have in a test = > > setup. (However, the ISC dhcpd can only do either v4 or v6, not both at = > > the same time.) > > Which is a limitation that we intend to address. It was more time > sensitive to get a DHCPv6 server out there than a integrated > DHCPv4/DHCPv6 server. No date has been set for this yet. > > > subnet6 2001:960:7bf:d::/64 > > { > > option dhcp6.name-servers 2001:1af8:2:5::2; > > option dhcp6.domain-search "bonjour.muada.nl"; > > range6 2001:960:7bf:d::1000 2001:960:7bf:d::1fff; > > } Just need to add default route in there and make dhcpd do RA then the user can turn off RA on their routers and not care that DHCPv6 doesn't include default router. Future proof, if/when it gets added natively too it'll just carry on with no reconfig. brandon From owen at delong.com Wed Feb 2 19:14:11 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 2 Feb 2011 17:14:11 -0800 Subject: quietly.... In-Reply-To: References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <53820806-5EF6-4E8D-900C-CDBEDB097E2E@sackheads.org> <9E196E91-4086-4081-B7DC-D30C1589D9FC@sackheads.org> <1397B616-F7F5-4212-B055-C0DFE1A99E3C@muada.com> Message-ID: <44DDE580-2B01-46A3-B424-66468A6BA026@delong.com> On Feb 2, 2011, at 5:03 PM, david raistrick wrote: > On Wed, 2 Feb 2011, Chris Owen wrote: > >> On Feb 2, 2011, at 3:09 PM, david raistrick wrote: >> >>> At least in ARIN territory, if you're multihomed, and you can show in-1-year use of 50% of a (v4) /24, you qualify for a PI v6 /48. > >> One of the things I find frustrating about this is the cost of the space. We're a very small shop and to add IPv6 addresses for testing now we're looking at paying another $2,200 a year ($1,700 in the first > > Ooof. I didn't get that far - and hadn't realized the waiver was expired. > > That's a pretty signficant barrier to entry. :( > Um, I think you guys are mistaken... You're talking about ISP pricing, not end-user pricing. End user, a /48 will cost you $1,250 one-time and then it's part of your usual $100/year that you would be paying if you had an ASN or IPv4 space anyway. Owen From marka at isc.org Wed Feb 2 19:20:18 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 03 Feb 2011 12:20:18 +1100 Subject: quietly.... In-Reply-To: Your message of "Wed, 02 Feb 2011 17:58:48 CDT." References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <5CB621E0-1873-47DC-B4EE-A5E2D6E5D5B4@sackheads.org> <25915.1296675743@localhost> <20110202221825.9EF3A970315@drugs.dv.isc.org> Message-ID: <20110203012018.6E526971AA1@drugs.dv.isc.org> In message , "Ricky Beam" writes: > On Wed, 02 Feb 2011 17:18:25 -0500, Mark Andrews wrote: > > Or you just filter them out in the laptop. With the proper tools you > > just ignore and RA's containing 2002:. Done that for years now. > > Get back to me when you control every network device in the world. > > That may work for you. In your network. On devices you control. > However, the brokenness is still there. And rogue DHCP servers also exist. The reason you see lots of rouge 2002: prefixes announcements is that ISP's havn't delivered IPv6 so people have routed around them and turned on 6to4 on their machines. The problem will mostly go away once consumer ISP's get off their butts and actually deliver IPv6 when their customer asked for it (I've been asking this of my ISP for the last 7 or so years and I suspect I was not alone). This is industry self inflicted pain. As for hosts swithing over to the new prefix immediately I suspect a lot of that will go away as the host OS's mature. Just selecting the router by matching it prefix announcements to the source address will keep existing sessions going. It also works better with bcp38 filters. Add rules which depreference 2002: source addresses and you won't notice these RA's anymore (this part already exists). In Leo's case the source address selection part wouldn't have helped but Leo's case is the router wouldn't have had a 2002 address but this senario is also rarer. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From cb.list6 at gmail.com Wed Feb 2 19:21:25 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Wed, 2 Feb 2011 17:21:25 -0800 Subject: quietly.... In-Reply-To: References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <53820806-5EF6-4E8D-900C-CDBEDB097E2E@sackheads.org> <9E196E91-4086-4081-B7DC-D30C1589D9FC@sackheads.org> <1397B616-F7F5-4212-B055-C0DFE1A99E3C@muada.com> Message-ID: On Wed, Feb 2, 2011 at 5:03 PM, david raistrick wrote: > On Wed, 2 Feb 2011, Chris Owen wrote: > >> On Feb 2, 2011, at 3:09 PM, david raistrick wrote: >> >>> At least in ARIN territory, if you're multihomed, and you can show >>> in-1-year use of 50% of a (v4) /24, you qualify for a PI v6 /48. > >> One of the things I find frustrating about this is the cost of the space. >> ?We're a very small shop and to add IPv6 addresses for testing now we're >> looking at paying another $2,200 a year ($1,700 in the first > > Ooof. ? I didn't get that far - and hadn't realized the waiver was expired. > > That's a pretty signficant barrier to entry. :( > Not sure of all your requirements, but you can use PA space. It is generally free if you are just looking for an entry into the v6 world. It may not fit for you, just saying ... I use PA in places where it works. Cameron From rcarpen at network1.net Wed Feb 2 19:22:34 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Wed, 2 Feb 2011 20:22:34 -0500 (EST) Subject: quietly.... In-Reply-To: <44DDE580-2B01-46A3-B424-66468A6BA026@delong.com> Message-ID: <17286018.1914.1296696154135.JavaMail.root@zimbra.network1.net> > >> One of the things I find frustrating about this is the cost of the > >> space. We're a very small shop and to add IPv6 addresses for > >> testing now we're looking at paying another $2,200 a year ($1,700 > >> in the first > > > > Ooof. I didn't get that far - and hadn't realized the waiver was > > expired. > > > > That's a pretty signficant barrier to entry. :( > > > Um, I think you guys are mistaken... > > You're talking about ISP pricing, not end-user pricing. > > End user, a /48 will cost you $1,250 one-time and then it's part of > your usual $100/year that you would be > paying if you had an ASN or IPv4 space anyway. > > Owen And, even if you are an ISP, you only pay the larger of the two fees if you have both v4 and v6. I'm not sure if that is permanent or not, though. -Randy From owenc at hubris.net Wed Feb 2 19:46:14 2011 From: owenc at hubris.net (Chris Owen) Date: Wed, 2 Feb 2011 19:46:14 -0600 Subject: quietly.... In-Reply-To: <17286018.1914.1296696154135.JavaMail.root@zimbra.network1.net> References: <17286018.1914.1296696154135.JavaMail.root@zimbra.network1.net> Message-ID: <92484528-AB9D-408A-8F1E-1D59A80DC469@hubris.net> On Feb 2, 2011, at 7:22 PM, Randy Carpenter wrote: > And, even if you are an ISP, you only pay the larger of the two fees if you have both v4 and v6. I'm not sure if that is permanent or not, though. I thought that was part of the "waiver" stuff that expires this year. Chris -- ------------------------------------------------------------------------- Chris Owen - Garden City (620) 275-1900 - Lottery (noun): President - Wichita (316) 858-3000 - A stupidity tax Hubris Communications Inc www.hubris.net ------------------------------------------------------------------------- From rcarpen at network1.net Wed Feb 2 20:38:10 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Wed, 2 Feb 2011 21:38:10 -0500 (EST) Subject: quietly.... In-Reply-To: <92484528-AB9D-408A-8F1E-1D59A80DC469@hubris.net> Message-ID: <1906085828.1923.1296700690262.JavaMail.root@zimbra.network1.net> >From the main section on https://www.arin.net/fees/fee_schedule.html: "... ISPs with both IPv4 resources and IPv6 resources pay the larger of the two fees." It is not mentioned anywhere in the waiver stuff. -Randy -- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1 ---- ----- Original Message ----- > On Feb 2, 2011, at 7:22 PM, Randy Carpenter wrote: > > > And, even if you are an ISP, you only pay the larger of the two fees > > if you have both v4 and v6. I'm not sure if that is permanent or > > not, though. > > I thought that was part of the "waiver" stuff that expires this year. > > Chris > > -- > ------------------------------------------------------------------------- > Chris Owen - Garden City (620) 275-1900 - Lottery (noun): > President - Wichita (316) 858-3000 - A stupidity tax > Hubris Communications Inc www.hubris.net > ------------------------------------------------------------------------- From owenc at hubris.net Wed Feb 2 20:46:06 2011 From: owenc at hubris.net (Chris Owen) Date: Wed, 2 Feb 2011 20:46:06 -0600 Subject: quietly.... In-Reply-To: <1906085828.1923.1296700690262.JavaMail.root@zimbra.network1.net> References: <1906085828.1923.1296700690262.JavaMail.root@zimbra.network1.net> Message-ID: <54A021B6-5765-4A38-88B7-62278AFAD2F1@hubris.net> On Feb 2, 2011, at 8:38 PM, Randy Carpenter wrote: > From the main section on https://www.arin.net/fees/fee_schedule.html: > > "... ISPs with both IPv4 resources and IPv6 resources pay the larger of the two fees." > > It is not mentioned anywhere in the waiver stuff. Actually it is in the waiver stuff but I didn't see it at the top too. That's much more reasonable. Chris -- ------------------------------------------------------------------------- Chris Owen - Garden City (620) 275-1900 - Lottery (noun): President - Wichita (316) 858-3000 - A stupidity tax Hubris Communications Inc www.hubris.net ------------------------------------------------------------------------- From george.herbert at gmail.com Wed Feb 2 21:25:28 2011 From: george.herbert at gmail.com (George Herbert) Date: Wed, 2 Feb 2011 19:25:28 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: References: <1296089078.6522.194.camel@karl> <5D2659F3-5853-4C1C-A26D-D6EB5AA75195@delong.com> <4D4820E1.20600@brightok.net> <077208EB-39DF-4F51-B263-E1BEB0BCE75A@delong.com> <4D48454A.1090807@brightok.net> <4D488FF8.4010106@brightok.net> <8998E21B-14FB-45A8-A849-D1416E946505@delong.com> <20110201233846.GV13890@angus.ind.WPI.EDU> Message-ID: On Wed, Feb 2, 2011 at 5:07 PM, Carlos Martinez-Cagnazzo wrote: > Disconnected networks have a bothersome tendency to get connected at > some point ( I have been severely bitten by this in the past ), so > while I agree that there is no need to coordinate anything globally, > then a RFC 1918-like definition would be nice (if we are not going to > use ULAs, that is) If possible, I would argue to go further than that. Every couple of years, interconnecting organizations that used 1918 space on the back end and later turned out to need to talk to each other *and had 1918 usage conflicts* has been part of my painful world. 1918 defined both a useful private range and a space anyone could expand into if standard v4 allocations weren't enough and you weren't trying to directly route those systems. A lot of people used "useful private range" as a cover for "expanding into". Push people to get proper public assigned v6 allocations for private use going forwards. Many of them will need to interconnect them later. We know better now, and we won't exhaust anything doing so. Globally allocated != globally routed. -- -george william herbert george.herbert at gmail.com From jra at baylink.com Wed Feb 2 22:31:34 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 2 Feb 2011 23:31:34 -0500 (EST) Subject: quietly.... In-Reply-To: Message-ID: <31501371.4291.1296707494566.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "david raistrick" > On Tue, 1 Feb 2011, Dave Israel wrote: > > > responsibility. If they want to use DHCPv6, or NAT, or Packet over > > Avian > > Carrier to achieve that, let them. If using them causes them > > problems, then > > they should not use them. It really isn't the community's place to > > force > > people not to use tools they find useful because we do not like > > them. > > Not to mention that when you take tools -away- from people that solve > an existing problem, you'll get a lot of pushback. I, personally, have been waiting to hear what happens when network techs discover that they can't carry IP addresses around in their heads anymore. That sounds trivial, perhaps, but I don't think it will be. Cheers, -- jr 'dirty little secret' a From jra at baylink.com Wed Feb 2 22:34:52 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 2 Feb 2011 23:34:52 -0500 (EST) Subject: quietly.... In-Reply-To: <93FDC643-D434-4D3B-9E01-3FE5FB1080F9@delong.com> Message-ID: <12182006.4293.1296707692487.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > If you're determined to destroy IPv6 by bringing the problems of NAT > forward with you, then, I'm fine with you remaining in your IPv4 > island. I'm willing to bet that most organizations will embrace an > internet unencumbered by the brokenness that is NAT and move forward. > I do not think that lack of NAT has been a significant barrier to IPv6 > adoption, nor do I think it will be. I won't run an edge-network that *isn't* NATted; my internal machines have no business having publicly routable addresses. No one has *ever* provided me with a serviceable explanation as to why that's an invalid view. Cheers, -- jra From ikiris at gmail.com Wed Feb 2 22:41:54 2011 From: ikiris at gmail.com (Blake Dunlap) Date: Wed, 2 Feb 2011 22:41:54 -0600 Subject: quietly.... In-Reply-To: <12182006.4293.1296707692487.JavaMail.root@benjamin.baylink.com> References: <93FDC643-D434-4D3B-9E01-3FE5FB1080F9@delong.com> <12182006.4293.1296707692487.JavaMail.root@benjamin.baylink.com> Message-ID: On Wed, Feb 2, 2011 at 22:34, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Owen DeLong" > > > If you're determined to destroy IPv6 by bringing the problems of NAT > > forward with you, then, I'm fine with you remaining in your IPv4 > > island. I'm willing to bet that most organizations will embrace an > > internet unencumbered by the brokenness that is NAT and move forward. > > I do not think that lack of NAT has been a significant barrier to IPv6 > > adoption, nor do I think it will be. > > I won't run an edge-network that *isn't* NATted; my internal machines > have no business having publicly routable addresses. No one has *ever* > provided me with a serviceable explanation as to why that's an invalid > view. > > Cheers, > -- jra > > Quite simply, its called Tragedy of the Commons. Everyone else has to work harder to provide you services if you are using something which breaks end to end connectivity, which costs everyone else money. The protocol designers are making a stand against this for the good of the "commons". -Blake From jra at baylink.com Wed Feb 2 22:45:49 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 2 Feb 2011 23:45:49 -0500 (EST) Subject: quietly.... In-Reply-To: Message-ID: <10058800.4297.1296708348990.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Blake Dunlap" > On Wed, Feb 2, 2011 at 22:34, Jay Ashworth wrote: > > > I won't run an edge-network that *isn't* NATted; my internal machines > > have no business having publicly routable addresses. No one has *ever* > > provided me with a serviceable explanation as to why that's an > > invalid view. > Quite simply, its called Tragedy of the Commons. Everyone else has to > work harder to provide you services if you are using something which breaks > end to end connectivity, which costs everyone else money. The protocol > designers are making a stand against this for the good of the "commons". You'll have to document "everyone has to work harder to provide me services"; this is not my first rodeo, and TTBOMK, it's *transparent* to the other end of any connection out of my edge network that it's NATted at my end. As for incoming connections, it's transparent to them as well -- and which ones are valid targets for such connections *is a policy decision of mine*, not subject to external opinion. Could you clarify, in some detail, precisely how you get to TotC, Blake? Cheers, -- jra From mysidia at gmail.com Wed Feb 2 22:47:54 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 2 Feb 2011 22:47:54 -0600 Subject: quietly.... In-Reply-To: <201102030110.BAA19803@sunf10.rd.bbc.co.uk> References: <201102030110.BAA19803@sunf10.rd.bbc.co.uk> Message-ID: On Wed, Feb 2, 2011 at 7:10 PM, Brandon Butterworth wrote: > > Just need to add default route in there and make dhcpd do RA > then the user can turn off RA on their routers and not care > that DHCPv6 doesn't include default router. > Having a DHCP server generate RA messages kind of defeats the point of having RA messages in the first place, resulting in loss of robustness, and now a new mode of failure. The point of having RA messages is they are simple, and integrated into the routers, so there is not a separate server to fail (a "DHCP server") to cause loss of connectivity, due to server appliances (computers) being less reliable than routers. With the RA integrated into the routers properly, clients can maintain connectivity (and establish connectivity, provided DNS details obtained in the past), even if DHCP server(s) should fail. -- -JH From marka at isc.org Wed Feb 2 23:08:15 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 03 Feb 2011 16:08:15 +1100 Subject: quietly.... In-Reply-To: Your message of "Wed, 02 Feb 2011 23:45:49 CDT." <10058800.4297.1296708348990.JavaMail.root@benjamin.baylink.com> References: <10058800.4297.1296708348990.JavaMail.root@benjamin.baylink.com> Message-ID: <20110203050815.70FC0977343@drugs.dv.isc.org> In message <10058800.4297.1296708348990.JavaMail.root at benjamin.baylink.com>, Jay Ashwor th writes: > ----- Original Message ----- > > From: "Blake Dunlap" > > > On Wed, Feb 2, 2011 at 22:34, Jay Ashworth wrote: > > > > > I won't run an edge-network that *isn't* NATted; my internal machines > > > have no business having publicly routable addresses. No one has *ever* > > > provided me with a serviceable explanation as to why that's an > > > invalid view. > > > Quite simply, its called Tragedy of the Commons. Everyone else has to > > work harder to provide you services if you are using something which breaks > > end to end connectivity, which costs everyone else money. The protocol > > designers are making a stand against this for the good of the "commons". > > You'll have to document "everyone has to work harder to provide me services"; > this is not my first rodeo, and TTBOMK, it's *transparent* to the other end > of any connection out of my edge network that it's NATted at my end. > > As for incoming connections, it's transparent to them as well -- and which > ones are valid targets for such connections *is a policy decision of > mine*, not subject to external opinion. > > Could you clarify, in some detail, precisely how you get to TotC, Blake? > > Cheers, > -- jra You are going to want the your clients to work well with your NAT. Your vendor is going to have to spend money to do this. The cost of doing this will be passed onto everyone else that buys this client as a direct monetory cost and/or extra complexity in the product. The later also increases the cost in maintaining the product. It also stops the vendor developing other products as it takes additional resources to do this work. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mysidia at gmail.com Wed Feb 2 23:10:22 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 2 Feb 2011 23:10:22 -0600 Subject: quietly.... In-Reply-To: <12182006.4293.1296707692487.JavaMail.root@benjamin.baylink.com> References: <93FDC643-D434-4D3B-9E01-3FE5FB1080F9@delong.com> <12182006.4293.1296707692487.JavaMail.root@benjamin.baylink.com> Message-ID: On Wed, Feb 2, 2011 at 10:34 PM, Jay Ashworth wrote: [snip] > I won't run an edge-network that *isn't* NATted; my internal machines > have no business having publicly routable addresses. ?No one has *ever* > provided me with a serviceable explanation as to why that's an invalid > view. If you want to provide an edge network IPv6 connectivity with no routable address space, then use a proxy server / application layer gateway for every allowed application. SOCKS5 can be used to forward any TCP based protocol, and most UDP protocols, other UDP protocols do not actually function correctly in NAT environments anyways (neither do protocols such as FTP which require client side to accept port bound connections). There's no reason for the internet community to re-design every protocol to allow and try to function in a NAT environment, for the benefit of a small number of edge networks, who want a private castle with hosts on their network not connected to the internet, for no reason that has been adequately justified. In IPv4, this had to be accepted, because with limited IP address space, it was not an option to have no NAT. Now with IPv6 it is not an option to have NAT. No one has ever provided me with a serviceable explanation of why a stateful firewall is an insufficient method for implementing any desired network policy, with regards to limiting accepted traffic to outbound connections for nodes on an edge network. > -- jra -- -JH From mpalmer at hezmatt.org Wed Feb 2 23:13:11 2011 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Thu, 3 Feb 2011 16:13:11 +1100 Subject: quietly.... In-Reply-To: <10058800.4297.1296708348990.JavaMail.root@benjamin.baylink.com> References: <10058800.4297.1296708348990.JavaMail.root@benjamin.baylink.com> Message-ID: <20110203051311.GA24798@hezmatt.org> On Wed, Feb 02, 2011 at 11:45:49PM -0500, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Blake Dunlap" > > > On Wed, Feb 2, 2011 at 22:34, Jay Ashworth wrote: > > > > > I won't run an edge-network that *isn't* NATted; my internal machines > > > have no business having publicly routable addresses. No one has *ever* > > > provided me with a serviceable explanation as to why that's an > > > invalid view. > > > Quite simply, its called Tragedy of the Commons. Everyone else has to > > work harder to provide you services if you are using something which breaks > > end to end connectivity, which costs everyone else money. The protocol > > designers are making a stand against this for the good of the "commons". > > You'll have to document "everyone has to work harder to provide me services"; > this is not my first rodeo, and TTBOMK, it's *transparent* to the other end > of any connection out of my edge network that it's NATted at my end. > > As for incoming connections, it's transparent to them as well -- and which > ones are valid targets for such connections *is a policy decision of > mine*, not subject to external opinion. You're thinking too small -- it's not that individual TCP connections have problems, it's that the ability to solve a given problem using connections and UDP packets is badly constrained by a lack of end-to-end connectivity. The proof is fairly obvious in the number of hacks that have been deployed to try and get around NAT's inadequacies: Skype supernodes, STUN, all the various conntrack helpers in netfilters, etc etc etc. Now, if you decide that none of those applications are important to you, sure, you can firewall them off as appropriate. But the pervasive deployment of NAT means that the set of problems that can be solved is constrained, and of the problems that *can* be solved, the solutions tend to be more complicated, harder to implement, understand, and so on, which has a cost to the community (higher prices, less solved problems, whatever your desired metric may be). I think that's what Blake is getting at with his TotC. Of course, I'm a tiny bit of a skeptic, as I really can't see how a stateful firewall can know which other connections / packets are related without a lot of the same dodgy shenanigans that goes on now, but at least if you've gotten rid of the 1-to-N address mangling a fundamental stumbling block is removed and people can get on and solve the remaining (tractable) problems. - Matt From jra at baylink.com Wed Feb 2 23:14:55 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 3 Feb 2011 00:14:55 -0500 (EST) Subject: quietly.... In-Reply-To: <20110203050815.70FC0977343@drugs.dv.isc.org> Message-ID: <12326660.4311.1296710095252.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Mark Andrews" > > You'll have to document "everyone has to work harder to provide me > > services"; > > this is not my first rodeo, and TTBOMK, it's *transparent* to the > > other end > > of any connection out of my edge network that it's NATted at my end. > > > > As for incoming connections, it's transparent to them as well -- and > > which > > ones are valid targets for such connections *is a policy decision of > > mine*, not subject to external opinion. > > > > Could you clarify, in some detail, precisely how you get to TotC, > > Blake? > > You are going to want the your clients to work well with your NAT. > Your vendor is going to have to spend money to do this. The cost > of doing this will be passed onto everyone else that buys this > client as a direct monetory cost and/or extra complexity in the > product. The later also increases the cost in maintaining the > product. It also stops the vendor developing other products as it > takes additional resources to do this work. So far as I can tell, Mark, the only place where this becomes an issue is in the design of protocols which violate layer independence[1] by baking external transport layer address into fields in higher-layer frames; this in inherently Broken As Designed, and isn't my fault, or problem. I'll point out that such protocols will have to be fixed *anyway*, as transitioning to IPv6 will break them as well. If you merely meant "client operating systems", then I'm going back to "transparent"; please itemize how NAT at the edge of my edge network negatively affects the operations of a client OS, absent the specific broken protocols mentioned above. Next argument? :-) Cheers, -- jra [1] I originally wrote "lawyer independence"; that's funny, but too far off-meaning to leave in. :-) From jra at baylink.com Wed Feb 2 23:18:43 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 3 Feb 2011 00:18:43 -0500 (EST) Subject: quietly.... In-Reply-To: Message-ID: <1899106.4313.1296710323930.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jimmy Hess" > There's no reason for the internet community to re-design every > protocol to allow and > try to function in a NAT environment, for the benefit of a small > number of edge networks, > who want a private castle with hosts on their network not connected > to the internet, > for no reason that has been adequately justified. Justify, yourself in turn, "small number". My personal estimate of the number of NATted edge networks is well north of 75%, on a network count basis. > No one has ever provided me with a serviceable explanation of why a > stateful firewall > is an insufficient method for implementing any desired network policy, > with > regards to limiting accepted traffic to outbound connections for nodes > on an edge network. Complexity of the configuration vastly increases the size of the attack surface: in a NATted edge network, *no packets can come in unless I explicitly configure for them*; there are any number of reasons why an equivalently simply assertion cannot be made concerning the configuration of firewalls, of whatever type or construction. In a firewall, you are *fighting* the default "route this packet" design; in a NATgate, you have to consciously throw the packets over the moat. I've never been clear why this isn't intiutively obvious to the people with whom I have to have this argument. Cheers, -- jra From jra at baylink.com Wed Feb 2 23:23:54 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 3 Feb 2011 00:23:54 -0500 (EST) Subject: quietly.... In-Reply-To: <20110203051311.GA24798@hezmatt.org> Message-ID: <12428586.4315.1296710634343.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Matthew Palmer" > You're thinking too small -- it's not that individual TCP connections > have > problems, it's that the ability to solve a given problem using > connections > and UDP packets is badly constrained by a lack of end-to-end > connectivity. > The proof is fairly obvious in the number of hacks that have been > deployed > to try and get around NAT's inadequacies: Skype supernodes, STUN, all > the > various conntrack helpers in netfilters, etc etc etc. At last, some meat. :-) > Now, if you decide that none of those applications are important to > you, > sure, you can firewall them off as appropriate. But the pervasive > deployment of NAT means that the set of problems that can be solved is > constrained, and of the problems that *can* be solved, the solutions > tend to > be more complicated, harder to implement, understand, and so on, which > has a > cost to the community (higher prices, less solved problems, whatever > your > desired metric may be). I think that's what Blake is getting at with > his TotC. Perhaps. I'm not sure that the collective importance of that difficulty outweighs the collective danger of making all nodes of the Internet *as it presently exists* publicly routable. I don't know whether it's occurred to people that if you make every node on the present day Internet routable, then *you've made every node on the present day Internet routable*; the number of machines subject to more or less direct attack goes up (by a jackleg estimate I've just now made up) by between 3 and 5 orders of magnitude. I make jackleg estimates all the time; I don't believe I've ever had to say "5 orders of magnitude". > Of course, I'm a tiny bit of a skeptic, as I really can't see how a > stateful > firewall can know which other connections / packets are related > without a > lot of the same dodgy shenanigans that goes on now, but at least if > you've > gotten rid of the 1-to-N address mangling a fundamental stumbling > block is > removed and people can get on and solve the remaining (tractable) > problems. That is problematic as well, isn't it? It speaks directly to the attack-surface comment I just made in another reply. I'm going to bed now, which will reduce the number of replies the "aw crap, is he really going to beat this dead horse again?" crowd will have to skip. :-) Cheers, -- jra From mysidia at gmail.com Wed Feb 2 23:37:14 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 2 Feb 2011 23:37:14 -0600 Subject: quietly.... In-Reply-To: <1899106.4313.1296710323930.JavaMail.root@benjamin.baylink.com> References: <1899106.4313.1296710323930.JavaMail.root@benjamin.baylink.com> Message-ID: On Wed, Feb 2, 2011 at 11:18 PM, Jay Ashworth wrote: > Justify, yourself in turn, "small number". ?My personal estimate of the > number of NATted edge networks is well north of 75%, on a network count You don't get to count all NAT'ed IPv4 edge networks the same. Only the number of NAT'ed edge networks that decide they don't want to have normal connectivity for their IPs, even with IP address space available to, and even after reading up on IPv6. > Complexity of the configuration vastly increases the size of the > attack surface: in a NATted edge network, *no packets can come in > unless I explicitly configure for them*; there are any number of Not necessarily true. This is a case of 'wish it were secure', but can't prove it. It is possible that a client on a NAT'ed network can conspire with an intruder to defeat the NAT device, and in various cases NAT can be completely defeated by an outsider, without a direct conspiracy. Any device on the subnet can spoof a SYN packet from any other device on the subnet. The NAT device will now have a connection entry, and the intruder can use this to circumvent the NAT. A good stateful firewall can prevent this and a few other similar shenanigans. But if the NAT device does not have a true stateful firewall function integrated, it is not nearly as secure as it might at first appear. > In a firewall, you are *fighting* the default "route this packet" > design; in a NATgate, you have to consciously throw the packets > over the moat. It sounds like you have a lousy firewall. Decent stateful firewalls deny all incoming traffic by default that does not go with an outbound connection, until policies have been established. It's possible you can make an erroneous access rule, but you can also make an erroneous port forward on a NAT device. -- -JH From mpalmer at hezmatt.org Wed Feb 2 23:53:30 2011 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Thu, 3 Feb 2011 16:53:30 +1100 Subject: quietly.... In-Reply-To: <12428586.4315.1296710634343.JavaMail.root@benjamin.baylink.com> References: <20110203051311.GA24798@hezmatt.org> <12428586.4315.1296710634343.JavaMail.root@benjamin.baylink.com> Message-ID: <20110203055330.GB24798@hezmatt.org> On Thu, Feb 03, 2011 at 12:23:54AM -0500, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Matthew Palmer" > > Now, if you decide that none of those applications are important to > > you, > > sure, you can firewall them off as appropriate. But the pervasive > > deployment of NAT means that the set of problems that can be solved is > > constrained, and of the problems that *can* be solved, the solutions > > tend to > > be more complicated, harder to implement, understand, and so on, which > > has a > > cost to the community (higher prices, less solved problems, whatever > > your > > desired metric may be). I think that's what Blake is getting at with > > his TotC. > > Perhaps. I'm not sure that the collective importance of that difficulty > outweighs the collective danger of making all nodes of the Internet *as it > presently exists* publicly routable. Well, technically, nodes aren't routable, addresses are... and I don't even see any danger in the mere existence of a valid route to a host. The danger exists when that host is not sufficiently secured (be it via firewall, sensible configuration, whatever). > I don't know whether it's occurred to people that if you make every node > on the present day Internet routable, then *you've made every node on the > present day Internet routable*; the number of machines subject to > more or less direct attack goes up (by a jackleg estimate I've just now > made up) by between 3 and 5 orders of magnitude. > > I make jackleg estimates all the time; I don't believe I've ever had to > say "5 orders of magnitude". I'm willing to bet you're being deeply optimistic (pessimistic?) with that estimate; if your estimate were accurate, it would mean that for every publically addressed device there are between 1,000 and 100,000 privately addressed nodes. I *really* don't think that's plausible. At any rate, I think the days of severely broken IP stacks and "spectacularly insecure by default" OS installations are largely behind us; the security battle for the "client endpoint" has moved to client-initiated attacks, which are unhindered by NAT, firewalling, or any other "layer-respecting" network security device. > > Of course, I'm a tiny bit of a skeptic, as I really can't see how a > > stateful > > firewall can know which other connections / packets are related > > without a > > lot of the same dodgy shenanigans that goes on now, but at least if > > you've > > gotten rid of the 1-to-N address mangling a fundamental stumbling > > block is > > removed and people can get on and solve the remaining (tractable) > > problems. > > That is problematic as well, isn't it? It is, but at least it's a problem that has a hope of being solved. > It speaks directly to the attack-surface comment I just made in another reply. I can't see how. - Matt -- "For once, Microsoft wasn't exaggerating when they named it the 'Jet Engine' -- your data's the seagull." -- Chris Adams From davei at otd.com Wed Feb 2 23:57:10 2011 From: davei at otd.com (Dave Israel) Date: Thu, 03 Feb 2011 00:57:10 -0500 Subject: quietly.... In-Reply-To: References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <4D48E558.7070805@brightok.net> <2FD9EDE7-E28C-48E7-B6FB-8386773EF98E@delong.com> <9689E83C-048A-4D72-946B-978FB3C315A4@sackheads.org> , <3CD3A697-8D3C-4EDE-8E4E-53C0E103E12C@sackheads.org> Message-ID: <4D4A43B6.5080306@otd.com> On 2/2/2011 5:42 PM, Brian Johnson wrote: > I must have missed something. Why would u do NAT in IPv6? 1) To allow yourself to change or maintain multiple upstreams without renumbering. 2) To allow your IPv6-only hosts to reach IPv4 addresses, or vice versa. 3) To give all your outbound sessions a mutual appearance, so as to confound those attempting to build a profile of your activity. 4) To irritate the IPv6 faithful. 5) Because it is funny. 6) Because you have allocated a single address to a machine that later on actually represents n differerent actual network entities, and retrofitting them with their own unique IPv6 subnet presents a problem. 7) Because Iljitch bet you you couldn't, and you don't want to lose a bet. 8) Because chicks/dudes think it's hot. 9) Because you can. 10) Because it is the year 8585, and we're running low on IPv6 addresses. From owen at delong.com Thu Feb 3 00:08:29 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 2 Feb 2011 22:08:29 -0800 Subject: quietly.... In-Reply-To: <17286018.1914.1296696154135.JavaMail.root@zimbra.network1.net> References: <17286018.1914.1296696154135.JavaMail.root@zimbra.network1.net> Message-ID: <730B00C2-C13F-4DAD-9565-3015410F547C@delong.com> On Feb 2, 2011, at 5:22 PM, Randy Carpenter wrote: >>>> One of the things I find frustrating about this is the cost of the >>>> space. We're a very small shop and to add IPv6 addresses for >>>> testing now we're looking at paying another $2,200 a year ($1,700 >>>> in the first >>> >>> Ooof. I didn't get that far - and hadn't realized the waiver was >>> expired. >>> >>> That's a pretty signficant barrier to entry. :( >>> >> Um, I think you guys are mistaken... >> >> You're talking about ISP pricing, not end-user pricing. >> >> End user, a /48 will cost you $1,250 one-time and then it's part of >> your usual $100/year that you would be >> paying if you had an ASN or IPv4 space anyway. >> >> Owen > > And, even if you are an ISP, you only pay the larger of the two fees if you have both v4 and v6. I'm not sure if that is permanent or not, though. > > -Randy To the best of my knowledge, the board has no intention of changing that policy. I'd be surprised if that were the case. Owen From fernando at gont.com.ar Wed Feb 2 23:45:04 2011 From: fernando at gont.com.ar (Fernando Gont) Date: Thu, 03 Feb 2011 02:45:04 -0300 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <1296089078.6522.194.camel@karl> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> Message-ID: <4D4A40E0.6020806@gont.com.ar> On 26/01/2011 09:44 p.m., Karl Auer wrote: > So let's get rid of the limitation in our minds. IPv6 provides > *effectively* unlimited address space, even if it's only "for now". So > let's USE it that way. Let's unlearn our limited thinking patterns. > Let's go colonise infinity. And if we need to fix it in a few decades, > so what? Nothing is forever. You must be kiddin'... You're considering going through this mess again in a few decades? Thanks, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nsuan at nonexiste.net Thu Feb 3 00:24:16 2011 From: nsuan at nonexiste.net (Nicholas Suan) Date: Thu, 3 Feb 2011 01:24:16 -0500 Subject: quietly.... In-Reply-To: <1899106.4313.1296710323930.JavaMail.root@benjamin.baylink.com> References: <1899106.4313.1296710323930.JavaMail.root@benjamin.baylink.com> Message-ID: On Thu, Feb 3, 2011 at 12:18 AM, Jay Ashworth wrote: > Complexity of the configuration vastly increases the size of the > attack surface: in a NATted edge network, *no packets can come in > unless I explicitly configure for them*; there are any number of > reasons why an equivalently simply assertion cannot be made concerning > the configuration of firewalls, of whatever type or construction. > I've always wondered how many consumer routers aren't actually From nsuan at nonexiste.net Thu Feb 3 00:24:47 2011 From: nsuan at nonexiste.net (Nicholas Suan) Date: Thu, 3 Feb 2011 01:24:47 -0500 Subject: quietly.... In-Reply-To: <1899106.4313.1296710323930.JavaMail.root@benjamin.baylink.com> References: <1899106.4313.1296710323930.JavaMail.root@benjamin.baylink.com> Message-ID: On Thu, Feb 3, 2011 at 12:18 AM, Jay Ashworth wrote: > Complexity of the configuration vastly increases the size of the > attack surface: in a NATted edge network, *no packets can come in > unless I explicitly configure for them*; there are any number of > reasons why an equivalently simply assertion cannot be made concerning > the configuration of firewalls, of whatever type or construction. > I've always wondered how many consumer-grade routers aren't actually doing this, and the fact that they don't do this is masked by the use of RFC1918 addresses on the internal side of the router. (Linux with netfilter won't, by default, unless you change the default ACCEPT policy, or add a specific rule to block incoming packets.) From owen at delong.com Thu Feb 3 00:28:23 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 2 Feb 2011 22:28:23 -0800 Subject: quietly.... In-Reply-To: <10058800.4297.1296708348990.JavaMail.root@benjamin.baylink.com> References: <10058800.4297.1296708348990.JavaMail.root@benjamin.baylink.com> Message-ID: <10030DF7-3718-421B-8B78-51454F81D2AE@delong.com> On Feb 2, 2011, at 8:45 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Blake Dunlap" > >> On Wed, Feb 2, 2011 at 22:34, Jay Ashworth wrote: >> >>> I won't run an edge-network that *isn't* NATted; my internal machines >>> have no business having publicly routable addresses. No one has *ever* >>> provided me with a serviceable explanation as to why that's an >>> invalid view. > >> Quite simply, its called Tragedy of the Commons. Everyone else has to >> work harder to provide you services if you are using something which breaks >> end to end connectivity, which costs everyone else money. The protocol >> designers are making a stand against this for the good of the "commons". > > You'll have to document "everyone has to work harder to provide me services"; > this is not my first rodeo, and TTBOMK, it's *transparent* to the other end > of any connection out of my edge network that it's NATted at my end. > It's not transparent to: Application Developers Operating Systems Home Gateway Developers Consumer Electronics Developers Technical Support departments My users who are trying to talk to your users using applications that are designed to work in a NAT-free world. My technical support department that gets the "we can't reach them" calls from my users who can't reach your users. It may not be your first trip to the rodeo, but, you do appear to have a rather limited perspective on the far reaching detriments of NAT. > As for incoming connections, it's transparent to them as well -- and which > ones are valid targets for such connections *is a policy decision of > mine*, not subject to external opinion. > Stateful inspection gives you all the same protection for that policy as NAT without breaking the end-to-end model. Nobody is trying to take away your policy rights. > Could you clarify, in some detail, precisely how you get to TotC, Blake? > I think the list of afflicted groups above covers it pretty well. Owen From owen at delong.com Thu Feb 3 00:40:02 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 2 Feb 2011 22:40:02 -0800 Subject: quietly.... In-Reply-To: <20110203051311.GA24798@hezmatt.org> References: <10058800.4297.1296708348990.JavaMail.root@benjamin.baylink.com> <20110203051311.GA24798@hezmatt.org> Message-ID: <1F2028E9-C32B-4FF6-8A01-07F983E453E1@delong.com> > > Of course, I'm a tiny bit of a skeptic, as I really can't see how a stateful > firewall can know which other connections / packets are related without a > lot of the same dodgy shenanigans that goes on now, but at least if you've > gotten rid of the 1-to-N address mangling a fundamental stumbling block is > removed and people can get on and solve the remaining (tractable) problems. > > - Matt Some applications will still require ALG functionality (or modification) to manage the state in the stateful firewall. The beauty is that this is much simpler if the address and port number on the outside of the stateful firewall are the same as the address and port number inside. It can be reduced, for example to: A->B Connect from A/tcp/29199 to B/tcp/9009 SYN B->A From B/tcp/9009 to A/tcp/29199 SYN ACK A->B From A/tcp/29199 to B/tcp/9009 ACK A->B From A/tcp/29199 to B/tcp/9009 INVITE A/tcp/54450 B->A From A/tcp/9009 to A/tcp/29199 ACCEPT B/tcp/9229 (for A/tcp/54450) B->A From B/tcp/9229 to A/tcp/54450 SYN (ignores if RST in response) A->B From A/tcp/54450 to B/TCP/9229 SYN B->A From B/TCP/9229 to A/tcp/54450 SYN ACK ... Notice how the application was able to poke the holes in both sides because it easily knew the address and port number information since it isn't modified. Both firewalls think that the secondary channel is an outbound connection on both sides. There might be some additional signaling required between the host and the firewall in order to let the firewall know that this is a negotiated connection and the funky combination of states (SYN/SYNACK) is acceptable, but, I think that can be worked around fairly easily. Owen From mohacsi at niif.hu Thu Feb 3 02:45:29 2011 From: mohacsi at niif.hu (Mohacsi Janos) Date: Thu, 3 Feb 2011 09:45:29 +0100 (CET) Subject: quietly.... In-Reply-To: References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> Message-ID: On Wed, 2 Feb 2011, Tony Finch wrote: > On Wed, 2 Feb 2011, Iljitsch van Beijnum wrote: >> >> Example: if you give administrators the option of putting a router >> address in a DHCP option, they will do so and some fraction of the time, >> this will be the wrong address and things don't work. If you let routers >> announce their presence, then it's virtually impossible that something >> goes wrong because routers know who they are. A clear win. > > Counterexample: rogue RAs from Windows boxes running 6to4 or Teredo and > Internet Connection Sharing. This is a lot harder to fix than a > misconfigured DHCP server. > > http://malc.org.uk/6doom Force your switch vendor to implement rogue RA filter (ra guard) in your box: http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard Best Regards, Janos Mohacsi From brandon at rd.bbc.co.uk Thu Feb 3 03:48:15 2011 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Thu, 3 Feb 2011 09:48:15 GMT Subject: quietly.... Message-ID: <201102030948.JAA14756@sunf10.rd.bbc.co.uk> > > Just need to add default route in there and make dhcpd do RA > > then the user can turn off RA on their routers and not care > > that DHCPv6 doesn't include default router. > > Having a DHCP server generate RA messages kind of defeats the point of > having RA messages in the first place, resulting in loss of robustness, > and now a new mode of failure. We've already established that the people who want a complete dhcpv6 do not care, they are going to maintain their dhcp server as much as their router, they are equally robust to the same degree of arm waving that the router is robust. That this is still being asked for in dhcp should be enough to convince people IETF "RA is all you'll ever need" mind tricks aren't going to make them go away. I say they as I work on both sides. I know today we have to work with what's been specced though we can choose how to implement them and continue to raise the issues for future development rather than let them be swept aside. brandon From iljitsch at muada.com Thu Feb 3 04:01:17 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 3 Feb 2011 11:01:17 +0100 Subject: IPv6 routing talk @ RIPE, was: Re: quietly.... In-Reply-To: <201102021740.12357.lowen@pari.edu> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <201102021740.12357.lowen@pari.edu> Message-ID: On 2 feb 2011, at 23:40, Lamar Owen wrote: >> I can explain everything you need to know about how to run IPv6 BGP, RIP and OSPF in an hour and a half. Did that at a RIPE meeting some years ago. Setting up Apache to use IPv6 is one line of config. BIND two or three (not counting IPv6 reverse zones). > Now, taking the op hat off for a moment, and stepping down from the soapbox, this is something that could be useful; has this talk been recorded and/or transcribed? If so, that's a useful resource, and, an hour and a half of relevant material is much easier to swallow than some of the books out there. Yes, they recorded it (but in pretty low quality and they didn't bother to cut out the many minutes during which we tried to get the projector and my laptop to talk to each other). It's linked at the top of this page: http://www.ripe.net/ripe/meetings/ripe-53/presentations/wednesday.html These are the slides: http://www.bgpexpert.com/presentations/ipv6_tutorial.pdf From brandon at rd.bbc.co.uk Thu Feb 3 04:09:00 2011 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Thu, 3 Feb 2011 10:09:00 GMT Subject: quietly.... Message-ID: <201102031009.KAA16315@sunf10.rd.bbc.co.uk> > Some applications will still require ALG functionality (or modification) > to manage the state in the stateful firewall. This is where I think the end to end mantra has lead us astray. The users do not care, they just want stuff to work despite security and other real world complexities that have been handled with ALG, SPF and NAT (I agree NAT as bodged on v4 is evil) > There might be some additional signaling required between the host > and the firewall in order to let the firewall know If v6 had allowed for indirect end to end, such as with SOCKS, then people who want ALG, SPF, NAT could do them without having to infer intent and end up breaking apps. brandon From cdl at asgaard.org Thu Feb 3 00:56:38 2011 From: cdl at asgaard.org (Christopher LILJENSTOLPE) Date: Thu, 3 Feb 2011 17:56:38 +1100 Subject: 5.7/5.8 GHz 802.11n dual polarity MIMO through office building glass, 1.5 km distance In-Reply-To: References: <4D1ACC74.2020901@bogus.com> <20101229060744.GA28982@typo.org> <86pqskg1ir.fsf@seastrom.com> <4D1B5405.20701@bryanfields.net> Message-ID: <004389B3-AEC6-4015-85C1-1E9AFE08F8FA@asgaard.org> ++ On 30Dec2010, at 12.47, Jared Mauch wrote: > > On Dec 29, 2010, at 11:24 AM, Josh Smith wrote: > >> While certainly not the best stuff made I've found the ubiquiti >> equipment to be very nice for the price and have a few of their AP's >> which have been in service 24x7 for a couple of years now. > > Same here. > > The price performance is hard (impossible?) to beat. > > Combine that with the Linux/SDK stuff and you can do some interesting things with it that you can't do with other devices. > > - Jared > --- ??? Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 455 bytes Desc: This is a digitally signed message part URL: From dredd at megacity.org Thu Feb 3 06:25:06 2011 From: dredd at megacity.org (Derek J. Balling) Date: Thu, 3 Feb 2011 07:25:06 -0500 Subject: quietly.... In-Reply-To: References: <201102030110.BAA19803@sunf10.rd.bbc.co.uk> Message-ID: <17111218-309D-49F7-9C58-D97B59637F45@megacity.org> On Feb 2, 2011, at 11:47 PM, Jimmy Hess wrote: > Having a DHCP server generate RA messages kind of defeats the point of having RA messages > in the first place, resulting in loss of robustness, and now a new mode of failure. And by "new" here you mean "exactly the same mode of failure that's been around for decades but hasn't been so serious as to be the downfall of internetworking". Right? From brunner at nic-naa.net Thu Feb 3 06:34:24 2011 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Thu, 03 Feb 2011 07:34:24 -0500 Subject: Egypt: direct economic cost estimated at $18m/day Message-ID: <4D4AA0D0.7070002@nic-naa.net> This is from a 3% to 4% estimate of telecomms and datacomms in the overall Egyptian economy. The OEDC communique notes that attracting foreign investment may now be more difficult. (Is there anyone not looking at regional alternatives?) Source: http://www.lemonde.fr/technologies/article/2011/02/03/egypte-la-coupure-internet-a-coute-90-millions-de-dollars_1474489_651865.html From eugen at leitl.org Thu Feb 3 06:49:08 2011 From: eugen at leitl.org (Eugen Leitl) Date: Thu, 3 Feb 2011 13:49:08 +0100 Subject: quietly.... In-Reply-To: <17286018.1914.1296696154135.JavaMail.root@zimbra.network1.net> References: <44DDE580-2B01-46A3-B424-66468A6BA026@delong.com> <17286018.1914.1296696154135.JavaMail.root@zimbra.network1.net> Message-ID: <20110203124908.GJ23560@leitl.org> On Wed, Feb 02, 2011 at 08:22:34PM -0500, Randy Carpenter wrote: > > End user, a /48 will cost you $1,250 one-time and then it's part of > > your usual $100/year that you would be > > paying if you had an ASN or IPv4 space anyway. Any reason why RIPE NCC charges so much more? http://www.ripe.net/membership/billing/procedure-enduser.html (other than "because they can", I mean). > > > > Owen > > And, even if you are an ISP, you only pay the larger of the two fees if you have both v4 and v6. I'm not sure if that is permanent or not, though. -- Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE From fweimer at bfk.de Thu Feb 3 06:58:43 2011 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 03 Feb 2011 12:58:43 +0000 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: (Carlos Martinez-Cagnazzo's message of "Mon\, 24 Jan 2011 10\:59\:59 -0200") References: Message-ID: <82fws5nukc.fsf@mid.bfk.de> * Carlos Martinez-Cagnazzo: > The subject says it all... anyone with experience with a setup like > this ? Unicast addresses must be located in at least a /64 subnet. No doubt there are vendors which enforce this (perhaps even in the ASICs), so deviating from this rule will result in some lock-in. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From nick at foobar.org Thu Feb 3 07:03:00 2011 From: nick at foobar.org (Nick Hilliard) Date: Thu, 03 Feb 2011 13:03:00 +0000 Subject: quietly.... In-Reply-To: <20110203124908.GJ23560@leitl.org> References: <44DDE580-2B01-46A3-B424-66468A6BA026@delong.com> <17286018.1914.1296696154135.JavaMail.root@zimbra.network1.net> <20110203124908.GJ23560@leitl.org> Message-ID: <4D4AA784.7070208@foobar.org> On 03/02/2011 12:49, Eugen Leitl wrote: > Any reason why RIPE NCC charges so much more? > > http://www.ripe.net/membership/billing/procedure-enduser.html > > (other than "because they can", I mean). That's if you deal with the RIPE NCC directly. If you get your direct assignments via a LIR, the cost drops to ?50 per each independent number resource, with no setup fee. Although a wholesale cost, it is significantly cheaper than ARIN. Nick From fweimer at bfk.de Thu Feb 3 07:03:36 2011 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 03 Feb 2011 13:03:36 +0000 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: (Ray Soucy's message of "Mon\, 24 Jan 2011 15\:53\:32 -0500") References: Message-ID: <82bp2tnuc7.fsf@mid.bfk.de> * Ray Soucy: > Every time I see this question it' usually related to a fundamental > misunderstanding of IPv6 and the attempt to apply v4 logic to v6. True, you have to ignore more than a decade of IPv4 protocol development and resort to things like pre-VLSM networking. > That said. Any size prefix will likely work and is even permitted by > the RFC. Could you quote chapter and verse, please? RFC 4291 section 2.5.4 says this: All Global Unicast addresses other than those that start with binary 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as described in Section 2.5.1. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From internetplumber at gmail.com Thu Feb 3 07:07:10 2011 From: internetplumber at gmail.com (Rob Evans) Date: Thu, 3 Feb 2011 13:07:10 +0000 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <4D4A40E0.6020806@gont.com.ar> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> Message-ID: > You must be kiddin'... You're considering going through this mess again > in a few decades? I'm mildly surprised if you think we're going to be done with *this* mess in a few decades. Rob From jamie at photon.com Thu Feb 3 07:08:17 2011 From: jamie at photon.com (Jamie Bowden) Date: Thu, 3 Feb 2011 08:08:17 -0500 Subject: quietly.... In-Reply-To: References: <201102030110.BAA19803@sunf10.rd.bbc.co.uk> Message-ID: <5C836A1A98186142A6BEC393FD5E2A86015793@hal.photon.com> I don't mean to rain on your parade here...oh wait, yeah, I do actually. I have an SGI Indigo (MIPS R3000/25 with 32MB RAM baby, it's a screamer!) that still runs with no problems. Show me an eighteen year old router that's still up and running. The Dell hardware we ran NT4 Server on for providing DHCP until I replaced it is still as functional today as it was when it was purchased in 1998. I have a five year old Cisco doorstop. Don't tell me routers are made of magic hardware that is somehow immune to failure. Jamie -----Original Message----- From: Jimmy Hess [mailto:mysidia at gmail.com] Sent: Wednesday, February 02, 2011 11:48 PM To: Brandon Butterworth Cc: nanog at nanog.org Subject: Re: quietly.... On Wed, Feb 2, 2011 at 7:10 PM, Brandon Butterworth wrote: > > Just need to add default route in there and make dhcpd do RA > then the user can turn off RA on their routers and not care > that DHCPv6 doesn't include default router. > Having a DHCP server generate RA messages kind of defeats the point of having RA messages in the first place, resulting in loss of robustness, and now a new mode of failure. The point of having RA messages is they are simple, and integrated into the routers, so there is not a separate server to fail (a "DHCP server") to cause loss of connectivity, due to server appliances (computers) being less reliable than routers. With the RA integrated into the routers properly, clients can maintain connectivity (and establish connectivity, provided DNS details obtained in the past), even if DHCP server(s) should fail. -- -JH From fweimer at bfk.de Thu Feb 3 07:11:35 2011 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 03 Feb 2011 13:11:35 +0000 Subject: quietly.... In-Reply-To: <4D4AA784.7070208@foobar.org> (Nick Hilliard's message of "Thu\, 03 Feb 2011 13\:03\:00 +0000") References: <44DDE580-2B01-46A3-B424-66468A6BA026@delong.com> <17286018.1914.1296696154135.JavaMail.root@zimbra.network1.net> <20110203124908.GJ23560@leitl.org> <4D4AA784.7070208@foobar.org> Message-ID: <8262t1ntyw.fsf@mid.bfk.de> * Nick Hilliard: > On 03/02/2011 12:49, Eugen Leitl wrote: >> Any reason why RIPE NCC charges so much more? >> >> http://www.ripe.net/membership/billing/procedure-enduser.html >> >> (other than "because they can", I mean). > > That's if you deal with the RIPE NCC directly. If you get your direct > assignments via a LIR, the cost drops to ?50 per each independent > number resource, with no setup fee. Although a wholesale cost, it is > significantly cheaper than ARIN. Has RIPE charged a LIR for their independent resources yet? I don't think so. Therefore, comparisons with ARIN are a bit premature. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From simon at slimey.org Thu Feb 3 07:14:31 2011 From: simon at slimey.org (Simon Lockhart) Date: Thu, 3 Feb 2011 13:14:31 +0000 Subject: quietly.... In-Reply-To: <8262t1ntyw.fsf@mid.bfk.de> References: <44DDE580-2B01-46A3-B424-66468A6BA026@delong.com> <17286018.1914.1296696154135.JavaMail.root@zimbra.network1.net> <20110203124908.GJ23560@leitl.org> <4D4AA784.7070208@foobar.org> <8262t1ntyw.fsf@mid.bfk.de> Message-ID: <20110203131430.GV6098@virtual.bogons.net> On Thu Feb 03, 2011 at 01:11:35PM +0000, Florian Weimer wrote: > Has RIPE charged a LIR for their independent resources yet? I don't > think so. Therefore, comparisons with ARIN are a bit premature. Yes - we got charged in our 2011 invoice. Simon -- Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration * Director | * Domain & Web Hosting * Internet Consultancy * Bogons Ltd | * http://www.bogons.net/ * Email: info at bogons.net * From fweimer at bfk.de Thu Feb 3 07:23:20 2011 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 03 Feb 2011 13:23:20 +0000 Subject: quietly.... In-Reply-To: <20110203131430.GV6098@virtual.bogons.net> (Simon Lockhart's message of "Thu\, 3 Feb 2011 13\:14\:31 +0000") References: <44DDE580-2B01-46A3-B424-66468A6BA026@delong.com> <17286018.1914.1296696154135.JavaMail.root@zimbra.network1.net> <20110203124908.GJ23560@leitl.org> <4D4AA784.7070208@foobar.org> <8262t1ntyw.fsf@mid.bfk.de> <20110203131430.GV6098@virtual.bogons.net> Message-ID: <82tyglmeuv.fsf@mid.bfk.de> * Simon Lockhart: > On Thu Feb 03, 2011 at 01:11:35PM +0000, Florian Weimer wrote: >> Has RIPE charged a LIR for their independent resources yet? I don't >> think so. Therefore, comparisons with ARIN are a bit premature. > > Yes - we got charged in our 2011 invoice. Very interesting. Are you sure it's not new allocations? I think we're still waiting for our provider-independent resources to be assigned to us. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From jbates at brightok.net Thu Feb 3 08:15:48 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 03 Feb 2011 08:15:48 -0600 Subject: quietly.... In-Reply-To: <4D499910.4020001@foobar.org> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <4D4979D1.4000104@phaze.org> <70C15FD9-CF85-4664-B913-3EBE4271C7F5@muada.com> <4D499910.4020001@foobar.org> Message-ID: <4D4AB894.6050107@brightok.net> On 2/2/2011 11:49 AM, Nick Hilliard wrote: > This is a well-examined problem: well known unicast listener addresses > are a bad, bad idea. > Is this why the root isn't just using well-known? :) Jack From nick at foobar.org Thu Feb 3 08:20:36 2011 From: nick at foobar.org (Nick Hilliard) Date: Thu, 03 Feb 2011 14:20:36 +0000 Subject: quietly.... In-Reply-To: <4D4AB894.6050107@brightok.net> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <4D4979D1.4000104@phaze.org> <70C15FD9-CF85-4664-B913-3EBE4271C7F5@muada.com> <4D499910.4020001@foobar.org> <4D4AB894.6050107@brightok.net> Message-ID: <4D4AB9B4.4060201@foobar.org> On 03/02/2011 14:15, Jack Bates wrote: > Is this why the root isn't just using well-known? No - that's pretty much the only situation where you have a technical requirement to hardcode IP address, and there's basically no way of getting around it. Besides, it's completely different to having a requirement that all locally connected machines should by default send all of their DNS requests to a specific address. You're talking about a situation which affects only DNS resolvers. I'm talking about something which affects all end-user nodes in the world. i.e. much messier problem on a completely different scale. Nick From andrew.wallace at rocketmail.com Thu Feb 3 08:24:58 2011 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Thu, 3 Feb 2011 06:24:58 -0800 (PST) Subject: Egypt 'hijacked Vodafone network' Message-ID: <629152.45886.qm@web59601.mail.ac4.yahoo.com> Mobile phone firm Vodafone accuses the Egyptian authorities of using its network to send pro-government text messages. http://www.bbc.co.uk/news/business-12357694 Andrew From scott at doc.net.au Thu Feb 3 08:35:57 2011 From: scott at doc.net.au (Scott Howard) Date: Thu, 3 Feb 2011 06:35:57 -0800 Subject: And so it ends... Message-ID: 102/8 AfriNIC 2011-02 whois.afrinic.net ALLOCATED 103/8 APNIC 2011-02 whois.apnic.net ALLOCATED 104/8 ARIN 2011-02 whois.arin.net ALLOCATED 179/8 LACNIC 2011-02 whois.lacnic.net ALLOCATED 185/8 RIPE NCC 2011-02 whois.ripe.net ALLOCATED From skhosla at neutraldata.com Thu Feb 3 08:37:04 2011 From: skhosla at neutraldata.com (Sameer Khosla) Date: Thu, 3 Feb 2011 09:37:04 -0500 Subject: Significant Announcement (re: IPv4) 3 February - Watch it Live! In-Reply-To: <34AA4613-61BD-4C3F-8480-6E10EE6309AE@corp.arin.net> References: <4D47F7DE.6040102@arin.net> <34AA4613-61BD-4C3F-8480-6E10EE6309AE@corp.arin.net> Message-ID: <3CDAFF22BE6DAF43B7EA263F6707D2892BE3A9@mail.neutraldata.com> Anyone else getting Error establishing a database connection trying to bring this up? Thanks Sameer -----Original Message----- From: John Curran [mailto:jcurran at arin.net] Sent: Tuesday, February 01, 2011 8:24 AM To: nanog at nanog.org list Subject: Significant Announcement (re: IPv4) 3 February - Watch it Live! FYI - Some people in this community may want to watch this event (either in person or via webcast) /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN > Date: February 1, 2011 7:09:02 AM EST To: > Subject: [arin-announce] Significant Announcement 3 February - Watch it Live! On Thursday, 3 February 2011, at 9:30 AM Eastern Standard Time (EST), the Number Resource Organization (NRO), along with the Internet Corporation for Assigned Names and Numbers, the Internet Society (ISOC) and the Internet Architecture Board (IAB) will be holding a ceremony and press conference to make a significant announcement and to discuss the global transition to the next generation of Internet addresses. Much has been written in the international media over the last few weeks about the dwindling pool of Internet addresses using the original Internet protocol, called IPv4 (Internet Protocol version 4), and this topic will be addressed at the event. We invite all interested community members to view the webcast of this event at: http://www.nro.net/news/icann-nro-live-stream In the event you happen to be at the Intercontinental Hotel in Miami on Thursday, there will be limited public seating available to attend (with press receiving seating priority) in Room "Concourse II" at 9:30 AM EST for the ceremony and 10:00 AM for press conference which follows. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From cmadams at hiwaay.net Thu Feb 3 08:43:44 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 3 Feb 2011 08:43:44 -0600 Subject: Significant Announcement (re: IPv4) 3 February - Watch it Live! In-Reply-To: <3CDAFF22BE6DAF43B7EA263F6707D2892BE3A9@mail.neutraldata.com> References: <4D47F7DE.6040102@arin.net> <34AA4613-61BD-4C3F-8480-6E10EE6309AE@corp.arin.net> <3CDAFF22BE6DAF43B7EA263F6707D2892BE3A9@mail.neutraldata.com> Message-ID: <20110203144344.GB890@hiwaay.net> Once upon a time, Sameer Khosla said: > Anyone else getting Error establishing a database connection trying to > bring this up? It was posted to /. this morning, so it is probably overloaded (I didn't even try). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From bjohnson at drtel.com Thu Feb 3 08:44:22 2011 From: bjohnson at drtel.com (Brian Johnson) Date: Thu, 3 Feb 2011 14:44:22 +0000 Subject: Significant Announcement (re: IPv4) 3 February - Watch it Live! In-Reply-To: <3CDAFF22BE6DAF43B7EA263F6707D2892BE3A9@mail.neutraldata.com> References: <4D47F7DE.6040102@arin.net> <34AA4613-61BD-4C3F-8480-6E10EE6309AE@corp.arin.net> <3CDAFF22BE6DAF43B7EA263F6707D2892BE3A9@mail.neutraldata.com> Message-ID: I think they were under a TCP-SYN attack :) The video was super choppy from here and I have bandwidth to burn at this time of the day. A little disappointing, but I'm sure (fingers crossed) someone will have a clean recording of it that they will make available. - Brian J. >-----Original Message----- >From: Sameer Khosla [mailto:skhosla at neutraldata.com] >Sent: Thursday, February 03, 2011 8:37 AM >To: nanog at nanog.org >Subject: RE: Significant Announcement (re: IPv4) 3 February - Watch it Live! > >Anyone else getting Error establishing a database connection trying to >bring this up? > >Thanks >Sameer > >-----Original Message----- >From: John Curran [mailto:jcurran at arin.net] >Sent: Tuesday, February 01, 2011 8:24 AM >To: nanog at nanog.org list >Subject: Significant Announcement (re: IPv4) 3 February - Watch it Live! > >FYI - Some people in this community may want to watch this event (either >in person or via webcast) /John > >John Curran >President and CEO >ARIN > >Begin forwarded message: > >From: ARIN > >Date: February 1, 2011 7:09:02 AM EST >To: > >Subject: [arin-announce] Significant Announcement 3 February - Watch it >Live! > >On Thursday, 3 February 2011, at 9:30 AM Eastern Standard Time (EST), >the Number Resource Organization (NRO), along with the Internet >Corporation for Assigned Names and Numbers, the Internet Society (ISOC) >and the Internet Architecture Board (IAB) will be holding a ceremony and >press conference to make a significant announcement and to discuss the >global transition to the next generation of Internet addresses. > >Much has been written in the international media over the last few weeks >about the dwindling pool of Internet addresses using the original >Internet protocol, called IPv4 (Internet Protocol version 4), and this >topic will be addressed at the event. > >We invite all interested community members to view the webcast of this >event at: http://www.nro.net/news/icann-nro-live-stream > >In the event you happen to be at the Intercontinental Hotel in Miami on >Thursday, there will be limited public seating available to attend (with >press receiving seating priority) in Room "Concourse II" at 9:30 AM EST >for the ceremony and 10:00 AM for press conference which follows. > >Regards, > >Communications and Member Services >American Registry for Internet Numbers (ARIN) > From scott at doc.net.au Thu Feb 3 08:45:48 2011 From: scott at doc.net.au (Scott Howard) Date: Thu, 3 Feb 2011 06:45:48 -0800 Subject: Significant Announcement (re: IPv4) 3 February - Watch it Live! In-Reply-To: <3CDAFF22BE6DAF43B7EA263F6707D2892BE3A9@mail.neutraldata.com> References: <4D47F7DE.6040102@arin.net> <34AA4613-61BD-4C3F-8480-6E10EE6309AE@corp.arin.net> <3CDAFF22BE6DAF43B7EA263F6707D2892BE3A9@mail.neutraldata.com> Message-ID: The Windows Media stream was working for me (the others were giving the database error), but it's all over now. There's a press conference at 10:00am EST, but I'm not sure if it's going to be webcast or not. Scott. On Thu, Feb 3, 2011 at 6:37 AM, Sameer Khosla wrote: > Anyone else getting Error establishing a database connection trying to > bring this up? > > Thanks > Sameer > > -----Original Message----- > From: John Curran [mailto:jcurran at arin.net] > Sent: Tuesday, February 01, 2011 8:24 AM > To: nanog at nanog.org list > Subject: Significant Announcement (re: IPv4) 3 February - Watch it Live! > > FYI - Some people in this community may want to watch this event (either > in person or via webcast) /John > > John Curran > President and CEO > ARIN > > Begin forwarded message: > > From: ARIN > > Date: February 1, 2011 7:09:02 AM EST > To: > > Subject: [arin-announce] Significant Announcement 3 February - Watch it > Live! > > On Thursday, 3 February 2011, at 9:30 AM Eastern Standard Time (EST), > the Number Resource Organization (NRO), along with the Internet > Corporation for Assigned Names and Numbers, the Internet Society (ISOC) > and the Internet Architecture Board (IAB) will be holding a ceremony and > press conference to make a significant announcement and to discuss the > global transition to the next generation of Internet addresses. > > Much has been written in the international media over the last few weeks > about the dwindling pool of Internet addresses using the original > Internet protocol, called IPv4 (Internet Protocol version 4), and this > topic will be addressed at the event. > > We invite all interested community members to view the webcast of this > event at: http://www.nro.net/news/icann-nro-live-stream > > In the event you happen to be at the Intercontinental Hotel in Miami on > Thursday, there will be limited public seating available to attend (with > press receiving seating priority) in Room "Concourse II" at 9:30 AM EST > for the ceremony and 10:00 AM for press conference which follows. > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > From wschultz at bsdboy.com Thu Feb 3 08:46:21 2011 From: wschultz at bsdboy.com (Wil Schultz) Date: Thu, 3 Feb 2011 06:46:21 -0800 Subject: And so it ends... In-Reply-To: References: Message-ID: It's been a fun ride, adios good friend. -wil On Feb 3, 2011, at 6:35 AM, Scott Howard wrote: > 102/8 AfriNIC 2011-02 whois.afrinic.net ALLOCATED > 103/8 APNIC 2011-02 whois.apnic.net ALLOCATED > 104/8 ARIN 2011-02 whois.arin.net ALLOCATED > 179/8 LACNIC 2011-02 whois.lacnic.net ALLOCATED > 185/8 RIPE NCC 2011-02 whois.ripe.net ALLOCATED From rcarpen at network1.net Thu Feb 3 08:47:58 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Thu, 3 Feb 2011 09:47:58 -0500 (EST) Subject: Significant Announcement (re: IPv4) 3 February - Watch it Live! In-Reply-To: <20110203144344.GB890@hiwaay.net> Message-ID: <1404600274.2040.1296744478836.JavaMail.root@zimbra.network1.net> It didn't work too bad. Does anyone know why it was pretty much over at 9:30, when they said it would start? Did they start a half-hour early or something? -Randy -- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1 ---- ----- Original Message ----- > Once upon a time, Sameer Khosla said: > > Anyone else getting Error establishing a database connection trying > > to > > bring this up? > > It was posted to /. this morning, so it is probably overloaded (I > didn't > even try). > -- > Chris Adams > Systems and Network Administrator - HiWAAY Internet Services > I don't speak for anybody but myself - that's enough trouble. From maxlarson.henry at transversal.ht Thu Feb 3 08:49:31 2011 From: maxlarson.henry at transversal.ht (Max Larson Henry) Date: Thu, 3 Feb 2011 09:49:31 -0500 Subject: And so it ends... In-Reply-To: References: Message-ID: Still a few LEGACY in the status column ;-) -M On Thu, Feb 3, 2011 at 9:35 AM, Scott Howard wrote: > 102/8 AfriNIC 2011-02 whois.afrinic.net ALLOCATED > 103/8 APNIC 2011-02 whois.apnic.net ALLOCATED > 104/8 ARIN 2011-02 whois.arin.net ALLOCATED > 179/8 LACNIC 2011-02 whois.lacnic.net ALLOCATED > 185/8 RIPE NCC 2011-02 whois.ripe.net ALLOCATED > From igor at ergens.org Thu Feb 3 08:49:53 2011 From: igor at ergens.org (Igor Ybema) Date: Thu, 3 Feb 2011 15:49:53 +0100 Subject: Significant Announcement (re: IPv4) 3 February - Watch it Live! In-Reply-To: References: <4D47F7DE.6040102@arin.net> <34AA4613-61BD-4C3F-8480-6E10EE6309AE@corp.arin.net> <3CDAFF22BE6DAF43B7EA263F6707D2892BE3A9@mail.neutraldata.com> Message-ID: > I think they were under a TCP-SYN attack :) > > The video was super choppy from here and I have bandwidth to burn at this > time of the day. A little disappointing, but I'm sure (fingers crossed) > someone will have a clean recording of it that they will make available. > > > I saw that also. Switched to windows media stream which was working fine. However,.. stream was not available on a IPv6 only host. Epic fail! :) regards, Igor From leo.vegoda at icann.org Thu Feb 3 08:51:35 2011 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 3 Feb 2011 06:51:35 -0800 Subject: Five /8s allocated to RIRs - no unallocated IPv4 unicast /8s remain Message-ID: <32E11FDF-3F84-44DD-9D1A-4C1EB51D55AA@icann.org> Hi, The IANA IPv4 registry has been updated to reflect the allocation of five /8 IPv4 blocks: one to each RIR, in February 2011. You can find the updated IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt Please update your filters as appropriate. There are no more unallocated unicast IPv4 /8s in the IANA IPv4 Address Space Registry. Kind regards, Leo Vegoda Number Resources Manager, IANA ICANN From maxlarson.henry at transversal.ht Thu Feb 3 08:51:38 2011 From: maxlarson.henry at transversal.ht (Max Larson Henry) Date: Thu, 3 Feb 2011 09:51:38 -0500 Subject: Significant Announcement (re: IPv4) 3 February - Watch it Live! In-Reply-To: References: <4D47F7DE.6040102@arin.net> <34AA4613-61BD-4C3F-8480-6E10EE6309AE@corp.arin.net> <3CDAFF22BE6DAF43B7EA263F6707D2892BE3A9@mail.neutraldata.com> Message-ID: http://www.nro.net/supplemental/icann-nro-low-bandwidth -M On Thu, Feb 3, 2011 at 9:44 AM, Brian Johnson wrote: > I think they were under a TCP-SYN attack :) > > The video was super choppy from here and I have bandwidth to burn at this > time of the day. A little disappointing, but I'm sure (fingers crossed) > someone will have a clean recording of it that they will make available. > > - Brian J. > > > > >-----Original Message----- > >From: Sameer Khosla [mailto:skhosla at neutraldata.com] > >Sent: Thursday, February 03, 2011 8:37 AM > >To: nanog at nanog.org > >Subject: RE: Significant Announcement (re: IPv4) 3 February - Watch it > Live! > > > >Anyone else getting Error establishing a database connection trying to > >bring this up? > > > >Thanks > >Sameer > > > >-----Original Message----- > >From: John Curran [mailto:jcurran at arin.net] > >Sent: Tuesday, February 01, 2011 8:24 AM > >To: nanog at nanog.org list > >Subject: Significant Announcement (re: IPv4) 3 February - Watch it Live! > > > >FYI - Some people in this community may want to watch this event (either > >in person or via webcast) /John > > > >John Curran > >President and CEO > >ARIN > > > >Begin forwarded message: > > > >From: ARIN > > >Date: February 1, 2011 7:09:02 AM EST > >To: > > >Subject: [arin-announce] Significant Announcement 3 February - Watch it > >Live! > > > >On Thursday, 3 February 2011, at 9:30 AM Eastern Standard Time (EST), > >the Number Resource Organization (NRO), along with the Internet > >Corporation for Assigned Names and Numbers, the Internet Society (ISOC) > >and the Internet Architecture Board (IAB) will be holding a ceremony and > >press conference to make a significant announcement and to discuss the > >global transition to the next generation of Internet addresses. > > > >Much has been written in the international media over the last few weeks > >about the dwindling pool of Internet addresses using the original > >Internet protocol, called IPv4 (Internet Protocol version 4), and this > >topic will be addressed at the event. > > > >We invite all interested community members to view the webcast of this > >event at: http://www.nro.net/news/icann-nro-live-stream > > > >In the event you happen to be at the Intercontinental Hotel in Miami on > >Thursday, there will be limited public seating available to attend (with > >press receiving seating priority) in Room "Concourse II" at 9:30 AM EST > >for the ceremony and 10:00 AM for press conference which follows. > > > >Regards, > > > >Communications and Member Services > >American Registry for Internet Numbers (ARIN) > > > > > From bjohnson at drtel.com Thu Feb 3 08:53:12 2011 From: bjohnson at drtel.com (Brian Johnson) Date: Thu, 3 Feb 2011 14:53:12 +0000 Subject: quietly.... In-Reply-To: <4D4A43B6.5080306@otd.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <4D48E558.7070805@brightok.net> <2FD9EDE7-E28C-48E7-B6FB-8386773EF98E@delong.com> <9689E83C-048A-4D72-946B-978FB3C315A4@sackheads.org> , <3CD3A697-8D3C-4EDE-8E4E-53C0E103E12C@sackheads.org> <4D4A43B6.5080306@otd.com> Message-ID: I will rebut in-line. >-----Original Message----- >From: Dave Israel [mailto:davei at otd.com] >Sent: Wednesday, February 02, 2011 11:57 PM >To: nanog at nanog.org >Subject: Re: quietly.... > >On 2/2/2011 5:42 PM, Brian Johnson wrote: >> I must have missed something. Why would u do NAT in IPv6? > >1) To allow yourself to change or maintain multiple upstreams without >renumbering. Not sure what you mean here. So having PI space can't accomplish this? >2) To allow your IPv6-only hosts to reach IPv4 addresses, or vice versa. This is not a NAT66 specific solution. >3) To give all your outbound sessions a mutual appearance, so as to >confound those attempting to build a profile of your activity. So this goes back to security through obscurity. OK. >4) To irritate the IPv6 faithful. >5) Because it is funny. Oh yeah, I forgot that you were funny. :) >6) Because you have allocated a single address to a machine that later >on actually represents n differerent actual network entities, and >retrofitting them with their own unique IPv6 subnet presents a problem. Huh? >7) Because Iljitch bet you you couldn't, and you don't want to lose a bet. >8) Because chicks/dudes think it's hot. >9) Because you can. >10) Because it is the year 8585, and we're running low on IPv6 addresses OK... so this list of ten boils down to really two items that seem completely valid and one that seems like a corner case, but are also not the purpose of NAT66 as far as I can tell. Anyone else without the sarcasm? - Brian P.S... I'm not against NAT66, I just don't yet understand it at the layers above 7. :) From tony at lava.net Thu Feb 3 08:58:03 2011 From: tony at lava.net (Antonio Querubin) Date: Thu, 3 Feb 2011 04:58:03 -1000 (HST) Subject: Significant Announcement (re: IPv4) 3 February - Watch it Live! In-Reply-To: <1404600274.2040.1296744478836.JavaMail.root@zimbra.network1.net> References: <1404600274.2040.1296744478836.JavaMail.root@zimbra.network1.net> Message-ID: On Thu, 3 Feb 2011, Randy Carpenter wrote: > It didn't work too bad. Does anyone know why it was pretty much over at > 9:30, when they said it would start? Did they start a half-hour early or > something? I think that was just the ceremony for handing out the last /8s and it went very quickly. The press conference starts at 10:00. Antonio Querubin e-mail/xmpp: tony at lava.net From alex at corp.nac.net Thu Feb 3 08:58:56 2011 From: alex at corp.nac.net (Alex Rubenstein) Date: Thu, 3 Feb 2011 09:58:56 -0500 Subject: And so it ends... In-Reply-To: References: Message-ID: And we have yet to see what happens with backend transactions between private institutions that have large blocks laying around, and them realizing that they have a marketable and valuable thing. We may all say it won't happen, we may even say we don't want it to happen, or that it shouldn't be allowed - but I'm a realist. > From: Max Larson Henry [mailto:maxlarson.henry at transversal.ht] > > Still a few LEGACY in the status column ;-) > > -M > > On Thu, Feb 3, 2011 at 9:35 AM, Scott Howard wrote: > > > 102/8 AfriNIC 2011-02 whois.afrinic.net ALLOCATED > > 103/8 APNIC 2011-02 whois.apnic.net ALLOCATED > > 104/8 ARIN 2011-02 whois.arin.net ALLOCATED > > 179/8 LACNIC 2011-02 whois.lacnic.net ALLOCATED > > 185/8 RIPE NCC 2011-02 whois.ripe.net ALLOCATED > > From maxlarson.henry at transversal.ht Thu Feb 3 09:00:41 2011 From: maxlarson.henry at transversal.ht (Max Larson Henry) Date: Thu, 3 Feb 2011 10:00:41 -0500 Subject: Significant Announcement (re: IPv4) 3 February - Watch it Live! In-Reply-To: <1404600274.2040.1296744478836.JavaMail.root@zimbra.network1.net> References: <20110203144344.GB890@hiwaay.net> <1404600274.2040.1296744478836.JavaMail.root@zimbra.network1.net> Message-ID: News conference starts now -M On Thu, Feb 3, 2011 at 9:47 AM, Randy Carpenter wrote: > > It didn't work too bad. Does anyone know why it was pretty much over at > 9:30, when they said it would start? Did they start a half-hour early or > something? > > > -Randy > > -- > | Randy Carpenter > | Vice President - IT Services > | Red Hat Certified Engineer > | First Network Group, Inc. > | (800)578-6381, Opt. 1 > ---- > > ----- Original Message ----- > > Once upon a time, Sameer Khosla said: > > > Anyone else getting Error establishing a database connection trying > > > to > > > bring this up? > > > > It was posted to /. this morning, so it is probably overloaded (I > > didn't > > even try). > > -- > > Chris Adams > > Systems and Network Administrator - HiWAAY Internet Services > > I don't speak for anybody but myself - that's enough trouble. > > > From jbates at brightok.net Thu Feb 3 09:00:47 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 03 Feb 2011 09:00:47 -0600 Subject: quietly.... In-Reply-To: <1906085828.1923.1296700690262.JavaMail.root@zimbra.network1.net> References: <1906085828.1923.1296700690262.JavaMail.root@zimbra.network1.net> Message-ID: <4D4AC31F.1050000@brightok.net> On 2/2/2011 8:38 PM, Randy Carpenter wrote: > >> From the main section on https://www.arin.net/fees/fee_schedule.html: > > "... ISPs with both IPv4 resources and IPv6 resources pay the larger of the two fees." > > It is not mentioned anywhere in the waiver stuff. > The concept of v4 to v6 addressing scale doesn't match the pricing scale, though. Generally, I expect to see most ISPs find themselves 1 rank higher in the v6 model compared to v4, which effectively doubles your price anyways. :) Jack From sthaug at nethelp.no Thu Feb 3 09:02:18 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Thu, 03 Feb 2011 16:02:18 +0100 (CET) Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <82fws5nukc.fsf@mid.bfk.de> References: <82fws5nukc.fsf@mid.bfk.de> Message-ID: <20110203.160218.74692032.sthaug@nethelp.no> > > The subject says it all... anyone with experience with a setup like > > this ? > > Unicast addresses must be located in at least a /64 subnet. No doubt > there are vendors which enforce this (perhaps even in the ASICs), so > deviating from this rule will result in some lock-in. The Juniper and Cisco equipment I have worked with can handle static LAN addresses with a mask different from /64 just fine. Same with OSes like FreeBSD, for instance. SLAAC obviously won't work. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From owenc at hubris.net Thu Feb 3 09:05:31 2011 From: owenc at hubris.net (Chris Owen) Date: Thu, 3 Feb 2011 09:05:31 -0600 Subject: quietly.... In-Reply-To: <4D4AC31F.1050000@brightok.net> References: <1906085828.1923.1296700690262.JavaMail.root@zimbra.network1.net> <4D4AC31F.1050000@brightok.net> Message-ID: <0336232C-B037-4AFF-A91A-71FFAE2DDEF4@hubris.net> On Feb 3, 2011, at 9:00 AM, Jack Bates wrote: > The concept of v4 to v6 addressing scale doesn't match the pricing scale, though. Generally, I expect to see most ISPs find themselves 1 rank higher in the v6 model compared to v4, which effectively doubles your price anyways. :) Not sure I understand that one. /19 = 500 /29s /32 = 64,000 /48s Shouldn't the v6 blocks be a lot bigger? Chris -- ------------------------------------------------------------------------- Chris Owen - Garden City (620) 275-1900 - Lottery (noun): President - Wichita (316) 858-3000 - A stupidity tax Hubris Communications Inc www.hubris.net ------------------------------------------------------------------------- From jra at baylink.com Thu Feb 3 09:08:46 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 3 Feb 2011 10:08:46 -0500 (EST) Subject: quietly.... In-Reply-To: <431B4BAB-747A-4CDB-95A5-0E95BAF3E35A@delong.com> Message-ID: <27407059.4419.1296745726636.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > On Feb 2, 2011, at 8:34 PM, Jay Ashworth wrote: > > I won't run an edge-network that *isn't* NATted; my internal > > machines > > have no business having publicly routable addresses. No one has > > *ever* > > provided me with a serviceable explanation as to why that's an > > invalid > > view. > > Good luck with that when you become an IPv4 island. Strawman, Owen; the content of my assertion clearly was meant to be interpreted in the context of the current, 98% IPv4 Internet, and extrapolated to IPv6; I was pretty clearly not suggesting that I want to stay IPv4 as the rest of the Net leaves... as you imply. Cheers, -- jra From jlewis at lewis.org Thu Feb 3 09:11:27 2011 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 3 Feb 2011 10:11:27 -0500 (EST) Subject: And so it ends... In-Reply-To: References: Message-ID: The real fun's going to be over the next several years as the RIR's become irrelevant in the acquisition of scarce IPv4 resources...and things become less stable as lots of orgs rush to implement a strange new IP version. On Thu, 3 Feb 2011, Wil Schultz wrote: > It's been a fun ride, adios good friend. > > -wil > > On Feb 3, 2011, at 6:35 AM, Scott Howard wrote: > >> 102/8 AfriNIC 2011-02 whois.afrinic.net ALLOCATED >> 103/8 APNIC 2011-02 whois.apnic.net ALLOCATED >> 104/8 ARIN 2011-02 whois.arin.net ALLOCATED >> 179/8 LACNIC 2011-02 whois.lacnic.net ALLOCATED >> 185/8 RIPE NCC 2011-02 whois.ripe.net ALLOCATED > > ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jra at baylink.com Thu Feb 3 09:12:02 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 3 Feb 2011 10:12:02 -0500 (EST) Subject: quietly.... In-Reply-To: <10030DF7-3718-421B-8B78-51454F81D2AE@delong.com> Message-ID: <31497797.4421.1296745922825.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > It's not transparent to: > Application Developers > Operating Systems > Home Gateway Developers > Consumer Electronics Developers > Technical Support departments > My users who are trying to talk to your users using applications that > are designed to work in a NAT-free world. > My technical support department that gets the "we can't reach them" > calls from my users who can't reach your users. > > It may not be your first trip to the rodeo, but, you do appear to have > a rather limited perspective on the far reaching detriments of NAT. This is possible. The networks I administer are, admittedly, smaller ones, and they tend to be business-aimed, and thereby have a more strictly limited set of policy-allowed uses... which I've set. Customer transit networks will necessarily expose a larger set of usage... but they also generally (Rose.net notwithstanding) don't apply NAT. I see cogent arguments on both sides of the issue. And my thanks to those on this part of this thread who've supplied actual explanations, rather than merely assertions. Cheers, -- jra From rcarpen at network1.net Thu Feb 3 09:13:12 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Thu, 3 Feb 2011 10:13:12 -0500 (EST) Subject: quietly.... In-Reply-To: <4D4AC31F.1050000@brightok.net> Message-ID: <790878118.2062.1296745992579.JavaMail.root@zimbra.network1.net> ----- Original Message ----- > On 2/2/2011 8:38 PM, Randy Carpenter wrote: > > > >> From the main section on > >> https://www.arin.net/fees/fee_schedule.html: > > > > "... ISPs with both IPv4 resources and IPv6 resources pay the larger > > of the two fees." > > > > It is not mentioned anywhere in the waiver stuff. > > > > The concept of v4 to v6 addressing scale doesn't match the pricing > scale, though. Generally, I expect to see most ISPs find themselves 1 > rank higher in the v6 model compared to v4, which effectively doubles > your price anyways. :) This is true, and is something that I hope ARIN addresses. Policy Proposal 121 urges the ARIN board to restructure the fees to more closely match the block sizes, should it be adopted. Hopefully both will happen. -Randy From tjc at ecs.soton.ac.uk Thu Feb 3 09:14:27 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Thu, 3 Feb 2011 15:14:27 +0000 Subject: Significant Announcement (re: IPv4) 3 February - Watch it Live! In-Reply-To: References: <4D47F7DE.6040102@arin.net> <34AA4613-61BD-4C3F-8480-6E10EE6309AE@corp.arin.net> <3CDAFF22BE6DAF43B7EA263F6707D2892BE3A9@mail.neutraldata.com> Message-ID: On 3 Feb 2011, at 14:49, Igor Ybema wrote: >> I think they were under a TCP-SYN attack :) >> >> The video was super choppy from here and I have bandwidth to burn at this >> time of the day. A little disappointing, but I'm sure (fingers crossed) >> someone will have a clean recording of it that they will make available. > > I saw that also. Switched to windows media stream which was working fine. > However,.. stream was not available on a IPv6 only host. Epic fail! :) Seemed the nro web site was v6 but the embedded video from flash.merit.edu was IPv4-only? Tim From tme at americafree.tv Thu Feb 3 09:14:42 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Thu, 3 Feb 2011 10:14:42 -0500 Subject: Egypt 'hijacked Vodafone network' In-Reply-To: <629152.45886.qm@web59601.mail.ac4.yahoo.com> References: <629152.45886.qm@web59601.mail.ac4.yahoo.com> Message-ID: On Feb 3, 2011, at 9:24 AM, andrew.wallace wrote: > Mobile phone firm Vodafone accuses the Egyptian authorities of using its network to send pro-government text messages. > > http://www.bbc.co.uk/news/business-12357694 Here is their PR http://www.vodafone.com/content/index/press.html Note that this is entirely legal, under "the emergency powers provisions of the Telecoms Act" Regards Marshall > > Andrew > > > > > > From jlewis at lewis.org Thu Feb 3 09:17:22 2011 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 3 Feb 2011 10:17:22 -0500 (EST) Subject: And so it ends... In-Reply-To: References: Message-ID: On Thu, 3 Feb 2011, Alex Rubenstein wrote: > And we have yet to see what happens with backend transactions between > private institutions that have large blocks laying around, and them > realizing that they have a marketable and valuable thing. We may all say > it won't happen, we may even say we don't want it to happen, or that it > shouldn't be allowed - but I'm a realist. Be a realist. A private market in IPv4 leasing is inevitable. The RIRs won't/can't prevent it. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jbates at brightok.net Thu Feb 3 09:18:50 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 03 Feb 2011 09:18:50 -0600 Subject: quietly.... In-Reply-To: <1F2028E9-C32B-4FF6-8A01-07F983E453E1@delong.com> References: <10058800.4297.1296708348990.JavaMail.root@benjamin.baylink.com> <20110203051311.GA24798@hezmatt.org> <1F2028E9-C32B-4FF6-8A01-07F983E453E1@delong.com> Message-ID: <4D4AC75A.9060807@brightok.net> On 2/3/2011 12:40 AM, Owen DeLong wrote: > Notice how the application was able to poke the holes in both sides > because it easily knew the address and port number information since > it isn't modified. Both firewalls think that the secondary channel is > an outbound connection on both sides. And the network attack vector with inside spoofing just go even more interesting and easier. Jack From rdobbins at arbor.net Thu Feb 3 09:20:01 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 3 Feb 2011 15:20:01 +0000 Subject: And so it ends... In-Reply-To: References: Message-ID: On Feb 3, 2011, at 9:35 PM, Scott Howard wrote: > 102/8 AfriNIC 2011-02 whois.afrinic.net ALLOCATED > 103/8 APNIC 2011-02 whois.apnic.net ALLOCATED > 104/8 ARIN 2011-02 whois.arin.net ALLOCATED > 179/8 LACNIC 2011-02 whois.lacnic.net ALLOCATED > 185/8 RIPE NCC 2011-02 whois.ripe.net ALLOCATED ----------------------------------------------------------------------- Roland Dobbins // From patrick at ianai.net Thu Feb 3 09:29:18 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 3 Feb 2011 10:29:18 -0500 Subject: Significant Announcement (re: IPv4) 3 February - Watch it Live! In-Reply-To: References: <1404600274.2040.1296744478836.JavaMail.root@zimbra.network1.net> Message-ID: On Feb 3, 2011, at 9:58 AM, Antonio Querubin wrote: > On Thu, 3 Feb 2011, Randy Carpenter wrote: > >> It didn't work too bad. Does anyone know why it was pretty much over at 9:30, when they said it would start? Did they start a half-hour early or something? > > I think that was just the ceremony for handing out the last /8s and it went very quickly. The press conference starts at 10:00. It definitely started at 9:30, and it was very short. Boring actually. But that's the way it should have been. Not like this was a surprise. Even the reporter from ZDNet asked "since we gave out the last 2 to APNIC last week, why is this day important?" If ZDNet gets it, NANOG (actually *NOG) members should as well. That said, I guess just like when any long time friend leaves us, we should have a ceremony to mark the passing. -- TTFN, patrick From patrick at ianai.net Thu Feb 3 09:30:53 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 3 Feb 2011 10:30:53 -0500 Subject: And so it ends... In-Reply-To: References: Message-ID: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> On Feb 3, 2011, at 10:11 AM, Jon Lewis wrote: > The real fun's going to be over the next several years as the RIR's become irrelevant in the acquisition of scarce IPv4 resources...and things become less stable as lots of orgs rush to implement a strange new IP version. Supposedly[*] transfers between private entities are still supposed to be justified to the local RIRs. (At least that's how it works in ARIN's area.) -- TTFN, patrick [*] I know, I know.... > On Thu, 3 Feb 2011, Wil Schultz wrote: > >> It's been a fun ride, adios good friend. >> >> -wil >> >> On Feb 3, 2011, at 6:35 AM, Scott Howard wrote: >> >>> 102/8 AfriNIC 2011-02 whois.afrinic.net ALLOCATED >>> 103/8 APNIC 2011-02 whois.apnic.net ALLOCATED >>> 104/8 ARIN 2011-02 whois.arin.net ALLOCATED >>> 179/8 LACNIC 2011-02 whois.lacnic.net ALLOCATED >>> 185/8 RIPE NCC 2011-02 whois.ripe.net ALLOCATED >> >> > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > From jbates at brightok.net Thu Feb 3 09:35:23 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 03 Feb 2011 09:35:23 -0600 Subject: quietly.... In-Reply-To: <4D4AB9B4.4060201@foobar.org> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <4D4979D1.4000104@phaze.org> <70C15FD9-CF85-4664-B913-3EBE4271C7F5@muada.com> <4D499910.4020001@foobar.org> <4D4AB894.6050107@brightok.net> <4D4AB9B4.4060201@foobar.org> Message-ID: <4D4ACB3B.4080200@brightok.net> On 2/3/2011 8:20 AM, Nick Hilliard wrote: > On 03/02/2011 14:15, Jack Bates wrote: >> Is this why the root isn't just using well-known? > > No - that's pretty much the only situation where you have a technical > requirement to hardcode IP address, and there's basically no way of > getting around it. > > Besides, it's completely different to having a requirement that all > locally connected machines should by default send all of their DNS > requests to a specific address. You're talking about a situation which > affects only DNS resolvers. I'm talking about something which affects > all end-user nodes in the world. i.e. much messier problem on a > completely different scale. You missed my pointed. Root servers are hard coded, but they aren't using a well known anycast address. Jack From nick at foobar.org Thu Feb 3 09:35:18 2011 From: nick at foobar.org (Nick Hilliard) Date: Thu, 03 Feb 2011 15:35:18 +0000 Subject: =?windows-1252?Q?Re=3A_Significant_Announcement_=28re=3A_?= =?windows-1252?Q?IPv4=29__3_February_=96_Watch_it_Live!?= In-Reply-To: <34AA4613-61BD-4C3F-8480-6E10EE6309AE@corp.arin.net> References: <4D47F7DE.6040102@arin.net> <34AA4613-61BD-4C3F-8480-6E10EE6309AE@corp.arin.net> Message-ID: <4D4ACB36.7060301@foobar.org> On 01/02/2011 13:23, John Curran wrote: > FYI - Some people in this community may want to watch this event (either in person or via webcast) I see Mr. Kolkman is involved in this press conference, and can therefore assume that Bert - working behind the scenes as he usually does - is fully responsible for depletion. Nick From rcarpen at network1.net Thu Feb 3 09:37:08 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Thu, 3 Feb 2011 10:37:08 -0500 (EST) Subject: quietly.... In-Reply-To: <0336232C-B037-4AFF-A91A-71FFAE2DDEF4@hubris.net> Message-ID: <299860873.2074.1296747428703.JavaMail.root@zimbra.network1.net> ----- Original Message ----- > On Feb 3, 2011, at 9:00 AM, Jack Bates wrote: > > > The concept of v4 to v6 addressing scale doesn't match the pricing > > scale, though. Generally, I expect to see most ISPs find themselves > > 1 rank higher in the v6 model compared to v4, which effectively > > doubles your price anyways. :) > > Not sure I understand that one. > > /19 = 500 /29s > > /32 = 64,000 /48s > > Shouldn't the v6 blocks be a lot bigger? > > Chris Yes, they should be. Someone with a /19 would likely be looking at larger than a /32. Under proposal 121, it would be a /28, which would double the fee. I would imagine that the fee structure would have to change somehow, since /31 and /30, for example, won't even be an option. -Randy From jared at puck.nether.net Thu Feb 3 09:36:53 2011 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 3 Feb 2011 10:36:53 -0500 Subject: It's the end of IPv4 as we know it... and I feel fine.. In-Reply-To: References: Message-ID: <532030EB-3A85-4E86-ACEC-ED273183BE3C@puck.nether.net> (apologies to REM) On Feb 3, 2011, at 10:11 AM, Jon Lewis wrote: > The real fun's going to be over the next several years as the RIR's become irrelevant in the acquisition of scarce IPv4 resources...and things become less stable as lots of orgs rush to implement a strange new IP version. There's clearly two things that need to be done: 1) Major infrastructure (ie: backhaul, corporate, ISP gateway) need to be upgraded/configured to support IPv6 2) Edge networks need to start to hand out IPv6 addresses and name servers. I think it would be great if providers started handing out IPv6 addressed name servers when an IPv4 client does a dhcp renew, etc. (eg: the NANOG conference lan gave my iPhone/iPad v6 nameservers..) #1 should be easy enough to do #2 is complicated as well by the lack of a single coherent edge technology that can deliver solutions - Jared (btw: has anyone configured IOS PPTP/VPDN to hand out IPv6 that would be willing to share config example with me) From trejrco at gmail.com Thu Feb 3 09:39:28 2011 From: trejrco at gmail.com (TJ) Date: Thu, 3 Feb 2011 10:39:28 -0500 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <5C836A1A98186142A6BEC393FD5E2A8601578D@hal.photon.com> References: <1296089078.6522.194.camel@karl> <5D2659F3-5853-4C1C-A26D-D6EB5AA75195@delong.com> <4D4820E1.20600@brightok.net> <077208EB-39DF-4F51-B263-E1BEB0BCE75A@delong.com> <4D48454A.1090807@brightok.net> <4D488FF8.4010106@brightok.net> <8998E21B-14FB-45A8-A849-D1416E946505@delong.com> <20110201233846.GV13890@angus.ind.WPI.EDU> <5C836A1A98186142A6BEC393FD5E2A8601578D@hal.photon.com> Message-ID: On Wed, Feb 2, 2011 at 08:11, Jamie Bowden wrote: > Our classified networks aren't ever going to be connected to anything > but themselves either, and they need sane local addressing. Some of > them are a single room with a few machines, some of them are entire > facilities with hundreds of machines, but none of them are going to be > talking to a router or anything upstream, as neither of those exist on > said networks. > Correct me if I am wrong, but won't Classified networks will get their addresses IAW the DoD IPv6 Addressing Plan (using globals)? /TJ From tme at americafree.tv Thu Feb 3 09:57:08 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Thu, 3 Feb 2011 10:57:08 -0500 Subject: Significant Announcement (re: IPv4) 3 February - Watch it Live! In-Reply-To: References: <20110203144344.GB890@hiwaay.net> <1404600274.2040.1296744478836.JavaMail.root@zimbra.network1.net> Message-ID: <4900C41C-3414-424A-9683-DE3D7F25FC85@americafree.tv> On Feb 3, 2011, at 10:00 AM, Max Larson Henry wrote: > News conference starts now The exhaustion has made CNN http://www.cnn.com/2011/TECH/web/02/03/internet.addresses.gone/ Marshall > > -M > > > On Thu, Feb 3, 2011 at 9:47 AM, Randy Carpenter wrote: > >> >> It didn't work too bad. Does anyone know why it was pretty much over at >> 9:30, when they said it would start? Did they start a half-hour early or >> something? >> >> >> -Randy >> >> -- >> | Randy Carpenter >> | Vice President - IT Services >> | Red Hat Certified Engineer >> | First Network Group, Inc. >> | (800)578-6381, Opt. 1 >> ---- >> >> ----- Original Message ----- >>> Once upon a time, Sameer Khosla said: >>>> Anyone else getting Error establishing a database connection trying >>>> to >>>> bring this up? >>> >>> It was posted to /. this morning, so it is probably overloaded (I >>> didn't >>> even try). >>> -- >>> Chris Adams >>> Systems and Network Administrator - HiWAAY Internet Services >>> I don't speak for anybody but myself - that's enough trouble. >> >> >> > From jeffrey.lyon at blacklotus.net Thu Feb 3 09:38:22 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 3 Feb 2011 10:38:22 -0500 Subject: And so it ends... In-Reply-To: References: Message-ID: On Thu, Feb 3, 2011 at 9:58 AM, Alex Rubenstein wrote: > And we have yet to see what happens with backend transactions between private institutions that have large blocks laying around, and them realizing that they have a marketable and valuable thing. We may all say it won't happen, we may even say we don't want it to happen, or that it shouldn't be allowed - but I'm a realist. > > >> From: Max Larson Henry [mailto:maxlarson.henry at transversal.ht] >> >> Still a few LEGACY in the status column ;-) >> >> -M >> >> On Thu, Feb 3, 2011 at 9:35 AM, Scott Howard wrote: >> >> > 102/8 ? AfriNIC ? ?2011-02 ? ?whois.afrinic.net ALLOCATED >> > 103/8 ? APNIC ? ? ?2011-02 ? ?whois.apnic.net ? ALLOCATED >> > 104/8 ? ARIN ? ? ? 2011-02 ? ?whois.arin.net ? ?ALLOCATED >> > 179/8 ? LACNIC ? ? 2011-02 ? ?whois.lacnic.net ?ALLOCATED >> > 185/8 ? RIPE NCC ? 2011-02 ? ?whois.ripe.net ? ?ALLOCATED >> > > > My theory is that IPv4 will continue to survive with companies becoming more and more conservative on the use of space. IPv6 adoption will happen more substantially as the cost of second hand IPv4 becomes more and more severe, approaching the apex of IPv4 cost vs. IPv6 adoption cost. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From jamie at photon.com Thu Feb 3 10:08:59 2011 From: jamie at photon.com (Jamie Bowden) Date: Thu, 3 Feb 2011 11:08:59 -0500 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: References: <1296089078.6522.194.camel@karl><5D2659F3-5853-4C1C-A26D-D6EB5AA75195@delong.com><4D4820E1.20600@brightok.net><077208EB-39DF-4F51-B263-E1BEB0BCE75A@delong.com><4D48454A.1090807@brightok.net><4D488FF8.4010106@brightok.net><8998E21B-14FB-45A8-A849-D1416E946505@delong.com><20110201233846.GV13890@angus.ind.WPI.EDU><5C836A1A98186142A6BEC393FD5E2A8601578D@hal.photon.com> Message-ID: <5C836A1A98186142A6BEC393FD5E2A86015794@hal.photon.com> If you're on a DoD classified network that spans multiple facilities (as a contractor we only get access to certain ones, and only certain hosts are allowed to access them). Self contained networks are our problem. Jamie -----Original Message----- From: TJ [mailto:trejrco at gmail.com] Sent: Thursday, February 03, 2011 10:39 AM To: NANOG Subject: Re: Using IPv6 with prefixes shorter than a /64 on a LAN On Wed, Feb 2, 2011 at 08:11, Jamie Bowden wrote: > Our classified networks aren't ever going to be connected to anything > but themselves either, and they need sane local addressing. Some of > them are a single room with a few machines, some of them are entire > facilities with hundreds of machines, but none of them are going to be > talking to a router or anything upstream, as neither of those exist on > said networks. > Correct me if I am wrong, but won't Classified networks will get their addresses IAW the DoD IPv6 Addressing Plan (using globals)? /TJ From rbonica at juniper.net Thu Feb 3 10:04:29 2011 From: rbonica at juniper.net (Ronald Bonica) Date: Thu, 3 Feb 2011 11:04:29 -0500 Subject: And so it ends (slightly off topic) In-Reply-To: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> Message-ID: <13205C286662DE4387D9AF3AC30EF456B16F4B85AC@EMBX01-WF.jnpr.net> Folks, Somehow, it is appropriate that this should happen on February 3. On February 3, 1959, Buddy Holly, Richie Valens and JP Richardson (aka The Big Bopper) died in a plane crash. Don McLean immortalized that day as "The Day The Music Died" in his 1971 hit, "American Pie". Ron From sstack at citco.com Thu Feb 3 10:15:13 2011 From: sstack at citco.com (Stack, Stephen (Citco)) Date: Thu, 3 Feb 2011 16:15:13 +0000 Subject: Significant Announcement (re: IPv4) 3 February - Watch it Live! In-Reply-To: <4900C41C-3414-424A-9683-DE3D7F25FC85@americafree.tv> References: <20110203144344.GB890@hiwaay.net> <1404600274.2040.1296744478836.JavaMail.root@zimbra.network1.net> <4900C41C-3414-424A-9683-DE3D7F25FC85@americafree.tv> Message-ID: <1691673F105F974E97B60CC2263A6A2F468B03904C@CRK2MSEXM01.ad.ent.citco.com> 340 'undecillion', what a great word!!! Number!!! Stephen -----Original Message----- From: Marshall Eubanks [mailto:tme at americafree.tv] Sent: 03 February 2011 15:57 To: Max Larson Henry Cc: nanog at nanog.org Subject: Re: Significant Announcement (re: IPv4) 3 February - Watch it Live! On Feb 3, 2011, at 10:00 AM, Max Larson Henry wrote: > News conference starts now The exhaustion has made CNN http://www.cnn.com/2011/TECH/web/02/03/internet.addresses.gone/ Marshall > > -M > > > On Thu, Feb 3, 2011 at 9:47 AM, Randy Carpenter wrote: > >> >> It didn't work too bad. Does anyone know why it was pretty much over at >> 9:30, when they said it would start? Did they start a half-hour early or >> something? >> >> >> -Randy >> >> -- >> | Randy Carpenter >> | Vice President - IT Services >> | Red Hat Certified Engineer >> | First Network Group, Inc. >> | (800)578-6381, Opt. 1 >> ---- >> >> ----- Original Message ----- >>> Once upon a time, Sameer Khosla said: >>>> Anyone else getting Error establishing a database connection trying >>>> to >>>> bring this up? >>> >>> It was posted to /. this morning, so it is probably overloaded (I >>> didn't >>> even try). >>> -- >>> Chris Adams >>> Systems and Network Administrator - HiWAAY Internet Services >>> I don't speak for anybody but myself - that's enough trouble. >> >> >> > Disclaimer link. To see it, click the link below, or copy and paste it into your browser's address line. http://www.citco.com/emaildisclaimer.htm From owen at delong.com Thu Feb 3 10:12:55 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 3 Feb 2011 08:12:55 -0800 Subject: quietly.... In-Reply-To: <4D4AC31F.1050000@brightok.net> References: <1906085828.1923.1296700690262.JavaMail.root@zimbra.network1.net> <4D4AC31F.1050000@brightok.net> Message-ID: <1194ECD9-496C-4270-9A1F-C9D4D91204E3@delong.com> On Feb 3, 2011, at 7:00 AM, Jack Bates wrote: > > > On 2/2/2011 8:38 PM, Randy Carpenter wrote: >> >>> From the main section on https://www.arin.net/fees/fee_schedule.html: >> >> "... ISPs with both IPv4 resources and IPv6 resources pay the larger of the two fees." >> >> It is not mentioned anywhere in the waiver stuff. >> > > The concept of v4 to v6 addressing scale doesn't match the pricing scale, though. Generally, I expect to see most ISPs find themselves 1 rank higher in the v6 model compared to v4, which effectively doubles your price anyways. :) > > > Jack Actually, so far, most ISPs are finding themselves one rank lower. The exception is particularly small providers and there is a combination of suggestion (about fees) and policy (Proposal 121) effort underway to rectify that problem. Owen From jlewis at lewis.org Thu Feb 3 10:16:18 2011 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 3 Feb 2011 11:16:18 -0500 (EST) Subject: quietly.... In-Reply-To: References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <4D48E558.7070805@brightok.net> <2FD9EDE7-E28C-48E7-B6FB-8386773EF98E@delong.com> <9689E83C-048A-4D72-946B-978FB3C315A4@sackheads.org> , <3CD3A697-8D3C-4EDE-8E4E-53C0E103E12C@sackheads.org> <4D4A43B6.5080306@otd.com> Message-ID: On Thu, 3 Feb 2011, Brian Johnson wrote: >> 3) To give all your outbound sessions a mutual appearance, so as to >> confound those attempting to build a profile of your activity. > > So this goes back to security through obscurity. OK. There's an awful lot of inertia in the "NAPT/firewall keeps our hosts safe from the internet" mentality. Sure, a stateful firewall can be configured allow all outbound traffic and only connected/related inbound. When someone breaks or shuts off that filter, traffic through the NAPT firewall stops working. On the stateful firewall with public IPs on both sides, everything works...including the traffic you didn't want. People are going to want NAT66...and not providing it may slow down IPv6 adoption. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From bensons at queuefull.net Thu Feb 3 10:22:05 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Thu, 3 Feb 2011 10:22:05 -0600 Subject: And so it ends... In-Reply-To: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> Message-ID: On Feb 3, 2011, at 9:30 AM, Patrick W. Gilmore wrote: > On Feb 3, 2011, at 10:11 AM, Jon Lewis wrote: > >> The real fun's going to be over the next several years as the RIR's become irrelevant in the acquisition of scarce IPv4 resources...and things become less stable as lots of orgs rush to implement a strange new IP version. > > Supposedly[*] transfers between private entities are still supposed to be justified to the local RIRs. (At least that's how it works in ARIN's area.) That's what the RIR might say. But without legal authority (e.g. under contract, as a regulator, or through statutory authority) it is difficult or impossible to enforce. We can talk about how people "should" return addresses, or "should" justify transfers, etc, but we would only be begging. Transfers will take place outside the RIR scope, because RIR transfer/market policy doesn't accommodate reality. Or, we can fix policy..? Cheers, -Benson From owen at delong.com Thu Feb 3 10:21:14 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 3 Feb 2011 08:21:14 -0800 Subject: And so it ends... In-Reply-To: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> Message-ID: On Feb 3, 2011, at 7:30 AM, Patrick W. Gilmore wrote: > On Feb 3, 2011, at 10:11 AM, Jon Lewis wrote: > >> The real fun's going to be over the next several years as the RIR's become irrelevant in the acquisition of scarce IPv4 resources...and things become less stable as lots of orgs rush to implement a strange new IP version. > > Supposedly[*] transfers between private entities are still supposed to be justified to the local RIRs. (At least that's how it works in ARIN's area.) > The only registry where it doesn't work that way at this time is APNIC. RIPE is unfortunately considering the APNIC model. Fortunately, APNIC is reconsidering their model. Owen From jra at baylink.com Thu Feb 3 10:27:06 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 3 Feb 2011 11:27:06 -0500 (EST) Subject: quietly.... In-Reply-To: <9CF17C6A-4A8D-4687-A8A9-5474BD26DEDB@delong.com> Message-ID: <32776191.4481.1296750426524.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > The point I'm trying to get across to you is that your security does > NOT come from NAT. It comes from the stateful inspection mechanism and > the policies you set within that stateful inspection mechanism. The > unfortunate problem is that an entire generation of engineers has > grown up not knowing the difference between stateful inspection and > NAT because hardly any products contained stateful inspection without > NAT and stateful inspection with address translation is a mouthful > and NAT is a syllable. The point you *appear* to be trying to make is that *NO* security comes from NAT, and that is not a defensible argument. If that's not what you mean to say, you might want to reexamine your phrasing. :-) Cheers, -- jra From sethm at rollernet.us Thu Feb 3 10:27:38 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 03 Feb 2011 08:27:38 -0800 Subject: It's the end of IPv4 as we know it... and I feel fine.. In-Reply-To: <532030EB-3A85-4E86-ACEC-ED273183BE3C@puck.nether.net> References: <532030EB-3A85-4E86-ACEC-ED273183BE3C@puck.nether.net> Message-ID: <4D4AD77A.4050705@rollernet.us> On 2/3/11 7:36 AM, Jared Mauch wrote: > (apologies to REM) > > On Feb 3, 2011, at 10:11 AM, Jon Lewis wrote: > >> The real fun's going to be over the next several years as the RIR's become irrelevant in the acquisition of scarce IPv4 resources...and things become less stable as lots of orgs rush to implement a strange new IP version. > > There's clearly two things that need to be done: > > 1) Major infrastructure (ie: backhaul, corporate, ISP gateway) need to be upgraded/configured to support IPv6 > 2) Edge networks need to start to hand out IPv6 addresses and name servers. I think it would be great if providers started handing out IPv6 addressed name servers when an IPv4 client does a dhcp renew, etc. > Well, I'm doing my part by turning up native IPv6 at my parent's house this week or next. They are not technically inclined and I'm confident it won't be a problem. ;) ~Seth From jra at baylink.com Thu Feb 3 10:29:01 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 3 Feb 2011 11:29:01 -0500 (EST) Subject: quietly.... In-Reply-To: Message-ID: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jon Lewis" > There's an awful lot of inertia in the "NAPT/firewall keeps our hosts > safe from the internet" mentality. Sure, a stateful firewall can be > configured allow all outbound traffic and only connected/related > inbound. > When someone breaks or shuts off that filter, traffic through the NAPT > firewall stops working. On the stateful firewall with public IPs on > both sides, everything works...including the traffic you didn't want. Precisely. This is the crux of the argument I've been trying, rather ineptly, to make: when it breaks, *which way does it fail*. NAT fails safe, generally. > People are going to want NAT66...and not providing it may slow down > IPv6 adoption. You're using the future tense there, Jon; are you sure you didn't mean to use the present? Or the past...? Cheers, -- jra From owen at delong.com Thu Feb 3 10:24:34 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 3 Feb 2011 08:24:34 -0800 Subject: quietly.... In-Reply-To: <299860873.2074.1296747428703.JavaMail.root@zimbra.network1.net> References: <299860873.2074.1296747428703.JavaMail.root@zimbra.network1.net> Message-ID: <6DD6AF9B-9203-4B26-B8E0-7EBFA266CA21@delong.com> On Feb 3, 2011, at 7:37 AM, Randy Carpenter wrote: > > ----- Original Message ----- >> On Feb 3, 2011, at 9:00 AM, Jack Bates wrote: >> >>> The concept of v4 to v6 addressing scale doesn't match the pricing >>> scale, though. Generally, I expect to see most ISPs find themselves >>> 1 rank higher in the v6 model compared to v4, which effectively >>> doubles your price anyways. :) >> >> Not sure I understand that one. >> >> /19 = 500 /29s >> >> /32 = 64,000 /48s >> >> Shouldn't the v6 blocks be a lot bigger? >> >> Chris > > Yes, they should be. Someone with a /19 would likely be looking at larger than a /32. Under proposal 121, it would be a /28, which would double the fee. I would imagine that the fee structure would have to change somehow, since /31 and /30, for example, won't even be an option. > > -Randy > I fully expect that if proposal 121 is adopted (and I very much hope it will be), the board will make appropriate changes to the fee structure. It is also important to note that while 121 sets liberal maximum allocation sizes, it does not require providers to request or accept maximum allocations. A provider that qualifies for a /28 can request and get a /32 or even a /36 if they really want. So far, there has been good support for it, but if you are interested, please get on PPML and express your opinion. Owen From patrick at ianai.net Thu Feb 3 10:30:24 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 3 Feb 2011 11:30:24 -0500 Subject: And so it ends... In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> Message-ID: On Feb 3, 2011, at 11:22 AM, Benson Schliesser wrote: > On Feb 3, 2011, at 9:30 AM, Patrick W. Gilmore wrote: >> On Feb 3, 2011, at 10:11 AM, Jon Lewis wrote: >> >>> The real fun's going to be over the next several years as the RIR's become irrelevant in the acquisition of scarce IPv4 resources...and things become less stable as lots of orgs rush to implement a strange new IP version. >> >> Supposedly[*] transfers between private entities are still supposed to be justified to the local RIRs. (At least that's how it works in ARIN's area.) > > That's what the RIR might say. But without legal authority (e.g. under contract, as a regulator, or through statutory authority) it is difficult or impossible to enforce. You missed the [*] where I said "I know, I know...." -- TTFN, patrick > can talk about how people "should" return addresses, or "should" justify transfers, etc, but we would only be begging. Transfers will take place outside the RIR scope, because RIR transfer/market policy doesn't accommodate reality. > > Or, we can fix policy..? > > Cheers, > -Benson > > From iljitsch at muada.com Thu Feb 3 10:30:11 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 3 Feb 2011 17:30:11 +0100 Subject: quietly.... In-Reply-To: References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <4D48E558.7070805@brightok.net> <2FD9EDE7-E28C-48E7-B6FB-8386773EF98E@delong.com> <9689E83C-048A-4D72-946B-978FB3C315A4@sackheads.org> , <3CD3A697-8D3C-4EDE-8E4E-53C0E103E12C@sackheads.org> <4D4A43B6.5080306@otd.com> Message-ID: <5A51DAF3-6189-4785-9543-CB046B2819B9@muada.com> On 3 feb 2011, at 17:16, Jon Lewis wrote: > When someone breaks or shuts off that filter, traffic through the NAPT firewall stops working. On the stateful firewall with public IPs on both sides, everything works...including the traffic you didn't want. > People are going to want NAT66...and not providing it may slow down IPv6 adoption. Hm, if you turn off the NAT66 function, wouldn't the traffic pass through unhindered, too? Or do you propose to make IPv6 home gateways the same way IPv4 home gateways work, where it's usually not even possible to turn it off? Consumer systems need to be able to function without a firewall device, anyway. Who brings a firewall to a wifi hotspot, or puts one between his laptop and 3G adapter? I'm perfectly happy with an IPv6 network that only has rational people on it while those who insist on NAT stay behind on IPv4. From jlewis at lewis.org Thu Feb 3 10:32:40 2011 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 3 Feb 2011 11:32:40 -0500 (EST) Subject: And so it ends... In-Reply-To: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> Message-ID: On Thu, 3 Feb 2011, Patrick W. Gilmore wrote: > On Feb 3, 2011, at 10:11 AM, Jon Lewis wrote: > >> The real fun's going to be over the next several years as the RIR's >> become irrelevant in the acquisition of scarce IPv4 resources...and >> things become less stable as lots of orgs rush to implement a strange >> new IP version. > > Supposedly[*] transfers between private entities are still supposed to > be justified to the local RIRs. (At least that's how it works in ARIN's > area.) I was going to say this when I walked up to the mic at the IPv4 runout talk yesterday morning, but sat down when they said "we're going to wrap this up now" and ended up going and talking to the RIPE people about it. For a year or more, there have been RIPE region LIRs willing to lease relatively large amounts of IPv4 to anyone willing to pay. The ones I've been noticing have been "snowshoe spammers" who get their RIPE space and then announce it in datacenters in the US...presumably on rented dedicated servers from which they send spam. My point being, the leasing of IP space to non-connectivity customers is already well established, whether it's technically permitted by the [ir]relevant RIRs. I fully expect this to continue and spread. Eventually, holders of large legacy blocks will realize they can make good money acting as an LIR, leasing portions of their unused space to people who need it and can't get it, want it and don't qualify, etc. These start-up LIRs won't be bound by RIR policies, both because in some cases they'll be legacy space holders with no RSA with their region's RIR, and because they won't be worried about eligibility for future RIR allocations of v4 space...because there won't be any. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From bmanning at vacation.karoshi.com Thu Feb 3 10:38:08 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 3 Feb 2011 16:38:08 +0000 Subject: And so it ends... NOT In-Reply-To: References: Message-ID: <20110203163808.GA29231@vacation.karoshi.com.> For all you folks mourning the demise of IPv4, could you PLEASE transfer those old, used, not useful to you anymore IPv4 blocks to me ... PLEASE? Pretty Please? just saying. --bill From rcarpen at network1.net Thu Feb 3 10:39:59 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Thu, 3 Feb 2011 11:39:59 -0500 (EST) Subject: quietly.... In-Reply-To: <1194ECD9-496C-4270-9A1F-C9D4D91204E3@delong.com> Message-ID: <1344594475.2126.1296751198990.JavaMail.root@zimbra.network1.net> > > The concept of v4 to v6 addressing scale doesn't match the pricing > > scale, though. Generally, I expect to see most ISPs find themselves > > 1 rank higher in the v6 model compared to v4, which effectively > > doubles your price anyways. :) > > > > > > Jack > > Actually, so far, most ISPs are finding themselves one rank lower. > > The exception is particularly small providers and there is a > combination of suggestion (about fees) and policy (Proposal 121) > effort underway to rectify that problem. > > Owen A specific example of the sizes of ISP I am working with: Most of them have between a /17 and a /20 of address space. If (hopefully when) Proposal 121 is adopted, all of the ones that are around a /17, should be getting a /28. Some of the ones that are /19 currently, would be getting a /28. While I wholeheartedly agree with Proposal 121, that represents 2 jumps in cost. These might represent some unusual situations, and might even fall under your definition of "particularly small." I hope that if Proposal 121 does pass, that the fees are restructured so that /36, /32, /28, /24, and /20 have different fees that line up with X-small, Small, Medium, Large, and X-large, respectively. -Randy From jcurran at arin.net Thu Feb 3 10:39:13 2011 From: jcurran at arin.net (John Curran) Date: Thu, 3 Feb 2011 16:39:13 +0000 Subject: And so it ends... In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> Message-ID: <6E186F3F-6267-4D9B-916A-3663F13AA999@corp.arin.net> On Feb 3, 2011, at 11:22 AM, Benson Schliesser wrote: > That's what the RIR might say. But without legal authority (e.g. under contract, as a regulator, or through statutory authority) it is difficult or impossible to enforce. Transfers are permitted in the ARIN region per the community developed policies. > We can talk about how people "should" return addresses, or "should" justify transfers, etc, but we would only be begging. Transfers will take place outside the RIR scope, because RIR transfer/market policy doesn't accommodate reality. Such transfers should be reported when noticed, so the resources can be reclaimed and reissued. > Or, we can fix policy..? Absolutely... if the policy doesn't match your needs, please make a policy proposal. Thanks! /John John Curran President and CEO ARIN From jlewis at lewis.org Thu Feb 3 10:40:52 2011 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 3 Feb 2011 11:40:52 -0500 (EST) Subject: quietly.... In-Reply-To: <5A51DAF3-6189-4785-9543-CB046B2819B9@muada.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <4D48E558.7070805@brightok.net> <2FD9EDE7-E28C-48E7-B6FB-8386773EF98E@delong.com> <9689E83C-048A-4D72-946B-978FB3C315A4@sackheads.org> , <3CD3A697-8D3C-4EDE-8E4E-53C0E103E12C@sackheads.org> <4D4A43B6.5080306@otd.com> <5A51DAF3-6189-4785-9543-CB046B2819B9@muada.com> Message-ID: On Thu, 3 Feb 2011, Iljitsch van Beijnum wrote: > On 3 feb 2011, at 17:16, Jon Lewis wrote: > >> When someone breaks or shuts off that filter, traffic through the NAPT firewall stops working. On the stateful firewall with public IPs on both sides, everything works...including the traffic you didn't want. > >> People are going to want NAT66...and not providing it may slow down IPv6 adoption. > > Hm, if you turn off the NAT66 function, wouldn't the traffic pass through unhindered, too? Outbound traffic would. Inbound, if on the inside, you're using IPv6 space that's not globally routed, won't. Just like what happens now with NAPT with rfc1918 space on the inside when you stop doing translation...private IP traffic leaks out...but nothing comes back because there is no return path. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From juicewvu at gmail.com Thu Feb 3 10:38:52 2011 From: juicewvu at gmail.com (Josh Smith) Date: Thu, 3 Feb 2011 11:38:52 -0500 Subject: It's the end of IPv4 as we know it... and I feel fine.. In-Reply-To: <4D4AD77A.4050705@rollernet.us> References: <532030EB-3A85-4E86-ACEC-ED273183BE3C@puck.nether.net> <4D4AD77A.4050705@rollernet.us> Message-ID: Seth, What sort of ISP do your "not technically inclined" parents have that offers native ipv6? :-) -- Josh Smith KD8HRX email/jabber:? juicewvu at gmail.com phone:? 304.237.9369(c) On Thu, Feb 3, 2011 at 11:27 AM, Seth Mattinen wrote: > On 2/3/11 7:36 AM, Jared Mauch wrote: >> (apologies to REM) >> >> On Feb 3, 2011, at 10:11 AM, Jon Lewis wrote: >> >>> The real fun's going to be over the next several years as the RIR's become irrelevant in the acquisition of scarce IPv4 resources...and things become less stable as lots of orgs rush to implement a strange new IP version. >> >> There's clearly two things that need to be done: >> >> 1) Major infrastructure (ie: backhaul, corporate, ISP gateway) need to be upgraded/configured to support IPv6 >> 2) Edge networks need to start to hand out IPv6 addresses and name servers. ?I think it would be great if providers started handing out IPv6 addressed name servers when an IPv4 client does a dhcp renew, etc. >> > > > Well, I'm doing my part by turning up native IPv6 at my parent's house > this week or next. They are not technically inclined and I'm confident > it won't be a problem. ;) > > ~Seth > > From mhuff at ox.com Thu Feb 3 10:46:11 2011 From: mhuff at ox.com (Matthew Huff) Date: Thu, 3 Feb 2011 11:46:11 -0500 Subject: quietly.... In-Reply-To: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> Message-ID: <483E6B0272B0284BA86D7596C40D29F9011F76964E89@PUR-EXCH07.ox.com> There is also another reason for NAT44 or NAT66 in the corporate world that has been missed in these conversations. It is very common to NAT44 when connected via extranets to another company via an b2b provider such as TNS or BTRadianz. Not everything goes over the net. NAT44 (especially "twice-nat") is used for a number of reasons including limiting of exchange of routing information, routing of different services in different directions via NAT, or to prevent having to contact the other side when a server changes. For example if we are natting one of our FIX servers then the internal machine can change as long as the NAT is updated. This is far simpler than having to get the changes externally especially at some big bank. Also some companies bring internet routes into their core (I still don't know why). In order to route web/email to them via the internet and protocols such as FIX via an extranet, twice-nat is required. Within similar function in Ipv6, there are a lot of companies, especially in the financial realm, that won't migrate off of ipv4. NAT is used for a reason, not just because "we don't know better". Yes, we know it breaks certain apps, especially p2p ones. In a corporate view, that is a feature, not a bug. We neither want, nor will allow individual desktops to become peers. Only a limited number of dedicated servers have external visibility, and that's the way it's going to stay regardless of ipv6 ideology. > -----Original Message----- > From: Jay Ashworth [mailto:jra at baylink.com] > Sent: Thursday, February 03, 2011 11:29 AM > To: NANOG > Subject: Re: quietly.... > > ----- Original Message ----- > > From: "Jon Lewis" > > > There's an awful lot of inertia in the "NAPT/firewall keeps our hosts > > safe from the internet" mentality. Sure, a stateful firewall can be > > configured allow all outbound traffic and only connected/related > > inbound. > > > When someone breaks or shuts off that filter, traffic through the NAPT > > firewall stops working. On the stateful firewall with public IPs on > > both sides, everything works...including the traffic you didn't want. > > Precisely. > > This is the crux of the argument I've been trying, rather ineptly, > to make: when it breaks, *which way does it fail*. NAT fails safe, > generally. > > > People are going to want NAT66...and not providing it may slow down > > IPv6 adoption. > > You're using the future tense there, Jon; are you sure you didn't mean > to use the present? Or the past...? > > Cheers, > -- jra From tchristell at springnet.net Thu Feb 3 10:48:49 2011 From: tchristell at springnet.net (Todd Christell) Date: Thu, 3 Feb 2011 10:48:49 -0600 Subject: Significant Announcement (re: IPv4) 3 February - Watch it Live! In-Reply-To: <1691673F105F974E97B60CC2263A6A2F468B03904C@CRK2MSEXM01.ad.ent.citco.com> References: <20110203144344.GB890@hiwaay.net> <1404600274.2040.1296744478836.JavaMail.root@zimbra.network1.net> <4900C41C-3414-424A-9683-DE3D7F25FC85@americafree.tv> <1691673F105F974E97B60CC2263A6A2F468B03904C@CRK2MSEXM01.ad.ent.citco.com> Message-ID: <97487AA41962C74E83D8ABABD2A90A49076EF850EF@mail.springnet.local> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 340 undecillion, 282 decillion, 366 nonillion, 920 octillion, 938 septillion, 463 sextillion, 463 quintillion, 374 quadrillion, 607 trillion, 431 billion, 768 million, 211 thousand, 456 Todd Christell Manager Network Architecture and Support www.springnet.net 417.831.8688 Key fingerprint = 4F26 A0B4 5AAD 7FCA 48DD 7F40 A57E 9235 5202 D508 - -----Original Message----- From: Stack, Stephen (Citco) [mailto:sstack at citco.com] Sent: Thursday, February 03, 2011 10:15 AM To: Marshall Eubanks; Max Larson Henry Cc: nanog at nanog.org Subject: RE: Significant Announcement (re: IPv4) 3 February - Watch it Live! 340 'undecillion', what a great word!!! Number!!! Stephen - -----Original Message----- From: Marshall Eubanks [mailto:tme at americafree.tv] Sent: 03 February 2011 15:57 To: Max Larson Henry Cc: nanog at nanog.org Subject: Re: Significant Announcement (re: IPv4) 3 February - Watch it Live! On Feb 3, 2011, at 10:00 AM, Max Larson Henry wrote: > News conference starts now The exhaustion has made CNN http://www.cnn.com/2011/TECH/web/02/03/internet.addresses.gone/ Marshall > > -M > > > On Thu, Feb 3, 2011 at 9:47 AM, Randy Carpenter wrote: > >> >> It didn't work too bad. Does anyone know why it was pretty much over at >> 9:30, when they said it would start? Did they start a half-hour early or >> something? >> >> >> -Randy >> >> -- >> | Randy Carpenter >> | Vice President - IT Services >> | Red Hat Certified Engineer >> | First Network Group, Inc. >> | (800)578-6381, Opt. 1 >> ---- >> >> ----- Original Message ----- >>> Once upon a time, Sameer Khosla said: >>>> Anyone else getting Error establishing a database connection trying >>>> to >>>> bring this up? >>> >>> It was posted to /. this morning, so it is probably overloaded (I >>> didn't >>> even try). >>> -- >>> Chris Adams >>> Systems and Network Administrator - HiWAAY Internet Services >>> I don't speak for anybody but myself - that's enough trouble. >> >> >> > Disclaimer link. To see it, click the link below, or copy and paste it into your browser's address line. http://www.citco.com/emaildisclaimer.htm -----BEGIN PGP SIGNATURE----- Version: 10.0.3 (Build 1) Charset: utf-8 wj8DBQFNStwFpX6SNVIC1QgRAskEAJ4vda6BY/TL5XGOzPPx5S7tvhBRfQCfV+6R AEgujaLswtnPm0/pw6J/Plo= =m4wo -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: Christell Todd.vcf Type: text/x-vcard Size: 548 bytes Desc: Christell Todd.vcf URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Christell Todd.vcf.sig Type: application/octet-stream Size: 188 bytes Desc: Christell Todd.vcf.sig URL: From jbates at brightok.net Thu Feb 3 10:47:50 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 03 Feb 2011 10:47:50 -0600 Subject: quietly.... In-Reply-To: <5A51DAF3-6189-4785-9543-CB046B2819B9@muada.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <4D48E558.7070805@brightok.net> <2FD9EDE7-E28C-48E7-B6FB-8386773EF98E@delong.com> <9689E83C-048A-4D72-946B-978FB3C315A4@sackheads.org> , <3CD3A697-8D3C-4EDE-8E4E-53C0E103E12C@sackheads.org> <4D4A43B6.5080306@otd.com> <5A51DAF3-6189-4785-9543-CB046B2819B9@muada.com> Message-ID: <4D4ADC36.1080803@brightok.net> On 2/3/2011 10:30 AM, Iljitsch van Beijnum wrote: > Hm, if you turn off the NAT66 function, wouldn't the traffic pass > through unhindered, too? > Only if the ISP is routing your inside address space to the firewall. > Or do you propose to make IPv6 home gateways the same way IPv4 home > gateways work, where it's usually not even possible to turn it off? > Home gateways don't need NAT. It's a balancing act between what is acceptable to break and what isn't. You wouldn't put uPNP on a corporate firewall either (but it's necessary for home gateways even without NAT). > I'm perfectly happy with an IPv6 network that only has rational > people on it while those who insist on NAT stay behind on IPv4. I'm perfectly happy with watching the Internet go to hell; as it has been, and IPv6 will just escalate it. :) Jack From tme at americafree.tv Thu Feb 3 10:49:24 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Thu, 3 Feb 2011 11:49:24 -0500 Subject: And so it ends (slightly off topic) In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B16F4B85AC@EMBX01-WF.jnpr.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <13205C286662DE4387D9AF3AC30EF456B16F4B85AC@EMBX01-WF.jnpr.net> Message-ID: <1FE0135C-E726-45A2-ADAC-297096B3C867@americafree.tv> On Feb 3, 2011, at 11:04 AM, Ronald Bonica wrote: > Folks, > > Somehow, it is appropriate that this should happen on February 3. On February 3, 1959, Buddy Holly, Richie Valens and JP Richardson (aka The Big Bopper) died in a plane crash. Don McLean immortalized that day as "The Day The Music Died" in his 1971 hit, "American Pie". > Yes, among other things it ties it nicely to this http://www.youtube.com/watch?v=_y36fG2Oba0 Regards Marshall > Ron > > > > From iljitsch at muada.com Thu Feb 3 10:49:44 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 3 Feb 2011 17:49:44 +0100 Subject: quietly.... In-Reply-To: References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <4D48E558.7070805@brightok.net> <2FD9EDE7-E28C-48E7-B6FB-8386773EF98E@delong.com> <9689E83C-048A-4D72-946B-978FB3C315A4@sackheads.org> , <3CD3A697-8D3C-4EDE-8E4E-53C0E103E12C@sackheads.org> <4D4A43B6.5080306@otd.com> <5A51DAF3-6189-4785-9543-CB046B2819B9@muada.com> Message-ID: <1818414F-15A4-4F7B-A2E4-C9519BBAAF2D@muada.com> On 3 feb 2011, at 17:40, Jon Lewis wrote: >> Hm, if you turn off the NAT66 function, wouldn't the traffic pass through unhindered, too? > Outbound traffic would. Inbound, if on the inside, you're using IPv6 space that's not globally routed, won't. Just like what happens now with NAPT with rfc1918 space on the inside when you stop doing translation...private IP traffic leaks out...but nothing comes back because there is no return path. Don't be so sure. Just like I can set my Airport base station up for NAT or bridge mode now, in a NAT66 future there would be a choice between "obtain addresses from ISP and advertise them on the LAN side" and "obtain addresses from ISP, advertise ULAs on the LAN side and translate". So if the setting gets flipped from the latter to the former you're still wide open. From bensons at queuefull.net Thu Feb 3 10:51:31 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Thu, 3 Feb 2011 10:51:31 -0600 Subject: And so it ends... In-Reply-To: <6E186F3F-6267-4D9B-916A-3663F13AA999@corp.arin.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <6E186F3F-6267-4D9B-916A-3663F13AA999@corp.arin.net> Message-ID: <0FDB411B-3687-40F0-B18C-4A2A28ACA51E@queuefull.net> On Feb 3, 2011, at 10:39 AM, John Curran wrote: > On Feb 3, 2011, at 11:22 AM, Benson Schliesser wrote: >> That's what the RIR might say. But without legal authority (e.g. under contract, as a regulator, or through statutory authority) it is difficult or impossible to enforce. > > Transfers are permitted in the ARIN region per the community developed policies. Understood. My point is: legacy holders, unless they've signed the LRSA or equivalent, aren't required to submit to the ARIN process. >> We can talk about how people "should" return addresses, or "should" justify transfers, etc, but we would only be begging. Transfers will take place outside the RIR scope, because RIR transfer/market policy doesn't accommodate reality. > > Such transfers should be reported when noticed, so the resources can be reclaimed and reissued. Is any RIR authorized, in a legal sense, to "reclaim" legacy address blocks that RIR didn't "issue"? Without that legal authority, is any RIR prepared to accommodate the legal damages stemming from "reclamation"? (Does the RIR membership support such action, in the first place?) >> Or, we can fix policy..? > > Absolutely... if the policy doesn't match your needs, please make a policy proposal. That's a good suggestion, which I will follow-up on. I hope the RIR community can change despite its own momentum. Cheers, -Benson From snar at snar.spb.ru Thu Feb 3 10:48:45 2011 From: snar at snar.spb.ru (Alexandre Snarskii) Date: Thu, 3 Feb 2011 19:48:45 +0300 Subject: And so it ends (slightly off topic) In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B16F4B85AC@EMBX01-WF.jnpr.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <13205C286662DE4387D9AF3AC30EF456B16F4B85AC@EMBX01-WF.jnpr.net> Message-ID: <20110203164845.GB83379@snar.spb.ru> On Thu, Feb 03, 2011 at 11:04:29AM -0500, Ronald Bonica wrote: > Folks, > > Somehow, it is appropriate that this should happen on February 3. > On February 3, 1959, Buddy Holly, Richie Valens and JP Richardson > (aka The Big Bopper) died in a plane crash. Don McLean immortalized > that day as "The Day The Music Died" in his 1971 hit, "American Pie". And exactly this song was later rephrased as 'the day the routers died' concerning IPv4 exhaustion at RIPE55 meeting. Another coincidence ? :) -- In theory, there is no difference between theory and practice. But, in practice, there is. From jcurran at arin.net Thu Feb 3 10:54:42 2011 From: jcurran at arin.net (John Curran) Date: Thu, 3 Feb 2011 16:54:42 +0000 Subject: "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> Message-ID: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> On Feb 3, 2011, at 11:32 AM, Jon Lewis wrote: > My point being, the leasing of IP space to non-connectivity customers is already well established, whether it's technically permitted by the [ir]relevant RIRs. I fully expect this to continue and spread. Eventually, holders of large legacy blocks will realize they can make good money acting as an LIR, leasing portions of their unused space to people who need it and can't get it, want it and don't qualify, etc. > > These start-up LIRs won't be bound by RIR policies, both because in some cases they'll be legacy space holders with no RSA with their region's RIR, and because they won't be worried about eligibility for future RIR allocations of v4 space...because there won't be any. For the ARIN region, it would be nice to know how you'd like ARIN perform in the presence of such activity ("leasing" IP addresses by ISP not providing connectivity). It's possible that such is perfectly reasonable and to simply be ignored, it's also possible that such should be considered a fraudulent transfer and the resources reclaimed. At the end of the day, the policy is set by this community, and clarity over ambiguity is very helpful. Policy proposal process: https://www.arin.net/policy/pdp.html Thanks! /John John Curran President and CEO ARIN From jcurran at arin.net Thu Feb 3 10:57:40 2011 From: jcurran at arin.net (John Curran) Date: Thu, 3 Feb 2011 16:57:40 +0000 Subject: And so it ends... In-Reply-To: <0FDB411B-3687-40F0-B18C-4A2A28ACA51E@queuefull.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <6E186F3F-6267-4D9B-916A-3663F13AA999@corp.arin.net> <0FDB411B-3687-40F0-B18C-4A2A28ACA51E@queuefull.net> Message-ID: <8CB83F29-CE39-4775-84E0-8F57A932225D@arin.net> On Feb 3, 2011, at 11:51 AM, Benson Schliesser wrote: >> Such transfers should be reported when noticed, so the resources can be reclaimed and reissued. > > Is any RIR authorized, in a legal sense, to "reclaim" legacy address blocks that RIR didn't "issue"? Without that legal authority, is any RIR prepared to accommodate the legal damages stemming from "reclamation"? (Does the RIR membership support such action, in the first place?) Resources are listed in the ARIN WHOIS database, which is administered per policies established by the community in this region. Short answer: there's no shortage of authority updating that database as long as the community wishes it so. /John John Curran President and CEO ARIN From mhuff at ox.com Thu Feb 3 10:58:27 2011 From: mhuff at ox.com (Matthew Huff) Date: Thu, 3 Feb 2011 11:58:27 -0500 Subject: quietly.... In-Reply-To: References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <4D48E558.7070805@brightok.net> <2FD9EDE7-E28C-48E7-B6FB-8386773EF98E@delong.com> <9689E83C-048A-4D72-946B-978FB3C315A4@sackheads.org> , <3CD3A697-8D3C-4EDE-8E4E-53C0E103E12C@sackheads.org> <4D4A43B6.5080306@otd.com> <5A51DAF3-6189-4785-9543-CB046B2819B9@muada.com> Message-ID: <483E6B0272B0284BA86D7596C40D29F9011F76964E8E@PUR-EXCH07.ox.com> Yes, but unless that ipv6 that isn't globally routed is NAT66 to the outside world, then it wouldn't have external access. > -----Original Message----- > From: Jon Lewis [mailto:jlewis at lewis.org] > Sent: Thursday, February 03, 2011 11:41 AM > To: Iljitsch van Beijnum > Cc: nanog at nanog.org > Subject: Re: quietly.... > > On Thu, 3 Feb 2011, Iljitsch van Beijnum wrote: > > > On 3 feb 2011, at 17:16, Jon Lewis wrote: > > > >> When someone breaks or shuts off that filter, traffic through the NAPT firewall stops working. On > the stateful firewall with public IPs on both sides, everything works...including the traffic you > didn't want. > > > >> People are going to want NAT66...and not providing it may slow down IPv6 adoption. > > > > Hm, if you turn off the NAT66 function, wouldn't the traffic pass through unhindered, too? > > Outbound traffic would. Inbound, if on the inside, you're using IPv6 > space that's not globally routed, won't. Just like what happens now with > NAPT with rfc1918 space on the inside when you stop doing > translation...private IP traffic leaks out...but nothing comes back > because there is no return path. > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From rubensk at gmail.com Thu Feb 3 10:59:42 2011 From: rubensk at gmail.com (Rubens Kuhl) Date: Thu, 3 Feb 2011 14:59:42 -0200 Subject: And so it ends (slightly off topic) In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B16F4B85AC@EMBX01-WF.jnpr.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <13205C286662DE4387D9AF3AC30EF456B16F4B85AC@EMBX01-WF.jnpr.net> Message-ID: On Thu, Feb 3, 2011 at 2:04 PM, Ronald Bonica wrote: > Folks, > > Somehow, it is appropriate that this should happen on February 3. On February 3, 1959, Buddy Holly, Richie Valens and JP Richardson (aka The Big Bopper) died in a plane crash. Don McLean immortalized that day as "The Day The Music Died" in his 1971 hit, "American Pie". And at RIPE55, "The Day The Music Died" morphed into "The Day The Routers Died': http://www.youtube.com/watch?v=_y36fG2Oba0 The music is... guess what, about IP address depletion... Rubens From rcarpen at network1.net Thu Feb 3 11:00:06 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Thu, 3 Feb 2011 12:00:06 -0500 (EST) Subject: Last of ipv4 /8's allocated In-Reply-To: <238182428.1509.1296599596109.JavaMail.root@zimbra.network1.net> Message-ID: <1990435515.2143.1296752406360.JavaMail.root@zimbra.network1.net> ----- Original Message ----- > My guesses as to who gets what: > > 102/8 - APNIC > 103/8 - LACNIC > 104/8 - AfriNIC > 179/8 - RIPE NCC > 185/8 - ARIN > I couldn't have been more wrong :-) I guess alphabetical order won rather than neighboring blocks :-) -Randy From jra at baylink.com Thu Feb 3 11:00:40 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 3 Feb 2011 12:00:40 -0500 (EST) Subject: quietly.... In-Reply-To: <5A51DAF3-6189-4785-9543-CB046B2819B9@muada.com> Message-ID: <26933088.4507.1296752440582.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Iljitsch van Beijnum" > On 3 feb 2011, at 17:16, Jon Lewis wrote: > > > When someone breaks or shuts off that filter, traffic through the > > NAPT firewall stops working. On the stateful firewall with public > > IPs on both sides, everything works...including the traffic you > > didn't want. > > > People are going to want NAT66...and not providing it may slow down > > IPv6 adoption. > > Hm, if you turn off the NAT66 function, wouldn't the traffic pass > through unhindered, too? > > Or do you propose to make IPv6 home gateways the same way IPv4 home > gateways work, where it's usually not even possible to turn it off? I think the implication includes available 1918-like space to use behind the NAT which is similarly publicly non-routable; *this* is the part we care about -- that those addresses are only accessible *to the edge router*. Cheers, -- jra From cb.list6 at gmail.com Thu Feb 3 11:02:09 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Thu, 3 Feb 2011 09:02:09 -0800 Subject: Significant Announcement (re: IPv4) 3 February - Watch it Live! In-Reply-To: <4900C41C-3414-424A-9683-DE3D7F25FC85@americafree.tv> References: <20110203144344.GB890@hiwaay.net> <1404600274.2040.1296744478836.JavaMail.root@zimbra.network1.net> <4900C41C-3414-424A-9683-DE3D7F25FC85@americafree.tv> Message-ID: On Thu, Feb 3, 2011 at 7:57 AM, Marshall Eubanks wrote: > > On Feb 3, 2011, at 10:00 AM, Max Larson Henry wrote: > >> News conference starts now > > > The exhaustion has made CNN > > http://www.cnn.com/2011/TECH/web/02/03/internet.addresses.gone/ > You mean http://ipv6.cnn.com/2011/TECH/web/02/03/internet.addresses.gone/ Right? Yes, it works. Cameron ========== http://groups.google.com/group/tmoipv6beta ========== > Marshall > > >> >> -M >> >> >> On Thu, Feb 3, 2011 at 9:47 AM, Randy Carpenter wrote: >> >>> >>> It didn't work too bad. ?Does anyone know why it was pretty much over at >>> 9:30, when they said it would start? Did they start a half-hour early or >>> something? >>> >>> >>> -Randy >>> >>> -- >>> | Randy Carpenter >>> | Vice President - IT Services >>> | Red Hat Certified Engineer >>> | First Network Group, Inc. >>> | (800)578-6381, Opt. 1 >>> ---- >>> >>> ----- Original Message ----- >>>> Once upon a time, Sameer Khosla said: >>>>> Anyone else getting Error establishing a database connection trying >>>>> to >>>>> bring this up? >>>> >>>> It was posted to /. this morning, so it is probably overloaded (I >>>> didn't >>>> even try). >>>> -- >>>> Chris Adams >>>> Systems and Network Administrator - HiWAAY Internet Services >>>> I don't speak for anybody but myself - that's enough trouble. >>> >>> >>> >> > > > From bensons at queuefull.net Thu Feb 3 11:07:14 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Thu, 3 Feb 2011 11:07:14 -0600 Subject: And so it ends... In-Reply-To: <8CB83F29-CE39-4775-84E0-8F57A932225D@arin.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <6E186F3F-6267-4D9B-916A-3663F13AA999@corp.arin.net> <0FDB411B-3687-40F0-B18C-4A2A28ACA51E@queuefull.net> <8CB83F29-CE39-4775-84E0-8F57A932225D@arin.net> Message-ID: On Feb 3, 2011, at 10:57 AM, John Curran wrote: > On Feb 3, 2011, at 11:51 AM, Benson Schliesser wrote: >>> Such transfers should be reported when noticed, so the resources can be reclaimed and reissued. >> >> Is any RIR authorized, in a legal sense, to "reclaim" legacy address blocks that RIR didn't "issue"? Without that legal authority, is any RIR prepared to accommodate the legal damages stemming from "reclamation"? (Does the RIR membership support such action, in the first place?) > > Resources are listed in the ARIN WHOIS database, which is administered per policies established by the community in this region. > > Short answer: there's no shortage of authority updating that database as long as the community wishes it so. I respect the community-driven process and I respect that ARIN's role is to enforce community-developed policy. From that perspective, thank you for your answer. But that's only valid up to a point. If the community declared overwhelmingly that ARIN should start clubbing random people over the head, I suspect your legal counsel would take issue with that policy and ARIN would refuse to enforce it. Of course this is only theoretical at the moment. The rubber will meet the road soon, now that the exhaustion phase has arrived. Cheers, -Benson From chip.gwyn at gmail.com Thu Feb 3 11:10:55 2011 From: chip.gwyn at gmail.com (chip) Date: Thu, 3 Feb 2011 12:10:55 -0500 Subject: NANOG 51: Tutorial: IPv6 Technology Overview Part II - Missing Slides Message-ID: Anyone have slides for Part 2 of the IPv6 Technology Overview from Cisco? http://nanog.org/meetings/nanog51/abstracts.php?pt=MTcyMiZuYW5vZzUx&nm=nanog51 Part 1 is there but Part 2 seems to be missing. Thanks! --chip -- Just my $.02, your mileage may vary,? batteries not included, etc.... From sthaug at nethelp.no Thu Feb 3 11:11:35 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Thu, 03 Feb 2011 18:11:35 +0100 (CET) Subject: quietly.... In-Reply-To: <5A51DAF3-6189-4785-9543-CB046B2819B9@muada.com> References: <5A51DAF3-6189-4785-9543-CB046B2819B9@muada.com> Message-ID: <20110203.181135.74676955.sthaug@nethelp.no> > I'm perfectly happy with an IPv6 network that only has rational people on it while those who insist on NAT stay behind on IPv4. There's an inherent conflict between your wish here and the desire to bring IPv6 to the masses... Steinar Haug, Nethelp consulting, sthaug at nethelp.no From jbates at brightok.net Thu Feb 3 11:14:41 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 03 Feb 2011 11:14:41 -0600 Subject: Significant Announcement (re: IPv4) 3 February - Watch it Live! In-Reply-To: <97487AA41962C74E83D8ABABD2A90A49076EF850EF@mail.springnet.local> References: <20110203144344.GB890@hiwaay.net> <1404600274.2040.1296744478836.JavaMail.root@zimbra.network1.net> <4900C41C-3414-424A-9683-DE3D7F25FC85@americafree.tv> <1691673F105F974E97B60CC2263A6A2F468B03904C@CRK2MSEXM01.ad.ent.citco.com> <97487AA41962C74E83D8ABABD2A90A49076EF850EF@mail.springnet.local> Message-ID: <4D4AE281.4050108@brightok.net> I want PI for my house IPv6 address. :( Jack On 2/3/2011 10:48 AM, Todd Christell wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 340 undecillion, 282 decillion, 366 nonillion, 920 octillion, 938 septillion, 463 sextillion, 463 quintillion, 374 quadrillion, 607 trillion, 431 billion, 768 million, 211 thousand, 456 > > Todd Christell > Manager Network Architecture and Support > www.springnet.net > 417.831.8688 > > Key fingerprint = 4F26 A0B4 5AAD 7FCA 48DD 7F40 A57E 9235 5202 D508 > > > > > - -----Original Message----- > From: Stack, Stephen (Citco) [mailto:sstack at citco.com] > Sent: Thursday, February 03, 2011 10:15 AM > To: Marshall Eubanks; Max Larson Henry > Cc: nanog at nanog.org > Subject: RE: Significant Announcement (re: IPv4) 3 February - Watch it Live! > > 340 'undecillion', what a great word!!! Number!!! > > Stephen > > - -----Original Message----- > From: Marshall Eubanks [mailto:tme at americafree.tv] > Sent: 03 February 2011 15:57 > To: Max Larson Henry > Cc: nanog at nanog.org > Subject: Re: Significant Announcement (re: IPv4) 3 February - Watch it Live! > > > On Feb 3, 2011, at 10:00 AM, Max Larson Henry wrote: > >> News conference starts now > > > The exhaustion has made CNN > > http://www.cnn.com/2011/TECH/web/02/03/internet.addresses.gone/ > > Marshall > > >> >> -M >> >> >> On Thu, Feb 3, 2011 at 9:47 AM, Randy Carpenterwrote: >> >>> >>> It didn't work too bad. Does anyone know why it was pretty much over at >>> 9:30, when they said it would start? Did they start a half-hour early or >>> something? >>> >>> >>> -Randy >>> >>> -- >>> | Randy Carpenter >>> | Vice President - IT Services >>> | Red Hat Certified Engineer >>> | First Network Group, Inc. >>> | (800)578-6381, Opt. 1 >>> ---- >>> >>> ----- Original Message ----- >>>> Once upon a time, Sameer Khosla said: >>>>> Anyone else getting Error establishing a database connection trying >>>>> to >>>>> bring this up? >>>> >>>> It was posted to /. this morning, so it is probably overloaded (I >>>> didn't >>>> even try). >>>> -- >>>> Chris Adams >>>> Systems and Network Administrator - HiWAAY Internet Services >>>> I don't speak for anybody but myself - that's enough trouble. >>> >>> >>> >> > > > > Disclaimer link. To see it, click the link below, or copy and paste it into your browser's address line. > http://www.citco.com/emaildisclaimer.htm > > > > -----BEGIN PGP SIGNATURE----- > Version: 10.0.3 (Build 1) > Charset: utf-8 > > wj8DBQFNStwFpX6SNVIC1QgRAskEAJ4vda6BY/TL5XGOzPPx5S7tvhBRfQCfV+6R > AEgujaLswtnPm0/pw6J/Plo= > =m4wo > -----END PGP SIGNATURE----- > > From jcurran at arin.net Thu Feb 3 11:21:15 2011 From: jcurran at arin.net (John Curran) Date: Thu, 3 Feb 2011 17:21:15 +0000 Subject: And so it ends... In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <6E186F3F-6267-4D9B-916A-3663F13AA999@corp.arin.net> <0FDB411B-3687-40F0-B18C-4A2A28ACA51E@queuefull.net> <8CB83F29-CE39-4775-84E0-8F57A932225D@arin.net> Message-ID: On Feb 3, 2011, at 12:07 PM, Benson Schliesser wrote: > On Feb 3, 2011, at 10:57 AM, John Curran wrote: > >> On Feb 3, 2011, at 11:51 AM, Benson Schliesser wrote: >>>> Such transfers should be reported when noticed, so the resources can be reclaimed and reissued. >>> >>> Is any RIR authorized, in a legal sense, to "reclaim" legacy address blocks that RIR didn't "issue"? Without that legal authority, is any RIR prepared to accommodate the legal damages stemming from "reclamation"? (Does the RIR membership support such action, in the first place?) >> >> Resources are listed in the ARIN WHOIS database, which is administered per policies established by the community in this region. >> >> Short answer: there's no shortage of authority updating that database as long as the community wishes it so. > > I respect the community-driven process and I respect that ARIN's role is to enforce community-developed policy. From that perspective, thank you for your answer. > > But that's only valid up to a point. If the community declared overwhelmingly that ARIN should start clubbing random people over the head, I suspect your legal counsel would take issue with that policy and ARIN would refuse to enforce it. Clubbing people over the head would not get adopted by the policy progress, since legal review is part of the process. Reclaiming addresses that are used contrary to policy process is already part of the number resource policy in the ARIN region, has passed legal review, and has already been done on occasion. > Of course this is only theoretical at the moment. Incorrect. It's running code. /John From ernesto at cs.fiu.edu Thu Feb 3 11:26:47 2011 From: ernesto at cs.fiu.edu (Ernie Rubi) Date: Thu, 3 Feb 2011 12:26:47 -0500 Subject: And so it ends... In-Reply-To: <8CB83F29-CE39-4775-84E0-8F57A932225D@arin.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <6E186F3F-6267-4D9B-916A-3663F13AA999@corp.arin.net> <0FDB411B-3687-40F0-B18C-4A2A28ACA51E@queuefull.net> <8CB83F29-CE39-4775-84E0-8F57A932225D@arin.net> Message-ID: <496ACB00-D0C8-4E7A-8ED3-176DC3BF819E@cs.fiu.edu> OK so the argument is the 'community' is ARIN's source of legal power or is the corporate laws of the State of Virginia? On Feb 3, 2011, at 11:57 AM, John Curran wrote: > On Feb 3, 2011, at 11:51 AM, Benson Schliesser wrote: >>> Such transfers should be reported when noticed, so the resources can be reclaimed and reissued. >> >> Is any RIR authorized, in a legal sense, to "reclaim" legacy address blocks that RIR didn't "issue"? Without that legal authority, is any RIR prepared to accommodate the legal damages stemming from "reclamation"? (Does the RIR membership support such action, in the first place?) > > Resources are listed in the ARIN WHOIS database, which is administered per policies established by the community in this region. > > Short answer: there's no shortage of authority updating that database as long as the community wishes it so. > > /John > > John Curran > President and CEO > ARIN > > From bicknell at ufp.org Thu Feb 3 11:29:43 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 3 Feb 2011 09:29:43 -0800 Subject: And so it ends (slightly off topic) In-Reply-To: <20110203164845.GB83379@snar.spb.ru> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <13205C286662DE4387D9AF3AC30EF456B16F4B85AC@EMBX01-WF.jnpr.net> <20110203164845.GB83379@snar.spb.ru> Message-ID: <20110203172943.GA70391@ussenterprise.ufp.org> In a message written on Thu, Feb 03, 2011 at 07:48:45PM +0300, Alexandre Snarskii wrote: > On Thu, Feb 03, 2011 at 11:04:29AM -0500, Ronald Bonica wrote: > > Somehow, it is appropriate that this should happen on February 3. > > On February 3, 1959, Buddy Holly, Richie Valens and JP Richardson > > (aka The Big Bopper) died in a plane crash. Don McLean immortalized > > that day as "The Day The Music Died" in his 1971 hit, "American Pie". > > And exactly this song was later rephrased as 'the day the routers died' > concerning IPv4 exhaustion at RIPE55 meeting. Another coincidence ? :) Let me see if I can speed this thread to it's eventual conclusion. :) Hitler clearly went into hiding and became Buddy Holly, who died in the plane crash. His unground supporters masterminded 9/11 in his memory as a means to use up all the IPv4 addresses sparking a revolution of socialism during the transition to IPv6 lead by Barack Obama. But what most people don't know is that Hitler was just a messager from Xenu, who are fighting a proxy battle with the Raelians on earth for control of the universe. The Japanese have taken up the fight, as the Raelians are here as whales. It is the whales, er Raelians who are pushing for IPv6, so they can address the entire universe when their scheme for world domination finally succeeds. This is why Japan spent so much energy with IPv6 early on, so they could develop a stuxnet like virus that would infect all of the Raelian IPv6 devices and destroy them. It's all really quite obvious, I don't understand why so many people don't see the connections. They are all here in plain sight. I really should stop watching cable news. :) [For the humor impared, some or all of this message may be totally made up.] -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From khelms at ispalliance.net Thu Feb 3 11:32:36 2011 From: khelms at ispalliance.net (Scott Helms) Date: Thu, 03 Feb 2011 12:32:36 -0500 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> Message-ID: <4D4AE6B4.90403@ispalliance.net> John, I would hope that if some ARIN policy is enacted there would be some way to differentiate between organizations, like the one I belong to, that have provided this kind of service to customers for a number of years and organizations looking to take advantage of the new scarcity. We have and do provide IP space for other ISPs (mainly small and mid size) despite not providing connectivity for a number of reasons. We began providing this as a way of getting connectivity provider independent space to ISPs that lacked their own ASN and usually were not multi-homed because I had so many ISPs changing their upstream provider that it was causing us issues in both our engineering and call center teams. We provide network engineering (think re-IPing lots of ISP networks) and end user technical support (think lots of calls from upset customer who had to change their static IP) for many ISPs around the country. We certainly don't have a huge allocation, we have 209 /24s reassigned and 9 reallocated currently. We also pass along all of the usage and reporting requirements that ARIN requires of us. We also don't make money on the practice we charge a small amount on an annual basis for record keeping. As I said, we started this mainly to prevent network disruption and extra work _not_ as a profit center. How a line might be drawn I don't know, but its important to understand that there are very legitimate reasons to reassign or reallocate space even if you are not providing connectivity for a given network. On 2/3/2011 11:54 AM, John Curran wrote: > On Feb 3, 2011, at 11:32 AM, Jon Lewis wrote: > >> My point being, the leasing of IP space to non-connectivity customers is already well established, whether it's technically permitted by the [ir]relevant RIRs. I fully expect this to continue and spread. Eventually, holders of large legacy blocks will realize they can make good money acting as an LIR, leasing portions of their unused space to people who need it and can't get it, want it and don't qualify, etc. >> >> These start-up LIRs won't be bound by RIR policies, both because in some cases they'll be legacy space holders with no RSA with their region's RIR, and because they won't be worried about eligibility for future RIR allocations of v4 space...because there won't be any. > For the ARIN region, it would be nice to know how you'd like ARIN perform > in the presence of such activity ("leasing" IP addresses by ISP not providing > connectivity). It's possible that such is perfectly reasonable and to simply > be ignored, it's also possible that such should be considered a fraudulent > transfer and the resources reclaimed. At the end of the day, the policy is > set by this community, and clarity over ambiguity is very helpful. > > Policy proposal process: https://www.arin.net/policy/pdp.html > > Thanks! > /John > > John Curran > President and CEO > ARIN > > > -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- Looking for hand-selected news, views and tips for independent broadband providers? Follow us on Twitter! http://twitter.com/ZCorum -------------------------------- From jlewis at lewis.org Thu Feb 3 11:36:05 2011 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 3 Feb 2011 12:36:05 -0500 (EST) Subject: "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> Message-ID: On Thu, 3 Feb 2011, John Curran wrote: > On Feb 3, 2011, at 11:32 AM, Jon Lewis wrote: > >> My point being, the leasing of IP space to non-connectivity customers is already well established, whether it's technically permitted by the [ir]relevant RIRs. I fully expect this to continue and spread. Eventually, holders of large legacy blocks will realize they can make good money acting as an LIR, leasing portions of their unused space to people who need it and can't get it, want it and don't qualify, etc. >> >> These start-up LIRs won't be bound by RIR policies, both because in some cases they'll be legacy space holders with no RSA with their region's RIR, and because they won't be worried about eligibility for future RIR allocations of v4 space...because there won't be any. > > For the ARIN region, it would be nice to know how you'd like ARIN perform > in the presence of such activity ("leasing" IP addresses by ISP not providing > connectivity). It's possible that such is perfectly reasonable and to simply > be ignored, it's also possible that such should be considered a fraudulent > transfer and the resources reclaimed. At the end of the day, the policy is > set by this community, and clarity over ambiguity is very helpful. I'm not saying that ARIN should. Even if I thought ARIN should, I suspect the policy process (to develop policies governing org to org IP space leases) would be a waste of everyone's time, because I seriously doubt any policy attempting to forbid or control such activity would be possible to enforce. I merely meant to point out that it's already happening, and IMO, will continue and spread. Additionally, I suspect any attempt by the RIRs to become the sole brokers or clearing houses for org to org IP space transactions within their regions will be futile. There may be some utility to the RIRs providing such a function, but I don't believe the RIRs will be able to control the markets and prevent ad-hoc LIRs from popping up and operating however they see fit. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From drais at icantclick.org Thu Feb 3 11:36:51 2011 From: drais at icantclick.org (david raistrick) Date: Thu, 3 Feb 2011 12:36:51 -0500 (EST) Subject: quietly.... In-Reply-To: References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <4D48E558.7070805@brightok.net> <2FD9EDE7-E28C-48E7-B6FB-8386773EF98E@delong.com> <9689E83C-048A-4D72-946B-978FB3C315A4@sackheads.org> , <3CD3A697-8D3C-4EDE-8E4E-53C0E103E12C@sackheads.org> <4D4A43B6.5080306@otd.com> Message-ID: On Thu, 3 Feb 2011, Brian Johnson wrote: >> 1) To allow yourself to change or maintain multiple upstreams without >> renumbering. > > Not sure what you mean here. So having PI space can't accomplish this? Using PI space means paying significantly more money per year than using PA space, particularly if you factor in the "recommended" subnet sizing and that your v6 address space requirements signficantly increase over v4+NAT. Remember that we're not talking about ISPs and large enterprises who are used to shelling out artifically inflated $$ per year to use PI space. We're talking about telling folks who were happy using PA space (or who have PI space from before IANA) that they now have to rent addresses if they want to avoid internal renumbering. >> 6) Because you have allocated a single address to a machine that later >> on actually represents n differerent actual network entities, and >> retrofitting them with their own unique IPv6 subnet presents a problem. > > Huh? I understood that. I have a customer in my datacenter with 50 servers behind a firewall. (that "customer" could be an internal team at my enterprise, or a customer at a colo, or even a customer at the end of a telco circuit). I need to renumber. The coordination effort involved in renumbering @ the firewall, vs renumbering the -entirety- of the customer's internal subnets is significant. One customer side example? Oracle RAC. With v4 and NAT, RAC would never have to know anything. With no NAT, I have to shut down RAC, shut down OCFS2, reconfigure the cluster filesystem (which is a nontrival task with nontrival risk), reconfigure RAC (which goes OK, other than that I have to reconfigure potentially a half dozen config files on every server that connects to it), restart ocfs, restart RAC.... That's all new work, because I told my customer they cannot use NAT. And I have to do that with -every- customer. With v4, I just helped the customer configure his firewall to support both the old and new addresses, changed external facing DNS, waited for all traffic to move over, removed the old addresses, and we were done. -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From jeffrey.lyon at blacklotus.net Thu Feb 3 11:41:55 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 3 Feb 2011 12:41:55 -0500 Subject: And so it ends... In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <6E186F3F-6267-4D9B-916A-3663F13AA999@corp.arin.net> <0FDB411B-3687-40F0-B18C-4A2A28ACA51E@queuefull.net> <8CB83F29-CE39-4775-84E0-8F57A932225D@arin.net> Message-ID: On Thu, Feb 3, 2011 at 12:07 PM, Benson Schliesser wrote: > > On Feb 3, 2011, at 10:57 AM, John Curran wrote: > >> On Feb 3, 2011, at 11:51 AM, Benson Schliesser wrote: >>>> Such transfers should be reported when noticed, so the resources can be reclaimed and reissued. >>> >>> Is any RIR authorized, in a legal sense, to "reclaim" legacy address blocks that RIR didn't "issue"? ?Without that legal authority, is any RIR prepared to accommodate the legal damages stemming from "reclamation"? (Does the RIR membership support such action, in the first place?) >> >> Resources are listed in the ARIN WHOIS database, which is administered per policies established by the community in this region. >> >> Short answer: there's no shortage of authority updating that database as long as the community wishes it so. > > I respect the community-driven process and I respect that ARIN's role is to enforce community-developed policy. ?From that perspective, thank you for your answer. > > But that's only valid up to a point. ?If the community declared overwhelmingly that ARIN should start clubbing random people over the head, I suspect your legal counsel would take issue with that policy and ARIN would refuse to enforce it. > > Of course this is only theoretical at the moment. ?The rubber will meet the road soon, now that the exhaustion phase has arrived. > > Cheers, > -Benson > > > > I'm not inclined to believe that ARIN members will collectively agree on anything significant, so the policy process is a lot like U.S. government (not a lot getting done). -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From jcdill.lists at gmail.com Thu Feb 3 11:54:58 2011 From: jcdill.lists at gmail.com (JC Dill) Date: Thu, 03 Feb 2011 09:54:58 -0800 Subject: Significant Announcement (re: IPv4) 3 February - Watch it Live! In-Reply-To: <1691673F105F974E97B60CC2263A6A2F468B03904C@CRK2MSEXM01.ad.ent.citco.com> References: <20110203144344.GB890@hiwaay.net> <1404600274.2040.1296744478836.JavaMail.root@zimbra.network1.net> <4900C41C-3414-424A-9683-DE3D7F25FC85@americafree.tv> <1691673F105F974E97B60CC2263A6A2F468B03904C@CRK2MSEXM01.ad.ent.citco.com> Message-ID: <4D4AEBF2.5060808@gmail.com> On 03/02/11 8:15 AM, Stack, Stephen (Citco) wrote: > 340 'undecillion', what a great word!!! Number!!! > If you need more: http://www.isthe.com/chongo/tech/math/number/howhigh.html jc From jcurran at arin.net Thu Feb 3 11:58:34 2011 From: jcurran at arin.net (John Curran) Date: Thu, 3 Feb 2011 17:58:34 +0000 Subject: And so it ends... In-Reply-To: <496ACB00-D0C8-4E7A-8ED3-176DC3BF819E@cs.fiu.edu> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <6E186F3F-6267-4D9B-916A-3663F13AA999@corp.arin.net> <0FDB411B-3687-40F0-B18C-4A2A28ACA51E@queuefull.net> <8CB83F29-CE39-4775-84E0-8F57A932225D@arin.net> <496ACB00-D0C8-4E7A-8ED3-176DC3BF819E@cs.fiu.edu> Message-ID: <45444CE9-AB4B-4308-B1EC-D80D4DB7EAC1@arin.net> On Feb 3, 2011, at 12:26 PM, Ernie Rubi wrote: > OK so the argument is the 'community' is ARIN's source of legal power or is the corporate laws of the State of Virginia? Mr. Rubi - ARIN operates the ARIN WHOIS database as part of the mission of organization in serving the community, and we're incorporated in the State of Virginia as nonstock corporation pursuant to the Virginia Nonstock Corporation Act. Our corporate documents are available here: Please do not hesitate to contact me if you have further questions. /John John Curran President and CEO ARIN From source_route at yahoo.com Thu Feb 3 12:04:10 2011 From: source_route at yahoo.com (Philip Lavine) Date: Thu, 3 Feb 2011 10:04:10 -0800 (PST) Subject: External sanity checks Message-ID: <844412.30168.qm@web30804.mail.mud.yahoo.com> To all, Does any one know a Vendor (NOT Keynote) that can do sanity checks against your web/smtp/ftp farms with pings, traceroutes, latency checks as well as application checks (GET, POST, ESMTP, etc) Thank you, Philip From matthew at matthew.at Thu Feb 3 12:05:29 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 03 Feb 2011 10:05:29 -0800 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <4D4AE6B4.90403@ispalliance.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <4D4AE6B4.90403@ispalliance.net> Message-ID: <4D4AEE69.5070002@matthew.at> On 2/3/2011 9:32 AM, Scott Helms wrote: > John, > > I would hope that if some ARIN policy is enacted there would be > some way to differentiate between organizations, like the one I belong > to, that have provided this kind of service to customers for a number > of years and organizations looking to take advantage of the new > scarcity. We have and do provide IP space for other ISPs (mainly > small and mid size) despite not providing connectivity for a number of > reasons. We began providing this as a way of getting connectivity > provider independent space to ISPs that lacked their own ASN and > usually were not multi-homed because I had so many ISPs changing their > upstream provider that it was causing us issues in both our > engineering and call center teams. We provide network engineering > (think re-IPing lots of ISP networks) and end user technical support > (think lots of calls from upset customer who had to change their > static IP) for many ISPs around the country. We certainly don't have > a huge allocation, we have 209 /24s reassigned and 9 reallocated > currently. We also pass along all of the usage and reporting > requirements that ARIN requires of us. We also don't make money on > the practice we charge a small amount on an annual basis for record > keeping. As I said, we started this mainly to prevent network > disruption and extra work _not_ as a profit center. > > How a line might be drawn I don't know, but its important to > understand that there are very legitimate reasons to reassign or > reallocate space even if you are not providing connectivity for a > given network. It isn't at all clear to me how your business model is different from an ISP that chooses to connect their customer base to the Internet by buying multiple transit connections that happen to terminate very close to the customer's CPE. Or an ISP that has its own IP space but is letting their DSL aggregator announce it and provide the downstream DSL circuits to the ISP's customers. Seems perfectly legitimate to me. Matthew Kaufman From lowen at pari.edu Thu Feb 3 12:05:32 2011 From: lowen at pari.edu (Lamar Owen) Date: Thu, 3 Feb 2011 13:05:32 -0500 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: References: Message-ID: <201102031305.32966.lowen@pari.edu> On Thursday, February 03, 2011 10:39:28 am TJ wrote: > Correct me if I am wrong, but won't Classified networks will get their > addresses IAW the DoD IPv6 Addressing Plan (using globals)? 'Classified' networks are not all governmental. HIPPA requirements can be met with SCIFs, and those need 'classified' networks. Here, we have some control networks that one could consider 'classified' in the access control sense of the word, that is, even if a host is allowed access it must have a proven need to access, and such access needs supervision by another host. This type of network is used here for our large antenna controls, which need to be network accessible on-campus but such access must have two points of supervision (one of which is an actual person), with accessing hosts not allowed to access other networks while accessing the antenna controller. This has been an interesting network design problem, and turns traditional 'stateful' firewalling on its ear, as the need is to block access when certain connections are open, and permit access otherwise. It's made some easier since wireless access is not an option (interferes with the research done with the antennas), and wireless AP's and cell cards are actively hunted down, as well as passively hindered with shielding in the areas which have network access to the antenna controllers. It's a simple matter of protecting assets that would cost millions to replace if the controllers were given errant commands, or if the access to those controllers were to be hacked. From kevin at steadfast.net Thu Feb 3 12:15:33 2011 From: kevin at steadfast.net (Kevin Stange) Date: Thu, 03 Feb 2011 12:15:33 -0600 Subject: And so it ends... In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <6E186F3F-6267-4D9B-916A-3663F13AA999@corp.arin.net> <0FDB411B-3687-40F0-B18C-4A2A28ACA51E@queuefull.net> <8CB83F29-CE39-4775-84E0-8F57A932225D@arin.net> Message-ID: <4D4AF0C5.1020000@steadfast.net> On 02/03/2011 11:41 AM, Jeffrey Lyon wrote: > I'm not inclined to believe that ARIN members will collectively agree > on anything significant, so the policy process is a lot like U.S. > government (not a lot getting done). ARIN members don't make binding votes on individual policy actions, they elect the Advisory Council and Board of ARIN. ARIN solicits policy proposals and takes feedback and general counts of yea and nay votes for those proposals before deciding whether to adopt them. All of this is documented: https://www.arin.net/participate/how_to_participate.html It's true a lot of policy proposal never get out of the discussion phase, but they're posted to the PPML and anyone can discuss their reasons for support or opposition, propose improvements and work to get the policy into a state where the AC will bring it under review. This process is far more open than that of the US Government. -- Kevin Stange Chief Technology Officer Steadfast Networks http://steadfast.net Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From Valdis.Kletnieks at vt.edu Thu Feb 3 12:17:19 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 03 Feb 2011 13:17:19 -0500 Subject: quietly.... In-Reply-To: Your message of "Thu, 03 Feb 2011 09:18:25 +1100." <20110202221825.9EF3A970315@drugs.dv.isc.org> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <5CB621E0-1873-47DC-B4EE-A5E2D6E5D5B4@sackheads.org> <25915.1296675743@localhost> <20110202221825.9EF3A970315@drugs.dv.isc.org> Message-ID: <32825.1296757039@localhost> On Thu, 03 Feb 2011 09:18:25 +1100, Mark Andrews said: > Or you just filter them out in the laptop. With the proper tools you just > ignore and RA's containing 2002:. Done that for years now. You're welcome to stop by and fix 30,000+ systems here, most of which we do *not* have administrative control over because they're personal laptops and the like. For most of these users, if it doesn't do the filtering correctly out of the box when they pick it at Best Buy or Walmart or whatever, it isn't going to get reconfigured. (We do provide a free "configure your box for our network" CD that does all this stuff and installs a site-licensed AV and all that, but not everybody actually uses it, and there's no really good way to mandate it - and anyhow, that's a purely local fix for a problem that's more than local). (We'll overlook the fun and games that start when you have a laptop that travels between a site where 2002:: is verboten, and another where 2002:: is the way it has to be done... Doesn't happen much.. *yet*. Good luck explaining *that* to Joe Sixpack) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From owen at delong.com Thu Feb 3 12:17:14 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 3 Feb 2011 10:17:14 -0800 Subject: quietly.... In-Reply-To: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> Message-ID: On Feb 3, 2011, at 8:29 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Jon Lewis" > >> There's an awful lot of inertia in the "NAPT/firewall keeps our hosts >> safe from the internet" mentality. Sure, a stateful firewall can be >> configured allow all outbound traffic and only connected/related >> inbound. > >> When someone breaks or shuts off that filter, traffic through the NAPT >> firewall stops working. On the stateful firewall with public IPs on >> both sides, everything works...including the traffic you didn't want. > > Precisely. > > This is the crux of the argument I've been trying, rather ineptly, > to make: when it breaks, *which way does it fail*. NAT fails safe, > generally. > So does any decent stateful inspection firewall. That's why your argument doesn't hold water. The only thing NAT brings to the equation over a properly constructed stateful firewall is the mutilation of the IP header. >> People are going to want NAT66...and not providing it may slow down >> IPv6 adoption. > > You're using the future tense there, Jon; are you sure you didn't mean > to use the present? Or the past...? > If the lack of NAT66 slows down IPv6 adoption, even though I am a big IPv6 cheerleader, I am willing to accept that particular tradeoff. Overloaded NAT is too costly to the community to be allowed to promulgate into IPv6. It is detrimental to: Application development Innovation Security Auditing Cost: Cost of application development Cost of devices Cost of administration Cost of operations People that hold steadfast to the idea of not implementing IPv6 without NAT will eventually become IPv4 islands. The rest of the internet will continue to innovate without them and they will eventually come along or they will be left behind. Owen From brandon.galbraith at gmail.com Thu Feb 3 12:24:01 2011 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Thu, 3 Feb 2011 12:24:01 -0600 Subject: External sanity checks In-Reply-To: <844412.30168.qm@web30804.mail.mud.yahoo.com> References: <844412.30168.qm@web30804.mail.mud.yahoo.com> Message-ID: Pingdom will do most of what you're looking for (www.pingdom.com). We're quite fond of them after a bad Keynote experience. -brandon On Thu, Feb 3, 2011 at 12:04 PM, Philip Lavine wrote: > To all, > > Does any one know a Vendor (NOT Keynote) that can do sanity checks against > your web/smtp/ftp farms with pings, traceroutes, latency checks as well as > application checks (GET, POST, ESMTP, etc) > > Thank you, > > Philip > > > > > > -- Brandon Galbraith US Voice: 630.492.0464 From williamsjj at digitar.com Thu Feb 3 12:24:12 2011 From: williamsjj at digitar.com (Jason J. W. Williams) Date: Thu, 3 Feb 2011 13:24:12 -0500 Subject: External sanity checks In-Reply-To: <844412.30168.qm@web30804.mail.mud.yahoo.com> Message-ID: We've been pretty happy with Pingdom. They do latency with all the healthchecks...give pretty nice history graphs of latency and uptime. They'll do automatic traceroutes when a check hard fails (I.e. 3 fails from 3 different geographic locations). -J -------- Jason J. W. Williams, COO/CTO DigiTar williamsjj at digitar.com V: 208.343.8520 F: 208.322.8522 M: 208.863.0727 www.digitar.com On 2/3/11 11:04 AM, "Philip Lavine" wrote: > >To all, > >Does any one know a Vendor (NOT Keynote) that can do sanity checks >against your web/smtp/ftp farms with pings, traceroutes, latency checks >as well as application checks (GET, POST, ESMTP, etc) > >Thank you, > >Philip > > > > > >!SIG:4d4af065241134394420122! > From rsm at fast-serv.com Thu Feb 3 12:26:03 2011 From: rsm at fast-serv.com (Randy McAnally) Date: Thu, 3 Feb 2011 13:26:03 -0500 Subject: External sanity checks In-Reply-To: <844412.30168.qm@web30804.mail.mud.yahoo.com> References: <844412.30168.qm@web30804.mail.mud.yahoo.com> Message-ID: <20110203182523.M12269@fast-serv.com> On Thu, 3 Feb 2011 10:04:10 -0800 (PST), Philip Lavine wrote > To all, > > Does any one know a Vendor (NOT Keynote) that can do sanity checks > against your web/smtp/ftp farms with pings, traceroutes, latency > checks as well as application checks (GET, POST, ESMTP, etc) I've had good results with hyperspin.com...never any false alarms for that matter. ~Randy From gdendy at equinix.com Thu Feb 3 12:34:46 2011 From: gdendy at equinix.com (Greg Dendy) Date: Thu, 3 Feb 2011 10:34:46 -0800 Subject: External sanity checks In-Reply-To: References: <844412.30168.qm@web30804.mail.mud.yahoo.com> Message-ID: <19C36902-4D62-4F3E-A4C3-6EDF72D8E62C@equinix.com> Gomez isn't too bad either for the http side. http://www.gomez.com/ Greg On Feb 3, 2011, at 10:29 AM, "Brandon Galbraith" wrote: > Pingdom will do most of what you're looking for (www.pingdom.com). We're > quite fond of them after a bad Keynote experience. > > -brandon > > On Thu, Feb 3, 2011 at 12:04 PM, Philip Lavine wrote: > >> To all, >> >> Does any one know a Vendor (NOT Keynote) that can do sanity checks against >> your web/smtp/ftp farms with pings, traceroutes, latency checks as well as >> application checks (GET, POST, ESMTP, etc) >> >> Thank you, >> >> Philip >> >> >> >> >> >> > > > -- > Brandon Galbraith > US Voice: 630.492.0464 From owen at delong.com Thu Feb 3 12:29:56 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 3 Feb 2011 10:29:56 -0800 Subject: quietly.... In-Reply-To: <1344594475.2126.1296751198990.JavaMail.root@zimbra.network1.net> References: <1344594475.2126.1296751198990.JavaMail.root@zimbra.network1.net> Message-ID: <41721521-005D-4586-BC5F-9FB11CA88228@delong.com> On Feb 3, 2011, at 8:39 AM, Randy Carpenter wrote: >>> The concept of v4 to v6 addressing scale doesn't match the pricing >>> scale, though. Generally, I expect to see most ISPs find themselves >>> 1 rank higher in the v6 model compared to v4, which effectively >>> doubles your price anyways. :) >>> >>> >>> Jack >> >> Actually, so far, most ISPs are finding themselves one rank lower. >> >> The exception is particularly small providers and there is a >> combination of suggestion (about fees) and policy (Proposal 121) >> effort underway to rectify that problem. >> >> Owen > > A specific example of the sizes of ISP I am working with: > > Most of them have between a /17 and a /20 of address space. > > If (hopefully when) Proposal 121 is adopted, all of the ones that are around a /17, should be getting a /28. Some of the ones that are /19 currently, would be getting a /28. While I wholeheartedly agree with Proposal 121, that represents 2 jumps in cost. These might represent some unusual situations, and might even fall under your definition of "particularly small." I hope that if Proposal 121 does pass, that the fees are restructured so that /36, /32, /28, /24, and /20 have different fees that line up with X-small, Small, Medium, Large, and X-large, respectively. > > -Randy Randy, Without proposal 121, they would fall into the /32 category and would be in the same pricing category as they are today. I realize that if they get their maximum allowed allocation under proposal 121, they would be facing significant cost increases and I do sincerely hope that the board will address this issue promptly in the process of implementing 121 when it passes. However, my comment was targeted at the current situation pre-121. In the current situation, the only providers that pay more are those with less than a /20 who cannot get less than a /32 in IPv6. They are forced from the $1250 tier to the $2,250 pricing tier. Everyone else pays either the same or less under current policy. Owen From jbates at brightok.net Thu Feb 3 12:35:46 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 03 Feb 2011 12:35:46 -0600 Subject: quietly.... In-Reply-To: References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> Message-ID: <4D4AF582.6080902@brightok.net> On 2/3/2011 12:17 PM, Owen DeLong wrote: > Cost of application development Applications do not have to be written to support NAT (NAT66 shouldn't find itself in the areas where it's traditionally been a problem). The burden should be upon the NAT device to fix any issues, and this will be paid for by the few that utilize NAT. > Cost of devices Cost of border firewalls you mean; also not an issue. > Cost of administration If I choose to use NAPTv6, it's right to accept this cost. It doesn't make someone else pay more for me to administer my firewall. > Cost of operations If I choose to use NAPTv6, it's right to accept this cost. It doesn't make someone else pay more for me to administer my firewall. I understand and agree that CPEs should not use NAT66. It should even be a MUST NOT in the cpe router draft. However, there is no cost benefit of denying it to corporate border firewalls, and it most likely will be implemented anyways, so it should be properly documented. Jack From ernesto at cs.fiu.edu Thu Feb 3 12:41:02 2011 From: ernesto at cs.fiu.edu (Ernie Rubi) Date: Thu, 3 Feb 2011 13:41:02 -0500 Subject: And so it ends... In-Reply-To: <45444CE9-AB4B-4308-B1EC-D80D4DB7EAC1@arin.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <6E186F3F-6267-4D9B-916A-3663F13AA999@corp.arin.net> <0FDB411B-3687-40F0-B18C-4A2A28ACA51E@queuefull.net> <8CB83F29-CE39-4775-84E0-8F57A932225D@arin.net> <496ACB00-D0C8-4E7A-8ED3-176DC3BF819E@cs.fiu.edu> <45444CE9-AB4B-4308-B1EC-D80D4DB7EAC1@arin.net> Message-ID: <12F71EB1-E945-4189-BD5F-19715F7DE680@cs.fiu.edu> I think it's OK to say you cannot/would rather not answer the question, instead of giving a non-answer. I was trying to follow along with your 'the community acquiescence gives us the legal right to take back legacy IP addresses' argument. Cheers, Ernie On Feb 3, 2011, at 12:58 PM, John Curran wrote: > On Feb 3, 2011, at 12:26 PM, Ernie Rubi wrote: > >> OK so the argument is the 'community' is ARIN's source of legal authority or is it the corporate laws of the State of Virginia? > > Mr. Rubi - > > ARIN operates the ARIN WHOIS database as part of the mission of > organization in serving the community, and we're incorporated in > the State of Virginia as nonstock corporation pursuant to the > Virginia Nonstock Corporation Act. Our corporate documents are > available here: > > > Please do not hesitate to contact me if you have further questions. > /John > > John Curran > President and CEO > ARIN From mhuff at ox.com Thu Feb 3 12:41:26 2011 From: mhuff at ox.com (Matthew Huff) Date: Thu, 3 Feb 2011 13:41:26 -0500 Subject: quietly.... In-Reply-To: References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> Message-ID: <483E6B0272B0284BA86D7596C40D29F9011F76964E94@PUR-EXCH07.ox.com> > Overloaded NAT is too costly to the community to be allowed to promulgate > into IPv6. It is detrimental to: > Application development > Innovation > Security > Auditing > Cost: > Cost of application development > Cost of devices > Cost of administration > Cost of operations > > People that hold steadfast to the idea of not implementing IPv6 without > NAT will eventually become IPv4 islands. The rest of the internet will > continue to innovate without them and they will eventually come along > or they will be left behind. > > Owen > Owen, can you point to a application protocol that is broken via NAT that isn't a p2p protocol or VoIP? Corporations are interested in neither (except SIP trunking, which works fine with NAT). Corporate networks have zero interest in p2p protocols or allowing desktops to be "full members" of the ip world. Like I posted earlier, there are signficant reasons to use NAT44 and NAT66 that have nothing to do with perceived security, but rather with virtualization of ip endpoints/ip routing used by companies such as TNS and BTRadianz for extranet connectivity. From our standpoint NAT44 is a signifcant cost reduction because it allows us to make changes to internal environments without having to coordinate with all of our extranet partners. The difference is significant. In a very simple example, changing one of our FIX servers with the extranet clients being twice-natted, requires one change on one firewall. If I had to contact all the clients (and no, they can't use dynamic routing and/or DNS), then it would require hours of paperwork and time coordinating it. It's not even close. From owen at delong.com Thu Feb 3 12:45:53 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 3 Feb 2011 10:45:53 -0800 Subject: quietly.... In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9011F76964E89@PUR-EXCH07.ox.com> References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> <483E6B0272B0284BA86D7596C40D29F9011F76964E89@PUR-EXCH07.ox.com> Message-ID: <22DB2CB6-F5BE-41CA-A719-86C42A303D24@delong.com> On Feb 3, 2011, at 8:46 AM, Matthew Huff wrote: > There is also another reason for NAT44 or NAT66 in the corporate world that has been missed in these conversations. It is very common to NAT44 when connected via extranets to another company via an b2b provider such as TNS or BTRadianz. Not everything goes over the net. NAT44 (especially "twice-nat") is used for a number of reasons including limiting of exchange of routing information, routing of different services in different directions via NAT, or to prevent having to contact the other side when a server changes. For example if we are natting one of our FIX servers then the internal machine can change as long as the NAT is updated. This is far simpler than having to get the changes externally especially at some big bank. Also some companies bring internet routes into their core (I still don't know why). In order to route web/email to them via the internet and protocols such as FIX via an extranet, twice-nat is required. > > Within similar function in Ipv6, there are a lot of companies, especially in the financial realm, that won't migrate off of ipv4. > In IPv6, the simpler solution is to allocate a /64 to groups of machines that serve such a function. If you need to move the group, you can simply move the entire prefix. > NAT is used for a reason, not just because "we don't know better". Yes, we know it breaks certain apps, especially p2p ones. In a corporate view, that is a feature, not a bug. We neither want, nor will allow individual desktops to become peers. Only a limited number of dedicated servers have external visibility, and that's the way it's going to stay regardless of ipv6 ideology. > Actually, there are better alternatives to NAT in IPv6 for just about every reason, so, yeah, the desire for NAT in IPv6 really does boil down to "we don't know better yet". You can break p2p just as quickly without NAT using policy. NAT doesn't provide policy, it just limits your ability to choose your own policy. Owen > > > > > >> -----Original Message----- >> From: Jay Ashworth [mailto:jra at baylink.com] >> Sent: Thursday, February 03, 2011 11:29 AM >> To: NANOG >> Subject: Re: quietly.... >> >> ----- Original Message ----- >>> From: "Jon Lewis" >> >>> There's an awful lot of inertia in the "NAPT/firewall keeps our hosts >>> safe from the internet" mentality. Sure, a stateful firewall can be >>> configured allow all outbound traffic and only connected/related >>> inbound. >> >>> When someone breaks or shuts off that filter, traffic through the NAPT >>> firewall stops working. On the stateful firewall with public IPs on >>> both sides, everything works...including the traffic you didn't want. >> >> Precisely. >> >> This is the crux of the argument I've been trying, rather ineptly, >> to make: when it breaks, *which way does it fail*. NAT fails safe, >> generally. >> >>> People are going to want NAT66...and not providing it may slow down >>> IPv6 adoption. >> >> You're using the future tense there, Jon; are you sure you didn't mean >> to use the present? Or the past...? >> >> Cheers, >> -- jra > From scott.brim at gmail.com Thu Feb 3 12:59:31 2011 From: scott.brim at gmail.com (Scott Brim) Date: Thu, 03 Feb 2011 13:59:31 -0500 Subject: Egypt 'hijacked Vodafone network' In-Reply-To: References: <629152.45886.qm@web59601.mail.ac4.yahoo.com> Message-ID: <4D4AFB13.50803@gmail.com> On 02/03/2011 10:14 EST, Marshall Eubanks wrote: > > On Feb 3, 2011, at 9:24 AM, andrew.wallace wrote: > >> Mobile phone firm Vodafone accuses the Egyptian authorities of >> using its network to send pro-government text messages. >> >> http://www.bbc.co.uk/news/business-12357694 > > Here is their PR > > http://www.vodafone.com/content/index/press.html > > Note that this is entirely legal, under "the emergency powers > provisions of the Telecoms Act" Which is legal, Vodafone's protest or the government's telling them to send messages? afaik the agreement was that the operator would have preloaded canned messages, agreed on in advance with the government, and now the government is telling them to send out arbitrary messages they compose on the spot. From mhuff at ox.com Thu Feb 3 13:00:57 2011 From: mhuff at ox.com (Matthew Huff) Date: Thu, 3 Feb 2011 14:00:57 -0500 Subject: quietly.... In-Reply-To: <22DB2CB6-F5BE-41CA-A719-86C42A303D24@delong.com> References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> <483E6B0272B0284BA86D7596C40D29F9011F76964E89@PUR-EXCH07.ox.com> <22DB2CB6-F5BE-41CA-A719-86C42A303D24@delong.com> Message-ID: <483E6B0272B0284BA86D7596C40D29F9011F76964E95@PUR-EXCH07.ox.com> > In IPv6, the simpler solution is to allocate a /64 to groups of machines that serve such a function. > If you need to move the group, you can simply move the entire prefix. If we change the prefix, then I have to contact and deal with the bureaucracy of external corporate entities. This is a significant cost that is completely prevented by using NAT. Also, given that the prefix is a network address, now we have to contact a separate department with a separate bureaucracy to get routing changes approved. Again, how is this easier without nat? > You can break p2p just as quickly without NAT using policy. NAT doesn't provide policy, it just limits > your ability to choose your own policy. The goal is not to break p2p. The goal is to use NAT for various reasons, and the fact that it breaks p2p is just a benefit. You keep pointing out that NAT should be eliminated so that p2p will work, to me, that is an good argument for the opposite. NAT, at least in a coroprate world, is never going away. There are two many good reasons for it to exist. For a ISP/CPE or University environment, I understand your argument, but not for a corporate network. If there were a good NAT46 implementation on a cisco asa, juniper firewall, checkpoint and others, then most corporate networks could stay in ipv4 RFC1918 private IP addresses, get PA ipv6 global routable address space from their providers, and setup global NAT pools and have access to ipv4 and ipv6 with no internal changes. It may not be ideologically pure, but it would work, as least as well as it does now, and allow the migration to ipv6 to move forward easier. From owen at delong.com Thu Feb 3 12:59:10 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 3 Feb 2011 10:59:10 -0800 Subject: And so it ends... In-Reply-To: <0FDB411B-3687-40F0-B18C-4A2A28ACA51E@queuefull.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <6E186F3F-6267-4D9B-916A-3663F13AA999@corp.arin.net> <0FDB411B-3687-40F0-B18C-4A2A28ACA51E@queuefull.net> Message-ID: <765C578E-3EB4-4C73-ADD8-D3A175FE5371@delong.com> On Feb 3, 2011, at 8:51 AM, Benson Schliesser wrote: > > On Feb 3, 2011, at 10:39 AM, John Curran wrote: > >> On Feb 3, 2011, at 11:22 AM, Benson Schliesser wrote: >>> That's what the RIR might say. But without legal authority (e.g. under contract, as a regulator, or through statutory authority) it is difficult or impossible to enforce. >> >> Transfers are permitted in the ARIN region per the community developed policies. > > Understood. My point is: legacy holders, unless they've signed the LRSA or equivalent, aren't required to submit to the ARIN process. > That remains to be seen. If they give up their space, it is unclear that they have any right to transfer it to another organization rather than return it to the successor registry. There is no precedent established showing that this is allowed. > >>> We can talk about how people "should" return addresses, or "should" justify transfers, etc, but we would only be begging. Transfers will take place outside the RIR scope, because RIR transfer/market policy doesn't accommodate reality. >> >> Such transfers should be reported when noticed, so the resources can be reclaimed and reissued. > > Is any RIR authorized, in a legal sense, to "reclaim" legacy address blocks that RIR didn't "issue"? Without that legal authority, is any RIR prepared to accommodate the legal damages stemming from "reclamation"? (Does the RIR membership support such action, in the first place?) > That remains to be seen. IANA has declared them the successor registries for the legacy blocks and there is widespread belief that addresses were issued for use and expected to be returned when that use was no longer valid. The other thing to consider is that the RIR doesn't really need to "reclaim" the block, per se. They can simply stop providing uniqueness to the organizations that don't have a contract with them and issue those numbers to some other organization that has a contract. The other organization would know that their uniqueness is limited to those cooperating in the registry system. Does an organization that has no contract with an RIR have a right to expect that RIR to continue to provide them a unique registration? Owen From lowen at pari.edu Thu Feb 3 13:04:45 2011 From: lowen at pari.edu (Lamar Owen) Date: Thu, 3 Feb 2011 14:04:45 -0500 Subject: quietly.... In-Reply-To: <4D4AF582.6080902@brightok.net> References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> Message-ID: <201102031404.45801.lowen@pari.edu> On Thursday, February 03, 2011 01:35:46 pm Jack Bates wrote: > I understand and agree that CPEs should not use NAT66. It should even be > a MUST NOT in the cpe router draft. Do you really think that this will stop the software developers of some CPE routers' OS code from just making it work? Do you really think the standard saying 'thou shalt not NAT' will produce the desired effect of preventing such devices from actually getting built? From dwhite at olp.net Thu Feb 3 13:16:19 2011 From: dwhite at olp.net (Dan White) Date: Thu, 3 Feb 2011 13:16:19 -0600 Subject: And so it ends... In-Reply-To: References: Message-ID: <20110203191619.GE4550@dan.olp.net> On 03/02/11?10:38?-0500, Jeffrey Lyon wrote: >On Thu, Feb 3, 2011 at 9:58 AM, Alex Rubenstein wrote: >> And we have yet to see what happens with backend transactions between >> private institutions that have large blocks laying around, and them >> realizing that they have a marketable and valuable thing. We may all say >> it won't happen, we may even say we don't want it to happen, or that it >> shouldn't be allowed - but I'm a realist. > >My theory is that IPv4 will continue to survive with companies >becoming more and more conservative on the use of space. IPv6 adoption >will happen more substantially as the cost of second hand IPv4 becomes >more and more severe, approaching the apex of IPv4 cost vs. IPv6 >adoption cost. That makes sense in a 'market' kind of way, however I expect v6 adoption to be much less of a cost curve and more of a flood gate as vendors start rolling out better support, or any support for v6. It's difficult for me to imagine any kind of v4 address market extending the life of the public v4-only internet more than a few months, any more than 2 or 3 legacy /8s getting returned to the global pool would. There's just too much growth and too few networks that would get those addresses to be significant in the larger picture. I do agree that v4 will continue to survive for quite some time though, but not at the expense of v6 adoption. -- Dan White From jcurran at arin.net Thu Feb 3 13:16:36 2011 From: jcurran at arin.net (John Curran) Date: Thu, 3 Feb 2011 19:16:36 +0000 Subject: And so it ends... In-Reply-To: <12F71EB1-E945-4189-BD5F-19715F7DE680@cs.fiu.edu> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <6E186F3F-6267-4D9B-916A-3663F13AA999@corp.arin.net> <0FDB411B-3687-40F0-B18C-4A2A28ACA51E@queuefull.net> <8CB83F29-CE39-4775-84E0-8F57A932225D@arin.net> <496ACB00-D0C8-4E7A-8ED3-176DC3BF819E@cs.fiu.edu> <45444CE9-AB4B-4308-B1EC-D80D4DB7EAC1@arin.net> <12F71EB1-E945-4189-BD5F-19715F7DE680@cs.fiu.edu> Message-ID: <9D4F0A12-2F7A-4352-92CF-3863E7028AFE@arin.net> Mr. Rubi - I'm sorry if my answer is not clear. If your question was: "What is the source of ARIN's legal authority to manage the ARIN WHOIS database?" then answer is that the database is managed as part of ARIN's mission, per policies established by the community. If you're trying to ask a different question, I'm more than happy to answer, but I'd ask that you be more explicit. Thank you, /John John Curran President and CEO ARIN On Feb 3, 2011, at 1:41 PM, Ernie Rubi wrote: > I think it's OK to say you cannot/would rather not answer the question, instead of giving a non-answer. I was trying to follow along with your 'the community acquiescence gives us the legal right to take back legacy IP addresses' argument. > > Cheers, > > Ernie > > On Feb 3, 2011, at 12:58 PM, John Curran wrote: > >> On Feb 3, 2011, at 12:26 PM, Ernie Rubi wrote: >> >>> OK so the argument is the 'community' is ARIN's source of legal authority or is it the corporate laws of the State of Virginia? >> >> Mr. Rubi - >> >> ARIN operates the ARIN WHOIS database as part of the mission of >> organization in serving the community, and we're incorporated in >> the State of Virginia as nonstock corporation pursuant to the >> Virginia Nonstock Corporation Act. Our corporate documents are >> available here: >> >> >> Please do not hesitate to contact me if you have further questions. >> /John >> >> John Curran >> President and CEO >> ARIN > > From jra at baylink.com Thu Feb 3 13:11:42 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 3 Feb 2011 14:11:42 -0500 (EST) Subject: quietly.... In-Reply-To: <32825.1296757039@localhost> Message-ID: <16075456.4557.1296760302037.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Valdis Kletnieks" > (We'll overlook the fun and games that start when you have a laptop that > travels between a site where 2002:: is verboten, and another where 2002:: is > the way it has to be done... Doesn't happen much.. *yet*. Good luck explaining > *that* to Joe Sixpack) With all due respect to the people who had to get it done... And so *this* you call "engineering"? Was TCP/IP this bad back in 1983, folks? Cheers, -- jra From jra at baylink.com Thu Feb 3 13:09:52 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 3 Feb 2011 14:09:52 -0500 (EST) Subject: Failure modes: NAT vs SPI In-Reply-To: Message-ID: <13040078.4555.1296760192315.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > On Feb 3, 2011, at 8:29 AM, Jay Ashworth wrote: > > This is the crux of the argument I've been trying, rather ineptly, > > to make: when it breaks, *which way does it fail*. NAT fails safe, > > generally. > > > So does any decent stateful inspection firewall. That's why your > argument doesn't hold water. Perhaps we disagree on the definition of "decent". An SPI Firewall is code, running on a router. It drops packets which should not otherwise be routed by the base routing code running on that router, which knows how to reach the internal network's addresses, and packets are sent to it from the Net-at-large. In the NAT4 case, those internal addresses are unknown to the NAL, and the NAT code, as configured by the person operating the edge router, is the only way for packets to get into the LAN; if the NAT code falls over on the router, then packets cannot get in, since the outside world *cannot get packets to that router with addresses which it will further route inbound*. That's the expansion of "fails safe". Let us now examine the alternate case. In this case, that original SPI case I mentioned above, we're assuming routable addresses behind that firewall -- that is, the NAL *does* know how to aim packets at a *specific host inside my LAN*. Those packets get to my edge router, and the SPI firewall drops the appropriate packets before they're actually handed to the routing core, and sent inwards. If the firewall code fails or is inadvertanly turned off, what happens? Why, the router does what it's designed for, it routes. Those external packets. In, to my hosts. With no firewall in the way. Sorry to have to show my work, but that's my work: please explain how you feel that those two situations do *not* make NAT safer in the edge case where an SPI firewall fails in such a fashion as not to drop the packets asked of it? All that's necessary to cause that failure is to say "turn it off", whereas causing a comparable failure on the NAT side requires *defining specific new rules that target specific internal hosts by IP address*, which is a much more complex task, which effectively cannot be accomplished by accident, unlike accidentally disabling a firewall. Cheers, -- jra From andrew.wallace at rocketmail.com Thu Feb 3 13:20:04 2011 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Thu, 3 Feb 2011 11:20:04 -0800 (PST) Subject: Egypt 'hijacked Vodafone network' Message-ID: <347523.24998.qm@web59612.mail.ac4.yahoo.com> On Thu, Feb 3, 2011 at 6:59 PM, Scott Brim wrote: > On 02/03/2011 10:14 EST, Marshall Eubanks wrote: >> >> On Feb 3, 2011, at 9:24 AM, andrew.wallace wrote: >> >>> Mobile phone firm Vodafone accuses the Egyptian authorities of >>> using its network to send pro-government text messages. >>> >>> http://www.bbc.co.uk/news/business-12357694 >> >> Here is their PR >> >> http://www.vodafone.com/content/index/press.html >> >> Note that this is entirely legal, under "the emergency powers >> provisions of the Telecoms Act" > > Which is legal, Vodafone's protest or the government's telling them to > send messages? afaik the agreement was that the operator would have > preloaded canned messages, agreed on in advance with the government, and > now the government is telling them to send out arbitrary messages they > compose on the spot. > > I wonder if these messages were blockable by the end-user or if they were being sent as a service announcement from Vodafone. Certainly, if the government were sending the messages under the company name then something sounds wrong about that. What I would like is to hear from someone who received the messages and what their experiences were. Andrew From jeff-kell at utc.edu Thu Feb 3 13:25:18 2011 From: jeff-kell at utc.edu (Jeff Kell) Date: Thu, 03 Feb 2011 14:25:18 -0500 Subject: quietly.... In-Reply-To: <16075456.4557.1296760302037.JavaMail.root@benjamin.baylink.com> References: <16075456.4557.1296760302037.JavaMail.root@benjamin.baylink.com> Message-ID: <4D4B011E.90808@utc.edu> On 2/3/2011 2:11 PM, Jay Ashworth wrote: > Was TCP/IP this bad back in 1983, folks? Yeah. Only real hosts on the network, and you had to be a real "root" user to bind a listening port < 1024 :-) Now a 5-year-old with a freakin' phone can do it. Jeff From lists at internetpolicyagency.com Thu Feb 3 13:26:11 2011 From: lists at internetpolicyagency.com (Roland Perry) Date: Thu, 3 Feb 2011 19:26:11 +0000 Subject: quietly.... In-Reply-To: <5A055785-D55E-47A3-87B0-58B0DE81F60E@delong.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <437F22E3-154B-4DD2-B37B-8BC54D116B40@delong.com> <9F2mjoD95cSNFAI6@perry.co.uk> <5A055785-D55E-47A3-87B0-58B0DE81F60E@delong.com> Message-ID: In article <5A055785-D55E-47A3-87B0-58B0DE81F60E at delong.com>, Owen DeLong writes >>> NAT provides a solution to, lets call it, enterprise multihoming. >>> Remote office with a local Internet connection, but failover through >>> the corporate network. >> >> And for home (/homeworker) networks ... eg I have a NAT box with a >>default connection to my ADSL provider and an automatic failover to >>3G (completely separate supplier). >> >> Almost everything inside my network doesn't notice when it switches over. >> >> Now, if only I could get it to automatically revert to ADSL when >>it reappears - I wouldn't have to worry so much about the 3G bill. > >In this case in IPv6, the better choice is to have addresses on each >host from both providers. When a provider goes away, the router should >invalidate the prefix in the RAs. If the hosts have proper address >selection policies, they will actually go back to the ADSL prefix as >soon as it reappears. Which in turn implies that I'd have to start getting involved in DNS for the hosts inside my network. At the moment I can ignore that and just enter their rfc1918 address into various applications. [This is all under Windows, of course, the sort of user I'm playing at being doesn't use anything more sophisticated.] In any event, two of my applications are not IPv6 compatible, and would require significant upgrading. And will my ADSL provider and my 3G provider both switch to IPv6 at about the same time? Unfortunately this all sounds like a lot of work, but am I a rare kind of user? -- Roland Perry From Valdis.Kletnieks at vt.edu Thu Feb 3 13:28:32 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 03 Feb 2011 14:28:32 -0500 Subject: quietly.... In-Reply-To: Your message of "Thu, 03 Feb 2011 13:41:26 EST." <483E6B0272B0284BA86D7596C40D29F9011F76964E94@PUR-EXCH07.ox.com> References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> <483E6B0272B0284BA86D7596C40D29F9011F76964E94@PUR-EXCH07.ox.com> Message-ID: <37955.1296761312@localhost> On Thu, 03 Feb 2011 13:41:26 EST, Matthew Huff said: > Owen, can you point to a application protocol that is broken via NAT that > isn't a p2p protocol or VoIP? The only reason FTP works through a NAT is because the NAT has already been hacked up to further mangle the data stream to make up for the mangling it does. I'm told that IPSEC through a NAT can be interesting too... And that's something I'm also told some corporations are interested in. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jra at baylink.com Thu Feb 3 13:34:03 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 3 Feb 2011 14:34:03 -0500 (EST) Subject: And so it ends... In-Reply-To: <9D4F0A12-2F7A-4352-92CF-3863E7028AFE@arin.net> Message-ID: <32423678.4563.1296761643887.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "John Curran" > Mr. Rubi - > > I'm sorry if my answer is not clear. > > If your question was: "What is the source of ARIN's legal authority to > manage the ARIN WHOIS database?" > > then answer is that the database is managed as part of ARIN's mission, > per policies established by the community. > > If you're trying to ask a different question, I'm more than happy to > answer, but I'd ask that you be more explicit. I strongly suspect that his question is actually "Does ARIN have any enforceable legal authority to compel an entity to cease using a specific block of address space, absent a contract?" I suspect the actual answer will turn out to depend on whether courts construe that as a property right or not. The situation is analogous to that concerning telephone numbers, and that position has changed over time, in that arena, as I understand it. Cheers, -- jra From paul at paulgraydon.co.uk Thu Feb 3 13:39:09 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Thu, 03 Feb 2011 09:39:09 -1000 Subject: External sanity checks In-Reply-To: <844412.30168.qm@web30804.mail.mud.yahoo.com> References: <844412.30168.qm@web30804.mail.mud.yahoo.com> Message-ID: <4D4B045D.1020409@paulgraydon.co.uk> On 02/03/2011 08:04 AM, Philip Lavine wrote: > To all, > > Does any one know a Vendor (NOT Keynote) that can do sanity checks against your web/smtp/ftp farms with pings, traceroutes, latency checks as well as application checks (GET, POST, ESMTP, etc) > > Thank you, > > Philip > Slight hijack, I'm interested in the answer to this question, but I'm also wondering about a service that will actually phone you (or is there a reliable text/e-mail->phone call service?) I'd appreciate actually being phoned overnight if something dies drastically to the outside world! From mhuff at ox.com Thu Feb 3 13:39:15 2011 From: mhuff at ox.com (Matthew Huff) Date: Thu, 3 Feb 2011 14:39:15 -0500 Subject: quietly.... In-Reply-To: <37955.1296761312@localhost> References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> <483E6B0272B0284BA86D7596C40D29F9011F76964E94@PUR-EXCH07.ox.com> <37955.1296761312@localhost> Message-ID: <483E6B0272B0284BA86D7596C40D29F9011F76964E98@PUR-EXCH07.ox.com> Trust me, I'm very familiar with FTP and firewalls. The problem is not just with NAT, but exists with SPI. Both are solved problems that work with NAT. Something like ftp over SSH works well without fixup or NAT issues and is becoming more standard at least in the financial services community. IPSEC to a NAT/SPI firewall works fine, through it has issues. But then again, rarely do you want that in a corporate network anyway. > -----Original Message----- > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > Sent: Thursday, February 03, 2011 2:29 PM > To: Matthew Huff > Cc: Owen DeLong; nanog at nanog.org > Subject: Re: quietly.... > > On Thu, 03 Feb 2011 13:41:26 EST, Matthew Huff said: > > Owen, can you point to a application protocol that is broken via NAT that > > isn't a p2p protocol or VoIP? > > The only reason FTP works through a NAT is because the NAT has already > been hacked up to further mangle the data stream to make up for the > mangling it does. > > I'm told that IPSEC through a NAT can be interesting too... And that's > something I'm also told some corporations are interested in. From Bryan at bryanfields.net Thu Feb 3 13:45:32 2011 From: Bryan at bryanfields.net (Bryan Fields) Date: Thu, 03 Feb 2011 14:45:32 -0500 Subject: And so it ends... In-Reply-To: <9D4F0A12-2F7A-4352-92CF-3863E7028AFE@arin.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <6E186F3F-6267-4D9B-916A-3663F13AA999@corp.arin.net> <0FDB411B-3687-40F0-B18C-4A2A28ACA51E@queuefull.net> <8CB83F29-CE39-4775-84E0-8F57A932225D@arin.net> <496ACB00-D0C8-4E7A-8ED3-176DC3BF819E@cs.fiu.edu> <45444CE9-AB4B-4308-B1EC-D80D4DB7EAC1@arin.net> <12F71EB1-E945-4189-BD5F-19715F7DE680@cs.fiu.edu> <9D4F0A12-2F7A-4352-92CF-3863E7028AFE@arin.net> Message-ID: <4D4B05DC.4080501@bryanfields.net> On 2/3/2011 14:16, John Curran wrote: > then answer is that the database is managed as part of ARIN's mission, per > policies established by the community. > > If you're trying to ask a different question, I'm more than happy to > answer, but I'd ask that you be more explicit. > > On Feb 3, 2011, at 1:41 PM, Ernie Rubi wrote: > >>> I think it's OK to say you cannot/would rather not answer the question, >>> instead of giving a non-answer. I was trying to follow along with your >>> 'the community acquiescence gives us the legal right to take back >>> legacy IP addresses' argument. I guess my question here is, does ARIN have the right to take Legacy IP space if it's not being used properly? For example 44/8 which is Legacy from IANA. Or does legacy in this context mean a company with a /14 allocation from ARIN thats not using it? If so, how often, if ever has ARIN done this? Can you provide some examples of this being done? -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From iljitsch at muada.com Thu Feb 3 13:47:48 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 3 Feb 2011 20:47:48 +0100 Subject: Failure modes: NAT vs SPI In-Reply-To: <13040078.4555.1296760192315.JavaMail.root@benjamin.baylink.com> References: <13040078.4555.1296760192315.JavaMail.root@benjamin.baylink.com> Message-ID: <1BC162C5-2535-48F0-8CA3-CDCD1490E568@muada.com> On 3 feb 2011, at 20:09, Jay Ashworth wrote: > That's the expansion of "fails safe". You conviently overlook my earlier message about this. But sure, let's assume that at some point, some packets from the outside manage to pass through to the inside in the IPv6 case. So how does anyone know where to send these packets in the first place? And if they do, what bad effects exactly do packets coming from the outside have? Ping of death has been fixed a loooong time ago. And you assume that NATs block packets very well. They don't. First of all, there's uPNP IGD and NAT-PMP. Depending on the type of NAT, the bindings are quite loose and allow lots of additional packets that don't belong to the NATed sessions in. After all, NATs only break incoming sessions by accident. Firewalls do this on purpose, so they do a much better job. If you really want to be safe, you should completely disconnect your network. Or at the very least not run any code, such as javascript and java, that comes in over the network. This is one of the biggest sources of real-world infections. Incoming packets haven't been since about the slammer worm era. From tme at americafree.tv Thu Feb 3 13:48:58 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Thu, 3 Feb 2011 14:48:58 -0500 Subject: Egypt 'hijacked Vodafone network' In-Reply-To: <347523.24998.qm@web59612.mail.ac4.yahoo.com> References: <347523.24998.qm@web59612.mail.ac4.yahoo.com> Message-ID: <76ED7DE1-2097-41A4-A5E1-4E226C50DC42@americafree.tv> On Feb 3, 2011, at 2:20 PM, andrew.wallace wrote: > On Thu, Feb 3, 2011 at 6:59 PM, Scott Brim wrote: >> On 02/03/2011 10:14 EST, Marshall Eubanks wrote: >>> >>> On Feb 3, 2011, at 9:24 AM, andrew.wallace wrote: >>> >>>> Mobile phone firm Vodafone accuses the Egyptian authorities of >>>> using its network to send pro-government text messages. >>>> >>>> http://www.bbc.co.uk/news/business-12357694 >>> >>> Here is their PR >>> >>> http://www.vodafone.com/content/index/press.html >>> >>> Note that this is entirely legal, under "the emergency powers >>> provisions of the Telecoms Act" >> >> Which is legal, Vodafone's protest or the government's telling them to >> send messages? afaik the agreement was that the operator would have >> preloaded canned messages, agreed on in advance with the government, and >> now the government is telling them to send out arbitrary messages they >> compose on the spot. >> >> > > I wonder if these messages were blockable by the end-user or if they were being sent as a service announcement from Vodafone. > > Certainly, if the government were sending the messages under the company name then something sounds wrong about that. > > What I would like is to hear from someone who received the messages and what their experiences were. > They were described to me as being "from Vodafone." I assumed that this meant that they were service messages. Marshall > Andrew > > > > > From ernesto at cs.fiu.edu Thu Feb 3 13:54:02 2011 From: ernesto at cs.fiu.edu (Ernie Rubi) Date: Thu, 3 Feb 2011 14:54:02 -0500 Subject: And so it ends... In-Reply-To: <32423678.4563.1296761643887.JavaMail.root@benjamin.baylink.com> References: <32423678.4563.1296761643887.JavaMail.root@benjamin.baylink.com> Message-ID: That's the question, and it seemed that the answer started to be formulated in terms of 'community acquiescence/policy leads to authority' in a previous email, so I wanted to make sure that was in fact the response to the question, at least in part. ARIN will likely argue that 'this was done already' (i.e. they've taken legacy IP space away from an unwilling/uncooperative holder of said legacy space), but I haven't seen such an example. This is a good debate, a lot of people are already annoyed at these questions and every single one always has an air of 'stfu kid' about them. But then again, a lot of ppl got annoyed at the civil rights movement. (drifting off topic here). You cannot escape these questions and they will be decided firmly (in a legal sense) sooner or later. It may be that this all becomes moot when v6 gets fully deployed, but until then, it's a worthwhile conversation to have. On Feb 3, 2011, at 2:34 PM, Jay Ashworth wrote: > I strongly suspect that his question is actually "Does ARIN have any > enforceable legal authority to compel an entity to cease using a > specific block of address space, absent a contract?" From jbates at brightok.net Thu Feb 3 13:55:39 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 03 Feb 2011 13:55:39 -0600 Subject: quietly.... In-Reply-To: <201102031404.45801.lowen@pari.edu> References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> <201102031404.45801.lowen@pari.edu> Message-ID: <4D4B083B.3070900@brightok.net> On 2/3/2011 1:04 PM, Lamar Owen wrote: > On Thursday, February 03, 2011 01:35:46 pm Jack Bates wrote: >> I understand and agree that CPEs should not use NAT66. It should even be >> a MUST NOT in the cpe router draft. > > Do you really think that this will stop the software developers of some CPE routers' OS code from just making it work? Do you really think the standard saying 'thou shalt not NAT' will produce the desired effect of preventing such devices from actually getting built? > Do you think we have to have a standard for them to implement it? If they can ignore the CPE router rules, they can implement NAT66 on their own, too. Jack From jcurran at arin.net Thu Feb 3 13:56:46 2011 From: jcurran at arin.net (John Curran) Date: Thu, 3 Feb 2011 19:56:46 +0000 Subject: And so it ends... In-Reply-To: <32423678.4563.1296761643887.JavaMail.root@benjamin.baylink.com> References: <32423678.4563.1296761643887.JavaMail.root@benjamin.baylink.com> Message-ID: On Feb 3, 2011, at 2:34 PM, Jay Ashworth wrote: > > I strongly suspect that his question is actually "Does ARIN have any > enforceable legal authority to compel an entity to cease using a > specific block of address space, absent a contract?" ARIN has the authority to manage its database, and does so according to the community developed policies. This includes changing the entries which designate the address holder, and specify that there is now a new address holder. None of this has to do with how entities configure their routers or servers. /John John Curran President and CEO ARIN From jra at baylink.com Thu Feb 3 14:02:14 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 3 Feb 2011 15:02:14 -0500 (EST) Subject: And so it ends... In-Reply-To: Message-ID: <29938340.4577.1296763334557.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "John Curran" > On Feb 3, 2011, at 2:34 PM, Jay Ashworth wrote: > > I strongly suspect that his question is actually "Does ARIN have any > > enforceable legal authority to compel an entity to cease using a > > specific block of address space, absent a contract?" > > ARIN has the authority to manage its database, and does so according to > the community developed policies. This includes changing the entries > which designate the address holder, and specify that there is now a new > address holder. > > None of this has to do with how entities configure their routers or > servers. Sure it does. If best common practice is for network operators to get address space from ARIN, and someone gets a block from you that you've supposedly adversely taken back from, say, Goldman Sachs, and starts using it, then *someone* is going to drink your milkshake, whether it be the new user or the old one. There is some reasonable expectation that if you claim to be the Source of All Good (Address) Bits, and you hand out a block that's in dispute, that whomever relied on that will have an action. It's an unpleasant position to be in, but you *are* there, make no mistake. Cheers, -- jra From mpalmer at hezmatt.org Thu Feb 3 14:12:26 2011 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Fri, 4 Feb 2011 07:12:26 +1100 Subject: quietly.... In-Reply-To: <4D4ADC36.1080803@brightok.net> References: <2FD9EDE7-E28C-48E7-B6FB-8386773EF98E@delong.com> <9689E83C-048A-4D72-946B-978FB3C315A4@sackheads.org> <3CD3A697-8D3C-4EDE-8E4E-53C0E103E12C@sackheads.org> <4D4A43B6.5080306@otd.com> <5A51DAF3-6189-4785-9543-CB046B2819B9@muada.com> <4D4ADC36.1080803@brightok.net> Message-ID: <20110203201226.GG24798@hezmatt.org> On Thu, Feb 03, 2011 at 10:47:50AM -0600, Jack Bates wrote: > On 2/3/2011 10:30 AM, Iljitsch van Beijnum wrote: > >I'm perfectly happy with an IPv6 network that only has rational > >people on it while those who insist on NAT stay behind on IPv4. > > I'm perfectly happy with watching the Internet go to hell; as it has > been, and IPv6 will just escalate it. :) I am intrigued by your ideas, and wish to subscribe to your newsletter. Actually, I must agree that since I've stopped doing IT work professionally, I've found myself far less emotionally invested in this kind of thing, and far less worried about the world ending (which, let's face it, it rarely does). Does wonders for the blood pressure. - Matt From lowen at pari.edu Thu Feb 3 14:20:25 2011 From: lowen at pari.edu (Lamar Owen) Date: Thu, 3 Feb 2011 15:20:25 -0500 Subject: quietly.... In-Reply-To: <37955.1296761312@localhost> References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> Message-ID: <201102031520.26126.lowen@pari.edu> On Thursday, February 03, 2011 02:28:32 pm Valdis.Kletnieks at vt.edu wrote: > The only reason FTP works through a NAT is because the NAT has already > been hacked up to further mangle the data stream to make up for the > mangling it does. FTP is a in essence a peer-to-peer protocol, as both ends initiate TCP streams. I know that's nitpicking, but it is true. > I'm told that IPSEC through a NAT can be interesting too... And that's > something I'm also told some corporations are interested in. IPsec NAT Traversal over UDP port 4500 works ok, but it does require port-forwarding (either manual, automatic-in-the-router, or uPNP) to work ok. There are a number of HOWTO's out there to make it work, and we've been doing it between the native Windows L2TP VPN client (PPTP is insecure; L2TP as implemented by Microsoft is a three layer melange of PPP on top, with L2TP carrying that, encapsulated in IPsec between two endpoints) and SmoothWall's SmoothTunnel for several years. It does work, and it's not as hard as it could be. But it's not as easy as it should be, at least on the network plumbing side of things. However, that's not typically the hardest part of setting up a Microsoft-style PPPoL2TPoIPsec VPN, though, especially if you use certificates instead of preshared keys. From jcurran at arin.net Thu Feb 3 14:22:28 2011 From: jcurran at arin.net (John Curran) Date: Thu, 3 Feb 2011 20:22:28 +0000 Subject: And so it ends... In-Reply-To: <29938340.4577.1296763334557.JavaMail.root@benjamin.baylink.com> References: <29938340.4577.1296763334557.JavaMail.root@benjamin.baylink.com> Message-ID: <58E6E7D6-00D9-42E9-BF45-41CD9D6A5BB9@corp.arin.net> On Feb 3, 2011, at 3:02 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "John Curran" > >> On Feb 3, 2011, at 2:34 PM, Jay Ashworth wrote: >>> I strongly suspect that his question is actually "Does ARIN have any >>> enforceable legal authority to compel an entity to cease using a >>> specific block of address space, absent a contract?" >> >> ARIN has the authority to manage its database, and does so according to >> the community developed policies. This includes changing the entries >> which designate the address holder, and specify that there is now a new >> address holder. >> >> None of this has to do with how entities configure their routers or >> servers. > > Sure it does. If best common practice is for network operators to get > address space from ARIN, and someone gets a block from you that you've > supposedly adversely taken back from, say, Goldman Sachs, and starts > using it, then *someone* is going to drink your milkshake, whether it be > the new user or the old one. To be clear, that's not ARIN "legally compelling an entity to cease using a specific block of address space" We've never claimed that authority, and I'm not aware of any entity that does claim such authority to compel organizations to make router and system configuration changes. We do claim authority to manage the database as part of our organizational mission. /John John Curran President and CEO ARIN From jbates at brightok.net Thu Feb 3 14:23:26 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 03 Feb 2011 14:23:26 -0600 Subject: quietly.... In-Reply-To: <37955.1296761312@localhost> References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> <483E6B0272B0284BA86D7596C40D29F9011F76964E94@PUR-EXCH07.ox.com> <37955.1296761312@localhost> Message-ID: <4D4B0EBE.6000903@brightok.net> On 2/3/2011 1:28 PM, Valdis.Kletnieks at vt.edu wrote: > The only reason FTP works through a NAT is because the NAT has already > been hacked up to further mangle the data stream to make up for the > mangling it does. PASV From mpalmer at hezmatt.org Thu Feb 3 14:24:57 2011 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Fri, 4 Feb 2011 07:24:57 +1100 Subject: quietly.... In-Reply-To: <4D4AF582.6080902@brightok.net> References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> <4D4AF582.6080902@brightok.net> Message-ID: <20110203202457.GH24798@hezmatt.org> On Thu, Feb 03, 2011 at 12:35:46PM -0600, Jack Bates wrote: > On 2/3/2011 12:17 PM, Owen DeLong wrote: > > Cost of application development > > Applications do not have to be written to support NAT (NAT66 > shouldn't find itself in the areas where it's traditionally been a > problem). The burden should be upon the NAT device to fix any > issues, and this will be paid for by the few that utilize NAT. You're joking, right? > > Cost of administration > > If I choose to use NAPTv6, it's right to accept this cost. It > doesn't make someone else pay more for me to administer my firewall. > > > Cost of operations > > If I choose to use NAPTv6, it's right to accept this cost. It > doesn't make someone else pay more for me to administer my firewall. Oh wait... you're *serious*? Have you never in your career come up against another party that says "this is how we do it, and if you want to do business with us you can do it our way or get stuffed"? All of a sudden, their decision to use NAT and/or do other spectacularly stupid things with their networks impacts on *me*[1], and costs *me* money. It doesn't work out like the optimistic utopia you're espousing. - Matt [1] Is there such thing as a "royal me"? There should be. From jra at baylink.com Thu Feb 3 14:27:40 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 3 Feb 2011 15:27:40 -0500 (EST) Subject: And so it ends... In-Reply-To: <58E6E7D6-00D9-42E9-BF45-41CD9D6A5BB9@corp.arin.net> Message-ID: <14874181.4589.1296764860080.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "John Curran" > On Feb 3, 2011, at 3:02 PM, Jay Ashworth wrote: > To be clear, that's not ARIN "legally compelling an entity to cease using > a specific block of address space" We've never claimed that authority, > and I'm not aware of any entity that does claim such authority to compel > organizations to make router and system configuration changes. We do > claim authority to manage the database as part of our organizational > mission. I was insufficiently clear, I guess. If that database, which it is your mission to manage, purports to contain "address blocks which an applicant can safely deploy without fear of conflicting routes being advertised on the greater Internet" (as I understand that it does), and I were such an applicant, and you assigned me a block which was in dispute -- it had been adversely taken away from someone who believed they had rights to it -- *and they were still using it* -- then I as that new applicant would be very unhappy with ARIN, particularly if they did not notify me that there was a conflict. Whether I would take action against ARIN or the old holder, I dunno; IANAL. But, in short, if ARIN ever *does* take a block back adversely, and the holder refuses to let it go, and ARIN assigns that block to someone else... well, things might get messy. Cheers, -- jra From jbates at brightok.net Thu Feb 3 14:28:00 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 03 Feb 2011 14:28:00 -0600 Subject: quietly.... In-Reply-To: <20110203201226.GG24798@hezmatt.org> References: <2FD9EDE7-E28C-48E7-B6FB-8386773EF98E@delong.com> <9689E83C-048A-4D72-946B-978FB3C315A4@sackheads.org> <3CD3A697-8D3C-4EDE-8E4E-53C0E103E12C@sackheads.org> <4D4A43B6.5080306@otd.com> <5A51DAF3-6189-4785-9543-CB046B2819B9@muada.com> <4D4ADC36.1080803@brightok.net> <20110203201226.GG24798@hezmatt.org> Message-ID: <4D4B0FD0.3080300@brightok.net> On 2/3/2011 2:12 PM, Matthew Palmer wrote: > Actually, I must agree that since I've stopped doing IT work professionally, > I've found myself far less emotionally invested in this kind of thing, and > far less worried about the world ending (which, let's face it, it rarely > does). Does wonders for the blood pressure. I used to say that if I won the lottery, I'd still keep my job (as I love it). Dealing with IPv6 and the fact that decades apparently isn't enough for a standards body and a small set of corporations to design and implement a protocol which needs to do everything the old one did (minimum) and more (advisable), I've recently reconsidered. Here's to winning the Lottery. Then I won't need the Internet. :) jack From jeffrey.lyon at blacklotus.net Thu Feb 3 14:28:40 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 3 Feb 2011 15:28:40 -0500 Subject: And so it ends... In-Reply-To: <29938340.4577.1296763334557.JavaMail.root@benjamin.baylink.com> References: <29938340.4577.1296763334557.JavaMail.root@benjamin.baylink.com> Message-ID: On Thu, Feb 3, 2011 at 3:02 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "John Curran" > >> On Feb 3, 2011, at 2:34 PM, Jay Ashworth wrote: >> > I strongly suspect that his question is actually "Does ARIN have any >> > enforceable legal authority to compel an entity to cease using a >> > specific block of address space, absent a contract?" >> >> ARIN has the authority to manage its database, and does so according to >> the community developed policies. This includes changing the entries >> which designate the address holder, and specify that there is now a new >> address holder. >> >> None of this has to do with how entities configure their routers or >> servers. > > Sure it does. ?If best common practice is for network operators to get > address space from ARIN, and someone gets a block from you that you've > supposedly adversely taken back from, say, Goldman Sachs, and starts > using it, then *someone* is going to drink your milkshake, whether it be > the new user or the old one. > > There is some reasonable expectation that if you claim to be the > Source of All Good (Address) Bits, and you hand out a block that's in > dispute, that whomever relied on that will have an action. > > It's an unpleasant position to be in, but you *are* there, make no mistake. > > Cheers, > -- jra > > I think what John Curran is trying to say is that ARIN does not have the authority to reclaim any space, as it merely provides a registration service for the benefit of operators who recognize ARIN's database as legitimate. Similarly, no one is required to recognize the "rights" of legacy block holders which opens the doors for the operator community to declare those blocks as bogons until the legacy holders decide to play nice and release the space to an RIR. In short, no one can take their space by force but we as a community can stop recognizing them as legitimate owners. My highly controversial two cents, -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From lowen at pari.edu Thu Feb 3 14:29:12 2011 From: lowen at pari.edu (Lamar Owen) Date: Thu, 3 Feb 2011 15:29:12 -0500 Subject: quietly.... In-Reply-To: <4D4B083B.3070900@brightok.net> References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> Message-ID: <201102031529.12870.lowen@pari.edu> On Thursday, February 03, 2011 02:55:39 pm Jack Bates wrote: > Do you think we have to have a standard for them to implement it? > > If they can ignore the CPE router rules, they can implement NAT66 on > their own, too. See the map66 Sourceforge.net project. Already happening. From khelms at ispalliance.net Thu Feb 3 14:36:53 2011 From: khelms at ispalliance.net (Scott Helms) Date: Thu, 03 Feb 2011 15:36:53 -0500 Subject: And so it ends... In-Reply-To: <14874181.4589.1296764860080.JavaMail.root@benjamin.baylink.com> References: <14874181.4589.1296764860080.JavaMail.root@benjamin.baylink.com> Message-ID: <4D4B11E5.7000005@ispalliance.net> My 2 cents, in the few cases that we've been involved with that dealt with reclaiming space the backbone providers have universally followed what is in the ARIN database. If you need a block routed they generally will not take action until the SWIP is complete and the same is true when pulling space back that had been in use. Since the major ISPs (and most of the minor ones as well) filter the BGP they get from customer they can prevent the advertisement of blocks that are disputed. On 2/3/2011 3:27 PM, Jay Ashworth wrote: > > I was insufficiently clear, I guess. > > If that database, which it is your mission to manage, purports to contain > "address blocks which an applicant can safely deploy without fear of > conflicting routes being advertised on the greater Internet" (as I understand > that it does), and I were such an applicant, and you assigned me a block > which was in dispute -- it had been adversely taken away from someone > who believed they had rights to it -- *and they were still using it* -- > then I as that new applicant would be very unhappy with ARIN, particularly > if they did not notify me that there was a conflict. > > Whether I would take action against ARIN or the old holder, I dunno; IANAL. > > But, in short, if ARIN ever *does* take a block back adversely, and the > holder refuses to let it go, and ARIN assigns that block to someone else... > > well, things might get messy. > > Cheers, > -- jra > > -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- Looking for hand-selected news, views and tips for independent broadband providers? Follow us on Twitter! http://twitter.com/ZCorum -------------------------------- From jeffrey.lyon at blacklotus.net Thu Feb 3 14:37:26 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 3 Feb 2011 15:37:26 -0500 Subject: And so it ends... In-Reply-To: <14874181.4589.1296764860080.JavaMail.root@benjamin.baylink.com> References: <58E6E7D6-00D9-42E9-BF45-41CD9D6A5BB9@corp.arin.net> <14874181.4589.1296764860080.JavaMail.root@benjamin.baylink.com> Message-ID: On Thu, Feb 3, 2011 at 3:27 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "John Curran" > >> On Feb 3, 2011, at 3:02 PM, Jay Ashworth wrote: >> To be clear, that's not ARIN "legally compelling an entity to cease using >> a specific block of address space" We've never claimed that authority, >> and I'm not aware of any entity that does claim such authority to compel >> organizations to make router and system configuration changes. We do >> claim authority to manage the database as part of our organizational >> mission. > > I was insufficiently clear, I guess. > > If that database, which it is your mission to manage, purports to contain > "address blocks which an applicant can safely deploy without fear of > conflicting routes being advertised on the greater Internet" (as I understand > that it does), and I were such an applicant, and you assigned me a block > which was in dispute -- it had been adversely taken away from someone > who believed they had rights to it -- *and they were still using it* -- > then I as that new applicant would be very unhappy with ARIN, particularly > if they did not notify me that there was a conflict. > > Whether I would take action against ARIN or the old holder, I dunno; IANAL. > > But, in short, if ARIN ever *does* take a block back adversely, and the > holder refuses to let it go, and ARIN assigns that block to someone else... > > well, things might get messy. > > Cheers, > -- jra > > On the other hand, if the community agrees to implement something like Spamhaus' DROP list, any space that an RIR wishes to reclaim can be added to the list to prevent routing/peering until such time that the affected user releases their grip. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From Valdis.Kletnieks at vt.edu Thu Feb 3 14:36:26 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 03 Feb 2011 15:36:26 -0500 Subject: quietly.... In-Reply-To: Your message of "Thu, 03 Feb 2011 14:39:15 EST." <483E6B0272B0284BA86D7596C40D29F9011F76964E98@PUR-EXCH07.ox.com> References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> <483E6B0272B0284BA86D7596C40D29F9011F76964E94@PUR-EXCH07.ox.com> <37955.1296761312@localhost> <483E6B0272B0284BA86D7596C40D29F9011F76964E98@PUR-EXCH07.ox.com> Message-ID: <43082.1296765386@localhost> On Thu, 03 Feb 2011 14:39:15 EST, Matthew Huff said: > Something like ftp over SSH works well without fixup or NAT issues and is > becoming more standard at least in the financial services community. And having to do it over SSH *isn't* a fixup/hackaround? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From drais at icantclick.org Thu Feb 3 14:38:47 2011 From: drais at icantclick.org (david raistrick) Date: Thu, 3 Feb 2011 15:38:47 -0500 (EST) Subject: quietly.... In-Reply-To: <37955.1296761312@localhost> References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> <483E6B0272B0284BA86D7596C40D29F9011F76964E94@PUR-EXCH07.ox.com> <37955.1296761312@localhost> Message-ID: On Thu, 3 Feb 2011, Valdis.Kletnieks at vt.edu wrote: > The only reason FTP works through a NAT is because the NAT has already > been hacked up to further mangle the data stream to make up for the > mangling it does. Speaking of should-have-died-years-ago. FTP fits that category well. ;) > I'm told that IPSEC through a NAT can be interesting too... And that's > something I'm also told some corporations are interested in. NAT traversal for ipsec was sorted out more than a few years ago with 3 or 4 different methods in play. I dropped out of that market about the time it came to light, but as a ipsec end user I haven't had NAT problems going back as far as 2006 for sure, possibily further. (the original problem was that only 1 user behind 1 IP could speak ipsec because it uses a specific protocol, not a port, that can only be 1-to-1. I'll leave it as an exercise for the reader to figure out that was magiced around without requiring the NAT devices to do anything. and ssl doesn't count. :) -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From drc at virtualized.org Thu Feb 3 14:42:06 2011 From: drc at virtualized.org (David Conrad) Date: Thu, 3 Feb 2011 10:42:06 -1000 Subject: And so it ends... In-Reply-To: <765C578E-3EB4-4C73-ADD8-D3A175FE5371@delong.com> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <6E186F3F-6267-4D9B-916A-3663F13AA999@corp.arin.net> <0FDB411B-3687-40F0-B18C-4A2A28ACA51E@queuefull.net> <765C578E-3EB4-4C73-ADD8-D3A175FE5371@delong.com> Message-ID: <76CBE1FA-FDFF-446D-8ACA-C304D9CA2DE2@virtualized.org> On Feb 3, 2011, at 8:59 AM, Owen DeLong wrote: > That remains to be seen. If they give up their space, it is unclear that they have any right to transfer it to another > organization rather than return it to the successor registry. There is no precedent established showing that > this is allowed. Right. Like Compaq returned 16/8 when they acquired Digital (and HP returned 16/8 when they acquired Compaq). > That remains to be seen. IANA has declared them the successor registries No. First, "IANA" does not exist. The term "IANA" now refers to a series of functions currently performed under contract from the US Dept. of Commerce, NTIA by ICANN. As such it can't declare anything. Second, neither ICANN nor the USG has (to my knowledge) declared the RIRs to be "successor registries" (whatever they are). The IPv4 registry continues to exist and will undoubtedly be maintained as it always has been. The only real difference is that there aren't any more IPv4 /8s tagged with "UNALLOCATED". > The other thing to consider is that the RIR doesn't really need to "reclaim" the block, per se. They can simply stop providing uniqueness to the organizations that don't have a contract with them and issue those numbers to some other organization that has a contract. The other organization would know that their uniqueness is limited to those cooperating in the registry system. > > Does an organization that has no contract with an RIR have a right to expect that RIR to continue to provide them a unique registration? The RIRs are self-defined geographical monopolies that provide a set of public infrastructure services to the Internet community at large. It's an interesting question whether that service is limited to only those folks who pay -- my guess if the RIRs took this stance, they'd be looking down the barrel of numerous governmental anti-monopoly/anti-cartel agencies. However, pragmatically speaking, the folks who matter in any of this are the ISPs. The RIRs exist primarily as a means by which ISPs can avoid doing a myriad set of bilateral agreements as to who "owns" what address space to ensure uniqueness. If the RIRs reduce their value by no longer providing that service in an effective way (e.g., by doing what you suggest), I suspect the ISPs would find other entities to provide global uniqueness services. Regards, -drc From simon.perreault at viagenie.ca Thu Feb 3 14:46:06 2011 From: simon.perreault at viagenie.ca (Simon Perreault) Date: Thu, 03 Feb 2011 15:46:06 -0500 Subject: quietly.... In-Reply-To: <201102031529.12870.lowen@pari.edu> References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> <201102031529.12870.lowen@pari.edu> Message-ID: <4D4B140E.5050707@viagenie.ca> On 2011-02-03 15:29, Lamar Owen wrote: > On Thursday, February 03, 2011 02:55:39 pm Jack Bates wrote: >> Do you think we have to have a standard for them to implement it? >> >> If they can ignore the CPE router rules, they can implement NAT66 on >> their own, too. > > See the map66 Sourceforge.net project. Already happening. OpenBSD's pf has had stateful NAT66 for many years... Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From mhuff at ox.com Thu Feb 3 14:46:11 2011 From: mhuff at ox.com (Matthew Huff) Date: Thu, 3 Feb 2011 15:46:11 -0500 Subject: quietly.... In-Reply-To: <43082.1296765386@localhost> References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> <483E6B0272B0284BA86D7596C40D29F9011F76964E94@PUR-EXCH07.ox.com> <37955.1296761312@localhost> <483E6B0272B0284BA86D7596C40D29F9011F76964E98@PUR-EXCH07.ox.com> <43082.1296765386@localhost> Message-ID: <483E6B0272B0284BA86D7596C40D29F9011F76964E9C@PUR-EXCH07.ox.com> Well, since ssh is a straight up tcp socket protocol on a well know port with no gimmicks needed like FTP, yeah, I would say it isn't a hack. FTP over TLS/SSL is much worse. In some implementations you can do an non-encrypted control channel and an encrypted data channel, so that a SPI firewall can "hack" it through, but unfortunately a lot of servers and/or clients won't negotiate that correctly and only allow both type of channels to be encrypted which is not possible to pass through a SPI firewall. There are two other sorta widely implemented secure file transfer protocols, SCP and WebDav over TLS/SSL. Either works fine through a SPI firewall, but the consensus for file transfer (at least over the pub net) within the financial services community appears to be converging to FTP over ssh. > -----Original Message----- > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > Sent: Thursday, February 03, 2011 3:36 PM > To: Matthew Huff > Cc: Owen DeLong; nanog at nanog.org > Subject: Re: quietly.... > > On Thu, 03 Feb 2011 14:39:15 EST, Matthew Huff said: > > Something like ftp over SSH works well without fixup or NAT issues and is > > becoming more standard at least in the financial services community. > > And having to do it over SSH *isn't* a fixup/hackaround? > From ernesto at cs.fiu.edu Thu Feb 3 14:48:16 2011 From: ernesto at cs.fiu.edu (Ernie Rubi) Date: Thu, 3 Feb 2011 15:48:16 -0500 Subject: And so it ends... In-Reply-To: References: <29938340.4577.1296763334557.JavaMail.root@benjamin.baylink.com> Message-ID: Um, I think that's what ARIN means when they say changing the registrant on a block from Entity A to Entity B means. That's effectively 'reclaiming'. As I understand it, I think they also contend that the 'community' could say to ARIN 'take back X legacy block' and that ARIN would have no choice but to do it if the 'community' wished it so (via policy process, etc). On Feb 3, 2011, at 3:28 PM, Jeffrey Lyon wrote: > I think what John Curran is trying to say is that ARIN does not have > the authority to reclaim any space From jeffrey.lyon at blacklotus.net Thu Feb 3 14:51:31 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 3 Feb 2011 15:51:31 -0500 Subject: And so it ends... In-Reply-To: References: <29938340.4577.1296763334557.JavaMail.root@benjamin.baylink.com> Message-ID: On Thu, Feb 3, 2011 at 3:48 PM, Ernie Rubi wrote: > Um, I think that's what ARIN means when they say changing the registrant on a block from Entity A to Entity B means. ?That's effectively 'reclaiming'. > > As I understand it, I think they also contend that the 'community' could say to ARIN 'take back X legacy block' and that ARIN would have no choice but to do it if the 'community' wished it so (via policy process, etc). > > On Feb 3, 2011, at 3:28 PM, Jeffrey Lyon wrote: > >> I think what John Curran is trying to say is that ARIN does not have >> the authority to reclaim any space > > > Perhaps i'm missing the point, but my interpretation is that legacy holders are sovereign and have the same standing in the community as the RIR's. The only way to get that space back is to ask nicely or for operators to stop routing legacy space. I very seriously doubt that it is within ARIN's mission to form policy that directly impacts non-members. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From jra at baylink.com Thu Feb 3 14:55:54 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 3 Feb 2011 15:55:54 -0500 (EST) Subject: And so it ends... In-Reply-To: <4D4B11E5.7000005@ispalliance.net> Message-ID: <12333314.4611.1296766554573.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Scott Helms" > My 2 cents, in the few cases that we've been involved with that dealt > with reclaiming space the backbone providers have universally followed > what is in the ARIN database. If you need a block routed they generally > will not take action until the SWIP is complete and the same is true > when pulling space back that had been in use. Since the major ISPs (and > most of the minor ones as well) filter the BGP they get from customer > they can prevent the advertisement of blocks that are disputed. Stipulated. But are they going to go up against someone big? Do Lilly, DuPont and Merck need /8? HP need a /7? What if one of those blocks was the subject here? Apple? I will in turn stipulate that these events are not likely. But they're certainly not impossible. Cheers, -- jra From drc at virtualized.org Thu Feb 3 14:59:18 2011 From: drc at virtualized.org (David Conrad) Date: Thu, 3 Feb 2011 10:59:18 -1000 Subject: quietly.... In-Reply-To: <4D4ACB3B.4080200@brightok.net> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <4D4979D1.4000104@phaze.org> <70C15FD9-CF85-4664-B913-3EBE4271C7F5@muada.com> <4D499910.4020001@foobar.org> <4D4AB894.6050107@brightok.net> <4D4AB9B4.4060201@foobar.org> <4D4ACB3B.4080200@brightok.net > Message-ID: On Feb 3, 2011, at 5:35 AM, Jack Bates wrote: > You missed my pointed. Root servers are hard coded, but they aren't using a well known anycast address. Actually, most of the IP addresses used for root servers are anycast addresses and given they're in every resolver on the Internet, they're pretty well known... Of course, one might ask why those well known anycast addresses are "owned" by 12 different organizations instead of being "golden" addresses specified in an RFC or somesuch, but that gets into root server operator politics... Regards, -drc From drais at icantclick.org Thu Feb 3 14:59:50 2011 From: drais at icantclick.org (david raistrick) Date: Thu, 3 Feb 2011 15:59:50 -0500 (EST) Subject: And so it ends... In-Reply-To: <4D4B11E5.7000005@ispalliance.net> References: <14874181.4589.1296764860080.JavaMail.root@benjamin.baylink.com> <4D4B11E5.7000005@ispalliance.net> Message-ID: On Thu, 3 Feb 2011, Scott Helms wrote: > My 2 cents, in the few cases that we've been involved with that dealt with > reclaiming space the backbone providers have universally followed what is in If that legacy block holder were, well, one of the legacy block holders, would you as a backbone provider reject IBM or ATT or HP or Apple, etc? -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From mpalmer at hezmatt.org Thu Feb 3 14:59:56 2011 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Fri, 4 Feb 2011 07:59:56 +1100 Subject: quietly.... In-Reply-To: <201102031520.26126.lowen@pari.edu> References: <37955.1296761312@localhost> <201102031520.26126.lowen@pari.edu> Message-ID: <20110203205956.GK24798@hezmatt.org> On Thu, Feb 03, 2011 at 03:20:25PM -0500, Lamar Owen wrote: > On Thursday, February 03, 2011 02:28:32 pm Valdis.Kletnieks at vt.edu wrote: > > The only reason FTP works through a NAT is because the NAT has already > > been hacked up to further mangle the data stream to make up for the > > mangling it does. > > FTP is a in essence a peer-to-peer protocol, as both ends initiate TCP > streams. I know that's nitpicking, but it is true. So is SMTP, by the same token. Aptly demonstrating why the term "P2P" is so mind-alteringly stupid. - Matt From drc at virtualized.org Thu Feb 3 15:00:39 2011 From: drc at virtualized.org (David Conrad) Date: Thu, 3 Feb 2011 11:00:39 -1000 Subject: quietly.... In-Reply-To: <20110203124908.GJ23560@leitl.org> References: <44DDE580-2B01-46A3-B424-66468A6BA026@delong.com> <17286018.1914.1296696154135.JavaMail.root@zimbra.network1.net> <20110203124908.GJ23560@leitl.org> Message-ID: On Feb 3, 2011, at 2:49 AM, Eugen Leitl wrote: > Any reason why RIPE NCC charges so much more? > > http://www.ripe.net/membership/billing/procedure-enduser.html > > (other than "because they can", I mean). http://wiki.answers.com/Q/What_is_geographic_monopoly Regards, -drc From ernesto at cs.fiu.edu Thu Feb 3 15:01:26 2011 From: ernesto at cs.fiu.edu (Ernie Rubi) Date: Thu, 3 Feb 2011 16:01:26 -0500 Subject: And so it ends... In-Reply-To: References: <29938340.4577.1296763334557.JavaMail.root@benjamin.baylink.com> Message-ID: I don't think that's ARIN's position (someone correct me if I'm wrong), especially if you mean to say they having the same 'rights' as RIRs to transfer/assign/lease/delegate/port those IP numbers. Using the numbers you have is another thing entirely. On Feb 3, 2011, at 3:51 PM, Jeffrey Lyon wrote: > my interpretation is that legacy > holders are sovereign and have the same standing in the community as > the RIR's. From khelms at ispalliance.net Thu Feb 3 15:05:58 2011 From: khelms at ispalliance.net (Scott Helms) Date: Thu, 03 Feb 2011 16:05:58 -0500 Subject: And so it ends... In-Reply-To: References: <14874181.4589.1296764860080.JavaMail.root@benjamin.baylink.com> <4D4B11E5.7000005@ispalliance.net> Message-ID: <4D4B18B6.9040207@ispalliance.net> David, That certainly could have an impact, since I imagine that corporations that large are purchasing nice big (expensive) connections. Having said that the cases I am familiar with were all dealt with at the technical level and a "business" rep wasn't involved. The BGP teams at the various providers tend to have a strong respect (much more so than their business leadership) for the RIRs, RFCs, and the various informal practices we've all dealt with that keep the Internet moving properly. On 2/3/2011 3:59 PM, david raistrick wrote: > On Thu, 3 Feb 2011, Scott Helms wrote: > >> My 2 cents, in the few cases that we've been involved with that dealt >> with reclaiming space the backbone providers have universally >> followed what is in > > If that legacy block holder were, well, one of the legacy block > holders, would you as a backbone provider reject IBM or ATT or HP or > Apple, etc? > > > -- > david raistrick http://www.netmeister.org/news/learn2quote.html > drais at icantclick.org http://www.expita.com/nomime.html > > -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- Looking for hand-selected news, views and tips for independent broadband providers? Follow us on Twitter! http://twitter.com/ZCorum -------------------------------- From ernesto at cs.fiu.edu Thu Feb 3 15:08:50 2011 From: ernesto at cs.fiu.edu (Ernie Rubi) Date: Thu, 3 Feb 2011 16:08:50 -0500 Subject: And so it ends... In-Reply-To: <76CBE1FA-FDFF-446D-8ACA-C304D9CA2DE2@virtualized.org> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <6E186F3F-6267-4D9B-916A-3663F13AA999@corp.arin.net> <0FDB411B-3687-40F0-B18C-4A2A28ACA51E@queuefull.net> <765C578E-3EB4-4C73-ADD8-D3A175FE5371@delong.com> <76CBE1FA-FDFF-446D-8ACA-C304D9CA2DE2@virtualized.org> Message-ID: <9A144B1F-323C-47A3-AA2C-F96E24A1729D@cs.fiu.edu> Way off topic here...and into the legal arena: As to the monopoly classification, do you think, at least with ARIN (since it is a US/Virginia corporation) that Sherman Act ?2 (i.e. antitrust) principles could be applied to require that it relinquish some of the control over said IP space/database and act in a more competitive manner? What about the other RIRs worldwide? I'm not an antitrust lawyer, but there may be an issue there. There was a paper a while back from a UMiami (Michael Froomkin) professor talking about ICANN and Antitrust. http://arxiv.org/pdf/cs/0109075 - This is a legal paper, not an engineering paper. I wonder if those same principles could be applied here. On Feb 3, 2011, at 3:42 PM, David Conrad wrote: > On Feb 3, 2011, at 8:59 AM, Owen DeLong wrote: >> That remains to be seen. If they give up their space, it is unclear that they have any right to transfer it to another >> organization rather than return it to the successor registry. There is no precedent established showing that >> this is allowed. > > Right. Like Compaq returned 16/8 when they acquired Digital (and HP returned 16/8 when they acquired Compaq). > >> That remains to be seen. IANA has declared them the successor registries > > No. First, "IANA" does not exist. The term "IANA" now refers to a series of functions currently performed under contract from the US Dept. of Commerce, NTIA by ICANN. As such it can't declare anything. > > Second, neither ICANN nor the USG has (to my knowledge) declared the RIRs to be "successor registries" (whatever they are). The IPv4 registry continues to exist and will undoubtedly be maintained as it always has been. The only real difference is that there aren't any more IPv4 /8s tagged with "UNALLOCATED". > >> The other thing to consider is that the RIR doesn't really need to "reclaim" the block, per se. They can simply stop providing uniqueness to the organizations that don't have a contract with them and issue those numbers to some other organization that has a contract. The other organization would know that their uniqueness is limited to those cooperating in the registry system. >> >> Does an organization that has no contract with an RIR have a right to expect that RIR to continue to provide them a unique registration? > > The RIRs are self-defined geographical monopolies that provide a set of public infrastructure services to the Internet community at large. It's an interesting question whether that service is limited to only those folks who pay -- my guess if the RIRs took this stance, they'd be looking down the barrel of numerous governmental anti-monopoly/anti-cartel agencies. > > However, pragmatically speaking, the folks who matter in any of this are the ISPs. The RIRs exist primarily as a means by which ISPs can avoid doing a myriad set of bilateral agreements as to who "owns" what address space to ensure uniqueness. If the RIRs reduce their value by no longer providing that service in an effective way (e.g., by doing what you suggest), I suspect the ISPs would find other entities to provide global uniqueness services. > > Regards, > -drc > Ernesto M. Rubi Sr. Network Engineer AMPATH/CIARA Florida International Univ, Miami Reply-to: ernesto at cs.fiu.edu Cell: 786-282-6783 From khelms at ispalliance.net Thu Feb 3 15:12:03 2011 From: khelms at ispalliance.net (Scott Helms) Date: Thu, 03 Feb 2011 16:12:03 -0500 Subject: And so it ends... In-Reply-To: <12333314.4611.1296766554573.JavaMail.root@benjamin.baylink.com> References: <12333314.4611.1296766554573.JavaMail.root@benjamin.baylink.com> Message-ID: <4D4B1A23.9060303@ispalliance.net> Jay, We were talking about the legacy disbursements here at the office much of the day. It would certainly be *nice* if some of the folks who were granted a class A back in the day would throw the unused parts back in the community bin. I don't think its a good idea to try and force the organizations in question to do so though and I'd guess that IBM and the others we've mentioned all have deeper pockets for legal teams than ARIN or most of the backbone providers. On 2/3/2011 3:55 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Scott Helms" >> My 2 cents, in the few cases that we've been involved with that dealt >> with reclaiming space the backbone providers have universally followed >> what is in the ARIN database. If you need a block routed they generally >> will not take action until the SWIP is complete and the same is true >> when pulling space back that had been in use. Since the major ISPs (and >> most of the minor ones as well) filter the BGP they get from customer >> they can prevent the advertisement of blocks that are disputed. > Stipulated. > > But are they going to go up against someone big? > > Do Lilly, DuPont and Merck need /8? HP need a /7? > > What if one of those blocks was the subject here? > > Apple? > > I will in turn stipulate that these events are not likely. But they're > certainly not impossible. > > Cheers, > -- jra > > -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- Looking for hand-selected news, views and tips for independent broadband providers? Follow us on Twitter! http://twitter.com/ZCorum -------------------------------- From jeffrey.lyon at blacklotus.net Thu Feb 3 15:27:38 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 3 Feb 2011 16:27:38 -0500 Subject: And so it ends... In-Reply-To: <9A144B1F-323C-47A3-AA2C-F96E24A1729D@cs.fiu.edu> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <6E186F3F-6267-4D9B-916A-3663F13AA999@corp.arin.net> <0FDB411B-3687-40F0-B18C-4A2A28ACA51E@queuefull.net> <765C578E-3EB4-4C73-ADD8-D3A175FE5371@delong.com> <76CBE1FA-FDFF-446D-8ACA-C304D9CA2DE2@virtualized.org> <9A144B1F-323C-47A3-AA2C-F96E24A1729D@cs.fiu.edu> Message-ID: On Thu, Feb 3, 2011 at 4:08 PM, Ernie Rubi wrote: > Way off topic here...and into the legal arena: > > As to the monopoly classification, do you think, at least with ARIN (since it is a US/Virginia corporation) that Sherman Act ?2 (i.e. antitrust) principles could be applied to require that it relinquish some of the control over said IP space/database and act in a more competitive manner? ?What about the other RIRs worldwide? ?I'm not an antitrust lawyer, but there may be an issue there. > > There was a paper a while back from a UMiami (Michael Froomkin) professor talking about ICANN and Antitrust. ?http://arxiv.org/pdf/cs/0109075 ?- This is a legal paper, not an engineering paper. > > I wonder if those same principles could be applied here. > > On Feb 3, 2011, at 3:42 PM, David Conrad wrote: > >> On Feb 3, 2011, at 8:59 AM, Owen DeLong wrote: >>> That remains to be seen. If they give up their space, it is unclear that they have any right to transfer it to another >>> organization rather than return it to the successor registry. There is no precedent established showing that >>> this is allowed. >> >> Right. ?Like Compaq returned 16/8 when they acquired Digital (and HP returned 16/8 when they acquired Compaq). >> >>> That remains to be seen. IANA has declared them the successor registries >> >> No. ?First, "IANA" does not exist. ?The term "IANA" now refers to a series of functions currently performed under contract from the US Dept. of Commerce, NTIA by ICANN. ?As such it can't declare anything. >> >> Second, neither ICANN nor the USG has (to my knowledge) declared the RIRs to be "successor registries" (whatever they are). ?The IPv4 registry continues to exist and will undoubtedly be maintained as it always has been. ?The only real difference is that there aren't any more IPv4 /8s tagged with "UNALLOCATED". >> >>> The other thing to consider is that the RIR doesn't really need to "reclaim" the block, per se. They can simply stop providing uniqueness to the organizations that don't have a contract with them and issue those numbers to some other organization that has a contract. The other organization would know that their uniqueness is limited to those cooperating in the registry system. >>> >>> Does an organization that has no contract with an RIR have a right to expect that RIR to continue to provide them a unique registration? >> >> The RIRs are self-defined geographical monopolies that provide a set of public infrastructure services to the Internet community at large. ?It's an interesting question whether that service is limited to only those folks who pay -- my guess if the RIRs took this stance, they'd be looking down the barrel of numerous governmental anti-monopoly/anti-cartel agencies. >> >> However, pragmatically speaking, the folks who matter in any of this are the ISPs. ?The RIRs exist primarily as a means by which ISPs can avoid doing a myriad set of bilateral agreements as to who "owns" what address space to ensure uniqueness. ?If the RIRs reduce their value by no longer providing that service in an effective way (e.g., by doing what you suggest), I suspect the ISPs would find other entities to provide global uniqueness services. >> >> Regards, >> -drc >> > > Ernesto M. Rubi > Sr. Network Engineer > AMPATH/CIARA > Florida International Univ, Miami > Reply-to: ernesto at cs.fiu.edu > Cell: 786-282-6783 > > > > > Pragmatically, compelling the release of a legacy allocation to a major company could be difficult, however, if the ARIN community were to draft a resolution to reclaim the space it may have a profound effect on public sentiment toward those companies. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From rcarpen at network1.net Thu Feb 3 15:31:43 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Thu, 3 Feb 2011 16:31:43 -0500 (EST) Subject: quietly.... In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9011F76964E9C@PUR-EXCH07.ox.com> Message-ID: <67743569.2257.1296768703397.JavaMail.root@zimbra.network1.net> ----- Original Message ----- > Well, since ssh is a straight up tcp socket protocol on a well know > port with no gimmicks needed like FTP, yeah, I would say it isn't a > hack. FTP over TLS/SSL is much worse. In some implementations you can > do an non-encrypted control channel and an encrypted data channel, so > that a SPI firewall can "hack" it through, but unfortunately a lot of > servers and/or clients won't negotiate that correctly and only allow > both type of channels to be encrypted which is not possible to pass > through a SPI firewall. > > There are two other sorta widely implemented secure file transfer > protocols, SCP and WebDav over TLS/SSL. Either works fine through a > SPI firewall, but the consensus for file transfer (at least over the > pub net) within the financial services community appears to be > converging to FTP over ssh. Do you mean sftp, or ftp over an ssh tunnel? -Randy From andrew.wallace at rocketmail.com Thu Feb 3 15:32:12 2011 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Thu, 3 Feb 2011 13:32:12 -0800 (PST) Subject: Egypt 'hijacked Vodafone network' Message-ID: <841166.44185.qm@web59604.mail.ac4.yahoo.com> On Thu, Feb 3, 2011 at 7:48 PM, Marshall Eubanks wrote: > > On Feb 3, 2011, at 2:20 PM, andrew.wallace wrote: > >> On Thu, Feb 3, 2011 at 6:59 PM, Scott Brim wrote: >>> On 02/03/2011 10:14 EST, Marshall Eubanks wrote: >>>> >>>> On Feb 3, 2011, at 9:24 AM, andrew.wallace wrote: >>>> >>>>> Mobile phone firm Vodafone accuses the Egyptian authorities of >>>>> using its network to send pro-government text messages. >>>>> >>>>> http://www.bbc.co.uk/news/business-12357694 >>>> >>>> Here is their PR >>>> >>>> http://www.vodafone.com/content/index/press.html >>>> >>>> Note that this is entirely legal, under "the emergency powers >>>> provisions of the Telecoms Act" >>> >>> Which is legal, Vodafone's protest or the government's telling them to >>> send messages? afaik the agreement was that the operator would have >>> preloaded canned messages, agreed on in advance with the government, and >>> now the government is telling them to send out arbitrary messages they >>> compose on the spot. >>> >>> >> >> I wonder if these messages were blockable by the end-user or if they were being sent as a service announcement from Vodafone. >> >> Certainly, if the government were sending the messages under the company name then something sounds wrong about that. >> >> What I would like is to hear from someone who received the messages and what their experiences were. >> > > They were described to me as being "from Vodafone." I assumed that this meant that they were service messages. > > Marshall A text message received Sunday by an Associated Press reporter in Egypt appealed to the country's "honest and loyal men to confront the traitors and criminals and protect our people and honor." Another urged Egyptians to attend a pro-Mubarak rally in Cairo on Wednesday. The first was marked as coming from "Vodafone." The other was signed: "Egypt Lovers." http://news.yahoo.com/s/ap/20110203/ap_on_hi_te/eu_egypt_cell_phones Andrew From marka at isc.org Thu Feb 3 15:38:50 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 04 Feb 2011 08:38:50 +1100 Subject: quietly.... In-Reply-To: Your message of "Thu, 03 Feb 2011 13:17:19 CDT." <32825.1296757039@localhost> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <5CB621E0-1873-47DC-B4EE-A5E2D6E5D5B4@sackheads.org> <25915.1296675743@localhost> <20110202221825.9EF3A970315@drugs.dv.isc.org> <32825.1296757039@localhost> Message-ID: <20110203213850.EE2AD9A4F00@drugs.dv.isc.org> In message <32825.1296757039 at localhost>, Valdis.Kletnieks at vt.edu writes: > --==_Exmh_1296757039_6170P > Content-Type: text/plain; charset=us-ascii > > On Thu, 03 Feb 2011 09:18:25 +1100, Mark Andrews said: > > > Or you just filter them out in the laptop. With the proper tools you just > > ignore and RA's containing 2002:. Done that for years now. > > You're welcome to stop by and fix 30,000+ systems here, most of which we do > *not* have administrative control over because they're personal laptops and t > he > like. For most of these users, if it doesn't do the filtering correctly out > of > the box when they pick it at Best Buy or Walmart or whatever, it isn't going > to > get reconfigured. (We do provide a free "configure your box for our network" > CD > that does all this stuff and installs a site-licensed AV and all that, but no > t > everybody actually uses it, and there's no really good way to mandate it - an > d > anyhow, that's a purely local fix for a problem that's more than local). > > (We'll overlook the fun and games that start when you have a laptop that > travels between a site where 2002:: is verboten, and another where 2002:: is > the way it has to be done... Doesn't happen much.. *yet*. Good luck explaini > ng > *that* to Joe Sixpack) Joe sixpack is quite capable of learning this stuff. That said modern OS also come with connection profiles which make this even easier and will reduce the incidents of rougue RA as DHCP as connection sharing gets tied to the profile. Additionally connection sharing will shift for using 6to4 to doing prefix delegation. OS vendors that support connection sharing should also look at the IPv6 CPE draft as lots of that is applicable. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From george.herbert at gmail.com Thu Feb 3 15:39:25 2011 From: george.herbert at gmail.com (George Herbert) Date: Thu, 3 Feb 2011 13:39:25 -0800 Subject: And so it ends... In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <6E186F3F-6267-4D9B-916A-3663F13AA999@corp.arin.net> <0FDB411B-3687-40F0-B18C-4A2A28ACA51E@queuefull.net> <765C578E-3EB4-4C73-ADD8-D3A175FE5371@delong.com> <76CBE1FA-FDFF-446D-8ACA-C304D9CA2DE2@virtualized.org> <9A144B1F-323C-47A3-AA2C-F96E24A1729D@cs.fiu.edu> Message-ID: On Thu, Feb 3, 2011 at 1:27 PM, Jeffrey Lyon wrote: > Pragmatically, compelling the release of a legacy allocation to a > major company could be difficult, however, if the ARIN community were > to draft a resolution to reclaim the space it may have a profound > effect on public sentiment toward those companies. A best practice doc / resolution would be good. It's probably most practical for them to renumber into a subset of their existing space, collapsing down from the whole /8 into a /10 or something longer, which would free up 75% of that space or more. A resolution that made that practice a best practice and that asked that enterprises give a general utilization report to the public to give an idea of whether they were close to being able to do that or far from it seems harmless. It all depends on what their internal network allocation model has been all along. Hopefully sane, but we can't plan on it. -- -george william herbert george.herbert at gmail.com From mhuff at ox.com Thu Feb 3 15:41:12 2011 From: mhuff at ox.com (Matthew Huff) Date: Thu, 3 Feb 2011 16:41:12 -0500 Subject: quietly.... In-Reply-To: <20110203205956.GK24798@hezmatt.org> References: <37955.1296761312@localhost> <201102031520.26126.lowen@pari.edu> <20110203205956.GK24798@hezmatt.org> Message-ID: <483E6B0272B0284BA86D7596C40D29F9011F76964EA0@PUR-EXCH07.ox.com> SMTP is definitely not a p2p protocol in most corporate environments. In ours, all email (even ones that you would think should be host2host) go to a central "smarthost" that processes the mail, and archive it for compliance. All internal to external and external to internal email is tightly controlled and only goes through a very specific route. Again, big difference between a univerisity or ISP environment and a corporate one. > -----Original Message----- > From: Matthew Palmer [mailto:mpalmer at hezmatt.org] > Sent: Thursday, February 03, 2011 4:00 PM > To: nanog at nanog.org > Subject: Re: quietly.... > > On Thu, Feb 03, 2011 at 03:20:25PM -0500, Lamar Owen wrote: > > On Thursday, February 03, 2011 02:28:32 pm Valdis.Kletnieks at vt.edu wrote: > > > The only reason FTP works through a NAT is because the NAT has already > > > been hacked up to further mangle the data stream to make up for the > > > mangling it does. > > > > FTP is a in essence a peer-to-peer protocol, as both ends initiate TCP > > streams. I know that's nitpicking, but it is true. > > So is SMTP, by the same token. Aptly demonstrating why the term "P2P" is so > mind-alteringly stupid. > > - Matt From mike.lyon at gmail.com Thu Feb 3 15:41:15 2011 From: mike.lyon at gmail.com (Mike Lyon) Date: Thu, 3 Feb 2011 13:41:15 -0800 Subject: Egypt 'hijacked Vodafone network' In-Reply-To: <841166.44185.qm@web59604.mail.ac4.yahoo.com> References: <841166.44185.qm@web59604.mail.ac4.yahoo.com> Message-ID: That is horrible.... Next thing you know they'll be sending SMS messages to the people saying "TEXT 666 to donate 58 Egyption Pounds to support Mubarak" On Thu, Feb 3, 2011 at 1:32 PM, andrew.wallace < andrew.wallace at rocketmail.com> wrote: > On Thu, Feb 3, 2011 at 7:48 PM, Marshall Eubanks > wrote: > > > > On Feb 3, 2011, at 2:20 PM, andrew.wallace wrote: > > > >> On Thu, Feb 3, 2011 at 6:59 PM, Scott Brim > wrote: > >>> On 02/03/2011 10:14 EST, Marshall Eubanks wrote: > >>>> > >>>> On Feb 3, 2011, at 9:24 AM, andrew.wallace wrote: > >>>> > >>>>> Mobile phone firm Vodafone accuses the Egyptian authorities of > >>>>> using its network to send pro-government text messages. > >>>>> > >>>>> http://www.bbc.co.uk/news/business-12357694 > >>>> > >>>> Here is their PR > >>>> > >>>> http://www.vodafone.com/content/index/press.html > >>>> > >>>> Note that this is entirely legal, under "the emergency powers > >>>> provisions of the Telecoms Act" > >>> > >>> Which is legal, Vodafone's protest or the government's telling them to > >>> send messages? afaik the agreement was that the operator would have > >>> preloaded canned messages, agreed on in advance with the government, > and > >>> now the government is telling them to send out arbitrary messages they > >>> compose on the spot. > >>> > >>> > >> > >> I wonder if these messages were blockable by the end-user or if they > were being sent as a service announcement from Vodafone. > >> > >> Certainly, if the government were sending the messages under the company > name then something sounds wrong about that. > >> > >> What I would like is to hear from someone who received the messages and > what their experiences were. > >> > > > > They were described to me as being "from Vodafone." I assumed that this > meant that they were service messages. > > > > Marshall > > A text message received Sunday by an Associated Press reporter in Egypt > appealed to > the country's "honest and loyal men to confront the traitors and > criminals and protect our people and honor." > > Another urged Egyptians to > attend a pro-Mubarak rally in Cairo on Wednesday. The first was marked as > coming from "Vodafone." The other was signed: "Egypt Lovers." > > http://news.yahoo.com/s/ap/20110203/ap_on_hi_te/eu_egypt_cell_phones > > Andrew > > > > > > From mhuff at ox.com Thu Feb 3 15:44:07 2011 From: mhuff at ox.com (Matthew Huff) Date: Thu, 3 Feb 2011 16:44:07 -0500 Subject: quietly.... In-Reply-To: <67743569.2257.1296768703397.JavaMail.root@zimbra.network1.net> References: <483E6B0272B0284BA86D7596C40D29F9011F76964E9C@PUR-EXCH07.ox.com> <67743569.2257.1296768703397.JavaMail.root@zimbra.network1.net> Message-ID: <483E6B0272B0284BA86D7596C40D29F9011F76964EA1@PUR-EXCH07.ox.com> Oh, don't get me started on the confusion between FTP over SSH versus FTP over TLS/SSL let alone ftp over ssh versus sftp. So many vendors and users use ftps or sftp indiscriminately to describe both and neither. By sftp, I mean ftp over ssh (not tunnelled) as an alternate to scp. I would personally prefer scp to sftp, but that isn't what is being deployed by our peers. > -----Original Message----- > From: Randy Carpenter [mailto:rcarpen at network1.net] > Sent: Thursday, February 03, 2011 4:32 PM > To: Matthew Huff > Cc: nanog at nanog.org; Valdis Kletnieks > Subject: Re: quietly.... > > ----- Original Message ----- > > Well, since ssh is a straight up tcp socket protocol on a well know > > port with no gimmicks needed like FTP, yeah, I would say it isn't a > > hack. FTP over TLS/SSL is much worse. In some implementations you can > > do an non-encrypted control channel and an encrypted data channel, so > > that a SPI firewall can "hack" it through, but unfortunately a lot of > > servers and/or clients won't negotiate that correctly and only allow > > both type of channels to be encrypted which is not possible to pass > > through a SPI firewall. > > > > There are two other sorta widely implemented secure file transfer > > protocols, SCP and WebDav over TLS/SSL. Either works fine through a > > SPI firewall, but the consensus for file transfer (at least over the > > pub net) within the financial services community appears to be > > converging to FTP over ssh. > > Do you mean sftp, or ftp over an ssh tunnel? > > -Randy From brandon at rd.bbc.co.uk Thu Feb 3 15:44:58 2011 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Thu, 3 Feb 2011 21:44:58 GMT Subject: And so it ends... Message-ID: <201102032144.VAA00640@sunf10.rd.bbc.co.uk> > But are they going to go up against someone big? > > Do Lilly, DuPont and Merck need /8? HP need a /7? You decide. Make a policy proposal, if enough agree the database changes and is reflected in many ISP networks. "we route therefore you are" I imagine (ianal) they would have to sue every ISP using ARIN data, I don't see how ARIN should be sued for changing some text in their memmers database at the request of their members. If the prefix concerned wasn't in use on the net I imagine they'd have a hard time but they're probably all reading this and thinking "let's just advertise it in case someone land grabs anyway". If there were to be good reason to do this I imagine peopel would try a more friendly approach first. If the space was used in, for example, China on services that the legacy user never used and the new user never needed to contact the legacy user they'd probably not even notice. brandon From Valdis.Kletnieks at vt.edu Thu Feb 3 15:46:31 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 03 Feb 2011 16:46:31 -0500 Subject: quietly.... In-Reply-To: Your message of "Thu, 03 Feb 2011 15:20:25 EST." <201102031520.26126.lowen@pari.edu> References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> <483E6B0272B0284BA86D7596C40D29F9011F76964E94@PUR-EXCH07.ox.com> <37955.1296761312@localhost> <201102031520.26126.lowen@pari.edu> Message-ID: <48563.1296769591@localhost> On Thu, 03 Feb 2011 15:20:25 EST, Lamar Owen said: > FTP is a in essence a peer-to-peer protocol, as both ends initiate TCP streams. I know that's nitpicking, but it is true. Well, it's official - the original end-to-end design principal of the Internet is dead, deceased, and buried. Henceforth, there will be Clients, and there will be Servers, and all nodes will be permanently classified as one or the other, with no changing or intermixing of status allowed. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Thu Feb 3 15:50:38 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 03 Feb 2011 16:50:38 -0500 Subject: quietly.... In-Reply-To: Your message of "Thu, 03 Feb 2011 16:41:12 EST." <483E6B0272B0284BA86D7596C40D29F9011F76964EA0@PUR-EXCH07.ox.com> References: <37955.1296761312@localhost> <201102031520.26126.lowen@pari.edu> <20110203205956.GK24798@hezmatt.org> <483E6B0272B0284BA86D7596C40D29F9011F76964EA0@PUR-EXCH07.ox.com> Message-ID: <48808.1296769838@localhost> On Thu, 03 Feb 2011 16:41:12 EST, Matthew Huff said: > SMTP is definitely not a p2p protocol in most corporate environments. Ahem. Please quit confusing "the protocol" with "that small segment of the protocol we choose to allow/support on our network". -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Thu Feb 3 15:52:55 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 03 Feb 2011 16:52:55 -0500 Subject: And so it ends... In-Reply-To: Your message of "Thu, 03 Feb 2011 13:39:25 PST." References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <6E186F3F-6267-4D9B-916A-3663F13AA999@corp.arin.net> <0FDB411B-3687-40F0-B18C-4A2A28ACA51E@queuefull.net> <765C578E-3EB4-4C73-ADD8-D3A175FE5371@delong.com> <76CBE1FA-FDFF-446D-8ACA-C304D9CA2DE2@virtualized.org> <9A144B1F-323C-47A3-AA2C-F96E24A1729D@cs.fiu.edu> Message-ID: <48974.1296769975@localhost> On Thu, 03 Feb 2011 13:39:25 PST, George Herbert said: > It's probably most practical for them to renumber into a subset of > their existing space, collapsing down from the whole /8 into a /10 or > something longer, which would free up 75% of that space or more. And they want to go to the trouble of doing that, why, exactly? Imagine taking that to the CIO and/or budgeting people: "We want to start this $mumble-million project to renumber". What's the first question they'll ask? "What's it mean for *our* bottom line?" What's the second? "Then why do we want to spend this money?" It just ain't gonna happen till you have good answers to those. "We can spend $mumble-million renumbering into 1/4 of the space, and then sell off the other 3/4 to various entities for an estimated $mumble-million+20%". *Then* it will happen. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Thu Feb 3 15:54:49 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 03 Feb 2011 16:54:49 -0500 Subject: Egypt 'hijacked Vodafone network' In-Reply-To: Your message of "Thu, 03 Feb 2011 13:41:15 PST." References: <841166.44185.qm@web59604.mail.ac4.yahoo.com> Message-ID: <49146.1296770089@localhost> On Thu, 03 Feb 2011 13:41:15 PST, Mike Lyon said: > That is horrible.... > > Next thing you know they'll be sending SMS messages to the people saying > "TEXT 666 to donate 58 Egyption Pounds to support Mubarak" I got an e-mail this morning... "Attention: I am a consultant to the Egyptian President. I am contacting you for a possible business deal based on the present political crisis in Egypt. The conglomerate of Mobarak is ready to partner with you to help secure the resources of the president since the office of the presidency has been dissolved." -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jra at baylink.com Thu Feb 3 16:00:55 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 3 Feb 2011 17:00:55 -0500 (EST) Subject: quietly.... In-Reply-To: <48563.1296769591@localhost> Message-ID: <29708557.4649.1296770455523.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Valdis Kletnieks" > Subject: Re: quietly.... > On Thu, 03 Feb 2011 15:20:25 EST, Lamar Owen said: > > FTP is a in essence a peer-to-peer protocol, as both ends initiate > > TCP streams. I know that's nitpicking, but it is true. > > Well, it's official - the original end-to-end design principal of the > Internet is > dead, deceased, and buried. Henceforth, there will be Clients, and > there will > be Servers, and all nodes will be permanently classified as one or the > other, > with no changing or intermixing of status allowed. Wow. $ANONYMOUS_COMMENTER was right: end-to-end isn't an engineering principle, it's a religion. There's nothing inherent in v6 that breaks it, Valdis, just as there was nothing in v4 that broke it. Or NAT44. Or whatever gets deployed for NAT66. If I, as the party responsible for an *end-user edge site*, decide that I do not feel the need to support it *all the way through my edge router*, that is my choice to make. It only affects *end users under my control*, and they're my users to make that decision for. But please don't go on about how the parrot has ceased to be, ok? Cheers, -- jra From jra at baylink.com Thu Feb 3 16:01:52 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 3 Feb 2011 17:01:52 -0500 (EST) Subject: quietly.... In-Reply-To: <48808.1296769838@localhost> Message-ID: <15097721.4651.1296770512049.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Valdis Kletnieks" > On Thu, 03 Feb 2011 16:41:12 EST, Matthew Huff said: > > SMTP is definitely not a p2p protocol in most corporate > > environments. > > Ahem. Please quit confusing "the protocol" with "that small segment of > the protocol we choose to allow/support on our network". Ahem. Please quit confusing "The Internet" with "my small edge network, which I interconnect with The Internet". Cheers, -- jra From marka at isc.org Thu Feb 3 16:06:04 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 04 Feb 2011 09:06:04 +1100 Subject: quietly.... In-Reply-To: Your message of "Thu, 03 Feb 2011 19:26:11 -0000." References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <437F22E3-154B-4DD2-B37B-8BC54D116B40@delong.com> <9F2mjoD95cSNFAI6@perry.co.uk> <5A055785-D55E-47A3-87B0-58B0DE81F60E@delong.com> Message-ID: <20110203220604.A8BAE9A5102@drugs.dv.isc.org> In message , Roland Perry writes: > In article <5A055785-D55E-47A3-87B0-58B0DE81F60E at delong.com>, Owen > DeLong writes > >>> NAT provides a solution to, lets call it, enterprise multihoming. > >>> Remote office with a local Internet connection, but failover through > >>> the corporate network. > >> > >> And for home (/homeworker) networks ... eg I have a NAT box with a > >>default connection to my ADSL provider and an automatic failover to > >>3G (completely separate supplier). > >> > >> Almost everything inside my network doesn't notice when it switches over. > >> > >> Now, if only I could get it to automatically revert to ADSL when > >>it reappears - I wouldn't have to worry so much about the 3G bill. > > > >In this case in IPv6, the better choice is to have addresses on each > >host from both providers. When a provider goes away, the router should > >invalidate the prefix in the RAs. If the hosts have proper address > >selection policies, they will actually go back to the ADSL prefix as > >soon as it reappears. > > Which in turn implies that I'd have to start getting involved in DNS for > the hosts inside my network. At the moment I can ignore that and just > enter their rfc1918 address into various applications. No, you can enter their ULA if you don't want to use the DNS. For external client you enter both their external addresses in the DNS. Clients don't need to be stupid about connecting to a multi-homed server. It's just that the client developers have ignored RFC 1123's suggestions for 20+ years and there hasn't been a lot of multi-homed servers. See the following for C code that works well even when the network layer fails to report connection errors to the application. http://www.isc.org/community/blog/201101/how-to-connect-to-a-multi-homed-server-over-tcp If a application you depend apon doesn't do something like this complain to its developers. UDP is harder but not impossible. DNS is a classic example. DNS servers deal with UDP over dead network paths and has done for the last 20 years. > [This is all under Windows, of course, the sort of user I'm playing at > being doesn't use anything more sophisticated.] > > In any event, two of my applications are not IPv6 compatible, and would > require significant upgrading. And will my ADSL provider and my 3G > provider both switch to IPv6 at about the same time? You shouldn't have to care. Properly written clients will connect over whatever is available without significant delay and since you are multi-homed you really do want your clients to be properly written. If they are not complain to your vendor as they are not meeting the RFC 1123 requirements. > Unfortunately this all sounds like a lot of work, but am I a rare kind > of user? > -- > Roland Perry -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From george.herbert at gmail.com Thu Feb 3 16:09:42 2011 From: george.herbert at gmail.com (George Herbert) Date: Thu, 3 Feb 2011 14:09:42 -0800 Subject: And so it ends... In-Reply-To: <48974.1296769975@localhost> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <6E186F3F-6267-4D9B-916A-3663F13AA999@corp.arin.net> <0FDB411B-3687-40F0-B18C-4A2A28ACA51E@queuefull.net> <765C578E-3EB4-4C73-ADD8-D3A175FE5371@delong.com> <76CBE1FA-FDFF-446D-8ACA-C304D9CA2DE2@virtualized.org> <9A144B1F-323C-47A3-AA2C-F96E24A1729D@cs.fiu.edu> <48974.1296769975@localhost> Message-ID: On Thu, Feb 3, 2011 at 1:52 PM, wrote: > On Thu, 03 Feb 2011 13:39:25 PST, George Herbert said: > >> It's probably most practical for them to renumber into a subset of >> their existing space, collapsing down from the whole /8 into a /10 or >> something longer, which would free up 75% of that space or more. > > And they want to go to the trouble of doing that, why, exactly? > > Imagine taking that to the CIO and/or budgeting people: "We want to start this > $mumble-million project to renumber". ?What's the first question they'll ask? > "What's it mean for *our* bottom line?" What's the second? "Then why do we want > to spend this money?" > > It just ain't gonna happen till ?you have good answers to those. "We can spend > $mumble-million renumbering into 1/4 of the space, and then sell off the other > 3/4 to various entities for an estimated $mumble-million+20%". > > *Then* it will happen. Some of them won't have to renumber at all to collapse into a subset (from what I was told). Some are spaghetti messes. Putting out a policy best practice that says "You really should do this, please" doesn't force multi-million-dollar projects, no. But might prompt returns where no renumbering is required. And can hopefully encourage network revamps going forwards to recover space as they go, if it's not too painful. The alternate method - to just openly commoditize it - will also work, but will incur significant political pushback within the community. I don't know which path is ultimately more productive over long timescales. I think that a best practice asking for handbacks is at least harmless in the nearterm. If we need time to overcome opposition to commoditization on our side of the fence, then that should start now, but we can't plan for overcoming that on a particular schedule. Given that APNIC hits their wall in 6-7 months-ish, I don't know that we can move quickly enough, but someone needs to start and see what happens. -- -george william herbert george.herbert at gmail.com From Valdis.Kletnieks at vt.edu Thu Feb 3 16:17:09 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 03 Feb 2011 17:17:09 -0500 Subject: quietly.... In-Reply-To: Your message of "Thu, 03 Feb 2011 17:00:55 EST." <29708557.4649.1296770455523.JavaMail.root@benjamin.baylink.com> References: <29708557.4649.1296770455523.JavaMail.root@benjamin.baylink.com> Message-ID: <50976.1296771429@localhost> On Thu, 03 Feb 2011 17:00:55 EST, Jay Ashworth said: > Wow. $ANONYMOUS_COMMENTER was right: end-to-end isn't an engineering principle, > it's a religion. No, I was commenting on the "FTP is peer-to-peer as both ends initiate connections" (which is true as far as it goes) - but when you look at the bigger context of "what protocols besides VoIP and p2p" it's important. First off, VoIP is merely one special case of peer-to-peer. The second, and more important, point is that if end-to-end is a religion, there is another, even more sizeable religion called "The Internet As A Whole Doesn't Need Any More Than The Small Subset of Protocols I Need For *MY* Network". Seems there's a lot of engineers out there that only want to make sure last year's protocols work, and are willing to totally ignore next year's. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From mhuff at ox.com Thu Feb 3 16:19:57 2011 From: mhuff at ox.com (Matthew Huff) Date: Thu, 3 Feb 2011 17:19:57 -0500 Subject: quietly.... In-Reply-To: <48563.1296769591@localhost> References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> <483E6B0272B0284BA86D7596C40D29F9011F76964E94@PUR-EXCH07.ox.com> <37955.1296761312@localhost> <201102031520.26126.lowen@pari.edu> <48563.1296769591@localhost> Message-ID: <483E6B0272B0284BA86D7596C40D29F9011F76964EA3@PUR-EXCH07.ox.com> In a corporate environment, that's the way it's been for almost 30 years. The feeling I get is that people want to re-litigate that with Ipv6, and make every desktop an end-to-end node. Not going to happen. In most corporate environments, even with sarcasm, you are right. There are clients and there are servers there are no such things as nodes. This is a major reason there is very little deployment of ipv6 within corporate networks. Things like DHCPv6 integrated with NAC/802.1x, RA Guard, etc are another. Oh, and telling everyone that all server addresses had to be dynamic and determined by your ISP (PA space) was another funny. Again, not going to happen. We have PI space and are testing Ipv6, but still waiting on consistent support from all Oses in use (Solaris, Linux and various flavors of Windows). Things like address token support (works fine in Solaris, I assume it's available somewhere in Linux but can't find it), and not available at all with Windows. > -----Original Message----- > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > Sent: Thursday, February 03, 2011 4:47 PM > To: Lamar Owen > Cc: nanog at nanog.org > Subject: Re: quietly.... > > On Thu, 03 Feb 2011 15:20:25 EST, Lamar Owen said: > > FTP is a in essence a peer-to-peer protocol, as both ends initiate TCP streams. I know that's > nitpicking, but it is true. > > Well, it's official - the original end-to-end design principal of the Internet is > dead, deceased, and buried. Henceforth, there will be Clients, and there will > be Servers, and all nodes will be permanently classified as one or the other, > with no changing or intermixing of status allowed. From lowen at pari.edu Thu Feb 3 16:25:14 2011 From: lowen at pari.edu (Lamar Owen) Date: Thu, 3 Feb 2011 17:25:14 -0500 Subject: quietly.... In-Reply-To: <20110203205956.GK24798@hezmatt.org> References: <37955.1296761312@localhost> Message-ID: <201102031725.14733.lowen@pari.edu> On Thursday, February 03, 2011 03:59:56 pm Matthew Palmer wrote: > On Thu, Feb 03, 2011 at 03:20:25PM -0500, Lamar Owen wrote: > > FTP is a in essence a peer-to-peer protocol, as both ends initiate TCP > > streams. I know that's nitpicking, but it is true. > So is SMTP, by the same token. Aptly demonstrating why the term "P2P" is so > mind-alteringly stupid. Yeah, SMTP between servers is peer-to-peer, since both ends can transmit and both ends can receive, using the same protocol, but in different sessions, unlike FTP, where one session needs two streams, and one originates at the file storage end. But it's also used as a client-server protocol between an SMTP sender and an SMTP receiver, which we commonly call the SMTP server. If it were peer-to-peer at that connection there would be no POP3 or IMAP stacks needed to go get the mail, rather, every workstation would receive its mail directly through SMTP. The peer-to-peer nature of SMTP is broken not by NAT, but by dynamically addressed and often disconnected clients, whether their IP addresses are globally routable or not. Sometimes it would be better to get a five day bounce than for the mail to be delivered to the smarthost but the client never picks it up..... There's a reason POP is the Post Office Protocol, as the addresses are then essentially PO Boxes..... But, with my apologies to Moe, Larry, and Curly: "NATagara Falls! Slowly I turned, step by step, inch by inch......" (with a subject of 'quietly' I've been wanting to quote that all thread....) Some are that knee-jerk whenever the Three Letter Acronym That Must Not Be Mentioned is writ large.... From jra at baylink.com Thu Feb 3 16:27:56 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 3 Feb 2011 17:27:56 -0500 (EST) Subject: quietly.... In-Reply-To: <50976.1296771429@localhost> Message-ID: <19942441.4657.1296772076371.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Valdis Kletnieks" > On Thu, 03 Feb 2011 17:00:55 EST, Jay Ashworth said: > > Wow. $ANONYMOUS_COMMENTER was right: end-to-end isn't an engineering > > principle, it's a religion. [ ... ] > Seems there's a lot of engineers out there that only want to make sure > last year's protocols work, and are willing to totally ignore next > year's. Perhaps. But I think a large part of our disconnect here is that there are lots of backbone-level ops listening to lots of edge-network ops, and failing to take into account that the latter group has *substantially* different constraints on their engineering decisions and practices, and that both groups' limitations are inherent in what they do. Certainly the backbone has to not mess with stuff. But that doesn't mean that edge networks should be *forbidden* from imposing their own restrictions; thos restrictions are (usually) business-based, where backbone decisions must be more engineering-based. Cheers, -- jra From mhuff at ox.com Thu Feb 3 16:28:09 2011 From: mhuff at ox.com (Matthew Huff) Date: Thu, 3 Feb 2011 17:28:09 -0500 Subject: quietly.... In-Reply-To: <50976.1296771429@localhost> References: <29708557.4649.1296770455523.JavaMail.root@benjamin.baylink.com> <50976.1296771429@localhost> Message-ID: <483E6B0272B0284BA86D7596C40D29F9011F76964EA4@PUR-EXCH07.ox.com> > Seems there's a lot of engineers out there that only want to make sure > last year's protocols work, and are willing to totally ignore next year's. It really is a different universe for University/ISP versus corporate networks. Neither is wrong or right, but both have different needs. My complaint is that my sense is that Ipv6 was designed and favors the ISP environment rather than corporate networks. A corporate network really does want to ignore next year's new hot protocol unless it makes business sense to support it. There may be regulatory reasons to block it (we are required to archive all email and instant messages) or management may decide it's a waste of time to support or management may feel it's a waste of people's work time to use. Obviously as a end-user with residential FTTH, I want something completely different from my ISP. From Valdis.Kletnieks at vt.edu Thu Feb 3 16:27:48 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 03 Feb 2011 17:27:48 -0500 Subject: quietly.... In-Reply-To: Your message of "Thu, 03 Feb 2011 17:01:52 EST." <15097721.4651.1296770512049.JavaMail.root@benjamin.baylink.com> References: <15097721.4651.1296770512049.JavaMail.root@benjamin.baylink.com> Message-ID: <51824.1296772068@localhost> On Thu, 03 Feb 2011 17:01:52 EST, Jay Ashworth said: > ----- Original Message ----- > > From: "Valdis Kletnieks" > > > On Thu, 03 Feb 2011 16:41:12 EST, Matthew Huff said: > > > SMTP is definitely not a p2p protocol in most corporate > > > environments. > > > > Ahem. Please quit confusing "the protocol" with "that small segment of > > the protocol we choose to allow/support on our network". > > Ahem. > > Please quit confusing "The Internet" with "my small edge network, which I > interconnect with The Internet". Corporations use a different version of RFC5321 that's 30% shorter and removes features they happen to not use? Or are they using the same RFC5321, but simply not using all the features? The distinction is in fact important. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jra at baylink.com Thu Feb 3 16:30:15 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 3 Feb 2011 17:30:15 -0500 (EST) Subject: quietly.... In-Reply-To: <51824.1296772068@localhost> Message-ID: <18979697.4665.1296772215500.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Valdis Kletnieks" > On Thu, 03 Feb 2011 17:01:52 EST, Jay Ashworth said: > > > Ahem. Please quit confusing "the protocol" with "that small > > > segment of > > > the protocol we choose to allow/support on our network". > > > > Ahem. > > > > Please quit confusing "The Internet" with "my small edge network, > > which I interconnect with The Internet". > > Corporations use a different version of RFC5321 that's 30% shorter and > removes features they happen to not use? Or are they using the same > RFC5321, but simply not using all the features? Probably the latter. C'mon; this isn't *your* first rodeo, either. From the viewpoint of The Internet, *my edge router* is The Node -- as long as everything gets to there ok, it's nunya damn business what I do inside. Only what comes out. That's Why I Have A Router. Cheers, -- jra From jcurran at arin.net Thu Feb 3 16:29:58 2011 From: jcurran at arin.net (John Curran) Date: Thu, 3 Feb 2011 22:29:58 +0000 Subject: And so it ends... In-Reply-To: <76CBE1FA-FDFF-446D-8ACA-C304D9CA2DE2@virtualized.org> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <6E186F3F-6267-4D9B-916A-3663F13AA999@corp.arin.net> <0FDB411B-3687-40F0-B18C-4A2A28ACA51E@queuefull.net> <765C578E-3EB4-4C73-ADD8-D3A175FE5371@delong.com> <76CBE1FA-FDFF-446D-8ACA-C304D9CA2DE2@virtualized.org> Message-ID: On Feb 3, 2011, at 3:42 PM, David Conrad wrote: > Second, neither ICANN nor the USG has (to my knowledge) declared the RIRs to be "successor registries" (whatever they are). David - ARIN succeeded Network Solutions in 1997 in the performance of IP number assignment, Autonomous System number assignment, and IN-ADDR.ARPA tasks. > However, pragmatically speaking, the folks who matter in any of this are the ISPs. The RIRs exist primarily as a means by which ISPs can avoid doing a myriad set of bilateral agreements as to who "owns" what address space to ensure uniqueness. If the RIRs reduce their value by no longer providing that service in an effective way (e.g., by doing what you suggest), I suspect the ISPs would find other entities to provide global uniqueness services. Full agreement on that point. /John From khelms at ispalliance.net Thu Feb 3 16:31:31 2011 From: khelms at ispalliance.net (Scott Helms) Date: Thu, 03 Feb 2011 17:31:31 -0500 Subject: quietly.... In-Reply-To: <19942441.4657.1296772076371.JavaMail.root@benjamin.baylink.com> References: <19942441.4657.1296772076371.JavaMail.root@benjamin.baylink.com> Message-ID: <4D4B2CC3.2070000@ispalliance.net> > But that doesn't mean that edge networks should be *forbidden* from imposing > their own restrictions; thos restrictions are (usually) business-based, where > backbone decisions must be more engineering-based. > > Cheers, > -- jra > > Well said, edge needs are virtually always dependent on client demands/realities and while they don't always mesh with elegant engineering they are just as vital. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From jra at baylink.com Thu Feb 3 16:32:48 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 3 Feb 2011 17:32:48 -0500 (EST) Subject: quietly.... In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9011F76964EA4@PUR-EXCH07.ox.com> Message-ID: <13180417.4669.1296772368252.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Matthew Huff" > It really is a different universe for University/ISP versus corporate > networks. Neither is wrong or right, but both have different needs. My > complaint is that my sense is that Ipv6 was designed and favors the > ISP environment rather than corporate networks. > > A corporate network really does want to ignore next year's new hot > protocol unless it makes business sense to support it. There may be > regulatory reasons to block it (we are required to archive all email > and instant messages) or management may decide it's a waste of time to > support or management may feel it's a waste of people's work time to > use. Obviously as a end-user with residential FTTH, I want something > completely different from my ISP. To steal some telco terminology, and tie into my previous reply to Valdis, *what is the demarcation point*? In most cases, it's the edge router. In .edu, it's generally a departmental or resnet router, or even closer to the end workstations than that. But inside the demarc, policy and engineering may -- and nearly always will -- hew to different standards. Cheers, -- jra From bonomi at mail.r-bonomi.com Thu Feb 3 16:34:35 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Thu, 3 Feb 2011 16:34:35 -0600 (CST) Subject: And so it ends... In-Reply-To: <9A144B1F-323C-47A3-AA2C-F96E24A1729D@cs.fiu.edu> Message-ID: <201102032234.p13MYZLA069782@mail.r-bonomi.com> > Subject: Re: And so it ends... > From: Ernie Rubi > Date: Thu, 3 Feb 2011 16:08:50 -0500 > To: David Conrad > Cc: NANOG list > > Way off topic here...and into the legal arena: > > As to the monopoly classification, do you think, at least with ARIN > (since it is a US/Virginia corporation) that Sherman Act 2 (i.e. > antitrust) principles could be applied to require that it relinquish some > of the control over said IP space/database and act in a more competitive > manner? Abssolutely *NOT*. their unique status derives from the actions of a contractor "faithfully executing" it's duties on the behalf of the U.S. Gov't. 'Antitrust' does not apply to the Gov't, nor to those acting on its behalf, nor to anyone operating a government-sanctioned monopoly. > What about the other RIRs worldwide? They're outside U.S. jurisdiction. Sherman Acg 2 is irrelevant to their operation. Even _if_ they were held to be subject to U.S. jurisdiction the prior logic would apply to them as well. > I'm not an antitrust > lawyer, Obvously. > but there may be an issue there. nope. > > No. First, "IANA" does not exist. The term "IANA" now refers to a > > series of functions currently performed under contract from the US > > Dept. of Commerce, NTIA by ICANN. As such it can't declare anything. > From jbates at brightok.net Thu Feb 3 16:37:06 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 03 Feb 2011 16:37:06 -0600 Subject: quietly.... In-Reply-To: <50976.1296771429@localhost> References: <29708557.4649.1296770455523.JavaMail.root@benjamin.baylink.com> <50976.1296771429@localhost> Message-ID: <4D4B2E12.5000504@brightok.net> On 2/3/2011 4:17 PM, Valdis.Kletnieks at vt.edu wrote: > Seems there's a lot of engineers out there that only want to make sure > last year's protocols work, and are willing to totally ignore next year's. To give them respect, they do have the job of making what currently works keep working in the way they originally engineered them to. Switching to IPv6 should not have had to require any changes from IPv4 outside of a larger address and some minor protocol differences. The support tools to enhance IPv6 beyond IPv4 should be the icing. For example. The CPE side of things and how chaining DHCPv6-PD is still an unfinished product, yet we are saying that everyone should be a go. There are too many configurations and setups out there to make it worth smoothly. We are taking a step backwards from how we do things in IPv4. I'm all for doing away with NAT on CPEs, but the work should have been completed before now on how to properly handle CPEs. The Imperial Geniuses apparently forgot. As for corporate networks, NAT is perfectly fine and they can use it until they need the new protocols we develop. Then they'll have to adapt, but they'll at least already have some of the IPv6 work done. Jack From jgreco at ns.sol.net Thu Feb 3 16:42:15 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 3 Feb 2011 16:42:15 -0600 (CST) Subject: quietly.... In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9011F76964EA4@PUR-EXCH07.ox.com> Message-ID: <201102032242.p13MgFsb046559@aurora.sol.net> > > Seems there's a lot of engineers out there that only want to make sure > > last year's protocols work, and are willing to totally ignore next year's= > . > > It really is a different universe for University/ISP versus corporate netw= > orks. Neither is wrong or right, but both have different needs. My complain= > t is that my sense is that Ipv6 was designed and favors the ISP environment= > rather than corporate networks. > > A corporate network really does want to ignore next year's new hot protocol= > unless it makes business sense to support it. There may be regulatory reas= > ons to block it (we are required to archive all email and instant messages)= > or management may decide it's a waste of time to support or management may= > feel it's a waste of people's work time to use. Obviously as a end-user wi= > th residential FTTH, I want something completely different from my ISP. This is not necessarily a good reason for taking business policies and using them to engineer a network that _cannot_ work with next year's new hot protocol. If we rewind ten years, you might find that the IP component of many business networks was merely another protocol stack alongside their existing one and a Socks proxy connecting to the Internet which was set up to "enforce policy"; I cannot recall having seen one of these setups survive the last decade. It seemed like a great idea at the time, but didn't really allow for many of the new technologies that businesses now use and rely on. Of course, the best consultants will advise you to implement that type of "great idea", because it means that they'll be seeing you again in a few years when you want your network to support that next new hot protocol. It may be better, however, and also simultaneously less disruptive in the long run, to engineer a network that *can* implement that next, new hot protocol and just use firewall policy to prevent it. ... 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. From Valdis.Kletnieks at vt.edu Thu Feb 3 16:47:44 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 03 Feb 2011 17:47:44 -0500 Subject: quietly.... In-Reply-To: Your message of "Thu, 03 Feb 2011 17:25:14 EST." <201102031725.14733.lowen@pari.edu> References: <37955.1296761312@localhost> <201102031520.26126.lowen@pari.edu> <20110203205956.GK24798@hezmatt.org> <201102031725.14733.lowen@pari.edu> Message-ID: <53353.1296773264@localhost> On Thu, 03 Feb 2011 17:25:14 EST, Lamar Owen said: > If it were peer-to-peer at that connection there would be no POP3 or IMAP > stacks needed to go get the mail, rather, every workstation would receive its > mail directly through SMTP. ETRN (RFC1985) FTW. Just because you don't use it, or don't realize it's there, doesn't mean the protocol doesn't already support it. (Of course, the operational problem with ETRN is that it in fact *does* implement "every workstation gets its mail directly through SMTP", when the actual need is "every *mail recipient*". POP included that whole concept of USER/PASS so you could snarf down the mail queued for one recipient, not one workstation.) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From owen at delong.com Thu Feb 3 16:53:12 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 3 Feb 2011 14:53:12 -0800 Subject: And so it ends... In-Reply-To: <4D4AF0C5.1020000@steadfast.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <6E186F3F-6267-4D9B-916A-3663F13AA999@corp.arin.net> <0FDB411B-3687-40F0-B18C-4A2A28ACA51E@queuefull.net> <8CB83F29-CE39-4775-84E0-8F57A932225D@arin.net> <4D4AF0C5.1020000@steadfast.net> Message-ID: On Feb 3, 2011, at 10:15 AM, Kevin Stange wrote: > On 02/03/2011 11:41 AM, Jeffrey Lyon wrote: >> I'm not inclined to believe that ARIN members will collectively agree >> on anything significant, so the policy process is a lot like U.S. >> government (not a lot getting done). > > ARIN members don't make binding votes on individual policy actions, they > elect the Advisory Council and Board of ARIN. ARIN solicits policy > proposals and takes feedback and general counts of yea and nay votes for > those proposals before deciding whether to adopt them. > Those advisory votes are by the community, not the membership as well. Owen From lowen at pari.edu Thu Feb 3 16:59:36 2011 From: lowen at pari.edu (Lamar Owen) Date: Thu, 3 Feb 2011 17:59:36 -0500 Subject: quietly.... In-Reply-To: <18979697.4665.1296772215500.JavaMail.root@benjamin.baylink.com> References: <18979697.4665.1296772215500.JavaMail.root@benjamin.baylink.com> Message-ID: <201102031759.37012.lowen@pari.edu> On Thursday, February 03, 2011 05:30:15 pm Jay Ashworth wrote: > C'mon; this isn't *your* first rodeo, either. From the viewpoint of > The Internet, *my edge router* is The Node Isn't that where this thing all started, with ARPAnet 'routers' on those leased lines? End-to-end is in reality, these days, AS-to-AS. Beyond that, each AS can do whatever it wants with those packets; if it wants to insert the full text of the Niagara Falls skit (with copyright owner's permission) into every packet, it can do that, and no other AS can make it do differently. Sure, it would be nice in ways to have full end to end at the individual host level, everybody has static addresses and domain names are free and address space at the /64 level is portable to kingdom come and back without routing table bloat.... NAT in IPv4 came about because people were doing it, and the standards were after the fact. Deja Vu, all over again. Make it easy to do what people want to do, but without NAT, perhaps overloading, port-translating NAT66 won't get traction. From bensons at queuefull.net Thu Feb 3 16:56:17 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Thu, 3 Feb 2011 16:56:17 -0600 Subject: And so it ends... In-Reply-To: <201102032234.p13MYZLA069782@mail.r-bonomi.com> References: <201102032234.p13MYZLA069782@mail.r-bonomi.com> Message-ID: <2E870E04-168C-49F5-90CD-388848977B3A@queuefull.net> On Feb 3, 2011, at 4:34 PM, Robert Bonomi wrote: > Abssolutely *NOT*. their unique status derives from the actions of a > contractor "faithfully executing" it's duties on the behalf of the U.S. > Gov't. 'Antitrust' does not apply to the Gov't, nor to those acting > on its behalf, nor to anyone operating a government-sanctioned monopoly. Maybe that applies to ICANN. But how does it apply to ARIN? -Benson From bensons at queuefull.net Thu Feb 3 17:05:16 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Thu, 3 Feb 2011 17:05:16 -0600 Subject: And so it ends... In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <6E186F3F-6267-4D9B-916A-3663F13AA999@corp.arin.net> <0FDB411B-3687-40F0-B18C-4A2A28ACA51E@queuefull.net> <765C578E-3EB4-4C73-ADD8-D3A175FE5371@delong.com> <76CBE1FA-FDFF-446D-8ACA-C304D9CA2DE2@virtualized.org> Message-ID: On Feb 3, 2011, at 4:29 PM, John Curran wrote: > On Feb 3, 2011, at 3:42 PM, David Conrad wrote: > >> Second, neither ICANN nor the USG has (to my knowledge) declared the RIRs to be "successor registries" (whatever they are). > > David - ARIN succeeded Network Solutions in 1997 in the performance of IP number assignment, Autonomous System number assignment, and IN-ADDR.ARPA tasks. I succeeded my father. That fact does not automatically grant me any authority of his - it has to be legally provided for (e.g. inherited per the law) if I'm to claim it legitimately. Does ARIN have a privileged legal status as a result of their formation by NetSol, by contract with IANA or the US Govt, or otherwise? -Benson From lists at internetpolicyagency.com Thu Feb 3 17:06:55 2011 From: lists at internetpolicyagency.com (Roland Perry) Date: Thu, 3 Feb 2011 23:06:55 +0000 Subject: quietly.... In-Reply-To: <20110203220604.A8BAE9A5102@drugs.dv.isc.org> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <437F22E3-154B-4DD2-B37B-8BC54D116B40@delong.com> <9F2mjoD95cSNFAI6@perry.co.uk> <5A055785-D55E-47A3-87B0-58B0DE81F60E@delong.com> <20110203220604.A8BAE9A5102@drugs.dv.isc.org> Message-ID: In article <20110203220604.A8BAE9A5102 at drugs.dv.isc.org>, Mark Andrews writes >> In any event, two of my applications are not IPv6 compatible, and would >> require significant upgrading. And will my ADSL provider and my 3G >> provider both switch to IPv6 at about the same time? > >You shouldn't have to care. Properly written clients will connect >over whatever is available without significant delay and since you >are multi-homed I'd call it more alternate-homed. >you really do want your clients to be properly written. If they are >not complain to your vendor as they are not meeting the RFC 1123 >requirements. One client is no longer maintained (but I am very attached to it). The other is nailed inside a five-year-old VoIP box and I suspect they'll say "buy a new one". These are just my straw poll of what may be difficult for small enterprises in a change to IPv6. -- Roland Perry From jcurran at arin.net Thu Feb 3 17:09:10 2011 From: jcurran at arin.net (John Curran) Date: Thu, 3 Feb 2011 23:09:10 +0000 Subject: And so it ends... In-Reply-To: <201102032234.p13MYZLA069782@mail.r-bonomi.com> References: <201102032234.p13MYZLA069782@mail.r-bonomi.com> Message-ID: <337AF996-AAC8-4FDD-A85E-37C0D806B4F2@corp.arin.net> On Feb 3, 2011, at 5:34 PM, Robert Bonomi wrote: > > Abssolutely *NOT*. their unique status derives from the actions of a > contractor "faithfully executing" it's duties on the behalf of the U.S. > Gov't. 'Antitrust' does not apply to the Gov't, nor to those acting > on its behalf, nor to anyone operating a government-sanctioned monopoly. Robert - To be clear, ARIN was formed by the Internet operator community to perform these Internet Registry functions. While the USG acknowledged its formation and facilitated the transition of the performance of these functions to ARIN, ARIN is not performing these duties under USG contract. I have no view on the question to which you replied, but want to be certain everyone has clear facts for the discussion. FYI, /John John Curran President and CEO ARIN From drais at icantclick.org Thu Feb 3 17:14:00 2011 From: drais at icantclick.org (david raistrick) Date: Thu, 3 Feb 2011 18:14:00 -0500 (EST) Subject: quietly.... In-Reply-To: <48563.1296769591@localhost> References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> <483E6B0272B0284BA86D7596C40D29F9011F76964E94@PUR-EXCH07.ox.com> <37955.1296761312@localhost> <201102031520.26126.lowen@pari.edu> <48563.1296769591@localhost> Message-ID: On Thu, 3 Feb 2011, Valdis.Kletnieks at vt.edu wrote: > Well, it's official - the original end-to-end design principal of the > Internet is dead, deceased, and buried. Henceforth, there will be > Clients, and there will be Servers, and all nodes will be permanently > classified as one or the other, with no changing or intermixing of > status allowed. Er. That's not news. That's been the state of the art for what, 15+ years or so now? SIP (because it's peer to peer) and P2P are really the only things that actually give a damn about it. No one is going to check out their neighbors website running on their neighbors computer if the neighbor didn't make an effort to make their computer a server (by assigning DNS, running server software, etc) regardless of NAT etc etc. -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From fernando at gont.com.ar Thu Feb 3 17:17:11 2011 From: fernando at gont.com.ar (Fernando Gont) Date: Thu, 03 Feb 2011 20:17:11 -0300 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> Message-ID: <4D4B3777.8020800@gont.com.ar> On 03/02/2011 10:07 a.m., Rob Evans wrote: >> You must be kiddin'... You're considering going through this mess >> again in a few decades? > > I'm mildly surprised if you think we're going to be done with *this* > mess in a few decades. I fully agree. But planning/expecting to go through this mess *again* is insane. -- I hope the lesson has been learned, and we won't repeat history. Thanks, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From lowen at pari.edu Thu Feb 3 17:21:48 2011 From: lowen at pari.edu (Lamar Owen) Date: Thu, 3 Feb 2011 18:21:48 -0500 Subject: quietly.... In-Reply-To: <53353.1296773264@localhost> References: <37955.1296761312@localhost> Message-ID: <201102031821.49044.lowen@pari.edu> On Thursday, February 03, 2011 05:47:44 pm Valdis.Kletnieks at vt.edu wrote: > ETRN (RFC1985) FTW. POP (RFC918), and the current version, POP3 (RFC1081) both predate the ETRN RFC: by 12 and 8 years, respectively. By 1996, POP3 was so thoroughly entrenched that ETRN really didn't have a chance to replace POP3 in normal use; of course, there was the point you mention below, too, that makes it less than useful for most e-mail tasks. The ETRN portion, however, introduces the idea of a distinct server and a distinct client that the server holds state for. > (Of course, the operational problem with ETRN is that it in fact *does* > implement "every workstation gets its mail directly through SMTP", when the > actual need is "every *mail recipient*". That has its advantages for certain uses. And its distinct disadvantages, as you correctly note, for most 'normal' uses. From drais at icantclick.org Thu Feb 3 17:27:14 2011 From: drais at icantclick.org (david raistrick) Date: Thu, 3 Feb 2011 18:27:14 -0500 (EST) Subject: quietly.... In-Reply-To: <31501371.4291.1296707494566.JavaMail.root@benjamin.baylink.com> References: <31501371.4291.1296707494566.JavaMail.root@benjamin.baylink.com> Message-ID: On Wed, 2 Feb 2011, Jay Ashworth wrote: > I, personally, have been waiting to hear what happens when network techs > discover that they can't carry IP addresses around in their heads anymore. > > That sounds trivial, perhaps, but I don't think it will be. Heh. My personal hope, anyway, is that it will motivate certain software engineers (and companies) who decide that DNS isn't worthwhile to support (for x y z or no reason) will never be able to remember the new addressing schemes, and find themselves having to use DNS...and thereby adding support to their code. In which case, bring it on! :) -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From george.herbert at gmail.com Thu Feb 3 17:27:35 2011 From: george.herbert at gmail.com (George Herbert) Date: Thu, 3 Feb 2011 15:27:35 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <4D4B3777.8020800@gont.com.ar> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> Message-ID: On Thu, Feb 3, 2011 at 3:17 PM, Fernando Gont wrote: > On 03/02/2011 10:07 a.m., Rob Evans wrote: > >>> You must be kiddin'... You're considering going through this mess >>> again in a few decades? >> >> I'm mildly surprised if you think we're going to be done with *this* >> mess in a few decades. > > I fully agree. But planning/expecting to go through this mess *again* is > insane. -- I hope the lesson has been learned, and we won't repeat history. There is not yet a consensus understanding of what the problems are; that's a prerequisite to avoiding repeats. IPv4 was patched (well enough) to handle all the problems it encountered, until we hit address exhaustion. Some of the next couple of decades' problems may require another new protocol, hitting a non-address-exhaustion problem. That new problem could come out of various topology changes, inherent mobility, lots of other things. It could even come from address management (we won't likely exhaust 128 bits, but could hit configurations we can't route). Or from out of left field. -- -george william herbert george.herbert at gmail.com From owen at delong.com Thu Feb 3 17:25:09 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 3 Feb 2011 15:25:09 -0800 Subject: quietly.... In-Reply-To: <16075456.4557.1296760302037.JavaMail.root@benjamin.baylink.com> References: <16075456.4557.1296760302037.JavaMail.root@benjamin.baylink.com> Message-ID: On Feb 3, 2011, at 11:11 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Valdis Kletnieks" > >> (We'll overlook the fun and games that start when you have a laptop that >> travels between a site where 2002:: is verboten, and another where 2002:: is >> the way it has to be done... Doesn't happen much.. *yet*. Good luck explaining >> *that* to Joe Sixpack) > > With all due respect to the people who had to get it done... > > And so *this* you call "engineering"? > > Was TCP/IP this bad back in 1983, folks? > > Cheers, > -- jra In different ways, yes, it was. Owen From drais at icantclick.org Thu Feb 3 17:29:58 2011 From: drais at icantclick.org (david raistrick) Date: Thu, 3 Feb 2011 18:29:58 -0500 (EST) Subject: quietly.... In-Reply-To: References: <93FDC643-D434-4D3B-9E01-3FE5FB1080F9@delong.com> <12182006.4293.1296707692487.JavaMail.root@benjamin.baylink.com> Message-ID: On Wed, 2 Feb 2011, Jimmy Hess wrote: > SOCKS5 can be used to forward any TCP based protocol, and most UDP > protocols, Because SOCKS didn't break things worse than NAT? Really? -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From paul at paulgraydon.co.uk Thu Feb 3 17:37:55 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Thu, 03 Feb 2011 13:37:55 -1000 Subject: quietly.... In-Reply-To: <31501371.4291.1296707494566.JavaMail.root@benjamin.baylink.com> References: <31501371.4291.1296707494566.JavaMail.root@benjamin.baylink.com> Message-ID: <4D4B3C53.5080507@paulgraydon.co.uk> On 02/02/2011 06:31 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "david raistrick" >> On Tue, 1 Feb 2011, Dave Israel wrote: >> >>> responsibility. If they want to use DHCPv6, or NAT, or Packet over >>> Avian >>> Carrier to achieve that, let them. If using them causes them >>> problems, then >>> they should not use them. It really isn't the community's place to >>> force >>> people not to use tools they find useful because we do not like >>> them. >> Not to mention that when you take tools -away- from people that solve >> an existing problem, you'll get a lot of pushback. > I, personally, have been waiting to hear what happens when network techs > discover that they can't carry IP addresses around in their heads anymore. > > That sounds trivial, perhaps, but I don't think it will be. > Absolutely, it's certainly one thing I'm dreading. I know, DNS is awesome, but DNS also breaks (SysAdmin mantra: "It's a DNS problem", because if something is behaving in an unusual fashion, it's usually DNS that's at fault). I guess I'll routinely be storing a copy of the zone file in my DropBox or something as a precaution so I can access it from my phone. Paul From bensons at queuefull.net Thu Feb 3 17:38:32 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Thu, 3 Feb 2011 17:38:32 -0600 Subject: And so it ends... In-Reply-To: <58E6E7D6-00D9-42E9-BF45-41CD9D6A5BB9@corp.arin.net> References: <29938340.4577.1296763334557.JavaMail.root@benjamin.baylink.com> <58E6E7D6-00D9-42E9-BF45-41CD9D6A5BB9@corp.arin.net> Message-ID: <3C4B93EE-7629-4612-96FD-514F8720FCEC@queuefull.net> On Feb 3, 2011, at 2:22 PM, John Curran wrote: > To be clear, that's not ARIN "legally compelling an entity to cease using > a specific block of address space" We've never claimed that authority, > and I'm not aware of any entity that does claim such authority to compel > organizations to make router and system configuration changes. We do > claim authority to manage the database as part of our organizational > mission. I recognize the technical difference, but I don't think it's material in this instance. Although I'm not a lawyer, I see a few legal hazards in the position you've described. Foremost: (a) there still is potential liability in contributing to a harm (or crime) even if you're not the firsthand actor, and (b) being "community-driven" and "following policy" is not a valid legal defense. ARIN is a business league that maintains a database commonly relied upon for establishing "rights" to use addresses (or "ownership" depending on your view). ARIN may not control the networks that leverage this data, but there is responsibility in publishing it. If people act in a coordinated manner, directly as a result of data that ARIN publishes, then ARIN would be hard pressed to avoid liability. Having said that, it should be clear that I view ARIN "reclaiming" legacy addresses that aren't under contract (i.e. LRSA) as fraud, perhaps even in the legal sense of the word. It might also be considered theft by some. But outright reclaiming from ongoing address holders isn't a big concern of mine, because I doubt ARIN will go far down that path (if it goes at all). My real concern is that ARIN might refuse to recognize legacy transfers, fail to update the Whois database, issue RPKI inappropriately, and cause real damage to live networks. This would be bad for the networks that implement ARIN Whois-based policy, of course. It would also be bad for ARIN if it causes legal disputes (and costs). On that note, I'm going to take my discussion of policy to the PPML list. I'd be interested, however, in NANOG discussion of my comments on Whois, RPKI, etc. Cheers, -Benson From marka at isc.org Thu Feb 3 17:44:41 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 04 Feb 2011 10:44:41 +1100 Subject: quietly.... In-Reply-To: Your message of "Thu, 03 Feb 2011 17:30:15 CDT." <18979697.4665.1296772215500.JavaMail.root@benjamin.baylink.com> References: <18979697.4665.1296772215500.JavaMail.root@benjamin.baylink.com> Message-ID: <20110203234441.1A2CB9A9DE4@drugs.dv.isc.org> In message <18979697.4665.1296772215500.JavaMail.root at benjamin.baylink.com>, Ja y Ashworth writes: > ----- Original Message ----- > > From: "Valdis Kletnieks" > > > On Thu, 03 Feb 2011 17:01:52 EST, Jay Ashworth said: > > > > Ahem. Please quit confusing "the protocol" with "that small > > > > segment of > > > > the protocol we choose to allow/support on our network". > > > > > > Ahem. > > > > > > Please quit confusing "The Internet" with "my small edge network, > > > which I interconnect with The Internet". > > > > Corporations use a different version of RFC5321 that's 30% shorter and > > removes features they happen to not use? Or are they using the same > > RFC5321, but simply not using all the features? > > Probably the latter. > > C'mon; this isn't *your* first rodeo, either. From the viewpoint of > The Internet, *my edge router* is The Node -- as long as everything gets > to there ok, it's nunya damn business what I do inside. Only what > comes out. > > That's Why I Have A Router. Routers don't mangle packets. They route packet and decrement hop counts. > Cheers, > -- jra > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jra at baylink.com Thu Feb 3 17:59:47 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 3 Feb 2011 18:59:47 -0500 (EST) Subject: quietly.... In-Reply-To: <20110203234441.1A2CB9A9DE4@drugs.dv.isc.org> Message-ID: <4680378.4717.1296777587916.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Mark Andrews" [ me, to Valdis: ] > > C'mon; this isn't *your* first rodeo, either. From the viewpoint of > > The Internet, *my edge router* is The Node -- as long as everything > > gets to there ok, it's nunya damn business what I do inside. Only what > > comes out. > > > > That's Why I Have A Router. > > Routers don't mangle packets. They route packet and decrement hop > counts. I will remind you, Mark, that routers were originally called *gateways*. That was for a reason. Cheers, -- jra From jcurran at arin.net Thu Feb 3 17:59:32 2011 From: jcurran at arin.net (John Curran) Date: Thu, 3 Feb 2011 23:59:32 +0000 Subject: And so it ends... In-Reply-To: <3C4B93EE-7629-4612-96FD-514F8720FCEC@queuefull.net> References: <29938340.4577.1296763334557.JavaMail.root@benjamin.baylink.com> <58E6E7D6-00D9-42E9-BF45-41CD9D6A5BB9@corp.arin.net> <3C4B93EE-7629-4612-96FD-514F8720FCEC@queuefull.net> Message-ID: On Feb 3, 2011, at 6:38 PM, Benson Schliesser wrote: > Having said that, it should be clear that I view ARIN "reclaiming" legacy addresses that aren't under contract (i.e. LRSA) as fraud, perhaps even in the legal sense of the word. It might also be considered theft by some. But outright reclaiming from ongoing address holders isn't a big concern of mine, because I doubt ARIN will go far down that path (if it goes at all). My real concern is that ARIN might refuse to recognize legacy transfers, fail to update the Whois database, issue RPKI inappropriately, and cause real damage to live networks. This would be bad for the networks that implement ARIN Whois-based policy, of course. Benson - ARIN provides legacy holders with WHOIS and IN-ADDR services without charge. If a legacy holder simply wishes to make use of their resources and maintains current directory information, ARIN left them fairly undisturbed since its formation. Via the Legacy RSA, ARIN offers contractual assurances to legacy holders of ARIN providing these services, as well as certain protections from reclamation and policy changes. Note that ARIN can't allow transfers contrary to the community-developed policy, so legacy address holders who wish to do more then just use their resources (e.g. transfer them) are encouraged to get involved in the community to create policies that match their needs. /John John Curran President and CEO ARIN From marka at isc.org Thu Feb 3 18:03:40 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 04 Feb 2011 11:03:40 +1100 Subject: quietly.... In-Reply-To: Your message of "Thu, 03 Feb 2011 16:37:06 MDT." <4D4B2E12.5000504@brightok.net> References: <29708557.4649.1296770455523.JavaMail.root@benjamin.baylink.com> <50976.1296771429@localhost><4D4B2E12.5000504@brightok.net> Message-ID: <20110204000340.16AAA9A9EF3@drugs.dv.isc.org> In message <4D4B2E12.5000504 at brightok.net>, Jack Bates writes: > > > On 2/3/2011 4:17 PM, Valdis.Kletnieks at vt.edu wrote: > > Seems there's a lot of engineers out there that only want to make sure > > last year's protocols work, and are willing to totally ignore next year's. > > To give them respect, they do have the job of making what currently > works keep working in the way they originally engineered them to. > > Switching to IPv6 should not have had to require any changes from IPv4 > outside of a larger address and some minor protocol differences. The > support tools to enhance IPv6 beyond IPv4 should be the icing. > > For example. The CPE side of things and how chaining DHCPv6-PD is still > an unfinished product, yet we are saying that everyone should be a go. > There are too many configurations and setups out there to make it worth > smoothly. We are taking a step backwards from how we do things in IPv4. The protocol was done in December 2003. Any CPE vendor could have added support anytime in the last 7 years. Did we really need to specify how to daisy chain PD requests when these vendors have been daisy chaining DHCPv4 for various option without any written specification? People have been begging the CPE vendors for IPv6 support for years. > I'm all for doing away with NAT on CPEs, but the work should have been > completed before now on how to properly handle CPEs. The Imperial > Geniuses apparently forgot. Seriously. CPE vendors could have release IPv6 capable products that had a stateful firewall, DHCPv6 with prefix delegation 7 years ago. There was *nothing* stopping them except themselves. People have been retrofitting CPE devices to have this functionality for about as long as this. > As for corporate networks, NAT is perfectly fine and they can use it > until they need the new protocols we develop. Then they'll have to > adapt, but they'll at least already have some of the IPv6 work done. > > Jack > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bret at getjive.com Thu Feb 3 17:59:30 2011 From: bret at getjive.com (Bret Palsson) Date: Thu, 3 Feb 2011 16:59:30 -0700 Subject: BGP Looking glass and monitoring Message-ID: I'm interested to know what tools everyone uses for the following: Looking Glass server. BGP Monitoring BGP Management, ie. cost/preferred path management. Does anyone use tools to make changes to configurations? For example svn. How do you push changes? Manually, approval process, scripts? Currently the only thing we use is subversion to track changes in configurations. Now that we are up to around 20 routers and growing we are looking for better methods to manage our infrastructure. Thanks guys! -Bret From marka at isc.org Thu Feb 3 18:09:54 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 04 Feb 2011 11:09:54 +1100 Subject: quietly.... In-Reply-To: Your message of "Thu, 03 Feb 2011 23:06:55 -0000." References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <437F22E3-154B-4DD2-B37B-8BC54D116B40@delong.com> <9F2mjoD95cSNFAI6@perry.co.uk> <5A055785-D55E-47A3-87B0-58B0DE81F60E@delong.com> <20110203220604.A8BAE9A5102@drugs.dv.isc.org> Message-ID: <20110204000954.A64C79A9FED@drugs.dv.isc.org> In message , Roland Perry writes: > In article <20110203220604.A8BAE9A5102 at drugs.dv.isc.org>, Mark Andrews > writes > > >> In any event, two of my applications are not IPv6 compatible, and would > >> require significant upgrading. And will my ADSL provider and my 3G > >> provider both switch to IPv6 at about the same time? > > > >You shouldn't have to care. Properly written clients will connect > >over whatever is available without significant delay and since you > >are multi-homed > > I'd call it more alternate-homed. > > >you really do want your clients to be properly written. If they are > >not complain to your vendor as they are not meeting the RFC 1123 > >requirements. > > One client is no longer maintained (but I am very attached to it). The > other is nailed inside a five-year-old VoIP box and I suspect they'll > say "buy a new one". > > These are just my straw poll of what may be difficult for small > enterprises in a change to IPv6. It isn't "change to", its "add IPv6". I expect to see IPv4 used for years inside homes and enterprises where there is enough IPv4 addresses to meet the internal needs. It's external communication which needs to switch to IPv6. Internal communication just comes along for the ride. Mark > -- > Roland Perry > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From owen at delong.com Thu Feb 3 18:33:36 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 3 Feb 2011 16:33:36 -0800 Subject: And so it ends... In-Reply-To: References: <29938340.4577.1296763334557.JavaMail.root@benjamin.baylink.com> Message-ID: <8B955CB2-2152-4BA2-95BF-83709304D9D3@delong.com> On Feb 3, 2011, at 12:51 PM, Jeffrey Lyon wrote: > On Thu, Feb 3, 2011 at 3:48 PM, Ernie Rubi wrote: >> Um, I think that's what ARIN means when they say changing the registrant on a block from Entity A to Entity B means. That's effectively 'reclaiming'. >> >> As I understand it, I think they also contend that the 'community' could say to ARIN 'take back X legacy block' and that ARIN would have no choice but to do it if the 'community' wished it so (via policy process, etc). >> >> On Feb 3, 2011, at 3:28 PM, Jeffrey Lyon wrote: >> >>> I think what John Curran is trying to say is that ARIN does not have >>> the authority to reclaim any space >> >> >> > > > Perhaps i'm missing the point, but my interpretation is that legacy > holders are sovereign and have the same standing in the community as > the RIR's. The only way to get that space back is to ask nicely or for > operators to stop routing legacy space. I very seriously doubt that it > is within ARIN's mission to form policy that directly impacts > non-members. Most ARIN policies directly impact non-members. The vast majority of ARIN resource holders are non-members. Owen From jbates at brightok.net Thu Feb 3 19:10:02 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 03 Feb 2011 19:10:02 -0600 Subject: quietly.... In-Reply-To: <20110204000340.16AAA9A9EF3@drugs.dv.isc.org> References: <29708557.4649.1296770455523.JavaMail.root@benjamin.baylink.com> <50976.1296771429@localhost><4D4B2E12.5000504@brightok.net> <20110204000340.16AAA9A9EF3@drugs.dv.isc.org> Message-ID: <4D4B51EA.2030301@brightok.net> On 2/3/2011 6:03 PM, Mark Andrews wrote: > > The protocol was done in December 2003. Any CPE vendor could have > added support anytime in the last 7 years. Did we really need to > specify how to daisy chain PD requests when these vendors have been > daisy chaining DHCPv4 for various option without any written > specification? > NAT definitely made it easier. The same can't be said for DHCPv6-PD. And yes, replacing NAT with a protocol that will handle dissemination of network prefixes deserved having a standards based formula. For CPEs to work well, there must be expectations of what will happen in a number of scenarios so that they can deal with it. For example, will the CPE just hand out /64 networks behind it to other routers? Will it hand out a prefix one longer than what it received and increment up until it's out of space? How does this work in the myriad of ways home users connect things? Cheap CPE routers have come a long way over the last decade. They are probably as close to perfect as you can expect for the price. Now we're just starting over to go through the pains of trying to automate home routers. > Seriously. CPE vendors could have release IPv6 capable products > that had a stateful firewall, DHCPv6 with prefix delegation 7 years > ago. There was *nothing* stopping them except themselves. > > People have been retrofitting CPE devices to have this functionality > for about as long as this. > Prefix delegation replaces NAT, but there's no standard for how to divide it up? Sure, people have retrofit it for years. I have myself. However, even in linux, it's a very manual process and involves deciding for yourself how you will hand out prefixes behind the front router. This wasn't a concern with NAT. The most NAT had to worry about was conflicting addresses on the LAN/WAN (and most, these days, will auto renumber if necessary). Jack From owen at delong.com Thu Feb 3 19:23:26 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 3 Feb 2011 17:23:26 -0800 Subject: quietly.... In-Reply-To: References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> <483E6B0272B0284BA86D7596C40D29F9011F76964E94@PUR-EXCH07.ox.com> <37955.1296761312@localhost> <201102031520.26126.lowen@pari.edu> <48563.1296769591@localhost> Message-ID: On Feb 3, 2011, at 3:14 PM, david raistrick wrote: > On Thu, 3 Feb 2011, Valdis.Kletnieks at vt.edu wrote: > >> Well, it's official - the original end-to-end design principal of the Internet is dead, deceased, and buried. Henceforth, there will be Clients, and there will be Servers, and all nodes will be permanently classified as one or the other, with no changing or intermixing of status allowed. > > Er. That's not news. That's been the state of the art for what, 15+ years or so now? SIP (because it's peer to peer) and P2P are really the only things that actually give a damn about it. > Largely because we've been living with the tradeoff that we had to break the end-to-end model to temporarily compensate for an address shortage. Those of us that remember life before NAT would prefer not to bring this damage forward into an area of address abundance. In other words, yes, we gave up on the end-to-end model and accepted that some innovations simply wouldn't happen for a while. That doesn't mean we want to make that tradeoff or those limitations permanent. > > No one is going to check out their neighbors website running on their neighbors computer if the neighbor didn't make an effort to make their computer a server (by assigning DNS, running server software, etc) regardless of NAT etc etc. > So? That's an extremely narrow view of the potential applications of restored globally unique host addressing. Owen From marka at isc.org Thu Feb 3 19:31:23 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 04 Feb 2011 12:31:23 +1100 Subject: quietly.... In-Reply-To: Your message of "Thu, 03 Feb 2011 18:59:47 CDT." <4680378.4717.1296777587916.JavaMail.root@benjamin.baylink.com> References: <4680378.4717.1296777587916.JavaMail.root@benjamin.baylink.com> Message-ID: <20110204013123.AF0049AC07D@drugs.dv.isc.org> In message <4680378.4717.1296777587916.JavaMail.root at benjamin.baylink.com>, Jay Ashworth writes: > ----- Original Message ----- > > From: "Mark Andrews" > > [ me, to Valdis: ] > > > C'mon; this isn't *your* first rodeo, either. From the viewpoint of > > > The Internet, *my edge router* is The Node -- as long as everything > > > gets to there ok, it's nunya damn business what I do inside. Only what > > > comes out. > > > > > > That's Why I Have A Router. > > > > Routers don't mangle packets. They route packet and decrement hop > > counts. > > I will remind you, Mark, that routers were originally called *gateways*. And they didn't mangle packets. You either pass through a gateway or not. You don't have your internal organs re-arranged as you go through. > That was for a reason. > > Cheers, > -- jra > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jbates at brightok.net Thu Feb 3 19:38:42 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 03 Feb 2011 19:38:42 -0600 Subject: quietly.... In-Reply-To: <20110204013123.AF0049AC07D@drugs.dv.isc.org> References: <4680378.4717.1296777587916.JavaMail.root@benjamin.baylink.com> <20110204013123.AF0049AC07D@drugs.dv.isc.org> Message-ID: <4D4B58A2.7040603@brightok.net> On 2/3/2011 7:31 PM, Mark Andrews wrote: > And they didn't mangle packets. You either pass through a gateway > or not. You don't have your internal organs re-arranged as you go > through. Next you'll tell me that Compuserve had a real IP stack. Jack From drc at virtualized.org Thu Feb 3 19:42:01 2011 From: drc at virtualized.org (David Conrad) Date: Thu, 3 Feb 2011 15:42:01 -1000 Subject: And so it ends... In-Reply-To: <201102032234.p13MYZLA069782@mail.r-bonomi.com> References: <201102032234.p13MYZLA069782@mail.r-bonomi.com> Message-ID: Robert, On Feb 3, 2011, at 12:34 PM, Robert Bonomi wrote: > Abssolutely *NOT*. their unique status derives from the actions of a > contractor "faithfully executing" it's duties on the behalf of the U.S. > Gov't. 'Antitrust' does not apply to the Gov't, nor to those acting > on its behalf, nor to anyone operating a government-sanctioned monopoly. As far as I am aware, the USG contract is with ICANN, not ARIN (see http://www.ntia.doc.gov/ntiahome/domainname/iana/ianacontract_081406.pdf, section C.2.2.1.3). >> What about the other RIRs worldwide? > They're outside U.S. jurisdiction. Sherman Acg 2 is irrelevant to their > operation. The question was about other RIRs. Other countries have anti-monopoly/anti-cartel laws. Regards, -drc From marka at isc.org Thu Feb 3 19:50:53 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 04 Feb 2011 12:50:53 +1100 Subject: quietly.... In-Reply-To: Your message of "Thu, 03 Feb 2011 19:10:02 MDT." <4D4B51EA.2030301@brightok.net> References: <29708557.4649.1296770455523.JavaMail.root@benjamin.baylink.com> <50976.1296771429@localhost><4D4B2E12.5000504@brightok.net> <20110204000340.16AAA9A9EF3@drugs.dv.isc.org><4D4B51EA.2030301@brightok.net> Message-ID: <20110204015053.487D89AC17F@drugs.dv.isc.org> In message <4D4B51EA.2030301 at brightok.net>, Jack Bates writes: > On 2/3/2011 6:03 PM, Mark Andrews wrote: > > > > The protocol was done in December 2003. Any CPE vendor could have > > added support anytime in the last 7 years. Did we really need to > > specify how to daisy chain PD requests when these vendors have been > > daisy chaining DHCPv4 for various option without any written > > specification? > > > NAT definitely made it easier. The same can't be said for DHCPv6-PD. And > yes, replacing NAT with a protocol that will handle dissemination of > network prefixes deserved having a standards based formula. For CPEs to > work well, there must be expectations of what will happen in a number of > scenarios so that they can deal with it. For example, will the CPE just > hand out /64 networks behind it to other routers? Will it hand out a > prefix one longer than what it received and increment up until it's out > of space? How does this work in the myriad of ways home users connect > things? > > Cheap CPE routers have come a long way over the last decade. They are > probably as close to perfect as you can expect for the price. Now we're > just starting over to go through the pains of trying to automate home > routers. > > > Seriously. CPE vendors could have release IPv6 capable products > > that had a stateful firewall, DHCPv6 with prefix delegation 7 years > > ago. There was *nothing* stopping them except themselves. > > > > People have been retrofitting CPE devices to have this functionality > > for about as long as this. > > Prefix delegation replaces NAT, but there's no standard for how to > divide it up? Why does there have to be a standard way to divide it up? You fullfill the request if you can or you ask upstream for more, record the result and add a prefix to the routing table pointing at the requesting device. There done. Even with a /48 you are only going to get to 64000 routes which these devices should be able to handle. In practice it will be a lot less. If you don't have a route you send upstream. The ISP doesn't want to have 64000*customers PD leases so it will return a /48. This matches what's done with IPv4 and NATs. This was blindling obvious to me years ago and should have been to any CPE developer. > Sure, people have retrofit it for years. I have myself. > However, even in linux, it's a very manual process and involves deciding > for yourself how you will hand out prefixes behind the front router. > This wasn't a concern with NAT. The most NAT had to worry about was > conflicting addresses on the LAN/WAN (and most, these days, will auto > renumber if necessary). -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jbates at brightok.net Thu Feb 3 20:00:43 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 03 Feb 2011 20:00:43 -0600 Subject: quietly.... In-Reply-To: <20110204015053.487D89AC17F@drugs.dv.isc.org> References: <29708557.4649.1296770455523.JavaMail.root@benjamin.baylink.com> <50976.1296771429@localhost><4D4B2E12.5000504@brightok.net> <20110204000340.16AAA9A9EF3@drugs.dv.isc.org><4D4B51EA.2030301@brightok.net> <20110204015053.487D89AC17F@drugs.dv.isc.org> Message-ID: <4D4B5DCB.3090909@brightok.net> On 2/3/2011 7:50 PM, Mark Andrews wrote: > This was blindling obvious to me years ago and should have been to > any CPE developer. > It doesn't appear to be blindingly simple for the cpe-router-bis draft, which leaves it as TBD, or the cpe-router draft which also is silent. General consensus I got from v6ops was that IAIDs won't be utilized by CPE routers, which means they don't expect your requesting upstream logic. In fact, they didn't seem to like any of my ideas on versatility for handling this job, which means we'll likely have interoperability problems between CPE manufacturers. Jack From ops.lists at gmail.com Thu Feb 3 20:24:53 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 4 Feb 2011 07:54:53 +0530 Subject: And so it ends... In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> Message-ID: If you want to follow it up there's a pretty interesting thread ongoing in the ripe anti abuse working group All of the traffic from 2011 (only a few posts) .. http://ripe.net/ripe/maillists/archives/anti-abuse-wg/2011/ Start with this note here - http://ripe.net/ripe/maillists/archives/anti-abuse-wg/2011/msg00000.html - where (a few months late) I wrote in to protest Richard Cox's being removed as co-chair of the ripe anti abuse working group because he made much the same points. There was some argument that RIPE WG co-chairs are responsible to the RIPE chair / board etc and should be removed if they are overly critical of these, as richard admittedly was. Then go off far afield into various topics including whether that wg was really operational, and then the same question you asked .. what to do when the same entities acquiring /15s get themselves IPv6 netblocks? There seems to be a belief (in various posts in those threads) that v6 is so vast it just wont matter. Not sure that I share the belief but .. Anyway as this is about RIPE LIRs, those interested please join the abuse wg (link above) and chip in. --srs On Thu, Feb 3, 2011 at 10:02 PM, Jon Lewis wrote: > On Thu, 3 Feb 2011, Patrick W. Gilmore wrote: > >> On Feb 3, 2011, at 10:11 AM, Jon Lewis wrote: >> >>> The real fun's going to be over the next several years as the RIR's >>> become irrelevant in the acquisition of scarce IPv4 resources...and things >>> become less stable as lots of orgs rush to implement a strange new IP >>> version. >> >> Supposedly[*] transfers between private entities are still supposed to be >> justified to the local RIRs. ?(At least that's how it works in ARIN's area.) > > I was going to say this when I walked up to the mic at the IPv4 runout talk > yesterday morning, but sat down when they said "we're going to wrap this up > now" and ended up going and talking to the RIPE people about it. > > For a year or more, there have been RIPE region LIRs willing to lease > relatively large amounts of IPv4 to anyone willing to pay. ?The ones I've > been noticing have been "snowshoe spammers" who get their RIPE space and > then announce it in datacenters in the US...presumably on rented dedicated > servers from which they send spam. > > My point being, the leasing of IP space to non-connectivity customers is > already well established, whether it's technically permitted by the > [ir]relevant RIRs. ?I fully expect this to continue and spread. Eventually, > holders of large legacy blocks will realize they can make good money acting > as an LIR, leasing portions of their unused space to people who need it and > can't get it, want it and don't qualify, etc. > > These start-up LIRs won't be bound by RIR policies, both because in some > cases they'll be legacy space holders with no RSA with their region's RIR, > and because they won't be worried about eligibility for future RIR > allocations of v4 space...because there won't be any. > > ---------------------------------------------------------------------- > ?Jon Lewis, MCP :) ? ? ? ? ? | ?I route > ?Senior Network Engineer ? ? | ?therefore you are > ?Atlantic Net ? ? ? ? ? ? ? ?| > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > > -- Suresh Ramasubramanian (ops.lists at gmail.com) From justin.horstman at gorillanation.com Thu Feb 3 20:25:45 2011 From: justin.horstman at gorillanation.com (Justin Horstman) Date: Thu, 3 Feb 2011 18:25:45 -0800 Subject: External sanity checks In-Reply-To: <19C36902-4D62-4F3E-A4C3-6EDF72D8E62C@equinix.com> References: <844412.30168.qm@web30804.mail.mud.yahoo.com> <19C36902-4D62-4F3E-A4C3-6EDF72D8E62C@equinix.com> Message-ID: <8C164D3BAF7C7F41B9B286385037B1311909D817F7@lax-exch-fe-01.gorillanation.local> +1 vote for Gomez, they are the most advanced and most capable in this space. They are also not very cheap... ~J > -----Original Message----- > From: Greg Dendy [mailto:gdendy at equinix.com] > Sent: Thursday, February 03, 2011 10:35 AM > To: Brandon Galbraith > Cc: nanog > Subject: Re: External sanity checks > > Gomez isn't too bad either for the http side. > > http://www.gomez.com/ > > > Greg > > On Feb 3, 2011, at 10:29 AM, "Brandon Galbraith" > wrote: > > > Pingdom will do most of what you're looking for (www.pingdom.com). > We're > > quite fond of them after a bad Keynote experience. > > > > -brandon > > > > On Thu, Feb 3, 2011 at 12:04 PM, Philip Lavine > wrote: > > > >> To all, > >> > >> Does any one know a Vendor (NOT Keynote) that can do sanity checks > against > >> your web/smtp/ftp farms with pings, traceroutes, latency checks as > well as > >> application checks (GET, POST, ESMTP, etc) > >> > >> Thank you, > >> > >> Philip > >> > >> > >> > >> > >> > >> > > > > > > -- > > Brandon Galbraith > > US Voice: 630.492.0464 > From jeffrey.lyon at blacklotus.net Thu Feb 3 20:31:35 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 3 Feb 2011 21:31:35 -0500 Subject: External sanity checks In-Reply-To: <8C164D3BAF7C7F41B9B286385037B1311909D817F7@lax-exch-fe-01.gorillanation.local> References: <844412.30168.qm@web30804.mail.mud.yahoo.com> <19C36902-4D62-4F3E-A4C3-6EDF72D8E62C@equinix.com> <8C164D3BAF7C7F41B9B286385037B1311909D817F7@lax-exch-fe-01.gorillanation.local> Message-ID: On Thu, Feb 3, 2011 at 9:25 PM, Justin Horstman wrote: > +1 vote for Gomez, they are the most advanced and most capable in this space. They are also not very cheap... > > > ~J > >> -----Original Message----- >> From: Greg Dendy [mailto:gdendy at equinix.com] >> Sent: Thursday, February 03, 2011 10:35 AM >> To: Brandon Galbraith >> Cc: nanog >> Subject: Re: External sanity checks >> >> Gomez isn't too bad either for the http side. >> >> http://www.gomez.com/ >> >> >> Greg >> >> On Feb 3, 2011, at 10:29 AM, "Brandon Galbraith" >> wrote: >> >> > Pingdom will do most of what you're looking for (www.pingdom.com). >> We're >> > quite fond of them after a bad Keynote experience. >> > >> > -brandon >> > >> > On Thu, Feb 3, 2011 at 12:04 PM, Philip Lavine >> wrote: >> > >> >> To all, >> >> >> >> Does any one know a Vendor (NOT Keynote) that can do sanity checks >> against >> >> your web/smtp/ftp farms with pings, traceroutes, latency checks as >> well as >> >> application checks (GET, POST, ESMTP, etc) >> >> >> >> Thank you, >> >> >> >> Philip >> >> >> >> >> >> >> >> >> >> >> >> >> > >> > >> > -- >> > Brandon Galbraith >> > US Voice: 630.492.0464 >> > > > Pingdom has been pretty solid, only criticism is that all of their nodes are North America and Europe. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From ops.lists at gmail.com Thu Feb 3 20:32:44 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 4 Feb 2011 08:02:44 +0530 Subject: External sanity checks In-Reply-To: <8C164D3BAF7C7F41B9B286385037B1311909D817F7@lax-exch-fe-01.gorillanation.local> References: <844412.30168.qm@web30804.mail.mud.yahoo.com> <19C36902-4D62-4F3E-A4C3-6EDF72D8E62C@equinix.com> <8C164D3BAF7C7F41B9B286385037B1311909D817F7@lax-exch-fe-01.gorillanation.local> Message-ID: On Fri, Feb 4, 2011 at 7:55 AM, Justin Horstman wrote: > +1 vote for Gomez, they are the most advanced and most capable in this space. They are also not very cheap... Depends on whether you're monitoring SLA or performance from remote locations. There's also webmetrics (acquired by neustar sometime back) - http://www.webmetrics.com -- Suresh Ramasubramanian (ops.lists at gmail.com) From franck at genius.com Thu Feb 3 20:36:09 2011 From: franck at genius.com (Franck Martin) Date: Fri, 4 Feb 2011 15:36:09 +1300 (FJST) Subject: External sanity checks In-Reply-To: <4D4B045D.1020409@paulgraydon.co.uk> Message-ID: <12095298.254.1296786966316.JavaMail.franck@franck-martins-macbook-pro.local> ----- Original Message ----- > From: "Paul Graydon" > To: nanog at nanog.org > Sent: Friday, 4 February, 2011 8:39:09 AM > Subject: Re: External sanity checks > On 02/03/2011 08:04 AM, Philip Lavine wrote: > > To all, > > > > Does any one know a Vendor (NOT Keynote) that can do sanity checks > > against your web/smtp/ftp farms with pings, traceroutes, latency > > checks as well as application checks (GET, POST, ESMTP, etc) > > > > Thank you, > > > > Philip > > > Slight hijack, I'm interested in the answer to this question, but I'm > also wondering about a service that will actually phone you (or is > there > a reliable text/e-mail->phone call service?) I'd appreciate actually > being phoned overnight if something dies drastically to the outside > world! A bit different, but if you are looking for something that works a bit before the problem becomes visible to the user, check: http://www.avonsys.com/Application+Monitoring From nevin at enginehosting.com Thu Feb 3 20:37:47 2011 From: nevin at enginehosting.com (nevin at enginehosting.com) Date: Thu, 3 Feb 2011 20:37:47 -0600 (CST) Subject: External sanity checks In-Reply-To: References: <844412.30168.qm@web30804.mail.mud.yahoo.com> <19C36902-4D62-4F3E-A4C3-6EDF72D8E62C@equinix.com> <8C164D3BAF7C7F41B9B286385037B1311909D817F7@lax-exch-fe-01.gorillanation.l ocal> Message-ID: <1296787067.17598654@192.168.4.58> On Thursday, February 3, 2011 8:31pm, "Jeffrey Lyon" said: > On Thu, Feb 3, 2011 at 9:25 PM, Justin Horstman > wrote: >> +1 vote for Gomez, they are the most advanced and most capable in this space. >> They are also not very cheap... >> >> >> ~J >> >>> -----Original Message----- >>> From: Greg Dendy [mailto:gdendy at equinix.com] >>> Sent: Thursday, February 03, 2011 10:35 AM >>> To: Brandon Galbraith >>> Cc: nanog >>> Subject: Re: External sanity checks >>> >>> Gomez isn't too bad either for the http side. >>> >>> http://www.gomez.com/ >>> >>> >>> Greg >>> >>> On Feb 3, 2011, at 10:29 AM, "Brandon Galbraith" >>> wrote: >>> >>> > Pingdom will do most of what you're looking for (www.pingdom.com). >>> We're >>> > quite fond of them after a bad Keynote experience. >>> > >>> > -brandon >>> > >>> > On Thu, Feb 3, 2011 at 12:04 PM, Philip Lavine >>> wrote: >>> > >>> >> To all, >>> >> >>> >> Does any one know a Vendor (NOT Keynote) that can do sanity checks >>> against >>> >> your web/smtp/ftp farms with pings, traceroutes, latency checks as >>> well as >>> >> application checks (GET, POST, ESMTP, etc) >>> >> >>> >> Thank you, >>> >> >>> >> Philip >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> > >>> > >>> > -- >>> > Brandon Galbraith >>> > US Voice: 630.492.0464 >>> >> >> >> > > Pingdom has been pretty solid, only criticism is that all of their > nodes are North America and Europe. > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications - AS32421 > First and Leading in DDoS Protection Solutions http://www.websitepulse.com/ been around and solid for years, much more advanced than pingdom.com but pingdom.com is great for certain levels of testing. -- Nevin Lyne -- Founder / Director of Technology -- EngineHosting.com -- 888-576-HOST or 612-234-8964 From marka at isc.org Thu Feb 3 20:48:03 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 04 Feb 2011 13:48:03 +1100 Subject: quietly.... In-Reply-To: Your message of "Thu, 03 Feb 2011 20:00:43 MDT." <4D4B5DCB.3090909@brightok.net> References: <29708557.4649.1296770455523.JavaMail.root@benjamin.baylink.com> <50976.1296771429@localhost><4D4B2E12.5000504@brightok.net> <20110204000340.16AAA9A9EF3@drugs.dv.isc.org><4D4B51EA.2030301@brightok.net> <20110204015053.487D89AC17F@drugs.dv.isc.org><4D4B5DCB.3090909@brightok.net> Message-ID: <20110204024803.AC2CF9AC8FA@drugs.dv.isc.org> In message <4D4B5DCB.3090909 at brightok.net>, Jack Bates writes: > On 2/3/2011 7:50 PM, Mark Andrews wrote: > > This was blindling obvious to me years ago and should have been to > > any CPE developer. > > > It doesn't appear to be blindingly simple for the cpe-router-bis draft, > which leaves it as TBD, or the cpe-router draft which also is silent. > General consensus I got from v6ops was that IAIDs won't be utilized by > CPE routers, which means they don't expect your requesting upstream logic. Well the DHCP server has to support multiple IAID's as that is how it is spec'd. A DHCP server that doesn't do this is broken. There doesn't have to be consensus in this area because it does not matter. Different vendors can choose different solutions to how they make upstream requests. > In fact, they didn't seem to like any of my ideas on versatility for > handling this job, which means we'll likely have interoperability > problems between CPE manufacturers. > > > Jack -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jcurran at arin.net Thu Feb 3 20:50:47 2011 From: jcurran at arin.net (John Curran) Date: Fri, 4 Feb 2011 02:50:47 +0000 Subject: Internet number resource policy in the ARIN region References: <4D4B21C8.9090506@arin.net> Message-ID: <82461D2B-366E-4F2E-BC0B-B3AEC0468B38@corp.arin.net> Nanog Folks - Your participation makes a significant difference in the ARIN number resource policy, and while you may think that there's not much going on, the truth is that there are significant number of policy proposals at any given moment, and to the extent that you care about the actual policies used in number resource management, it would be very helpful if you could read and comment on policies while they are being developed. Please find attached the results of the last Advisory Council (AC) meeting; discussions of these proposals are taking place on the ARIN PPML mailing list and are open to all parties. Information on the Policy Development Process, the PPML mailing list, and the current proposals are all included in the attached message. Thanks! /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN > Date: February 3, 2011 4:44:40 PM EST To: arin-ppml at arin.net Subject: [arin-ppml] Advisory Council Meeting Results - January 2011 In accordance with the ARIN Policy Development Process (PDP), the ARIN Advisory Council (AC) held a meeting on 28 January 2011 and made decisions about several draft policies and proposals. The AC recommended that the ARIN Board of Trustees adopt the following draft policy: ARIN-2010-14: Standardize IP Reassignment Registration Requirements The AC selected the following proposals as draft policies for adoption discussion online and at the ARIN XXVII Public Policy Meeting in San Juan, Puerto Rico. Each draft policy will be posted shortly to the PPML. ARIN-prop-119. Globally Coordinated Transfer Policy ARIN-prop-120. Protecting Number Resources ARIN-prop-121. Better IPv6 Allocation for ISPs ARIN-prop-123. Reserved Pool for Critical Infrastructure ARIN-prop-127. Shared Transition Space for IPv4 Address Extension The AC added the following proposal to their docket but decided not to select it as a draft policy at this time: ARIN-prop-126. Compliance Requirement The AC abandoned the following proposals: ARIN-prop-128. Replacement of Section 4.2.4.4 ARIN-prop-129. IPv4 Addresses for Process Participants ARIN-prop-130. IPv4 Transition Reservation for Every ASN The AC abandoned ARIN-prop-128 due to opposition on the list, and because there is insufficient time to implement the proposal through the normal PDP. As a result, the proposal would need to be a Board Emergency PDP action to have any effect. The AC understands that the use of the emergency process requires that there be significant risk to ARIN should the Board allow a situation to continue. This matter does not warrant the use of the emergency process. The AC abandoned ARIN-prop-129 and ARIN-prop-130 because they violate the community principle of needs-based assignments. The PDP states, ?Any member of the community, including a proposal originator, may initiate a Discussion Petition if they are dissatisfied with the action taken by the Advisory Council regarding any specific policy proposal.? Proposals 126, 128, 129 and 130 may be petitioned (Discussion Petition) to try to change them into draft policies for adoption discussion on the Public Policy Mailing List and at the April Public Policy Meeting. The deadline to begin a petition will be five business days after the AC's draft meeting minutes are published. For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.html Draft Policy and Policy Proposal texts are available at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) _____________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From morrowc.lists at gmail.com Thu Feb 3 21:03:21 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 3 Feb 2011 22:03:21 -0500 Subject: External sanity checks In-Reply-To: <1296787067.17598654@192.168.4.58> References: <844412.30168.qm@web30804.mail.mud.yahoo.com> <19C36902-4D62-4F3E-A4C3-6EDF72D8E62C@equinix.com> <1296787067.17598654@192.168.4.58> Message-ID: not sure where these folks are in terms of deployment or meeting the OP's needs, but the owner/founder is a nanog person: so maybe you can link up with him and ask some questions? -Chris On Thu, Feb 3, 2011 at 9:37 PM, wrote: > > > On Thursday, February 3, 2011 8:31pm, "Jeffrey Lyon" said: > >> On Thu, Feb 3, 2011 at 9:25 PM, Justin Horstman >> wrote: >>> +1 vote for Gomez, they are the most advanced and most capable in this space. >>> They are also not very cheap... >>> >>> >>> ~J >>> >>>> -----Original Message----- >>>> From: Greg Dendy [mailto:gdendy at equinix.com] >>>> Sent: Thursday, February 03, 2011 10:35 AM >>>> To: Brandon Galbraith >>>> Cc: nanog >>>> Subject: Re: External sanity checks >>>> >>>> Gomez isn't too bad either for the http side. >>>> >>>> http://www.gomez.com/ >>>> >>>> >>>> Greg >>>> >>>> On Feb 3, 2011, at 10:29 AM, "Brandon Galbraith" >>>> wrote: >>>> >>>> > Pingdom will do most of what you're looking for (www.pingdom.com). >>>> We're >>>> > quite fond of them after a bad Keynote experience. >>>> > >>>> > -brandon >>>> > >>>> > On Thu, Feb 3, 2011 at 12:04 PM, Philip Lavine >>>> wrote: >>>> > >>>> >> To all, >>>> >> >>>> >> Does any one know a Vendor (NOT Keynote) that can do sanity checks >>>> against >>>> >> your web/smtp/ftp farms with pings, traceroutes, latency checks as >>>> well as >>>> >> application checks (GET, POST, ESMTP, etc) >>>> >> >>>> >> Thank you, >>>> >> >>>> >> Philip >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> > >>>> > >>>> > -- >>>> > Brandon Galbraith >>>> > US Voice: 630.492.0464 >>>> >>> >>> >>> >> >> Pingdom has been pretty solid, only criticism is that all of their >> nodes are North America and Europe. >> >> -- >> Jeffrey Lyon, Leadership Team >> jeffrey.lyon at blacklotus.net | http://www.blacklotus.net >> Black Lotus Communications - AS32421 >> First and Leading in DDoS Protection Solutions > > http://www.websitepulse.com/ been around and solid for years, much more advanced than pingdom.com but pingdom.com is great for certain levels of testing. > > -- Nevin Lyne > -- Founder / Director of Technology > -- EngineHosting.com > -- 888-576-HOST or 612-234-8964 > > > > From franck at genius.com Thu Feb 3 21:04:14 2011 From: franck at genius.com (Franck Martin) Date: Fri, 4 Feb 2011 16:04:14 +1300 (FJST) Subject: My upstream ISP does not support IPv6 In-Reply-To: <33299560.263.1296788434505.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <18699589.266.1296788654238.JavaMail.franck@franck-martins-macbook-pro.local> The biggest complaint that I hear from ISPs, is that their upstream ISP does not support IPv6 or will not provide them with a native IPv6 circuit. Is that bull? I thought the whole backbone is IPv6 now, and it is only the residential ISPs that are still figuring it out because CPE are still not there yet. Where can I get more information? Any list of peering ISPs that have IPv6 as part of their products? It seems to me the typical answer sales people say when asked about IPv6: "Gosh, this is the first time I'm asked this one". From rdobbins at arbor.net Thu Feb 3 21:10:07 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 4 Feb 2011 03:10:07 +0000 Subject: My upstream ISP does not support IPv6 In-Reply-To: <18699589.266.1296788654238.JavaMail.franck@franck-martins-macbook-pro.local> References: <18699589.266.1296788654238.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On Feb 4, 2011, at 10:04 AM, Franck Martin wrote: > Where can I get more information? There's some survey data related to this topic presented in the latest Worldwide Infrastructure Security Report, available at . ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From richard.barnes at gmail.com Thu Feb 3 21:11:40 2011 From: richard.barnes at gmail.com (Richard Barnes) Date: Thu, 3 Feb 2011 22:11:40 -0500 Subject: My upstream ISP does not support IPv6 In-Reply-To: <18699589.266.1296788654238.JavaMail.franck@franck-martins-macbook-pro.local> References: <33299560.263.1296788434505.JavaMail.franck@franck-martins-macbook-pro.local> <18699589.266.1296788654238.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: This seems ironic, given the number of ISPs I've heard say "There's no customer demand." --Richard On Thu, Feb 3, 2011 at 10:04 PM, Franck Martin wrote: > The biggest complaint that I hear from ISPs, is that their upstream ISP does not support IPv6 or will not provide them with a native IPv6 circuit. > > Is that bull? > > I thought the whole backbone is IPv6 now, and it is only the residential ISPs that are still figuring it out because CPE are still not there yet. > > Where can I get more information? Any list of peering ISPs that have IPv6 as part of their products? > > It seems to me the typical answer sales people say when asked about IPv6: "Gosh, this is the first time I'm asked this one". > From streiner at cluebyfour.org Thu Feb 3 17:17:44 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 3 Feb 2011 18:17:44 -0500 (EST) Subject: My upstream ISP does not support IPv6 In-Reply-To: <18699589.266.1296788654238.JavaMail.franck@franck-martins-macbook-pro.local> References: <18699589.266.1296788654238.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On Fri, 4 Feb 2011, Franck Martin wrote: > The biggest complaint that I hear from ISPs, is that their upstream ISP > does not support IPv6 or will not provide them with a native IPv6 > circuit. I know of a few regional ISPs that don't (yet) support IPv6. As far as carriers go, some seem to support it readily, and others seem like they're being dragged into it kicking and screaming. With the IPv4 well running dry in some sense, the people who aren't supporting it yet will have to realize sooner or later that they're swimming against the tide. > It seems to me the typical answer sales people say when asked about > IPv6: "Gosh, this is the first time I'm asked this one". In some organizations, that's an organizational problem. In others, it just means you got the wrong salesdroid... jms From jared at puck.nether.net Thu Feb 3 21:16:23 2011 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 3 Feb 2011 22:16:23 -0500 Subject: My upstream ISP does not support IPv6 In-Reply-To: <18699589.266.1296788654238.JavaMail.franck@franck-martins-macbook-pro.local> References: <18699589.266.1296788654238.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On Feb 3, 2011, at 10:04 PM, Franck Martin wrote: > The biggest complaint that I hear from ISPs, is that their upstream ISP does not support IPv6 or will not provide them with a native IPv6 circuit. > > Is that bull? > > I thought the whole backbone is IPv6 now, and it is only the residential ISPs that are still figuring it out because CPE are still not there yet. > > Where can I get more information? Any list of peering ISPs that have IPv6 as part of their products? > > It seems to me the typical answer sales people say when asked about IPv6: "Gosh, this is the first time I'm asked this one". There is a wikipedia article on this: http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_by_major_transit_providers It's not very marketing nor deep in details. There are also a variety of other sites as well with various lists that are more focused on the edge networks such as: http://www.sixxs.net/faq/connectivity/?faq=native I'm not aware of a fully comprehensive list, but it may be worthwhile to ask over on the ipv6-ops list with further details about where you are located or looking at desiring service: http://lists.cluenet.de/mailman/listinfo/ipv6-ops There's good discussion over there, and a great resource if you are looking for details on enabling IPv6. - Jared From paul at paulgraydon.co.uk Thu Feb 3 21:18:54 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Thu, 03 Feb 2011 17:18:54 -1000 Subject: My upstream ISP does not support IPv6 In-Reply-To: <18699589.266.1296788654238.JavaMail.franck@franck-martins-macbook-pro.local> References: <18699589.266.1296788654238.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4D4B701E.2060100@paulgraydon.co.uk> On 02/03/2011 05:04 PM, Franck Martin wrote: > The biggest complaint that I hear from ISPs, is that their upstream ISP does not support IPv6 or will not provide them with a native IPv6 circuit. > > Is that bull? > > I thought the whole backbone is IPv6 now, and it is only the residential ISPs that are still figuring it out because CPE are still not there yet. > > Where can I get more information? Any list of peering ISPs that have IPv6 as part of their products? > > It seems to me the typical answer sales people say when asked about IPv6: "Gosh, this is the first time I'm asked this one". I've just been trying to persuade our upstream provider that they can actually get IPv6 addresses. They seem to be operating under the belief that they can only get IPv6 addresses once they're running out of IPv4 before going through the usual justification business. It seems bizarre that they've specifically gone to the extent of testing and changing their infrastructure to ensure it's fully IPv6 capable, yet not go all the way and actually get a range or poll customers to find out if they're interested in one. I sent them this link : https://www.arin.net/resources/request/ipv6_initial_alloc.html and brought their attention to point 1. Yet to hear back from them.. Paul From morrowc.lists at gmail.com Thu Feb 3 21:22:09 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 3 Feb 2011 22:22:09 -0500 Subject: My upstream ISP does not support IPv6 In-Reply-To: References: <18699589.266.1296788654238.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On Thu, Feb 3, 2011 at 6:17 PM, Justin M. Streiner wrote: > On Fri, 4 Feb 2011, Franck Martin wrote: > >> The biggest complaint that I hear from ISPs, is that their upstream ISP >> does not support IPv6 or will not provide them with a native IPv6 circuit. > > I know of a few regional ISPs that don't (yet) support IPv6. > > As far as carriers go, some seem to support it readily, and others seem like > they're being dragged into it kicking and screaming. ?With the IPv4 well > running dry in some sense, the people who aren't supporting it yet will have > to realize sooner or later that they're swimming against the tide. 1) in which city you exist 2) in which city does IPV6 support exist for the carrier(s) you choose to do business with 3) can you get your sales-droid to actually sleep eye-pee-vee-six and sell it to you? how many times, for the simple case, has someone piped up on nanog (here) about VZB and their attempts to find someone with a clue about getting ipv6 enabled? (I can easily count 10 in the last ~4 years) The same goes for ATT and L3... I believe all of these carriers (and NTT since I see Jared responding as well) have v6 capabilities, they may hide SOME of their issues in marketting-speak: "Oh, we have that available in 75% of our pops(*)" (* in south-east oozbekistan) or "We offer ipv6 to the customers of our Mananged Internet Services network(*)" (* wholesale internet is not currently able to signup/route ipv6) Asking straight, clear, concise questions of your sales driod, finding his management when he's unable to answer satisfactorily, and parsing the answers closely is your only way forward. (I think) -Chris >> It seems to me the typical answer sales people say when asked about IPv6: >> "Gosh, this is the first time I'm asked this one". > > In some organizations, that's an organizational problem. ?In others, it just > means you got the wrong salesdroid... > > jms > > From brandon at burn.net Thu Feb 3 21:23:08 2011 From: brandon at burn.net (Brandon Applegate) Date: Thu, 3 Feb 2011 22:23:08 -0500 (EST) Subject: My upstream ISP does not support IPv6 In-Reply-To: <18699589.266.1296788654238.JavaMail.franck@franck-martins-macbook-pro.local> References: <18699589.266.1296788654238.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On Fri, 4 Feb 2011, Franck Martin wrote: > The biggest complaint that I hear from ISPs, is that their upstream ISP does not support IPv6 or will not provide them with a native IPv6 circuit. > > Is that bull? > > I thought the whole backbone is IPv6 now, and it is only the residential ISPs that are still figuring it out because CPE are still not there yet. > > Where can I get more information? Any list of peering ISPs that have IPv6 as part of their products? > > It seems to me the typical answer sales people say when asked about IPv6: "Gosh, this is the first time I'm asked this one". > I can provide anecdotal feedback on this. When we did v6 on our network - we did it to full v4 parity. I.e. if we offer v4 / HSRP redundancy / BGP full table, etc in a given site, we need to be able to do the same with v6. We acheived that. At this point I had a decent v6 network, but was isolated from the world. I had to talk to upstreams. In a nutshell, it was non-trivial. The upstreams in question will remain nameless to protect the guilty, but they are all who some would call 'tier 1'. The common themes were: - Hmm, don't know our process for that, let me send emails and 'reach out' and get back to you. - We can do it, but we have to home you to a different router. This will be a provisioning exercise and you will get new /30 (/126, etc) and new circuit ID. So it was far from simply adding v6 to our existing circuit(s) and another BGP session. It has taken months. I couldn't quite wait that long so I did a tunnel w/ BGP to Hurricane and got it up in a matter of days. At that point, at least I could traceroute somewhere :) We are just now finishing up getting native on our transit circuits. -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 7407 DC86 AA7B A57F 62D1 A715 3C63 66A1 181E 6996 "SH1-0151. This is the serial number, of our orbital gun." From joly at punkcast.com Thu Feb 3 21:30:27 2011 From: joly at punkcast.com (Joly MacFie) Date: Thu, 3 Feb 2011 22:30:27 -0500 Subject: Fwd: You Tube Problems In-Reply-To: <2da8b.6c6e6037.3a7c8a6f@aol.com> References: <2da8b.6c6e6037.3a7c8a6f@aol.com> Message-ID: This was recently posted to a mailing list I'm on from the UK. I'd laugh it off, but I've been seeing the same thing here in NYC on my Verizon DSL - a lot of the time I''m only getting around 200kpbs out of YouTube while speedtest shows I have 3mbps. Any comments? j ---------- Forwarded message ---------- From: (a uk user) For several days now I have found it impossible to view anything on You Tube properly. A few seconds & then it freezes, starts again, then freezes & so on & 0n. It's like the bad old days of "dial up" but I have had Broadband for some years & not had this problem for ages. Any advise , anybody , please ? Mike T -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org --------------------------------------------------------------- From franck at genius.com Thu Feb 3 21:37:55 2011 From: franck at genius.com (Franck Martin) Date: Fri, 4 Feb 2011 16:37:55 +1300 (FJST) Subject: You Tube Problems In-Reply-To: Message-ID: <16898807.270.1296790672357.JavaMail.franck@franck-martins-macbook-pro.local> Any relation? http://mobile.slashdot.org/story/11/02/04/0043234/Verizon-To-Throttle-High-Bandwidth-Users ----- Original Message ----- From: "Joly MacFie" To: "North American Network Operators Group" Sent: Friday, 4 February, 2011 4:30:27 PM Subject: Fwd: You Tube Problems This was recently posted to a mailing list I'm on from the UK. I'd laugh it off, but I've been seeing the same thing here in NYC on my Verizon DSL - a lot of the time I''m only getting around 200kpbs out of YouTube while speedtest shows I have 3mbps. Any comments? j From joly at punkcast.com Thu Feb 3 21:46:56 2011 From: joly at punkcast.com (Joly MacFie) Date: Thu, 3 Feb 2011 22:46:56 -0500 Subject: You Tube Problems In-Reply-To: <16898807.270.1296790672357.JavaMail.franck@franck-martins-macbook-pro.local> References: <16898807.270.1296790672357.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: I think that refers to mobile. I am talking common and garden residential 3mpbs dsl. j On Thu, Feb 3, 2011 at 10:37 PM, Franck Martin wrote: > Any relation? > > > http://mobile.slashdot.org/story/11/02/04/0043234/Verizon-To-Throttle-High-Bandwidth-Users > > ----- Original Message ----- > From: "Joly MacFie" > To: "North American Network Operators Group" > Sent: Friday, 4 February, 2011 4:30:27 PM > Subject: Fwd: You Tube Problems > > This was recently posted to a mailing list I'm on from the UK. I'd laugh it > off, but I've been seeing the same thing here in NYC on my Verizon DSL - a > lot of the time I''m only getting around 200kpbs out of YouTube while > speedtest shows I have 3mbps. > > Any comments? > > j > > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org --------------------------------------------------------------- From rcarpen at network1.net Thu Feb 3 21:54:03 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Thu, 3 Feb 2011 22:54:03 -0500 (EST) Subject: My upstream ISP does not support IPv6 In-Reply-To: Message-ID: <1127264403.2346.1296791643752.JavaMail.root@zimbra.network1.net> IPv6 from both of my upstream providers has been "coming soon" for about a year and a half. One is a very major national provider, one is a regional which is connected to numerous national carriers. The major national provider is supposed to be swapping out equipment any day now in order to support IPv6. The regional is claiming that their upstreams do not have IPv6 support yet. Their upstream providers certainly do have IPv6, but I do not know if they are not offering it to their downstream ISP customers. I don't know, but as a company that manages the internet operations for numerous ISPs, and needs to have full monitoring capability for said customers, it is frustrating not to have native IPv6. -Randy From jra at baylink.com Thu Feb 3 21:43:09 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 3 Feb 2011 22:43:09 -0500 (EST) Subject: Weekend Gedankenexperiment - The Kill Switch Message-ID: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> An armed FBI special agent shows up at your facility and tells your ranking manager to "shut down the Internet". What do you do when you get home to put it back on the air -- let's say email as a base service, since it is -- do you have the gear laying around, and how long would it take? Do you have out-of-band communications (let's say phone numbers) for enough remote contacts? Cheers, -- jra From roll at Stupi.SE Fri Feb 4 05:08:42 2011 From: roll at Stupi.SE (Peter Lothberg) Date: Fri, 4 Feb 2011 5:08:42 CET Subject: My upstream ISP does not support IPv6 In-Reply-To: Message-ID: > So it was far from simply adding v6 to our existing circuit(s) and another > BGP session. It has taken months. You don't need a new BGP session to turn on IPv6, you just need to enable IPv6 NLRI on your V4 session.. So, in theory your upstream can enable IPv6 on their side and then wait until you are ready.. It helps to have a IPv6 address on the link, but it does not need to carry the the BGP session over IPv6.. This is a feature that also simplifies your IBGP.. -P (My mother has had IPv6 since 2007, and she lives in the boonies!) From jra at baylink.com Thu Feb 3 22:10:06 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 3 Feb 2011 23:10:06 -0500 (EST) Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> Message-ID: <5817196.4787.1296792606407.JavaMail.root@benjamin.baylink.com> ---- Original Message ----- > What do you do when you get home to put it back on the air -- let's > say email as a base service, since it is -- do you have the gear laying around, > and how long would it take? Focus on this part, BTW, folks; let's ignore the politics behind the shutdown. :-) Cheers, -- jra From nenolod at systeminplace.net Thu Feb 3 22:13:35 2011 From: nenolod at systeminplace.net (William Pitcock) Date: Thu, 3 Feb 2011 22:13:35 -0600 Subject: You Tube Problems In-Reply-To: <16898807.270.1296790672357.JavaMail.franck@franck-martins-macbook-pro.local> References: <16898807.270.1296790672357.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <20110203221335.21e614d2@petrie> On Fri, 4 Feb 2011 16:37:55 +1300 (FJST) Franck Martin wrote: > Any relation? > > http://mobile.slashdot.org/story/11/02/04/0043234/Verizon-To-Throttle-High-Bandwidth-Users No, that has to do with wireless users, not DSL. Wireless is an entirely different part of the Verizon empire. William From nanog-post at rsuc.gweep.net Thu Feb 3 22:15:31 2011 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Thu, 3 Feb 2011 23:15:31 -0500 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> Message-ID: <20110204041531.GA8354@gweep.net> On Thu, Feb 03, 2011 at 10:43:09PM -0500, Jay Ashworth wrote: > An armed FBI special agent shows up at your facility and tells your ranking > manager to "shut down the Internet". legal paperwork or pound sand. [very small hurdle, pathetic how many LEOs seek to avoid it] The rest of it waits for that. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From joly at punkcast.com Thu Feb 3 22:20:24 2011 From: joly at punkcast.com (Joly MacFie) Date: Thu, 3 Feb 2011 23:20:24 -0500 Subject: You Tube Problems In-Reply-To: <20110203221335.21e614d2@petrie> References: <16898807.270.1296790672357.JavaMail.franck@franck-martins-macbook-pro.local> <20110203221335.21e614d2@petrie> Message-ID: This is only in the last week or so. What might be a possibility is that YouTube is actually choking under the demand for Egypt related footage, nearly all of which is hosted on the site. j On Thu, Feb 3, 2011 at 11:13 PM, William Pitcock wrote: > On Fri, 4 Feb 2011 16:37:55 +1300 (FJST) > Franck Martin wrote: > > > Any relation? > > > > > http://mobile.slashdot.org/story/11/02/04/0043234/Verizon-To-Throttle-High-Bandwidth-Users > > No, that has to do with wireless users, not DSL. Wireless is an > entirely different part of the Verizon empire. > > William > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org --------------------------------------------------------------- From ryan at deadfrog.net Thu Feb 3 22:46:47 2011 From: ryan at deadfrog.net (Ryan Wilkins) Date: Thu, 3 Feb 2011 22:46:47 -0600 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <5817196.4787.1296792606407.JavaMail.root@benjamin.baylink.com> References: <5817196.4787.1296792606407.JavaMail.root@benjamin.baylink.com> Message-ID: <9D145C3C-2D3A-4D73-997C-6346B6EF402A@deadfrog.net> On Feb 3, 2011, at 10:10 PM, Jay Ashworth wrote: > ---- Original Message ----- >> What do you do when you get home to put it back on the air -- let's >> say email as a base service, since it is -- do you have the gear laying around, >> and how long would it take? > > Focus on this part, BTW, folks; let's ignore the politics behind the > shutdown. :-) > So if I get what you're saying, I could have something operational from scratch in a few hours. I've got a variety of Cisco routers and switches, Linux and Mac OS X boxes in various shapes and sizes, and a five CPE + one AP 5 GHz Mikrotik RouterOS-based radio system, 802.11b/g wireless AP, 800' of Cat 5e cable, connectors, and crimpers. The radios, if well placed, could allow me to connect up several strategic locations, or perhaps use them to connect to other sources of Internet access, if available. If it really came down to it, I could probably gather enough satellite communications gear from the office to allow me to stand up satellite Internet to someone. Of course, the trick would be to talk to that "someone" to coordinate connectivity over the satellite which may be hard to do given the communications outage you described. I wouldn't be so worried about transmitting to the satellite, in this case I'd just transmit without authorization, but someone needs to be receiving my transmission and vice versa for this to be useful. At a minimum, I could enable communications between my neighbors. Regards, Ryan Wilkins From newton at internode.com.au Thu Feb 3 23:09:08 2011 From: newton at internode.com.au (Mark Newton) Date: Fri, 4 Feb 2011 05:09:08 +0000 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> Message-ID: <96503CEA-C922-47A6-9691-FCF157DF15D5@internode.com.au> On 04/02/2011, at 2:13 PM, Jay Ashworth wrote: > An armed FBI special agent shows up at your facility and tells your ranking > manager to "shut down the Internet". Turn off the room lights, salute, and shout, "Mission Accomplished." The FBI dude with the gun won't know the difference. - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From fergdawgster at gmail.com Thu Feb 3 23:13:46 2011 From: fergdawgster at gmail.com (Paul Ferguson) Date: Thu, 3 Feb 2011 21:13:46 -0800 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <96503CEA-C922-47A6-9691-FCF157DF15D5@internode.com.au> References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> <96503CEA-C922-47A6-9691-FCF157DF15D5@internode.com.au> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Feb 3, 2011 at 9:09 PM, Mark Newton wrote: > > On 04/02/2011, at 2:13 PM, Jay Ashworth wrote: > >> An armed FBI special agent shows up at your facility and tells your >> ranking manager to "shut down the Internet". > > Turn off the room lights, salute, and shout, "Mission Accomplished." > The FBI dude with the gun won't know the difference. > No. The correct answer is that in the U.S., if the Agent in question has a valid subpoena or N.S.L., you must comply. If he doesn't, then you do not have to comply. I cannot answer for any other jurisdiction. Also, make sure you have staff attorneys well-versed in Internet law -- you'll need them either way. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFNS4sCq1pz9mNUZTMRAu1EAKCMTVfXnYlbzjpyrKNfiW1grhaUgwCfQTos KDDZdBA0Xd/2cy0Wx9qf3gc= =vNsc -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson ?Engineering Architecture for the Internet ?fergdawgster(at)gmail.com ?ferg's tech blog: http://fergdawg.blogspot.com/ From mmc at internode.com.au Thu Feb 3 23:26:39 2011 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Fri, 4 Feb 2011 05:26:39 +0000 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> <96503CEA-C922-47A6-9691-FCF157DF15D5@internode.com.au> Message-ID: <15DCBF6D-423D-48F6-B9F1-5B1227AB042D@internode.com.au> On 04/02/2011, at 3:43 PM, Paul Ferguson wrote: Also, make sure you have staff attorneys well-versed in Internet law -- you'll need them either way. The Internet has it's own law now? MMC -- Matthew Moyle-Croft Peering Manager and Team Lead - Commercial and DSLAMs Internode /Agile Level 5, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc at internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 From newton at internode.com.au Thu Feb 3 23:27:52 2011 From: newton at internode.com.au (Mark Newton) Date: Fri, 4 Feb 2011 05:27:52 +0000 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> <96503CEA-C922-47A6-9691-FCF157DF15D5@internode.com.au> Message-ID: <10A940BA-6D90-4663-B942-5FFF2CB49D7A@internode.com.au> On 04/02/2011, at 3:43 PM, Paul Ferguson wrote: > On Thu, Feb 3, 2011 at 9:09 PM, Mark Newton > wrote: > >> >> On 04/02/2011, at 2:13 PM, Jay Ashworth wrote: >> >>> An armed FBI special agent shows up at your facility and tells your >>> ranking manager to "shut down the Internet". >> >> Turn off the room lights, salute, and shout, "Mission Accomplished." >> The FBI dude with the gun won't know the difference. >> > > No. The correct answer is that in the U.S., if the Agent in question has a > valid subpoena or N.S.L., you must comply. Subpoenas and NSLs are used to gather information, not to shut down telcos. They're just an enforceable request for records. Considering that politicians in the US have suggested that they need "kill switch" legislation passed before they can do it, and further considering that "kill switch" legislation doesn't currently exist, what lawful means do you anticipate an FBI special agent to rely on in making such a request? I'm not actually in the US. In a question arising from the Egypt demonstrations earlier this week, Australia's Communications Minister said he didn't think the law as written at the moment provided the government with the lawful ability to shut down telecommunications services. http://delimiter.com.au/2011/02/03/no-internet-kill-switch-for-australia-says-conroy/ - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From fergdawgster at gmail.com Thu Feb 3 23:29:19 2011 From: fergdawgster at gmail.com (Paul Ferguson) Date: Thu, 3 Feb 2011 21:29:19 -0800 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <15DCBF6D-423D-48F6-B9F1-5B1227AB042D@internode.com.au> References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> <96503CEA-C922-47A6-9691-FCF157DF15D5@internode.com.au> <15DCBF6D-423D-48F6-B9F1-5B1227AB042D@internode.com.au> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Feb 3, 2011 at 9:26 PM, Matthew Moyle-Croft wrote: > > On 04/02/2011, at 3:43 PM, Paul Ferguson wrote: > > Also, make sure you have staff attorneys well-versed in Internet law -- > you'll need them either way. > > > The Internet has it's own law now? The Internet is not immune to the law, as you should well know. In fact, the Internet seems to be a legal "proving ground" these days, so word to the wise. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFNS46qq1pz9mNUZTMRAphoAJsGW/J6Y7lrWkJF0nQMMudHmom5dQCg13a9 LSNA73S6cRpfNELRSsyApTc= =t13Y -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson ?Engineering Architecture for the Internet ?fergdawgster(at)gmail.com ?ferg's tech blog: http://fergdawg.blogspot.com/ From fergdawgster at gmail.com Thu Feb 3 23:32:07 2011 From: fergdawgster at gmail.com (Paul Ferguson) Date: Thu, 3 Feb 2011 21:32:07 -0800 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <10A940BA-6D90-4663-B942-5FFF2CB49D7A@internode.com.au> References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> <96503CEA-C922-47A6-9691-FCF157DF15D5@internode.com.au> <10A940BA-6D90-4663-B942-5FFF2CB49D7A@internode.com.au> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Feb 3, 2011 at 9:27 PM, Mark Newton wrote: > > On 04/02/2011, at 3:43 PM, Paul Ferguson wrote: > >> On Thu, Feb 3, 2011 at 9:09 PM, Mark Newton >> wrote: >> >>> >>> On 04/02/2011, at 2:13 PM, Jay Ashworth wrote: >>> >>>> An armed FBI special agent shows up at your facility and tells your >>>> ranking manager to "shut down the Internet". >>> >>> Turn off the room lights, salute, and shout, "Mission Accomplished." >>> The FBI dude with the gun won't know the difference. >>> >> >> No. The correct answer is that in the U.S., if the Agent in question has >> a valid subpoena or N.S.L., you must comply. > > Subpoenas and NSLs are used to gather information, not to shut down > telcos. They're just an enforceable request for records. > > Considering that politicians in the US have suggested that they need > "kill switch" legislation passed before they can do it, and further > considering that "kill switch" legislation doesn't currently exist, > what lawful means do you anticipate an FBI special agent to rely on > in making such a request? > > I'm not actually in the US. In a question arising from the Egypt > demonstrations earlier this week, Australia's Communications Minister > said he didn't think the law as written at the moment provided the > government with the lawful ability to shut down telecommunications > services. > http://delimiter.com.au/2011/02/03/no-internet-kill-switch-for-australia- > says-conroy/ > I share your sentiment. One of the best commentaries I have read lately on this issue was earlier today: http://www.zdnet.com/blog/government/ive-changed-my-mind-america-must-never - -allow-an-internet-kill-switch-heres-why/9982 Worth a quick read. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFNS49Qq1pz9mNUZTMRAg63AJ9XifxhugBVp9eyMrGQW7W9uKiAMACgor23 ISBUTZgvbwKKjJ5qBnJxPrg= =O3vq -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson ?Engineering Architecture for the Internet ?fergdawgster(at)gmail.com ?ferg's tech blog: http://fergdawg.blogspot.com/ From gbonser at seven.com Fri Feb 4 00:07:10 2011 From: gbonser at seven.com (George Bonser) Date: Thu, 3 Feb 2011 22:07:10 -0800 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com><96503CEA-C922-47A6-9691-FCF157DF15D5@internode.com.au> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13850@RWC-EX1.corp.seven.com> > No. The correct answer is that in the U.S., if the Agent in question > has a > valid subpoena or N.S.L., you must comply. If he doesn't, then you do > not > have to comply. > > I cannot answer for any other jurisdiction. > > Also, make sure you have staff attorneys well-versed in Internet law -- > you'll need them either way. > > - - ferg The federal government clearly has the authority to manage communications across the border of the country and between states but it would be questionable if the federal government has the authority to manage any communications completely within a state. Do they have the authority to tell me to turn down a connection that terminates within the same state that I am in? Sure, they would have the authority to tell me to turn down any international tunnels I might have running or a point-to-point that crosses state lines but I doubt they have the authority to tell me to turn down a cross-connect terminating in the same building. That would be the jurisdiction of state authority, not federal. From fergdawgster at gmail.com Fri Feb 4 00:13:34 2011 From: fergdawgster at gmail.com (Paul Ferguson) Date: Thu, 3 Feb 2011 22:13:34 -0800 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13850@RWC-EX1.corp.seven.com> References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> <96503CEA-C922-47A6-9691-FCF157DF15D5@internode.com.au> <5A6D953473350C4B9995546AFE9939EE0BC13850@RWC-EX1.corp.seven.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Feb 3, 2011 at 10:07 PM, George Bonser wrote: > > The federal government clearly has the authority to manage > communications across the border of the country and between states but > it would be questionable if the federal government has the authority to > manage any communications completely within a state. Do they have the > authority to tell me to turn down a connection that terminates within > the same state that I am in? > > Sure, they would have the authority to tell me to turn down any > international tunnels I might have running or a point-to-point that > crosses state lines but I doubt they have the authority to tell me to > turn down a cross-connect terminating in the same building. That would > be the jurisdiction of state authority, not federal. > I am making no argument to the contrary. But I should caution you that there are forces at work currently which are making motions to federalize this authority. I think we all should be deeply concerned -- some of this pandering/politicizing/scar-mongering can have ill effects. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFNS5kHq1pz9mNUZTMRAv3oAKCsa61VtcyKOiVWqGZ2mJX4eFScuACffSWB thx5VA2MbLZyGn/GzH3Qz2M= =oKF9 -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson ?Engineering Architecture for the Internet ?fergdawgster(at)gmail.com ?ferg's tech blog: http://fergdawg.blogspot.com/ From millnert at gmail.com Fri Feb 4 00:34:12 2011 From: millnert at gmail.com (Martin Millnert) Date: Fri, 4 Feb 2011 01:34:12 -0500 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> <96503CEA-C922-47A6-9691-FCF157DF15D5@internode.com.au> <10A940BA-6D90-4663-B942-5FFF2CB49D7A@internode.com.au> Message-ID: Paul, a key piece in the article is on the second page: "In fact, a lot of what the bill provides for are a very good ideas. The bill sets out the concept that cyberspace is a strategic asset for the United States and needs to be protected like any other strategic asset. This is good. The bill also acknowledges that we?re likely to come under severe attack and need to have a way to respond. We also need to have a single point of authority to make sure we respond in a coordinated way, instead of having all of America?s security forces working at cross-purposes. That single point of authority is the President. This makes sense." In all seriousness here, I wonder how the Egyptian law was worded, that allowed them to legally (let's assume so) send out propaganda text messages through all mobile operators (force operators to comply), and even shut down the Internet (force operators to comply). It is fully possible that the law says something very similar to that above, that when the state is under stress or attack (by its own storm troopers...), the state is allowed to step in to take protective measures, all in the good interest of the state, authorized by their single point of authority. This is a dangerous design, specifically as it assumes that the state under all circumstances is good which most observers will note, especially now, that states cannot be assumed to be, forever and always. Essentially, I'm not seeing the upside in assuming any state will always be good, forever and always. And it boils down to what's been discussed earlier: centralizing control of the Internet, whether political or technical, makes it less robust to failures and more prone to abuse/attack, as the value of a single point or target increases. This sub-thread is a bit off-topic, and to the thread starter I only suggest you look into the Egypt situation/operations a bit, but I guess that's where you got your inspiration for the question anyway. :) Cheers, Martin On Fri, Feb 4, 2011 at 12:32 AM, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Thu, Feb 3, 2011 at 9:27 PM, Mark Newton > wrote: > >> >> On 04/02/2011, at 3:43 PM, Paul Ferguson wrote: >> >>> On Thu, Feb 3, 2011 at 9:09 PM, Mark Newton >>> wrote: >>> >>>> >>>> On 04/02/2011, at 2:13 PM, Jay Ashworth wrote: >>>> >>>>> An armed FBI special agent shows up at your facility and tells your >>>>> ranking manager to "shut down the Internet". >>>> >>>> Turn off the room lights, salute, and shout, "Mission Accomplished." >>>> The FBI dude with the gun won't know the difference. >>>> >>> >>> No. The correct answer is that in the U.S., if the Agent in question has >>> a valid subpoena or N.S.L., you must comply. >> >> Subpoenas and NSLs are used to gather information, not to shut down >> telcos. ?They're just an enforceable request for records. >> >> Considering that politicians in the US have suggested that they need >> "kill switch" legislation passed before they can do it, and further >> considering that "kill switch" legislation doesn't currently exist, >> what lawful means do you anticipate an FBI special agent to rely on >> in making such a request? >> >> I'm not actually in the US. ?In a question arising from the Egypt >> demonstrations earlier this week, Australia's Communications Minister >> said he didn't think the law as written at the moment provided the >> government with the lawful ability to shut down telecommunications >> services. >> http://delimiter.com.au/2011/02/03/no-internet-kill-switch-for-australia- >> says-conroy/ >> > > I share your sentiment. > > One of the best commentaries I have read lately on this issue was earlier > today: > > http://www.zdnet.com/blog/government/ive-changed-my-mind-america-must-never > - -allow-an-internet-kill-switch-heres-why/9982 > > Worth a quick read. > > - - ferg > > -----BEGIN PGP SIGNATURE----- > Version: PGP Desktop 9.5.3 (Build 5003) > > wj8DBQFNS49Qq1pz9mNUZTMRAg63AJ9XifxhugBVp9eyMrGQW7W9uKiAMACgor23 > ISBUTZgvbwKKjJ5qBnJxPrg= > =O3vq > -----END PGP SIGNATURE----- > > -- > "Fergie", a.k.a. Paul Ferguson > ?Engineering Architecture for the Internet > ?fergdawgster(at)gmail.com > ?ferg's tech blog: http://fergdawg.blogspot.com/ > > From fergdawgster at gmail.com Fri Feb 4 00:38:37 2011 From: fergdawgster at gmail.com (Paul Ferguson) Date: Thu, 3 Feb 2011 22:38:37 -0800 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> <96503CEA-C922-47A6-9691-FCF157DF15D5@internode.com.au> <10A940BA-6D90-4663-B942-5FFF2CB49D7A@internode.com.au> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Feb 3, 2011 at 10:34 PM, Martin Millnert wrote: > > Essentially, I'm not seeing the upside in assuming any state will > always be good, forever and always. And it boils down to what's been > discussed earlier: centralizing control of the Internet, whether > political or technical, makes it less robust to failures and more > prone to abuse/attack, as the value of a single point or target > increases. > In this, we completely agree. And as an aside, governments will always believe that that they can control the flow of information, when push comes to shove. This has always been a hazard, and will always continue to be so. As technologists, we need to be cognizant of that fact. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFNS57lq1pz9mNUZTMRAlnAAKDoz15jmBf/N54958iUDbysbDPWkwCgx42x TAOZkWP+Dq0aOe7qzOB8WvQ= =rEH0 -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson ?Engineering Architecture for the Internet ?fergdawgster(at)gmail.com ?ferg's tech blog: http://fergdawg.blogspot.com/ From frnkblk at iname.com Fri Feb 4 00:45:09 2011 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 4 Feb 2011 00:45:09 -0600 Subject: Significant Announcement (re: IPv4) 3 February - Watch it Live! In-Reply-To: References: <1404600274.2040.1296744478836.JavaMail.root@zimbra.network1.net> Message-ID: <011901cbc437$11131620$33394260$@iname.com> It started at 9:25 am -- I normally tune in to online videos late, but I'm glad I checked earlier. Frank -----Original Message----- From: Patrick W. Gilmore [mailto:patrick at ianai.net] Sent: Thursday, February 03, 2011 9:29 AM To: NANOG list Subject: Re: Significant Announcement (re: IPv4) 3 February - Watch it Live! On Feb 3, 2011, at 9:58 AM, Antonio Querubin wrote: > On Thu, 3 Feb 2011, Randy Carpenter wrote: > >> It didn't work too bad. Does anyone know why it was pretty much over at 9:30, when they said it would start? Did they start a half-hour early or something? > > I think that was just the ceremony for handing out the last /8s and it went very quickly. The press conference starts at 10:00. It definitely started at 9:30, and it was very short. Boring actually. But that's the way it should have been. Not like this was a surprise. Even the reporter from ZDNet asked "since we gave out the last 2 to APNIC last week, why is this day important?" If ZDNet gets it, NANOG (actually *NOG) members should as well. That said, I guess just like when any long time friend leaves us, we should have a ceremony to mark the passing. -- TTFN, patrick From bonomi at mail.r-bonomi.com Fri Feb 4 00:53:27 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Fri, 4 Feb 2011 00:53:27 -0600 (CST) Subject: And so it ends... In-Reply-To: Message-ID: <201102040653.p146rRGU072389@mail.r-bonomi.com> > Subject: Re: And so it ends... > From: David Conrad > Date: Thu, 3 Feb 2011 15:42:01 -1000 > Cc: NANOG list > To: Robert Bonomi > > Robert, > > On Feb 3, 2011, at 12:34 PM, Robert Bonomi wrote: > > Abssolutely *NOT*. their unique status derives from the actions of a > > contractor "faithfully executing" it's duties on the behalf of the U.S. > > Gov't. 'Antitrust' does not apply to the Gov't, nor to those acting on > > its behalf, nor to anyone operating a government-sanctioned monopoly. > > As far as I am aware, the USG contract is with ICANN, not ARIN (see > http://www.ntia.doc.gov/ntiahome/domainname/iana/ianacontract_081406.pdf, > section C.2.2.1.3). Correct. _They_ can can delegate "as they see fit", with no requirement to provide competing alternatives. ARIN, the delegatee, is not the 'monopolist' -- the party controlling the situation -- they are just a delagatee of the party who has the monopoly position. Any action to "enforce" competition would be against the monopolist -- the authority who _delegates_ operations, ICANN. Which doesn't fly for the reasons stated. Basically, you cannot force a RIR to share with others that which they get from somebody else. To enforce competition, you would have to force the party who 'controls' the distribution to also provide the thing to the aforeentioned 'somebody else' (singular or plural). Which one cannot do under Sherman, when that party is a government actor. > > >> What about the other RIRs worldwide? > > They're outside U.S. jurisdiction. Sherman Acg 2 is irrelevant to > > their operation. > > The question was about other RIRs. Other countries have > anti-monopoly/anti-cartel laws. Irrelevant and immateral to the operation of ICANN. ICANN "controls" everything, under the auspices of the U.S.G. They have issued 'territory-protected franchises' to a limited number of parties. You cannot force the frachisee to 'share' their franchise. You have to go after the franchisor, and force -them- to issue competing franchises. Nothing prevents anyone in the 'territory' of one franchisee from attempting to do business with a diffrent franchisee. *IF* the franchisees agree among themselves not to deal with anyone that is not within the limits of their protected territory, _that_ could be a proscribed anti-competitive practice *by*the*franchisee*. IF, on the other hand, the 'grant of franchise' allows them to 'sell' only to parties in the defined territory, a refusal to deal with an extra- territorial party is -not- an anti-competitive act by the franchisee. In this situation, one would have to act against the franchisor. Who is exempt as a governent actor. > > Regards, > -drc > > From mysidia at gmail.com Fri Feb 4 00:57:46 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 4 Feb 2011 00:57:46 -0600 Subject: And so it ends... In-Reply-To: <32423678.4563.1296761643887.JavaMail.root@benjamin.baylink.com> References: <9D4F0A12-2F7A-4352-92CF-3863E7028AFE@arin.net> <32423678.4563.1296761643887.JavaMail.root@benjamin.baylink.com> Message-ID: On Thu, Feb 3, 2011 at 1:34 PM, Jay Ashworth wrote: > I strongly suspect that his question is actually "Does ARIN have any > enforceable legal authority to compel an entity to cease using a > specific block of address space, absent a contract?" ARIN has about as much to do with legally compelling an entity (who has signed no contract with ARIN) to stop using a block of IP address space, as a DNSBL has to do with compelling some random spammer to stop attempting to send spam. What keeps people using only IPs they were allocated by a registry are network policies of cooperating networks who are independent of ARIN (aside from possibly receiving an assignment of their own from ARIN). The RIRs and IANA have not been shown to have any legally enforceable authority of their own to stop an IP network from using IPs not assigned by the registry, or to prevent someone from starting to use IPs already assigned by the RIR to someone else. If you need examples; look at all the unofficial usage of 1.0.0.0/8 and 5.0.0.0/8 in private networks, that the RIRs did not attempt to compel anyone to stop. ARIN does not appear to directly legally compel any entity to cease using any specific block of address space. Neither is any other RIR in the business of 'enforcing' that only a registrant uses the IPs, nor does the registry detect if a wrong entity is using the IPs. Neither does any internet registry promise that allocations can be routed on the public internet. You can ignore the RIRs and use whatever IP addresses you want, at your own peril. That peril is not created by any RIR, however; the "peril" is the community response, and response by other organizations you rely on for connectivity. Neither does any internet registry promise that allocations will be unique on the public internet. A competing (non-cooperating) registry could have made a conflicting assignment. The RIRs can only make promises about uniqueness within their own allocations, and that they made the allocations within address space they were delegated by other registries according to their policies. The only thing a registration tells you the registrant is this particular registry administers a database containing that block of IPs, and you are the only organization currently assigned that IP space _by that registry_. If you as a network operator do not cooperate with IANA, then, perhaps you create your own registry, and just use whatever IP addresses you want. However, other networks may refuse to interconnect with you due to their policies determining that to be "improper addressing". It is not as if ARIN has a policy of looking for hijacked/unofficial announcements of address space and dispatching an army of lawyers with 'cease and decist' letters. Instead, what happens is members of the internet community investigate IP space and AS numbers before turning up new interconnections, and decide on their own, which blocks to route, based on peering network's request. Internet connected networks will find the entry in the IANA database for the /8 the requested prefix resides in, find delegation to ARIN, look in the ARIN WHOIS database, and then make a decision to route the blocks or not. The new peer might be required to show correct current registry delegation of the block, authorization from the contact listed in the database, OR merely sign a promise that they will only originate prefixes assigned to them through IANA or a RIR recognized by IANA, BUT the registry operator, ARIN itself is not the entity that imposes any specific requirement. If IP address space is legacy and not properly kept up to date in the registry under current RIR policies, then some community members might choose to reject or disallow their use by a peer, based on their own internal routing policies. Also, many members of the community rely on the ICANN delegated DNS root for all DNS lookups. the .ARPA TLD servers refer to ARIN for Reverse DNS; which is important for adequate SMTP operation, in many mail environments, lack of proper reverse DNS can lead to mail being rejected. If IP address spaces appear to be used by a person other than the registrant, the listed registrant might submit complaints to ISPs in order to act according to their network's routing policies; if their policy is to recognize ARIN's listings as the authoritative ones, they might even turn off prior users of the IP addresses. There is the RPKI pilot. In the future, members of the community may authenticate resource assignment through resource certification according to the policies of the accepted registry, through cryptographic methods. That would certainly give ICANN, IANA, and the RIRs stronger technical enforcement powers. It's even conceivable this could be used in the future to "Revoke such and such evil outside country network's Resource certificates" (so they will be forcibly disconnected) But it's still not 'legal' enforcement of resource 'ownership'. The community members still have the ability to accept use of IP address blocks outside what ARIN determines to be the proper registrations, and recourse is not really ARIN's, if someone other than the proper registrant is making use of the IP address space in disagreement with the registry. -- -JH From jcdill.lists at gmail.com Fri Feb 4 01:38:59 2011 From: jcdill.lists at gmail.com (JC Dill) Date: Thu, 03 Feb 2011 23:38:59 -0800 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> <96503CEA-C922-47A6-9691-FCF157DF15D5@internode.com.au> <10A940BA-6D90-4663-B942-5FFF2CB49D7A@internode.com.au> Message-ID: <4D4BAD13.9090301@gmail.com> On 03/02/11 10:38 PM, Paul Ferguson wrote: > > And as an aside, governments will always believe that that they can control > the flow of information, when push comes to shove. > > This has always been a hazard, and will always continue to be so. > > As technologists, we need to be cognizant of that fact. In the US, by accident (surely not by design) we are lucky that our network of networks does not have the convenient 4 chokepoints that the Egyptian network had, making it easy for the government to shut off the entier internet by putting pressure on just 4 companies. Where we *really* need to be fighting this battle is in the laws and policies that are producing a duopoly in much of the US where consumers have 2 choices, the ILEC for DSL or their local cableco for Cable Internet. As theses companies push smaller competing ISPs out of business, and as they consolidate (e.g. Cablecos buying each other up, resulting in fewer and fewer cablecos over time), we head down the direction of Egypt, where pressure on just a few companies CAN shut down the entire internet. Otherwise we end up with a few companies that will play Visa and PayPal and roll over and play dead when a government official says "Wikileaks is bad" - and equally easily will shut down their entire networks for "national security". If you *really* believe that the TSA is effective, you would be in favor of an Internet Kill Switch. If you understand that this is really security theater, and despite all the inconvenience we aren't really any safer, then you should equally be very concerned that someone ever has the power to order that the internet be "shut down" for our safety. jc From hank at efes.iucc.ac.il Fri Feb 4 01:40:29 2011 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Fri, 4 Feb 2011 09:40:29 +0200 (IST) Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <9D145C3C-2D3A-4D73-997C-6346B6EF402A@deadfrog.net> References: <5817196.4787.1296792606407.JavaMail.root@benjamin.baylink.com> <9D145C3C-2D3A-4D73-997C-6346B6EF402A@deadfrog.net> Message-ID: On Thu, 3 Feb 2011, Ryan Wilkins wrote: >> ---- Original Message ----- >>> What do you do when you get home to put it back on the air -- let's >>> say email as a base service, since it is -- do you have the gear laying around, >>> and how long would it take? >> >> Focus on this part, BTW, folks; let's ignore the politics behind the >> shutdown. :-) 1. I always keep a printed copy of all email and cellphone contacts that I normally would have access to online. 2. Critical is contacting your users. Normally your company has its mailing list but that is now down. You could set up a new list via Google groups or Yahoogroups or even your own Mailman on a VPS, but what about the list of users? Always keep an updated exported list of your users on a DoK so you can rebuild later. 3. Website: as above, keep a duplicate copy of your basic HTML pages on some DoK that you can take with you. Have the user+pswd to your registrar so you can repoint your DNS to some new site you now setup up with the new updated info about your downtime. -Hank From gbonser at seven.com Fri Feb 4 01:59:45 2011 From: gbonser at seven.com (George Bonser) Date: Thu, 3 Feb 2011 23:59:45 -0800 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: References: <5817196.4787.1296792606407.JavaMail.root@benjamin.baylink.com><9D145C3C-2D3A-4D73-997C-6346B6EF402A@deadfrog.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13856@RWC-EX1.corp.seven.com> > > 3. Website: as above, keep a duplicate copy of your basic HTML pages > on > some DoK that you can take with you. Have the user+pswd to your > registrar so you can repoint your DNS to some new site you now > setup up > with the new updated info about your downtime. > > -Hank Having a DNS server and MX host outside the borders of the country would help as well. I believe that any "attack" is likely to come from within, not from an external source. It would seem most likely to me that some malware would be spread around ahead of time that does nothing to bother the host until it is time for it to act. At that point, cutting off international links will have little/no impact and would possibly be the entire goal of the event. Shutting down the Internet would be "mission accomplished". The government should be, in my opinion, focusing its efforts on how it can best facilitate a coordination of efforts to A: profile the traffic so it can be blocked B: locate infected nodes so they can be disconnected or disinfected. The source of the attack is not likely going to be network infrastructure but instead the millions of end user devices out there. Questions like: who is monitoring traffic and noting traffic profiles of malware and developing some mechanism for distributing those traffic profiles to network operators so they can be blocked or otherwise acted on? How can that distribution channel be made "robust" in the face of a general public network breakdown? Is there a need for some sort of an operational "order wire" network that interconnects network operators as sort of an "out of band" communications path for handling emergency coordination among operators? What would be the connectivity requirements for such a network? The government could be a lot of help in keeping the network up in the face of attack rather than simply shutting it off. The emphasis should be on keeping it working, not how to most efficiently shut it down. From brandon at rd.bbc.co.uk Fri Feb 4 02:48:40 2011 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Fri, 4 Feb 2011 08:48:40 GMT Subject: Weekend Gedankenexperiment - The Kill Switch Message-ID: <201102040848.IAA04232@sunf10.rd.bbc.co.uk> > An armed FBI special agent shows up at your facility and tells your ranking > manager to "shut down the Internet". a) you give them the crystals and warn that in isolation they can be unstable so drive slow or b) you give them the internet to take away http://www.youtube.com/watch?v=iRmxXp62O8g or c) you point to egypt and tell them the kill switch is there, just turn it to a higher setting than their government used > What do you do when you get home to put it back on the air Are you crazy, they'll then know where else to visit. This is a trap. brandon From BECHA at ripe.net Fri Feb 4 05:02:10 2011 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 04 Feb 2011 12:02:10 +0100 Subject: My upstream ISP does not support IPv6 In-Reply-To: <18699589.266.1296788654238.JavaMail.franck@franck-martins-macbook-pro.local> References: <18699589.266.1296788654238.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4D4BDCB2.7060403@ripe.net> Hi Franck, On 2/4/11 4:04 AM, Franck Martin wrote: > The biggest complaint that I hear from ISPs, is that their upstream > ISP does not support IPv6 or will not provide them with a native IPv6 > circuit. > > Is that bull? > > I thought the whole backbone is IPv6 now, and it is only the > residential ISPs that are still figuring it out because CPE are still > not there yet. > > Where can I get more information? > Any list of peering ISPs that have IPv6 as part of their products? There is a list of LIRs (ISPs) in RIPE NCC service region that have some aspects of IPv6 sorted out: - got address space - registered route6 in Routing Registry - got reverse DNS delegation - and are visible in ris.ripe.net If they have all "4 stars", they are listed here (per country) http://ipv6ripeness.ripe.net That still does not mean that they are offering IPv6 to their customers, but it is a good indication. I hope this helps, Vesna (IPv6 Ripeness goddess ;-) From eugen at leitl.org Fri Feb 4 05:03:04 2011 From: eugen at leitl.org (Eugen Leitl) Date: Fri, 4 Feb 2011 12:03:04 +0100 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <4D4B3777.8020800@gont.com.ar> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> Message-ID: <20110204110304.GP23560@leitl.org> On Thu, Feb 03, 2011 at 08:17:11PM -0300, Fernando Gont wrote: > > I'm mildly surprised if you think we're going to be done with *this* > > mess in a few decades. > > I fully agree. But planning/expecting to go through this mess *again* is > insane. -- I hope the lesson has been learned, and we won't repeat history. Given http://weblog.chrisgrundemann.com/index.php/2009/how-much-ipv6-is-there/ it is pretty clear the allocation algorithms have to change, or the resource is just as finite as the one we ran out yesterday. From lists at internetpolicyagency.com Fri Feb 4 06:30:46 2011 From: lists at internetpolicyagency.com (Roland Perry) Date: Fri, 4 Feb 2011 12:30:46 +0000 Subject: quietly.... In-Reply-To: <20110204000954.A64C79A9FED@drugs.dv.isc.org> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <437F22E3-154B-4DD2-B37B-8BC54D116B40@delong.com> <9F2mjoD95cSNFAI6@perry.co.uk> <5A055785-D55E-47A3-87B0-58B0DE81F60E@delong.com> <20110203220604.A8BAE9A5102@drugs.dv.isc.org> <20110204000954.A64C79A9FED@drugs.dv.isc.org> Message-ID: In article <20110204000954.A64C79A9FED at drugs.dv.isc.org>, Mark Andrews writes >> These are just my straw poll of what may be difficult for small >> enterprises in a change to IPv6. > >It isn't "change to", its "add IPv6". > >I expect to see IPv4 used for years inside homes and enterprises >where there is enough IPv4 addresses to meet the internal needs. >It's external communication which needs to switch to IPv6. Internal >communication just comes along for the ride. If people start supplying CPE that are running IPv6 on the outside and IPv4 NAT in the inside, then that would just fine, in the sense that the users (in this case including the self-administrators of these small enterprise networks) won't notice the difference. -- Roland Perry From dredd at megacity.org Fri Feb 4 08:05:09 2011 From: dredd at megacity.org (Derek J. Balling) Date: Fri, 4 Feb 2011 09:05:09 -0500 Subject: quietly.... In-Reply-To: References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <437F22E3-154B-4DD2-B37B-8BC54D116B40@delong.com> <9F2mjoD95cSNFAI6@perry.co.uk> <5A055785-D55E-47A3-87B0-58B0DE81F60E@delong.com> <20110203220604.A8BAE9A5102@drugs.dv.isc.org> <20110204000954.A64C79A9FED@drugs.dv.isc.org> Message-ID: <5FDDAD27-71F3-44FE-B195-4E0F27F09EC5@megacity.org> On Feb 4, 2011, at 7:30 AM, Roland Perry wrote: >> It isn't "change to", its "add IPv6". >> >> I expect to see IPv4 used for years inside homes and enterprises >> where there is enough IPv4 addresses to meet the internal needs. >> It's external communication which needs to switch to IPv6. Internal >> communication just comes along for the ride. > > If people start supplying CPE that are running IPv6 on the outside and IPv4 NAT in the inside, then that would just fine, in the sense that the users (in this case including the self-administrators of these small enterprise networks) won't notice the difference. I think they'll eventually notice a difference. How will an IPv4-only internal host know what to do with an IPv6 AAAA record it gets from a DNS lookup? Sure, I think we're a long way off from any "significant sites" being v6-only, but "6-outside-4-inside" CPE will cut those users off from 6-only sites unless the NATing CPE is also doing some really, really, wonky DNS interception and proxying at the same time, and I don't *anyone* wants to see that.... D From jbates at brightok.net Fri Feb 4 08:13:10 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 04 Feb 2011 08:13:10 -0600 Subject: My upstream ISP does not support IPv6 In-Reply-To: <1127264403.2346.1296791643752.JavaMail.root@zimbra.network1.net> References: <1127264403.2346.1296791643752.JavaMail.root@zimbra.network1.net> Message-ID: <4D4C0976.8010506@brightok.net> On 2/3/2011 9:54 PM, Randy Carpenter wrote: > The major national provider is supposed to be swapping out equipment > any day now in order to support IPv6. The regional is claiming that > their upstreams do not have IPv6 support yet. Their upstream > providers certainly do have IPv6, but I do not know if they are not > offering it to their downstream ISP customers. > > I don't know, but as a company that manages the internet operations > for numerous ISPs, and needs to have full monitoring capability for > said customers, it is frustrating not to have native IPv6. > I waited years and finally turned up a transit to L3 for additional bandwidth (had to wait for GE support from the other 2, of which 1 still can't give me a GE) and luckily native v6. Within 30 days I should have a cogent 10G, and I hear I'll get v6 there as well. I'm still waiting for v6 on the original 2, but I can live with what I have. Jack From jbates at brightok.net Fri Feb 4 08:15:11 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 04 Feb 2011 08:15:11 -0600 Subject: You Tube Problems In-Reply-To: References: <16898807.270.1296790672357.JavaMail.franck@franck-martins-macbook-pro.local> <20110203221335.21e614d2@petrie> Message-ID: <4D4C09EF.9030103@brightok.net> On 2/3/2011 10:20 PM, Joly MacFie wrote: > What might be a possibility is that YouTube is actually choking under the > demand for Egypt related footage, nearly all of which is hosted on the site. The overall bandwith utilization from Oklahoma has spiked due to the snow. I'm sure other ISPs are seeing similar issues where people aren't able to get out. The first day, we hit our usual peak high at 10am, and up she went. Jack From bgreene at senki.org Fri Feb 4 08:18:01 2011 From: bgreene at senki.org (Barry Greene) Date: Fri, 4 Feb 2011 06:18:01 -0800 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> <96503CEA-C922-47A6-9691-FCF157DF15D5@internode.com.au> <15DCBF6D-423D-48F6-B9F1-5B1227AB042D@internode.com.au> Message-ID: > The Internet is not immune to the law, as you should well know. In fact, > the Internet seems to be a legal "proving ground" these days, so word to > the wise. And, the US National Communication Service (http://www.ncs.gov/index.html) "technically" has the ability to order all US telecommunications providers to disconnect for the express purpose of maintaining the integrity of the US Telecommunications system. If the NCS does not have implicit authority, a Executive order would grant it. So beware, most of the "US Internet Kill Switch" talk in Washington DC is politics from people who have not read that can be done now using existing authorities. From jbates at brightok.net Fri Feb 4 08:28:53 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 04 Feb 2011 08:28:53 -0600 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <20110204110304.GP23560@leitl.org> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org> Message-ID: <4D4C0D25.70408@brightok.net> On 2/4/2011 5:03 AM, Eugen Leitl wrote: > Given http://weblog.chrisgrundemann.com/index.php/2009/how-much-ipv6-is-there/ > it is pretty clear the allocation algorithms have to change, or the resource > is just as finite as the one we ran out yesterday. That's not what the author says. It says, IPv6 is only somewherein the range of 16 million to 17 billion times larger than IPv4. Let's be realistic. A /32 (standard small ISP) is equiv to an IPv4 single IP. A /28 (medium ISP) is equiv to an IPv4 /28. A /24 (high medium, large ISP) is equiv to an IPv4 /24. A /16 (a huge ISP) is equiv to an IPv4 /16. Get the picture? So, I currently route a /16 worth of deaggregated IPv4 address space (sorry, allocation policy fault, not mine). There is NEVER a time that I will be allocated an IPv6 /16 from ARIN. Heck, the most I'll ever hope for is the current proposal's nibble boundary which might get me to a /24. I'll never talk to ARIN again after that. Jack From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Fri Feb 4 08:32:06 2011 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sat, 5 Feb 2011 01:02:06 +1030 Subject: ipv4's last graph In-Reply-To: References: <876F9BFF-4807-49A5-9D76-9FC067CCC645@apnic.net> Message-ID: <20110205010206.2dda5857@opy.nosense.org> On Wed, 02 Feb 2011 06:25:18 +0900 Randy Bush wrote: > > http://www.potaroo.net/tools/ipv4/rir.jpg > > > > This is a different graph - it is a probabilistic graph that shows the > > predicted month when the RIR will be down to its last /8 policy > > (whatever that policy may be), and the relative probability that the > > event will occur in that particular month. > > brilliant! and damned useful! > > there's a reason you get the big bucks. thanks. really appreciated. > (I'm plonked by Randy, so I doubt he will get this. I don't necessarily care too much about that.) I doubt Geoff is getting the "big bucks" that he could get at a few other places in the region. He used to work for the incumbent telco in .au, and based on what the last CEO was paid, he'd probably have been on a very good wicket these days if he'd chosen to stay there. He didn't. (Randy, if you see this, you do add a lot of value to the community. However, I think your knee-jerk, childish and schoolyard reactions would also loose you a lot of the respect that you've earned from the work that you've done. Please just accept that not everybody will always agree with your opinions, despite how informed and experienced they are.) From khelms at ispalliance.net Fri Feb 4 09:05:34 2011 From: khelms at ispalliance.net (Scott Helms) Date: Fri, 04 Feb 2011 10:05:34 -0500 Subject: My upstream ISP does not support IPv6 In-Reply-To: <18699589.266.1296788654238.JavaMail.franck@franck-martins-macbook-pro.local> References: <18699589.266.1296788654238.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4D4C15BE.8090801@ispalliance.net> We have been working diligently for more than 6 months to try and get a /56 routed to one of our offices in metro Atlanta. The carrier in question is a Tier 1 as well as being one of the old telecom names. I have the entire chain of emails documenting the carrier's struggles with internal process and technical issues. We are currently waiting for a new edge router to be ready to transfer our existing circuits to. Not that it matters but we were also told that we would be moved from a Cisco to a Juniper. Once I realized how much of a struggle that was turning into I contacted some of our other providers (a mix of Tier 1 & 2 ISPs and collocation providers) as of this moment none of them (though some seem close) are actually prepared to deliver IPv6 connectivity where we need it despite some of them already touting preparedness. What I think is worth remembering is that there are a _lot_ of moving parts to get right to actually route an IPv6 block down a connection. Some of those parts are technical like making sure an edge router that may have been in place for years can handle IPv6 traffic _and_ that addition won't cause a CPU or other issue on the specific platform you're looking at. Some of the others are simply business process pieces like making sure contracts, internal and external documentation, and work flow that need to be updated. TLDR version, marketing often fails to reflect reality :) On 2/3/2011 10:04 PM, Franck Martin wrote: > The biggest complaint that I hear from ISPs, is that their upstream ISP does not support IPv6 or will not provide them with a native IPv6 circuit. > > Is that bull? > > I thought the whole backbone is IPv6 now, and it is only the residential ISPs that are still figuring it out because CPE are still not there yet. > > Where can I get more information? Any list of peering ISPs that have IPv6 as part of their products? > > It seems to me the typical answer sales people say when asked about IPv6: "Gosh, this is the first time I'm asked this one". > -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From lists at internetpolicyagency.com Fri Feb 4 10:07:35 2011 From: lists at internetpolicyagency.com (Roland Perry) Date: Fri, 4 Feb 2011 16:07:35 +0000 Subject: quietly.... In-Reply-To: <5FDDAD27-71F3-44FE-B195-4E0F27F09EC5@megacity.org> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <437F22E3-154B-4DD2-B37B-8BC54D116B40@delong.com> <9F2mjoD95cSNFAI6@perry.co.uk> <5A055785-D55E-47A3-87B0-58B0DE81F60E@delong.com> <20110203220604.A8BAE9A5102@drugs.dv.isc.org> <20110204000954.A64C79A9FED@drugs.dv.isc.org> <5FDDAD27-71F3-44FE-B195-4E0F27F09EC5@megacity.org> Message-ID: <87pGcPBHRCTNFAjT@perry.co.uk> In article <5FDDAD27-71F3-44FE-B195-4E0F27F09EC5 at megacity.org>, Derek J. Balling writes >> If people start supplying CPE that are running IPv6 on the outside and IPv4 NAT in the inside, then that would just fine, in the sense that >>the users (in this case including the self-administrators of these small enterprise networks) won't notice the difference. > >I think they'll eventually notice a difference. How will an IPv4-only internal host know what to do with an IPv6 AAAA record it gets from a DNS >lookup? The IPv4 only hosts (and gradually they'll be converted to dual stack and IPv6 capable, some are there already) will only be able to see IPv4 resources on the wider Internet. I'd have to decide on a case by case basis (one case being a particular VoIP service I subscribe to) when those hosts of mine needed early replacement on account of the provider switching off his end. (My point here mainly being that it's not just a case of simply reconfiguring them, if they simply don't have any IPv6 capability). For those familiar with Windows, it's not dissimilar to my recent decision to update one of my desktops to XP, because so much software (mainly device drivers) no longer supports Win2000. But then you find you have apps that won't run under XP [more likely on a jump from XP to Vista, but you get my point]. >Sure, I think we're a long way off from any "significant sites" being v6-only, but "6-outside-4-inside" CPE will cut those users off from >6-only sites unless the NATing CPE is also doing some really, really, wonky DNS interception and proxying at the same time, and I don't >*anyone* wants to see that.... I don't know if it's the "wonky behaviour" you describe, but I'd have expected any IPv6 traffic inside the network to go round the side of the NAT functionality (ie behave as if the IPv4 NAT wasn't there). But we've drifted a bit away from the earlier problem of how I can make all the hosts on my internal network "hop" between ISPs with in effect no user intervention (and no pre-emptive configuration). I'll let this pass for now and see how the market/technology develops. -- Roland Perry From lowen at pari.edu Fri Feb 4 10:40:42 2011 From: lowen at pari.edu (Lamar Owen) Date: Fri, 4 Feb 2011 11:40:42 -0500 Subject: quietly.... In-Reply-To: <5FDDAD27-71F3-44FE-B195-4E0F27F09EC5@megacity.org> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> Message-ID: <201102041140.42719.lowen@pari.edu> On Friday, February 04, 2011 09:05:09 am Derek J. Balling wrote: > I think they'll eventually notice a difference. How will an IPv4-only internal host know what to do with an IPv6 AAAA record it gets from a DNS lookup? If the CPE is doing DNS proxy (most do) then it can map the AAAA record to an A record it passes to the internal client, with an internal address for the record chosen from RFC1918 space, and perform IPv4-IPv6 1:1 NAT from the assigned RFC1918 address to the external IPv6 address from the AAAA record (since you have at least a /64 at your CPE, you can even use the RFC1918 address in the lower 32 bits.... :-P). This may already be a standard, or a draft, or implemented somewhere; I don't know. But that is how I would do it, just thinking off the top of my head. From bmanning at vacation.karoshi.com Fri Feb 4 10:50:01 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 4 Feb 2011 16:50:01 +0000 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <4D4C0D25.70408@brightok.net> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org> <4D4C0D25.70408@brightok.net> Message-ID: <20110204165001.GB17194@vacation.karoshi.com.> On Fri, Feb 04, 2011 at 08:28:53AM -0600, Jack Bates wrote: > > > On 2/4/2011 5:03 AM, Eugen Leitl wrote: > > >Given > >http://weblog.chrisgrundemann.com/index.php/2009/how-much-ipv6-is-there/ > >it is pretty clear the allocation algorithms have to change, or the > >resource > >is just as finite as the one we ran out yesterday. > > That's not what the author says. It says, IPv6 is only somewherein the > range of 16 million to 17 billion times larger than IPv4. presuming you don't adhere to the guidelines that insist on the bottom 64 bits being used as a "MAC" address and the top 32 bits being used as an RIR identifier. in reality, IPv6 (as specified by many IETF RFCs and as implemented in lots of codes bases) only has 32 usable bits... just like IPv4. > Let's be realistic. A /32 (standard small ISP) is equiv to an IPv4 > single IP. A /28 (medium ISP) is equiv to an IPv4 /28. A /24 (high > medium, large ISP) is equiv to an IPv4 /24. A /16 (a huge ISP) is equiv > to an IPv4 /16. Get the picture? sho'huff. the real question is, how will you manage your own 32bits of space? this is a change from the old v4 world, when the question was, how will you manage your (pre CIDR) 8bits (or 16bits, or 24bits) of space? > > Jack I suspect that many people will do stupid things in managing their bits - presuming that there is virtually infinate 'greenfield' and when they have "pissed in the pool" they can just move on to a new pool. the downside... renumbering is never easy - even with/especially with IPv6. --bill From jbates at brightok.net Fri Feb 4 10:55:21 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 04 Feb 2011 10:55:21 -0600 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <20110204165001.GB17194@vacation.karoshi.com.> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org> <4D4C0D25.70408@brightok.net> <20110204165001.GB17194@vacation.karoshi.com.> Message-ID: <4D4C2F79.1090702@brightok.net> On 2/4/2011 10:50 AM, bmanning at vacation.karoshi.com wrote: > I suspect that many people will do stupid things in managing their > bits - presuming that there is virtually infinate 'greenfield' and > when they have "pissed in the pool" they can just move on to a new > pool. the downside... renumbering is never easy - even with/especially > with IPv6. The problem is, they'll be restricted by RIR guidelines. I know that existing and future IPv6 allocation proposals for ARIN (our immediate concern) is based more on end site counts, and a limitation of /48 per end site without very good justification. Jack From drc at virtualized.org Fri Feb 4 11:11:30 2011 From: drc at virtualized.org (David Conrad) Date: Fri, 4 Feb 2011 07:11:30 -1000 Subject: And so it ends... In-Reply-To: <201102040653.p146rRGU072389@mail.r-bonomi.com> References: <201102040653.p146rRGU072389@mail.r-bonomi.com> Message-ID: <6C82BAC8-AC53-4EE2-8B05-22023CF56F5E@virtualized.org> Robert, On Feb 3, 2011, at 8:53 PM, Robert Bonomi wrote: >> As far as I am aware, the USG contract is with ICANN, not ARIN (see >> http://www.ntia.doc.gov/ntiahome/domainname/iana/ianacontract_081406.pdf, >> section C.2.2.1.3). > > Correct. _They_ can can delegate "as they see fit", with no requirement > to provide competing alternatives. ARIN, the delegatee, is not the > 'monopolist' -- the party controlling the situation -- they are just a > delagatee of the party who has the monopoly position. An interesting perspective. Thanks! Regards, -drc From Valdis.Kletnieks at vt.edu Fri Feb 4 11:38:49 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 04 Feb 2011 12:38:49 -0500 Subject: quietly.... In-Reply-To: Your message of "Thu, 03 Feb 2011 18:14:00 EST." References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> <483E6B0272B0284BA86D7596C40D29F9011F76964E94@PUR-EXCH07.ox.com> <37955.1296761312@localhost> <201102031520.26126.lowen@pari.edu> <48563.1296769591@localhost> Message-ID: <23296.1296841129@localhost> On Thu, 03 Feb 2011 18:14:00 EST, david raistrick said: > Er. That's not news. That's been the state of the art for what, 15+ > years or so now? SIP (because it's peer to peer) and P2P are really the > only things that actually give a damn about it. "It's client/server unless it's peer-to-peer" is almost a tautology, you know... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From rali+nanog at tifosi.com Fri Feb 4 11:50:21 2011 From: rali+nanog at tifosi.com (R A Lichtensteiger) Date: Fri, 4 Feb 2011 12:50:21 -0500 Subject: External sanity checks In-Reply-To: <8C164D3BAF7C7F41B9B286385037B1311909D817F7@lax-exch-fe-01.gorillanation.local> References: <844412.30168.qm@web30804.mail.mud.yahoo.com> <19C36902-4D62-4F3E-A4C3-6EDF72D8E62C@equinix.com> <8C164D3BAF7C7F41B9B286385037B1311909D817F7@lax-exch-fe-01.gorillanation.local> Message-ID: <20110204175021.GB5781@mta.tifosi.com> Justin Horstman wrote: <> +1 vote for Gomez, they are the most advanced and most capable in <> this space. They are also not very cheap... And Gomez' service contracts include automatic rollover. -1 on Gomez R -- R A Lichtensteiger rali at tifosi.com "Dual [IS-IS] is intended to be more of a long-term solution because there will be very few pure OSI or TCP/IP routing environments in the future." - Network World April 9, 1990 (page 59) From ikiris at gmail.com Fri Feb 4 11:59:24 2011 From: ikiris at gmail.com (Blake Dunlap) Date: Fri, 4 Feb 2011 11:59:24 -0600 Subject: quietly.... In-Reply-To: <23296.1296841129@localhost> References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> <483E6B0272B0284BA86D7596C40D29F9011F76964E94@PUR-EXCH07.ox.com> <37955.1296761312@localhost> <201102031520.26126.lowen@pari.edu> <48563.1296769591@localhost> <23296.1296841129@localhost> Message-ID: On Fri, Feb 4, 2011 at 11:38, wrote: > On Thu, 03 Feb 2011 18:14:00 EST, david raistrick said: > > > Er. That's not news. That's been the state of the art for what, 15+ > > years or so now? SIP (because it's peer to peer) and P2P are really the > > only things that actually give a damn about it. > > "It's client/server unless it's peer-to-peer" is almost a tautology, you > know... > The argument is specious anyway, as many existing protocols that should by all rights be peer to peer, are forced to use HTTP to a server that someone has to pay for (and it isn't the guy running NAT) due to the brokenness of the internet. Those 65k ports were not meant solely for client random connects to port 80. Why an instant message client even would use the far over bloated HTTP to some 3rd party that shouldn't be privy to the packets anyway for the purpose is an example of what we've been reduced to. Trying to ask for examples of things that are broken by NAT or have not been implemented due to it, after it has been the standard for many years, and then using arguments that they work over NAT to counter it, ignoring the fact that someone had to invest a lot of money and time (again, not the NAT users) in being able to do that, is amazing to me. It's like asking for people that have died hungry to come speak out against hunger, and claiming that clearly it isn't a problem, when they don't show up. -Blake From drais at icantclick.org Fri Feb 4 12:04:00 2011 From: drais at icantclick.org (david raistrick) Date: Fri, 4 Feb 2011 13:04:00 -0500 (EST) Subject: quietly.... In-Reply-To: References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> <483E6B0272B0284BA86D7596C40D29F9011F76964E94@PUR-EXCH07.ox.com> <37955.1296761312@localhost> <201102031520.26126.lowen@pari.edu> <48563.1296769591@localhost> Message-ID: On Thu, 3 Feb 2011, Owen DeLong wrote: > Er. ?That's not news. ?That's been the state of the art for > what, 15+ years or so now? ??SIP (because it's peer to peer) and > P2P are really the only things that actually give a damn about > it. > > Largely because we've been living with the tradeoff that we had to break the > end-to-end model to temporarily compensate for an address shortage. Those of > us that remember life before NAT would prefer not to bring this damage > forward into an area of address abundance. In other words, yes, we gave up Life before NAT, and firewalls (with or without SPI) on every PC and every CPI, also was life before mass consuption of internet access by the "normal" folks. And before extensive cellular and wifi networks for internet access. And before many of today's (common end user PC) security issues had been discovered. Firewalls -destroy- the "end to end" model. You don't get inbound connectivity past the firewall unless a rule is explicitly created. That's no different than NAT requiring specific work to be done. Firewalls are not going away, if anything the continuing expansion of consumer users will create more and more breakage of the open-everything-connects-to-everything model, regardless of what the core engineering teams may want. Hell, even without CPE doing it, many residential ISPs (regardless of NAT) block inbound traffic to consumers. The end-to-end model ended a long long time ago....maybe it will come back, but I rather doubt it. We'll continue to have users, who run client software, and providers, who run server software. And a mix in between, because the user end can CHOOSE to enable server functionality (with their feet, by choosing a new ISP, at their firewall and or NAT device, and by enabling "server" software). NAT doesn't destroy end-to-end. It just makes it slightly more difficult. But no more difficult that turning on a firewall does. It doesn't break anything that isn't trying to "announce" itself - and imo, applications that want to "announce" themselves seem like a pretty big security hole. -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From dredd at megacity.org Fri Feb 4 12:09:11 2011 From: dredd at megacity.org (Derek J. Balling) Date: Fri, 4 Feb 2011 13:09:11 -0500 Subject: quietly.... In-Reply-To: <201102041140.42719.lowen@pari.edu> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <201102041140.42719.lowen@pari.edu> Message-ID: On Feb 4, 2011, at 11:40 AM, Lamar Owen wrote: > On Friday, February 04, 2011 09:05:09 am Derek J. Balling wrote: >> I think they'll eventually notice a difference. How will an IPv4-only internal host know what to do with an IPv6 AAAA record it gets from a DNS lookup? > > If the CPE is doing DNS proxy (most do) then it can map the AAAA record to an A record it passes to the internal client, with an internal address for the record chosen from RFC1918 space, and perform IPv4-IPv6 1:1 NAT from the assigned RFC1918 address to the external IPv6 address from the AAAA record (since you have at least a /64 at your CPE, you can even use the RFC1918 address in the lower 32 bits.... :-P). > > This may already be a standard, or a draft, or implemented somewhere; I don't know. But that is how I would do it, just thinking off the top of my head. That's exactly how I'd implement it too, but I'm just saying that that's sort of a kludge (even above and beyond the types of hoops that NAT itself is jumping through). You'd probably have to configure the CPE manually to say something like "here's which RFC1918 space I *don't* care about, that you can use as your v6 IP NAT pool", so that the CPE didn't accidentally abuse IPs in use somewhere else in the environment.... D From bjohnson at drtel.com Fri Feb 4 12:11:42 2011 From: bjohnson at drtel.com (Brian Johnson) Date: Fri, 4 Feb 2011 18:11:42 +0000 Subject: quietly.... In-Reply-To: References: <16075456.4557.1296760302037.JavaMail.root@benjamin.baylink.com> Message-ID: >> >> Was TCP/IP this bad back in 1983, folks? >> >> Cheers, >> -- jra > >In different ways, yes, it was. > >Owen > This is exactly the problem we have. Some people have no perspective on what the Internet is and it's real power. I've met too many people who claim to be "in the know" on these topics that don't understand that NAT was designed for address preservation. That was the only/primary/driving real reason for its development. The other "features" were side effects and are not intended to be solutions to production issues. If I use a wrench to hammer nails, it may work fine, but when It comes to certain nails it may have issues. I'm using the tool for the wrong purpose. This is the folly of NAT. - Brian J. From sethm at rollernet.us Fri Feb 4 12:15:37 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 04 Feb 2011 10:15:37 -0800 Subject: My upstream ISP does not support IPv6 In-Reply-To: <4D4C0976.8010506@brightok.net> References: <1127264403.2346.1296791643752.JavaMail.root@zimbra.network1.net> <4D4C0976.8010506@brightok.net> Message-ID: <4D4C4249.7010209@rollernet.us> On 2/4/2011 06:13, Jack Bates wrote: > > I waited years and finally turned up a transit to L3 for additional > bandwidth (had to wait for GE support from the other 2, of which 1 still > can't give me a GE) and luckily native v6. Within 30 days I should have > a cogent 10G, and I hear I'll get v6 there as well. > Does anyone know how partitioned Cogent is these days? ~Seth From drais at icantclick.org Fri Feb 4 12:15:44 2011 From: drais at icantclick.org (david raistrick) Date: Fri, 4 Feb 2011 13:15:44 -0500 (EST) Subject: My upstream ISP does not support IPv6 In-Reply-To: <1127264403.2346.1296791643752.JavaMail.root@zimbra.network1.net> References: <1127264403.2346.1296791643752.JavaMail.root@zimbra.network1.net> Message-ID: On Thu, 3 Feb 2011, Randy Carpenter wrote: > IPv6 from both of my upstream providers has been "coming soon" for about > a year and a half. Can we start naming names and locations for both sides of the answer? My last v6 queries are a few years out of date, so no point in sharing them. Well, I take that back. Amazon AWS - "No." But I'm asking again, that's a few months old. -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From sethm at rollernet.us Fri Feb 4 12:23:59 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 04 Feb 2011 10:23:59 -0800 Subject: My upstream ISP does not support IPv6 In-Reply-To: <4D4C15BE.8090801@ispalliance.net> References: <18699589.266.1296788654238.JavaMail.franck@franck-martins-macbook-pro.local> <4D4C15BE.8090801@ispalliance.net> Message-ID: <4D4C443F.1060502@rollernet.us> On 2/4/2011 07:05, Scott Helms wrote: > > TLDR version, marketing often fails to reflect reality :) > My experience with trying to get a circuit turned up with Verizon boiled down to two things: 1) Failure to meet the standards of my existing IPv6 connections in carrying PI /48 (apparently now changed). 2) Failure to home the circuit on a router that supported IPv6. Month after month they would keep placing it to an IPv4-only router and I would refuse to accept it until it was moved to an IPv6 capable router. It never happened. They said they could do it, but couldn't figure out how. ~Seth From cscora at apnic.net Fri Feb 4 12:27:05 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 5 Feb 2011 04:27:05 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201102041827.p14IR5wE029149@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 05 Feb, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 344448 Prefixes after maximum aggregation: 155332 Deaggregation factor: 2.22 Unique aggregates announced to Internet: 170039 Total ASes present in the Internet Routing Table: 35787 Prefixes per ASN: 9.62 Origin-only ASes present in the Internet Routing Table: 30852 Origin ASes announcing only one prefix: 14951 Transit ASes present in the Internet Routing Table: 4935 Transit-only ASes present in the Internet Routing Table: 119 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 31 Max AS path prepend of ASN (36992) 29 Prefixes from unregistered ASNs in the Routing Table: 397 Unregistered ASNs in the Routing Table: 129 Number of 32-bit ASNs allocated by the RIRs: 1077 Prefixes from 32-bit ASNs in the Routing Table: 1 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 203 Number of addresses announced to Internet: 2380656448 Equivalent to 141 /8s, 229 /16s and 239 /24s Percentage of available address space announced: 64.2 Percentage of allocated address space announced: 65.7 Percentage of available address space allocated: 97.7 Percentage of address space in use by end-sites: 88.1 Total number of prefixes smaller than registry allocations: 142101 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 85206 Total APNIC prefixes after maximum aggregation: 28888 APNIC Deaggregation factor: 2.95 Prefixes being announced from the APNIC address blocks: 81892 Unique aggregates announced from the APNIC address blocks: 35574 APNIC Region origin ASes present in the Internet Routing Table: 4314 APNIC Prefixes per ASN: 18.98 APNIC Region origin ASes announcing only one prefix: 1208 APNIC Region transit ASes present in the Internet Routing Table: 687 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 20 Number of APNIC addresses announced to Internet: 586924320 Equivalent to 34 /8s, 251 /16s and 193 /24s Percentage of available APNIC address space announced: 76.1 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 138523 Total ARIN prefixes after maximum aggregation: 70948 ARIN Deaggregation factor: 1.95 Prefixes being announced from the ARIN address blocks: 109351 Unique aggregates announced from the ARIN address blocks: 44581 ARIN Region origin ASes present in the Internet Routing Table: 14172 ARIN Prefixes per ASN: 7.72 ARIN Region origin ASes announcing only one prefix: 5410 ARIN Region transit ASes present in the Internet Routing Table: 1468 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 23 Number of ARIN addresses announced to Internet: 751911808 Equivalent to 44 /8s, 209 /16s and 67 /24s Percentage of available ARIN address space announced: 63.1 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 47/8, 48/8, 50/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 81469 Total RIPE prefixes after maximum aggregation: 46272 RIPE Deaggregation factor: 1.76 Prefixes being announced from the RIPE address blocks: 74776 Unique aggregates announced from the RIPE address blocks: 48554 RIPE Region origin ASes present in the Internet Routing Table: 15262 RIPE Prefixes per ASN: 4.90 RIPE Region origin ASes announcing only one prefix: 7770 RIPE Region transit ASes present in the Internet Routing Table: 2373 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 30 Number of RIPE addresses announced to Internet: 457667392 Equivalent to 27 /8s, 71 /16s and 115 /24s Percentage of available RIPE address space announced: 75.8 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 31580 Total LACNIC prefixes after maximum aggregation: 7273 LACNIC Deaggregation factor: 4.34 Prefixes being announced from the LACNIC address blocks: 30338 Unique aggregates announced from the LACNIC address blocks: 15849 LACNIC Region origin ASes present in the Internet Routing Table: 1424 LACNIC Prefixes per ASN: 21.30 LACNIC Region origin ASes announcing only one prefix: 430 LACNIC Region transit ASes present in the Internet Routing Table: 250 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 19 Number of LACNIC addresses announced to Internet: 80422528 Equivalent to 4 /8s, 203 /16s and 38 /24s Percentage of available LACNIC address space announced: 59.9 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 7450 Total AfriNIC prefixes after maximum aggregation: 1839 AfriNIC Deaggregation factor: 4.05 Prefixes being announced from the AfriNIC address blocks: 5872 Unique aggregates announced from the AfriNIC address blocks: 1790 AfriNIC Region origin ASes present in the Internet Routing Table: 436 AfriNIC Prefixes per ASN: 13.47 AfriNIC Region origin ASes announcing only one prefix: 132 AfriNIC Region transit ASes present in the Internet Routing Table: 96 Average AfriNIC Region AS path length visible: 5.3 Max AfriNIC Region AS path length visible: 31 Number of AfriNIC addresses announced to Internet: 21818624 Equivalent to 1 /8s, 76 /16s and 237 /24s Percentage of available AfriNIC address space announced: 43.3 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1914 9485 525 Korea Telecom (KIX) 7545 1619 301 84 TPG Internet Pty Ltd 4755 1409 637 161 TATA Communications formerly 17974 1391 467 27 PT TELEKOMUNIKASI INDONESIA 24560 1099 318 182 Bharti Airtel Ltd., Telemedia 9583 1044 76 490 Sify Limited 4808 1034 2130 292 CNCGROUP IP network: China169 17488 952 162 104 Hathway IP Over Cable Interne 18101 928 117 144 Reliance Infocom Ltd Internet 9829 895 762 41 BSNL National Internet Backbo Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3704 3855 265 bellsouth.net, inc. 4323 2622 1109 403 Time Warner Telecom 19262 1842 4949 287 Verizon Global Networks 1785 1784 697 132 PaeTec Communications, Inc. 20115 1522 1532 642 Charter Communications 6478 1482 291 81 AT&T Worldnet Services 7018 1353 6673 871 AT&T WorldNet Services 2386 1295 553 933 AT&T Data Communications Serv 22773 1278 2865 78 Cox Communications, Inc. 11492 1264 235 79 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6830 515 1764 319 UPC Distribution Services 9198 464 266 14 Kazakhtelecom Data Network Ad 34984 458 97 137 BILISIM TELEKOM 3292 447 2011 390 TDC Tele Danmark 8866 440 133 23 Bulgarian Telecommunication C 3320 407 7620 355 Deutsche Telekom AG 8551 403 353 46 Bezeq International 702 397 1817 310 UUNET - Commercial IP service 20940 387 89 296 Akamai Technologies European 3301 382 1822 340 TeliaNet Sweden Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1357 252 162 TVCABLE BOGOTA 8151 1332 2647 359 UniNet S.A. de C.V. 28573 1238 961 82 NET Servicos de Comunicao S.A 6503 1187 355 78 AVANTEL, S.A. 7303 882 461 112 Telecom Argentina Stet-France 14420 625 56 93 CORPORACION NACIONAL DE TELEC 22047 548 310 15 VTR PUNTO NET S.A. 3816 500 220 94 Empresa Nacional de Telecomun 7738 478 922 30 Telecomunicacoes da Bahia S.A 14117 456 34 31 Telefonica del Sur S.A. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 800 445 11 TEDATA 24863 761 147 39 LINKdotNET AS number 36992 635 329 19 Etisalat MISR 3741 264 987 226 The Internet Solution 24835 217 78 10 RAYA Telecom - Egypt 6713 203 199 12 Itissalat Al-MAGHRIB 33776 194 12 15 Starcomms Nigeria Limited 29571 192 17 11 Ci Telecom Autonomous system 16637 146 422 83 MTN Network Solutions 29975 132 490 17 Vodacom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3704 3855 265 bellsouth.net, inc. 4323 2622 1109 403 Time Warner Telecom 4766 1914 9485 525 Korea Telecom (KIX) 19262 1842 4949 287 Verizon Global Networks 1785 1784 697 132 PaeTec Communications, Inc. 7545 1619 301 84 TPG Internet Pty Ltd 20115 1522 1532 642 Charter Communications 6478 1482 291 81 AT&T Worldnet Services 4755 1409 637 161 TATA Communications formerly 17974 1391 467 27 PT TELEKOMUNIKASI INDONESIA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 2622 2219 Time Warner Telecom 1785 1784 1652 PaeTec Communications, Inc. 19262 1842 1555 Verizon Global Networks 7545 1619 1535 TPG Internet Pty Ltd 6478 1482 1401 AT&T Worldnet Services 4766 1914 1389 Korea Telecom (KIX) 17974 1391 1364 PT TELEKOMUNIKASI INDONESIA 4755 1409 1248 TATA Communications formerly 22773 1278 1200 Cox Communications, Inc. 10620 1357 1195 TVCABLE BOGOTA Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.0.0.0/16 12654 RIPE NCC RIS Project 5.1.0.0/21 12654 RIPE NCC RIS Project 5.1.24.0/24 12654 RIPE NCC RIS Project 24.129.192.0/19 7922 Continental Cablevision 37.0.0.0/16 12654 RIPE NCC RIS Project 37.1.0.0/21 12654 RIPE NCC RIS Project 37.1.24.0/24 12654 RIPE NCC RIS Project 41.78.192.0/22 30999 Emtel is GSM, 3G and ISP in M 41.78.228.0/22 5713 Telkom SA Ltd 41.222.79.0/24 36938 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:11 /10:26 /11:72 /12:221 /13:445 /14:772 /15:1371 /16:11547 /17:5632 /18:9292 /19:18815 /20:24292 /21:24666 /22:32814 /23:31471 /24:180138 /25:995 /26:1072 /27:587 /28:163 /29:16 /30:3 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2283 3704 bellsouth.net, inc. 6478 1436 1482 AT&T Worldnet Services 4323 1412 2622 Time Warner Telecom 10620 1248 1357 TVCABLE BOGOTA 11492 1221 1264 Cable One 18566 1160 1182 Covad Communications 7011 1063 1164 Citizens Utilities 1785 1053 1784 PaeTec Communications, Inc. 6503 963 1187 AVANTEL, S.A. 19262 954 1842 Verizon Global Networks Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:169 2:39 4:13 5:1 8:334 12:2027 13:1 14:396 15:15 16:3 17:8 20:9 23:1 24:1465 27:570 32:61 33:5 34:2 37:1 38:695 40:101 41:2326 44:3 46:563 47:5 49:143 50:84 52:12 55:5 56:2 57:31 58:866 59:483 60:391 61:1116 62:1065 63:1919 64:3753 65:2358 66:4116 67:1760 68:1004 69:2878 70:717 71:397 72:1992 73:1 74:2322 75:293 76:329 77:848 78:702 79:440 80:1044 81:808 82:534 83:473 84:645 85:1046 86:533 87:732 88:356 89:1584 90:157 91:3458 92:494 93:1038 94:1195 95:791 96:416 97:250 98:759 99:33 101:23 107:3 108:82 109:863 110:472 111:693 112:312 113:354 114:495 115:641 116:922 117:676 118:649 119:1020 120:240 121:698 122:1612 123:1053 124:1269 125:1216 128:264 129:152 130:172 131:567 132:110 133:20 134:217 135:49 136:216 137:147 138:290 139:120 140:490 141:196 142:362 143:376 144:483 145:51 146:425 147:193 148:626 149:273 150:151 151:230 152:306 153:177 154:3 155:347 156:173 157:342 158:128 159:380 160:315 161:205 162:278 163:159 164:486 165:338 166:481 167:420 168:741 169:152 170:750 171:66 172:2 173:1275 174:521 175:314 176:1 177:12 178:752 180:778 182:340 183:250 184:208 186:988 187:790 188:912 189:1053 190:4357 192:5785 193:4800 194:3500 195:2946 196:1176 197:3 198:3579 199:3755 200:5592 201:1579 202:8263 203:8417 204:4097 205:2341 206:2632 207:3083 208:3884 209:3499 210:2641 211:1332 212:1859 213:1717 214:757 215:62 216:4796 217:1615 218:528 219:376 220:1202 221:449 222:319 223:95 End of report From heinrich at hstrauss.co.za Fri Feb 4 12:47:26 2011 From: heinrich at hstrauss.co.za (Heinrich Strauss) Date: Fri, 04 Feb 2011 20:47:26 +0200 Subject: Post-Exhaustion-phase "punishment" for early adopters Message-ID: <4D4C49BE.3030907@hstrauss.co.za> Hi, NANOG. Something's just struck me: every IPv4 allocation over a certain threshold has a monetary cost (sometimes in the tens of thousands of USD) and according to our RIR, the first equivalent IPv6 allocation is given as a freebie (to encourage migration). (Disclaimer: I'm on the Dark Continent of Africa) So once the "early" adopters migrate their networks to IPv6, there is no business need to maintain the IPv4 allocation and that will be returned to the free pool, since Business would see it as an unnecessary cost. This would seem to counteract the forced move to IPv6, since, once the early adopters move their services exclusively to IPv6 (or maintaining very small IPv4 blocks), there would be plenty of IPv4 space for the late adopters to request (after the RIR quarantine period, etc). Naturally, 6to4 functionality must remain for a while to interoperability reasons, so their resources would be available to the IPv6 world for time to come. Unless I'm misunderstanding the RIRs policy regarding IPv4 allocations; has it been stated by all RIRs that IPv4 blocks are unallocatable once the exhaustion phase kicks in? Or is there another mechanism to ensure that we don't hand out the space being handed back once IPv6 is the norm? :) Regards, -H. From fred at cisco.com Fri Feb 4 13:08:03 2011 From: fred at cisco.com (Fred Baker) Date: Fri, 4 Feb 2011 19:08:03 +0000 Subject: Post-Exhaustion-phase "punishment" for early adopters In-Reply-To: <4D4C49BE.3030907@hstrauss.co.za> References: <4D4C49BE.3030907@hstrauss.co.za> Message-ID: On Feb 4, 2011, at 6:47 PM, Heinrich Strauss wrote: > So once the "early" adopters migrate their networks to IPv6, there is no business need to maintain the IPv4 allocation and that will be returned to the free pool, since Business would see it as an unnecessary cost. Interesting reasoning. I would think that until we have pretty wide IPv4 implementation, the business need to keep the allocation is to talk with the people who have not yet implemented it. From a Reductio ad Absurdum perspective, imagine that facebook or youtube, now that they have implemented IPv6, felt obliged to give up their IPv4 allocation immediately? It would mean that they were out of business, which I should think might be an excellent business reason to not deploy IPv6. From woody at pch.net Fri Feb 4 13:11:02 2011 From: woody at pch.net (Bill Woodcock) Date: Fri, 4 Feb 2011 11:11:02 -0800 Subject: Post-Exhaustion-phase "punishment" for early adopters In-Reply-To: <4D4C49BE.3030907@hstrauss.co.za> References: <4D4C49BE.3030907@hstrauss.co.za> Message-ID: <250E0B78-4DC5-4A94-B05A-95F0755C8884@pch.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 4, 2011, at 10:47 AM, Heinrich Strauss wrote: > So once the "early" adopters migrate their networks to IPv6, there is no business need to maintain the IPv4 allocation and that will be returned to the free pool, since Business would see it as an unnecessary cost. However, doing enough of a migration to be able to actually free up the IPv4 addresses, in advance of the devices using them dying of old age or being naturally cycled out, also imposes a cost, and likely a high one relative to the RIR maintenance fees, so it's my guess that the rate of IPv4 returns may not be too fast. > This would seem to counteract the forced move to IPv6, since, once the early adopters move their services exclusively to IPv6 (or maintaining very small IPv4 blocks), there would be plenty of IPv4 space for the late adopters to request. If you look at the actual numbers involved, I think you'll find that the "plenty" would actually be quite small and in quite small chunks, relative to what the industry could use, if they weren't trying to get over to v6. So I doubt it will have that much effect. > Has it been stated by all RIRs that IPv4 blocks are unallocatable once the exhaustion phase kicks in? Or is there another mechanism to ensure that we don't hand out the space being handed back once IPv6 is the norm? No, and in fact, I believe all the RIRs will probably do a reasonably brisk business in reclamation and reallocation, albeit in ever smaller blocks. One way to think about it is that there's no particular reason to think that the rate of increase in the number of IPv4 prefixes in the global BGP routing table will slack off, therefore those prefixes will each simply be smaller and smaller, over time. More or less. Speaking not particularly with my ARIN-board-hat-on, -Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk1MT0YACgkQGvQy4xTRsBH3RwCgpfo6JbOC8aYnsCu3h5B9++6u qA4AoJVds96Ua9dvqx2RDUw9qBZcyOQK =aMk8 -----END PGP SIGNATURE----- From bensons at queuefull.net Fri Feb 4 13:13:07 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 4 Feb 2011 13:13:07 -0600 Subject: Post-Exhaustion-phase "punishment" for early adopters In-Reply-To: References: <4D4C49BE.3030907@hstrauss.co.za> Message-ID: On Feb 4, 2011, at 1:08 PM, Fred Baker wrote: > On Feb 4, 2011, at 6:47 PM, Heinrich Strauss wrote: >> So once the "early" adopters migrate their networks to IPv6, there is no business need to maintain the IPv4 allocation and that will be returned to the free pool, since Business would see it as an unnecessary cost. > > Interesting reasoning. I would think that until we have pretty wide IPv4 implementation, the business need to keep the allocation is to talk with the people who have not yet implemented it. From a Reductio ad Absurdum perspective, imagine that facebook or youtube, now that they have implemented IPv6, felt obliged to give up their IPv4 allocation immediately? It would mean that they were out of business, which I should think might be an excellent business reason to not deploy IPv6. Exactly. Which means that folks deploying IPv6 will keep their IPv4 until no longer needed. Which in turn means that the value of redeploying those returned addresses would be minimal - the Internet would be dominantly IPv6 at that point in time. Cheers, -Benson From ryan at deadfrog.net Fri Feb 4 13:23:09 2011 From: ryan at deadfrog.net (Ryan Wilkins) Date: Fri, 4 Feb 2011 13:23:09 -0600 Subject: My upstream ISP does not support IPv6 In-Reply-To: References: <1127264403.2346.1296791643752.JavaMail.root@zimbra.network1.net> Message-ID: <9A142313-6C58-470C-BE80-582D602F64AA@deadfrog.net> >> IPv6 from both of my upstream providers has been "coming soon" for about a year and a half. I'm getting ready to try to enable IPv6 natively with Above.net in the Chicago area. Has anyone had any experience with them? Thanks, Ryan Wilkins From chip.gwyn at gmail.com Fri Feb 4 14:36:57 2011 From: chip.gwyn at gmail.com (chip) Date: Fri, 4 Feb 2011 15:36:57 -0500 Subject: My upstream ISP does not support IPv6 In-Reply-To: <9A142313-6C58-470C-BE80-582D602F64AA@deadfrog.net> References: <1127264403.2346.1296791643752.JavaMail.root@zimbra.network1.net> <9A142313-6C58-470C-BE80-582D602F64AA@deadfrog.net> Message-ID: On Fri, Feb 4, 2011 at 2:23 PM, Ryan Wilkins wrote: >>> IPv6 from both of my upstream providers has been "coming soon" for about a year and a half. > > I'm getting ready to try to enable IPv6 natively with Above.net in the Chicago area. ?Has anyone had any experience with them? > > Thanks, > Ryan Wilkins > Just wanted to throw in my 2 cents.... We're pretty much done with going dual-stack on circuits from Tiscali, GBLX, Cogent, NTT/Verio, XO, and Telia. -- Just my $.02, your mileage may vary,? batteries not included, etc.... From dseagrav at humancapitaldev.com Fri Feb 4 14:39:32 2011 From: dseagrav at humancapitaldev.com (Daniel Seagraves) Date: Fri, 4 Feb 2011 14:39:32 -0600 Subject: Post-Exhaustion-phase "punishment" for early adopters In-Reply-To: <250E0B78-4DC5-4A94-B05A-95F0755C8884@pch.net> References: <4D4C49BE.3030907@hstrauss.co.za> <250E0B78-4DC5-4A94-B05A-95F0755C8884@pch.net> Message-ID: <640AC628-0D14-4194-A195-3A58E6008917@humancapitaldev.com> On Feb 4, 2011, at 1:11 PM, Bill Woodcock wrote: > No, and in fact, I believe all the RIRs will probably do a reasonably brisk business in reclamation and reallocation, albeit in ever smaller blocks. As holder of a small block, this scares and irritates me. It scares me that I might lose my autonomy and future expansion through no fault of my own, and it irritates me that the reason I may be forced to give up my address space will probably be to satisfy the internet's desperate need for more spam cannons. From patrick at ianai.net Fri Feb 4 14:41:52 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 4 Feb 2011 15:41:52 -0500 Subject: Post-Exhaustion-phase "punishment" for early adopters In-Reply-To: <640AC628-0D14-4194-A195-3A58E6008917@humancapitaldev.com> References: <4D4C49BE.3030907@hstrauss.co.za> <250E0B78-4DC5-4A94-B05A-95F0755C8884@pch.net> <640AC628-0D14-4194-A195-3A58E6008917@humancapitaldev.com> Message-ID: <5C82B551-CE7D-4838-BC7D-150FE6DB108C@ianai.net> On Feb 4, 2011, at 3:39 PM, Daniel Seagraves wrote: > On Feb 4, 2011, at 1:11 PM, Bill Woodcock wrote: > >> No, and in fact, I believe all the RIRs will probably do a reasonably brisk business in reclamation and reallocation, albeit in ever smaller blocks. > > As holder of a small block, this scares and irritates me. It scares me that I might lose my autonomy and future expansion through no fault of my own, and it irritates me that the reason I may be forced to give up my address space will probably be to satisfy the internet's desperate need for more spam cannons. If you are using your block, why would you worry? If not are not using your block, why would you need it? -- TTFN, patrick From woody at pch.net Fri Feb 4 14:44:27 2011 From: woody at pch.net (Bill Woodcock) Date: Fri, 4 Feb 2011 12:44:27 -0800 Subject: Post-Exhaustion-phase "punishment" for early adopters In-Reply-To: <640AC628-0D14-4194-A195-3A58E6008917@humancapitaldev.com> References: <4D4C49BE.3030907@hstrauss.co.za> <250E0B78-4DC5-4A94-B05A-95F0755C8884@pch.net> <640AC628-0D14-4194-A195-3A58E6008917@humancapitaldev.com> Message-ID: <642D51E4-0521-49C5-A1CE-43704AED03C0@pch.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 4, 2011, at 1:11 PM, Bill Woodcock wrote: > >> No, and in fact, I believe all the RIRs will probably do a reasonably brisk business in reclamation and reallocation, albeit in ever smaller blocks. On Feb 4, 2011, at 12:39 PM, Daniel Seagraves wrote: > As holder of a small block, this scares and irritates me. It scares me that I might lose my autonomy and future expansion through no fault of my own, and it irritates me that the reason I may be forced to give up my address space will probably be to satisfy the internet's desperate need for more spam cannons. Excuse me, "reclamation" was probably the wrong word choice on my part. What I was intending to convey was "processing of returned blocks." And the use for the ever-smaller blocks is not for spammers, but for the IPv4 side of 4-to-6 NATs. -Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk1MZSwACgkQGvQy4xTRsBEdqACcDnngVari/dTZrt+ha9P8trct 7J4AoJDftyNiU/lB2+nHZPJrTlIkzJGE =Aaf9 -----END PGP SIGNATURE----- From marka at isc.org Fri Feb 4 15:20:57 2011 From: marka at isc.org (Mark Andrews) Date: Sat, 05 Feb 2011 08:20:57 +1100 Subject: quietly.... In-Reply-To: Your message of "Fri, 04 Feb 2011 12:30:46 -0000." References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <437F22E3-154B-4DD2-B37B-8BC54D116B40@delong.com> <9F2mjoD95cSNFAI6@perry.co.uk> <5A055785-D55E-47A3-87B0-58B0DE81F60E@delong.com> <20110203220604.A8BAE9A5102@drugs.dv.isc.org> <20110204000954.A64C79A9FED@drugs.dv.isc.org> Message-ID: <20110204212057.957EB9B1CE4@drugs.dv.isc.org> In message , Roland Perry writes: > In article <20110204000954.A64C79A9FED at drugs.dv.isc.org>, Mark Andrews > writes > >> These are just my straw poll of what may be difficult for small > >> enterprises in a change to IPv6. > > > >It isn't "change to", its "add IPv6". > > > >I expect to see IPv4 used for years inside homes and enterprises > >where there is enough IPv4 addresses to meet the internal needs. > >It's external communication which needs to switch to IPv6. Internal > >communication just comes along for the ride. > > If people start supplying CPE that are running IPv6 on the outside and > IPv4 NAT in the inside, then that would just fine, in the sense that the > users (in this case including the self-administrators of these small > enterprise networks) won't notice the difference. > -- > Roland Perry They exist are starting to exist and the feature sets keep expanding. I just wish that all vendors would stop shipping IPv4 only equipement. For example the D-LINK DIR-615 does just about everything upsteam except SLAAC which you want if you want to insert it into the middle of your network and not at the border. I havn't explictly asked D-LINK about SLAAC upstream but I couldn't find it in the manual. Newer firmware I believe does PD (again not in the manuals on the web). D-LINK claim they have routers that do 6rd. The DIR-615 is priced within a home budget but at the upper end. I was looking to buy one for home. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From rcarpen at network1.net Fri Feb 4 15:29:17 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Fri, 4 Feb 2011 16:29:17 -0500 (EST) Subject: My upstream ISP does not support IPv6 In-Reply-To: Message-ID: <1343053635.2713.1296854957303.JavaMail.root@zimbra.network1.net> > On Fri, Feb 4, 2011 at 2:23 PM, Ryan Wilkins > wrote: > >>> IPv6 from both of my upstream providers has been "coming soon" for > >>> about a year and a half. > > > > I'm getting ready to try to enable IPv6 natively with Above.net in > > the Chicago area. Has anyone had any experience with them? > > > > Thanks, > > Ryan Wilkins > > > > Just wanted to throw in my 2 cents.... > > We're pretty much done with going dual-stack on circuits from Tiscali, > GBLX, Cogent, NTT/Verio, XO, and Telia. > > -- > Just my $.02, your mileage may vary, batteries not included, etc.... Done as in it is complete and working? Or done as in you gave up trying? -Randy From marka at isc.org Fri Feb 4 15:32:59 2011 From: marka at isc.org (Mark Andrews) Date: Sat, 05 Feb 2011 08:32:59 +1100 Subject: quietly.... In-Reply-To: Your message of "Fri, 04 Feb 2011 11:40:42 CDT." <201102041140.42719.lowen@pari.edu> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <5FDDAD27-71F3-44FE-B195-4E0F27F09EC5@megacity.org> <201102041140.42719.lowen@pari.edu> Message-ID: <20110204213259.E2FE29B1DED@drugs.dv.isc.org> In message <201102041140.42719.lowen at pari.edu>, Lamar Owen writes: > On Friday, February 04, 2011 09:05:09 am Derek J. Balling wrote: > > I think they'll eventually notice a difference. How will an IPv4-only inter > nal host know what to do with an IPv6 AAAA record it gets from a DNS lookup? > > If the CPE is doing DNS proxy (most do) then it can map the AAAA record to an > A record it passes to the internal client, with an internal address for the > record chosen from RFC1918 space, and perform IPv4-IPv6 1:1 NAT from the assi > gned RFC1918 address to the external IPv6 address from the AAAA record (since > you have at least a /64 at your CPE, you can even use the RFC1918 address in > the lower 32 bits.... :-P). > > This may already be a standard, or a draft, or implemented somewhere; I don't > know. But that is how I would do it, just thinking off the top of my head. > DS-lite delivers a IPv4 softwire over a IPv6 upstream. It also introduces less problems than NAT64 as it works with DNSSEC and with IPv4 literal. Along with DS-lite there is a UPNP replacement designed to work with distributed NATs (DS-Lite (AFTR+B4) and NAT444 (LSN + CPE NAT)) so that holes can be punched threw multiple devices if needed. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jared at puck.nether.net Fri Feb 4 15:36:20 2011 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 4 Feb 2011 16:36:20 -0500 Subject: quietly.... In-Reply-To: <20110204213259.E2FE29B1DED@drugs.dv.isc.org> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <5FDDAD27-71F3-44FE-B195-4E0F27F09EC5@megacity.org> <201102041140.42719.lowen@pari.edu> <20110204213259.E2FE29B1DED@drugs.dv.isc.org> Message-ID: On Feb 4, 2011, at 4:32 PM, Mark Andrews wrote: > > In message <201102041140.42719.lowen at pari.edu>, Lamar Owen writes: >> On Friday, February 04, 2011 09:05:09 am Derek J. Balling wrote: >>> I think they'll eventually notice a difference. How will an IPv4-only inter >> nal host know what to do with an IPv6 AAAA record it gets from a DNS lookup? >> >> If the CPE is doing DNS proxy (most do) then it can map the AAAA record to an >> A record it passes to the internal client, with an internal address for the >> record chosen from RFC1918 space, and perform IPv4-IPv6 1:1 NAT from the assi >> gned RFC1918 address to the external IPv6 address from the AAAA record (since >> you have at least a /64 at your CPE, you can even use the RFC1918 address in >> the lower 32 bits.... :-P). >> >> This may already be a standard, or a draft, or implemented somewhere; I don't >> know. But that is how I would do it, just thinking off the top of my head. >> > > DS-lite delivers a IPv4 softwire over a IPv6 upstream. It also > introduces less problems than NAT64 as it works with DNSSEC and > with IPv4 literal. Along with DS-lite there is a UPNP replacement > designed to work with distributed NATs (DS-Lite (AFTR+B4) and NAT444 > (LSN + CPE NAT)) so that holes can be punched threw multiple devices > if needed. I've yet to see a version of ALG that isn't buggy (eg: Cisco SIP-ALG, 2Wire/ATT uverse sip-alg is seriously broken, same for either dlink or netgear... we have to turn it off otherwise it does bad things). I'm sure that LSN activity is going to work "great" for the carriers. *shakes head* - jared From jared at puck.nether.net Fri Feb 4 15:38:02 2011 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 4 Feb 2011 16:38:02 -0500 Subject: My upstream ISP does not support IPv6 In-Reply-To: <1343053635.2713.1296854957303.JavaMail.root@zimbra.network1.net> References: <1343053635.2713.1296854957303.JavaMail.root@zimbra.network1.net> Message-ID: <029BB8D0-BCBF-4E62-AA5F-6E44B4EC08D8@puck.nether.net> On Feb 4, 2011, at 4:29 PM, Randy Carpenter wrote: > >> On Fri, Feb 4, 2011 at 2:23 PM, Ryan Wilkins >> wrote: >>>>> IPv6 from both of my upstream providers has been "coming soon" for >>>>> about a year and a half. >>> >>> I'm getting ready to try to enable IPv6 natively with Above.net in >>> the Chicago area. Has anyone had any experience with them? >>> >>> Thanks, >>> Ryan Wilkins >>> >> >> Just wanted to throw in my 2 cents.... >> >> We're pretty much done with going dual-stack on circuits from Tiscali, >> GBLX, Cogent, NTT/Verio, XO, and Telia. >> >> -- >> Just my $.02, your mileage may vary, batteries not included, etc.... > > Done as in it is complete and working? Or done as in you gave up trying? Speaking as the NTT (2914) people, i'm sure it's working. If it's not, they should phone support. IPv6 is a production service with production support. It would also break a fair amount of internal stuff if our IPv6 was not working properly. - Jared From pekkas at netcore.fi Fri Feb 4 15:42:33 2011 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 4 Feb 2011 23:42:33 +0200 (EET) Subject: quietly.... In-Reply-To: References: Message-ID: Semi-OT: "You are now what we need you to be. A beaten, resentful people who will have to rebuild, who will have to rely on our.. good graces. Who can be used and.. guided as we wish to guide you. Perfect ground for us to do our work.. Quietly, quietly." Sorry. From jared at puck.nether.net Fri Feb 4 15:45:34 2011 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 4 Feb 2011 16:45:34 -0500 Subject: Post-Exhaustion-phase "punishment" for early adopters In-Reply-To: <5C82B551-CE7D-4838-BC7D-150FE6DB108C@ianai.net> References: <4D4C49BE.3030907@hstrauss.co.za> <250E0B78-4DC5-4A94-B05A-95F0755C8884@pch.net> <640AC628-0D14-4194-A195-3A58E6008917@humancapitaldev.com> <5C82B551-CE7D-4838-BC7D-150FE6DB108C@ianai.net> Message-ID: <4097D073-B087-4B97-BD23-51B80C3BC313@puck.nether.net> On Feb 4, 2011, at 3:41 PM, Patrick W. Gilmore wrote: > On Feb 4, 2011, at 3:39 PM, Daniel Seagraves wrote: >> On Feb 4, 2011, at 1:11 PM, Bill Woodcock wrote: >> >>> No, and in fact, I believe all the RIRs will probably do a reasonably brisk business in reclamation and reallocation, albeit in ever smaller blocks. >> >> As holder of a small block, this scares and irritates me. It scares me that I might lose my autonomy and future expansion through no fault of my own, and it irritates me that the reason I may be forced to give up my address space will probably be to satisfy the internet's desperate need for more spam cannons. > > If you are using your block, why would you worry? > > If not are not using your block, why would you need it? Likely because some devices still don't implement IPv6 bootstrap. Try to recover a Cisco router via TFTP boot in an IPv6 only environment. I have been trying to remind my vendors to think about IPv6 first and IPv4 as a secondary capability to supplement it, I do encourage everyone to make this part of your procurement of any equipment in 2011 and beyond. eg: If your DNS provider doesn't do IPv6, switch. (has tucows solved the AAAA glue issue yet? i think i need to switch... and no, i don't feel like using a hack process via a web form, I actually want real automated interfaces and support...) - Jared From justin.horstman at gorillanation.com Fri Feb 4 15:49:39 2011 From: justin.horstman at gorillanation.com (Justin Horstman) Date: Fri, 4 Feb 2011 13:49:39 -0800 Subject: External sanity checks In-Reply-To: <20110204175021.GB5781@mta.tifosi.com> References: <844412.30168.qm@web30804.mail.mud.yahoo.com> <19C36902-4D62-4F3E-A4C3-6EDF72D8E62C@equinix.com> <8C164D3BAF7C7F41B9B286385037B1311909D817F7@lax-exch-fe-01.gorillanation.local> <20110204175021.GB5781@mta.tifosi.com> Message-ID: <8C164D3BAF7C7F41B9B286385037B1311909D817F9@lax-exch-fe-01.gorillanation.local> > -----Original Message----- > From: R A Lichtensteiger [mailto:rali+nanog at tifosi.com] > Sent: Friday, February 04, 2011 9:50 AM > To: Justin Horstman > Cc: nanog > Subject: Re: External sanity checks > > Justin Horstman wrote: > > <> +1 vote for Gomez, they are the most advanced and most capable in > <> this space. They are also not very cheap... > > And Gomez' service contracts include automatic rollover. -1 on Gomez > > R > -- > R A Lichtensteiger rali at tifosi.com You can easily ask them to take that out. Never had an issue with them removing that from their contracts. In fact, there has never been any part of their aup, tos, or any other agreement that they were not willing to change to meet our needs. *shrugs* Your millage may vary. ~J From chip.gwyn at gmail.com Fri Feb 4 15:50:48 2011 From: chip.gwyn at gmail.com (chip) Date: Fri, 4 Feb 2011 16:50:48 -0500 Subject: My upstream ISP does not support IPv6 In-Reply-To: <029BB8D0-BCBF-4E62-AA5F-6E44B4EC08D8@puck.nether.net> References: <1343053635.2713.1296854957303.JavaMail.root@zimbra.network1.net> <029BB8D0-BCBF-4E62-AA5F-6E44B4EC08D8@puck.nether.net> Message-ID: On Fri, Feb 4, 2011 at 4:38 PM, Jared Mauch wrote: > > On Feb 4, 2011, at 4:29 PM, Randy Carpenter wrote: > >> >>> On Fri, Feb 4, 2011 at 2:23 PM, Ryan Wilkins >>> wrote: >>>>>> IPv6 from both of my upstream providers has been "coming soon" for >>>>>> about a year and a half. >>>> >>>> I'm getting ready to try to enable IPv6 natively with Above.net in >>>> the Chicago area. Has anyone had any experience with them? >>>> >>>> Thanks, >>>> Ryan Wilkins >>>> >>> >>> Just wanted to throw in my 2 cents.... >>> >>> We're pretty much done with going dual-stack on circuits from Tiscali, >>> GBLX, Cogent, NTT/Verio, XO, and Telia. >>> >>> -- >>> Just my $.02, your mileage may vary, batteries not included, etc.... >> >> Done as in it is complete and working? Or done as in you gave up trying? > > Speaking as the NTT (2914) people, i'm sure it's working. ?If it's not, they should phone support. ?IPv6 is a production service with production support. > > It would also break a fair amount of internal stuff if our IPv6 was not working properly. > > - Jared Done as in having circuits in multiple pops in production. Several more providers should be coming online in Q1/Q2. --chip -- Just my $.02, your mileage may vary,? batteries not included, etc.... From patrick at ianai.net Fri Feb 4 15:51:12 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 4 Feb 2011 16:51:12 -0500 Subject: Post-Exhaustion-phase "punishment" for early adopters In-Reply-To: <4097D073-B087-4B97-BD23-51B80C3BC313@puck.nether.net> References: <4D4C49BE.3030907@hstrauss.co.za> <250E0B78-4DC5-4A94-B05A-95F0755C8884@pch.net> <640AC628-0D14-4194-A195-3A58E6008917@humancapitaldev.com> <5C82B551-CE7D-4838-BC7D-150FE6DB108C@ianai.net> <4097D073-B087-4B97-BD23-51B80C3BC313@puck.nether.net> Message-ID: On Feb 4, 2011, at 4:45 PM, Jared Mauch wrote: > On Feb 4, 2011, at 3:41 PM, Patrick W. Gilmore wrote: >> On Feb 4, 2011, at 3:39 PM, Daniel Seagraves wrote: >>> On Feb 4, 2011, at 1:11 PM, Bill Woodcock wrote: >>> >>>> No, and in fact, I believe all the RIRs will probably do a reasonably brisk business in reclamation and reallocation, albeit in ever smaller blocks. >>> >>> As holder of a small block, this scares and irritates me. It scares me that I might lose my autonomy and future expansion through no fault of my own, and it irritates me that the reason I may be forced to give up my address space will probably be to satisfy the internet's desperate need for more spam cannons. >> >> If you are using your block, why would you worry? >> >> If not are not using your block, why would you need it? > > Likely because some devices still don't implement IPv6 bootstrap. Try to recover a Cisco router via TFTP boot in an IPv6 only environment. > > I have been trying to remind my vendors to think about IPv6 first and IPv4 as a secondary capability to supplement it, I do encourage everyone to make this part of your procurement of any equipment in 2011 and beyond. > > eg: If your DNS provider doesn't do IPv6, switch. (has tucows solved the AAAA glue issue yet? i think i need to switch... and no, i don't feel like using a hack process via a web form, I actually want real automated interfaces and support...) I'm a little confused. Sounds like the things you are talking about all fall into the "if you are using your block" category, so he shouldn't worry. ARIN should not reclaim a block that is in use. Unless I am confused? (Happens a lot, especially as I get older.) -- TTFN, patrick From hayden at nextlevelinternet.com Fri Feb 4 15:49:09 2011 From: hayden at nextlevelinternet.com (Hayden Katzenellenbogen) Date: Fri, 4 Feb 2011 13:49:09 -0800 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <4D4BAD13.9090301@gmail.com> References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> <96503CEA-C922-47A6-9691-FCF157DF15D5@internode.com.au> <10A940BA-6D90-4663-B942-5FFF2CB49D7A@internode.com.au> <4D4BAD13.9090301@gmail.com> Message-ID: <88BC6885D33A9D42A1CCB45E8749525E013CBC58@pigeon.sandiego.nextlevelinternet.com> Not sure if it has been said already but wasn't one of the key point for the creation of the internet to create and infrastructure that would survive in the case of all out war and massive destruction. (strategic nuclear strikes) Does it not bode ill for "national security" if any party could take out a massive communication system by destroying/pressuring a few choke points? -----Original Message----- From: JC Dill [mailto:jcdill.lists at gmail.com] Sent: Thursday, February 03, 2011 11:39 PM To: NANOG list Subject: Re: Weekend Gedankenexperiment - The Kill Switch On 03/02/11 10:38 PM, Paul Ferguson wrote: > > And as an aside, governments will always believe that that they can control > the flow of information, when push comes to shove. > > This has always been a hazard, and will always continue to be so. > > As technologists, we need to be cognizant of that fact. In the US, by accident (surely not by design) we are lucky that our network of networks does not have the convenient 4 chokepoints that the Egyptian network had, making it easy for the government to shut off the entier internet by putting pressure on just 4 companies. Where we *really* need to be fighting this battle is in the laws and policies that are producing a duopoly in much of the US where consumers have 2 choices, the ILEC for DSL or their local cableco for Cable Internet. As theses companies push smaller competing ISPs out of business, and as they consolidate (e.g. Cablecos buying each other up, resulting in fewer and fewer cablecos over time), we head down the direction of Egypt, where pressure on just a few companies CAN shut down the entire internet. Otherwise we end up with a few companies that will play Visa and PayPal and roll over and play dead when a government official says "Wikileaks is bad" - and equally easily will shut down their entire networks for "national security". If you *really* believe that the TSA is effective, you would be in favor of an Internet Kill Switch. If you understand that this is really security theater, and despite all the inconvenience we aren't really any safer, then you should equally be very concerned that someone ever has the power to order that the internet be "shut down" for our safety. jc From marka at isc.org Fri Feb 4 15:54:30 2011 From: marka at isc.org (Mark Andrews) Date: Sat, 05 Feb 2011 08:54:30 +1100 Subject: quietly.... In-Reply-To: Your message of "Fri, 04 Feb 2011 13:04:00 CDT." References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> <483E6B0272B0284BA86D7596C40D29F9011F76964E94@PUR-EXCH07.ox.com> <37955.1296761312@localhost> <201102031520.26126.lowen@pari.edu> <48563.1296769591@localhost> Message-ID: <20110204215430.0BEA09B1F01@drugs.dv.isc.org> In message , david rai strick writes: > > On Thu, 3 Feb 2011, Owen DeLong wrote: > > > Er. ?That's not news. ?That's been the state of the art for > > what, 15+ years or so now? ??SIP (because it's peer to peer) and > > P2P are really the only things that actually give a damn about > > it. > > > > Largely because we've been living with the tradeoff that we had to break th > e > > end-to-end model to temporarily compensate for an address shortage. Those o > f > > us that remember life before NAT would prefer not to bring this damage > > forward into an area of address abundance. In other words, yes, we gave up > > > Life before NAT, and firewalls (with or without SPI) on every PC and every > CPI, also was life before mass consuption of internet access by the > "normal" folks. And before extensive cellular and wifi networks for > internet access. And before many of today's (common end user PC) > security issues had been discovered. > > > Firewalls -destroy- the "end to end" model. You don't get inbound > connectivity past the firewall unless a rule is explicitly created. > That's no different than NAT requiring specific work to be done. No, they don't. "end to end" is about knowing how to reach everybody whether that is permitted or not. > Firewalls are not going away, if anything the continuing expansion of > consumer users will create more and more breakage of the > open-everything-connects-to-everything model, regardless of what the core > engineering teams may want. While it may be the default it should also be able to be turned off. CPE devices are not just uses at the edges of networks. The same boxes are used inside networks. > Hell, even without CPE doing it, many residential ISPs (regardless of NAT) > block inbound traffic to consumers. Some ISP's do lots of stupid things. > The end-to-end model ended a long long time ago....maybe it will come > back, but I rather doubt it. > > > We'll continue to have users, who run client software, and providers, who > run server software. And a mix in between, because the user end can > CHOOSE to enable server functionality (with their feet, by choosing a new > ISP, at their firewall and or NAT device, and by enabling "server" > software). > > > NAT doesn't destroy end-to-end. It just makes it slightly more difficult. > But no more difficult that turning on a firewall does. Actually its a lot more difficult. > It doesn't break anything that isn't trying to "announce" itself - and > imo, applications that want to "announce" themselves seem like a > pretty big security hole. Web browsers are much bigger security holes running arbitry code because some web page developer thought it would look nice. Most servers are written assuming the input stream is hostile. I run machines all the time that don't have firewall to protect them from the big wide world out there. I suspect we all do. Your not behind a external firewall when you are at NANOG or IETF. Everyone doesn't suddenly get "owned" because there isn't a external firewall. Modern OS's default to secure. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From lists at internetpolicyagency.com Fri Feb 4 15:57:12 2011 From: lists at internetpolicyagency.com (Roland Perry) Date: Fri, 4 Feb 2011 21:57:12 +0000 Subject: quietly.... In-Reply-To: References: <16075456.4557.1296760302037.JavaMail.root@benjamin.baylink.com> Message-ID: In article , Brian Johnson writes >Some people have no perspective on what the Internet is and it's real >power. I've met too many people who claim to be "in the know" on these >topics that don't understand that NAT was designed for address >preservation. Especially as most (I guess) users of NATing CPEs only have one dynamic IP address, of which they are generally oblivious. I have a feeling that the first NAT box I had (maybe 12 years ago), connected to the Internet by dial-up, where traditionally the user inherits the IP address (singular) of the modem/gateway they dialled into, even if they have multiple hosts on their premises. >That was the only/primary/driving real reason for its development. The >other "features" were side effects and are not intended to be solutions >to production issues. But NAT does have the useful (I think) side effect that I don't have to renumber my network when I change upstream providers - whether that's once every five years like I just did with my ADSL, or once every time the new ADSL hiccups[1] now that I have a CPE with 3G failover. [1] Seems to be about weekly, so far. -- Roland Perry From cidr-report at potaroo.net Fri Feb 4 16:00:02 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 4 Feb 2011 22:00:02 GMT Subject: BGP Update Report Message-ID: <201102042200.p14M02Ok017481@wattle.apnic.net> BGP Update Report Interval: 27-Jan-11 -to- 03-Feb-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS1785 20007 1.2% 11.5 -- AS-PAETEC-NET - PaeTec Communications, Inc. 2 - AS32528 19157 1.2% 6385.7 -- ABBOTT Abbot Labs 3 - AS33475 18844 1.2% 87.6 -- RSN-1 - RockSolid Network, Inc. 4 - AS9829 18671 1.2% 24.7 -- BSNL-NIB National Internet Backbone 5 - AS25019 17673 1.1% 80.3 -- SAUDINETSTC-AS Autonomus System Number for SaudiNet 6 - AS35931 17566 1.1% 5855.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 7 - AS17974 15439 1.0% 12.9 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 8 - AS8452 14957 0.9% 9.1 -- TE-AS TE-AS 9 - AS25438 14011 0.9% 159.2 -- ASN-ICCNET International Computer Company ICC 10 - AS24560 12621 0.8% 11.5 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 11 - AS24923 11525 0.7% 1280.6 -- SETTC South-East Transtelecom Joint Stock Co. 12 - AS49571 11245 0.7% 591.8 -- CELLNET-AS CellNet ltd ASN block 13 - AS17908 10934 0.7% 13.3 -- TCISL Tata Communications 14 - AS9498 10913 0.7% 14.6 -- BBIL-AP BHARTI Airtel Ltd. 15 - AS24528 9821 0.6% 1227.6 -- SINERGI-AS-ID PT. Sinergitama Komindo 16 - AS6316 8868 0.6% 84.5 -- AS-PAETEC-NET - PaeTec Communications, Inc. 17 - AS15105 8563 0.5% 31.8 -- NETWORKTELEPHONE - Network Telephone Corporation 18 - AS24554 8414 0.5% 70.1 -- FIVE-NET-AS-IN Fivenetwork Solution India Pvt Ltd Internet 19 - AS24863 8039 0.5% 10.5 -- LINKdotNET-AS 20 - AS14522 7367 0.5% 17.4 -- Satnet TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS32528 19157 1.2% 6385.7 -- ABBOTT Abbot Labs 2 - AS35931 17566 1.1% 5855.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 3 - AS40772 6994 0.4% 3497.0 -- VELOCITER-WIRELESS-INC - Velociter Wireless, Inc. 4 - AS49776 2212 0.1% 2212.0 -- GORSET-AS Gorodskaya Set Ltd. 5 - AS6401 2202 0.1% 2202.0 -- ALLST-6401 - Allstream Corp. 6 - AS11943 2182 0.1% 2182.0 -- GLOBE - Globe Wireless 7 - AS49600 1744 0.1% 1744.0 -- LASEDA La Seda de Barcelona, S.A 8 - AS24923 11525 0.7% 1280.6 -- SETTC South-East Transtelecom Joint Stock Co. 9 - AS24528 9821 0.6% 1227.6 -- SINERGI-AS-ID PT. Sinergitama Komindo 10 - AS34239 1164 0.1% 1164.0 -- INTERAMERICAN General Insurance Company 11 - AS35914 1495 0.1% 747.5 -- FIREHOST-INC - FireHost, Inc. 12 - AS9929 6375 0.4% 708.3 -- CNCNET-CN China Netcom Corp. 13 - AS2055 4878 0.3% 609.8 -- LSU-1 - Louisiana State University 14 - AS49571 11245 0.7% 591.8 -- CELLNET-AS CellNet ltd ASN block 15 - AS12190 532 0.0% 532.0 -- OOCL-NET - OOCL (USA), Inc. 16 - AS45550 502 0.0% 502.0 -- NGT-AS-VN New Generations Telecommunications Corporation 17 - AS51493 499 0.0% 499.0 -- UNITEL Unitel LLC 18 - AS47865 483 0.0% 483.0 -- LIBERTYSIG-ASN Liberty Sigorta AS Num 19 - AS5323 463 0.0% 463.0 -- DNIC-ASBLK-05120-05376 - DoD Network Information Center 20 - AS50623 445 0.0% 445.0 -- INFOTECH Infotech LLC TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 213.129.96.0/19 11506 0.7% AS24923 -- SETTC South-East Transtelecom Joint Stock Co. 2 - 63.211.68.0/22 11470 0.7% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 3 - 130.36.34.0/24 9576 0.6% AS32528 -- ABBOTT Abbot Labs 4 - 130.36.35.0/24 9576 0.6% AS32528 -- ABBOTT Abbot Labs 5 - 216.126.136.0/22 7890 0.5% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 6 - 198.140.43.0/24 6048 0.4% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 7 - 202.92.235.0/24 5309 0.3% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 8 - 68.65.152.0/22 3769 0.2% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 9 - 208.89.36.0/22 3497 0.2% AS40772 -- VELOCITER-WIRELESS-INC - Velociter Wireless, Inc. 10 - 74.116.44.0/22 3497 0.2% AS40772 -- VELOCITER-WIRELESS-INC - Velociter Wireless, Inc. 11 - 202.153.174.0/24 3320 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 12 - 183.88.0.0/16 3312 0.2% AS45629 -- JASTEL-NETWORK-TH-AP Jasmine International Tower AS45758 -- TRIPLETNET-AS-AP TripleT Internet Internet service provider Bangkok 13 - 206.184.16.0/24 3222 0.2% AS174 -- COGENT Cogent/PSI 14 - 67.210.226.0/24 2977 0.2% AS35914 -- FIREHOST-INC - FireHost, Inc. AS7819 -- GLOBAL-IP-NETWORKS - Global IP Networks INC 15 - 213.108.216.0/21 2212 0.1% AS49776 -- GORSET-AS Gorodskaya Set Ltd. 16 - 159.18.255.0/24 2202 0.1% AS6401 -- ALLST-6401 - Allstream Corp. 17 - 208.244.255.0/24 2182 0.1% AS11943 -- GLOBE - Globe Wireless 18 - 223.206.0.0/16 1909 0.1% AS45629 -- JASTEL-NETWORK-TH-AP Jasmine International Tower AS45758 -- TRIPLETNET-AS-AP TripleT Internet Internet service provider Bangkok 19 - 114.128.0.0/16 1897 0.1% AS45629 -- JASTEL-NETWORK-TH-AP Jasmine International Tower AS45758 -- TRIPLETNET-AS-AP TripleT Internet Internet service provider Bangkok 20 - 168.96.253.0/24 1860 0.1% AS3597 -- Asociacion Civil Ciencia Hoy Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Feb 4 16:00:01 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 4 Feb 2011 22:00:01 GMT Subject: The Cidr Report Message-ID: <201102042200.p14M01Fq017475@wattle.apnic.net> This report has been generated at Fri Feb 4 21:11:48 2011 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 28-01-11 342381 201194 29-01-11 342501 201083 30-01-11 342538 201134 31-01-11 342694 201113 01-02-11 342820 201369 02-02-11 342953 202987 03-02-11 345793 203290 04-02-11 345917 203451 AS Summary 36655 Number of ASes in routing system 15526 Number of ASes announcing only one prefix 3704 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 106681344 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 04Feb11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 346451 203367 143084 41.3% All ASes AS6389 3704 270 3434 92.7% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 2612 408 2204 84.4% TWTC - tw telecom holdings, inc. AS19262 1842 283 1559 84.6% VZGNI-TRANSIT - Verizon Online LLC AS4766 1914 543 1371 71.6% KIXS-AS-KR Korea Telecom AS6478 1482 230 1252 84.5% ATT-INTERNET3 - AT&T Services, Inc. AS22773 1278 87 1191 93.2% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1410 336 1074 76.2% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS1785 1788 763 1025 57.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS28573 1238 303 935 75.5% NET Servicos de Comunicao S.A. AS7545 1620 724 896 55.3% TPG-INTERNET-AP TPG Internet Pty Ltd AS10620 1357 481 876 64.6% Telmex Colombia S.A. AS6503 1188 410 778 65.5% Axtel, S.A.B. de C.V. AS18101 925 153 772 83.5% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS24560 1099 339 760 69.2% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7303 887 129 758 85.5% Telecom Argentina S.A. AS4808 1038 321 717 69.1% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS3356 1194 496 698 58.5% LEVEL3 Level 3 Communications AS9498 754 78 676 89.7% BBIL-AP BHARTI Airtel Ltd. AS8151 1341 668 673 50.2% Uninet S.A. de C.V. AS17488 952 279 673 70.7% HATHWAY-NET-AP Hathway IP Over Cable Internet AS18566 1182 511 671 56.8% COVAD - Covad Communications Co. AS11492 1264 648 616 48.7% CABLEONE - CABLE ONE, INC. AS17676 648 70 578 89.2% GIGAINFRA Softbank BB Corp. AS855 633 58 575 90.8% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS7552 642 93 549 85.5% VIETEL-AS-AP Vietel Corporation AS36992 635 89 546 86.0% ETISALAT-MISR AS14420 625 100 525 84.0% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS22047 548 29 519 94.7% VTR BANDA ANCHA S.A. AS3549 869 358 511 58.8% GBLX Global Crossing Ltd. AS9443 570 75 495 86.8% INTERNETPRIMUS-AS-AP Primus Telecommunications Total 37239 9332 27907 74.9% Top 30 total Possible Bogus Routes 5.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 5.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 5.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 24.129.192.0/19 AS7922 COMCAST-7922 - Comcast Cable Communications, Inc. 37.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 37.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 37.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.78.228.0/22 AS5713 SAIX-NET 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.18.224.0/20 AS12129 123NET - 123.Net, Inc. 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 72.22.32.0/19 AS33150 72.22.61.0/24 AS33150 72.22.62.0/24 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 96.45.161.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.162.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.163.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.164.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.165.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.166.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.167.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.168.0/21 AS3257 TINET-BACKBONE Tinet SpA 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 110.173.64.0/19 AS37963 CNNIC-ALIBABA-CN-NET-AP Alibaba (China) Technology Co., Ltd. 115.42.28.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.30.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.40.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.42.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.44.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.47.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.48.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.49.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.50.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.51.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.52.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.53.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.54.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.55.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.56.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.57.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.58.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.59.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.61.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.62.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.63.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 116.68.136.0/21 AS28045 Pantel Communications 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.54.160.0/24 AS38890 121.54.161.0/24 AS38890 121.54.162.0/24 AS38890 121.54.163.0/24 AS38890 121.54.164.0/24 AS38890 121.54.166.0/24 AS38890 121.54.167.0/24 AS38890 139.0.0.0/16 AS38639 HANABI NTT Communications Corporation 139.9.0.0/16 AS38639 HANABI NTT Communications Corporation 139.101.0.0/16 AS38639 HANABI NTT Communications Corporation 139.129.0.0/16 AS38639 HANABI NTT Communications Corporation 139.148.0.0/16 AS38639 HANABI NTT Communications Corporation 139.150.0.0/16 AS38639 HANABI NTT Communications Corporation 139.155.0.0/16 AS38639 HANABI NTT Communications Corporation 139.159.0.0/16 AS38639 HANABI NTT Communications Corporation 139.170.0.0/16 AS38639 HANABI NTT Communications Corporation 139.176.0.0/16 AS38639 HANABI NTT Communications Corporation 139.183.0.0/16 AS38639 HANABI NTT Communications Corporation 139.186.0.0/16 AS38639 HANABI NTT Communications Corporation 139.189.0.0/16 AS38639 HANABI NTT Communications Corporation 139.190.0.0/16 AS38639 HANABI NTT Communications Corporation 139.192.0.0/12 AS38639 HANABI NTT Communications Corporation 139.208.0.0/13 AS38639 HANABI NTT Communications Corporation 139.216.0.0/14 AS38639 HANABI NTT Communications Corporation 139.220.0.0/15 AS38639 HANABI NTT Communications Corporation 139.224.0.0/16 AS38639 HANABI NTT Communications Corporation 139.226.0.0/15 AS38639 HANABI NTT Communications Corporation 139.228.0.0/16 AS38639 HANABI NTT Communications Corporation 139.255.0.0/16 AS38639 HANABI NTT Communications Corporation 140.0.0.0/16 AS38639 HANABI NTT Communications Corporation 140.75.0.0/16 AS38639 HANABI NTT Communications Corporation 140.143.0.0/16 AS38639 HANABI NTT Communications Corporation 140.149.0.0/16 AS38639 HANABI NTT Communications Corporation 140.205.0.0/16 AS38639 HANABI NTT Communications Corporation 140.206.0.0/15 AS38639 HANABI NTT Communications Corporation 140.210.0.0/16 AS38639 HANABI NTT Communications Corporation 140.213.0.0/16 AS38639 HANABI NTT Communications Corporation 140.224.0.0/16 AS38639 HANABI NTT Communications Corporation 140.237.0.0/16 AS38639 HANABI NTT Communications Corporation 140.240.0.0/16 AS38639 HANABI NTT Communications Corporation 140.243.0.0/16 AS38639 HANABI NTT Communications Corporation 140.246.0.0/16 AS38639 HANABI NTT Communications Corporation 140.249.0.0/16 AS38639 HANABI NTT Communications Corporation 140.250.0.0/16 AS38639 HANABI NTT Communications Corporation 140.255.0.0/16 AS38639 HANABI NTT Communications Corporation 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 144.0.0.0/16 AS38639 HANABI NTT Communications Corporation 144.7.0.0/16 AS38639 HANABI NTT Communications Corporation 144.12.0.0/16 AS38639 HANABI NTT Communications Corporation 144.52.0.0/16 AS38639 HANABI NTT Communications Corporation 144.123.0.0/16 AS38639 HANABI NTT Communications Corporation 144.255.0.0/16 AS38639 HANABI NTT Communications Corporation 150.0.0.0/16 AS38639 HANABI NTT Communications Corporation 150.115.0.0/16 AS38639 HANABI NTT Communications Corporation 150.116.0.0/15 AS38639 HANABI NTT Communications Corporation 150.121.0.0/16 AS38639 HANABI NTT Communications Corporation 150.122.0.0/16 AS38639 HANABI NTT Communications Corporation 150.138.0.0/15 AS38639 HANABI NTT Communications Corporation 150.223.0.0/16 AS38639 HANABI NTT Communications Corporation 150.255.0.0/16 AS38639 HANABI NTT Communications Corporation 153.0.0.0/16 AS38639 HANABI NTT Communications Corporation 153.3.0.0/16 AS38639 HANABI NTT Communications Corporation 153.34.0.0/15 AS38639 HANABI NTT Communications Corporation 153.36.0.0/15 AS38639 HANABI NTT Communications Corporation 153.99.0.0/16 AS38639 HANABI NTT Communications Corporation 153.101.0.0/16 AS38639 HANABI NTT Communications Corporation 153.118.0.0/15 AS38639 HANABI NTT Communications Corporation 153.120.0.0/13 AS38639 HANABI NTT Communications Corporation 153.128.0.0/9 AS38639 HANABI NTT Communications Corporation 157.0.0.0/16 AS38639 HANABI NTT Communications Corporation 157.18.0.0/16 AS38639 HANABI NTT Communications Corporation 157.61.0.0/16 AS38639 HANABI NTT Communications Corporation 157.122.0.0/16 AS38639 HANABI NTT Communications Corporation 157.148.0.0/16 AS38639 HANABI NTT Communications Corporation 157.156.0.0/16 AS38639 HANABI NTT Communications Corporation 157.255.0.0/16 AS38639 HANABI NTT Communications Corporation 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 163.0.0.0/16 AS38639 HANABI NTT Communications Corporation 163.125.0.0/16 AS38639 HANABI NTT Communications Corporation 163.142.0.0/16 AS38639 HANABI NTT Communications Corporation 163.177.0.0/16 AS38639 HANABI NTT Communications Corporation 163.179.0.0/16 AS38639 HANABI NTT Communications Corporation 163.204.0.0/16 AS38639 HANABI NTT Communications Corporation 163.213.0.0/16 AS38639 HANABI NTT Communications Corporation 163.222.0.0/16 AS38639 HANABI NTT Communications Corporation 163.229.0.0/16 AS38639 HANABI NTT Communications Corporation 163.255.0.0/16 AS38639 HANABI NTT Communications Corporation 171.0.0.0/12 AS38639 HANABI NTT Communications Corporation 171.34.0.0/15 AS38639 HANABI NTT Communications Corporation 171.36.0.0/14 AS38639 HANABI NTT Communications Corporation 171.40.0.0/13 AS38639 HANABI NTT Communications Corporation 171.48.0.0/12 AS38639 HANABI NTT Communications Corporation 171.76.0.0/14 AS38639 HANABI NTT Communications Corporation 171.80.0.0/12 AS38639 HANABI NTT Communications Corporation 171.96.0.0/14 AS38639 HANABI NTT Communications Corporation 171.100.0.0/14 AS38639 HANABI NTT Communications Corporation 171.104.0.0/13 AS38639 HANABI NTT Communications Corporation 171.112.0.0/12 AS38639 HANABI NTT Communications Corporation 171.207.0.0/16 AS38639 HANABI NTT Communications Corporation 171.208.0.0/12 AS38639 HANABI NTT Communications Corporation 171.224.0.0/11 AS38639 HANABI NTT Communications Corporation 172.12.0.0/18 AS28665 PredialNet Provedor de Internet Ltda. 176.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.82.176.224/27 AS45976 CNYGE-AS-KR chungcheongnamdo yeongi office of education 181.82.177.0/26 AS45976 CNYGE-AS-KR chungcheongnamdo yeongi office of education 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.101.46.0/24 AS6503 Axtel, S.A.B. de C.V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.15.4.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.15.5.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.175.231.0/24 AS19262 VZGNI-TRANSIT - Verizon Online LLC 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.24.73.0/24 AS26061 Equant Colombia 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.20.108.0/23 AS17885 JKTXLNET-AS-AP PT Excelcomindo Pratama 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.176.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.146.186.0/24 AS23655 SNAP-NZ-AS Snap Internet Limited 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.130.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.133.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.149.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.150.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.18.156.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.22.78.0/24 AS18117 HARBOURMSP-AU-AP Harbour MSP Pty. Ltd 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.27.123.0/24 AS4739 CIX-ADELAIDE-AS Internode Systems Pty Ltd 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.10.232.0/21 AS33150 204.19.14.0/23 AS577 BACOM - Bell Canada 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 205.210.145.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 206.72.192.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.72.194.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.64.200.0/22 AS11730 CIL-ASN - Circle Internet LTD 208.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.73.160.0/24 AS32767 208.78.165.0/24 AS16565 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.89.60.0/22 AS40626 208.92.196.0/22 AS10929 NETELLIGENT - Netelligent Hosting Services Inc. 208.92.199.0/24 AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.10.235.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.10.236.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From drais at icantclick.org Fri Feb 4 16:04:03 2011 From: drais at icantclick.org (david raistrick) Date: Fri, 4 Feb 2011 17:04:03 -0500 (EST) Subject: quietly.... In-Reply-To: <20110204215430.0BEA09B1F01@drugs.dv.isc.org> References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> <483E6B0272B0284BA86D7596C40D29F9011F76964E94@PUR-EXCH07.ox.com> <37955.1296761312@localhost> <201102031520.26126.lowen@pari.edu> <48563.1296769591@localhost> <20110204215430.0BEA09B1F01@drugs.dv.isc.org> Message-ID: > Everyone doesn't suddenly get "owned" because there isn't a external > firewall. Modern OS's default to secure. We clearly live and work in different worlds. Not to mention that "we" are not the average consumers anymore. We were, in the days before NAT (and SPI). -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From bmanning at vacation.karoshi.com Fri Feb 4 16:08:52 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 4 Feb 2011 22:08:52 +0000 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <88BC6885D33A9D42A1CCB45E8749525E013CBC58@pigeon.sandiego.nextlevelinternet.com> References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> <96503CEA-C922-47A6-9691-FCF157DF15D5@internode.com.au> <10A940BA-6D90-4663-B942-5FFF2CB49D7A@internode.com.au> <4D4BAD13.9090301@gmail.com> <88BC6885D33A9D42A1CCB45E8749525E013CBC58@pigeon.sandiego.nextlevelinternet.com> Message-ID: <20110204220852.GC17194@vacation.karoshi.com.> the protocols ability to "route around" failures is an attribute of packet based protocols. it has little to do with legal compliance of an order to cease and desist forwarding packets. end of the day, i guess it boils down to the question of -civil disobedience- if the law is unjust, do you comply because it is the law, or do you protest, at the risk of punishment/death? hardly a wire-protocol question - no? --bill On Fri, Feb 04, 2011 at 01:49:09PM -0800, Hayden Katzenellenbogen wrote: > Not sure if it has been said already but wasn't one of the key point for > the creation of the internet to create and infrastructure that would > survive in the case of all out war and massive destruction. (strategic > nuclear strikes) > > Does it not bode ill for "national security" if any party could take out > a massive communication system by destroying/pressuring a few choke > points? > > -----Original Message----- > From: JC Dill [mailto:jcdill.lists at gmail.com] > Sent: Thursday, February 03, 2011 11:39 PM > To: NANOG list > Subject: Re: Weekend Gedankenexperiment - The Kill Switch > > On 03/02/11 10:38 PM, Paul Ferguson wrote: > > > > And as an aside, governments will always believe that that they can > control > > the flow of information, when push comes to shove. > > > > This has always been a hazard, and will always continue to be so. > > > > As technologists, we need to be cognizant of that fact. > > In the US, by accident (surely not by design) we are lucky that our > network of networks does not have the convenient 4 chokepoints that the > Egyptian network had, making it easy for the government to shut off the > entier internet by putting pressure on just 4 companies. > > Where we *really* need to be fighting this battle is in the laws and > policies that are producing a duopoly in much of the US where consumers > have 2 choices, the ILEC for DSL or their local cableco for Cable > Internet. As theses companies push smaller competing ISPs out of > business, and as they consolidate (e.g. Cablecos buying each other up, > resulting in fewer and fewer cablecos over time), we head down the > direction of Egypt, where pressure on just a few companies CAN shut down > > the entire internet. Otherwise we end up with a few companies that will > > play Visa and PayPal and roll over and play dead when a government > official says "Wikileaks is bad" - and equally easily will shut down > their entire networks for "national security". > > If you *really* believe that the TSA is effective, you would be in favor > > of an Internet Kill Switch. If you understand that this is really > security theater, and despite all the inconvenience we aren't really any > > safer, then you should equally be very concerned that someone ever has > the power to order that the internet be "shut down" for our safety. > > jc > > > From drais at icantclick.org Fri Feb 4 16:24:00 2011 From: drais at icantclick.org (david raistrick) Date: Fri, 4 Feb 2011 17:24:00 -0500 (EST) Subject: quietly.... In-Reply-To: References: <16075456.4557.1296760302037.JavaMail.root@benjamin.baylink.com> Message-ID: On Fri, 4 Feb 2011, Roland Perry wrote: > But NAT does have the useful (I think) side effect that I don't have to > renumber my network when I change upstream providers - whether that's once But (what I keep being told) you should never have to renumber! Get PI space and insert magic here! sigh -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From mpetach at netflight.com Fri Feb 4 16:27:32 2011 From: mpetach at netflight.com (Matthew Petach) Date: Fri, 4 Feb 2011 14:27:32 -0800 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <88BC6885D33A9D42A1CCB45E8749525E013CBC58@pigeon.sandiego.nextlevelinternet.com> References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> <96503CEA-C922-47A6-9691-FCF157DF15D5@internode.com.au> <10A940BA-6D90-4663-B942-5FFF2CB49D7A@internode.com.au> <4D4BAD13.9090301@gmail.com> <88BC6885D33A9D42A1CCB45E8749525E013CBC58@pigeon.sandiego.nextlevelinternet.com> Message-ID: On Fri, Feb 4, 2011 at 1:49 PM, Hayden Katzenellenbogen wrote: > Not sure if it has been said already but wasn't one of the key point for > the creation of the internet to create and infrastructure that would > survive in the case of all out war and massive destruction. (strategic > nuclear strikes) > > Does it not bode ill for "national security" if any party could take out > a massive communication system by destroying/pressuring a few choke > points? As has been noted previously, it's all about your frame of reference. If the US is removed from the Internet, it does not mean the Internet stops working; from the perspective of the rest of the world, the Internet is still there. likewise, when Egypt shut down the internet (from their perspective), it was essentially a complete shutdown, from their viewpoint; nothing on the internet was reachable. This did not mean the Internet shut down; for most of the rest of the world, they barely noticed Egypt was gone. The Internet itself will continue to function, no matter what silliness the US political system attempts to engage in; from the perspective of those in the US, it may appear that "the Internet" is unable to survive such an attack; but from the perspective of the rest of the world, it really will be localized damage in the US, and not at all a case of the Internet being shut down. Matt From dseagrav at humancapitaldev.com Fri Feb 4 16:28:48 2011 From: dseagrav at humancapitaldev.com (Daniel Seagraves) Date: Fri, 4 Feb 2011 16:28:48 -0600 Subject: Post-Exhaustion-phase "punishment" for early adopters In-Reply-To: References: <4D4C49BE.3030907@hstrauss.co.za> <250E0B78-4DC5-4A94-B05A-95F0755C8884@pch.net> <640AC628-0D14-4194-A195-3A58E6008917@humancapitaldev.com> <5C82B551-CE7D-4838-BC7D-150FE6DB108C@ianai.net> <4097D073-B087-4B97-BD23-51B80C3BC313@puck.nether.net> Message-ID: On Feb 4, 2011, at 3:51 PM, Patrick W. Gilmore wrote: > I'm a little confused. Sounds like the things you are talking about all fall into the "if you are using your block" category, so he shouldn't worry. > > ARIN should not reclaim a block that is in use. Unless I am confused? (Happens a lot, especially as I get older.) How many addresses do I have to be using for it to count as in use? How high will that number go in the next few months/years? We have a very old /24 direct allocation from the stone age, when we were a dialup ISP. The company still exists, we just aren't providing dialup service anymore. We still have a couple of our web-hosting customers, but for the most part we've moved on to running an unrelated web-based service. Having our own address space is nice because it means we don't have to worry about stepping on anyone's AUP, we can go multi-homed later as the usage goes up, and we don't have to worry about running out of space as the web service grows. The problem is that while we met the eligibility requirements for an ipv4 direct allocation back when we got it, the requirements have changed over time and we no longer meet the eligibility requirements for an ipv4 direct allocation. (We've shrunk quite a bit) As demand for the remaining ipv4 addresses goes up, ARIN might decide that since we're ineligible for an allocation under the current rules, we're no longer eligible to maintain the space we have, and take it away from us. As the remaining space gets smaller, I expect that the number needed to justify keeping my addresses is going to go up. I fear I'm already on thin ice. From rali+nanog at tifosi.com Fri Feb 4 16:34:43 2011 From: rali+nanog at tifosi.com (R A Lichtensteiger) Date: Fri, 4 Feb 2011 17:34:43 -0500 Subject: quietly.... In-Reply-To: References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> <483E6B0272B0284BA86D7596C40D29F9011F76964E94@PUR-EXCH07.ox.com> <37955.1296761312@localhost> <201102031520.26126.lowen@pari.edu> <48563.1296769591@localhost> <20110204215430.0BEA09B1F01@drugs.dv.isc.org> Message-ID: <20110204223443.GF333@mta.tifosi.com> david raistrick wrote: >> Everyone doesn't suddenly get "owned" because there isn't a external >> firewall. Modern OS's default to secure. > > We clearly live and work in different worlds. Not to mention that > "we" are not the average consumers anymore. We were, in the days > before NAT (and SPI). A quick mental review of my relatives indicates more than a few of them with a PC jacked into a cable modem. The only firewall is the one that comes with Windows. Sure, pretty much every company and +some+ residential service has a firewall fo some sort in place, but they aren't the automatic default that you are assuming. As you say, "live and work in different worlds." Reto -- R A Lichtensteiger rali at tifosi.com "A polar bear is just another way of expressing a rectangular bear" From marka at isc.org Fri Feb 4 16:44:00 2011 From: marka at isc.org (Mark Andrews) Date: Sat, 05 Feb 2011 09:44:00 +1100 Subject: quietly.... In-Reply-To: Your message of "Fri, 04 Feb 2011 16:36:20 CDT." References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <5FDDAD27-71F3-44FE-B195-4E0F27F09EC5@megacity.org> <201102041140.42719.lowen@pari.edu> <20110204213259.E2FE29B1DED@drugs.dv.isc.org> Message-ID: <20110204224400.387799B2789@drugs.dv.isc.org> In message , Jared Mauch writes: > > On Feb 4, 2011, at 4:32 PM, Mark Andrews wrote: > > >=20 > > In message <201102041140.42719.lowen at pari.edu>, Lamar Owen writes: > >> On Friday, February 04, 2011 09:05:09 am Derek J. Balling wrote: > >>> I think they'll eventually notice a difference. How will an = > IPv4-only inter > >> nal host know what to do with an IPv6 AAAA record it gets from a DNS = > lookup? > >>=20 > >> If the CPE is doing DNS proxy (most do) then it can map the AAAA = > record to an > >> A record it passes to the internal client, with an internal address = > for the=20 > >> record chosen from RFC1918 space, and perform IPv4-IPv6 1:1 NAT from = > the assi > >> gned RFC1918 address to the external IPv6 address from the AAAA = > record (since > >> you have at least a /64 at your CPE, you can even use the RFC1918 = > address in > >> the lower 32 bits.... :-P). =20 > >>=20 > >> This may already be a standard, or a draft, or implemented somewhere; = > I don't > >> know. But that is how I would do it, just thinking off the top of my = > head. > >>=20 > >=20 > > DS-lite delivers a IPv4 softwire over a IPv6 upstream. It also > > introduces less problems than NAT64 as it works with DNSSEC and > > with IPv4 literal. Along with DS-lite there is a UPNP replacement > > designed to work with distributed NATs (DS-Lite (AFTR+B4) and NAT444 > > (LSN + CPE NAT)) so that holes can be punched threw multiple devices > > if needed. > > I've yet to see a version of ALG that isn't buggy (eg: Cisco SIP-ALG, = > 2Wire/ATT uverse sip-alg is seriously broken, same for either dlink or = > netgear... we have to turn it off otherwise it does bad things). And you reported the bugs. > I'm sure that LSN activity is going to work "great" for the carriers. Yes it is a worry which is why we want people to move to IPv6 and not use NAT. Less things to go wrong. A firewall only has to react to the traffic not re-write it. One lesa thing to go wrong. > - jared= -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Fri Feb 4 16:51:50 2011 From: marka at isc.org (Mark Andrews) Date: Sat, 05 Feb 2011 09:51:50 +1100 Subject: quietly.... In-Reply-To: Your message of "Fri, 04 Feb 2011 21:57:12 -0000." References: <16075456.4557.1296760302037.JavaMail.root@benjamin.baylink.com> Message-ID: <20110204225150.6FAC49B2854@drugs.dv.isc.org> In message , Roland Perry writes: > But NAT does have the useful (I think) side effect that I don't have to > renumber my network when I change upstream providers - whether that's > once every five years like I just did with my ADSL, or once every time > the new ADSL hiccups[1] now that I have a CPE with 3G failover. > > [1] Seems to be about weekly, so far. > -- > Roland Perry And that can be pretty much automated these days. Windows boxes if you let them will just register their new addresses in the DNS. MacOS also has the ability to do this as well. You should be asking the other vendors for similar support. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From joelja at bogus.com Fri Feb 4 17:08:04 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 04 Feb 2011 15:08:04 -0800 Subject: quietly.... In-Reply-To: <20110204223443.GF333@mta.tifosi.com> References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> <483E6B0272B0284BA86D7596C40D29F9011F76964E94@PUR-EXCH07.ox.com> <37955.1296761312@localhost> <201102031520.26126.lowen@pari.edu> <48563.1296769591@localhost> <20110204215430.0BEA09B1F01@drugs.dv.isc.org> <20110204223443.GF333@mta.tifosi.com> Message-ID: <4D4C86D4.6070101@bogus.com> On 2/4/11 2:34 PM, R A Lichtensteiger wrote: > david raistrick wrote: > >>> Everyone doesn't suddenly get "owned" because there isn't a external >>> firewall. Modern OS's default to secure. >> >> We clearly live and work in different worlds. Not to mention that >> "we" are not the average consumers anymore. We were, in the days >> before NAT (and SPI). > > A quick mental review of my relatives indicates more than a few of > them with a PC jacked into a cable modem. The only firewall is the > one that comes with Windows. > > Sure, pretty much every company and +some+ residential service has a > firewall fo some sort in place, but they aren't the automatic default > that you are assuming. As you say, "live and work in different > worlds." Bearing in mind that modst of the computers being sold today are laptops they do not sit inside the home cowering behind the firewall they are routinely attached to all sorts of potentially hositile environments, campus networks, offices, starbucks, airplanes etc and the only security perimeter they can count on is the one established inside the network interface rather than outside of it. this mac while a little more widely traveled than most has 500+ wireless networks which it remembers. making assumptions abou the security of the nework outside your machine or expectations for it is extremely dangerous. mMving into the future a larger percentage of the devices are or are going to be network agile and the upshot is a rather different take on what constitutes a security domain. > Reto From marka at isc.org Fri Feb 4 17:11:34 2011 From: marka at isc.org (Mark Andrews) Date: Sat, 05 Feb 2011 10:11:34 +1100 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: Your message of "Fri, 04 Feb 2011 08:28:53 MDT." <4D4C0D25.70408@brightok.net> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org> <4D4C0D25.70408@brightok.net> Message-ID: <20110204231134.3AA029B2B39@drugs.dv.isc.org> In message <4D4C0D25.70408 at brightok.net>, Jack Bates writes: > > > On 2/4/2011 5:03 AM, Eugen Leitl wrote: > > > Given http://weblog.chrisgrundemann.com/index.php/2009/how-much-ipv6-is-the > re/ > > it is pretty clear the allocation algorithms have to change, or the resourc > e > > is just as finite as the one we ran out yesterday. > > That's not what the author says. It says, IPv6 is only somewherein the > range of 16 million to 17 billion times larger than IPv4. And the author gets it wrong. > Let's be realistic. A /32 (standard small ISP) is equiv to an IPv4 > single IP. No, a /48 is equivalent to a single IP. You loose a little bit with small ISPs as their minimum is a /32 and supports up to 64000 customers. The bigger ISPs don't get to waste addresses space. And if a small ISP is getting space from a big ISP it also needs to maintain good usage ratios. > A /28 (medium ISP) is equiv to an IPv4 /28. A /24 (high > medium, large ISP) is equiv to an IPv4 /24. A /16 (a huge ISP) is equiv > to an IPv4 /16. Get the picture? > > So, I currently route a /16 worth of deaggregated IPv4 address space > (sorry, allocation policy fault, not mine). There is NEVER a time that I > will be allocated an IPv6 /16 from ARIN. Heck, the most I'll ever hope > for is the current proposal's nibble boundary which might get me to a > /24. I'll never talk to ARIN again after that. > > > Jack > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From kauer at biplane.com.au Fri Feb 4 17:14:27 2011 From: kauer at biplane.com.au (Karl Auer) Date: Sat, 05 Feb 2011 10:14:27 +1100 Subject: OT: (was Re: Weekend Gedankenexperiment - The Kill Switch) In-Reply-To: References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> <96503CEA-C922-47A6-9691-FCF157DF15D5@internode.com.au> <10A940BA-6D90-4663-B942-5FFF2CB49D7A@internode.com.au> <4D4BAD13.9090301@gmail.com> <88BC6885D33A9D42A1CCB45E8749525E013CBC58@pigeon.sandiego.nextlevelinternet.com> Message-ID: <1296861267.2146.16.camel@karl> On Fri, 2011-02-04 at 14:27 -0800, Matthew Petach wrote: > As has been noted previously, it's all about your frame of > reference. If the US is removed from the Internet, it does not > mean the Internet stops working; from the perspective of the > rest of the world, the Internet is still there. Many years ago, there was a headline in the London Times: "Fog In Channel, Europe Cut Off" Regards, K. PS: Might be an apocryphal story :-) -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jbates at brightok.net Fri Feb 4 17:25:44 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 04 Feb 2011 17:25:44 -0600 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <20110204231134.3AA029B2B39@drugs.dv.isc.org> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org> <4D4C0D25.70408@brightok.net> <20110204231134.3AA029B2B39@drugs.dv.isc.org> Message-ID: <4D4C8AF8.1030703@brightok.net> On 2/4/2011 5:11 PM, Mark Andrews wrote: > No, a /48 is equivalent to a single IP. > > You loose a little bit with small ISPs as their minimum is a /32 > and supports up to 64000 customers. The bigger ISPs don't get to > waste addresses space. And if a small ISP is getting space from > a big ISP it also needs to maintain good usage ratios. > Read the rest of what I said again. In the layout I used, a /32 is a /32. a /28 is a /28. Yet when you look at what is being assigned in IPv6 and you look at what we assign in IPv4, it's pretty laughable. It took years for me to get to a /16 of IPv4; where a /16 of IPv4 is small change for many large providers. In IPv6, a /16 is well out of my league and much larger than many large providers will ever need. >> A /28 (medium ISP) is equiv to an IPv4 /28. A /24 (high >> medium, large ISP) is equiv to an IPv4 /24. A /16 (a huge ISP) is equiv >> to an IPv4 /16. Get the picture? >> >> So, I currently route a /16 worth of deaggregated IPv4 address space >> (sorry, allocation policy fault, not mine). There is NEVER a time that I >> will be allocated an IPv6 /16 from ARIN. Heck, the most I'll ever hope >> for is the current proposal's nibble boundary which might get me to a >> /24. I'll never talk to ARIN again after that. >> >> >> Jack >> From randy at psg.com Fri Feb 4 17:30:48 2011 From: randy at psg.com (Randy Bush) Date: Fri, 04 Feb 2011 15:30:48 -0800 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <88BC6885D33A9D42A1CCB45E8749525E013CBC58@pigeon.sandiego.nextlevelinternet.com> References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> <96503CEA-C922-47A6-9691-FCF157DF15D5@internode.com.au> <10A940BA-6D90-4663-B942-5FFF2CB49D7A@internode.com.au> <4D4BAD13.9090301@gmail.com> <88BC6885D33A9D42A1CCB45E8749525E013CBC58@pigeon.sandiego.nextlevelinternet.com> Message-ID: > Not sure if it has been said already but wasn't one of the key point for > the creation of the internet to create and infrastructure that would > survive in the case of all out war and massive destruction. no. fable From brandon at rd.bbc.co.uk Fri Feb 4 18:01:42 2011 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Sat, 5 Feb 2011 00:01:42 GMT Subject: Post-Exhaustion-phase "punishment" for early adopters Message-ID: <201102050001.AAA08181@sunf10.rd.bbc.co.uk> > ARIN might decide that since we're ineligible for an allocation under > the current rules, we're no longer eligible to maintain the space we > have, and take it away from us. ARIN don't know that > As the remaining space gets smaller, I expect that the number needed > to justify keeping my addresses is going to go up. I fear I'm already > on thin ice. Nobody reads this list, your secret is safe brandon From owen at delong.com Fri Feb 4 18:06:03 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 4 Feb 2011 16:06:03 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <20110204165001.GB17194@vacation.karoshi.com.> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org> <4D4C0D25.70408@brightok.net> <20110204165001.GB17194@vacation.karoshi.com.> Message-ID: <28190609-10CA-4B25-8CAC-D63C5BFE7AC3@delong.com> On Feb 4, 2011, at 8:50 AM, bmanning at vacation.karoshi.com wrote: > On Fri, Feb 04, 2011 at 08:28:53AM -0600, Jack Bates wrote: >> >> >> On 2/4/2011 5:03 AM, Eugen Leitl wrote: >> >>> Given >>> http://weblog.chrisgrundemann.com/index.php/2009/how-much-ipv6-is-there/ >>> it is pretty clear the allocation algorithms have to change, or the >>> resource >>> is just as finite as the one we ran out yesterday. >> >> That's not what the author says. It says, IPv6 is only somewherein the >> range of 16 million to 17 billion times larger than IPv4. > > presuming you don't adhere to the guidelines that > insist on the bottom 64 bits being used as a "MAC" address > and the top 32 bits being used as an RIR identifier. > 1. The top 12 bits identify the RIR, not the top 32. 2. The bits somewhere between 12 and 32 identify the LIR or ISP. 3. Those facts do not reduce the available number of network numbers. Yes, EUI-64 could be argued to impinge on that, except that EUI-64 only addresses the lower 64 bits. The upper 64 bits provide about 17 billion times as many network numbers as there are host numbers in IPv4. That's without accounting for the fact that ~25% of the IPv4 addresses are unusable as unicast host addresses. > in reality, IPv6 (as specified by many IETF RFCs and as implemented > in lots of codes bases) only has 32 usable bits... just like IPv4. > Um, in reality, no, that is NOT the case. >> Let's be realistic. A /32 (standard small ISP) is equiv to an IPv4 >> single IP. A /28 (medium ISP) is equiv to an IPv4 /28. A /24 (high >> medium, large ISP) is equiv to an IPv4 /24. A /16 (a huge ISP) is equiv >> to an IPv4 /16. Get the picture? > > sho'huff. the real question is, how will you manage your own 32bits > of space? this is a change from the old v4 world, when the question > was, how will you manage your (pre CIDR) 8bits (or 16bits, or 24bits) > of space? Among others. Owen From mmc at internode.com.au Fri Feb 4 18:22:48 2011 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Sat, 5 Feb 2011 00:22:48 +0000 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> <96503CEA-C922-47A6-9691-FCF157DF15D5@internode.com.au> <10A940BA-6D90-4663-B942-5FFF2CB49D7A@internode.com.au> <4D4BAD13.9090301@gmail.com> <88BC6885D33A9D42A1CCB45E8749525E013CBC58@pigeon.sandiego.nextlevelinternet.com> Message-ID: <4E6EEFAB-3563-4245-9599-B4B54AC2223B@internode.com.au> On 05/02/2011, at 8:57 AM, Matthew Petach wrote: As has been noted previously, it's all about your frame of reference. If the US is removed from the Internet, it does not mean the Internet stops working; from the perspective of the rest of the world, the Internet is still there. I suspect you'll find it would be pretty crippled if the US was removed. Given the majority of my country's (Australia) internet connectivity is to the USA (English language speakers looking for English language content) we'd probably find that we were left with very limited connectivity. Quite a number of Australian ISPs would have no international connectivity at all. We'd have limited capacity to Europe as the Westward paths are thin and expensive and it's mostly via the USA. This is one of the risks the world, now relying on the "Interwebz" for communication runs. The heavy centralisation of the core of the internet (ie. really "Tier1" defines connectivity inside the USA only and is vague for the rest of the world) as well as Asia especially having very poor intra-Asia connectivity for various reasons. (ie. A number of Asian carriers optimise for connectivity to the USA and have silly views about "regional tier 1" that means they peer poorly within Asia. This leads to a lack of local connectivity. If the USA went "dark" then we'd lose connectivity to them). So, really, this is a call to the rest of the world to start thinking about the benefits of more regional connectivity and connectivity between Asia and Europe avoiding the USA so that any "kill switch" implemented doesn't cause the world to have any more problems than it needs to face. MMC From owen at delong.com Fri Feb 4 18:27:56 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 4 Feb 2011 16:27:56 -0800 Subject: quietly.... In-Reply-To: References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> <483E6B0272B0284BA86D7596C40D29F9011F76964E94@PUR-EXCH07.ox.com> <37955.1296761312@localhost> <201102031520.26126.lowen@pari.edu> <48563.1296769591@localhost> Message-ID: <8DABAA64-1036-4B27-BCDA-D3E4833FDB4F@delong.com> On Feb 4, 2011, at 10:04 AM, david raistrick wrote: > On Thu, 3 Feb 2011, Owen DeLong wrote: > >> Er. That's not news. That's been the state of the art for >> what, 15+ years or so now? SIP (because it's peer to peer) and >> P2P are really the only things that actually give a damn about >> it. >> Largely because we've been living with the tradeoff that we had to break the >> end-to-end model to temporarily compensate for an address shortage. Those of >> us that remember life before NAT would prefer not to bring this damage >> forward into an area of address abundance. In other words, yes, we gave up > > > Life before NAT, and firewalls (with or without SPI) on every PC and every CPI, also was life before mass consuption of internet access by the "normal" folks. And before extensive cellular and wifi networks for internet access. And before many of today's (common end user PC) security issues had been discovered. > > > Firewalls -destroy- the "end to end" model. You don't get inbound connectivity past the firewall unless a rule is explicitly created. That's no different than NAT requiring specific work to be done. > No... Firewalls enforce policies on the end-to-end connectivity. The end-to-end model is not about every host can deliver a packet to every other host. That is a misunderstanding of the meaning and principle of the end-to-end model. The end-to-end model is about "If my packet is permitted by policy and delivered to the remote host, I expect it to arrive as sent, without unexpected modifications." Mutilating the IP address portion of the header is an unexpected modification. Decrementing the TTL and replacing the MAC address for routing are not unexpected modifications. > Firewalls are not going away, if anything the continuing expansion of consumer users will create more and more breakage of the open-everything-connects-to-everything model, regardless of what the core engineering teams may want. > Nobody wants to get rid of firewalls. We want to get rid of NAT. Firewalls work great without NAT and by having firewalls without NAT, we gain back the end-to-end model while preserving the ability to enforce policy on end-to-end connectivity. > > Hell, even without CPE doing it, many residential ISPs (regardless of NAT) block inbound traffic to consumers. > Really? And they have subscribers? Surprising. > > The end-to-end model ended a long long time ago....maybe it will come back, but I rather doubt it. > Sadly, yes. We gave up the end-to-end model when we accepted NAT as a workaround for address shortage. We did so believing that IPv6 deployment and migration would eventually remove this shortage (which it does) and allow us to restore the end-to-end model. Now you're suggesting we should abandon that hope? I think not. > > We'll continue to have users, who run client software, and providers, who run server software. And a mix in between, because the user end can CHOOSE to enable server functionality (with their feet, by choosing a new ISP, at their firewall and or NAT device, and by enabling "server" software). > There is no need for NAT. > > NAT doesn't destroy end-to-end. It just makes it slightly more difficult. But no more difficult that turning on a firewall does. > It doesn't break anything that isn't trying to "announce" itself - and imo, applications that want to "announce" themselves seem like a pretty big security hole. > NAT does destroy end-to-end. Firewalls do not. Owen From owen at delong.com Fri Feb 4 18:33:10 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 4 Feb 2011 16:33:10 -0800 Subject: My upstream ISP does not support IPv6 In-Reply-To: References: <1127264403.2346.1296791643752.JavaMail.root@zimbra.network1.net> Message-ID: <185E6979-5F80-4F7A-8DE6-562132264990@delong.com> I'll start.. Hurricane Electric Happily and readily provided me IPv6 Transit on request. Layer42 Happily and readily provided me IPv6 Transit on request. Owen Disclaimer: While I work at HE, I'm speaking for my house, AS1734 in this case. On Feb 4, 2011, at 10:15 AM, david raistrick wrote: > On Thu, 3 Feb 2011, Randy Carpenter wrote: > >> IPv6 from both of my upstream providers has been "coming soon" for about a year and a half. > > Can we start naming names and locations for both sides of the answer? My last v6 queries are a few years out of date, so no point in sharing them. > > Well, I take that back. > > Amazon AWS - "No." But I'm asking again, that's a few months old. > > > -- > david raistrick http://www.netmeister.org/news/learn2quote.html > drais at icantclick.org http://www.expita.com/nomime.html > From owen at delong.com Fri Feb 4 18:35:29 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 4 Feb 2011 16:35:29 -0800 Subject: Post-Exhaustion-phase "punishment" for early adopters In-Reply-To: <4D4C49BE.3030907@hstrauss.co.za> References: <4D4C49BE.3030907@hstrauss.co.za> Message-ID: <56164EBA-7494-4A67-AE99-9A6800CD67D9@delong.com> On Feb 4, 2011, at 10:47 AM, Heinrich Strauss wrote: > Hi, NANOG. > > Something's just struck me: every IPv4 allocation over a certain threshold has a monetary cost (sometimes in the tens of thousands of USD) and according to our RIR, the first equivalent IPv6 allocation is given as a freebie (to encourage migration). (Disclaimer: I'm on the Dark Continent of Africa) > > So once the "early" adopters migrate their networks to IPv6, there is no business need to maintain the IPv4 allocation and that will be returned to the free pool, since Business would see it as an unnecessary cost. > > This would seem to counteract the forced move to IPv6, since, once the early adopters move their services exclusively to IPv6 (or maintaining very small IPv4 blocks), there would be plenty of IPv4 space for the late adopters to request (after the RIR quarantine period, etc). Naturally, 6to4 functionality must remain for a while to interoperability reasons, so their resources would be available to the IPv6 world for time to come. > > Unless I'm misunderstanding the RIRs policy regarding IPv4 allocations; has it been stated by all RIRs that IPv4 blocks are unallocatable once the exhaustion phase kicks in? Or is there another mechanism to ensure that we don't hand out the space being handed back once IPv6 is the norm? :) > > Regards, > -H. The big providers will not be deprecating their IPv4 addresses until there is no longer a significant IPv4 internet. At that time, smaller providers could probably get them, but, they will need IPv6 in order to talk to most of the world. Owen From marka at isc.org Fri Feb 4 18:45:17 2011 From: marka at isc.org (Mark Andrews) Date: Sat, 05 Feb 2011 11:45:17 +1100 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: Your message of "Fri, 04 Feb 2011 17:25:44 MDT." <4D4C8AF8.1030703@brightok.net> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org> <4D4C0D25.70408@brightok.net> <20110204231134.3AA029B2B39@drugs.dv.isc.org> <4D4C8AF8.1030703@brightok.net> Message-ID: <20110205004517.371F99B3B3C@drugs.dv.isc.org> In message <4D4C8AF8.1030703 at brightok.net>, Jack Bates writes: > On 2/4/2011 5:11 PM, Mark Andrews wrote: > > No, a /48 is equivalent to a single IP. > > > > You loose a little bit with small ISPs as their minimum is a /32 > > and supports up to 64000 customers. The bigger ISPs don't get to > > waste addresses space. And if a small ISP is getting space from > > a big ISP it also needs to maintain good usage ratios. > > > > Read the rest of what I said again. In the layout I used, a /32 is a > /32. a /28 is a /28. Yet when you look at what is being assigned in IPv6 > and you look at what we assign in IPv4, it's pretty laughable. > > It took years for me to get to a /16 of IPv4; where a /16 of IPv4 is > small change for many large providers. In IPv6, a /16 is well out of my > league and much larger than many large providers will ever need. A /16 of IPv4 is a /32 of IPv6 if you were only delivering 1 address per customer. If you were delivering /28's to customers that /16 is equivalent to a /36. /32 get assigned to ISPs. Those ISPs assign /48s downstream. The only place where that doesn't happen is ISP to ISP assignments (resellers). /48 get assigned to everybody else. The whole internet has shifted a minimum of 16 bits to the right. In many cases it will be 32 bits to the right. If ISP's only give out /56 then the shift is 24 bits. I used to work for CSIRO. Their /16's which were got back in the late 80's will now be /48's. Mark > >> A /28 (medium ISP) is equiv to an IPv4 /28. A /24 (high > >> medium, large ISP) is equiv to an IPv4 /24. A /16 (a huge ISP) is equiv > >> to an IPv4 /16. Get the picture? > >> > >> So, I currently route a /16 worth of deaggregated IPv4 address space > >> (sorry, allocation policy fault, not mine). There is NEVER a time that I > >> will be allocated an IPv6 /16 from ARIN. Heck, the most I'll ever hope > >> for is the current proposal's nibble boundary which might get me to a > >> /24. I'll never talk to ARIN again after that. > >> > >> > >> Jack > >> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jbates at brightok.net Fri Feb 4 19:02:41 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 04 Feb 2011 19:02:41 -0600 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <20110205004517.371F99B3B3C@drugs.dv.isc.org> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org> <4D4C0D25.70408@brightok.net> <20110204231134.3AA029B2B39@drugs.dv.isc.org> <4D4C8AF8.1030703@brightok.net> <20110205004517.371F99B3B3C@drugs.dv.isc.org> Message-ID: <4D4CA1B1.5060002@brightok.net> On 2/4/2011 6:45 PM, Mark Andrews wrote: > > I used to work for CSIRO. Their /16's which were got back in the > late 80's will now be /48's. > That's why I didn't try doing any adjustments of X is the new /32. The whole paradigm changes. Many ISPs devote large amounts of space to single corporate network sites. Those sites will now have a single /48. On the other hand, we currently give /32 to residential customers. They also are getting a /48. Which is why the only way to consider address usage from an ISP and RIR perspective is by how it is handed to a standard ISP of a given size. Originally, ARIN was being overly restrictive and it was "/32 for every ISP". They have loosened up, and will continue to do so (including ISP to ISP) as future proposals come to fruition. So from an ISP perspective, you have to consider your total IPv6 allocation size (within the first 32 bits of IPv6) in comparison to your total IPv4 allocations summed. From what I can tell, on average, all ISPs are shifting between 8 and 16 bits to the right from their total IPv4 size depending on their primary customer type (residential ISPs shift less than ISPs that primarily only service corporations). Jack From tony at pardini.org Fri Feb 4 19:17:36 2011 From: tony at pardini.org (Anthony Pardini) Date: Fri, 4 Feb 2011 19:17:36 -0600 Subject: My upstream ISP does not support IPv6 In-Reply-To: References: <1127264403.2346.1296791643752.JavaMail.root@zimbra.network1.net> <9A142313-6C58-470C-BE80-582D602F64AA@deadfrog.net> Message-ID: how do the routes they offer compare? On Feb 4, 2011 2:38 PM, "chip" wrote: > On Fri, Feb 4, 2011 at 2:23 PM, Ryan Wilkins wrote: >>>> IPv6 from both of my upstream providers has been "coming soon" for about a year and a half. >> >> I'm getting ready to try to enable IPv6 natively with Above.net in the Chicago area. Has anyone had any experience with them? >> >> Thanks, >> Ryan Wilkins >> > > Just wanted to throw in my 2 cents.... > > We're pretty much done with going dual-stack on circuits from Tiscali, > GBLX, Cogent, NTT/Verio, XO, and Telia. > > -- > Just my $.02, your mileage may vary, batteries not included, etc.... > From jbates at brightok.net Fri Feb 4 19:26:22 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 04 Feb 2011 19:26:22 -0600 Subject: quietly.... In-Reply-To: <8DABAA64-1036-4B27-BCDA-D3E4833FDB4F@delong.com> References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> <483E6B0272B0284BA86D7596C40D29F9011F76964E94@PUR-EXCH07.ox.com> <37955.1296761312@localhost> <201102031520.26126.lowen@pari.edu> <48563.1296769591@localhost> <8DABAA64-1036-4B27-BCDA-D3E4833FDB4F@delong.com> Message-ID: <4D4CA73E.1030003@brightok.net> On 2/4/2011 6:27 PM, Owen DeLong wrote: >> Hell, even without CPE doing it, many residential ISPs (regardless of NAT) block inbound traffic to consumers. >> > > Really? And they have subscribers? Surprising. > Mark Andrews wrote: > I run machines all the time that don't have firewall to protect > them from the big wide world out there. I suspect we all do. Your > not behind a external firewall when you are at NANOG or IETF. > Everyone doesn't suddenly get "owned" because there isn't a external > firewall. Modern OS's default to secure. Yes, and some of you thanked us for blocking RPC in the ISP or in the cable modems. Many such blocks are still in place in many ISPs as there was no reason to ever remove them. TCP/25 outbound is often blocked in many locations as well. Just because you don't notice the firewall, doesn't mean it doesn't exist. We stay in business when you don't notice. :) Jack From mysidia at gmail.com Fri Feb 4 19:28:58 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 4 Feb 2011 19:28:58 -0600 Subject: Post-Exhaustion-phase "punishment" for early adopters In-Reply-To: References: <4D4C49BE.3030907@hstrauss.co.za> <250E0B78-4DC5-4A94-B05A-95F0755C8884@pch.net> <640AC628-0D14-4194-A195-3A58E6008917@humancapitaldev.com> <5C82B551-CE7D-4838-BC7D-150FE6DB108C@ianai.net> <4097D073-B087-4B97-BD23-51B80C3BC313@puck.nether.net> Message-ID: On Fri, Feb 4, 2011 at 4:28 PM, Daniel Seagraves wrote: > On Feb 4, 2011, at 3:51 PM, Patrick W. Gilmore wrote: > How many addresses do I have to be using for it to count as in use? How high will that number go in the next few months/years? The most important thing to ensure "usage" is recognized is that the entire address space is announced plus routed, at least one valid host exists, reverse DNS servers are live, AND ensure that all contact details in the WHOIS database are present, accurate,and up to date; including phone numbers, postal address, and e-mails for the organization contacts. You might look into the option of signing the Legacy RSA: https://www.arin.net/resources/legacy/ Available until Dec 2011; If your allocation predated ARIN. I doubt the community is going to scour through all the /24 allocations and try to reclaim them, however. It's not that legacy /24 allocations don't matter, if they are entirely derelict, but the /8s are the ones that "sort of" matter... sort of, because a /8 reclaimed could provide a few months of IP addresses for a RIR. If you have a RSA, you are not really subject to the RIR taking IP addresses that you were already allocated (unless you had violated a policy, for example, by submitting a false application, or you no longer have a justified need for the IPs). Changes to the policy for new allocations doesn't mean existing allocations are cancelled, just because the new rule doesn't allow them. Probably it would not be too fair to try to answer a question that the community hasn't defined an answer for (yet at least) through any RIR policy, in regards to "how much usage" is usage. "Usage" is probably going to mean something like "globally" routed, at least one host exists in each /24, and the addresses are being used for the purpose originally in the application.. That would be what "used" means, but not what "efficiently utilized" means. It's not likely but conceivable, that the RIRs could decide to make a policy of reviewing legacy resources and revoking allocations with bad contact info, or apply an "efficient usage" criterion requiring return/renumbering, for legacy resource holders who have no RSA. -- -JH From jbates at brightok.net Fri Feb 4 19:33:29 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 04 Feb 2011 19:33:29 -0600 Subject: My upstream ISP does not support IPv6 In-Reply-To: References: <1127264403.2346.1296791643752.JavaMail.root@zimbra.network1.net> <9A142313-6C58-470C-BE80-582D602F64AA@deadfrog.net> Message-ID: <4D4CA8E9.4030806@brightok.net> On 2/4/2011 7:17 PM, Anthony Pardini wrote: > how do the routes they offer compare? Speaking generically, everyone's routes suck. It's also not a fully fair comparison of reachability. You can see my network from HE and Level3, but if see me through Level3 without the use of a tunnel, it is probably the better path (which is why I prepend out the tunnel to HE). On the other hand, there are cases where HE is better connectivity, even with the horrid tunnel. Jack From owen at delong.com Fri Feb 4 19:42:52 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 4 Feb 2011 17:42:52 -0800 Subject: Post-Exhaustion-phase "punishment" for early adopters In-Reply-To: References: <4D4C49BE.3030907@hstrauss.co.za> <250E0B78-4DC5-4A94-B05A-95F0755C8884@pch.net> <640AC628-0D14-4194-A195-3A58E6008917@humancapitaldev.com> <5C82B551-CE7D-4838-BC7D-150FE6DB108C@ianai.net> <4097D073-B087-4B97-BD23-51B80C3BC313@puck.nether.net> Message-ID: <7DC29AB0-271C-4793-BB1F-BB6B54E8F0F9@delong.com> On Feb 4, 2011, at 2:28 PM, Daniel Seagraves wrote: > > On Feb 4, 2011, at 3:51 PM, Patrick W. Gilmore wrote: > >> I'm a little confused. Sounds like the things you are talking about all fall into the "if you are using your block" category, so he shouldn't worry. >> >> ARIN should not reclaim a block that is in use. Unless I am confused? (Happens a lot, especially as I get older.) > > How many addresses do I have to be using for it to count as in use? How high will that number go in the next few months/years? > > We have a very old /24 direct allocation from the stone age, when we were a dialup ISP. The company still exists, we just aren't providing dialup service anymore. We still have a couple of our web-hosting customers, but for the most part we've moved on to running an unrelated web-based service. Having our own address space is nice because it means we don't have to worry about stepping on anyone's AUP, we can go multi-homed later as the usage goes up, and we don't have to worry about running out of space as the web service grows. The problem is that while we met the eligibility requirements for an ipv4 direct allocation back when we got it, the requirements have changed over time and we no longer meet the eligibility requirements for an ipv4 direct allocation. (We've shrunk quite a bit) As demand for the remaining ipv4 addresses goes up, ARIN might decide that since we're ineligible for an allocation under the current rules, we're no longer eligible to maintain the space we have, and take it away from us. > > As the remaining space gets smaller, I expect that the number needed to justify keeping my addresses is going to go up. I fear I'm already on thin ice. > If you don't sign the LRSA, who knows. If you sign the LRSA, you're completely protected regardless of future policy changes. Owen From owen at delong.com Fri Feb 4 20:05:58 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 4 Feb 2011 18:05:58 -0800 Subject: quietly.... In-Reply-To: <4D4CA73E.1030003@brightok.net> References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> <483E6B0272B0284BA86D7596C40D29F9011F76964E94@PUR-EXCH07.ox.com> <37955.1296761312@localhost> <201102031520.26126.lowen@pari.edu> <48563.1296769591@localhost> <8DABAA64-1036-4B27-BCDA-D3E4833FDB4F@delong.com> <4D4CA73E.1030003@brightok.net> Message-ID: On Feb 4, 2011, at 5:26 PM, Jack Bates wrote: > On 2/4/2011 6:27 PM, Owen DeLong wrote: >>> Hell, even without CPE doing it, many residential ISPs (regardless of NAT) block inbound traffic to consumers. >>> > >> Really? And they have subscribers? Surprising. >> > > Mark Andrews wrote: >> I run machines all the time that don't have firewall to protect >> them from the big wide world out there. I suspect we all do. Your >> not behind a external firewall when you are at NANOG or IETF. >> Everyone doesn't suddenly get "owned" because there isn't a external >> firewall. Modern OS's default to secure. > > Yes, and some of you thanked us for blocking RPC in the ISP or in the cable modems. Many such blocks are still in place in many ISPs as there was no reason to ever remove them. TCP/25 outbound is often blocked in many locations as well. Just because you don't notice the firewall, doesn't mean it doesn't exist. We stay in business when you don't notice. :) > > > Jack True... If you review the NANOG archives you'll find that at least in the case of the port 25 absurdity, I have noticed and have railed against it. Owen From jra at baylink.com Fri Feb 4 20:20:37 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 4 Feb 2011 21:20:37 -0500 (EST) Subject: quietly.... In-Reply-To: <23296.1296841129@localhost> Message-ID: <10377008.5003.1296872437713.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Valdis Kletnieks" > Subject: Re: quietly.... > On Thu, 03 Feb 2011 18:14:00 EST, david raistrick said: > > > Er. That's not news. That's been the state of the art for what, 15+ > > years or so now? SIP (because it's peer to peer) and P2P are really > > the > > only things that actually give a damn about it. > > "It's client/server unless it's peer-to-peer" is almost a tautology, > you know... Yes, yes; and the first rule of Tautology Club is the first rule of Tautology Club. Cheers, -- jra From jra at baylink.com Fri Feb 4 20:23:05 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 4 Feb 2011 21:23:05 -0500 (EST) Subject: quietly.... In-Reply-To: Message-ID: <33494363.5005.1296872585683.JavaMail.root@benjamin.baylink.com> ---- Original Message ----- > From: "Brian Johnson" > This is exactly the problem we have. Some people have no perspective > on what the Internet is and it's real power. I've met too many people > who claim to be "in the know" on these topics that don't understand > that NAT was designed for address preservation. That was the > only/primary/driving real reason for its development. The other > "features" were side effects and are not intended to be solutions to > production issues. "[were] not intended to be solutions to production issues" != "are not being depended on now". > If I use a wrench to hammer nails, it may work fine, but when It comes > to certain nails it may have issues. I'm using the tool for the wrong > purpose. This is the folly of NAT. Perhaps. But that's not important, now. Cheers, -- jr 'Good luck. We're all counting on you' a From ken at sizone.org Fri Feb 4 20:25:27 2011 From: ken at sizone.org (Ken Chase) Date: Fri, 4 Feb 2011 21:25:27 -0500 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> <96503CEA-C922-47A6-9691-FCF157DF15D5@internode.com.au> <10A940BA-6D90-4663-B942-5FFF2CB49D7A@internode.com.au> <4D4BAD13.9090301@gmail.com> <88BC6885D33A9D42A1CCB45E8749525E013CBC58@pigeon.sandiego.nextlevelinternet.com> Message-ID: <20110205022526.GC28351@sizone.org> On Fri, Feb 04, 2011 at 02:27:32PM -0800, Matthew Petach said: >The Internet itself will continue to function, no matter what silliness the >US political system attempts to engage in; from the perspective of those >in the US, it may appear that "the Internet" is unable to survive such an >attack; but from the perspective of the rest of the world, it really will be >localized damage in the US, and not at all a case of the Internet being >shut down. Hardly. A lot of top level/very popular sites likely have no extra-US redundancy. However, shutting the internet down (you know, when they press the magic button that makes my telebit trailblazer no longer able to do UUCP) would instantly create a market for services more robust/localized/ culturally-customized than those that suddenly go missing on that day. (wonder if anyone has contingency plans in the wings waiting for such an event). That's a pretty dumbass business decision, IMHO. Will nevar evar happen. Political and economic suicide. "internet presence vacuum" - there I coined it. [ side question, how many of the root servers evaporate on that day? ] [ additionally, when the usa is shutdown taking 80% of Canada with it, (truly, w'iz yr biyatches) do we declare a diplomatic emergency/act of war for american actions? or do we just hang our heads in shame at our poor redundancy? ] I suspect the 'internet kill switch' will be used in far more localized situations, like containing single ISPs/cells/threat vectors, as required. (Harkens back to GWB's rarely-mentioned theorizing end-run around Posse Comitatus suggesting 'who else but the military to contain an epidemic outbreak' without mention of threat authentication by independent civilian bodies). Popular uprising in city X tweeting out the new version of Rodney King? Good night and good luck. /kc -- Ken Chase - ken at heavycomputing.ca skype:kenchase23 +1 416 897 6284 Toronto Canada Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From jra at baylink.com Fri Feb 4 20:29:57 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 4 Feb 2011 21:29:57 -0500 (EST) Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <20110204220852.GC17194@vacation.karoshi.com.> Message-ID: <23261591.5007.1296872997737.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: bmanning at vacation.karoshi.com > if the law is unjust, do you comply because it is the law, or do you > protest, at the risk of punishment/death? hardly a wire-protocol question - > no? Correct: a decision each person must make for themselves... which is why it was *not* the topic of my inquiry. I was just curious as to whether people had given any thought to *whether and how* they could do it, if they decided it was necessary. Cheers, -- jra From jra at baylink.com Fri Feb 4 20:34:09 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 4 Feb 2011 21:34:09 -0500 (EST) Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <20110205022526.GC28351@sizone.org> Message-ID: <26012966.5009.1296873249342.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Ken Chase" > However, shutting the internet down (you know, when they press the > magic button that makes my telebit trailblazer no longer able to do > UUCP) would instantly create a market for services more robust/localized/ > culturally-customized than those that suddenly go missing on that day. > (wonder if anyone has contingency plans in the wings waiting for such > an event). So, Ken. Where *is* your Trailblazer? Is it hooked up? Have you tested it lately? Do you have Taylor UUCP installed? Configured? Have peers? Cheers, -- jr ':-)' a From jra at baylink.com Fri Feb 4 20:35:13 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 4 Feb 2011 21:35:13 -0500 (EST) Subject: Post-Exhaustion-phase "punishment" for early adopters In-Reply-To: Message-ID: <7558994.5011.1296873313924.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jimmy Hess" > On Fri, Feb 4, 2011 at 4:28 PM, Daniel Seagraves > wrote: > > On Feb 4, 2011, at 3:51 PM, Patrick W. Gilmore wrote: > > > How many addresses do I have to be using for it to count as in use? > > How high will that number go in the next few months/years? > > The most important thing to ensure "usage" is recognized is that the > entire address space is announced plus routed, at least one valid > host exists, reverse DNS servers are live, AND ensure that all > contact details in the WHOIS database are present, accurate,and up to > date; including phone numbers, postal address, and e-mails for the > organization contacts. > > You might look into the option of signing the Legacy RSA: > https://www.arin.net/resources/legacy/ > Available until Dec 2011; If your allocation predated ARIN. I gather that if you're considering signing an LRSA, you might want to take *technically competent* legal advice first. Cheers, -- jra From owen at delong.com Fri Feb 4 20:46:17 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 4 Feb 2011 18:46:17 -0800 Subject: quietly.... In-Reply-To: <33494363.5005.1296872585683.JavaMail.root@benjamin.baylink.com> References: <33494363.5005.1296872585683.JavaMail.root@benjamin.baylink.com> Message-ID: On Feb 4, 2011, at 6:23 PM, Jay Ashworth wrote: > ---- Original Message ----- >> From: "Brian Johnson" > >> This is exactly the problem we have. Some people have no perspective >> on what the Internet is and it's real power. I've met too many people >> who claim to be "in the know" on these topics that don't understand >> that NAT was designed for address preservation. That was the >> only/primary/driving real reason for its development. The other >> "features" were side effects and are not intended to be solutions to >> production issues. > > "[were] not intended to be solutions to production issues" != > "are not being depended on now". > >> If I use a wrench to hammer nails, it may work fine, but when It comes >> to certain nails it may have issues. I'm using the tool for the wrong >> purpose. This is the folly of NAT. > > Perhaps. But that's not important, now. > > Cheers, > -- jr 'Good luck. We're all counting on you' a True. It's also a backwards version of the analogy. The IPv4 situation today is that we have very few screws and we use NAT as a hammer to pound in small brads in places where we need screws because they are the only fastener we have left. What is important with IPv6 is to teach the generation of hammer-wielding mechanics who have grown up rarely seeing a screw and never knowing that there were wrenches that there are new tools available in IPv6. That screws or nuts and bolts can usually be superior to nails. That screws, nuts, and bolts work better if you install them with a screw driver or a wrench. That small brads lack structural integrity and that lag screws or bolts provide a superior structural hold when installed properly. That attempting to hammer every screw into a NAT-hole will destroy both the screw and the NAT-hole in most cases. Owen From jbates at brightok.net Fri Feb 4 20:49:07 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 04 Feb 2011 20:49:07 -0600 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <20110205022526.GC28351@sizone.org> References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> <96503CEA-C922-47A6-9691-FCF157DF15D5@internode.com.au> <10A940BA-6D90-4663-B942-5FFF2CB49D7A@internode.com.au> <4D4BAD13.9090301@gmail.com> <88BC6885D33A9D42A1CCB45E8749525E013CBC58@pigeon.sandiego.nextlevelinternet.com> <20110205022526.GC28351@sizone.org> Message-ID: <4D4CBAA3.6060403@brightok.net> On 2/4/2011 8:25 PM, Ken Chase wrote: > However, shutting the internet down (you know, when they press the > magic button that makes my telebit trailblazer no longer able to do > UUCP) would instantly create a market for services more robust/localized/ > culturally-customized than those that suddenly go missing on that day. > (wonder if anyone has contingency plans in the wings waiting for such > an event). Eh, We'd all rub our eyes, see the light creeping under the door, and actually go and see what's going on outside. :) Except the HAM operators. They don't need the Internet to stay inside. Jack From jbates at brightok.net Fri Feb 4 20:53:36 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 04 Feb 2011 20:53:36 -0600 Subject: quietly.... In-Reply-To: References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> <483E6B0272B0284BA86D7596C40D29F9011F76964E94@PUR-EXCH07.ox.com> <37955.1296761312@localhost> <201102031520.26126.lowen@pari.edu> <48563.1296769591@localhost> <8DABAA64-1036-4B27-BCDA-D3E4833FDB4F@delong.com> <4D4CA73E.1030003@brightok.net> Message-ID: <4D4CBBB0.60908@brightok.net> On 2/4/2011 8:05 PM, Owen DeLong wrote: > > True... If you review the NANOG archives you'll find that at least in the case > of the port 25 absurdity, I have noticed and have railed against it. > Yeah, I threw it in as an afterthought. ISP firewalls do exist and not just small isolated incidents. I wish more money had gone into making them much more adaptive, then you could enjoy your tcp/25 and possibly not have a problem unless your traffic patterns drew concerns and caused an adaptive filter to block it (eh? thousands of emails suddenly to a variety of servers? block). Interestingly, adaptive filters are often used for probing scans (and we didn't apply them to tcp/25, why?) Jack From gbonser at seven.com Fri Feb 4 21:25:51 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 4 Feb 2011 19:25:51 -0800 Subject: quietly.... In-Reply-To: <4D4CBBB0.60908@brightok.net> References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> <483E6B0272B0284BA86D7596C40D29F9011F76964E94@PUR-EXCH07.ox.com> <37955.1296761312@localhost><201102031520.26126.lowen@pari.edu> <48563.1296769591@localhost> <8DABAA64-1036-4B27-BCDA-D3E4833FDB4F@delong.com><4D4CA73E.1030003@brightok.net> <4D4CBBB0.60908@brightok.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13893@RWC-EX1.corp.seven.com> > > Yeah, I threw it in as an afterthought. ISP firewalls do exist and not > just small isolated incidents. I wish more money had gone into making > them much more adaptive, then you could enjoy your tcp/25 and possibly > not have a problem unless your traffic patterns drew concerns and > caused > an adaptive filter to block it (eh? thousands of emails suddenly to a > variety of servers? block). Interestingly, adaptive filters are often > used for probing scans (and we didn't apply them to tcp/25, why?) > > > Jack Maybe because it is just easier to do a transparent redirect to the ISPs mail server and look for patterns there. Some customer drops a bazillion email messages from a bazillion From: addresses in 14.7 seconds ... chances are you have a spam candidate. If the spam filter flags a lot (all?) of the messages as possible spam, queue them to the quarantine until someone can have a look and if they are, dismiss the customer and send them up the road OR inform them that they are possibly bot-net infected and block access to port 25 from them until they get it cleaned up. From ken at sizone.org Fri Feb 4 22:03:26 2011 From: ken at sizone.org (Ken Chase) Date: Fri, 4 Feb 2011 23:03:26 -0500 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <26012966.5009.1296873249342.JavaMail.root@benjamin.baylink.com> References: <20110205022526.GC28351@sizone.org> <26012966.5009.1296873249342.JavaMail.root@benjamin.baylink.com> Message-ID: <20110205040326.GD28351@sizone.org> On Fri, Feb 04, 2011 at 09:34:09PM -0500, Jay Ashworth said: >Where *is* your Trailblazer? Is it hooked up? Have you tested it >lately? > >Do you have Taylor UUCP installed? Configured? Have peers? No, but i have old drives full of uucp maps around. I'd start with those. And I'd use the terrestrial phone system to call up/figure out who's still out there (im friends/colleagues or know how to reach many of the people who ran my old peers). Once it became clear it was a long outtage, the effort required to get all this going again would be worth it. I have the tools around to make it happen, if I needed to, and I know several others who also do. (Maybe time to keep a copy of uu*.deb around though..) Oh whoops, except I have a dry copper loop in my house for my dsl. Dang nabbit. Stupid advancing technology. (During an internet outtage I wonder if new orders for POTS phone service would be quashed in the interest of 'public safety'... :) /kc -- Ken Chase - ken at heavycomputing.ca skype:kenchase23 +1 416 897 6284 Toronto Canada Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From gbonser at seven.com Fri Feb 4 23:04:15 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 4 Feb 2011 21:04:15 -0800 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <20110205040326.GD28351@sizone.org> References: <20110205022526.GC28351@sizone.org><26012966.5009.1296873249342.JavaMail.root@benjamin.baylink.com> <20110205040326.GD28351@sizone.org> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13894@RWC-EX1.corp.seven.com> > Dang nabbit. Stupid advancing technology. (During an internet outtage I > wonder > if new orders for POTS phone service would be quashed in the interest > of > 'public safety'... :) > > /kc > -- UUCP works just fine over TCP/IP and works with Exim and Postfix (I have used both with UUCP over TCP/IP) with regular ARPA style addresses (@ addressing). Might be worthwhile to set up just to keep in practice. Once served as an MX host for a local family that moved overseas for a while and they had their own domain. They would connect to the Internet when they could, connect to me and pull the family's mail by UUCP over TCP/IP. That wasn't that long ago (less than 10 years ago). It is actually a pretty decent way to collect email for an entire domain when you have only intermittent connectivity. From charles at knownelement.com Fri Feb 4 11:13:09 2011 From: charles at knownelement.com (Charles N Wyble) Date: Fri, 04 Feb 2011 09:13:09 -0800 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> Message-ID: <4D4C33A5.1090507@knownelement.com> On 2/3/2011 7:43 PM, Jay Ashworth wrote: > An armed FBI special agent shows up at your facility and tells your ranking > manager to "shut down the Internet". Let's look at this from a different perspective. What level of impairment would the feds face if they ordered wide spread net shut downs. Do the feds have a big enough network of their own, that they can continue to operate without the commercial nets being up? I mean they would need to declare martial law and coordinate enforcement activities. Can they do this all via satellite networks? Also what's to stop the operations staff from saying "no way jose" and walking out? Ok. Let's say they aren't dependent on the net being up. What would the scenario look like? Presumably this would be at a major IX, colo etc? Like say One Wilshire or something? They would show up with several agents, and probably some tech folks. One presumes they would have an injunction or some other legal authority to order you to terminate connectivity. This would have to be spelled out to the letter (terminate all IX traffic, drop all external sessions, take down core routers etc). > What do you do when you get home to put it back on the air Put what back on the air? Regional connectivity to let people coordinate a revolution? (I'm dead serious by the way. If things have gotten to the point where the feds are shutting down the net, it's time to follow our founding code: That whenever any Form of Government becomes destructive of these ends, it is the Right of the People to alter or to abolish it Depending on the geography, one could establish some long distance links via 802.11/3.65ghz. Hopefully that gear is already on stand by. > -- let's say email > as a base service, since it is -- do you have the gear laying around, and how > long would it take? Well I'm a huge data ownership guy and have been preaching to folks the importance of self hosting. Lots of details are on my wiki at http://wiki.knownelement.com/index.php/Data_Ownership So yes, I have the gear in service already doing my hosting. I also run a small neighborhood WISP. I only offer net access via that WISP, but it would be trivial to stand up a neighborhood xmpp/irc/mail/www server in that VLAN. Maybe I should do that now. Get people using it before hand, so it's what they naturally turn to in time of distress/disaster. Hmmm.... > Do you have out-of-band communications (let's say phone numbers) for enough > remote contacts? How much phone service would still work, if the feds hit all the major IX points and terminate connectivity? I seem to recall much discussion about the all IP back bone of the various large carriers (Qwest/ATT). I guess calls in the same CO and maybe between regional CO's might work. Think of this from a disaster preparedness perspective (ie a major earthquake or terrorist attack significantly damages One Wilshire and/or various IXes in the bay area). AT&T has a very large CO right next to One Wilshire, with something like 1.5 million lines terminated in the building. It wouldn't take that much work for the FBI to shut those places down if they felt a significant need to. Interesting thought exercise. Let's keep the conversation going guys/gals! From jbates at brightok.net Fri Feb 4 23:39:29 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 04 Feb 2011 23:39:29 -0600 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <4D4C33A5.1090507@knownelement.com> References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> <4D4C33A5.1090507@knownelement.com> Message-ID: <4D4CE291.8080702@brightok.net> On 2/4/2011 11:13 AM, Charles N Wyble wrote: > > How much phone service would still work, if the feds hit all the major > IX points and terminate > connectivity? I seem to recall much discussion about the all IP back > bone of the various large > carriers (Qwest/ATT). I guess calls in the same CO and maybe between > regional CO's might work. Yeah, that's the problem. The Internet isn't the Internet. The data needs of public Internet have reached a level that it is actually cheaper to consider the networks we use to transport that data as our primary networks, and run everything else over it as bonus recovery revenue (and MPLS became really popular). Most LECs are at least considering, if they haven't implemented, SIP/MGCP from DLC/ONT to local or region soft switches. In addition, long distance is increasingly running over pseudowire or SIP trunks. Cell networks are definitely pushing hard to drop the old T1 circuits and cranking up 300mb+ circuits, which often causes the carriers of those circuits to backhaul the other cell companies who still require T1 via pseudowire. They aren't being picky either. I about died laughing watching a small LEC setup some feeds for some cell towers. The circuits cross 4 different networks with at least 3 different types of transport configurations (gpon through a calix E7, which is pure L2 ethernet, Lucent DMX ethernet over sonet, and a high end Alacatel IP/MPLS network which I'm sure carries Internet traffic as well). Jack From jbates at brightok.net Sat Feb 5 01:04:01 2011 From: jbates at brightok.net (Jack Bates) Date: Sat, 05 Feb 2011 01:04:01 -0600 Subject: quietly.... In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13893@RWC-EX1.corp.seven.com> References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> <483E6B0272B0284BA86D7596C40D29F9011F76964E94@PUR-EXCH07.ox.com> <37955.1296761312@localhost><201102031520.26126.lowen@pari.edu> <48563.1296769591@localhost> <8DABAA64-1036-4B27-BCDA-D3E4833FDB4F@delong.com><4D4CA73E.1030003@brightok.net> <4D4CBBB0.60908@brightok.net> <5A6D953473350C4B9995546AFE9939EE0BC13893@RWC-EX1.corp.seven.com> Message-ID: <4D4CF661.1000409@brightok.net> On 2/4/2011 9:25 PM, George Bonser wrote: > Maybe because it is just easier to do a transparent redirect to the ISPs > mail server and look for patterns there. Analyzing flows generally isn't any more difficult than analyzing mail log patterns. It doesn't have the queue and check mechanism of a transparent redirect, but transparent redirects break certain types of mail connections as well. It is good practice for an ISP to run flow analysis anyways to detect bad traffic patterns. What I really want and haven't had time to write is a good procedure that establishes dynamic policies for flow pattern matches which causes the suspect packets to start tag switching to an analysis server where it is closer examined before actual filters are updated. I'd really like to see standards developed which router vendors supported to make such dynamic policies easier to update, along with the filters themselves. Perhaps we'll see it after more pressing IPv6 concerns are addressed. Jack From owen at delong.com Sat Feb 5 01:37:47 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 4 Feb 2011 23:37:47 -0800 Subject: quietly.... In-Reply-To: <4D4CBBB0.60908@brightok.net> References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> <483E6B0272B0284BA86D7596C40D29F9011F76964E94@PUR-EXCH07.ox.com> <37955.1296761312@localhost> <201102031520.26126.lowen@pari.edu> <48563.1296769591@localhost> <8DABAA64-1036-4B27-BCDA-D3E4833FDB4F@delong.com> <4D4CA73E.1030003@brightok.net> <4D4CBBB0.60908@brightok.net> Message-ID: On Feb 4, 2011, at 6:53 PM, Jack Bates wrote: > On 2/4/2011 8:05 PM, Owen DeLong wrote: >> >> True... If you review the NANOG archives you'll find that at least in the case >> of the port 25 absurdity, I have noticed and have railed against it. >> > > Yeah, I threw it in as an afterthought. ISP firewalls do exist and not just small isolated incidents. I wish more money had gone into making them much more adaptive, then you could enjoy your tcp/25 and possibly not have a problem unless your traffic patterns drew concerns and caused an adaptive filter to block it (eh? thousands of emails suddenly to a variety of servers? block). Interestingly, adaptive filters are often used for probing scans (and we didn't apply them to tcp/25, why?) > > > Jack Sad, but true. I will not patronize an ISP that decides for me which packets I want and do not want, but, apparently there are people who will. Not sure how I feel about a more adaptive version. Sounds like it would be better than the current state, but, I vastly prefer "I pay, you route. If I want filtration, I'll tell you." Owen From owen at delong.com Sat Feb 5 01:56:03 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 4 Feb 2011 23:56:03 -0800 Subject: quietly.... In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13893@RWC-EX1.corp.seven.com> References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> <483E6B0272B0284BA86D7596C40D29F9011F76964E94@PUR-EXCH07.ox.com> <37955.1296761312@localhost><201102031520.26126.lowen@pari.edu> <48563.1296769591@localhost> <8DABAA64-1036-4B27-BCDA-D3E4833FDB4F@delong.com><4D4CA73E.1030003@brightok.net> <4D4CBBB0.60908@brightok.net> <5A6D953473350C4B9995546AFE9939EE0BC13893@RWC-EX1.corp.seven.com> Message-ID: On Feb 4, 2011, at 7:25 PM, George Bonser wrote: >> >> Yeah, I threw it in as an afterthought. ISP firewalls do exist and not >> just small isolated incidents. I wish more money had gone into making >> them much more adaptive, then you could enjoy your tcp/25 and possibly >> not have a problem unless your traffic patterns drew concerns and >> caused >> an adaptive filter to block it (eh? thousands of emails suddenly to a >> variety of servers? block). Interestingly, adaptive filters are often >> used for probing scans (and we didn't apply them to tcp/25, why?) >> >> >> Jack > > Maybe because it is just easier to do a transparent redirect to the ISPs > mail server and look for patterns there. Some customer drops a > bazillion email messages from a bazillion From: addresses in 14.7 > seconds ... chances are you have a spam candidate. If the spam filter > flags a lot (all?) of the messages as possible spam, queue them to the > quarantine until someone can have a look and if they are, dismiss the > customer and send them up the road OR inform them that they are possibly > bot-net infected and block access to port 25 from them until they get it > cleaned up. > > The problem is some providers get a little too zealous and not only break port 25 (which is just mildly annoying), but, also break 587 and in rare cases 465 as well. Since I use SMTP+TLS to connect back to my mail server and use STMPAUTH to send my mail, hotels and conference centers that do this prove to be an annoying hurdle to doing something useful. The worst one I encountered was a JetStar lunch in Adelaide. They not only blocked 25, 465, 587, etc. They blocked everything except 80 and 443. I resorted to using an SSH client on my iPad over 3G to log into my server and start an SSH daemon on port 443 on an additional IP address I assigned. After that, I was able to use SSH tunnels for everything else. I don't know what a less technical user would to do use their lounge to actually use the internet. Just one more item in a long list of reasons I will _NEVER_ do business with JetStar again and will avoid Qantas unless I have no choice (since they own JetStar). Owen From siggi at bjarnason.us Sat Feb 5 01:59:12 2011 From: siggi at bjarnason.us (Siggi Bjarnason) Date: Fri, 4 Feb 2011 23:59:12 -0800 Subject: External sanity checks In-Reply-To: <844412.30168.qm@web30804.mail.mud.yahoo.com> References: <844412.30168.qm@web30804.mail.mud.yahoo.com> Message-ID: I've been using Site24x7 for some time now and am very pleased with them, plus their pricing is very reasonable. Siggi Bjarnason siggi at bjarnason.us "In free countries, every man is entitled to express his opinions and every other man is entitled not to listen." - G. Norman Collie On Thu, Feb 3, 2011 at 10:04 AM, Philip Lavine wrote: > To all, > > Does any one know a Vendor (NOT Keynote) that can do sanity checks against > your web/smtp/ftp farms with pings, traceroutes, latency checks as well as > application checks (GET, POST, ESMTP, etc) > > Thank you, > > Philip > > > > > > From jbates at brightok.net Sat Feb 5 02:26:38 2011 From: jbates at brightok.net (Jack Bates) Date: Sat, 05 Feb 2011 02:26:38 -0600 Subject: quietly.... In-Reply-To: References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> <483E6B0272B0284BA86D7596C40D29F9011F76964E94@PUR-EXCH07.ox.com> <37955.1296761312@localhost> <201102031520.26126.lowen@pari.edu> <48563.1296769591@localhost> <8DABAA64-1036-4B27-BCDA-D3E4833FDB4F@delong.com> <4D4CA73E.1030003@brightok.net> <4D4CBBB0.60908@brightok.net> Message-ID: <4D4D09BE.3070507@brightok.net> On 2/5/2011 1:37 AM, Owen DeLong wrote: > Not sure how I feel about a more adaptive version. Sounds like it would be better > than the current state, but, I vastly prefer "I pay, you route. If I want filtration, I'll > tell you." > I generally agree with you. However, I also believe that every network has a responsibility to assist in the overall well being of the Internet as well as provide the best service they can to their customers. In general, this means maintaining network stability and stopping abuse when detected. The slowest and last resort of abuse handling is done by an abuse and/or security department responsible for handling complaints. Stopping things prior to a complaint (which sometimes don't come at all and sometimes is a screaming roar) is even better. http://www.merit.edu/mail.archives/nanog/2003-01/msg00579.html http://www.merit.edu/mail.archives/nanog/2003-08/msg00284.html Eh, you know all of them anyways, and it's taking forever to troll the archives. :) Filtering is an age old argument, though. I wish I could live without it, personally. Jack From gadnet at aqueos.com Sat Feb 5 02:56:47 2011 From: gadnet at aqueos.com (Ghislain) Date: Sat, 05 Feb 2011 09:56:47 +0100 Subject: External sanity checks In-Reply-To: References: <844412.30168.qm@web30804.mail.mud.yahoo.com> Message-ID: <4D4D10CF.90601@aqueos.com> Le 05/02/2011 08:59, Siggi Bjarnason a ?crit : > I've been using Site24x7 for some time now and am very pleased with them, > plus their pricing is very reasonable. i am very pleased by serverguard24.com services. -- Cordialement, Ghislain -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3591 bytes Desc: S/MIME Cryptographic Signature URL: From lists at internetpolicyagency.com Sat Feb 5 03:54:35 2011 From: lists at internetpolicyagency.com (Roland Perry) Date: Sat, 5 Feb 2011 09:54:35 +0000 Subject: quietly.... In-Reply-To: References: <16075456.4557.1296760302037.JavaMail.root@benjamin.baylink.com> Message-ID: In article , david raistrick writes >> But NAT does have the useful (I think) side effect that I don't have >>to renumber my network when I change upstream providers - whether >>that's once > >But (what I keep being told) you should never have to renumber! Get PI >space and insert magic here! Part of the problem is knowing in advance what ISPs will and won't do. It's all very well saying one shouldn't patronise an ISP that blocks port 25, for example, but where is that documented before you buy? [My current 3G supplier blocks port 25 sometimes, I've yet to work out the algorithm used, it flips every day or two]. So will the likes of Vodafone and t-mobile support the PI model described above? -- Roland Perry From lists at internetpolicyagency.com Sat Feb 5 04:03:35 2011 From: lists at internetpolicyagency.com (Roland Perry) Date: Sat, 5 Feb 2011 10:03:35 +0000 Subject: quietly.... In-Reply-To: <20110204225150.6FAC49B2854@drugs.dv.isc.org> References: <16075456.4557.1296760302037.JavaMail.root@benjamin.baylink.com> <20110204225150.6FAC49B2854@drugs.dv.isc.org> Message-ID: In article <20110204225150.6FAC49B2854 at drugs.dv.isc.org>, Mark Andrews writes >> But NAT does have the useful (I think) side effect that I don't have to >> renumber my network when I change upstream providers - whether that's >> once every five years like I just did with my ADSL, or once every time >> the new ADSL hiccups[1] now that I have a CPE with 3G failover. >> >> [1] Seems to be about weekly, so far. > >And that can be pretty much automated these days. Windows boxes >if you let them will just register their new addresses in the DNS. >MacOS also has the ability to do this as well. You should be asking >the other vendors for similar support. And when my vendor is Sipura, or Sony[1], how does an individual small enterprise attract their attention and get the features added? [1] Quite by accident I have three net-connected items of theirs, a PS/3, a TV and a mobile phone. -- Roland Perry From lists at internetpolicyagency.com Sat Feb 5 04:18:23 2011 From: lists at internetpolicyagency.com (Roland Perry) Date: Sat, 5 Feb 2011 10:18:23 +0000 Subject: quietly.... In-Reply-To: References: <33494363.5005.1296872585683.JavaMail.root@benjamin.baylink.com> Message-ID: In article , Owen DeLong writes >What is important with IPv6 is to teach the generation of hammer-wielding >mechanics who have grown up rarely seeing a screw and never knowing >that there were wrenches that there are new tools available in IPv6. >That screws or nuts and bolts can usually be superior to nails. That screws, >nuts, and bolts work better if you install them with a screw driver or a wrench. >That small brads lack structural integrity and that lag screws or bolts provide >a superior structural hold when installed properly. That attempting to hammer >every screw into a NAT-hole will destroy both the screw and the NAT-hole in >most cases. This is all very true, but doesn't qualify (for my small-enterprise target audience) as "not noticing the difference" when the upstream network swaps from IPv4 to IPv6. I wonder what's the best way to get them up the necessary learning curve? [Maybe I should write a book about it] -- Roland Perry From bmanning at vacation.karoshi.com Sat Feb 5 04:57:31 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 5 Feb 2011 10:57:31 +0000 Subject: "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> Message-ID: <20110205105731.GA20900@vacation.karoshi.com.> On Thu, Feb 03, 2011 at 04:54:42PM +0000, John Curran wrote: > On Feb 3, 2011, at 11:32 AM, Jon Lewis wrote: > > > My point being, the leasing of IP space to non-connectivity customers is already well established, whether it's technically permitted by the [ir]relevant RIRs. I fully expect this to continue and spread. Eventually, holders of large legacy blocks will realize they can make good money acting as an LIR, leasing portions of their unused space to people who need it and can't get it, want it and don't qualify, etc. > > > > These start-up LIRs won't be bound by RIR policies, both because in some cases they'll be legacy space holders with no RSA with their region's RIR, and because they won't be worried about eligibility for future RIR allocations of v4 space...because there won't be any. > > For the ARIN region, it would be nice to know how you'd like ARIN perform > in the presence of such activity ("leasing" IP addresses by ISP not providing > connectivity). It's possible that such is perfectly reasonable and to simply > be ignored, it's also possible that such should be considered a fraudulent > transfer and the resources reclaimed. At the end of the day, the policy is > set by this community, and clarity over ambiguity is very helpful. > > Policy proposal process: https://www.arin.net/policy/pdp.html > > Thanks! > /John > > John Curran > President and CEO > ARIN the practice predates ARIN by many years... FWIW... --bill From owen at delong.com Sat Feb 5 05:12:26 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 5 Feb 2011 03:12:26 -0800 Subject: quietly.... In-Reply-To: References: <16075456.4557.1296760302037.JavaMail.root@benjamin.baylink.com> Message-ID: <85D304BA-6C4E-4B86-9717-2ADB542B8606@delong.com> On Feb 5, 2011, at 1:54 AM, Roland Perry wrote: > In article , david raistrick writes >>> But NAT does have the useful (I think) side effect that I don't have to renumber my network when I change upstream providers - whether that's once >> >> But (what I keep being told) you should never have to renumber! Get PI space and insert magic here! > > Part of the problem is knowing in advance what ISPs will and won't do. It's all very well saying one shouldn't patronise an ISP that blocks port 25, for example, but where is that documented before you buy? > If they don't document partial internet access blockage in the contract and the contract says they are providing internet access, then, they are in breach and you are free to depart without a termination fee and in most cases, demand a refund for service to date. (Yes, I have successfully argued this on multiple occasions). In fact, I get free internet in most of the more expensive hotel environments as a result. > [My current 3G supplier blocks port 25 sometimes, I've yet to work out the algorithm used, it flips every day or two]. > > So will the likes of Vodafone and t-mobile support the PI model described above? I use SPRINT. They used to. They've stopped. Admittedly, I'm not over-fussed about email on my phone and I don't use a tether device at this point. I mostly expect 3G and 4G networks to be broken internet anyway. I was more speaking in terms of land-line providers. Owen (Who only depends on his current residential ISPs for L2 transport and doesn't know what they block at L3 and up as long as they don't break GRE) From rmayer at vinotech.de Sat Feb 5 06:32:52 2011 From: rmayer at vinotech.de (Ralph J.Mayer) Date: Sat, 05 Feb 2011 13:32:52 +0100 Subject: Post-Exhaustion-phase "punishment" for early adopters In-Reply-To: <5C82B551-CE7D-4838-BC7D-150FE6DB108C@ianai.net> References: <4D4C49BE.3030907@hstrauss.co.za> <250E0B78-4DC5-4A94-B05A-95F0755C8884@pch.net> <640AC628-0D14-4194-A195-3A58E6008917@humancapitaldev.com> <5C82B551-CE7D-4838-BC7D-150FE6DB108C@ianai.net> Message-ID: <4D4D4374.2020007@vinotech.de> Hi, > If you are using your block, why would you worry? > > If not are not using your block, why would you need it? You may define "using" Hint: even IPs not pingable from the Internet are being used. Not everyone is an ISP/Webhoster ... with public services. -- Viele Gr??e / Kind Regards / Cordiali Saluti / Met vriendelijke groet Ralph J.Mayer xmpp:rmayer at vinotech.de www.vinoblog.de mailto:rmayer at vinotech.de From jcurran at arin.net Sat Feb 5 06:40:44 2011 From: jcurran at arin.net (John Curran) Date: Sat, 5 Feb 2011 12:40:44 +0000 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <20110205105731.GA20900@vacation.karoshi.com> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> Message-ID: <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> On Feb 5, 2011, at 5:57 AM, bmanning at vacation.karoshi.com wrote: >> For the ARIN region, it would be nice to know how you'd like ARIN perform >> in the presence of such activity ("leasing" IP addresses by ISP not providing >> connectivity). It's possible that such is perfectly reasonable and to simply >> be ignored, it's also possible that such should be considered a fraudulent >> transfer and the resources reclaimed. At the end of the day, the policy is >> set by this community, and clarity over ambiguity is very helpful. >> ... > > the practice predates ARIN by many years... FWIW... Good to know; it makes its omission from RFC2050 even more significant and highlights the need for clear policy in this area. Ultimately, the question is simply how the operator community wishes to have this treated, and there should be alignment between that consensus and the number resource policy. /John John Curran President and CEO ARIN From marka at isc.org Sat Feb 5 06:47:10 2011 From: marka at isc.org (Mark Andrews) Date: Sat, 05 Feb 2011 23:47:10 +1100 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: Your message of "Fri, 04 Feb 2011 19:02:41 MDT." <4D4CA1B1.5060002@brightok.net> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org> <4D4C0D25.70408@brightok.net> <20110204231134.3AA029B2B39@drugs.dv.isc.org> <4D4C8AF8.1030703@brightok.net> <20110205004517.371F99B3B3C@drugs.dv.isc.org> <4D4CA1B1.5060002@brightok.net> Message-ID: <20110205124710.059259B4E31@drugs.dv.isc.org> In message <4D4CA1B1.5060002 at brightok.net>, Jack Bates writes: > On 2/4/2011 6:45 PM, Mark Andrews wrote: > > > > I used to work for CSIRO. Their /16's which were got back in the > > late 80's will now be /48's. > > That's why I didn't try doing any adjustments of X is the new /32. The > whole paradigm changes. So why the ~!#! are you insisting on comparing IPv4 allocations with IPv6 alocations. > Many ISPs devote large amounts of space to > single corporate network sites. Those sites will now have a single /48. > On the other hand, we currently give /32 to residential customers. They > also are getting a /48. > > Which is why the only way to consider address usage from an ISP and RIR > perspective is by how it is handed to a standard ISP of a given size. There are two sizes. Those that fit into a /32 and those that don't. The latter ones have to justify their allocations. > Originally, ARIN was being overly restrictive and it was "/32 for every > ISP". They have loosened up, and will continue to do so (including ISP > to ISP) as future proposals come to fruition. So from an ISP > perspective, you have to consider your total IPv6 allocation size > (within the first 32 bits of IPv6) in comparison to your total IPv4 > allocations summed. No. You need to compare it to the number of customer sites. If you have 1 customer with wires going to two locations thats two /48's. > From what I can tell, on average, all ISPs are shifting between 8 and > 16 bits to the right from their total IPv4 size depending on their > primary customer type (residential ISPs shift less than ISPs that > primarily only service corporations). Residential ISPs shift 16 bits (48-32=16). You shift less if you have less than 64000 customers sites and don't get address space from a larger ISP. Commercial ISPs shift more as what was multiple address at one sites becomes 1 /48. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Sat Feb 5 07:15:10 2011 From: marka at isc.org (Mark Andrews) Date: Sun, 06 Feb 2011 00:15:10 +1100 Subject: quietly.... In-Reply-To: Your message of "Sat, 05 Feb 2011 10:03:35 -0000." References: <16075456.4557.1296760302037.JavaMail.root@benjamin.baylink.com> <20110204225150.6FAC49B2854@drugs.dv.isc.org> Message-ID: <20110205131510.BE13E9B5167@drugs.dv.isc.org> In message , Roland Perry writes: > In article <20110204225150.6FAC49B2854 at drugs.dv.isc.org>, Mark Andrews > writes > > >> But NAT does have the useful (I think) side effect that I don't have to > >> renumber my network when I change upstream providers - whether that's > >> once every five years like I just did with my ADSL, or once every time > >> the new ADSL hiccups[1] now that I have a CPE with 3G failover. > >> > >> [1] Seems to be about weekly, so far. > > > >And that can be pretty much automated these days. Windows boxes > >if you let them will just register their new addresses in the DNS. > >MacOS also has the ability to do this as well. You should be asking > >the other vendors for similar support. > > And when my vendor is Sipura, or Sony[1], how does an individual small > enterprise attract their attention and get the features added? You return the equipment as not suitable for the advertised purpose and demand your money back. Renumbering is expected to occur with IPv6, part of renumbering is getting the name to address mappings right. With DHCP the DHCP server normally does it. With SLAAC the host has to do it as there is no other choice. Here in Australia it is Repair/Replace/Refund if the product purchased is faulty. That applies to all products. If the milk is off when we get home we go back and get it replaced and if the store is out of stock we get a refund. I've returned and had replaced plenty of stuff over the years. > [1] Quite by accident I have three net-connected items of theirs, a > PS/3, a TV and a mobile phone. > -- > Roland Perry > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Sat Feb 5 07:36:03 2011 From: marka at isc.org (Mark Andrews) Date: Sun, 06 Feb 2011 00:36:03 +1100 Subject: quietly.... In-Reply-To: Your message of "Sat, 05 Feb 2011 10:18:23 -0000." References: <33494363.5005.1296872585683.JavaMail.root@benjamin.baylink.com> Message-ID: <20110205133603.7C6B19B5221@drugs.dv.isc.org> In message , Roland Perry writes: > In article , Owen > DeLong writes > > >What is important with IPv6 is to teach the generation of hammer-wielding > >mechanics who have grown up rarely seeing a screw and never knowing > >that there were wrenches that there are new tools available in IPv6. > >That screws or nuts and bolts can usually be superior to nails. That screws, > >nuts, and bolts work better if you install them with a screw driver or a wre > nch. > >That small brads lack structural integrity and that lag screws or bolts prov > ide > >a superior structural hold when installed properly. That attempting to hamme > r > >every screw into a NAT-hole will destroy both the screw and the NAT-hole in > >most cases. > > This is all very true, but doesn't qualify (for my small-enterprise > target audience) as "not noticing the difference" when the upstream > network swaps from IPv4 to IPv6. It won't be a swap. Even when the local ISP can only deliver IPv6 they will still be able to get IPv4. There will be business which just deliver IPv4 to IPv6 only connected customers whether they need server support or client support or both. The software to do this is already written. > I wonder what's the best way to get them up the necessary learning curve? Turn on IPv6 native or tunnel. Populate the IP6.ARPA space with individual PTR records for the machines. Add matching AAAA records. The outbound side should just work. Next you add AAAA records for all the services you offer after testing them. > [Maybe I should write a book about it] > -- > Roland Perry > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From Joel.Snyder at Opus1.COM Sat Feb 5 07:41:23 2011 From: Joel.Snyder at Opus1.COM (Joel M Snyder) Date: Sat, 05 Feb 2011 08:41:23 -0500 Subject: Random Port Blocking at Hotels (was: Re: quietly....) In-Reply-To: References: Message-ID: <4D4D5383.4050101@opus1.com> > If they don't document partial internet access blockage in the > contract and the contract says they are providing internet access, > then, they are in breach and you are free to depart without a > termination fee and in most cases, demand a refund for service to > date. > (Yes, I have successfully argued this on multiple occasions). > In fact, I get free internet in most of the more expensive hotel > environments as a result. It's more likely you get free internet service in expensive hotels because the guy/girl behind the front desk has been empowered to cancel out a ridiculously high charge for Internet when a guest starts jabbering at them about how the Internet didn't work for them for any reason, to keep the line moving and to make the guest happy, rather than any higher authority hunkering down with the CEO, legal staff, and CTO and saying "by God, this Owen character is right, we're in breach of contract and his definition of the purity of Internet ports has so stunned us with its symmetry and loveliness that we shall bow down and sin no more! Thank you Mr. DeLong from making the blind see again!" I mean, it's gratifying to think you've won the argument (hence: this is why they do it), but you could also have argued that they were giving out non-contiguous subnet masks or Class E addresses and it would have had the same effect. Try that next time and let us know how it works. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From jbates at brightok.net Sat Feb 5 08:34:36 2011 From: jbates at brightok.net (Jack Bates) Date: Sat, 05 Feb 2011 08:34:36 -0600 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <20110205124710.059259B4E31@drugs.dv.isc.org> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org> <4D4C0D25.70408@brightok.net> <20110204231134.3AA029B2B39@drugs.dv.isc.org> <4D4C8AF8.1030703@brightok.net> <20110205004517.371F99B3B3C@drugs.dv.isc.org> <4D4CA1B1.5060002@brightok.net> <20110205124710.059259B4E31@drugs.dv.isc.org> Message-ID: <4D4D5FFC.6020905@brightok.net> On 2/5/2011 6:47 AM, Mark Andrews wrote: > So why the ~!#! are you insisting on comparing IPv4 allocations with IPv6 > alocations. > Because that is where the comparison must be made, at the RIR allocation size/rate level. > There are two sizes. Those that fit into a /32 and those that don't. > The latter ones have to justify their allocations. > Yeah, tell that to the fee schedules. > No. You need to compare it to the number of customer sites. If you > have 1 customer with wires going to two locations thats two /48's. That's definitely the wrong way to look at it. Sure that's related to justification to an RIR to get an allocation, but ISPs will end up with much more flexible address space. > Residential ISPs shift 16 bits (48-32=16). You shift less if you > have less than 64000 customers sites and don't get address space > from a larger ISP. Commercial ISPs shift more as what was multiple > address at one sites becomes 1 /48. > 64,000 customer sites isn't required to receive more than a /32 (unless a single router makes up your entire network). Well, I currently have a /30, which is a 14 bit shift right from my /16. (30-16=14). In the near future I expect to be somewhere between a /24 and a /28, which is an 8 to 12 bit shift right from my IPv4 /16 allocation. Still, that is a considerable number of bits we'll have left when the dust settles and the RIR allocation rate drastically slows. Jack From johnl at iecc.com Sat Feb 5 09:00:05 2011 From: johnl at iecc.com (John Levine) Date: 5 Feb 2011 15:00:05 -0000 Subject: Random Port Blocking at Hotels (was: Re: quietly....) In-Reply-To: <4D4D5383.4050101@opus1.com> Message-ID: <20110205150005.40621.qmail@joyce.lan> >and saying "by God, this Owen character is right, we're in breach of >contract and his definition of the purity of Internet ports has so >stunned us with its symmetry and loveliness that we shall bow down and >sin no more! Thank you Mr. DeLong from making the blind see again!" More likely "uh, oh, we've got a loony one here. Maybe if I give him his ten bucks back, he'll go away." R's, John From bmanning at vacation.karoshi.com Sat Feb 5 10:08:09 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 5 Feb 2011 16:08:09 +0000 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <20110205124710.059259B4E31@drugs.dv.isc.org> References: <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org> <4D4C0D25.70408@brightok.net> <20110204231134.3AA029B2B39@drugs.dv.isc.org> <4D4C8AF8.1030703@brightok.net> <20110205004517.371F99B3B3C@drugs.dv.isc.org> <4D4CA1B1.5060002@brightok.net> <20110205124710.059259B4E31@drugs.dv.isc.org> Message-ID: <20110205160809.GB20900@vacation.karoshi.com.> On Sat, Feb 05, 2011 at 11:47:10PM +1100, Mark Andrews wrote: > > In message <4D4CA1B1.5060002 at brightok.net>, Jack Bates writes: > > On 2/4/2011 6:45 PM, Mark Andrews wrote: > > > > > > I used to work for CSIRO. Their /16's which were got back in the > > > late 80's will now be /48's. > > > > That's why I didn't try doing any adjustments of X is the new /32. The > > whole paradigm changes. > > So why the ~!#! are you insisting on comparing IPv4 allocations with IPv6 > alocations. "..96 more bits - no majik.." > Mark --bill From bmanning at vacation.karoshi.com Sat Feb 5 10:22:21 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 5 Feb 2011 16:22:21 +0000 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> Message-ID: <20110205162221.GE20900@vacation.karoshi.com.> On Sat, Feb 05, 2011 at 12:40:44PM +0000, John Curran wrote: > On Feb 5, 2011, at 5:57 AM, bmanning at vacation.karoshi.com wrote: > >> For the ARIN region, it would be nice to know how you'd like ARIN perform > >> in the presence of such activity ("leasing" IP addresses by ISP not providing > >> connectivity). It's possible that such is perfectly reasonable and to simply > >> be ignored, it's also possible that such should be considered a fraudulent > >> transfer and the resources reclaimed. At the end of the day, the policy is > >> set by this community, and clarity over ambiguity is very helpful. > >> ... > > > > the practice predates ARIN by many years... FWIW... > > Good to know; it makes its omission from RFC2050 even more significant and > highlights the need for clear policy in this area. Ultimately, the question > is simply how the operator community wishes to have this treated, and there > should be alignment between that consensus and the number resource policy. > > /John as you pointed out back in oh, IETF-29, actual network operators don't participate much in the standards setting process so its no wonder RFC 2050 has (several) "blind-spots" when it comes to operational reality. and pragmatically, I am not sure that one could come to a single consistent suite of polciy for management of number resource. there's just too many ways (some conflicting) to use them. but this might be a sigma-six outlying POV. ARIN's community certinly is dominated by a particular type of network operator. --bill From jcurran at istaff.org Sat Feb 5 11:24:01 2011 From: jcurran at istaff.org (John Curran) Date: Sat, 5 Feb 2011 12:24:01 -0500 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <20110205162221.GE20900@vacation.karoshi.com> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> Message-ID: <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> On Feb 5, 2011, at 11:22 AM, bmanning at vacation.karoshi.com wrote: > as you pointed out back in oh, IETF-29, actual network operators > don't participate much in the standards setting process so its > no wonder RFC 2050 has (several) "blind-spots" when it comes to > operational reality. > > and pragmatically, I am not sure that one could come to a single > consistent suite of polciy for management of number resource. there's > just too many ways (some conflicting) to use them. but this might be > a sigma-six outlying POV. ARIN's community certinly is dominated by > a particular type of network operator. To the extent that the operator community does not participate in the open standards setting process in the IETF, and also opts not to participate in the open policy development process in the Regional Internet Registries, it is indeed challenging to make sure that the outcomes meet any operational reality. Since the results are useless for everyone if they don't work for the operator community, there is obviously pressure to try to fairly consider those needs as best understood, but it takes good inputs into the system somewhere if we want reasonable outcomes. (my humble opinion alone) /John From patrick at ianai.net Sat Feb 5 11:57:26 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 5 Feb 2011 12:57:26 -0500 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> Message-ID: <8549FCCD-69C5-449A-90AB-95E91EF09500@ianai.net> On Feb 5, 2011, at 12:24 PM, John Curran wrote: > On Feb 5, 2011, at 11:22 AM, bmanning at vacation.karoshi.com wrote: > >> as you pointed out back in oh, IETF-29, actual network operators >> don't participate much in the standards setting process so its >> no wonder RFC 2050 has (several) "blind-spots" when it comes to >> operational reality. >> >> and pragmatically, I am not sure that one could come to a single >> consistent suite of polciy for management of number resource. there's >> just too many ways (some conflicting) to use them. but this might be >> a sigma-six outlying POV. ARIN's community certinly is dominated by >> a particular type of network operator. > > To the extent that the operator community does not participate > in the open standards setting process in the IETF, and also opts > not to participate in the open policy development process in the > Regional Internet Registries, it is indeed challenging to make > sure that the outcomes meet any operational reality. In fairness, Operators are ruled by business needs. Convincing management that we should spend money, time, and effort to change a process which _may_ have some relevance to the bottom line in some very obtuse (and completely unrelated - by accounting standards) way is difficult at best. Add to that the fact most companies are squeezing their employees for every possible efficiency, and even spending your own time on it becomes difficult. Despite all that, I agree it is difficult for the process to take operators' PoV into account if no operator is giving input. > Since the results are useless for everyone if they don't work for > the operator community, there is obviously pressure to try to fairly > consider those needs as best understood, but it takes good inputs > into the system somewhere if we want reasonable outcomes. We appreciate that. And let's hope the operators will make some attempt at being more involved in the process. (Guess I'll have to subscribe to PPML now, which I have been avoiding like the plague for years.) -- TTFN, patrick From joelja at bogus.com Sat Feb 5 12:11:21 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 5 Feb 2011 10:11:21 -0800 Subject: "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: <20110205105731.GA20900@vacation.karoshi.com.> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com.> Message-ID: <3A0FB168-B3AE-490F-B428-9FCC3DE5BF11@bogus.com> > > the practice predates ARIN by many years... FWIW... No reason to play coy... (ep.net) > --bill > From woody at pch.net Sat Feb 5 12:17:29 2011 From: woody at pch.net (Bill Woodcock) Date: Sat, 5 Feb 2011 10:17:29 -0800 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> Message-ID: <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 5, 2011, at 11:22 AM, bmanning at vacation.karoshi.com wrote: > ARIN's community certinly is dominated by a particular type of network operator. It's dominated by the type of network operator who shows up and participates. Generally, I hear what you're saying and don't disagree, but this is one of those truisms that applies across the whole spectrum of Internet governance: constrained-resource allocation, protocol definition, route and capacity forecasting, carrier interconnect, what-have-you. It's the people who sit back and say that someone else is doing it who don't get represented and don't get their way. So while I absolutely recognize the phenomenon you're describing and wish it were otherwise, the solution is action, not complaint. -Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk1NlDkACgkQGvQy4xTRsBF6KACfe+xqvrt8ikLIJme99rLYT1OZ tQYAoJ+VsUMsui5W6ss++aOXOPEqqoRh =Cruc -----END PGP SIGNATURE----- From bmanning at vacation.karoshi.com Sat Feb 5 12:18:45 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 5 Feb 2011 18:18:45 +0000 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> Message-ID: <20110205181845.GA22325@vacation.karoshi.com.> On Sat, Feb 05, 2011 at 12:24:01PM -0500, John Curran wrote: > On Feb 5, 2011, at 11:22 AM, bmanning at vacation.karoshi.com wrote: > > > as you pointed out back in oh, IETF-29, actual network operators > > don't participate much in the standards setting process so its > > no wonder RFC 2050 has (several) "blind-spots" when it comes to > > operational reality. > > > > and pragmatically, I am not sure that one could come to a single > > consistent suite of polciy for management of number resource. there's > > just too many ways (some conflicting) to use them. but this might be > > a sigma-six outlying POV. ARIN's community certinly is dominated by > > a particular type of network operator. > > To the extent that the operator community does not participate > in the open standards setting process in the IETF, and also opts > not to participate in the open policy development process in the > Regional Internet Registries, it is indeed challenging to make > sure that the outcomes meet any operational reality. > > Since the results are useless for everyone if they don't work for > the operator community, there is obviously pressure to try to fairly > consider those needs as best understood, but it takes good inputs > into the system somewhere if we want reasonable outcomes. > > (my humble opinion alone) > /John yeah... we are sharing opinions here.. :) the only analogy i can draw here is one of "land-grant" vs "eminent-domain" in the real estate world. in the case where an entity recevied an allocation at some point (being justified under then then current policy) it is going to take a bit of work to justify expropriation just 'cause the policy has changed... unless of course the RIR is willing to pay the fair market value to the holder to reclaim the space. this report suggests that the question is not RIR specific. http://ciara.fiu.edu/publications/Rubi%20-%20Property%20Rights%20in%20IP%20Numbers.pdf but thats just me. --bill From bmanning at vacation.karoshi.com Sat Feb 5 12:27:34 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 5 Feb 2011 18:27:34 +0000 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> Message-ID: <20110205182734.GB22325@vacation.karoshi.com.> On Sat, Feb 05, 2011 at 10:17:29AM -0800, Bill Woodcock wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Feb 5, 2011, at 11:22 AM, bmanning at vacation.karoshi.com wrote: > > ARIN's community certinly is dominated by a particular type of network operator. > > It's dominated by the type of network operator who shows up and participates. > > Generally, I hear what you're saying and don't disagree, but this is one of those truisms that applies across the whole spectrum of Internet governance: constrained-resource allocation, protocol definition, route and capacity forecasting, carrier interconnect, what-have-you. It's the people who sit back and say that someone else is doing it who don't get represented and don't get their way. So while I absolutely recognize the phenomenon you're describing and wish it were otherwise, the solution is action, not complaint. > > -Bill > there is no complaint here bill. there is simply the observation that if I justified an allocation 20 years ago, under the then current policy, that it is, at best, presumptious to presume the power of expropriation without taking into account the doctrine of eminent domain. If the RIR's and there active members want to take my right to use space away - I expect to be compensated at fair market value. I'm pretty sure that those arguments are going to be tested in the courts ... --bill From jcurran at istaff.org Sat Feb 5 12:31:36 2011 From: jcurran at istaff.org (John Curran) Date: Sat, 5 Feb 2011 13:31:36 -0500 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <20110205181845.GA22325@vacation.karoshi.com> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <20110205181845.GA22325@vacation.karoshi.com> Message-ID: <13771A62-92EE-4B66-A8E5-A54F39D236EF@istaff.org> On Feb 5, 2011, at 1:18 PM, bmanning at vacation.karoshi.com wrote: > > this report suggests that the question is not RIR specific. > http://ciara.fiu.edu/publications/Rubi%20-%20Property%20Rights%20in%20IP%20Numbers.pdf > but thats just me. FYI - Also remember to consider the views from papers that have actually been peer-reviewed and published (attached)... /John > "Legal And Policy Aspects Of Internet Number Resources" > > Santa Clara Computer & High Technology Law Journal. > > Volume 24 > Issue 2 > Page 335 > > Authors: Stephen M. Ryan, Esq. , Raymond A. Plzak , and John Curran > > http://www.chtlj.org/sites/default/files/media/articles/v024/v024.i2.Ryan.pdf From jcurran at istaff.org Sat Feb 5 12:38:29 2011 From: jcurran at istaff.org (John Curran) Date: Sat, 5 Feb 2011 13:38:29 -0500 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <20110205182734.GB22325@vacation.karoshi.com> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> Message-ID: <0CC2721B-C2C9-488F-91C8-520F79A746F8@istaff.org> On Feb 5, 2011, at 1:27 PM, bmanning at vacation.karoshi.com wrote: > On Sat, Feb 05, 2011 at 10:17:29AM -0800, Bill Woodcock wrote: >> ... >> It's dominated by the type of network operator who shows up and participates. >> >> Generally, I hear what you're saying and don't disagree, but this is one of those truisms that applies across the whole spectrum of Internet governance: constrained-resource allocation, protocol definition, route and capacity forecasting, carrier interconnect, what-have-you. It's the people who sit back and say that someone else is doing it who don't get represented and don't get their way. So while I absolutely recognize the phenomenon you're describing and wish it were otherwise, the solution is action, not complaint. >> >> -Bill > > there is no complaint here bill. there is simply the observation that > if I justified an allocation 20 years ago, under the then current policy, > that it is, at best, presumptious to presume the power of expropriation > without taking into account the doctrine of eminent domain. If the > RIR's and there active members want to take my right to use space away - > I expect to be compensated at fair market value. ... Bill - That seems like a particularly strong reason on your part to participate in the policy development process. I happen to believe that the community needs to be particularly respectful of the ability of all address holders to use their space undisturbed, but at the end of the day we have to run according to whatever policies the community develops. /John From james at gitflorida.com Sat Feb 5 12:22:52 2011 From: james at gitflorida.com (James P. Ashton) Date: Sat, 5 Feb 2011 13:22:52 -0500 (EST) Subject: And so it ends... In-Reply-To: Message-ID: <9499604.2426.1296930172108.JavaMail.root@mail.gitflorida.com> John, It seams that by stating "Note that ARIN can't allow transfers contrary to the community-developed policy" that you intend to say that ARIN, based on your current policies and processes, will not actively update whois information for legacy block holders that either "sub-assign" or "Transfer" segments of their legacy space to another entity. Is this the case? If so, as many others seam to be asking, do you and the ARIN legal representatives, feel that you can actually legally follow this course and do you feel that, as you had nothing to do with the assignment of this space that you have any real right to deny these services. The community expects you to to have a certain quality of information in the database and not offering updating services can present operational issues to those of us using the database as intended. James ----- Original Message ----- On Feb 3, 2011, at 6:38 PM, Benson Schliesser wrote: > Having said that, it should be clear that I view ARIN "reclaiming" legacy addresses that aren't under contract (i.e. LRSA) as fraud, perhaps even in the legal sense of the word. It might also be considered theft by some. But outright reclaiming from ongoing address holders isn't a big concern of mine, because I doubt ARIN will go far down that path (if it goes at all). My real concern is that ARIN might refuse to recognize legacy transfers, fail to update the Whois database, issue RPKI inappropriately, and cause real damage to live networks. This would be bad for the networks that implement ARIN Whois-based policy, of course. Benson - ARIN provides legacy holders with WHOIS and IN-ADDR services without charge. If a legacy holder simply wishes to make use of their resources and maintains current directory information, ARIN left them fairly undisturbed since its formation. Via the Legacy RSA, ARIN offers contractual assurances to legacy holders of ARIN providing these services, as well as certain protections from reclamation and policy changes. Note that ARIN can't allow transfers contrary to the community-developed policy, so legacy address holders who wish to do more then just use their resources (e.g. transfer them) are encouraged to get involved in the community to create policies that match their needs. /John John Curran President and CEO ARIN From woody at pch.net Sat Feb 5 13:01:00 2011 From: woody at pch.net (Bill Woodcock) Date: Sat, 5 Feb 2011 11:01:00 -0800 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <20110205182734.GB22325@vacation.karoshi.com.> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com.> Message-ID: <3867203A-05E5-478B-B467-ABA371027743@pch.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 5, 2011, at 10:27 AM, bmanning at vacation.karoshi.com wrote: > If I justified an allocation 20 years ago, under the then current policy, it's presumptuous to presume the power of expropriation. No one presumes it, and a lot of us are in the same boat as you, some of the addresses we're using predating the RIR system. That said, there will always be people who will turn up on the mailing list, participating in the public policy process, who are not in that boat, and whose interests differ significantly, and who will speak in favor of those interests. And the consensus of the public, the people who participate in the public policy process, is what decides > If the RIR's and there active members want to take my right to use space away... This is hyperbole. The RIRs are not people, they have no desires, other perhaps than that of self-perpetuation. I haven't heard _anyone_, active RIR member or otherwise, suggest that a right to _use_ space should be rescinded. The only thing I've heard even the most vehement pro-reclamation people argue in favor of is reclamation of _unused_ space. > I'm pretty sure that those arguments are going to be tested in the courts. And ultimately, the courts uphold community standards. Which is what the public expects. If the community uses the public policy process to set a standard that you cannot meet, it's very _very_ unlikely that a court would side with you in the long term. The community we live in generally believes that paint shouldn't have lead in it, and cars should have seatbelts, and people shouldn't beat their children when they get frustrated, and although each of those things was deemed a god-given right at one time, the courts would not side with someone who did any of them, anymore. So I think the two questions here are whether you really have a grievance (I don't believe you do, since you haven't described a problem that many of the rest of us wouldn't also face), and if so, whether and how you can better your lot (and I think the answer to that is to participate in the public policy process and help establish community norms that you're comfortable with, rather than hoping that a court will buck the tide). -Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk1NnmwACgkQGvQy4xTRsBHqBACdG/EB0mn2C/kd7tANzBVpBUbG EO8AoJu0gXNrNy3OMy88dsz10B9cWUUf =jhkb -----END PGP SIGNATURE----- From jcurran at arin.net Sat Feb 5 13:24:33 2011 From: jcurran at arin.net (John Curran) Date: Sat, 5 Feb 2011 19:24:33 +0000 Subject: And so it ends... In-Reply-To: <9499604.2426.1296930172108.JavaMail.root@mail.gitflorida.com> References: , <9499604.2426.1296930172108.JavaMail.root@mail.gitflorida.com> Message-ID: <7677EAEB-924A-41F7-8DE7-4C89144DE313@arin.net> James - ARIN allows legacy holders to update their registration information, in fact, we even allow such via ARIN Online. No agreement is required with ARIN; we provide this service as well as WHOIS and reverse DNS without charge. If you no longer want to use your address space, you may return it, or transfer according to the community developed policies. /John John Curran President and CEO ARIN On Feb 5, 2011, at 1:54 PM, "James P. Ashton" wrote: > John, > It seams that by stating "Note that ARIN can't allow transfers contrary to the > community-developed policy" that you intend to say that ARIN, based on your current policies and processes, will not actively update whois information for legacy block holders that either "sub-assign" or "Transfer" segments of their legacy space to another entity. > > Is this the case? If so, as many others seam to be asking, do you and the ARIN legal representatives, feel that you can actually legally follow this course and do you feel that, as you had nothing to do with the assignment of this space that you have any real right to deny these services. The community expects you to to have a certain quality of information in the database and not offering updating services can present operational issues to those of us using the database as intended. > > James > > > > ----- Original Message ----- > On Feb 3, 2011, at 6:38 PM, Benson Schliesser wrote: > >> Having said that, it should be clear that I view ARIN "reclaiming" legacy addresses that aren't under contract (i.e. LRSA) as fraud, perhaps even in the legal sense of the word. It might also be considered theft by some. But outright reclaiming from ongoing address holders isn't a big concern of mine, because I doubt ARIN will go far down that path (if it goes at all). My real concern is that ARIN might refuse to recognize legacy transfers, fail to update the Whois database, issue RPKI inappropriately, and cause real damage to live networks. This would be bad for the networks that implement ARIN Whois-based policy, of course. > > Benson - > > ARIN provides legacy holders with WHOIS and IN-ADDR services without charge. > If a legacy holder simply wishes to make use of their resources and maintains > current directory information, ARIN left them fairly undisturbed since its > formation. > > Via the Legacy RSA, ARIN offers contractual assurances to legacy holders of > ARIN providing these services, as well as certain protections from reclamation > and policy changes. Note that ARIN can't allow transfers contrary to the > community-developed policy, so legacy address holders who wish to do more > then just use their resources (e.g. transfer them) are encouraged to get > involved in the community to create policies that match their needs. > > /John > > John Curran > President and CEO > ARIN > > From bmanning at vacation.karoshi.com Sat Feb 5 13:33:28 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 5 Feb 2011 19:33:28 +0000 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <3867203A-05E5-478B-B467-ABA371027743@pch.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com.> <3867203A-05E5-478B-B467-ABA371027743@pch.net> Message-ID: <20110205193328.GC22325@vacation.karoshi.com.> On Sat, Feb 05, 2011 at 11:01:00AM -0800, Bill Woodcock wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On Feb 5, 2011, at 10:27 AM, bmanning at vacation.karoshi.com wrote: > > If I justified an allocation 20 years ago, under the then current policy, it's presumptuous to presume the power of expropriation. > > No one presumes it, and a lot of us are in the same boat as you, some of the addresses we're using predating the RIR system. > > That said, there will always be people who will turn up on the mailing list, participating in the public policy process, who are not in that boat, and whose interests differ significantly, and who will speak in favor of those interests. yup... said that earlier. > And the consensus of the public, the people who participate in the public policy process, is what decides decides current policy. when current policy directly contridicts the policies under which old address space was allocated, which policy trumps? this is where I suspect there will be legal intervention to instruct/enlighten network and rir practice. > > If the RIR's and there active members want to take my right to use space away... > > This is hyperbole. The RIRs are not people, they have no desires, other perhaps than that of self-perpetuation. absent people - RIRs are an empty shell... :) right... their v. there... sorry about that. > I haven't heard _anyone_, active RIR member or otherwise, suggest that a right to _use_ space should be rescinded. The only thing I've heard even the most vehement pro-reclamation people argue in favor of is reclamation of _unused_ space. definition of "used" is not particularly clear and rarely has been. the most pragmatic has been ... "when a recognized authority has delegated the address space" -- when that was Postel, or SRI, or NSI, or ARIN, or Dupont, or Rice University, or PCH, or ep.net... doesn't really matter. it was a recognized authority. when one authority disputes the rights of another, there is really one one venue for resolution... > > I'm pretty sure that those arguments are going to be tested in the courts. > > And ultimately, the courts uphold community standards. Which is what the public expects. If the community uses the public policy process to set a standard that you cannot meet, it's very _very_ unlikely that a court would side with you in the long term. The community we live in generally believes that paint shouldn't have lead in it, and cars should have seatbelts, and people shouldn't beat their children when they get frustrated, and although each of those things was deemed a god-given right at one time, the courts would not side with someone who did any of them, anymore. which is where we end up w/ the doctrine of eminent domain. and legacy/historical values do have some recognition in courts... my Ford Model T doesn't have seat belts... :) > > So I think the two questions here are whether you really have a grievance (I don't believe you do, since you haven't described a problem that many of the rest of us wouldn't also face), and if so, whether and how you can better your lot (and I think the answer to that is to participate in the public policy process and help establish community norms that you're comfortable with, rather than hoping that a court will buck the tide). of course I don't have a grievance... thats your allergic reaction :) as to your point of changing policy - sure, i could do that and i hope people become engaged... HOWEVER - I am not persuaded that a single policy framework will be applicable to all users of IP space... so n matter what current ARIN policy is - its not likely to be an exact match to the number resource policies of DuPont, or DoD, or Ohio State, or Google, or Nintendo, Toyota, PCH, or Bills Bait & Sushi. Nor can it ever be. Of course ARIN has every right to maintain its database (whois) in any way that it sees fit and how its members dictate - but unless the rights of all players are acknowledged/respected - I think ARIN is in danger of losing relevence. And that would be a great loss. --bill From owen at delong.com Sat Feb 5 14:25:22 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 5 Feb 2011 12:25:22 -0800 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <20110205182734.GB22325@vacation.karoshi.com.> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com.> Message-ID: On Feb 5, 2011, at 10:27 AM, bmanning at vacation.karoshi.com wrote: > On Sat, Feb 05, 2011 at 10:17:29AM -0800, Bill Woodcock wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On Feb 5, 2011, at 11:22 AM, bmanning at vacation.karoshi.com wrote: >>> ARIN's community certinly is dominated by a particular type of network operator. >> >> It's dominated by the type of network operator who shows up and participates. >> >> Generally, I hear what you're saying and don't disagree, but this is one of those truisms that applies across the whole spectrum of Internet governance: constrained-resource allocation, protocol definition, route and capacity forecasting, carrier interconnect, what-have-you. It's the people who sit back and say that someone else is doing it who don't get represented and don't get their way. So while I absolutely recognize the phenomenon you're describing and wish it were otherwise, the solution is action, not complaint. >> >> -Bill >> > > there is no complaint here bill. there is simply the observation that > if I justified an allocation 20 years ago, under the then current policy, > that it is, at best, presumptious to presume the power of expropriation > without taking into account the doctrine of eminent domain. If the > RIR's and there active members want to take my right to use space away - > I expect to be compensated at fair market value. I'm pretty sure that > those arguments are going to be tested in the courts ... > > --bill Bill, The RIRs can't take your right to do anything away, including your right to run a competing registry in which you are the sole recipient of 0.0.0.0/2 if you like. What the RIRs MIGHT do (and note that I would not support such action) is terminate registration services for those that have no contract with the RIR. Once they have done that, they are free to register the uniqueness of numbers previously registered as a free service to those without contracts to others who do have contracts. Whether or not anyone in the outside world makes use of that registration data is a matter of independent decision on the part of each consumer of registration data. Your right to use a particular set of addresses on a particular network is not granted by any RIR. It is granted by the people who run the routers on that network. It is up to the operators of each individual network to choose which network numbers they route and to whom. The fact that a very large number of network operators use the data contained in the RIR system in a cooperative manner is convenient and makes the internet substantially more useful than I can imagine it would be under alternative scenarios. However, that does not mean that the RIRs are granting any sort of license, right to use, or ownership. Nor does it mean that terminating a registration constitutes taking away such a grant that was never given. Owen From jcurran at arin.net Sat Feb 5 15:12:53 2011 From: jcurran at arin.net (John Curran) Date: Sat, 5 Feb 2011 21:12:53 +0000 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <20110205193328.GC22325@vacation.karoshi.com> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <20110205193328.GC22325@vacation.karoshi.com> Message-ID: <08F8827D-D8C3-4922-AC39-6C71ADBE8BDB@corp.arin.net> On Feb 5, 2011, at 2:33 PM, bmanning at vacation.karoshi.com wrote: > decides current policy. when current policy directly contridicts the policies > under which old address space was allocated, which policy trumps? Bill - RFC 2050 is the document which provides the registry system framework. Jon Postel is an author of same, as well as a founder of ARIN. We've adhered to these principles from RFC 2050 in address management without exception, and even in policy development today. When you speak of the policies of old allocations, please be specific. If they predated Jon, that would indeed be quite interesting. /John John Curran President and CEO ARIN From jbates at brightok.net Sat Feb 5 15:36:23 2011 From: jbates at brightok.net (Jack Bates) Date: Sat, 05 Feb 2011 15:36:23 -0600 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com.> Message-ID: <4D4DC2D7.7080009@brightok.net> On 2/5/2011 2:25 PM, Owen DeLong wrote: > Your right to use a particular set of addresses on a particular network is > not granted by any RIR. It is granted by the people who run the routers > on that network. It is up to the operators of each individual network to > choose which network numbers they route and to whom. Which would become extremely fun in a conflict case like this, as depending on which network you asked, they could consider either party to be the party that is "hijacking" the space. Jack From mysidia at gmail.com Sat Feb 5 16:53:08 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 5 Feb 2011 16:53:08 -0600 Subject: And so it ends... In-Reply-To: <7677EAEB-924A-41F7-8DE7-4C89144DE313@arin.net> References: <9499604.2426.1296930172108.JavaMail.root@mail.gitflorida.com> <7677EAEB-924A-41F7-8DE7-4C89144DE313@arin.net> Message-ID: On Sat, Feb 5, 2011 at 1:24 PM, John Curran wrote: > ? ?ARIN allows legacy holders to update their registration information, in fact, we even allow such via ARIN Online. ?No agreement is required with ARIN; we provide this service as well as WHOIS and reverse DNS without charge. > ? ? If you no longer want to use your address space, you may return it, or transfer according to the community developed policies. I think he means to ask: What happens if a legacy registrant (who has not signed any RSA) ad-hoc decided on their own that they have transferred some portion of their space (or their entire address space) to a different organization who was not named on the original IANA or Internic registration, and the legacy resource holder (or transfer recipient) cannot show their transfer was made with/through the approval of IANA, Internic, any RIR, etc, under any legacy policy, the legacy registry did not reflect it, (so there is no existing 'official' record of a transfer). Does ARIN recognize updates from organizations who claim that some resources were transferred to them by a legacy holder and treat the transfer recipient as a valid legacy resource holder? Particularly.... in difficult cases where the original legacy resource holder is completely defunct; the original organization named in the IANA or Internic registration might have moved (where multiple organizations have similar names), be bankrupt, have merged, or renamed itself, no longer able to be contacted, and the "claimed holder" might be claiming the entire legacy allocation was transferred to them (without WHOIS ever being updated) ? Does ARIN recognize all transfers claimed by the verifiable original legacy resource holder and treat transfers they claim to have made as valid? Or is some proof required that any transfer was made before ARIN existed (if an ARIN transfer policy was not followed)? Will they be allowed to update ARIN to reflect their ad-hoc "transfer" (which did not occur in a way that is valid under any current ARIN policy). *Since ARIN policy at the current time requires specified transfers be made through ARIN, and the recipient of address has to meet a utilization criterion. No ad-hoc transfers would seem to be allowed by current ARIN policies, except non-permanent reassignments. For example, if a legacy registrant with a /8 decided "One particular /24 somewhere in the middle of the assignment now permanently belongs to $OTHER_ENTITY" Will ARIN allow them to update WHOIS with that, and from then on treat $OTHER_ENTIY as a legacy holder of that one /24... with $ORIGINAL_ENTITY treated as a legacy holder who 'owns' all the /8 except one /24 ? Will ARIN allow the legacy resource holder to indicate "We have (non-permanently) reallocated or sub-delegated such and such /24 to $OTHER_ENTITY" Even if the legacy holder when obtaining the /8 was an "end user" (and not an ISP) when they obtained their legacy resources? > /John > John Curran > President and CEO > ARIN -- -JH From johnl at iecc.com Sat Feb 5 17:06:13 2011 From: johnl at iecc.com (John Levine) Date: 5 Feb 2011 23:06:13 -0000 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <4D4DC2D7.7080009@brightok.net> Message-ID: <20110205230613.9747.qmail@joyce.lan> >> Your right to use a particular set of addresses on a particular >> network is not granted by any RIR. As far as I know, there's no case law about address space assignments. There's been a bunch of cases where someone stole address space by pretending to be the original assignee, like the SF Bay Packet Radio case in 2008, but as far as I know, the ones that have been resolved were resolved without a court's help. There's also plenty of stolen address space still in use by the party that stole it. If there have been cases with a willing seller and a willing buyer where ARIN has refused to update WHOIS or rDNS, I'd be interested to hear about them. R's, John From jbates at brightok.net Sat Feb 5 17:07:18 2011 From: jbates at brightok.net (Jack Bates) Date: Sat, 05 Feb 2011 17:07:18 -0600 Subject: And so it ends... In-Reply-To: References: <9499604.2426.1296930172108.JavaMail.root@mail.gitflorida.com> <7677EAEB-924A-41F7-8DE7-4C89144DE313@arin.net> Message-ID: <4D4DD826.70904@brightok.net> On 2/5/2011 4:53 PM, Jimmy Hess wrote: > *Since ARIN policy at the current time requires specified transfers be > made through ARIN, > and the recipient of address has to meet a utilization criterion. > No ad-hoc transfers would seem to be allowed by current ARIN policies, > except non-permanent reassignments. I think ARIN's stance is they can update whois and issue reallocations/assignment information into whois based on their Legacy status. If they want to permanently give their space to someone else, documentation wise, the most they can do is allocate the entire space to the other person. They are still considered the primary holder and the only thing that makes it "permanent" is the contract signed between them and the other party. Given the reallocation, I'm sure the receiving party also can update whois. Jack From jbates at brightok.net Sat Feb 5 17:09:12 2011 From: jbates at brightok.net (Jack Bates) Date: Sat, 05 Feb 2011 17:09:12 -0600 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <20110205230613.9747.qmail@joyce.lan> References: <20110205230613.9747.qmail@joyce.lan> Message-ID: <4D4DD898.1030408@brightok.net> On 2/5/2011 5:06 PM, John Levine wrote: > If there have been cases with a willing seller and a willing buyer > where ARIN has refused to update WHOIS or rDNS, I'd be interested to > hear about them. Isn't it moot when you can reallocate the entire block to the other party? Contractual agreements of the sale would enforce the inability to reclaim or remove the reallocation. Jack From aaron at wholesaleinternet.net Sat Feb 5 17:12:40 2011 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Sat, 5 Feb 2011 17:12:40 -0600 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <20110205230613.9747.qmail@joyce.lan> References: <4D4DC2D7.7080009@brightok.net> <20110205230613.9747.qmail@joyce.lan> Message-ID: <0d7e01cbc58a$340347a0$9c09d6e0$@net> How can someone steal something from you that you don?t own? From: John Levine [mailto:johnl at iecc.com] Sent: Saturday, February 05, 2011 5:06 PM To: nanog at nanog.org Subject: Re: "Leasing" of space via non-connectivity providers >> Your right to use a particular set of addresses on a particular >> network is not granted by any RIR. As far as I know, there's no case law about address space assignments. There's been a bunch of cases where someone stole address space by pretending to be the original assignee, like the SF Bay Packet Radio case in 2008, but as far as I know, the ones that have been resolved were resolved without a court's help. There's also plenty of stolen address space still in use by the party that stole it. If there have been cases with a willing seller and a willing buyer where ARIN has refused to update WHOIS or rDNS, I'd be interested to hear about them. R's, John _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1204 / Virus Database: 1435/3424 - Release Date: 02/05/11 From johnl at iecc.com Sat Feb 5 17:25:07 2011 From: johnl at iecc.com (John R. Levine) Date: 5 Feb 2011 18:25:07 -0500 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <4D4DD898.1030408@brightok.net> References: <20110205230613.9747.qmail@joyce.lan> <4D4DD898.1030408@brightok.net> Message-ID: >> If there have been cases with a willing seller and a willing buyer >> where ARIN has refused to update WHOIS or rDNS, I'd be interested to >> hear about them. > > Isn't it moot when you can reallocate the entire block to the other party? > Contractual agreements of the sale would enforce the inability to reclaim or > remove the reallocation. If the user doesn't match what's in WHOIS, a lot of people will assume that the block is hijacked. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From johnl at iecc.com Sat Feb 5 17:39:44 2011 From: johnl at iecc.com (John Levine) Date: 5 Feb 2011 23:39:44 -0000 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <0d7e01cbc58a$340347a0$9c09d6e0$@net> Message-ID: <20110205233944.17980.qmail@joyce.lan> In article <0d7e01cbc58a$340347a0$9c09d6e0$@net> you write: >How can someone steal something from you that you don?t own? Here in the US, until there is statutory or case law, the question of whether the people with legacy IP space assignments own that space is entirely a matter of opinion. I realize a lot of people have made a lot of assertions, but anyone can assert anything. R's, John From jbates at brightok.net Sat Feb 5 17:41:23 2011 From: jbates at brightok.net (Jack Bates) Date: Sat, 05 Feb 2011 17:41:23 -0600 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: References: <20110205230613.9747.qmail@joyce.lan> <4D4DD898.1030408@brightok.net> Message-ID: <4D4DE023.3090608@brightok.net> On 2/5/2011 5:25 PM, John R. Levine wrote: >> >> Isn't it moot when you can reallocate the entire block to the other >> party? Contractual agreements of the sale would enforce the inability >> to reclaim or remove the reallocation. > > If the user doesn't match what's in WHOIS, a lot of people will assume > that the block is hijacked. That's my point. If a legacy holder can update WHOIS, I presume they can also just allocate the entire block to someone else. It would reflect that in WHOIS, no one would consider it hijacked. Jack From nenolod at systeminplace.net Sat Feb 5 17:44:48 2011 From: nenolod at systeminplace.net (William Pitcock) Date: Sat, 5 Feb 2011 17:44:48 -0600 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <0d7e01cbc58a$340347a0$9c09d6e0$@net> References: <4D4DC2D7.7080009@brightok.net> <20110205230613.9747.qmail@joyce.lan> <0d7e01cbc58a$340347a0$9c09d6e0$@net> Message-ID: <20110205174448.68dd7be8@petrie> Hi, On Sat, 5 Feb 2011 17:12:40 -0600 "Aaron Wendel" wrote: > How can someone steal something from you that you don?t own? > > Legacy space. The best example I can think of was Choopa's hijacking of Erie Forge and Steel's legacy space. In this case, it was theft as it was a legacy allocation and therefore "owned" by EFS. EFS however, did not notice because they were not using the legacy allocation for anything. William From ernesto at cs.fiu.edu Sat Feb 5 17:54:16 2011 From: ernesto at cs.fiu.edu (Ernie Rubi) Date: Sat, 5 Feb 2011 18:54:16 -0500 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <20110205230613.9747.qmail@joyce.lan> References: <20110205230613.9747.qmail@joyce.lan> Message-ID: <77CDE0D3-FAB7-4924-8370-FE88941DD861@cs.fiu.edu> Good question: Depends on what kind of address space assignment - if you mean legacy IP space, then no there is no case law. Kremen v. ARIN (Northern District of CA) is the only case law out there, but it is on point only as to 'current' IP space. In Kremen, the district court went only as far as saying that ARIN is the only available source for ?current? allocations. The court, in a motion to amend a prior ex parte order, found an applicant seeking IP space ?could only receive the number resources if he followed ARIN?s procedures, applied for...the resources, and signed ARIN?s standard Registration Services Agreement in effect when the resources were issued." There is no statutory (federal / state) authority on point; other than: Federal statutory law now makes a felony for anyone to ?falsely represent oneself to be the registrant...of 5 or more Internet Protocol addresses, and intentionally initiate the transmission of multiple commercial electronic mail messages from such addresses.? (See 18 U.S.C.A. ? 1037(a)(5), (2003)) Compare this to the well established law on domain name transfers (Anti Cybersquatting Protection Act; WIPO Treaties; state and federal cases). Ernie On Feb 5, 2011, at 6:06 PM, John Levine wrote: >>> Your right to use a particular set of addresses on a particular >>> network is not granted by any RIR. > > As far as I know, there's no case law about address space assignments. > > There's been a bunch of cases where someone stole address space by > pretending to be the original assignee, like the SF Bay Packet Radio > case in 2008, but as far as I know, the ones that have been resolved > were resolved without a court's help. There's also plenty of stolen > address space still in use by the party that stole it. > > If there have been cases with a willing seller and a willing buyer > where ARIN has refused to update WHOIS or rDNS, I'd be interested to > hear about them. > > R's, > John From zaid at zaidali.com Sat Feb 5 18:19:09 2011 From: zaid at zaidali.com (Zaid Ali) Date: Sun, 6 Feb 2011 11:19:09 +1100 Subject: External sanity checks In-Reply-To: <12095298.254.1296786966316.JavaMail.franck@franck-martins-macbook-pro.local> References: <12095298.254.1296786966316.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On Feb 4, 2011, at 1:36 PM, Franck Martin wrote: > > ----- Original Message ----- >> From: "Paul Graydon" >> To: nanog at nanog.org >> Sent: Friday, 4 February, 2011 8:39:09 AM >> Subject: Re: External sanity checks >> On 02/03/2011 08:04 AM, Philip Lavine wrote: >>> To all, >>> >>> Does any one know a Vendor (NOT Keynote) that can do sanity checks >>> against your web/smtp/ftp farms with pings, traceroutes, latency >>> checks as well as application checks (GET, POST, ESMTP, etc) >>> >>> Thank you, >>> >>> Philip >>> >> Slight hijack, I'm interested in the answer to this question, but I'm >> also wondering about a service that will actually phone you (or is >> there >> a reliable text/e-mail->phone call service?) I'd appreciate actually >> being phoned overnight if something dies drastically to the outside >> world! > > A bit different, but if you are looking for something that works a bit before the problem becomes visible to the user, check: > > http://www.avonsys.com/Application+Monitoring > I used Avonsys before for monitoring. You can have Keynote, Gomez, homegrown tool etc but you still need someone with clue on how to interpret it, verify alerts, find odd performance problems etc. Contact me off list if you want reference. Zaid From jlewis at lewis.org Sat Feb 5 18:30:39 2011 From: jlewis at lewis.org (Jon Lewis) Date: Sat, 5 Feb 2011 19:30:39 -0500 (EST) Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <4D4DE023.3090608@brightok.net> References: <20110205230613.9747.qmail@joyce.lan> <4D4DD898.1030408@brightok.net> <4D4DE023.3090608@brightok.net> Message-ID: On Sat, 5 Feb 2011, Jack Bates wrote: > That's my point. If a legacy holder can update WHOIS, I presume they can also > just allocate the entire block to someone else. It would reflect that in > WHOIS, no one would consider it hijacked. Does ARIN accept SWIP requests for IPs within legacy space assignments? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From marka at isc.org Sat Feb 5 19:01:45 2011 From: marka at isc.org (Mark Andrews) Date: Sun, 06 Feb 2011 12:01:45 +1100 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: Your message of "Sat, 05 Feb 2011 08:34:36 MDT." <4D4D5FFC.6020905@brightok.net> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org> <4D4C0D25.70408@brightok.net> <20110204231134.3AA029B2B39@drugs.dv.isc.org> <4D4C8AF8.1030703@brightok.net> <20110205004517.371F99B3B3C@drugs.dv.isc.org> <4D4CA1B1.5060002@brightok.net> <20110205124710.059259B4E31@drugs.dv.isc.org> <4D4D5FFC.6020905@brightok.net> Message-ID: <20110206010145.9DCD99B60B9@drugs.dv.isc.org> In message <4D4D5FFC.6020905 at brightok.net>, Jack Bates writes: > On 2/5/2011 6:47 AM, Mark Andrews wrote: > > So why the ~!#! are you insisting on comparing IPv4 allocations with IPv6 > > alocations. > > > Because that is where the comparison must be made, at the RIR allocation > size/rate level. > > > There are two sizes. Those that fit into a /32 and those that don't. > > The latter ones have to justify their allocations. > > > Yeah, tell that to the fee schedules. > > > No. You need to compare it to the number of customer sites. If you > > have 1 customer with wires going to two locations thats two /48's. > > That's definitely the wrong way to look at it. Sure that's related to > justification to an RIR to get an allocation, but ISPs will end up with > much more flexible address space. > > > Residential ISPs shift 16 bits (48-32=16). You shift less if you > > have less than 64000 customers sites and don't get address space > > from a larger ISP. Commercial ISPs shift more as what was multiple > > address at one sites becomes 1 /48. > > > > 64,000 customer sites isn't required to receive more than a /32 (unless > a single router makes up your entire network). No, but you still need to have reserved growth space sensibly. /32 for a town of 3000 is overkill. Last assume you are serving a home customers so you were at 1 address per customer. You still size your pops based on expected customers and having some growth room without having to renumber. n customers requires f(n) sized block of space. The only difference with IPv6 is f(n) << 80 bits to support /48's instead of single addresses. Expected growth rates in customers don't change because you are suddenly dealing with IPv6. > Well, I currently have a /30, which is a 14 bit shift right from my /16. > (30-16=14). And did you change the amount of growth space you allowed for each pop? Were you already constrained in your IPv4 growth space and just restored your desired growth margins? > In the near future I expect to be somewhere between a /24 > and a /28, which is an 8 to 12 bit shift right from my IPv4 /16 allocation. Only if you can serve all those customers from that /16. You are then not comparing apples to apples. You are comparing a net with no growth space (IPv4) to one with growth space (IPv6). > Still, that is a considerable number of bits we'll have left when the > dust settles and the RIR allocation rate drastically slows. > > Jack -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Sat Feb 5 19:14:04 2011 From: marka at isc.org (Mark Andrews) Date: Sun, 06 Feb 2011 12:14:04 +1100 Subject: Random Port Blocking at Hotels (was: Re: quietly....) In-Reply-To: Your message of "05 Feb 2011 15:00:05 -0000." <20110205150005.40621.qmail@joyce.lan> References: <20110205150005.40621.qmail@joyce.lan> Message-ID: <20110206011404.A19A99B625C@drugs.dv.isc.org> In message <20110205150005.40621.qmail at joyce.lan>, John Levine writes: > >and saying "by God, this Owen character is right, we're in breach of > >contract and his definition of the purity of Internet ports has so > >stunned us with its symmetry and loveliness that we shall bow down and > >sin no more! Thank you Mr. DeLong from making the blind see again!" > > More likely "uh, oh, we've got a loony one here. Maybe if I give him > his ten bucks back, he'll go away." > > R's, > John I have told a hotel they need to install equipment that supports RA guard as I've checked out. This was a hotel that only offered IPv4. Hotels ask for feedback on their services. If you see a fault report it in writing. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From fred at cisco.com Sat Feb 5 08:43:14 2011 From: fred at cisco.com (Fred Baker) Date: Sat, 5 Feb 2011 14:43:14 +0000 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <88BC6885D33A9D42A1CCB45E8749525E013CBC58@pigeon.sandiego.nextlevelinternet.com> References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> <96503CEA-C922-47A6-9691-FCF157DF15D5@internode.com.au> <10A940BA-6D90-4663-B942-5FFF2CB49D7A@internode.com.au> <4D4BAD13.9090301@gmail.com> <88BC6885D33A9D42A1CCB45E8749525E013CBC58@pigeon.sandiego.nextlevelinternet.com> Message-ID: <72609B8A-05D2-4039-85C4-A0578B9E6911@cisco.com> On Feb 4, 2011, at 9:49 PM, Hayden Katzenellenbogen wrote: > Not sure if it has been said already but wasn't one of the key point for > the creation of the internet to create and infrastructure that would > survive in the case of all out war and massive destruction. (strategic > nuclear strikes) Urban legend, although widely believed. Someone probably made the observation. > Does it not bode ill for "national security" if any party could take out > a massive communication system by destroying/pressuring a few choke > points? You mean, like drop a couple of trade towers and take out three class five switches, causing communication outages throughout New England and New Jersey, and affecting places as far away as Chicago? Nope. Couldn't happen. More seriously, yes, one could in fact take out any connectivity one wants by withdrawing routes (which is reportedly what Egypt did), and if you hit enough interchange points that could get serious. At the risk of sounding naive and pollyanna-ish, we have a few more of those interchange points in the US than they have in Egypt. In theory, yes. Making it actually happen could be quite an operation. > -----Original Message----- > From: JC Dill [mailto:jcdill.lists at gmail.com] > Sent: Thursday, February 03, 2011 11:39 PM > To: NANOG list > Subject: Re: Weekend Gedankenexperiment - The Kill Switch > > On 03/02/11 10:38 PM, Paul Ferguson wrote: >> >> And as an aside, governments will always believe that that they can > control >> the flow of information, when push comes to shove. >> >> This has always been a hazard, and will always continue to be so. >> >> As technologists, we need to be cognizant of that fact. > > In the US, by accident (surely not by design) we are lucky that our > network of networks does not have the convenient 4 chokepoints that the > Egyptian network had, making it easy for the government to shut off the > entier internet by putting pressure on just 4 companies. > > Where we *really* need to be fighting this battle is in the laws and > policies that are producing a duopoly in much of the US where consumers > have 2 choices, the ILEC for DSL or their local cableco for Cable > Internet. As theses companies push smaller competing ISPs out of > business, and as they consolidate (e.g. Cablecos buying each other up, > resulting in fewer and fewer cablecos over time), we head down the > direction of Egypt, where pressure on just a few companies CAN shut down > > the entire internet. Otherwise we end up with a few companies that will > > play Visa and PayPal and roll over and play dead when a government > official says "Wikileaks is bad" - and equally easily will shut down > their entire networks for "national security". > > If you *really* believe that the TSA is effective, you would be in favor > > of an Internet Kill Switch. If you understand that this is really > security theater, and despite all the inconvenience we aren't really any > > safer, then you should equally be very concerned that someone ever has > the power to order that the internet be "shut down" for our safety. > > jc > > > From jbates at brightok.net Sat Feb 5 19:20:30 2011 From: jbates at brightok.net (Jack Bates) Date: Sat, 05 Feb 2011 19:20:30 -0600 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <20110206010145.9DCD99B60B9@drugs.dv.isc.org> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org> <4D4C0D25.70408@brightok.net> <20110204231134.3AA029B2B39@drugs.dv.isc.org> <4D4C8AF8.1030703@brightok.net> <20110205004517.371F99B3B3C@drugs.dv.isc.org> <4D4CA1B1.5060002@brightok.net> <20110205124710.059259B4E31@drugs.dv.isc.org> <4D4D5FFC.6020905@brightok.net> <20110206010145.9DCD99B60B9@drugs.dv.isc.org> Message-ID: <4D4DF75E.1040109@brightok.net> On 2/5/2011 7:01 PM, Mark Andrews wrote: > And did you change the amount of growth space you allowed for each pop? > Were you already constrained in your IPv4 growth space and just restored > your desired growth margins? > Growth rate has nothing to do with it. ARIN doesn't allow for growth in initial assignments. No predictions, no HD-Ratio, and definitely no nibble alignments. Current policy proposal hopes to fix a lot of that. >> In the near future I expect to be somewhere between a /24 >> and a /28, which is an 8 to 12 bit shift right from my IPv4 /16 allocation. > Only if you can serve all those customers from that /16. You are > then not comparing apples to apples. You are comparing a net with > no growth space (IPv4) to one with growth space (IPv6). > Not sure I get ya here. I am comparing apples to apples. ARIN gives me a /16 of space. There are the same number of /16's in IPv4 as IPv6. However, in IPv6, they will allocate a /24 at most to me, and I will never exceed that. This shift of 8+ bits is the gains we get shifting from IPv4 to IPv6. Jack From dredd at megacity.org Sat Feb 5 19:34:19 2011 From: dredd at megacity.org (Derek J. Balling) Date: Sat, 5 Feb 2011 20:34:19 -0500 Subject: Random Port Blocking at Hotels (was: Re: quietly....) In-Reply-To: <20110206011404.A19A99B625C@drugs.dv.isc.org> References: <20110205150005.40621.qmail@joyce.lan> <20110206011404.A19A99B625C@drugs.dv.isc.org> Message-ID: On Feb 5, 2011, at 8:14 PM, Mark Andrews wrote: > I have told a hotel they need to install equipment that supports RA > guard as I've checked out. This was a hotel that only offered IPv4. Wow... Could that be any more of a waste of yours and their time? This is like telling the cashier at the hospital when you're being discharged, "y'know, I'm not sure that they're using the proper stitch-knot in the ER. You should have someone look at that." Do you honestly think that feedback is even *understood*, let alone passed on to anyone even close to the problem? D From bmanning at vacation.karoshi.com Sat Feb 5 19:40:14 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 6 Feb 2011 01:40:14 +0000 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <08F8827D-D8C3-4922-AC39-6C71ADBE8BDB@corp.arin.net> References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <20110205193328.GC22325@vacation.karoshi.com> <08F8827D-D8C3-4922-AC39-6C71ADBE8BDB@corp.arin.net> Message-ID: <20110206014014.GG22325@vacation.karoshi.com.> On Sat, Feb 05, 2011 at 09:12:53PM +0000, John Curran wrote: > On Feb 5, 2011, at 2:33 PM, bmanning at vacation.karoshi.com wrote: > > > decides current policy. when current policy directly contridicts the policies > > under which old address space was allocated, which policy trumps? > > Bill - > > RFC 2050 is the document which provides the registry system framework. Jon Postel is an author of same, as well as a founder of ARIN. yup.. i was there when it was written. what is not clear in that RFC is the status and effect of RFC 2050 (and subsiquent policy built on that foundation) on allocations made -prior- to RFC 2050. telling text is here: "This document describes the IP assignment policies currently used by the Regional Registries to implement the guidelines developed by the IANA...." It does not talk to address space allocated to entities from the IANA or other registries prior to the RIRs existance. oddly enough, the year prior to RFC 2050 being published, jon asked me to run a specialized address registry for things like exchange points. that service matched the subject of this thread... we didn't own any infrastrucuture, but we provided (and successors still provide) neutral address management services to those who wish it. it took the RIR system a few years to catch up and provide a similar service. > We've adhered to these principles from RFC 2050 in address management without exception, and even in policy development today. a firm foundation on which to build. > When you speak of the policies of > old allocations, please be specific. If they predated Jon, that would indeed be quite interesting. well - jon did point out the butcher-paper agreement, signed by all the grad students, agreeing that jon was the address maven... so anything pre-dating jon would be a trick. (the actual document is in the postel archives ... if you are interested...) i beleive i have produced for ARIN a letter from SRI to me - indicating that certain address blocks were given to me to use. No reference to an entity other than me, no claim for compliance with "justified need" or "acceptable-use", no indication that any subsiquant policy would be binding in the future. Pretty much, "we are sorry that you were forced to renumber 'cause we messed up w/ the -connected/unconneted- databases - please take these blocks as a token of our consideration..." Doesn't sound like RFC 2050 fodder to me. This type of letter flies in the face of current policy; allocations to legal entities that are not natural persons, justified need, requirements to periodically check in and re-affirm usage & compliance.... I just think that there are going to be turbulent waters when the ARIN community pushes to hard to force these folk into their (narrow) framework of acceptable use. I wish it was not so - but I am persuaded that it will be inevitable - given the current course of events. > > /John > > John Curran > President and CEO > ARIN From johnl at iecc.com Sat Feb 5 20:06:49 2011 From: johnl at iecc.com (John R. Levine) Date: 5 Feb 2011 21:06:49 -0500 Subject: Random Port Blocking at Hotels (was: Re: quietly....) In-Reply-To: <20110206011404.A19A99B625C@drugs.dv.isc.org> References: <20110205150005.40621.qmail@joyce.lan> <20110206011404.A19A99B625C@drugs.dv.isc.org> Message-ID: > I have told a hotel they need to install equipment that supports RA > guard as I've checked out. This was a hotel that only offered IPv4. > > Hotels ask for feedback on their services. If you see a fault report > it in writing. Sure. Bet you ten bucks that no hotel in North America offers IPv6 this year in the wifi they provide to customers. (Conference networks don't count.) Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From dhc2 at dcrocker.net Sat Feb 5 20:11:45 2011 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Sat, 05 Feb 2011 18:11:45 -0800 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <72609B8A-05D2-4039-85C4-A0578B9E6911@cisco.com> References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> <96503CEA-C922-47A6-9691-FCF157DF15D5@internode.com.au> <10A940BA-6D90-4663-B942-5FFF2CB49D7A@internode.com.au> <4D4BAD13.9090301@gmail.com> <88BC6885D33A9D42A1CCB45E8749525E013CBC58@pigeon.sandiego.nextlevelinternet.com> <72609B8A-05D2-4039-85C4-A0578B9E6911@cisco.com> Message-ID: <4D4E0361.3060505@dcrocker.net> On 2/5/2011 6:43 AM, Fred Baker wrote: > On Feb 4, 2011, at 9:49 PM, Hayden Katzenellenbogen wrote: >> Not sure if it has been said already but wasn't one of the key point for >> the creation of the internet to create and infrastructure that would >> survive in the case of all out war and massive destruction. (strategic >> nuclear strikes) > > Urban legend, although widely believed. Someone probably made the observation. Maybe not quite an UL... On the average, The Rand Corp is extremely careful about what it publishes, yet here it is, repeating the claim. Back in the '70s, I always heard "survive hostile battlefield conditions" and never heard anyone talk about comms survival of a nuclear event, but I wasn't in any interesting conversations, such as in front of funding agencies... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nathan at atlasnetworks.us Sat Feb 5 20:38:37 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Sun, 6 Feb 2011 02:38:37 +0000 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <4D4D5FFC.6020905@brightok.net> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org> <4D4C0D25.70408@brightok.net> <20110204231134.3AA029B2B39@drugs.dv.isc.org> <4D4C8AF8.1030703@brightok.net> <20110205004517.371F99B3B3C@drugs.dv.isc.org> <4D4CA1B1.5060002@brightok.net> <20110205124710.059259B4E31@drugs.dv.isc.org> <4D4D5FFC.6020905@brightok.net> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B35D455@ex-mb-1.corp.atlasnetworks.us> > Still, that is a considerable number of bits we'll have left when the dust > settles and the RIR allocation rate drastically slows. Like it did for IPv4? ;) -Nathan From marka at isc.org Sat Feb 5 20:40:51 2011 From: marka at isc.org (Mark Andrews) Date: Sun, 06 Feb 2011 13:40:51 +1100 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: Your message of "Sat, 05 Feb 2011 19:20:30 MDT." <4D4DF75E.1040109@brightok.net> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org> <4D4C0D25.70408@brightok.net> <20110204231134.3AA029B2B39@drugs.dv.isc.org> <4D4C8AF8.1030703@brightok.net> <20110205004517.371F99B3B3C@drugs.dv.isc.org> <4D4CA1B1.5060002@brightok.net> <20110205124710.059259B4E31@drugs.dv.isc.org> <4D4D5FFC.6020905@brightok.net> <20110206010145.9DCD99B60B9@drugs.dv.isc.org> <4D4DF75E.1040109@brightok.net> Message-ID: <20110206024051.D60349B6D50@drugs.dv.isc.org> In message <4D4DF75E.1040109 at brightok.net>, Jack Bates writes: > On 2/5/2011 7:01 PM, Mark Andrews wrote: > > And did you change the amount of growth space you allowed for each pop? > > Were you already constrained in your IPv4 growth space and just restored > > your desired growth margins? > > > Growth rate has nothing to do with it. ARIN doesn't allow for growth in > initial assignments. No predictions, no HD-Ratio, and definitely no > nibble alignments. > > Current policy proposal hopes to fix a lot of that. > > >> In the near future I expect to be somewhere between a /24 > >> and a /28, which is an 8 to 12 bit shift right from my IPv4 /16 allocation > . > > Only if you can serve all those customers from that /16. You are > > then not comparing apples to apples. You are comparing a net with > > no growth space (IPv4) to one with growth space (IPv6). > > Not sure I get ya here. I am comparing apples to apples. ARIN gives me a > /16 of space. There are the same number of /16's in IPv4 as IPv6. > However, in IPv6, they will allocate a /24 at most to me, and I will > never exceed that. This shift of 8+ bits is the gains we get shifting > from IPv4 to IPv6. A IPv4 /16 supports 64000 potential customers. A IPv6 /32 supports 64000 potential customers. Either you have changed the customer estimates or changed the growth space allowances or were using NAT or .... You don't suddenly need 256 times the amount of space overnight all other things being equal. About the only thing I can think of is you need to advertise 256 routes and you are asking for extra blocks to get around poorly thought out filtering policies. A routing slot is a routing slot. It really doesn't matter if that slot has a /32 or a /40 or a /48 in it. They are equally expensive. If ISPs were being honest and matching IPv4 to IPv6 filtering the filters would be set a /40 not /32. By setting the filters to /32 you force the small ISP to ask for up to 256 times as much address space as they need with absolutely no benefits to anyone just to get a routing slot that won't be filtered. What's really needed is seperate the routing slot market from the address allocation market. Mark > Jack -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From nathan at atlasnetworks.us Sat Feb 5 20:42:52 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Sun, 6 Feb 2011 02:42:52 +0000 Subject: Random Port Blocking at Hotels (was: Re: quietly....) In-Reply-To: References: <20110205150005.40621.qmail@joyce.lan> <20110206011404.A19A99B625C@drugs.dv.isc.org> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B35D48A@ex-mb-1.corp.atlasnetworks.us> > Sure. Bet you ten bucks that no hotel in North America offers IPv6 this year > in the wifi they provide to customers. (Conference networks don't > count.) John - I happen to know with absolute certainty that the above statement is false. But I'd be happy to take your money! :-) Nathan From marka at isc.org Sat Feb 5 20:52:21 2011 From: marka at isc.org (Mark Andrews) Date: Sun, 06 Feb 2011 13:52:21 +1100 Subject: Random Port Blocking at Hotels (was: Re: quietly....) In-Reply-To: Your message of "05 Feb 2011 21:06:49 CDT." References: <20110205150005.40621.qmail@joyce.lan> <20110206011404.A19A99B625C@drugs.dv.isc.org> Message-ID: <20110206025221.F15C39B6DBD@drugs.dv.isc.org> In message , "John R. Levine" wr ites: > > I have told a hotel they need to install equipment that supports RA > > guard as I've checked out. This was a hotel that only offered IPv4. > > > > Hotels ask for feedback on their services. If you see a fault report > > it in writing. > > Sure. Bet you ten bucks that no hotel in North America offers IPv6 this > year in the wifi they provide to customers. (Conference networks don't > count.) The point I was trying to make is that hotel still needs to protect their customers from bad actions by other customers. Investing in RA guard gives their current customers a better experience *now* and is not a wasted expense as they will continue to need it when they get IPv6 connectivity. The alternative is to filter all IPv6 packets and remember to turn off the filter when they go to turn on IPv6. The RA guard can be configured to allow the hotels routers to work when IPv6 is finally enabled on them. Anyway it's all about educating people to be aware that they need to purchace stuff with IPv6 in mind even if they don't yet use IPv6. Anything bought now is likely to be used in a envionment with IPv6 enabled at some point. Mark > Regards, > John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies > ", > Please consider the environment before reading this e-mail. http://jl.ly -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jra at baylink.com Sat Feb 5 21:00:06 2011 From: jra at baylink.com (Jay Ashworth) Date: Sat, 5 Feb 2011 22:00:06 -0500 (EST) Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <72609B8A-05D2-4039-85C4-A0578B9E6911@cisco.com> Message-ID: <27232489.5209.1296961206938.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Fred Baker" > You mean, like drop a couple of trade towers and take out three class > five switches, causing communication outages throughout New England > and New Jersey, and affecting places as far away as Chicago? 3 class-5s? I thought it was a 5E and a 4E. I heard the 4E stayed online *past* 1400, talking to its fiber neighbors... Cheers -- jra From marka at isc.org Sat Feb 5 21:07:57 2011 From: marka at isc.org (Mark Andrews) Date: Sun, 06 Feb 2011 14:07:57 +1100 Subject: Random Port Blocking at Hotels (was: Re: quietly....) In-Reply-To: Your message of "Sat, 05 Feb 2011 20:34:19 CDT." References: <20110205150005.40621.qmail@joyce.lan> <20110206011404.A19A99B625C@drugs.dv.isc.org> Message-ID: <20110206030757.3DCCE9B6F68@drugs.dv.isc.org> In message , "Derek J. Balli ng" writes: > > On Feb 5, 2011, at 8:14 PM, Mark Andrews wrote: > > I have told a hotel they need to install equipment that supports RA > > guard as I've checked out. This was a hotel that only offered IPv4. > > Wow... Could that be any more of a waste of yours and their time? I put it writing so it could be sent to someone that could actually do something about it. I didn't expect the girl at the desk to do anything about it other than make sure the report got to the right department. I expressed in terms of this is a future problem and you need to be planning for it. Bitching about problems with hotels networks here doesn't get them fixed. Complaining, in writing, has a chance of getting the problem fixed. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From nanog at jima.tk Sat Feb 5 21:32:31 2011 From: nanog at jima.tk (Jima) Date: Sat, 05 Feb 2011 21:32:31 -0600 Subject: Random Port Blocking at Hotels (was: Re: quietly....) In-Reply-To: References: <20110205150005.40621.qmail@joyce.lan> <20110206011404.A19A99B625C@drugs.dv.isc.org> Message-ID: <4D4E164F.3000802@jima.tk> On 2/5/2011 8:06 PM, John R. Levine wrote: > Sure. Bet you ten bucks that no hotel in North America offers IPv6 this > year in the wifi they provide to customers. (Conference networks don't > count.) http://twitter.com/unquietwiki/status/449593712050176 springs to mind -- it was even *last* year. I think you owe Mark $10. Jima From owen at delong.com Sat Feb 5 21:32:46 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 5 Feb 2011 19:32:46 -0800 Subject: Random Port Blocking at Hotels (was: Re: quietly....) In-Reply-To: <20110206011404.A19A99B625C@drugs.dv.isc.org> References: <20110205150005.40621.qmail@joyce.lan> <20110206011404.A19A99B625C@drugs.dv.isc.org> Message-ID: <150885AA-18E1-4403-A51D-F5B41D39D8D1@delong.com> On Feb 5, 2011, at 5:14 PM, Mark Andrews wrote: > > In message <20110205150005.40621.qmail at joyce.lan>, John Levine writes: >>> and saying "by God, this Owen character is right, we're in breach of >>> contract and his definition of the purity of Internet ports has so >>> stunned us with its symmetry and loveliness that we shall bow down and >>> sin no more! Thank you Mr. DeLong from making the blind see again!" >> >> More likely "uh, oh, we've got a loony one here. Maybe if I give him >> his ten bucks back, he'll go away." >> >> R's, >> John > > I have told a hotel they need to install equipment that supports RA > guard as I've checked out. This was a hotel that only offered IPv4. > > Hotels ask for feedback on their services. If you see a fault report > it in writing. > Rest assured, I do that as well. I also end up usually spending a fair amount of time on the phone with their contracted support desk which is usually staffed by people that can barely spell IP and get confused if you suffix it with v4 or v6. When I inquired about IPv4 and IPv6 support, I had one literally tell me "We don't support either of those. Just ordinary Internet Protocol." Owen From owen at delong.com Sat Feb 5 21:34:19 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 5 Feb 2011 19:34:19 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <4D4DF75E.1040109@brightok.net> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org> <4D4C0D25.70408@brightok.net> <20110204231134.3AA029B2B39@drugs.dv.isc.org> <4D4C8AF8.1030703@brightok.net> <20110205004517.371F99B3B3C@drugs.dv.isc.org> <4D4CA1B1.5060002@brightok.net> <20110205124710.059259B4E31@drugs.dv.isc.org> <4D4D5FFC.6020905@brightok.net> <20110206010145.9DCD99B60B9@drugs.dv.isc.org> <4D4DF75E.1040109@brightok.net> Message-ID: On Feb 5, 2011, at 5:20 PM, Jack Bates wrote: > On 2/5/2011 7:01 PM, Mark Andrews wrote: >> And did you change the amount of growth space you allowed for each pop? >> Were you already constrained in your IPv4 growth space and just restored >> your desired growth margins? >> > Growth rate has nothing to do with it. ARIN doesn't allow for growth in initial assignments. No predictions, no HD-Ratio, and definitely no nibble alignments. > Yet. > Current policy proposal hopes to fix a lot of that. > Yes... 2011-3 for those who are interested in knowing more. Owen From owen at delong.com Sat Feb 5 21:44:53 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 5 Feb 2011 19:44:53 -0800 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B35D455@ex-mb-1.corp.atlasnetworks.us> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org> <4D4C0D25.70408@brightok.net> <20110204231134.3AA029B2B39@drugs.dv.isc.org> <4D4C8AF8.1030703@brightok.net> <20110205004517.371F99B3B3C@drugs.dv.isc.org> <4D4CA1B1.5060002@brightok.net> <20110205124710.059259B4E31@drugs.dv.isc.org> <4D4D5FFC.6020905@brightok.net> <8C26A4FDAE599041A13EB499117D3C286B35D455@ex-mb-1.corp.atlasnetworks.us> Message-ID: <6252EF3B-AF60-42A4-9E95-1130ACA580EF@delong.com> On Feb 5, 2011, at 6:38 PM, Nathan Eisenberg wrote: >> Still, that is a considerable number of bits we'll have left when the dust >> settles and the RIR allocation rate drastically slows. > > Like it did for IPv4? ;) > > -Nathan > It long since would have if ISPs didn't have to come back annually (or more frequently in many cases) to get additional addresses to support their growth. In IPv6, we should be looking to do 5 or 10 year allocations. We can afford to be fairly speculative in our allocations in order to preserve greater aggregation. In iPv4, the registries were constantly trying to balance shortage of addresses with shortage of routing table slots. In IPv6, we can focus on rational allocation for administrative purposes with some consideration given to routing table slots. It makes for a significantly different set of tradeoffs and optimizations that should be used in address policy. That is why I wrote 2011-3 and why we passed 2010-8. Owen From jbates at brightok.net Sat Feb 5 21:58:21 2011 From: jbates at brightok.net (Jack Bates) Date: Sat, 05 Feb 2011 21:58:21 -0600 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <20110206024051.D60349B6D50@drugs.dv.isc.org> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org> <4D4C0D25.70408@brightok.net> <20110204231134.3AA029B2B39@drugs.dv.isc.org> <4D4C8AF8.1030703@brightok.net> <20110205004517.371F99B3B3C@drugs.dv.isc.org> <4D4CA1B1.5060002@brightok.net> <20110205124710.059259B4E31@drugs.dv.isc.org> <4D4D5FFC.6020905@brightok.net> <20110206010145.9DCD99B60B9@drugs.dv.isc.org> <4D4DF75E.1040109@brightok.net> <20110206024051.D60349B6D50@drugs.dv.isc.org> Message-ID: <4D4E1C5D.20407@brightok.net> On 2/5/2011 8:40 PM, Mark Andrews wrote: > A IPv4 /16 supports 64000 potential customers. A IPv6 /32 supports > 64000 potential customers. Either you have changed the customer > estimates or changed the growth space allowances or were using NAT > or .... > > You don't suddenly need 256 times the amount of space overnight all > other things being equal. About the only thing I can think of is > you need to advertise 256 routes and you are asking for extra blocks > to get around poorly thought out filtering policies. > What filtering policies? My allocation was based on customers per terminating router, 1 route per terminating router. A /32 was nowhere near enough. The reason a /16 works today is because I have a routing table that looks like swiss cheese and a 95%+ utilization rate. 9 /40 (equiv of 9 /24 IPv4 DHCP pools for residential DSL) networks don't fall on a bit boundary. Nibble would make things even easier, but to say I have to run multiple routes to a pop and squeeze things in as tight as possible is insane. Justifications DO allow for some amount of aggregation in numbering plans. > If ISPs were being honest and matching IPv4 to IPv6 filtering the > filters would be set a /40 not /32. By setting the filters to /32 > you force the small ISP to ask for up to 256 times as much address > space as they need with absolutely no benefits to anyone just to > get a routing slot that won't be filtered. > Actually, many router policies, as discussed previously on the list, support /48. Routing policies don't force the /32, and a current proposal to ARIN even supports a small ISP getting a /36, hopefully at a lower cost. > What's really needed is seperate the routing slot market from the > address allocation market. > I agree that inter-AS routing needs to change, though that still has nothing to do with address allocation itself. Sizes of allocations were chosen to allow for growth. The ISPs don't get near the wiggle room that corporations and end users get in address assignment currently. When analyzing exhaustion rate of IPv6, like IPv4, you have to view it at the RIR allocation level. In this case, across the board, we will see a minimum of an 8 bit shift in allocations, and often 12-16 bits (what's to the right of the allocation bits doesn't matter when we consider exhaustion rates, so long as what's to the right is appropriately utilized and justified by community standards before another request is handled by the RIR). Jack From jbates at brightok.net Sat Feb 5 22:10:11 2011 From: jbates at brightok.net (Jack Bates) Date: Sat, 05 Feb 2011 22:10:11 -0600 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <6252EF3B-AF60-42A4-9E95-1130ACA580EF@delong.com> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org> <4D4C0D25.70408@brightok.net> <20110204231134.3AA029B2B39@drugs.dv.isc.org> <4D4C8AF8.1030703@brightok.net> <20110205004517.371F99B3B3C@drugs.dv.isc.org> <4D4CA1B1.5060002@brightok.net> <20110205124710.059259B4E31@drugs.dv.isc.org> <4D4D5FFC.6020905@brightok.net> <8C26A4FDAE599041A13EB499117D3C286B35D455@ex-mb-1.corp.atlasnetworks.us> <6252EF3B-AF60-42A4-9E95-1130ACA580EF@delong.com> Message-ID: <4D4E1F23.2050806@brightok.net> On 2/5/2011 9:44 PM, Owen DeLong wrote: > In IPv6, we should be looking to do 5 or 10 year allocations. We can > afford to be fairly speculative in > our allocations in order to preserve greater aggregation. > And even if networks were only getting an 8 bit slide, that's 256 trips back to the RIR to get to their current allocations sizes (over 1000 years if they had to return once every 5 years). However, 12-16 bit slides seem more common (perhaps John knows the exact slide ratio, though I suspect many ISPs haven't really nailed down what they need in v6 yet) and that can exceed 10 year allocation rates for some ISPs. Jack From paul at telcodata.us Sat Feb 5 22:15:07 2011 From: paul at telcodata.us (Paul Timmins) Date: Sat, 05 Feb 2011 23:15:07 -0500 Subject: Random Port Blocking at Hotels (was: Re: quietly....) In-Reply-To: References: <20110205150005.40621.qmail@joyce.lan> <20110206011404.A19A99B625C@drugs.dv.isc.org> Message-ID: <4D4E204B.1080409@telcodata.us> John R. Levine wrote: >> I have told a hotel they need to install equipment that supports RA >> guard as I've checked out. This was a hotel that only offered IPv4. >> >> Hotels ask for feedback on their services. If you see a fault report >> it in writing. > > Sure. Bet you ten bucks that no hotel in North America offers IPv6 > this year in the wifi they provide to customers. (Conference networks > don't count.) I know a hospital in Metro Detroit that was offering it on their patient and guest WiFi in 2009. Of course, neither they, nor the individual running the rogue IPv6 router knew that, but as a person running an IPv6 enabled OS, it was really screwing up access to my dual stacked hosts to be getting RAs on their wireless with no prefixes on them. I had to filter out RAs in iptables in order to effectively use their WiFi, which was a mess to begin with. The guilty party should remain nameless for google's sake, but if you're a netadmin in a largeish, three location hospital entirely in the detroit suburbs, say the largest inpatient hospital in the country, please make sure you either filter IPv6 or offer it yourself so you'll at least know if it's broken. As much as I hear people whining these days about how to handle rogue RAs, they don't seem to realize that this is ALREADY an issue on their network, even if they haven't, or won't adopt IPv6, and so this is a NOW problem either way and needs to be addressed. It's not a barrier to IPv6 adoption, it's a security threat right this minute. Either block protocol 0x86dd using a mac address prefix list, or traffic with a destination of 33:33:00:00:00:01 from all untrusted ports and you can now safely enable IPv6, OR just upgrade your gear, and while you're at it, you can now safely enable IPv6 anyway. -Paul From fred at cisco.com Sat Feb 5 22:29:44 2011 From: fred at cisco.com (Fred Baker) Date: Sat, 5 Feb 2011 20:29:44 -0800 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <4D4E0361.3060505@dcrocker.net> References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> <96503CEA-C922-47A6-9691-FCF157DF15D5@internode.com.au> <10A940BA-6D90-4663-B942-5FFF2CB49D7A@internode.com.au> <4D4BAD13.9090301@gmail.com> <88BC6885D33A9D42A1CCB45E8749525E013CBC58@pigeon.sandiego.nextlevelinternet.com> <72609B8A-05D2-4039-85C4-A0578B9E6911@cisco.com> <4D4E0361.3060505@dcrocker.net> Message-ID: <9FCDBED3-FA1E-47F2-8939-A083B1CA0E2B@cisco.com> On Feb 5, 2011, at 6:11 PM, Dave CROCKER wrote: > > > On 2/5/2011 6:43 AM, Fred Baker wrote: >> On Feb 4, 2011, at 9:49 PM, Hayden Katzenellenbogen wrote: >>> Not sure if it has been said already but wasn't one of the key point for >>> the creation of the internet to create and infrastructure that would >>> survive in the case of all out war and massive destruction. (strategic >>> nuclear strikes) >> >> Urban legend, although widely believed. Someone probably made the observation. > > > Maybe not quite an UL... > > > > On the average, The Rand Corp is extremely careful about what it publishes, yet here it is, repeating the claim. But Len Kleinrock adamantly disputes it. > Back in the '70s, I always heard "survive hostile battlefield conditions" and never heard anyone talk about comms survival of a nuclear event, but I wasn't in any interesting conversations, such as in front of funding agencies... To survive an EMP, electronics needs some fancy circuitry. I've never worked with a bit of equipment that had it. It would therefore have to have been through path redundancy. From matthew at matthew.at Sat Feb 5 22:30:39 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Sat, 05 Feb 2011 20:30:39 -0800 Subject: Random Port Blocking at Hotels (was: Re: quietly....) In-Reply-To: <4D4E204B.1080409@telcodata.us> References: <20110205150005.40621.qmail@joyce.lan> <20110206011404.A19A99B625C@drugs.dv.isc.org> <4D4E204B.1080409@telcodata.us> Message-ID: <4D4E23EF.3050303@matthew.at> On 2/5/2011 8:15 PM, Paul Timmins wrote: > OR just upgrade your gear, and while you're at it, you can now safely > enable IPv6 anyway. Well, enable IPv6. Safely? I don't see how upgrading your gear magically makes the various security threats -- including the current topic of rogue RAs -- go away. Matthew Kaufman From bensons at queuefull.net Sat Feb 5 22:31:39 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Sat, 5 Feb 2011 22:31:39 -0600 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <3867203A-05E5-478B-B467-ABA371027743@pch.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com.> <3867203A-05E5-478B-B467-ABA371027743@pch.net> Message-ID: <392168FC-210F-4E52-98B8-49F4BE84DBCD@queuefull.net> On Feb 5, 2011, at 1:01 PM, Bill Woodcock wrote: > On Feb 5, 2011, at 10:27 AM, bmanning at vacation.karoshi.com wrote: >> If I justified an allocation 20 years ago, under the then current policy, it's presumptuous to presume the power of expropriation. > > No one presumes it, and a lot of us are in the same boat as you, some of the addresses we're using predating the RIR system. > > That said, there will always be people who will turn up on the mailing list, participating in the public policy process, who are not in that boat, and whose interests differ significantly, and who will speak in favor of those interests. > > And the consensus of the public, the people who participate in the public policy process, is what decides The ARIN community decides ARIN policy. That policy doesn't inherently reflect "community standards" in the broader sense, or inherently align with the law for that matter. If the ARIN community were to instruct ARIN to operate in an illegal capacity, for instance, the fact that a "community" reached "consensus" on the matter would be a ridiculous defense. Cheers, -Benson From paul at telcodata.us Sat Feb 5 22:32:26 2011 From: paul at telcodata.us (Paul Timmins) Date: Sat, 05 Feb 2011 23:32:26 -0500 Subject: Random Port Blocking at Hotels In-Reply-To: <4D4E23EF.3050303@matthew.at> References: <20110205150005.40621.qmail@joyce.lan> <20110206011404.A19A99B625C@drugs.dv.isc.org> <4D4E204B.1080409@telcodata.us> <4D4E23EF.3050303@matthew.at> Message-ID: <4D4E245A.8090404@telcodata.us> Matthew Kaufman wrote: > On 2/5/2011 8:15 PM, Paul Timmins wrote: >> OR just upgrade your gear, and while you're at it, you can now safely >> enable IPv6 anyway. > > Well, enable IPv6. Safely? I don't see how upgrading your gear > magically makes the various security threats -- including the current > topic of rogue RAs -- go away. > If you upgrade it to something that can filter rogue RA, like I was showing in the previous two examples, that would address the security issues. -Paul From fred at cisco.com Sat Feb 5 22:34:10 2011 From: fred at cisco.com (Fred Baker) Date: Sat, 5 Feb 2011 20:34:10 -0800 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <27232489.5209.1296961206938.JavaMail.root@benjamin.baylink.com> References: <27232489.5209.1296961206938.JavaMail.root@benjamin.baylink.com> Message-ID: <7C74DD14-875F-4B36-9E34-83F34DE2D41C@cisco.com> On Feb 5, 2011, at 7:00 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Fred Baker" > >> You mean, like drop a couple of trade towers and take out three class >> five switches, causing communication outages throughout New England >> and New Jersey, and affecting places as far away as Chicago? > > 3 class-5s? > > I thought it was a 5E and a 4E. I may have it wrong. My source is a talk given along with renesys-030502-NRC-911.pdf to a NAE committee writing http://www.nap.edu/openbook.php?isbn=0309087023. The author told us that there were two class five switches in one of the towers and one in a neighboring building; the neighboring building was damaged by debris from the tower. > I heard the 4E stayed online *past* 1400, talking to its fiber neighbors... > > Cheers > -- jra > From dredd at megacity.org Sat Feb 5 22:34:36 2011 From: dredd at megacity.org (Derek J. Balling) Date: Sat, 5 Feb 2011 23:34:36 -0500 Subject: Random Port Blocking at Hotels (was: Re: quietly....) In-Reply-To: <4D4E204B.1080409@telcodata.us> References: <20110205150005.40621.qmail@joyce.lan> <20110206011404.A19A99B625C@drugs.dv.isc.org> <4D4E204B.1080409@telcodata.us> Message-ID: <9ADCAE81-369D-4C36-BA13-208F32824EA9@megacity.org> On Feb 5, 2011, at 11:15 PM, Paul Timmins wrote: > I know a hospital in Metro Detroit that was offering it on their patient and guest WiFi in 2009. Of course, neither they, nor the individual running the rogue IPv6 router knew that, but as a person running an IPv6 enabled OS, it was really screwing up access to my dual stacked hosts to be getting RAs on their wireless with no prefixes on them. I had to filter out RAs in iptables in order to effectively use their WiFi, which was a mess to begin with. Wouldn't it have been awesome if, y'know, you hadn't had to worry about the RAs at all, but had just connected your single client machine, and gotten your simple gateway address from the DHCP server along with all the rest of your network configuration settings, just like has worked pretty darned well for a number of years? Oh, right... IPv6, whose mascot should be the camel[1]. Cheers, D [1] http://bit.ly/enLk3c From owen at delong.com Sat Feb 5 22:42:08 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 5 Feb 2011 20:42:08 -0800 Subject: Random Port Blocking at Hotels (was: Re: quietly....) In-Reply-To: <4D4E23EF.3050303@matthew.at> References: <20110205150005.40621.qmail@joyce.lan> <20110206011404.A19A99B625C@drugs.dv.isc.org> <4D4E204B.1080409@telcodata.us> <4D4E23EF.3050303@matthew.at> Message-ID: On Feb 5, 2011, at 8:30 PM, Matthew Kaufman wrote: > On 2/5/2011 8:15 PM, Paul Timmins wrote: >> OR just upgrade your gear, and while you're at it, you can now safely enable IPv6 anyway. > > Well, enable IPv6. Safely? I don't see how upgrading your gear magically makes the various security threats -- including the current topic of rogue RAs -- go away. > > Matthew Kaufman Most rogue RAs are problematic on networks that don't have legitimate RAs to override them. Yes, someone can do a malicious RA, but, the current problem is mostly people doing accidental RAs thanks to Micr0$0ft's convenient "Click here to screw your neighbors" buttons. Owen From paul at telcodata.us Sat Feb 5 22:46:02 2011 From: paul at telcodata.us (Paul Timmins) Date: Sat, 05 Feb 2011 23:46:02 -0500 Subject: Random Port Blocking at Hotels (was: Re: quietly....) In-Reply-To: <9ADCAE81-369D-4C36-BA13-208F32824EA9@megacity.org> References: <20110205150005.40621.qmail@joyce.lan> <20110206011404.A19A99B625C@drugs.dv.isc.org> <4D4E204B.1080409@telcodata.us> <9ADCAE81-369D-4C36-BA13-208F32824EA9@megacity.org> Message-ID: <4D4E278A.6040902@telcodata.us> Derek J. Balling wrote: > On Feb 5, 2011, at 11:15 PM, Paul Timmins wrote: > >> I know a hospital in Metro Detroit that was offering it on their patient and guest WiFi in 2009. Of course, neither they, nor the individual running the rogue IPv6 router knew that, but as a person running an IPv6 enabled OS, it was really screwing up access to my dual stacked hosts to be getting RAs on their wireless with no prefixes on them. I had to filter out RAs in iptables in order to effectively use their WiFi, which was a mess to begin with. >> > > Wouldn't it have been awesome if, y'know, you hadn't had to worry about the RAs at all, but had just connected your single client machine, and gotten your simple gateway address from the DHCP server along with all the rest of your network configuration settings, just like has worked pretty darned well for a number of years? > Because rogue DHCP servers have never been a problem. Switches supported keeping those secure since before DHCP was even commonly used, right? -Paul From jcurran at arin.net Sat Feb 5 22:48:30 2011 From: jcurran at arin.net (John Curran) Date: Sun, 6 Feb 2011 04:48:30 +0000 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <392168FC-210F-4E52-98B8-49F4BE84DBCD@queuefull.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <392168FC-210F-4E52-98B8-49F4BE84DBCD@queuefull.net> Message-ID: On Feb 5, 2011, at 11:31 PM, Benson Schliesser wrote: > ... > The ARIN community decides ARIN policy. That policy doesn't inherently reflect "community standards" in the broader sense, or inherently align with the law for that matter. If the ARIN community were to instruct ARIN to operate in an illegal capacity, for instance, the fact that a "community" reached "consensus" on the matter would be a ridiculous defense. Benson - You are correct that consensus doesn't assure legality; hence all draft policies receive a specific staff and legal review during the development process. /John John Curran President and CEO ARIN From owen at delong.com Sat Feb 5 22:44:39 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 5 Feb 2011 20:44:39 -0800 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <392168FC-210F-4E52-98B8-49F4BE84DBCD@queuefull.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com.> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <392168FC-210F-4E52-98B8-49F4BE84DBCD@queuefull.net> Message-ID: On Feb 5, 2011, at 8:31 PM, Benson Schliesser wrote: > > On Feb 5, 2011, at 1:01 PM, Bill Woodcock wrote: >> On Feb 5, 2011, at 10:27 AM, bmanning at vacation.karoshi.com wrote: >>> If I justified an allocation 20 years ago, under the then current policy, it's presumptuous to presume the power of expropriation. >> >> No one presumes it, and a lot of us are in the same boat as you, some of the addresses we're using predating the RIR system. >> >> That said, there will always be people who will turn up on the mailing list, participating in the public policy process, who are not in that boat, and whose interests differ significantly, and who will speak in favor of those interests. >> >> And the consensus of the public, the people who participate in the public policy process, is what decides > > The ARIN community decides ARIN policy. That policy doesn't inherently reflect "community standards" in the broader sense, or inherently align with the law for that matter. If the ARIN community were to instruct ARIN to operate in an illegal capacity, for instance, the fact that a "community" reached "consensus" on the matter would be a ridiculous defense. > > Cheers, > -Benson > We have a lawyer that does an excellent job of advising us on legal concerns in our policy proposals. That is part of the policy process. As such, yes, they do somewhat inherently align with the law. As to reflecting community standards, I'm not sure what better measure of "community standards" one could propose beyond a bottom-up open consensus driven policy process such as what we have today. If you know a better way to make policy reflect community standards, there is the ACSP and I'm sure that the PDP committee would be very happy to get your input. Owen From gbonser at seven.com Sat Feb 5 22:51:56 2011 From: gbonser at seven.com (George Bonser) Date: Sat, 5 Feb 2011 20:51:56 -0800 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <9FCDBED3-FA1E-47F2-8939-A083B1CA0E2B@cisco.com> References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> <96503CEA-C922-47A6-9691-FCF157DF15D5@internode.com.au> <10A940BA-6D90-4663-B942-5FFF2CB49D7A@internode.com.au> <4D4BAD13.9090301@gmail.com> <88BC6885D33A9D42A1CCB45E8749525E013CBC58@pigeon.sandiego.nextlevelinternet.com><72609B8A-05D2-4039-85C4-A0578B9E6911@cisco.com><4D4E0361.3060505@dcrocker.net> <9FCDBED3-FA1E-47F2-8939-A083B1CA0E2B@cisco.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC138A5@RWC-EX1.corp.seven.com> > > > Back in the '70s, I always heard "survive hostile battlefield > conditions" and never heard anyone talk about comms survival of a > nuclear event, but I wasn't in any interesting conversations, such as > in front of funding agencies... > > To survive an EMP, electronics needs some fancy circuitry. I've never > worked with a bit of equipment that had it. It would therefore have to > have been through path redundancy. It was designed to be robust but it wasn't designed to survive nuclear war. There WERE some networks that were designed to survive, though, so maybe some have confused them. I think what I hear seems to confuse MILNET with MILSTAR where MILNET was the military portion of the Internet (what has eventually evolved into NIPRNet) and MILSTAR which is a satellite network designed to be nuclear survivable. When it absolutely positively has to get there. From bmanning at vacation.karoshi.com Sat Feb 5 23:00:15 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 6 Feb 2011 05:00:15 +0000 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <9FCDBED3-FA1E-47F2-8939-A083B1CA0E2B@cisco.com> References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> <96503CEA-C922-47A6-9691-FCF157DF15D5@internode.com.au> <10A940BA-6D90-4663-B942-5FFF2CB49D7A@internode.com.au> <4D4BAD13.9090301@gmail.com> <88BC6885D33A9D42A1CCB45E8749525E013CBC58@pigeon.sandiego.nextlevelinternet.com> <72609B8A-05D2-4039-85C4-A0578B9E6911@cisco.com> <4D4E0361.3060505@dcrocker.net> <9FCDBED3-FA1E-47F2-8939-A083B1CA0E2B@cisco.com> Message-ID: <20110206050015.GA2060@vacation.karoshi.com.> On Sat, Feb 05, 2011 at 08:29:44PM -0800, Fred Baker wrote: > > On Feb 5, 2011, at 6:11 PM, Dave CROCKER wrote: > > > > > > > On 2/5/2011 6:43 AM, Fred Baker wrote: > >> On Feb 4, 2011, at 9:49 PM, Hayden Katzenellenbogen wrote: > >>> Not sure if it has been said already but wasn't one of the key point for > >>> the creation of the internet to create and infrastructure that would > >>> survive in the case of all out war and massive destruction. (strategic > >>> nuclear strikes) > >> > >> Urban legend, although widely believed. Someone probably made the observation. > > > > > > Maybe not quite an UL... > > > > > > > > On the average, The Rand Corp is extremely careful about what it publishes, yet here it is, repeating the claim. > > But Len Kleinrock adamantly disputes it. > > > Back in the '70s, I always heard "survive hostile battlefield conditions" and never heard anyone talk about comms survival of a nuclear event, but I wasn't in any interesting conversations, such as in front of funding agencies... > > To survive an EMP, electronics needs some fancy circuitry. I've never worked with a bit of equipment that had it. It would therefore have to have been through path redundancy. i suspect that the idea of survivalbility has everything to do w/ packet oriented communications vs circuit switching. packets work best w/ path redundancy... :) i've worked w/ EMP resistnt kit. its not something a commercial offering would ever have. --bill From joly at punkcast.com Sat Feb 5 23:00:33 2011 From: joly at punkcast.com (Joly MacFie) Date: Sun, 6 Feb 2011 00:00:33 -0500 Subject: US Warships jamming Lebanon Internet Message-ID: Lebanon's Telecom minister is claiming that US Navy radar is blocking the country's Internet.. http://www.naharnet.com/domino/tn/NewsDesk.nsf/0/93A95CA1A4E42178C225782E007371AF "The problem, however, is due to a coordination error related to waves," > Nahhas told OTV, adding that an investigation was underway to find out > whether this act is "intentional or not." also at http://www.naharnet.com/domino/tn/NewsDesk.nsf/Lebanon/EFCEF203B3C315A5C225782E0020C75F -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org --------------------------------------------------------------- From joelja at bogus.com Sat Feb 5 23:19:33 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 05 Feb 2011 21:19:33 -0800 Subject: US Warships jamming Lebanon Internet In-Reply-To: References: Message-ID: <4D4E2F65.1000704@bogus.com> On 2/5/11 9:00 PM, Joly MacFie wrote: > Lebanon's Telecom minister is claiming that US Navy radar is blocking the > country's Internet.. > > http://www.naharnet.com/domino/tn/NewsDesk.nsf/0/93A95CA1A4E42178C225782E007371AF Those repeaterless submarine optical systems are really impacted by terrestrial rf transmission... > "The problem, however, is due to a coordination error related to waves," >> Nahhas told OTV, adding that an investigation was underway to find out >> whether this act is "intentional or not." > > > also at > http://www.naharnet.com/domino/tn/NewsDesk.nsf/Lebanon/EFCEF203B3C315A5C225782E0020C75F > From bensons at queuefull.net Sat Feb 5 23:24:57 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Sat, 5 Feb 2011 23:24:57 -0600 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com.> Message-ID: <98C34E6A-7023-4141-BBC6-9A800CB2CB6B@queuefull.net> On Feb 5, 2011, at 2:25 PM, Owen DeLong wrote: > The fact that a very large number of network operators use the data > contained in the RIR system in a cooperative manner is convenient > and makes the internet substantially more useful than I can imagine > it would be under alternative scenarios. However, that does not mean > that the RIRs are granting any sort of license, right to use, or ownership. > Nor does it mean that terminating a registration constitutes taking away > such a grant that was never given. This is a pretty tenuous position. If the Whois database isn't specifying the proper association between an organization and an address block, what is it for? I think you're suggesting that the definition of "proper" in this case is no more than ARIN's non-binding recommendation. If that's the case then ARIN has no "authority" as the address registry. I think ARIN's own statements, relationship with NRO and IANA, etc, all contradict this. On the other hand, if ARIN intends the Whois to reflect the proper association between organizations and address blocks, then it has some responsibility for the accuracy of that data. While not a perfect comparison, it would be somewhat like a financial services company hired to maintain shareholder ownership records of a public company - negligence in maintaining accurate records can result in criminal consequences. In fact, in my example, if the company decided to reallocate one group of shares to new owners they'd find themselves in a deep pile of trouble - we have laws that govern property rights, define theft and fraud, etc, all of which takes precedence over company policy. It would be disingenuous to offer a database of information, recommend it be used by the public, support its use as an authoritative source, and then deny any responsibility for the contents. I don't think your position on this particular topic reflects ARIN in reality. Cheers, -Benson From bensons at queuefull.net Sat Feb 5 23:25:16 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Sat, 5 Feb 2011 23:25:16 -0600 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <392168FC-210F-4E52-98B8-49F4BE84DBCD@queuefull.net> Message-ID: On Feb 5, 2011, at 10:48 PM, John Curran wrote: > You are correct that consensus doesn't assure legality; hence > all draft policies receive a specific staff and legal review > during the development process. Thanks, John. I'm aware of the legal review, as well as the AC and board "gateways" to policy adoption. I don't have any recommendation for improving that process, per se - just a healthy dose of skepticism that it will always result in alignment with the law, especially given that the legal authority of ARIN isn't clearly defined. On Feb 5, 2011, at 10:44 PM, Owen DeLong wrote: > As to reflecting community standards, I'm not sure what better measure of "community standards" > one could propose beyond a bottom-up open consensus driven policy process such as what > we have today. Owen, my point is that the ARIN community does not necessarily reflect the community at large. Just like the common standards within the mafia community aren't necessarily aligned with the broader standards of civil society. If ARIN is appointed in an official capacity (i.e. granted such authority by the government, or by popular vote etc) to determine specific community standards then we don't have to worry. Otherwise, ARIN has to work carefully to ensure that it doesn't go awry. In that sense, the relative smallness of the ARIN community and ARIN's organizational momentum (natural to any self-preserving organization) should be of concern. Cheers, -Benson From jcurran at arin.net Sat Feb 5 23:33:49 2011 From: jcurran at arin.net (John Curran) Date: Sun, 6 Feb 2011 05:33:49 +0000 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <20110206014014.GG22325@vacation.karoshi.com> References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <20110205193328.GC22325@vacation.karoshi.com> <08F8827D-D8C3-4922-AC39-6C71ADBE8BDB@corp.arin.net> <20110206014014.GG22325@vacation.karoshi.com> Message-ID: On Feb 5, 2011, at 8:40 PM, bmanning at vacation.karoshi.com wrote: > On Sat, Feb 05, 2011 at 09:12:53PM +0000, John Curran wrote: >> RFC 2050 is the document which provides the registry system framework. Jon Postel is an author of same, as well as a founder of ARIN. > > yup.. i was there when it was written. Excellent; it could prove helpful in clarifying things. > It does not talk to address space allocated to entities from the IANA or other > registries prior to the RIRs existance. Is it your belief that Jon did not intend RFC 2050 to apply to the existing allocations maintained by the three regional registries in existence at the time (InterNIC, RIPE NCC and APNIC)? I imagine that is plausible, but it would run contrary to the language which states that assignments should be viewed as loans and "to this end, ISPs should have documented justification available for each assignment. The regional registry may, at any time, ask for this information. If the information is not available, future allocations may be impacted. In extreme cases, existing loans may be impacted." I'm having trouble understanding how *existing* allocations could be impacted if existing registry allocations were not covered. Or are you suggesting that RFC 2050 applies, but there is a select set of ISP allocations that were outside of InterNIC, APNIC, and RIPE NCC to which special handling is applied? Further, RFC 2050 states "The transfer of IP addresses from one party to another must be approved by the regional registries. The party trying to obtain the IP address must meet the same criteria as if they were requesting an IP address directly from the IR." Even one were to hypothecate some type of address space that could be the *source* of a transfer due to a mystical handling status, how could any party be the *recipient* of such without demonstrating need to one of the regional registries per the second referenced text? Is this also a case where it was meant to exclude some special parties but just did not get stated in the actual RFC 2050 text? Thanks! /John John Curran President and CEO ARIN From owen at delong.com Sat Feb 5 23:31:49 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 5 Feb 2011 21:31:49 -0800 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <392168FC-210F-4E52-98B8-49F4BE84DBCD@queuefull.net> Message-ID: On Feb 5, 2011, at 9:25 PM, Benson Schliesser wrote: > > On Feb 5, 2011, at 10:48 PM, John Curran wrote: >> You are correct that consensus doesn't assure legality; hence >> all draft policies receive a specific staff and legal review >> during the development process. > > Thanks, John. I'm aware of the legal review, as well as the AC and board "gateways" to policy adoption. I don't have any recommendation for improving that process, per se - just a healthy dose of skepticism that it will always result in alignment with the law, especially given that the legal authority of ARIN isn't clearly defined. > > > On Feb 5, 2011, at 10:44 PM, Owen DeLong wrote: >> As to reflecting community standards, I'm not sure what better measure of "community standards" >> one could propose beyond a bottom-up open consensus driven policy process such as what >> we have today. > > Owen, my point is that the ARIN community does not necessarily reflect the community at large. Just like the common standards within the mafia community aren't necessarily aligned with the broader standards of civil society. > It reflects those who care to participate. The process is open to anyone in the community that want to. That's as close as any body ever comes to such a thing. Just like you don't get better politicians unless you vote, you can't get better ARIN policy unless you participate. > If ARIN is appointed in an official capacity (i.e. granted such authority by the government, or by popular vote etc) to determine specific community standards then we don't have to worry. Otherwise, ARIN has to work carefully to ensure that it doesn't go awry. In that sense, the relative smallness of the ARIN community and ARIN's organizational momentum (natural to any self-preserving organization) should be of concern. > An interesting perspective. Owen From nenolod at systeminplace.net Sat Feb 5 23:39:31 2011 From: nenolod at systeminplace.net (William Pitcock) Date: Sat, 5 Feb 2011 23:39:31 -0600 Subject: nlayer contact Message-ID: <20110205233931.60f021c4@petrie> Hi, Could an nLayer network engineer contact me offlist regarding a service or core router at I'm guessing One Wilshire that is having serious problems? Thanks. William From owen at delong.com Sat Feb 5 23:42:38 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 5 Feb 2011 21:42:38 -0800 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <98C34E6A-7023-4141-BBC6-9A800CB2CB6B@queuefull.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com.> <98C34E6A-7023-4141-BBC6-9A800CB2CB6B@queuefull.net> Message-ID: <51B48028-7B1A-498C-8A7F-BE090421BBBA@delong.com> On Feb 5, 2011, at 9:24 PM, Benson Schliesser wrote: > > On Feb 5, 2011, at 2:25 PM, Owen DeLong wrote: > >> The fact that a very large number of network operators use the data >> contained in the RIR system in a cooperative manner is convenient >> and makes the internet substantially more useful than I can imagine >> it would be under alternative scenarios. However, that does not mean >> that the RIRs are granting any sort of license, right to use, or ownership. >> Nor does it mean that terminating a registration constitutes taking away >> such a grant that was never given. > I need to be very clear here... The opinions I am expressing are mine and mine alone. I don't know if ANYONE at ARIN shares them with me. > This is a pretty tenuous position. If the Whois database isn't specifying the proper association between an organization and an address block, what is it for? I think you're suggesting that the definition of "proper" in this case is no more than ARIN's non-binding recommendation. If that's the case then ARIN has no "authority" as the address registry. I think ARIN's own statements, relationship with NRO and IANA, etc, all contradict this. > What I am saying is that ARIN and the Whois database ARIN maintains is authoritative only so far as those using the data wish to consider it authoritative. It does not command any particular network operator to treat any set of numbers in any particular way. ARIN is the registry recognized as authoritative in its geographic region by NRO and IANA. However, one can maintain a database of integers that is not sanction by NRO and IANA and if people choose to put your numbers into their routers instead of ARIN or other NRO or IANA based registry numbers, who is to stop them or you? The ability of ARIN to influence the routing table is strictly limited to the fact that ISPs choose to consider ARIN authoritative. That choice is entirely voluntary on the part of the ISPs. > On the other hand, if ARIN intends the Whois to reflect the proper association between organizations and address blocks, then it has some responsibility for the accuracy of that data. While not a perfect comparison, it would be somewhat like a financial services company hired to maintain shareholder ownership records of a public company - negligence in maintaining accurate records can result in criminal consequences. In fact, in my example, if the company decided to reallocate one group of shares to new owners they'd find themselves in a deep pile of trouble - we have laws that govern property rights, define theft and fraud, etc, all of which takes precedence over company policy. > I think ARIN has tremendous responsibility for the accuracy of that data. However, the definition of what is accurate is governed only by ARIN policy and the contracts ARIN has to provide registration services. > It would be disingenuous to offer a database of information, recommend it be used by the public, support its use as an authoritative source, and then deny any responsibility for the contents. I don't think your position on this particular topic reflects ARIN in reality. > I am not denying that ARIN has responsibility for the contents of the database. I absolutely feel they are responsible to the members and to the resource holders who pay ARIN for registration services to keep that data accurate. So far, they have also voluntarily accepted additional data which may or may not be accurate in support of a community of pre-existing registrations that have no contract with ARIN. There is no reason I know of that ARIN would not be within its rights to terminate that free voluntary registration service at any time. Note, I think such an action on ARINs part would be ill-advised and contrary to the good of the community and harmful to the internet. It might even be damaging to ARINs very relevance to the internet. I'm merely pointing out that legacy holders cannot be assured ARIN will continue to provide a free registration service for them in perpetuity. If they want to guarantee the services they have today, signing the LRSA is crucial. If they do not sign the LRSA, there is nothing to prevent the community from changing ARIN policy in such a way that said free services are terminated. I will oppose any such move by the community. I have strongly opposed previous efforts in this direction. However, I am one voice in a much larger community. Owen From marka at isc.org Sat Feb 5 23:57:38 2011 From: marka at isc.org (Mark Andrews) Date: Sun, 06 Feb 2011 16:57:38 +1100 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: Your message of "Sat, 05 Feb 2011 21:58:21 MDT." <4D4E1C5D.20407@brightok.net> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org> <4D4C0D25.70408@brightok.net> <20110204231134.3AA029B2B39@drugs.dv.isc.org> <4D4C8AF8.1030703@brightok.net> <20110205004517.371F99B3B3C@drugs.dv.isc.org> <4D4CA1B1.5060002@brightok.net> <20110205124710.059259B4E31@drugs.dv.isc.org> <4D4D5FFC.6020905@brightok.net> <20110206010145.9DCD99B60B9@drugs.dv.isc.org> <4D4DF75E.1040109@brightok.net> <20110206024051.D60349B6D50@drugs.dv.isc.org> <4D4E1C5D.20407@brightok.net> Message-ID: <20110206055738.A128B9B78EA@drugs.dv.isc.org> In message <4D4E1C5D.20407 at brightok.net>, Jack Bates writes: > On 2/5/2011 8:40 PM, Mark Andrews wrote: > > A IPv4 /16 supports 64000 potential customers. A IPv6 /32 supports > > 64000 potential customers. Either you have changed the customer > > estimates or changed the growth space allowances or were using NAT > > or .... > > > > You don't suddenly need 256 times the amount of space overnight all > > other things being equal. About the only thing I can think of is > > you need to advertise 256 routes and you are asking for extra blocks > > to get around poorly thought out filtering policies. > > > What filtering policies? My allocation was based on customers per > terminating router, 1 route per terminating router. A /32 was nowhere > near enough. The reason a /16 works today is because I have a routing > table that looks like swiss cheese and a 95%+ utilization rate. 9 /40 > (equiv of 9 /24 IPv4 DHCP pools for residential DSL) networks don't fall > on a bit boundary. Nibble would make things even easier, but to say I > have to run multiple routes to a pop and squeeze things in as tight as > possible is insane. Justifications DO allow for some amount of > aggregation in numbering plans. Rationalising to power of 2 allocations shouldn't result in requiring 256 times the space you were claiming with the 8 bits of shift on average. A couple of bits will allow that. > > If ISPs were being honest and matching IPv4 to IPv6 filtering the > > filters would be set a /40 not /32. By setting the filters to /32 > > you force the small ISP to ask for up to 256 times as much address > > space as they need with absolutely no benefits to anyone just to > > get a routing slot that won't be filtered. > > > Actually, many router policies, as discussed previously on the list, > support /48. Routing policies don't force the /32, and a current > proposal to ARIN even supports a small ISP getting a /36, hopefully at a > lower cost. > > > What's really needed is seperate the routing slot market from the > > address allocation market. > > > > I agree that inter-AS routing needs to change, though that still has > nothing to do with address allocation itself. Sizes of allocations were > chosen to allow for growth. The ISPs don't get near the wiggle room that > corporations and end users get in address assignment currently. > > When analyzing exhaustion rate of IPv6, like IPv4, you have to view it > at the RIR allocation level. In this case, across the board, we will see > a minimum of an 8 bit shift in allocations, and often 12-16 bits (what's > to the right of the allocation bits doesn't matter when we consider > exhaustion rates, so long as what's to the right is appropriately > utilized and justified by community standards before another request is > handled by the RIR). You need to look very closely at any ISP that only shifts 8 bits going from IPv4 to IPv6, something dodgy is probably going on. This is not to say it is deliberately dodgy. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From drc at virtualized.org Sun Feb 6 00:25:04 2011 From: drc at virtualized.org (David Conrad) Date: Sat, 5 Feb 2011 20:25:04 -1000 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <20110205193328.GC22325@vacation.karoshi.com> <08F8827D-D8C3-4922-AC39-6C71ADBE8BDB@corp.arin.net> <20110206014014.GG22325@vacation.karoshi.com> Message-ID: <849FDB3F-EE29-48D6-8ECD-70AE6EB0B157@virtualized.org> John, On Feb 5, 2011, at 7:33 PM, John Curran wrote: >> It does not talk to address space allocated to entities from the IANA or other >> registries prior to the RIRs existance. > Is it your belief that Jon did not intend RFC 2050 to apply to the existing > allocations maintained by the three regional registries in existence at the > time (InterNIC, RIPE NCC and APNIC)? Last I checked, the other four authors of RFC 2050 are still alive. Why not ask them? > Further, RFC 2050 states "The transfer of IP addresses from one party to another > must be approved by the regional registries. The party trying to obtain the IP > address must meet the same criteria as if they were requesting an IP address > directly from the IR." I'm curious: when HP acquired the assets of Compaq (or when Compaq acquired the assets of Digital), is it your position that HP (or Compaq) "met the same criteria as if they were requesting an IP address directly from the IR." for 16.0.0.0/8? Regards, -drc From trelane at trelane.net Sun Feb 6 00:33:05 2011 From: trelane at trelane.net (Andrew Kirch) Date: Sun, 06 Feb 2011 01:33:05 -0500 Subject: US Warships jamming Lebanon Internet In-Reply-To: References: Message-ID: <4D4E40A1.2010408@trelane.net> On 2/6/2011 12:00 AM, Joly MacFie wrote: > Lebanon's Telecom minister is claiming that US Navy radar is blocking the > country's Internet.. > > http://www.naharnet.com/domino/tn/NewsDesk.nsf/0/93A95CA1A4E42178C225782E007371AF > > "The problem, however, is due to a coordination error related to waves," > Ok, I'm confused here, did we get one of our Aegis missile cruisers stuck in their series of tubes? Andrew From frnkblk at iname.com Sun Feb 6 00:34:14 2011 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 6 Feb 2011 00:34:14 -0600 Subject: My upstream ISP does not support IPv6 In-Reply-To: <4D4C4249.7010209@rollernet.us> References: <1127264403.2346.1296791643752.JavaMail.root@zimbra.network1.net> <4D4C0976.8010506@brightok.net> <4D4C4249.7010209@rollernet.us> Message-ID: <013c01cbc5c7$dfa509d0$9eef1d70$@iname.com> Here's a chart: http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_by_major_transit_providers Frank -----Original Message----- From: Seth Mattinen [mailto:sethm at rollernet.us] Sent: Friday, February 04, 2011 12:16 PM To: nanog at nanog.org Subject: Re: My upstream ISP does not support IPv6 On 2/4/2011 06:13, Jack Bates wrote: > > I waited years and finally turned up a transit to L3 for additional > bandwidth (had to wait for GE support from the other 2, of which 1 still > can't give me a GE) and luckily native v6. Within 30 days I should have > a cogent 10G, and I hear I'll get v6 there as well. > Does anyone know how partitioned Cogent is these days? ~Seth From mike.lyon at gmail.com Sun Feb 6 00:37:53 2011 From: mike.lyon at gmail.com (Mike Lyon) Date: Sat, 5 Feb 2011 22:37:53 -0800 Subject: US Warships jamming Lebanon Internet In-Reply-To: <4D4E40A1.2010408@trelane.net> References: <4D4E40A1.2010408@trelane.net> Message-ID: No, it's those Radar Sharks with Frickin' lasers on their heads: http://pokerterms.com/images/sharks-with-lasers-2.jpg -Mike On Sat, Feb 5, 2011 at 10:33 PM, Andrew Kirch wrote: > On 2/6/2011 12:00 AM, Joly MacFie wrote: > > Lebanon's Telecom minister is claiming that US Navy radar is blocking the > > country's Internet.. > > > > > http://www.naharnet.com/domino/tn/NewsDesk.nsf/0/93A95CA1A4E42178C225782E007371AF > > > > "The problem, however, is due to a coordination error related to waves," > > > Ok, I'm confused here, did we get one of our Aegis missile cruisers > stuck in their series of tubes? > > Andrew > > > From jcurran at arin.net Sun Feb 6 00:47:06 2011 From: jcurran at arin.net (John Curran) Date: Sun, 6 Feb 2011 06:47:06 +0000 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <849FDB3F-EE29-48D6-8ECD-70AE6EB0B157@virtualized.org> References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <20110205193328.GC22325@vacation.karoshi.com> <08F8827D-D8C3-4922-AC39-6C71ADBE8BDB@corp.arin.net> <20110206014014.GG22325@vacation.karoshi.com> <849FDB3F-EE29-48D6-8ECD-70AE6EB0B157@virtualized.org> Message-ID: <585A8651-6C2E-4B16-9D03-6C756CC9E77D@arin.net> On Feb 6, 2011, at 1:25 AM, David Conrad wrote: > Last I checked, the other four authors of RFC 2050 are still alive. Why not ask them? Bill indicated he "was there when it was written" in reference to Jon being an author, and I was inquiring to whether he had any knowledge of Jon's intent that he could share. If you have knowledge of Jon's intent, or any insight on why RFC 2050 includes the existing allocations if the intent was actually to leave it vague with respect to same, that also would be helpful. >> Further, RFC 2050 states "The transfer of IP addresses from one party to another >> must be approved by the regional registries. The party trying to obtain the IP >> address must meet the same criteria as if they were requesting an IP address >> directly from the IR." > > I'm curious: when HP acquired the assets of Compaq (or when Compaq acquired the assets of Digital), is it your position that HP (or Compaq) "met the same criteria as if they were requesting an IP address directly from the IR." for 16.0.0.0/8? The handling of general case varies based on the community developed policy over the years, currently as specified by NRPM 8.2 (M&A Transfer) in https://www.arin.net/policy/nrpm.html. There's a Change Log on the page if you want to track the policy at any given point in time. I can not comment on any specific transfer request, but will note that at one time the M&A transfer policy allowed transfer of all held number resources without justification of need as long as the entire entity was involved, but at this point the policy indicates that: "In the event that number resources of the combined organizations are no longer justified under ARIN policy at the time ARIN becomes aware of the transaction, through a transfer request or otherwise, ARIN will work with the resource holder(s) to return, aggregate, or reclaim resources as appropriate via the processes outlined in current ARIN policy (for example, sections 4.6, 4.7, or 12 of the NRPM)." FYI, /John John Curran President and CEO ARIN From millnert at gmail.com Sun Feb 6 01:20:16 2011 From: millnert at gmail.com (Martin Millnert) Date: Sun, 6 Feb 2011 02:20:16 -0500 Subject: US Warships jamming Lebanon Internet In-Reply-To: References: Message-ID: On Sun, Feb 6, 2011 at 12:00 AM, Joly MacFie wrote: > Lebanon's Telecom minister is claiming that US Navy radar is blocking the > country's Internet.. > > http://www.naharnet.com/domino/tn/NewsDesk.nsf/0/93A95CA1A4E42178C225782E007371AF > > "The problem, however, is due to a coordination error related to waves," >> Nahhas told OTV, adding that an investigation was underway to find out >> whether this act is "intentional or not." > > > also at > http://www.naharnet.com/domino/tn/NewsDesk.nsf/Lebanon/EFCEF203B3C315A5C225782E0020C75F Well-known problem with radars and wifi (used to live next to a (military) radar research site): http://en.wikipedia.org/wiki/Radar#Frequency_bands -- Check who uses S and C http://en.wikipedia.org/wiki/S_band Another reason to not rely on radio for your LAN/WAN in times of Aegis cruisers passing by... ;) Regards, Martin From nanog at thedaileyplanet.com Sun Feb 6 01:32:55 2011 From: nanog at thedaileyplanet.com (Chad Dailey) Date: Sun, 6 Feb 2011 01:32:55 -0600 Subject: US Warships jamming Lebanon Internet In-Reply-To: References: Message-ID: I used to work on some of this gear. The transmitters do indeed go to 11. If they want to talk, you won't. On Sun, Feb 6, 2011 at 1:20 AM, Martin Millnert wrote: > On Sun, Feb 6, 2011 at 12:00 AM, Joly MacFie wrote: > > Lebanon's Telecom minister is claiming that US Navy radar is blocking the > > country's Internet.. > > > > > http://www.naharnet.com/domino/tn/NewsDesk.nsf/0/93A95CA1A4E42178C225782E007371AF > > > > "The problem, however, is due to a coordination error related to waves," > >> Nahhas told OTV, adding that an investigation was underway to find out > >> whether this act is "intentional or not." > > > > > > also at > > > http://www.naharnet.com/domino/tn/NewsDesk.nsf/Lebanon/EFCEF203B3C315A5C225782E0020C75F > > Well-known problem with radars and wifi (used to live next to a > (military) radar research site): > http://en.wikipedia.org/wiki/Radar#Frequency_bands -- Check who uses S and > C > http://en.wikipedia.org/wiki/S_band > > Another reason to not rely on radio for your LAN/WAN in times of Aegis > cruisers passing by... ;) > > Regards, > Martin > > From tvhawaii at shaka.com Sun Feb 6 01:47:12 2011 From: tvhawaii at shaka.com (Michael Painter) Date: Sat, 5 Feb 2011 21:47:12 -1000 Subject: US Warships jamming Lebanon Internet References: Message-ID: Martin Millnert wrote: > On Sun, Feb 6, 2011 at 12:00 AM, Joly MacFie wrote: >> Lebanon's Telecom minister is claiming that US Navy radar is blocking the >> country's Internet.. >> >> http://www.naharnet.com/domino/tn/NewsDesk.nsf/0/93A95CA1A4E42178C225782E007371AF >> >> "The problem, however, is due to a coordination error related to waves," >>> Nahhas told OTV, adding that an investigation was underway to find out >>> whether this act is "intentional or not." >> >> >> also at >> http://www.naharnet.com/domino/tn/NewsDesk.nsf/Lebanon/EFCEF203B3C315A5C225782E0020C75F > > Well-known problem with radars and wifi (used to live next to a > (military) radar research site): > http://en.wikipedia.org/wiki/Radar#Frequency_bands -- Check who uses S and C > http://en.wikipedia.org/wiki/S_band > > Another reason to not rely on radio for your LAN/WAN in times of Aegis > cruisers passing by... ;) > > Regards, >Martin I've seen Aegis radar interfere with C-band satellite communications (3720-4180 MHz.) which is used by all kinds of services. From ryan.finnesey at HarrierInvestments.com Sun Feb 6 01:58:35 2011 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Sat, 5 Feb 2011 23:58:35 -0800 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <72609B8A-05D2-4039-85C4-A0578B9E6911@cisco.com> References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> <96503CEA-C922-47A6-9691-FCF157DF15D5@internode.com.au> <10A940BA-6D90-4663-B942-5FFF2CB49D7A@internode.com.au> <4D4BAD13.9090301@gmail.com><88BC6885D33A9D42A1CCB45E8749525E013CBC58@pigeon.sandiego.nextlevelinternet.com> <72609B8A-05D2-4039-85C4-A0578B9E6911@cisco.com> Message-ID: <6EFFEFBAC68377459A2E972105C759EC03539EE1@EXVBE005-2.exch005intermedia.net> Does anyone know when they took down connectivity in Egypt did they also bring down the MPLS networks global companies use? Cheers Ryan -----Original Message----- From: Fred Baker [mailto:fred at cisco.com] Sent: Saturday, February 05, 2011 9:43 AM To: Hayden Katzenellenbogen Cc: NANOG list Subject: Re: Weekend Gedankenexperiment - The Kill Switch On Feb 4, 2011, at 9:49 PM, Hayden Katzenellenbogen wrote: > Not sure if it has been said already but wasn't one of the key point > for the creation of the internet to create and infrastructure that > would survive in the case of all out war and massive destruction. > (strategic nuclear strikes) Urban legend, although widely believed. Someone probably made the observation. > Does it not bode ill for "national security" if any party could take > out a massive communication system by destroying/pressuring a few > choke points? You mean, like drop a couple of trade towers and take out three class five switches, causing communication outages throughout New England and New Jersey, and affecting places as far away as Chicago? Nope. Couldn't happen. More seriously, yes, one could in fact take out any connectivity one wants by withdrawing routes (which is reportedly what Egypt did), and if you hit enough interchange points that could get serious. At the risk of sounding naive and pollyanna-ish, we have a few more of those interchange points in the US than they have in Egypt. In theory, yes. Making it actually happen could be quite an operation. > -----Original Message----- > From: JC Dill [mailto:jcdill.lists at gmail.com] > Sent: Thursday, February 03, 2011 11:39 PM > To: NANOG list > Subject: Re: Weekend Gedankenexperiment - The Kill Switch > > On 03/02/11 10:38 PM, Paul Ferguson wrote: >> >> And as an aside, governments will always believe that that they can > control >> the flow of information, when push comes to shove. >> >> This has always been a hazard, and will always continue to be so. >> >> As technologists, we need to be cognizant of that fact. > > In the US, by accident (surely not by design) we are lucky that our > network of networks does not have the convenient 4 chokepoints that > the Egyptian network had, making it easy for the government to shut > off the entier internet by putting pressure on just 4 companies. > > Where we *really* need to be fighting this battle is in the laws and > policies that are producing a duopoly in much of the US where > consumers have 2 choices, the ILEC for DSL or their local cableco for > Cable Internet. As theses companies push smaller competing ISPs out > of business, and as they consolidate (e.g. Cablecos buying each other > up, resulting in fewer and fewer cablecos over time), we head down the > direction of Egypt, where pressure on just a few companies CAN shut > down > > the entire internet. Otherwise we end up with a few companies that > will > > play Visa and PayPal and roll over and play dead when a government > official says "Wikileaks is bad" - and equally easily will shut down > their entire networks for "national security". > > If you *really* believe that the TSA is effective, you would be in > favor > > of an Internet Kill Switch. If you understand that this is really > security theater, and despite all the inconvenience we aren't really > any > > safer, then you should equally be very concerned that someone ever has > the power to order that the internet be "shut down" for our safety. > > jc > > > From aj at sneep.net Sun Feb 6 05:12:29 2011 From: aj at sneep.net (Alastair Johnson) Date: Sun, 6 Feb 2011 11:12:29 +0000 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <6EFFEFBAC68377459A2E972105C759EC03539EE1@EXVBE005-2.exch005intermedia.net> References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> <96503CEA-C922-47A6-9691-FCF157DF15D5@internode.com.au> <10A940BA-6D90-4663-B942-5FFF2CB49D7A@internode.com.au> <4D4BAD13.9090301@gmail.com><88BC6885D33A9D42A1CCB45E8749525E013CBC58@pigeon.sandiego.nextlevelinternet.com><72609B8A-05D2-4039-85C4-A0578B9E6911@cisco.com><6EFFEFBAC68377459A2E972105C759EC03539EE1@EXVBE005-2.exch005intermedia.net> Message-ID: <1108983344-1296990747-cardhu_decombobulator_blackberry.rim.net-633387637-@bda2157.bisx.prod.on.blackberry> No - at least some links were still up. I saw both IPVPNs and leased lines still working during the event. aj -----Original Message----- From: "Ryan Finnesey" Date: Sat, 5 Feb 2011 23:58:35 To: Fred Baker; Hayden Katzenellenbogen Cc: NANOG list Subject: RE: Weekend Gedankenexperiment - The Kill Switch Does anyone know when they took down connectivity in Egypt did they also bring down the MPLS networks global companies use? Cheers Ryan -----Original Message----- From: Fred Baker [mailto:fred at cisco.com] Sent: Saturday, February 05, 2011 9:43 AM To: Hayden Katzenellenbogen Cc: NANOG list Subject: Re: Weekend Gedankenexperiment - The Kill Switch On Feb 4, 2011, at 9:49 PM, Hayden Katzenellenbogen wrote: > Not sure if it has been said already but wasn't one of the key point > for the creation of the internet to create and infrastructure that > would survive in the case of all out war and massive destruction. > (strategic nuclear strikes) Urban legend, although widely believed. Someone probably made the observation. > Does it not bode ill for "national security" if any party could take > out a massive communication system by destroying/pressuring a few > choke points? You mean, like drop a couple of trade towers and take out three class five switches, causing communication outages throughout New England and New Jersey, and affecting places as far away as Chicago? Nope. Couldn't happen. More seriously, yes, one could in fact take out any connectivity one wants by withdrawing routes (which is reportedly what Egypt did), and if you hit enough interchange points that could get serious. At the risk of sounding naive and pollyanna-ish, we have a few more of those interchange points in the US than they have in Egypt. In theory, yes. Making it actually happen could be quite an operation. > -----Original Message----- > From: JC Dill [mailto:jcdill.lists at gmail.com] > Sent: Thursday, February 03, 2011 11:39 PM > To: NANOG list > Subject: Re: Weekend Gedankenexperiment - The Kill Switch > > On 03/02/11 10:38 PM, Paul Ferguson wrote: >> >> And as an aside, governments will always believe that that they can > control >> the flow of information, when push comes to shove. >> >> This has always been a hazard, and will always continue to be so. >> >> As technologists, we need to be cognizant of that fact. > > In the US, by accident (surely not by design) we are lucky that our > network of networks does not have the convenient 4 chokepoints that > the Egyptian network had, making it easy for the government to shut > off the entier internet by putting pressure on just 4 companies. > > Where we *really* need to be fighting this battle is in the laws and > policies that are producing a duopoly in much of the US where > consumers have 2 choices, the ILEC for DSL or their local cableco for > Cable Internet. As theses companies push smaller competing ISPs out > of business, and as they consolidate (e.g. Cablecos buying each other > up, resulting in fewer and fewer cablecos over time), we head down the > direction of Egypt, where pressure on just a few companies CAN shut > down > > the entire internet. Otherwise we end up with a few companies that > will > > play Visa and PayPal and roll over and play dead when a government > official says "Wikileaks is bad" - and equally easily will shut down > their entire networks for "national security". > > If you *really* believe that the TSA is effective, you would be in > favor > > of an Internet Kill Switch. If you understand that this is really > security theater, and despite all the inconvenience we aren't really > any > > safer, then you should equally be very concerned that someone ever has > the power to order that the internet be "shut down" for our safety. > > jc > > > From lee at asgard.org Sun Feb 6 07:47:16 2011 From: lee at asgard.org (Lee Howard) Date: Sun, 6 Feb 2011 08:47:16 -0500 Subject: Post-Exhaustion-phase "punishment" for early adopters In-Reply-To: References: <4D4C49BE.3030907@hstrauss.co.za> <250E0B78-4DC5-4A94-B05A-95F0755C8884@pch.net> <640AC628-0D14-4194-A195-3A58E6008917@humancapitaldev.com> <5C82B551-CE7D-4838-BC7D-150FE6DB108C@ianai.net> <4097D073-B087-4B97-BD23-51B80C3BC313@puck.nether.net> Message-ID: <000001cbc604$5e4462e0$1acd28a0$@org> > -----Original Message----- > From: Jimmy Hess [mailto:mysidia at gmail.com] > > The most important thing to ensure "usage" is recognized is that the > entire address space is announced plus routed, I don't speak on behalf of a community, but in the past there have been people reminding the ARIN community that there are valid uses for address space, contemplated by rfc2050, in addition to routing on the public Internet. > You might look into the option of signing the Legacy RSA: > https://www.arin.net/resources/legacy/ > Available until Dec 2011; If your allocation predated ARIN. Yes. You might decide you don't like some provision, but it would be careless not to look into it. > I doubt the community is going to scour through all the /24 > allocations and try to reclaim them, however. It's not that legacy > /24 allocations don't matter, if they are entirely derelict, but the > /8s are the ones that "sort of" matter... sort of, because a /8 > reclaimed could provide a few months of IP addresses for a RIR. Agree; according to https://www.arin.net/knowledge/statistics/index.html ARIN has been issuing 20,000 - 50,000 /24 per month for the past few months. A /24 wouldn't extend runout time by a full minute. > It's not likely but conceivable, that the RIRs could decide to > make a policy of reviewing legacy resources and revoking allocations > with bad contact info, or apply > an "efficient usage" criterion requiring return/renumbering, for > legacy resource holders who have no RSA. That would be an exciting debate. Lee From lee at asgard.org Sun Feb 6 08:16:35 2011 From: lee at asgard.org (Lee Howard) Date: Sun, 6 Feb 2011 09:16:35 -0500 Subject: quietly.... In-Reply-To: <8DABAA64-1036-4B27-BCDA-D3E4833FDB4F@delong.com> References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> <483E6B0272B0284BA86D7596C40D29F9011F76964E94@PUR-EXCH07.ox.com> <37955.1296761312@localhost> <201102031520.26126.lowen@pari.edu> <48563.1296769591@localhost> <8DABAA64-1036-4B27-BCDA-D3E4833FDB4F@delong.com> Message-ID: <000101cbc608$769782b0$63c68810$@org> > The end-to-end model is about "If my packet is permitted by policy and delivered to the > remote host, I expect it to arrive as sent, without unexpected modifications." Well, it's about communications integrity being the responsibility of the endpoint. It is therefore expected that the network not mess with the communication. See http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf > Nobody wants to get rid of firewalls. Several people want to get rid of firewalls. Consistent with the end-to-end principle, hosts should provide their own policy enforcement. See expired draft-vyncke-advanced-ipv6-security-01 Unfortunately, the approach described doesn't work in state-of-the-art residential CPE, and relies heavily on endpoint security protection, which is weak in most Internet hosts. > We want to get rid of NAT. Firewalls work great > without NAT and by having > firewalls without NAT, we gain back the end-to-end model while preserving the ability to > enforce policy on end-to-end connectivity. I would rather see hosts protect themselves from badness, and network security appliances be limited to protecting against network threats (a DDOS is a network threat; a service DOS is an application threat). > > NAT doesn't destroy end-to-end. It just makes it slightly more difficult. But no more > > difficult that turning on a firewall does. > > It doesn't break anything that isn't trying to "announce" itself - and imo, applications that > > want to "announce" themselves seem like a pretty big security hole. Service discovery is an Internet weakness. > NAT does destroy end-to-end. Firewalls do not. Firewalls merely constrict it. Not that I advocate against the use of firewalls; in fact, I think I'm agreeing with you, and extending the argument a little further, that we should move from NAT to firewalls, then from stateful firewalls to secure hosts and network security appliances. Lee From isabeldias1 at yahoo.com Sun Feb 6 08:45:45 2011 From: isabeldias1 at yahoo.com (isabel dias) Date: Sun, 6 Feb 2011 06:45:45 -0800 (PST) Subject: quietly.... In-Reply-To: <000101cbc608$769782b0$63c68810$@org> References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> <483E6B0272B0284BA86D7596C40D29F9011F76964E94@PUR-EXCH07.ox.com> <37955.1296761312@localhost> <201102031520.26126.lowen@pari.edu> <48563.1296769591@localhost> <8DABAA64-1036-4B27-BCDA-D3E4833FDB4F@delong.com> <000101cbc608$769782b0$63c68810$@org> Message-ID: <764658.39553.qm@web121605.mail.ne1.yahoo.com> sure ................ ________________________________ From: Lee Howard To: Owen DeLong ; david raistrick Cc: nanog at nanog.org Sent: Sun, February 6, 2011 2:16:35 PM Subject: RE: quietly.... > The end-to-end model is about "If my packet is permitted by policy and delivered to the > remote host, I expect it to arrive as sent, without unexpected modifications." Well, it's about communications integrity being the responsibility of the endpoint.? It is therefore expected that the network not mess with the communication. See http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf > Nobody wants to get rid of firewalls. Several people want to get rid of firewalls.? Consistent with the end-to-end principle, hosts should provide their own policy enforcement.? See expired draft-vyncke-advanced-ipv6-security-01 Unfortunately, the approach described doesn't work in state-of-the-art residential CPE, and relies heavily on endpoint security protection, which is weak in most Internet hosts.? > We want to get rid of NAT. Firewalls work great > without NAT and by having > firewalls without NAT, we gain back the end-to-end model while preserving the ability to > enforce policy on end-to-end connectivity. I would rather see hosts protect themselves from badness, and network security appliances be limited to protecting against network threats (a DDOS is a network threat; a service DOS is an application threat). > > NAT doesn't destroy end-to-end.? It just makes it slightly more difficult. But no more > > difficult that turning on a firewall does. > > It doesn't break anything that isn't trying to "announce" itself - and imo, applications that > > want to "announce" themselves seem like a pretty big security hole. Service discovery is an Internet weakness. > NAT does destroy end-to-end. Firewalls do not. Firewalls merely constrict it.? Not that I advocate against the use of firewalls; in fact, I think I'm agreeing with you, and extending the argument a little further, that we should move from NAT to firewalls, then from stateful firewalls to secure hosts and network security appliances. Lee From tjc at ecs.soton.ac.uk Sun Feb 6 08:52:41 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Sun, 6 Feb 2011 14:52:41 +0000 Subject: Top webhosters offering v6 too? References: <16975AA8-ABEB-402E-BA05-1BE51138A133@ecs.soton.ac.uk> Message-ID: Which of the big boys are doing it? Tim From isabeldias1 at yahoo.com Sun Feb 6 08:57:06 2011 From: isabeldias1 at yahoo.com (isabel dias) Date: Sun, 6 Feb 2011 06:57:06 -0800 (PST) Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <9D145C3C-2D3A-4D73-997C-6346B6EF402A@deadfrog.net> References: <5817196.4787.1296792606407.JavaMail.root@benjamin.baylink.com> <9D145C3C-2D3A-4D73-997C-6346B6EF402A@deadfrog.net> Message-ID: <30423.88286.qm@web121602.mail.ne1.yahoo.com> do you have a satellite dish? what are your dish pointing coordinates......we just need to find out what is going on the air interface? ... ________________________________ From: Ryan Wilkins To: Jay Ashworth Cc: NANOG Sent: Fri, February 4, 2011 4:46:47 AM Subject: Re: Weekend Gedankenexperiment - The Kill Switch On Feb 3, 2011, at 10:10 PM, Jay Ashworth wrote: > ---- Original Message ----- >> What do you do when you get home to put it back on the air -- let's >> say email as a base service, since it is -- do you have the gear laying >around, >> and how long would it take? > > Focus on this part, BTW, folks; let's ignore the politics behind the > shutdown.? :-) > So if I get what you're saying, I could have something operational from scratch in a few hours.? I've got a variety of Cisco routers and switches, Linux and Mac OS X boxes in various shapes and sizes, and a five CPE + one AP 5 GHz Mikrotik RouterOS-based radio system, 802.11b/g wireless AP, 800' of Cat 5e cable, connectors, and crimpers.? The radios, if well placed, could allow me to connect up several strategic locations, or perhaps use them to connect to other sources of Internet access, if available.? If it really came down to it, I could probably gather enough satellite communications gear from the office to allow me to stand up satellite Internet to someone.? Of course, the trick would be to talk to that "someone" to coordinate connectivity over the satellite which may be hard to do given the communications outage you described.? I wouldn't be so worried about transmitting to the satellite, in this case I'd just transmit without authorization, but someone needs to be receiving my transmission and vice versa for this to be useful.? At a minimum, I could enable communications between my neighbors. Regards, Ryan Wilkins From jbates at brightok.net Sun Feb 6 09:07:42 2011 From: jbates at brightok.net (Jack Bates) Date: Sun, 06 Feb 2011 09:07:42 -0600 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: <20110206055738.A128B9B78EA@drugs.dv.isc.org> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org> <4D4C0D25.70408@brightok.net> <20110204231134.3AA029B2B39@drugs.dv.isc.org> <4D4C8AF8.1030703@brightok.net> <20110205004517.371F99B3B3C@drugs.dv.isc.org> <4D4CA1B1.5060002@brightok.net> <20110205124710.059259B4E31@drugs.dv.isc.org> <4D4D5FFC.6020905@brightok.net> <20110206010145.9DCD99B60B9@drugs.dv.isc.org> <4D4DF75E.1040109@brightok.net> <20110206024051.D60349B6D50@drugs.dv.isc.org> <4D4E1C5D.20407@brightok.net> <20110206055738.A128B9B78EA@drugs.dv.isc.org> Message-ID: <4D4EB93E.6000409@brightok.net> On 2/5/2011 11:57 PM, Mark Andrews wrote: > > Rationalising to power of 2 allocations shouldn't result in requiring > 256 times the space you were claiming with the 8 bits of shift on > average. A couple of bits will allow that. > I didn't claim 8 bit average (if I accidentally did, my apologies). I claimed a minimum of 8 bits. Somewhere between 12 and 16 is more likely. However, with new ARIN proposals, we will see shorter shifts (yet still over 8 bit shifts) as it does nibble allocations for everything (pop assignments nibble aligned, ISP allocations nibble aligned, ISP to ISP reallocation policies). It treats utilization as a 75% bar with nibble alignments to allow for proper growth at the ISP level. So for me, my /30 will at least expand out to a /28, though I will have to reanalyze the pop allocations with the new rules, as it's possible I may bump to a /24 (if I end up expanding to a /27 of actual current usage). > You need to look very closely at any ISP that only shifts 8 bits going > from IPv4 to IPv6, something dodgy is probably going on. This is not > to say it is deliberately dodgy. > Currently, I agree. It should be between 12 and 16 normally. However, new policy proposals are designed in such a way that the bit shift may only be 8. However, this also depends on the ISP. As ISPs do look towards dropping v4 in priority, they will also look at redesigning some of their pop layouts. This is actually a case for me. Due to growth and utilization issues on IPv4, I've concentrated pops into supernodes to better utilize the v4 I have (95% utilization of pools which cover much larger customer sets, versus a bunch of smaller utilized pools which have less utilization rates as the pops don't grow at the same rate). However, I have areas this is reaching a critical point, and the IPv6 model is dividing up into smaller pop nodes. Since I don't have address space concerns for IPv6, structuring the network and customer termination into a better layout is more appropriate. What's more, in most cases, I can accomplish v4 supernodes and v6 separation at the same time; and I'll see the benefits as more customers shift to actual v6 connectivity. Jack From jra at baylink.com Sun Feb 6 09:24:06 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 6 Feb 2011 10:24:06 -0500 (EST) Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <30423.88286.qm@web121602.mail.ne1.yahoo.com> Message-ID: <18870051.5285.1297005846948.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "isabel dias" > do you have a satellite dish? what are your dish pointing > coordinates......we > just need to find out what is going on the air interface ... Well, either iDirect or SCPC... Cheers, -- jra From jcurran at istaff.org Sun Feb 6 10:00:19 2011 From: jcurran at istaff.org (John Curran) Date: Sun, 6 Feb 2011 11:00:19 -0500 Subject: What's really needed is a routing slot market (was: Using IPv6 with prefixes shorter than a /64 on a LAN) In-Reply-To: <20110206024051.D60349B6D50@drugs.dv.isc.org> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org> <4D4C0D25.70408@brightok.net> <20110204231134.3AA029B2B39@drugs.dv.isc.org> <4D4C8AF8.1030703@brightok.net> <20110205004517.371F99B3B3C@drugs.dv.isc.org> <4D4CA1B1.5060002@brightok.net> <20110205124710.059259B4E31@drugs.dv.isc.org> <4D4D5FFC.6020905@brightok.net> <20110206010145.9DCD99B60B9@drugs.dv.isc.org> <4D4DF75E.1040109@brightok.net> <20110206024051.D60349B6D50@drugs.dv.isc.org> Message-ID: On Feb 5, 2011, at 9:40 PM, Mark Andrews wrote: > What's really needed is seperate the routing slot market from the > address allocation market. Bingo! In fact, having an efficient market for obtaining routing of a given prefix, combined with IPv6 vast identifier space, could actually satisfy the primary goals that we hold for a long-term scalable address architecture, and enable doing it in a highly distributed, automatable fashion: Aggregation would be encouraged, since use of non-aggregatable address space would entail addition costs. These costs might be seen as minimal for some organizations that desire addressing autonomy, but others might decide treating their address space portable and routable results in higher cost than is desired. Decisions about changing prefixes with ISPs can be made based on a rational tradeoff of costs, rather than in a thicket of ISP and registry policies. Conservation would actually be greatly improved, since address space would only be sought after because of the need for additional unique identifiers, rather than obtaining an address block of a given size to warrant implied routability. In light of IPv6's vast address space, it actually would be possible to provide minimally-sized but assured unique prefixes automatically via nearly any mechanism (i.e. let your local user or trade association be a registry if they want) With a significantly reduced policy framework, Registration could be fully automated, with issuance being as simple as assurance the right level of verification of requester identity (You might even get rid of this, if you can assure that ISPs obtain clear identity of clients before serving them but that would preclude any form of reputation systems based on IP address prefix such as we have in use today...) Just think: the savings in storage costs alone (from the reduction in address policy-related email on all our mailing lists) could probably fund the system. :-) Oh well, one project at a time... /John From owen at delong.com Sun Feb 6 10:22:55 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 6 Feb 2011 08:22:55 -0800 Subject: quietly.... In-Reply-To: <000101cbc608$769782b0$63c68810$@org> References: <19189394.4483.1296750541218.JavaMail.root@benjamin.baylink.com> <483E6B0272B0284BA86D7596C40D29F9011F76964E94@PUR-EXCH07.ox.com> <37955.1296761312@localhost> <201102031520.26126.lowen@pari.edu> <48563.1296769591@localhost> <8DABAA64-1036-4B27-BCDA-D3E4833FDB4F@delong.com> <000101cbc608$769782b0$63c68810$@org> Message-ID: > > Firewalls merely constrict it. Not that I advocate against the use of > firewalls; > in fact, I think I'm agreeing with you, and extending the argument a little > further, > that we should move from NAT to firewalls, then from stateful firewalls to > secure hosts and network security appliances. > > Lee > I would be fine with that. However, in terms of the art of the possible with the tools available today, IPv6 has no need of NAT, but, firewalls cannot yet be safely removed from the equation. Owen From simon.leinen at switch.ch Sun Feb 6 10:43:04 2011 From: simon.leinen at switch.ch (Simon Leinen) Date: Sun, 06 Feb 2011 17:43:04 +0100 Subject: Top webhosters offering v6 too? In-Reply-To: (Tim Chown's message of "Sun, 6 Feb 2011 14:52:41 +0000") References: <16975AA8-ABEB-402E-BA05-1BE51138A133@ecs.soton.ac.uk> Message-ID: Tim Chown writes: > Which of the big boys are doing it? Google - although there don't call themselves a web hoster, they can be used for hosting web sites using services such as Sites or App Engine. Both support IPv6, either using the opt-in mechanism or by using an alternate CNAME (ghs46 instead of ghs.google.com). That's what I use. None of the other large "cloud" providers seems to support IPv6 for their users yet. In particular, neither Amazon's AWS not Microsoft Azure have much visible activity in this direction. Rackspace have announced IPv6 support for the first half of 2011. Concerning the more traditional webhosting offerings, I have no idea about the "big boys". Here in Switzerland, a few smaller hosters support IPv6. And I saw IPv6 mentioned in ads for some German server hosting offering. Germany is interesting because it has a well-developed hosting ecosystem with some really big players. -- Simon. From fredr at geexology.org Sun Feb 6 10:49:06 2011 From: fredr at geexology.org (Fred Richards) Date: Sun, 6 Feb 2011 11:49:06 -0500 Subject: Top webhosters offering v6 too? In-Reply-To: References: <16975AA8-ABEB-402E-BA05-1BE51138A133@ecs.soton.ac.uk> Message-ID: I ran across this link a while back, it shows, of the top 100k websites (according to Alexa), which ones are IPv6 enabled: http://www.atoomnet.net/ipv6_enabled_popular_websites.php?complete_list=true On Sun, Feb 6, 2011 at 11:43 AM, Simon Leinen wrote: > Tim Chown writes: >> Which of the big boys are doing it? > > Google - although there don't call themselves a web hoster, they can be > used for hosting web sites using services such as Sites or App Engine. > Both support IPv6, either using the opt-in mechanism or by using an > alternate CNAME (ghs46 instead of ghs.google.com). ?That's what I use. > > None of the other large "cloud" providers seems to support IPv6 for > their users yet. ?In particular, neither Amazon's AWS not Microsoft > Azure have much visible activity in this direction. ?Rackspace have > announced IPv6 support for the first half of 2011. > > Concerning the more traditional webhosting offerings, I have no idea > about the "big boys". ?Here in Switzerland, a few smaller hosters > support IPv6. ?And I saw IPv6 mentioned in ads for some German server > hosting offering. ?Germany is interesting because it has a > well-developed hosting ecosystem with some really big players. > -- > Simon. > > -- ? ? ? ? ? ? ? ? ? ? ? Fred From joelja at bogus.com Sun Feb 6 11:15:09 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 06 Feb 2011 09:15:09 -0800 Subject: What's really needed is a routing slot market In-Reply-To: References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org> <4D4C0D25.70408@brightok.net> <20110204231134.3AA029B2B39@drugs.dv.isc.org> <4D4C8AF8.1030703@brightok.net> <20110205004517.371F99B3B3C@drugs.dv.isc.org> <4D4CA1B1.5060002@brightok.net> <20110205124710.059259B4E31@drugs.dv.isc.org> <4D4D5FFC.6020905@brightok.net> <20110206010145.9DCD99B60B9@drugs.dv.isc.org> <4D4DF75E.1040109@brightok.net> <20110206024051.D60349B6D50@drugs.dv.isc.org> Message-ID: <4D4ED71D.7020104@bogus.com> On 2/6/11 8:00 AM, John Curran wrote: > On Feb 5, 2011, at 9:40 PM, Mark Andrews wrote: > >> What's really needed is seperate the routing slot market from the >> address allocation market. > > Bingo! In fact, having an efficient market for obtaining routing of a > given prefix, combined with IPv6 vast identifier space, could actually > satisfy the primary goals that we hold for a long-term scalable address > architecture, and enable doing it in a highly distributed, automatable > fashion: So assuming this operates on a pollution model the victims of routing table bloat are compensated by the routing table pollutors for the use of the slots which they have to carry. so I take the marginal cost of the slots that I need subtract the royalities I recieve from the other participants and if I'm close to the mean number of slots per participant then it nets out to zero. Routing table growth continues but with some illusion of fairness and the cost of maintaining an elaborate system which no-one needs. Yay? > Aggregation would be encouraged, since use of non-aggregatable address > space would entail addition costs. These costs might be seen as minimal > for some organizations that desire addressing autonomy, but others might > decide treating their address space portable and routable results in > higher cost than is desired. Decisions about changing prefixes with > ISPs can be made based on a rational tradeoff of costs, rather than in > a thicket of ISP and registry policies. > > Conservation would actually be greatly improved, since address space > would only be sought after because of the need for additional unique > identifiers, rather than obtaining an address block of a given size > to warrant implied routability. In light of IPv6's vast address > space, it actually would be possible to provide minimally-sized but > assured unique prefixes automatically via nearly any mechanism (i.e. > let your local user or trade association be a registry if they want) > > With a significantly reduced policy framework, Registration could be > fully automated, with issuance being as simple as assurance the right > level of verification of requester identity (You might even get rid > of this, if you can assure that ISPs obtain clear identity of clients > before serving them but that would preclude any form of reputation > systems based on IP address prefix such as we have in use today...) > > Just think: the savings in storage costs alone (from the reduction in > address policy-related email on all our mailing lists) could probably > fund the system. :-) > > Oh well, one project at a time... > /John > > From cb.list6 at gmail.com Sun Feb 6 11:27:58 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Sun, 6 Feb 2011 09:27:58 -0800 Subject: Top webhosters offering v6 too? In-Reply-To: References: <16975AA8-ABEB-402E-BA05-1BE51138A133@ecs.soton.ac.uk> Message-ID: I have used both softlayer and arpnetworks. Both have v6 by default, but only softlayer can be considered a big boy... multiple sites. Cloud and dedicated servers ... softlayer is a class act with v6 added for free From jcurran at istaff.org Sun Feb 6 11:32:17 2011 From: jcurran at istaff.org (John Curran) Date: Sun, 6 Feb 2011 12:32:17 -0500 Subject: What's really needed is a routing slot market In-Reply-To: <4D4ED71D.7020104@bogus.com> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org> <4D4C0D25.70408@brightok.net> <20110204231134.3AA029B2B39@drugs.dv.isc.org> <4D4C8AF8.1030703@brightok.net> <20110205004517.371F99B3B3C@drugs.dv.isc.org> <4D4CA1B1.5060002@brightok.net> <20110205124710.059259B4E31@drugs.dv.isc.org> <4D4D5FFC.6020905@brightok.net> <20110206010145.9DCD99B60B9@drugs.dv.isc.org> <4D4DF75E.1040109@brightok.net> <20110206024051.D60349B6D50@drugs.dv.isc.org> <4D4ED71D.7020104@bogus.com> Message-ID: <83EF5AB0-741E-4FB2-A348-00477482A848@istaff.org> On Feb 6, 2011, at 12:15 PM, Joel Jaeggli wrote: > > So assuming this operates on a pollution model the victims of routing > table bloat are compensated by the routing table pollutors for the use > of the slots which they have to carry. so I take the marginal cost of > the slots that I need subtract the royalities I recieve from the other > participants and if I'm close to the mean number of slots per > participant then it nets out to zero. > > Routing table growth continues but with some illusion of fairness and > the cost of maintaining an elaborate system which no-one needs. One hopes that the costs of consuming routing table slots creates backpressure to discourage needless use, and that the royalities receive offset the costs of carrying any additional routing table slots. Note that our present system lacks both consistent backpressure on consumption of routing table slots and compensation for carrying additional routes. /John p.s. While I do believe there would be a net benefit, it also should be noted that there is no apparent way to transition to such a model in any case, i.e., it could have been done that way from the beginning, but a large scale economic reengineering effort at this point might be impossible. From lists at internetpolicyagency.com Sun Feb 6 11:45:46 2011 From: lists at internetpolicyagency.com (Roland Perry) Date: Sun, 6 Feb 2011 17:45:46 +0000 Subject: quietly.... In-Reply-To: <85D304BA-6C4E-4B86-9717-2ADB542B8606@delong.com> References: <16075456.4557.1296760302037.JavaMail.root@benjamin.baylink.com> <85D304BA-6C4E-4B86-9717-2ADB542B8606@delong.com> Message-ID: In article <85D304BA-6C4E-4B86-9717-2ADB542B8606 at delong.com>, Owen DeLong writes >> Part of the problem is knowing in advance what ISPs will and won't >>do. It's all very well saying one shouldn't patronise an ISP that >>blocks port 25, for example, but where is that documented before you buy? >> >If they don't document partial internet access blockage in the contract >and the contract says they are providing internet access, then, they >are in breach and you are free to depart without a termination fee and >in most cases, demand a refund for service to date. You may be right about enforcing that in the USA (is it an FCC thing?), but it won't fly in most other places. >Admittedly, I'm not over-fussed about email on my phone and I don't use >a tether device at this point. The 3G I'm discussing is a dongle intended for general access. >I mostly expect 3G and 4G networks to be broken internet anyway. I was >more speaking in terms of land-line providers. Apparently there are something like three times as many people with mobile phones in the world, as with Internet access. And a lot of network expansion is expected to be based on mobile connectivity as a result. -- Roland Perry From joelja at bogus.com Sun Feb 6 11:49:12 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 06 Feb 2011 09:49:12 -0800 Subject: What's really needed is a routing slot market In-Reply-To: <83EF5AB0-741E-4FB2-A348-00477482A848@istaff.org> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org> <4D4C0D25.70408@brightok.net> <20110204231134.3AA029B2B39@drugs.dv.isc.org> <4D4C8AF8.1030703@brightok.net> <20110205004517.371F99B3B3C@drugs.dv.isc.org> <4D4CA1B1.5060002@brightok.net> <20110205124710.059259B4E31@drugs.dv.isc.org> <4D4D5FFC.6020905@brightok.net> <20110206010145.9DCD99B60B9@drugs.dv.isc.org> <4D4DF75E.1040109@brightok.net> <20110206024051.D60349B6D50@drugs.dv.isc.org> <4D4ED71D.7020104@bogus.com> <83EF5AB0-741E-4FB2-A348-00477482A848@istaff.org> Message-ID: <4D4EDF18.3000207@bogus.com> On 2/6/11 9:32 AM, John Curran wrote: > One hopes that the costs of consuming routing table slots creates > backpressure to discourage needless use, and that the royalities > receive offset the costs of carrying any additional routing table > slots. > > Note that our present system lacks both consistent backpressure on > consumption of routing table slots and compensation for carrying > additional routes. The costs of carrying routes is unevenly distributed. when I have to carry 2 million routes in my fib on few hundred 120Gb/s line cards it's a bit different than someone with a software router who just has to make sure they have 4GB of ram... That has very attractive properties along some dimensions. e.g. the cost at the margin of connecting a new participant to the internet is rather low. From lists at internetpolicyagency.com Sun Feb 6 11:49:28 2011 From: lists at internetpolicyagency.com (Roland Perry) Date: Sun, 6 Feb 2011 17:49:28 +0000 Subject: quietly.... In-Reply-To: <20110205131510.BE13E9B5167@drugs.dv.isc.org> References: <16075456.4557.1296760302037.JavaMail.root@benjamin.baylink.com> <20110204225150.6FAC49B2854@drugs.dv.isc.org> <20110205131510.BE13E9B5167@drugs.dv.isc.org> Message-ID: <5iyXqtbo8tTNFAyd@perry.co.uk> In article <20110205131510.BE13E9B5167 at drugs.dv.isc.org>, Mark Andrews writes >> And when my vendor is Sipura, or Sony[1], how does an individual small >> enterprise attract their attention and get the features added? > >You return the equipment as not suitable for the advertised purpose >and demand your money back. Renumbering is expected to occur with >IPv6, part of renumbering is getting the name to address mappings >right. With DHCP the DHCP server normally does it. With SLAAC the >host has to do it as there is no other choice. > >Here in Australia it is Repair/Replace/Refund if the product purchased >is faulty. That applies to all products. If the milk is off when >we get home we go back and get it replaced and if the store is out >of stock we get a refund. I've returned and had replaced plenty >of stuff over the years. I think you are just confirming my view that moving from IPv4 to IPv6 will involve more than the ISP doing some magic that's transparent to the majority of users. And good luck returning a 3 year old PS/3 for a refund on the basis it doesn't support IPv6. -- Roland Perry From owen at delong.com Sun Feb 6 12:17:00 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 6 Feb 2011 10:17:00 -0800 Subject: quietly.... In-Reply-To: <5iyXqtbo8tTNFAyd@perry.co.uk> References: <16075456.4557.1296760302037.JavaMail.root@benjamin.baylink.com> <20110204225150.6FAC49B2854@drugs.dv.isc.org> <20110205131510.BE13E9B5167@drugs.dv.isc.org> <5iyXqtbo8tTNFAyd@perry.co.uk> Message-ID: On Feb 6, 2011, at 9:49 AM, Roland Perry wrote: > In article <20110205131510.BE13E9B5167 at drugs.dv.isc.org>, Mark Andrews writes >>> And when my vendor is Sipura, or Sony[1], how does an individual small >>> enterprise attract their attention and get the features added? >> >> You return the equipment as not suitable for the advertised purpose >> and demand your money back. Renumbering is expected to occur with >> IPv6, part of renumbering is getting the name to address mappings >> right. With DHCP the DHCP server normally does it. With SLAAC the >> host has to do it as there is no other choice. >> >> Here in Australia it is Repair/Replace/Refund if the product purchased >> is faulty. That applies to all products. If the milk is off when >> we get home we go back and get it replaced and if the store is out >> of stock we get a refund. I've returned and had replaced plenty >> of stuff over the years. > > I think you are just confirming my view that moving from IPv4 to IPv6 will involve more than the ISP doing some magic that's transparent to the majority of users. And good luck returning a 3 year old PS/3 for a refund on the basis it doesn't support IPv6. > -- > Roland Perry I'm pretty sure the PS3 will get resolved through a software update. Yes, there will be user-visible disruptions in this transition. No, it can't be 100% magic on the part of the service provider. It still has to happen. There is no viable alternative. Owen From owen at delong.com Sun Feb 6 12:15:49 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 6 Feb 2011 10:15:49 -0800 Subject: quietly.... In-Reply-To: References: <16075456.4557.1296760302037.JavaMail.root@benjamin.baylink.com> <85D304BA-6C4E-4B86-9717-2ADB542B8606@delong.com> Message-ID: <652B0A62-060F-4292-BE6D-164B44F2A841@delong.com> On Feb 6, 2011, at 9:45 AM, Roland Perry wrote: > In article <85D304BA-6C4E-4B86-9717-2ADB542B8606 at delong.com>, Owen DeLong writes > >>> Part of the problem is knowing in advance what ISPs will and won't do. It's all very well saying one shouldn't patronise an ISP that blocks port 25, for example, but where is that documented before you buy? >>> >> If they don't document partial internet access blockage in the contract and the contract says they are providing internet access, then, they are in breach and you are free to depart without a termination fee and in most cases, demand a refund for service to date. > > You may be right about enforcing that in the USA (is it an FCC thing?), but it won't fly in most other places. > It has worked for me so far in several countries. No, it's not an FCC thing, it's called "Truth in advertising" and/or Fraud. If you advertise a product as internet access, then, providing limited or partial access to the internet does not fulfill the terms of the contract unless you have the appropriate disclaimers. >> Admittedly, I'm not over-fussed about email on my phone and I don't use >> a tether device at this point. > > The 3G I'm discussing is a dongle intended for general access. > As I said, I don't use a tether device (the dongle would qualify as a tether device in my meaning). >> I mostly expect 3G and 4G networks to be broken internet anyway. I was more speaking in terms of land-line providers. > > Apparently there are something like three times as many people with mobile phones in the world, as with Internet access. And a lot of network expansion is expected to be based on mobile connectivity as a result. While this is true, for whatever unfortunate reasons, those users seem to expect and accept a certain level of brokenness in their internet access. When I looked into the mobile contracts I have (SPRINT 4G/EVDO service for my phone and AT&T 3G service on my iPad), it was pretty clear that they promised to provide whatever they felt like under whatever circumstances they chose and I was supposed to pay whether it works or not. Unfortunately, lacking viable alternatives, we live with that, but, at least in their case, the contract specifies that I accept brokenness as built in to their service models. Owen From jra at baylink.com Sun Feb 6 12:34:44 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 6 Feb 2011 13:34:44 -0500 (EST) Subject: quietly.... In-Reply-To: Message-ID: <23119638.5335.1297017284299.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > I'm pretty sure the PS3 will get resolved through a software update. > > Yes, there will be user-visible disruptions in this transition. > > No, it can't be 100% magic on the part of the service provider. > > It still has to happen. There is no viable alternative. There will be *lots* of user visible disruptions. And if you believe, as it appears you do from the integration of your messages on this thread, that anyone anywhere will be able through any legal theory to *force* Sony to make that older PS3 work on IPv6, then the term for your opinion, in *my* opinion, has changed from "optimistic" to "nutsabago". :-) >From up here at 30,000ft, the entire deployment of IPv6 has been cripplingly mismanaged, or we wouldn't be having all these conversations, still, now. Having had them 5 years ago would have been well more than good enough. And it will start to bite, hard, very shortly. Cheers, -- jra From mysidia at gmail.com Sun Feb 6 12:36:26 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 6 Feb 2011 12:36:26 -0600 Subject: What's really needed is a routing slot market In-Reply-To: <4D4ED71D.7020104@bogus.com> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org> <4D4C0D25.70408@brightok.net> <20110204231134.3AA029B2B39@drugs.dv.isc.org> <4D4C8AF8.1030703@brightok.net> <20110205004517.371F99B3B3C@drugs.dv.isc.org> <4D4CA1B1.5060002@brightok.net> <20110205124710.059259B4E31@drugs.dv.isc.org> <4D4D5FFC.6020905@brightok.net> <20110206010145.9DCD99B60B9@drugs.dv.isc.org> <4D4DF75E.1040109@brightok.net> <20110206024051.D60349B6D50@drugs.dv.isc.org> <4D4ED71D.7020104@bogus.com> Message-ID: On Sun, Feb 6, 2011 at 11:15 AM, Joel Jaeggli wrote: > So assuming this operates on a pollution model the victims of routing > table bloat are compensated by the routing table pollutors for the use > of the slots which they have to carry. so I take the marginal cost of In this case the "victims" are the other ASes, and the "pollutors" are the ASes that announce lots of blocks. However, the pollution is also something the "victims" need, so it's not really pollution at all, unless an excessive number of slots are used it's more "meat" than trash, the pollution model doesn't exactly make sense; the basic announced routes for connectivity are not like pollution. They are more like fertilizer... nutrients that are absolutely essential when utilized in appropriate quantities, but harmful in excessive quantity. And if too many use them in excessive quantity, then polluted runoff is released as a side-effect. There is an assumption that waste is so rampant, that a per-slot cost would lead to efficiency, and no loss of connectivity or stability, but there appears to be lack of data validating the suggestion. Private "routing slot markets" could be a huge can of worms... and we thought peering spats were bad. Some $BIG_DSL_PROVIDER is going to refuse to pay some $BIG_HOSTING_PROVIDER (or anyone else) for their routing slots, they will know that their size makes it too unpallatable for anyone else on the market to _not give them_ the slots, even if they are one of the larger polluters with numerous announcements. Other providers simply can't afford to be the provider whose customers can't reach $HIGHLY_POPULAR_WEB_SITE. If $BIG_HOSTING_PROVIDER's routers do not have $BIG_DSL_PROVIDER's routes, $BIG_HOSTING_PROVIDER's customers will scream, and jump ship for $other_hosting_provider that has $big_dsl_provider routability. There will be other $BIG_COMPANYs that as well have superior negotiating position, and noone else will be in a position to discard their routes, when they refuse to pay, or negotiate a price that reflects their superior position (rather than one reflecting cost of their excessive use of routing slots). So first of all... if there's a buying and selling of routing slots a "market". It cannot be a voluntary market, or it will simply lead to a chaotic situation where numerous big providers get free routes, and everyone else has to pay the big providers extortionate/disproportionately high fees because they _have to have those slots_ due to so many of their hosting customers requiring $big_provider connectivity. To ascertain a market in the first place... need to know.... How is the number of slots that will be on the market determined? Who gets to initialize the market; create and sell paid 'routing slots', and what will give them the power to enforce all users of routing slots buy from them... Are these one-time purchases... or do 'routing slot' purchases incur maintenance fees? How would the 'ownership' of a slot get verified, when a route is announced? How is it decided how much cost 'repayment' each AS gets? Who is going to make sure each AS fully populates their table with each routing slot they have been paid to fill and they do not populate any slots that were not purchased by the originator on the open market? The idea of 'ownership' of other people's things (slots on other people's routers) generally requires the AS owning those things to sell them. That would suggest each announcer of routes having to go to each AS and paying each AS a fee for slots on their routers --- not only would it be expensive, but the communication overhead required would be massive. So clearly any market would need to be centralized; transactions would need to happen through one entity. One buy/sell transaction for a routing slot on _all_ participating ASes. Seems like a tall order > the slots that I need subtract the royalities I recieve from the other > participants and if I'm close to the mean number of slots per > participant then it nets out to zero. -- -JH From caldcv at gmail.com Sun Feb 6 12:36:46 2011 From: caldcv at gmail.com (Chris) Date: Sun, 6 Feb 2011 13:36:46 -0500 Subject: Top webhosters offering v6 too? In-Reply-To: References: <16975AA8-ABEB-402E-BA05-1BE51138A133@ecs.soton.ac.uk> Message-ID: Many virtual private server companies (I have 2 BurstNET VPS servers in Scranton and Los Angeles) will give you a /64 of IPv6 addresses. This is always an option. From grobe0ba at gmail.com Sun Feb 6 12:40:53 2011 From: grobe0ba at gmail.com (Atticus) Date: Sun, 6 Feb 2011 13:40:53 -0500 Subject: 802.11g with WPA-PSK In-Reply-To: References: Message-ID: Im not familiar with wpa_supplicant, but you can preface external commands to execute in ifconfig.* with ! On Feb 6, 2011 1:08 PM, "Andrew Ball" wrote: Hello, I have a NetBSD host that I would like to connect to an existing wireless LAN using a rum(4) interface (Belkin F5D7050B USB 802.11g adaptor). I have tried configuring wpa_supplicant via rc.conf but it does not seem to start and I don't know why. Is there some other way to launch wpa_supplicant, perhaps via ifconfig.rum0? - Andy Ball From dredd at megacity.org Sun Feb 6 12:40:51 2011 From: dredd at megacity.org (Derek J. Balling) Date: Sun, 6 Feb 2011 13:40:51 -0500 Subject: quietly.... In-Reply-To: <652B0A62-060F-4292-BE6D-164B44F2A841@delong.com> References: <16075456.4557.1296760302037.JavaMail.root@benjamin.baylink.com> <85D304BA-6C4E-4B86-9717-2ADB542B8606@delong.com> <652B0A62-060F-4292-BE6D-164B44F2A841@delong.com> Message-ID: On Feb 6, 2011, at 1:15 PM, Owen DeLong wrote: > If you advertise a product as internet access, then, providing limited or partial access > to the internet does not fulfill the terms of the contract unless you have the appropriate > disclaimers. And in nearly every ISP's terms-of-service, which you agree to the terms and conditions of by becoming a customer, there's invariably clauses in there that give them all sorts of rights to filter traffic at their discretion, etc., etc. D From owen at delong.com Sun Feb 6 12:43:18 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 6 Feb 2011 10:43:18 -0800 Subject: quietly.... In-Reply-To: <23119638.5335.1297017284299.JavaMail.root@benjamin.baylink.com> References: <23119638.5335.1297017284299.JavaMail.root@benjamin.baylink.com> Message-ID: On Feb 6, 2011, at 10:34 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Owen DeLong" > >> I'm pretty sure the PS3 will get resolved through a software update. >> >> Yes, there will be user-visible disruptions in this transition. >> >> No, it can't be 100% magic on the part of the service provider. >> >> It still has to happen. There is no viable alternative. > > There will be *lots* of user visible disruptions. And if you believe, > as it appears you do from the integration of your messages on this thread, > that anyone anywhere will be able through any legal theory to *force* Sony > to make that older PS3 work on IPv6, then the term for your opinion, in *my* > opinion, has changed from "optimistic" to "nutsabago". :-) > No. I believe I can force through legal choices hotel providers to refund my internet access charges if they block certain ports. I've done so. I believe that Sony will offer IPv6 software upgrades for the PS-3 because they will eventually realize that failing to do so is bad for future sales. >> From up here at 30,000ft, the entire deployment of IPv6 has been cripplingly > mismanaged, or we wouldn't be having all these conversations, still, now. > Having had them 5 years ago would have been well more than good enough. > And it will start to bite, hard, very shortly. > An interesting perspective. The problem with that theory is that nobody actually manages the internet. It is a collection of independently managed networks that happen to coordinate, cooperate, and collaborate on a limited basis to make certain things work. I agree with you that many organizations and individuals could have acted differently to achieve a more optimal transition. However, they didn't and we are where we are. As a result, I think it is far more productive to move forward and make the transition as quickly and effectively as possible than to dwell on claims of "mismanagement" which lack both a meaningful target and any form of useful resolution. Owen From bzs at world.std.com Sun Feb 6 12:47:00 2011 From: bzs at world.std.com (Barry Shein) Date: Sun, 6 Feb 2011 13:47:00 -0500 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <4D4E0361.3060505@dcrocker.net> References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> <96503CEA-C922-47A6-9691-FCF157DF15D5@internode.com.au> <10A940BA-6D90-4663-B942-5FFF2CB49D7A@internode.com.au> <4D4BAD13.9090301@gmail.com> <88BC6885D33A9D42A1CCB45E8749525E013CBC58@pigeon.sandiego.nextlevelinternet.com> <72609B8A-05D2-4039-85C4-A0578B9E6911@cisco.com> <4D4E0361.3060505@dcrocker.net> Message-ID: <19790.60580.225216.4089@world.std.com> On February 5, 2011 at 18:11 dhc2 at dcrocker.net (Dave CROCKER) wrote: > > > On 2/5/2011 6:43 AM, Fred Baker wrote: > > On Feb 4, 2011, at 9:49 PM, Hayden Katzenellenbogen wrote: > >> Not sure if it has been said already but wasn't one of the key point for > >> the creation of the internet to create and infrastructure that would > >> survive in the case of all out war and massive destruction. (strategic > >> nuclear strikes) > > > > Urban legend, although widely believed. Someone probably made the observation. > > > Maybe not quite an UL... > > > > On the average, The Rand Corp is extremely careful about what it publishes, yet > here it is, repeating the claim. I agree with Dave, I think this idea that it's an urban legend has now become an urban legend. If you focus it down very sharply like this: DARPA specified (or, perhaps, the project was sold to DARPA with a promise...) that the network being designed in the late 1960s should be resistant to a nuclear attack. That's probably an urban legend, who knows, it's probably not all that interesting. But was it observed over and over from the early on that a packet network, versus the then predominant technology of virtual (or even real) circuit networks, would be resistant to damage of all sorts? Yes. Another early motivation which isn't often mentioned in these discussions was the sharing of supercomputer resources. Supercomputers generally cost tens of millions of dollars back then, approaching $100 million if you took the infrastructure into account. I worked on a $100M supercomputer proposal as it evolved into 50 tons of chilled water on the roof to shoring up the roof to hold that much water, to running a private gigawatt power line from the local utility thru Boston...etc. And the sort of people who needed access to those supercomputers were spread across the country (and world of course.) It was becoming a matter of whether to move the researchers, not very practical (how many finite element analysis experts do you really need at one university?), or buy each of them a supercomputer (kind of expensive), or try to hook them up remotely. At first dial-up seemed plausible but data visualization, graphical access, became more and more important even in the late 1970s and early 80s. Researchers were shipping large cartons of magtape so they could use local computers to generate graphical results of their computations. It was unwieldy to be kind. The internet was a good answer to that problem, and that vision of "high-speed" (for the era) remote access certainly factored into proposals such as the JVNC-era proposals, NSFnet, etc. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From dhc2 at dcrocker.net Sun Feb 6 13:09:05 2011 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Sun, 06 Feb 2011 11:09:05 -0800 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <19790.60580.225216.4089@world.std.com> References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> <96503CEA-C922-47A6-9691-FCF157DF15D5@internode.com.au> <10A940BA-6D90-4663-B942-5FFF2CB49D7A@internode.com.au> <4D4BAD13.9090301@gmail.com> <88BC6885D33A9D42A1CCB45E8749525E013CBC58@pigeon.sandiego.nextlevelinternet.com> <72609B8A-05D2-4039-85C4-A0578B9E6911@cisco.com> <4D4E0361.3060505@dcrocker.net> <19790.60580.225216.4089@world.std.com> Message-ID: <4D4EF1D1.7050708@dcrocker.net> On 2/6/2011 10:47 AM, Barry Shein wrote: > If you focus it down very sharply like this: > > DARPA specified (or, perhaps, the project was sold to DARPA with > a promise...) that the network being designed in the late 1960s > should be resistant to a nuclear attack. > > That's probably an urban legend, who knows, it's probably not all that > interesting. > > But was it observed over and over from the early on that a packet > network, versus the then predominant technology of virtual (or even > real) circuit networks, would be resistant to damage of all sorts? > > Yes. Sorry, but I think the technical implications of a goal to survive 'hostile battlefield conditions' versus 'nuclear attack' are (small pun) massively different. Hence I think the actual language used matters. And the fact that the common language around the net during the '70s was the former and not the latter matters. Which is why it would be helpful to get some credible documentation about use of the latter. I'd expect the major difference in the two terms is the scale of the outage. A few square miles, versus possibly thousands. To that end, I remember an anecdote about van Jacobson from the 1989 quake in California that might provide some insight about a large-scale outage:[1] He was living in Berkeley but was visiting Stanford when the quake hit and he wanted to check that his girlfriend was safe. Of course, the phone didn't work.[2] Out of sheer frustration and the need to do /something/ he sent her an email. He got a response within a few minutes. Surprised that the net was still working (and working quite well), he did a traceroute from the Stanford system to the one his girlfriend was using.[3] Not surprisingly, the path did not cross the San Francisco Bay, as it normally would have. Instead it went down to Los Angeles, across the southern US, up the East Coast and back across the Northern U.S. Although the outage was fairly small-scale, the scale of the re-routing suggests that a larger, 'regional' outage from something like a nuclear event would adapt readily. (We can ignore the additional question of EMP effects, since that only affects the scale of the outage.) And, of course, there have been other test cases since then... d/ [1] This is anecdotal; I've never confirmed the story with him. [2] That does not automatically indicate a system failure, given the switch to an emergency mode for the phone system that restricts access during major events like these. [3] Van created traceroute. -- Dave Crocker Brandenburg InternetWorking bbiw.net From henry at AegisInfoSys.com Sun Feb 6 13:11:47 2011 From: henry at AegisInfoSys.com (Henry Yen) Date: Sun, 6 Feb 2011 14:11:47 -0500 Subject: quietly.... In-Reply-To: References: <23119638.5335.1297017284299.JavaMail.root@benjamin.baylink.com> Message-ID: <20110206191147.GI16405@nntp.AegisInfoSys.com> On Sun, Feb 06, 2011 at 10:43:18AM -0800, Owen DeLong wrote: > I believe that Sony will offer IPv6 software upgrades for the PS-3 because > they will eventually realize that failing to do so is bad for future sales. Sony appears quite willing to file eye-openingly broad discovery requests in its OtherOS/geohotz lawsuit(s). Related, but separate, Sony appears to be unconcerned with the removal of OtherOS in the first place, a documented feature and selling point that's made some people unhappy (e.g. USAF). And Sony appears completely unconcerned about the Sony RootKit fiasco ("Most people, I think, don't even know what a Rootkit is, so why should they care about it?"). Technical impediments (lack of ipV6) in their product(s) do not necessarily correlate with what they think of future sales prospects. -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York (800) 234-4700 From jcurran at arin.net Sun Feb 6 13:13:13 2011 From: jcurran at arin.net (John Curran) Date: Sun, 6 Feb 2011 19:13:13 +0000 Subject: Seeking IPv6 services (was: Random Port Blocking at Hotels) In-Reply-To: References: <20110205150005.40621.qmail@joyce.lan> <20110206011404.A19A99B625C@drugs.dv.isc.org> Message-ID: <46129691-C276-4ED8-9794-F1AF89384395@corp.arin.net> On Feb 5, 2011, at 9:06 PM, John R. Levine wrote: > Sure. Bet you ten bucks that no hotel in North America offers IPv6 this year in the wifi they provide to customers. (Conference networks don't count.) That could easily be the case this year... However, it's not going to stay that way for long, particularly if corporate buyers specify IPv6 in their RFPs for hotel room blocks. As of January 1st, 2012, ARIN considers IPv4 and IPv6 both necessary for something to be "available via the Internet" per our procurement policy, and we're in the process of informing our service providers (including such things as hotels, payroll and benefit services with web portals, vendors with online support, etc) of that requirement. Note - we're not going to let lack of IPv6 in hotel rooms prevent us from holding a Public Policy Meeting, but making it clear that we'll prefer compliant vendors if there's a viable choice has a real effect on getting attention to the requirement by those in charge. I'm certain that others folks out there also buy things, but I'm only in charge of ARIN. FWIW, /John John Curran President and CEO ARIN From drc at virtualized.org Sun Feb 6 13:16:09 2011 From: drc at virtualized.org (David Conrad) Date: Sun, 6 Feb 2011 09:16:09 -1000 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <585A8651-6C2E-4B16-9D03-6C756CC9E77D@arin.net> References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <20110205193328.GC22325@vacation.karoshi.com> <08F8827D-D8C3-4922-AC39-6C71ADBE8BDB@corp.arin.net> <20110206014014.GG22325@vacation.karoshi.com> <849FDB3F-EE29-48D6-8ECD-70AE6EB0B157@virtualized.org> <585A8651-6C2E-4B16-9D03-6C756CC9E77D@arin.net> Message-ID: <57B939FE-3B74-4B70-8AD5-71176551C2BF@virtualized.org> John, On Feb 5, 2011, at 8:47 PM, John Curran wrote: > On Feb 6, 2011, at 1:25 AM, David Conrad wrote: >> Last I checked, the other four authors of RFC 2050 are still alive. Why not ask them? > Bill indicated he "was there when it was written" in reference to Jon being an > author, and I was inquiring to whether he had any knowledge of Jon's intent that > he could share. If you have knowledge of Jon's intent, or any insight on why RFC > 2050 includes the existing allocations if the intent was actually to leave it vague > with respect to same, that also would be helpful. As you're aware, RFC 2050 was a group effort, so focusing on Jon's intent seems questionable particularly given he sadly isn't around to provide corrections. My recollection is that all of the authors recognized that attempting to deal with what is now known as legacy space was _extremely_ controversial and was wildly unlikely to have reached any consensus, particularly in the context of how the IETF works and the then ongoing battles regarding CIDR deployment and its implications. Instead, we consciously focused on merely trying to document the then current practice for allocations and assignments. Even that turned out to be a prolonged nightmare, especially trying to get it through the IESG (which discouraged further attempts at trying to use the IETF to derive addressing policy). In other words, since RFC 2050 merely attempted to document then current practices, it intentionally did not address (pun intended) allocations made prior to the establishment of those practices directly. Rather, it merely noted that future allocations or assignments would take existing holdings into account. With regards to specific language, you reference section 2.1.1. You'll note that this is in a section talking about guidelines for how ISPs should deal with address space. It is saying ISPs should treat assignments to their customers like loans. Section 2.1.3 is talking about two different things as indicated by the terminology used. The "future _allocations_ may be impacted" is talking about allocations made from the RIR to the ISP. The "existing _loans_ may be impacted" is saying the RIR could ignore assignments the ISP has made to its customers (making it a bit difficult for the ISP to get new space). >>> Further, RFC 2050 states "The transfer of IP addresses from one party to another >>> must be approved by the regional registries. The party trying to obtain the IP >>> address must meet the same criteria as if they were requesting an IP address >>> directly from the IR." >> >> I'm curious: when HP acquired the assets of Compaq (or when Compaq acquired the assets of Digital), is it your position that HP (or Compaq) "met the same criteria as if they were requesting an IP address directly from the IR." for 16.0.0.0/8? > > The handling of general case varies based on the community developed > policy over the years, [...] but will note that at one > time the M&A transfer policy allowed transfer of all held number resources > without justification of need as long as the entire entity was involved, > but at this point the policy indicates that [....] So, if you believe ARIN policy applies to all space, you're saying that ARIN at one time violated the section of RFC 2050 you quoted and that later, ARIN changed that policy. This sort of policy evolution is exactly what was envisioned when we wrote RFC 2050. We assumed policies would change over time, and as such RFC 2050 was merely documenting the current practice as it was in 1996. This is why I always find your referencing 2050 as if it is sacred text curious. In thinking about this, since RFC 2050 was focused on IPv4 allocation policy and there is no more IPv4 to allocate, 2050 should probably be moved to historic. Regards, -drc From adrian at creative.net.au Sun Feb 6 13:22:24 2011 From: adrian at creative.net.au (Adrian Chadd) Date: Mon, 7 Feb 2011 03:22:24 +0800 Subject: 802.11g with WPA-PSK In-Reply-To: References: Message-ID: <20110206192224.GJ807@skywalker.creative.net.au> if it's running a recent net80211 stack, you'll need to create a vap sttion interface first eg, ifconfig wlan0 create wlandev rum0 then do stuff to wlan0, not rum0. Adrian On Sun, Feb 06, 2011, Atticus wrote: > Im not familiar with wpa_supplicant, but you can preface external commands > to execute in ifconfig.* with ! > > On Feb 6, 2011 1:08 PM, "Andrew Ball" > wrote: > > Hello, > > I have a NetBSD host that I would like to > connect to an existing wireless LAN using a rum(4) interface > (Belkin F5D7050B USB 802.11g adaptor). I have tried > configuring wpa_supplicant via rc.conf but it does not seem > to start and I don't know why. Is there some other way to > launch wpa_supplicant, perhaps via ifconfig.rum0? > > - Andy Ball -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA - From rudi.daniel at gmail.com Sun Feb 6 13:28:28 2011 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Sun, 6 Feb 2011 15:28:28 -0400 Subject: NANOG Digest, Vol 37, Issue 93 In-Reply-To: References: Message-ID: Is anyone on this list aware of any IPv6 ready networks in the English speaking caribbean? Rudi Daniel On Sun, Feb 6, 2011 at 2:19 PM, wrote: > Send NANOG mailing list submissions to > nanog at nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request at nanog.org > > You can reach the person managing the list at > nanog-owner at nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. Re: quietly.... (Owen DeLong) > 2. Re: Top webhosters offering v6 too? (Simon Leinen) > 3. Re: Top webhosters offering v6 too? (Fred Richards) > 4. Re: What's really needed is a routing slot market (Joel Jaeggli) > 5. Re: Top webhosters offering v6 too? (Cameron Byrne) > 6. Re: What's really needed is a routing slot market (John Curran) > 7. Re: quietly.... (Roland Perry) > 8. Re: What's really needed is a routing slot market (Joel Jaeggli) > 9. Re: quietly.... (Roland Perry) > 10. Re: quietly.... (Owen DeLong) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 6 Feb 2011 08:22:55 -0800 > From: Owen DeLong > Subject: Re: quietly.... > To: "Lee Howard" > Cc: nanog at nanog.org > Message-ID: > Content-Type: text/plain; charset=us-ascii > > > > > Firewalls merely constrict it. Not that I advocate against the use of > > firewalls; > > in fact, I think I'm agreeing with you, and extending the argument a > little > > further, > > that we should move from NAT to firewalls, then from stateful firewalls > to > > secure hosts and network security appliances. > > > > Lee > > > > > I would be fine with that. However, in terms of the art of the possible > with the tools available today, IPv6 has no need of NAT, but, firewalls > cannot yet be safely removed from the equation. > > Owen > > > > > ------------------------------ > > Message: 2 > Date: Sun, 06 Feb 2011 17:43:04 +0100 > From: Simon Leinen > Subject: Re: Top webhosters offering v6 too? > To: Tim Chown > Cc: NANOG list > Message-ID: > Content-Type: text/plain; charset=us-ascii > > Tim Chown writes: > > Which of the big boys are doing it? > > Google - although there don't call themselves a web hoster, they can be > used for hosting web sites using services such as Sites or App Engine. > Both support IPv6, either using the opt-in mechanism or by using an > alternate CNAME (ghs46 instead of ghs.google.com). That's what I use. > > None of the other large "cloud" providers seems to support IPv6 for > their users yet. In particular, neither Amazon's AWS not Microsoft > Azure have much visible activity in this direction. Rackspace have > announced IPv6 support for the first half of 2011. > > Concerning the more traditional webhosting offerings, I have no idea > about the "big boys". Here in Switzerland, a few smaller hosters > support IPv6. And I saw IPv6 mentioned in ads for some German server > hosting offering. Germany is interesting because it has a > well-developed hosting ecosystem with some really big players. > -- > Simon. > > > > ------------------------------ > > Message: 3 > Date: Sun, 6 Feb 2011 11:49:06 -0500 > From: Fred Richards > Subject: Re: Top webhosters offering v6 too? > To: NANOG list > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > I ran across this link a while back, it shows, of the top 100k > websites (according to Alexa), which ones are IPv6 enabled: > > > http://www.atoomnet.net/ipv6_enabled_popular_websites.php?complete_list=true > > > > On Sun, Feb 6, 2011 at 11:43 AM, Simon Leinen > wrote: > > Tim Chown writes: > >> Which of the big boys are doing it? > > > > Google - although there don't call themselves a web hoster, they can be > > used for hosting web sites using services such as Sites or App Engine. > > Both support IPv6, either using the opt-in mechanism or by using an > > alternate CNAME (ghs46 instead of ghs.google.com). ?That's what I use. > > > > None of the other large "cloud" providers seems to support IPv6 for > > their users yet. ?In particular, neither Amazon's AWS not Microsoft > > Azure have much visible activity in this direction. ?Rackspace have > > announced IPv6 support for the first half of 2011. > > > > Concerning the more traditional webhosting offerings, I have no idea > > about the "big boys". ?Here in Switzerland, a few smaller hosters > > support IPv6. ?And I saw IPv6 mentioned in ads for some German server > > hosting offering. ?Germany is interesting because it has a > > well-developed hosting ecosystem with some really big players. > > -- > > Simon. > > > > > > > > -- > ? ? ? ? ? ? ? ? ? ? ? Fred > > > > ------------------------------ > > Message: 4 > Date: Sun, 06 Feb 2011 09:15:09 -0800 > From: Joel Jaeggli > Subject: Re: What's really needed is a routing slot market > To: John Curran > Cc: NANOG list > Message-ID: <4D4ED71D.7020104 at bogus.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On 2/6/11 8:00 AM, John Curran wrote: > > On Feb 5, 2011, at 9:40 PM, Mark Andrews wrote: > > > >> What's really needed is seperate the routing slot market from the > >> address allocation market. > > > > Bingo! In fact, having an efficient market for obtaining routing of a > > given prefix, combined with IPv6 vast identifier space, could actually > > satisfy the primary goals that we hold for a long-term scalable address > > architecture, and enable doing it in a highly distributed, automatable > > fashion: > > So assuming this operates on a pollution model the victims of routing > table bloat are compensated by the routing table pollutors for the use > of the slots which they have to carry. so I take the marginal cost of > the slots that I need subtract the royalities I recieve from the other > participants and if I'm close to the mean number of slots per > participant then it nets out to zero. > > Routing table growth continues but with some illusion of fairness and > the cost of maintaining an elaborate system which no-one needs. > > Yay? > > > > Aggregation would be encouraged, since use of non-aggregatable address > > space would entail addition costs. These costs might be seen as minimal > > for some organizations that desire addressing autonomy, but others might > > decide treating their address space portable and routable results in > > higher cost than is desired. Decisions about changing prefixes with > > ISPs can be made based on a rational tradeoff of costs, rather than in > > a thicket of ISP and registry policies. > > > > Conservation would actually be greatly improved, since address space > > would only be sought after because of the need for additional unique > > identifiers, rather than obtaining an address block of a given size > > to warrant implied routability. In light of IPv6's vast address > > space, it actually would be possible to provide minimally-sized but > > assured unique prefixes automatically via nearly any mechanism (i.e. > > let your local user or trade association be a registry if they want) > > > > With a significantly reduced policy framework, Registration could be > > fully automated, with issuance being as simple as assurance the right > > level of verification of requester identity (You might even get rid > > of this, if you can assure that ISPs obtain clear identity of clients > > before serving them but that would preclude any form of reputation > > systems based on IP address prefix such as we have in use today...) > > > > Just think: the savings in storage costs alone (from the reduction in > > address policy-related email on all our mailing lists) could probably > > fund the system. :-) > > > > Oh well, one project at a time... > > /John > > > > > > > > > ------------------------------ > > Message: 5 > Date: Sun, 6 Feb 2011 09:27:58 -0800 > From: Cameron Byrne > Subject: Re: Top webhosters offering v6 too? > To: fredr at geexology.org > Cc: NANOG list > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > I have used both softlayer and arpnetworks. Both have v6 by default, but > only softlayer can be considered a big boy... multiple sites. Cloud and > dedicated servers ... softlayer is a class act with v6 added for free > > > ------------------------------ > > Message: 6 > Date: Sun, 6 Feb 2011 12:32:17 -0500 > From: John Curran > Subject: Re: What's really needed is a routing slot market > To: Joel Jaeggli > Cc: NANOG list > Message-ID: <83EF5AB0-741E-4FB2-A348-00477482A848 at istaff.org> > Content-Type: text/plain; charset=us-ascii > > On Feb 6, 2011, at 12:15 PM, Joel Jaeggli wrote: > > > > So assuming this operates on a pollution model the victims of routing > > table bloat are compensated by the routing table pollutors for the use > > of the slots which they have to carry. so I take the marginal cost of > > the slots that I need subtract the royalities I recieve from the other > > participants and if I'm close to the mean number of slots per > > participant then it nets out to zero. > > > > Routing table growth continues but with some illusion of fairness and > > the cost of maintaining an elaborate system which no-one needs. > > One hopes that the costs of consuming routing table slots creates > backpressure to discourage needless use, and that the royalities > receive offset the costs of carrying any additional routing table > slots. > > Note that our present system lacks both consistent backpressure on > consumption of routing table slots and compensation for carrying > additional routes. > > /John > > p.s. While I do believe there would be a net benefit, it also > should be noted that there is no apparent way to transition > to such a model in any case, i.e., it could have been done > that way from the beginning, but a large scale economic > reengineering effort at this point might be impossible. > > > > ------------------------------ > > Message: 7 > Date: Sun, 6 Feb 2011 17:45:46 +0000 > From: Roland Perry > Subject: Re: quietly.... > To: nanog at nanog.org > Message-ID: > Content-Type: text/plain;charset=us-ascii;format=flowed > > In article <85D304BA-6C4E-4B86-9717-2ADB542B8606 at delong.com>, Owen > DeLong writes > > >> Part of the problem is knowing in advance what ISPs will and won't > >>do. It's all very well saying one shouldn't patronise an ISP that > >>blocks port 25, for example, but where is that documented before you buy? > >> > >If they don't document partial internet access blockage in the contract > >and the contract says they are providing internet access, then, they > >are in breach and you are free to depart without a termination fee and > >in most cases, demand a refund for service to date. > > You may be right about enforcing that in the USA (is it an FCC thing?), > but it won't fly in most other places. > > >Admittedly, I'm not over-fussed about email on my phone and I don't use > >a tether device at this point. > > The 3G I'm discussing is a dongle intended for general access. > > >I mostly expect 3G and 4G networks to be broken internet anyway. I was > >more speaking in terms of land-line providers. > > Apparently there are something like three times as many people with > mobile phones in the world, as with Internet access. And a lot of > network expansion is expected to be based on mobile connectivity as a > result. > -- > Roland Perry > > > > ------------------------------ > > Message: 8 > Date: Sun, 06 Feb 2011 09:49:12 -0800 > From: Joel Jaeggli > Subject: Re: What's really needed is a routing slot market > To: John Curran > Cc: NANOG list > Message-ID: <4D4EDF18.3000207 at bogus.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On 2/6/11 9:32 AM, John Curran wrote: > > One hopes that the costs of consuming routing table slots creates > > backpressure to discourage needless use, and that the royalities > > receive offset the costs of carrying any additional routing table > > slots. > > > > Note that our present system lacks both consistent backpressure on > > consumption of routing table slots and compensation for carrying > > additional routes. > > The costs of carrying routes is unevenly distributed. when I have to > carry 2 million routes in my fib on few hundred 120Gb/s line cards it's > a bit different than someone with a software router who just has to make > sure they have 4GB of ram... > > That has very attractive properties along some dimensions. e.g. the cost > at the margin of connecting a new participant to the internet is rather > low. > > > > > ------------------------------ > > Message: 9 > Date: Sun, 6 Feb 2011 17:49:28 +0000 > From: Roland Perry > Subject: Re: quietly.... > To: nanog at nanog.org > Message-ID: <5iyXqtbo8tTNFAyd at perry.co.uk> > Content-Type: text/plain;charset=us-ascii;format=flowed > > In article <20110205131510.BE13E9B5167 at drugs.dv.isc.org>, Mark Andrews > writes > >> And when my vendor is Sipura, or Sony[1], how does an individual small > >> enterprise attract their attention and get the features added? > > > >You return the equipment as not suitable for the advertised purpose > >and demand your money back. Renumbering is expected to occur with > >IPv6, part of renumbering is getting the name to address mappings > >right. With DHCP the DHCP server normally does it. With SLAAC the > >host has to do it as there is no other choice. > > > >Here in Australia it is Repair/Replace/Refund if the product purchased > >is faulty. That applies to all products. If the milk is off when > >we get home we go back and get it replaced and if the store is out > >of stock we get a refund. I've returned and had replaced plenty > >of stuff over the years. > > I think you are just confirming my view that moving from IPv4 to IPv6 > will involve more than the ISP doing some magic that's transparent to > the majority of users. And good luck returning a 3 year old PS/3 for a > refund on the basis it doesn't support IPv6. > -- > Roland Perry > > > > ------------------------------ > > Message: 10 > Date: Sun, 6 Feb 2011 10:17:00 -0800 > From: Owen DeLong > Subject: Re: quietly.... > To: Roland Perry > Cc: nanog at nanog.org > Message-ID: > Content-Type: text/plain; charset=us-ascii > > > On Feb 6, 2011, at 9:49 AM, Roland Perry wrote: > > > In article <20110205131510.BE13E9B5167 at drugs.dv.isc.org>, Mark Andrews < > marka at isc.org> writes > >>> And when my vendor is Sipura, or Sony[1], how does an individual small > >>> enterprise attract their attention and get the features added? > >> > >> You return the equipment as not suitable for the advertised purpose > >> and demand your money back. Renumbering is expected to occur with > >> IPv6, part of renumbering is getting the name to address mappings > >> right. With DHCP the DHCP server normally does it. With SLAAC the > >> host has to do it as there is no other choice. > >> > >> Here in Australia it is Repair/Replace/Refund if the product purchased > >> is faulty. That applies to all products. If the milk is off when > >> we get home we go back and get it replaced and if the store is out > >> of stock we get a refund. I've returned and had replaced plenty > >> of stuff over the years. > > > > I think you are just confirming my view that moving from IPv4 to IPv6 > will involve more than the ISP doing some magic that's transparent to the > majority of users. And good luck returning a 3 year old PS/3 for a refund on > the basis it doesn't support IPv6. > > -- > > Roland Perry > > I'm pretty sure the PS3 will get resolved through a software update. > > Yes, there will be user-visible disruptions in this transition. > > No, it can't be 100% magic on the part of the service provider. > > It still has to happen. There is no viable alternative. > > Owen > > > > > ------------------------------ > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog > > End of NANOG Digest, Vol 37, Issue 93 > ************************************* > -- Rudi Daniel *danielcharles consulting **1-784 498 8277 * * * From owen at delong.com Sun Feb 6 13:28:28 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 6 Feb 2011 11:28:28 -0800 Subject: quietly.... In-Reply-To: <20110206191147.GI16405@nntp.AegisInfoSys.com> References: <23119638.5335.1297017284299.JavaMail.root@benjamin.baylink.com> <20110206191147.GI16405@nntp.AegisInfoSys.com> Message-ID: <00AEBEFA-7381-4C41-A909-11AC77107A57@delong.com> On Feb 6, 2011, at 11:11 AM, Henry Yen wrote: > On Sun, Feb 06, 2011 at 10:43:18AM -0800, Owen DeLong wrote: >> I believe that Sony will offer IPv6 software upgrades for the PS-3 because >> they will eventually realize that failing to do so is bad for future sales. > > Sony appears quite willing to file eye-openingly broad discovery requests > in its OtherOS/geohotz lawsuit(s). Related, but separate, Sony appears > to be unconcerned with the removal of OtherOS in the first place, a > documented feature and selling point that's made some people unhappy > (e.g. USAF). And Sony appears completely unconcerned about the Sony RootKit > fiasco ("Most people, I think, don't even know what a Rootkit is, so why > should they care about it?"). > > Technical impediments (lack of ipV6) in their product(s) do not necessarily > correlate with what they think of future sales prospects. > While Sony is, indeed, showing surprising market ignorance and bad judgment at the moment, I think that the market will eventually teach them a lesson in these regards. Time will tell. Owen From cmadams at hiwaay.net Sun Feb 6 13:48:28 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Sun, 6 Feb 2011 13:48:28 -0600 Subject: quietly.... In-Reply-To: <20110206191147.GI16405@nntp.AegisInfoSys.com> References: <23119638.5335.1297017284299.JavaMail.root@benjamin.baylink.com> <20110206191147.GI16405@nntp.AegisInfoSys.com> Message-ID: <20110206194828.GB25911@hiwaay.net> Once upon a time, Henry Yen said: > On Sun, Feb 06, 2011 at 10:43:18AM -0800, Owen DeLong wrote: > > I believe that Sony will offer IPv6 software upgrades for the PS-3 because > > they will eventually realize that failing to do so is bad for future sales. > > Technical impediments (lack of ipV6) in their product(s) do not necessarily > correlate with what they think of future sales prospects. Also, lack of functionality in the current generation can be seen by management as _good_ for future sales (of the PS4, the Xbox 720, WiiToo, etc.). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jcurran at arin.net Sun Feb 6 13:53:17 2011 From: jcurran at arin.net (John Curran) Date: Sun, 6 Feb 2011 19:53:17 +0000 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <57B939FE-3B74-4B70-8AD5-71176551C2BF@virtualized.org> References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <20110205193328.GC22325@vacation.karoshi.com> <08F8827D-D8C3-4922-AC39-6C71ADBE8BDB@corp.arin.net> <20110206014014.GG22325@vacation.karoshi.com> <849FDB3F-EE29-48D6-8ECD-70AE6EB0B157@virtualized.org> <585A8651-6C2E-4B16-9D03-6C756CC9E77D@arin.net> <57B939FE-3B74-4B70-8AD5-71176551C2BF@virtualized.org> Message-ID: <302202D5-A0C2-4BD9-B08B-A376A3174926@arin.net> On Feb 6, 2011, at 2:16 PM, David Conrad wrote: > > As you're aware, RFC 2050 was a group effort, so focusing on Jon's intent seems questionable particularly given he sadly isn't around to provide corrections. While it may have been a group effort, Jon was the IANA. > With regards to specific language, you reference section 2.1.1. You'll note that this is in a section talking about guidelines for how ISPs should deal with address space. It is saying ISPs should treat assignments to their customers like loans. Section 2.1.3 is talking about two different things as indicated by the terminology used. The "future _allocations_ may be impacted" is talking about allocations made from the RIR to the ISP. The "existing _loans_ may be impacted" is saying the RIR could ignore assignments the ISP has made to its customers (making it a bit difficult for the ISP to get new space). Interesting viewpoint in separating the two, as the full context is: "If the information is not available, future allocations may be impacted. In extreme cases, existing loans may be impacted." Your suggestion that "existing loans may be impacted" means to be ignored for evaluating future allocations does seems a bit superfluous when taken in full context, but obviously must be considered as you are one of the authors. One wonders why it just doesn't repeat "future allocations may be impacted" for the second sentence. Do you have any similar suggestions for how to reinterpret the transfer section, i.e. " The transfer of IP addresses from one party to another must be approved by the regional registries." or "The party trying to obtain the IP address must meet the same criteria as if they were requesting an IP address directly from the IR." ? > So, if you believe ARIN policy applies to all space, you're saying that ARIN at one time violated the section of RFC 2050 you quoted and that later, ARIN changed that policy. This sort of policy evolution is exactly what was envisioned when we wrote RFC 2050. We assumed policies would change over time, and as such RFC 2050 was merely documenting the current practice as it was in 1996. This is why I always find your referencing 2050 as if it is sacred text curious. It's fairly difficult to have a consistent global registry framework that the regional registries operate under unless its actually followed by the regional registries. What would have been best would have been to separate the document into two; one for the overall Internet Registry requirements technically necessary, and then one with the current view on appropriate allocation policy. I wasn't there, so I can't say why the two are combined. In the particular instance you point out, I'm happy to say ARIN is back in alignment with RFC 2050 as written. > In thinking about this, since RFC 2050 was focused on IPv4 allocation policy and there is no more IPv4 to allocate, 2050 should probably be moved to historic. It certainly would be worth considering revising to maintain the portions which are an inherent technical requirements from IAB/IETF versus those which are a snapshot of registry policy at the time. It also is interesting to consider which forum(s) such an activity should take place in, since it's clear that an overall framework is necessary for the system to keep working globally. /John John Curran President and CEO ARIN From dredd at megacity.org Sun Feb 6 14:53:08 2011 From: dredd at megacity.org (Derek J. Balling) Date: Sun, 6 Feb 2011 15:53:08 -0500 Subject: quietly.... In-Reply-To: <00AEBEFA-7381-4C41-A909-11AC77107A57@delong.com> References: <23119638.5335.1297017284299.JavaMail.root@benjamin.baylink.com> <20110206191147.GI16405@nntp.AegisInfoSys.com> <00AEBEFA-7381-4C41-A909-11AC77107A57@delong.com> Message-ID: On Feb 6, 2011, at 2:28 PM, Owen DeLong wrote: > While Sony is, indeed, showing surprising market ignorance and bad > judgment at the moment, I think that the market will eventually teach > them a lesson in these regards. > > Time will tell. It is worth correlating that there seems to be some agreement to "surprising market ignorance" in the feature set and implementation of IPv6 as it pertains to the demands of its myriad actual consumers, and that the market will eventually teach the designers of IPv6 a lesson in that regard. That sword has edges on both sides, my friend. :-) cheers, D From brunner at nic-naa.net Sun Feb 6 15:05:06 2011 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Sun, 06 Feb 2011 16:05:06 -0500 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <19790.60580.225216.4089@world.std.com> References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> <96503CEA-C922-47A6-9691-FCF157DF15D5@internode.com.au> <10A940BA-6D90-4663-B942-5FFF2CB49D7A@internode.com.au> <4D4BAD13.9090301@gmail.com> <88BC6885D33A9D42A1CCB45E8749525E013CBC58@pigeon.sandiego.nextlevelinternet.com> <72609B8A-05D2-4039-85C4-A0578B9E6911@cisco.com> <4D4E0361.3060505@dcrocker.net> <19790.60580.225216.4089@world.std.com> Message-ID: <4D4F0D02.8010103@nic-naa.net> the authoritative and secondary servers for the "????." zone were unreachable, a circumstance which existed a year ago for the .ht zone. the authoritative and secondary servers for the ".eg" zone were mutually unreachable. wireline dialtone was prevalent during the prefix withdrawal period. suggestions for oob control, 56kb tech and (signed) zone transfer would be useful. graceful conversion to a sparse 56kb and vsat connectivity regime may be a general form of robustness. From johnl at iecc.com Sun Feb 6 15:16:44 2011 From: johnl at iecc.com (John Levine) Date: 6 Feb 2011 21:16:44 -0000 Subject: What's really needed is a routing slot market In-Reply-To: Message-ID: <20110206211644.34560.qmail@joyce.lan> >> What's really needed is seperate the routing slot market from the >> address allocation market. >Bingo! In fact, having an efficient market for obtaining routing of a >given prefix, combined with IPv6 vast identifier space, could >actually satisfy the primary goals that we hold for a long-term >scalable address architecture, and enable doing it in a highly >distributed, automatable fashion This is not unlike the oft made comment that if you could just charge a fraction of a cent for every mail message, there would be no spam problem. They're both bad ideas that just won't go away. Here's some thought experiments: 1) You get a note from the owner of jidaw.com, a large ISP in Nigeria, telling you that they have two defaultless routers so they'd like a share of the route fees. Due to the well known fraud problem in Nigeria, please pay them into the company's account in the Channel Islands. What do you do? (Helpful hint: there are plenty of legitimate reasons for non-residents to have accounts in the Channel Islands. I have a few.) 2) Google says here's our routes, we won't be paying anything. What do you do? 2a) If you insist no pay, no route, what do you tell your users when they call and complain? 2b) If you make a special case for Google, what do you do when Yahoo, AOL, and Baidu do the same thing? I can imagine some technical backpressure, particularly against networks that don't aggregate their routes, but money? Forget about it, unless perhaps you want to mix them into the peering/transit negotiations. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From bill at herrin.us Sun Feb 6 15:23:08 2011 From: bill at herrin.us (William Herrin) Date: Sun, 6 Feb 2011 16:23:08 -0500 Subject: What's really needed is a routing slot market In-Reply-To: <4D4ED71D.7020104@bogus.com> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org> <4D4C0D25.70408@brightok.net> <20110204231134.3AA029B2B39@drugs.dv.isc.org> <4D4C8AF8.1030703@brightok.net> <20110205004517.371F99B3B3C@drugs.dv.isc.org> <4D4CA1B1.5060002@brightok.net> <20110205124710.059259B4E31@drugs.dv.isc.org> <4D4D5FFC.6020905@brightok.net> <20110206010145.9DCD99B60B9@drugs.dv.isc.org> <4D4DF75E.1040109@brightok.net> <20110206024051.D60349B6D50@drugs.dv.isc.org> <4D4ED71D.7020104@bogus.com> Message-ID: On Sun, Feb 6, 2011 at 12:15 PM, Joel Jaeggli wrote: > On 2/6/11 8:00 AM, John Curran wrote: >> On Feb 5, 2011, at 9:40 PM, Mark Andrews wrote: >>> What's really needed is seperate the routing slot market from the >>> address allocation market. >> >> Bingo! In fact, having an efficient market for obtaining routing of a >> given prefix, combined with IPv6 vast identifier space, could actually >> satisfy the primary goals that we hold for a long-term scalable address >> architecture, and enable doing it in a highly distributed, automatable >> fashion: > > So assuming this operates on a pollution model the victims of routing > table bloat are compensated by the routing table pollutors for the use > of the slots which they have to carry. so I take the marginal cost of > the slots that I need subtract the royalities I recieve from the other > participants and if I'm close to the mean number of slots per > participant then it nets out to zero. Hi Joel, It couldn't and wouldn't work that way. Here's how it could work: Part 1: The Promise. If paid to carry a particular route (consisting one specific network and netmask, no others) then barring a belief that a particular received route announcement is fraudulent, a given AS: A. Will announce that route to each neighbor AS which pays for Internet access if received from any neighbor AS, unless the specific neighbor AS has asked to receive a restricted set of routes. B. Will announce that route to every neighbor AS if received from any neighbor AS who pays for Internet access, unless the specific neighbor AS has asked to receive a restricted set of routes. C. Will not ask any neighbor AS to filter the given route or any superset from the list of routes offered on that connection. D. Will assure sufficient internal carriage of the route within the AS's network to reasonably meet responsibilities A, B and C, and extend the route or a sufficient covering route to every non-BGP customer of the network. Part 2: The Payment. Each AS who wishes to do so will offer to execute The Promise for any set of networks/netmasks requested by the legitimate origin AS for a reasonable and non-discriminatory (RAND) price selected by the AS based on reasonable estimates of the routing slot costs. The preceding not withstanding, an AS may determine that a particular route or AS is not eligible for carriage at any price due to violations of that AS's terms of service. If such is determined, the AS will not accept payment for carrying the route and will refund any payments made for service during the period in which carriage is not made. Needless to say, the origin AS with two routers can offer a RAND fee to carry routes, but not many will take them up on it. They'll have to carry the route or institute a default route if they want to remain fully connected. The folks who will get paid are the ones who collectively are the backbone where you, as the origin, can't afford for your route not to be carried. These are, of course, the same folks who are presently the victims of routing pollution who pay the lion's share of the $2B/yr routing slot costs yet have little choice but to carry the routes. Part 3: The Arbiter. One or several route payment centers collects the RAND offerings and makes them available to origin ASes in bulk sets. You write one check each month to the Arbiter and he collects your routes with his other customers and makes the appropriate Payments for the Promises. Part 4: The Covering Routes. ARIN and the other RIRs auction the rights to offer a covering route for particular /8's. The winner announces the whole /8 but gets to break the RAND rule in the Payment for covered routes. An origin AS can still choose to have everybody carry his routes. But he can also choose to have just the paid paths to the AS with the Covering Route carried, or some fraction of ASes that includes those paid paths. Or he could buy transit tunnels from the Covering Route AS anchored to PA addresses from his individual ISPs. Or he could do a mix of the two. Regardless, the origin AS ends up with full reachability without needing his explicit route to be carried the breadth of the Internet. Note that I use the term "auction" very loosely. The winner could be the qualified AS willing to pay a fixed nominal fee and promise the lowest carriage fee / 95th percentile tunnel transit fee. At any rate, you get a healthy potential for route aggregation through payment selection by the origin AS. If more precise routing is worth the money, they'll pay the slot cost. If not, they'll rely on the covers. Or if it works out that a router costs $5M because it has to carry 10M routes, who cares as long as you're being paid what it costs? > Yay? Yay! Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From dorn at hetzel.org Sun Feb 6 15:29:02 2011 From: dorn at hetzel.org (Dorn Hetzel) Date: Sun, 6 Feb 2011 16:29:02 -0500 Subject: What's really needed is a routing slot market In-Reply-To: <20110206211644.34560.qmail@joyce.lan> References: <20110206211644.34560.qmail@joyce.lan> Message-ID: > > > 1) You get a note from the owner of jidaw.com, a large ISP in Nigeria, > telling you that they have two defaultless routers so they'd like a > share of the route fees. Due to the well known fraud problem in > Nigeria, please pay them into the company's account in the Channel > Islands. What do you do? (Helpful hint: there are plenty of > legitimate reasons for non-residents to have accounts in the Channel > Islands. I have a few.) > > If I peer with them or sell them transit or buy transit from them then we have a reason to talk, otherwise, not so much. > 2) Google says here's our routes, we won't be paying anything. What > do you do? > > There's a cost to taking the routes from Google, and a benefit to having those routes. As long as the benefit exceeds the cost, no worries. > 2a) If you insist no pay, no route, what do you tell your users when > they call and complain? > > 2b) If you make a special case for Google, what do you do when Yahoo, > AOL, and Baidu do the same thing? > > Back to the cost/benefit balance above. > I can imagine some technical backpressure, particularly against networks > that don't aggregate their routes, but money? Forget about it, unless > perhaps you want to mix them into the peering/transit negotiations. > > I think the only way it works, presuming anyone wanted to do it, is as a property of transit and peering. If I buy transit from you and want to send you a mess of routes, you might charge me more for my transit on account of that. Perhaps I get one free prefix announcement per x amount of bandwidth I am buying ? If we are peering then prefix balance might join traffic balance as a way to think about whether the arrangement is good for both peers. All of these arrangements occur between directly peering or transit providing neighbors. If I buy transit from you, I expect you to pay any costs needed to get my routes out to the world (and probably to charge me accordingly). From jbates at brightok.net Sun Feb 6 15:44:22 2011 From: jbates at brightok.net (Jack Bates) Date: Sun, 06 Feb 2011 15:44:22 -0600 Subject: quietly.... In-Reply-To: References: <23119638.5335.1297017284299.JavaMail.root@benjamin.baylink.com> <20110206191147.GI16405@nntp.AegisInfoSys.com> <00AEBEFA-7381-4C41-A909-11AC77107A57@delong.com> Message-ID: <4D4F1636.4030507@brightok.net> On 2/6/2011 2:53 PM, Derek J. Balling wrote: > It is worth correlating that there seems to be some agreement to "surprising market ignorance" in the feature set and implementation of IPv6 as it pertains to the demands of its myriad actual consumers, and that the market will eventually teach the designers of IPv6 a lesson in that regard. > I don't think it's a concern or issue. Everyone will just have to buy an xbox. M$ can't claim ignorance. :) Jack From jbates at brightok.net Sun Feb 6 15:47:41 2011 From: jbates at brightok.net (Jack Bates) Date: Sun, 06 Feb 2011 15:47:41 -0600 Subject: What's really needed is a routing slot market In-Reply-To: <20110206211644.34560.qmail@joyce.lan> References: <20110206211644.34560.qmail@joyce.lan> Message-ID: <4D4F16FD.1080306@brightok.net> On 2/6/2011 3:16 PM, John Levine wrote: > I can imagine some technical backpressure, particularly against networks > that don't aggregate their routes, but money? Forget about it, unless > perhaps you want to mix them into the peering/transit negotiations. On the other hand, the ESPN3 extortion worked quite well. Jack From marka at isc.org Sun Feb 6 15:57:14 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 07 Feb 2011 08:57:14 +1100 Subject: Using IPv6 with prefixes shorter than a /64 on a LAN In-Reply-To: Your message of "Sun, 06 Feb 2011 09:07:42 MDT." <4D4EB93E.6000409@brightok.net> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org> <4D4C0D25.70408@brightok.net> <20110204231134.3AA029B2B39@drugs.dv.isc.org> <4D4C8AF8.1030703@brightok.net> <20110205004517.371F99B3B3C@drugs.dv.isc.org> <4D4CA1B1.5060002@brightok.net> <20110205124710.059259B4E31@drugs.dv.isc.org> <4D4D5FFC.6020905@brightok.net> <20110206010145.9DCD99B60B9@drugs.dv.isc.org> <4D4DF75E.1040109@brightok.net> <20110206024051.D60349B6D50@drugs.dv.isc.org> <4D4E1C5D.20407@brightok.net> <20110206055738.A128B9B78EA@drugs.dv.isc.org> <4D4EB93E.60004 09@brightok.net> Message-ID: <20110206215714.709CE9B99A0@drugs.dv.isc.org> In message <4D4EB93E.6000409 at brightok.net>, Jack Bates writes: > On 2/5/2011 11:57 PM, Mark Andrews wrote: > > > > Rationalising to power of 2 allocations shouldn't result in requiring > > 256 times the space you were claiming with the 8 bits of shift on > > average. A couple of bits will allow that. > > > I didn't claim 8 bit average (if I accidentally did, my apologies). I > claimed a minimum of 8 bits. Somewhere between 12 and 16 is more likely. > However, with new ARIN proposals, we will see shorter shifts (yet still > over 8 bit shifts) as it does nibble allocations for everything (pop > assignments nibble aligned, ISP allocations nibble aligned, ISP to ISP > reallocation policies). It treats utilization as a 75% bar with nibble > alignments to allow for proper growth at the ISP level. Why would a pop need to be nibble aligned? Customers should be nibble aligned as it requires a delegation in the DNS. A pop doesn't need a delegation in the DNS. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Sun Feb 6 16:15:21 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 07 Feb 2011 09:15:21 +1100 Subject: Top webhosters offering v6 too? In-Reply-To: Your message of "Sun, 06 Feb 2011 11:49:06 CDT." References: <16975AA8-ABEB-402E-BA05-1BE51138A133@ecs.soton.ac.uk> Message-ID: <20110206221521.364F89B9C2B@drugs.dv.isc.org> In message , Fred Richards writes: > I ran across this link a while back, it shows, of the top 100k > websites (according to Alexa), which ones are IPv6 enabled: > > http://www.atoomnet.net/ipv6_enabled_popular_websites.php?complete_list=3Dt= > rue And 1.5% of AAAA lookups, in the Alexa top 1000000, fail as the SOA is in the wrong section or the wrong SOA is returned or timeout or return NXDOMAIN when A returns a answer. GLB vendors have a lot to answer for as almost all of these errors involve a GLB being installed. Either their products are broken or their documentation is so poor that people can't configure their boxes properly. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From drc at virtualized.org Sun Feb 6 16:32:15 2011 From: drc at virtualized.org (David Conrad) Date: Sun, 6 Feb 2011 12:32:15 -1000 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <302202D5-A0C2-4BD9-B08B-A376A3174926@arin.net> References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <20110205193328.GC22325@vacation.karoshi.com> <08F8827D-D8C3-4922-AC39-6C71ADBE8BDB@corp.arin.net> <20110206014014.GG22325@vacation.karoshi.com> <849FDB3F-EE29-48D6-8ECD-70AE6EB0B157@virtualized.org> <585A8651-6C2E-4B16-9D03-6C756CC9E77D@arin.net> <57B939FE-3B74-4B70-8AD5-71176551C2BF@virtualized.org> <302202D5-A0C2-4BD9-B08B-A376A3174926@arin.net> Message-ID: On Feb 6, 2011, at 9:53 AM, John Curran wrote: > Your suggestion that "existing loans may be impacted" means to be ignored > for evaluating future allocations does seems a bit superfluous when taken > in full context, but obviously must be considered as you are one of the > authors. I believe (it has been 15 years after all) the idea was that if an ISP didn't update the registry with new assignments, the RIR could in extreme cases remove previously submitted reassignment information as punishment (the theory being that this would cause the ISP's customers to take action). Again, this wording is in a section that is discussing sub-delegation guidelines for ISPs who received an allocation from the RIRs. How are you "reinterpreting" section 2.1.3? > Do you have any similar suggestions for how to reinterpret the transfer > section, i.e. " The transfer of IP addresses from one party to another > must be approved by the regional registries." or "The party trying to > obtain the IP address must meet the same criteria as if they were > requesting an IP address directly from the IR." ? As opposed to section 2, section 4.7 seems pretty unambiguous to me: it was an attempt by the registries at the time to conserve the remaining IPv4 free pool by disallowing the bypassing of registry allocation restrictions. Do you "reinterpret" it differently? > It certainly would be worth considering revising to maintain the > portions which are an inherent technical requirements from IAB/IETF > versus those which are a snapshot of registry policy at the time. I hear Mark McFadden, since he hated his life, was working on 2050bis... :-) More seriously, RFC 2050 was an attempt to document the then current (in 1996) practices for allocating IPv4 addresses. Instead of revising that 15 year old document, I'd think a document that describes the role and responsibilities of the registries in a post-IPv4 free pool world would be much more valuable. My impression is that there is a bit of a disconnect between the folks who go to RIR meetings and the folks who have IP addresses (particularly those folks who received their addresses prior to the existence of the RIRs). Might be useful to remedy this. > It also is interesting to consider which forum(s) such an activity > should take place in, since it's clear that an overall framework > is necessary for the system to keep working globally. Yeah, too bad no one set up an organization whose By-Laws and Mission is to coordinate, at an overall level, the global Internet's systems of unique identifiers capable of providing such a forum. Regards, -drc From marka at isc.org Sun Feb 6 16:44:35 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 07 Feb 2011 09:44:35 +1100 Subject: quietly.... In-Reply-To: Your message of "Sun, 06 Feb 2011 13:34:44 CDT." <23119638.5335.1297017284299.JavaMail.root@benjamin.baylink.com> References: <23119638.5335.1297017284299.JavaMail.root@benjamin.baylink.com> Message-ID: <20110206224435.755439B9E0E@drugs.dv.isc.org> In message <23119638.5335.1297017284299.JavaMail.root at benjamin.baylink.com>, Ja y Ashworth writes: > ----- Original Message ----- > > From: "Owen DeLong" > > > I'm pretty sure the PS3 will get resolved through a software update. > > > > Yes, there will be user-visible disruptions in this transition. > > > > No, it can't be 100% magic on the part of the service provider. > > > > It still has to happen. There is no viable alternative. > > There will be *lots* of user visible disruptions. And if you believe, > as it appears you do from the integration of your messages on this thread, > that anyone anywhere will be able through any legal theory to *force* Sony > to make that older PS3 work on IPv6, then the term for your opinion, in *my* > opinion, has changed from "optimistic" to "nutsabago". :-) > > >From up here at 30,000ft, the entire deployment of IPv6 has been cripplingly > mismanaged, or we wouldn't be having all these conversations, still, now. > Having had them 5 years ago would have been well more than good enough. > And it will start to bite, hard, very shortly. > > Cheers, > -- jra PS3 will only be a problem if it doesn't work through double NAT or there is no IPv4 path available. Homes will be dual stacked for the next 10 years or so even if the upstream is IPv6 only. DS-Lite or similar will provide a IPv4 path. The DS-Lite service can be supplied by anyone anywhere on the IPv6 Internet that has public IPv4 addresses. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jbates at brightok.net Sun Feb 6 16:59:48 2011 From: jbates at brightok.net (Jack Bates) Date: Sun, 06 Feb 2011 16:59:48 -0600 Subject: quietly.... In-Reply-To: <20110206224435.755439B9E0E@drugs.dv.isc.org> References: <23119638.5335.1297017284299.JavaMail.root@benjamin.baylink.com> <20110206224435.755439B9E0E@drugs.dv.isc.org> Message-ID: <4D4F27E4.6080604@brightok.net> On 2/6/2011 4:44 PM, Mark Andrews wrote: > > PS3 will only be a problem if it doesn't work through double NAT > or there is no IPv4 path available. Homes will be dual stacked for > the next 10 years or so even if the upstream is IPv6 only. DS-Lite > or similar will provide a IPv4 path. The DS-Lite service can be > supplied by anyone anywhere on the IPv6 Internet that has public > IPv4 addresses. > I could be wrong, but I believe the PS3, like many game systems, has trouble with double NAT and supports end node game hosting, which will break with double NAT on both ends; we'll see double NAT commonly on both end points as we move forward if IPv4 is bothered to be supported for long, especially if ds-lite doesn't become more prevalent in CPEs. Jack From marka at isc.org Sun Feb 6 17:54:50 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 07 Feb 2011 10:54:50 +1100 Subject: quietly.... In-Reply-To: Your message of "Sun, 06 Feb 2011 16:59:48 MDT." <4D4F27E4.6080604@brightok.net> References: <23119638.5335.1297017284299.JavaMail.root@benjamin.baylink.com> <20110206224435.755439B9E0E@drugs.dv.isc.org><4D4F27E4.6080604@brightok.net> Message-ID: <20110206235450.3B4179BA233@drugs.dv.isc.org> In message <4D4F27E4.6080604 at brightok.net>, Jack Bates writes: > On 2/6/2011 4:44 PM, Mark Andrews wrote: > > > > PS3 will only be a problem if it doesn't work through double NAT > > or there is no IPv4 path available. Homes will be dual stacked for > > the next 10 years or so even if the upstream is IPv6 only. DS-Lite > > or similar will provide a IPv4 path. The DS-Lite service can be > > supplied by anyone anywhere on the IPv6 Internet that has public > > IPv4 addresses. > > > > I could be wrong, but I believe the PS3, like many game systems, has > trouble with double NAT and supports end node game hosting, which will > break with double NAT on both ends; we'll see double NAT commonly on > both end points as we move forward if IPv4 is bothered to be supported > for long, especially if ds-lite doesn't become more prevalent in CPEs. Note the CPE doesn't have to be the box they is offering the IPv4 connectivity to the net. Any dual stack box on the net could do the job provided it supports the B4 component. > Jack -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jabley at hopcount.ca Sun Feb 6 18:13:35 2011 From: jabley at hopcount.ca (Joe Abley) Date: Sun, 6 Feb 2011 19:13:35 -0500 Subject: quietly.... In-Reply-To: <4D4B3C53.5080507@paulgraydon.co.uk> References: <31501371.4291.1296707494566.JavaMail.root@benjamin.baylink.com> <4D4B3C53.5080507@paulgraydon.co.uk> Message-ID: On 2011-02-03, at 18:37, Paul Graydon wrote: > On 02/02/2011 06:31 PM, Jay Ashworth wrote: >> > >> I, personally, have been waiting to hear what happens when network techs >> discover that they can't carry IP addresses around in their heads anymore. >> >> That sounds trivial, perhaps, but I don't think it will be. >> > > Absolutely, it's certainly one thing I'm dreading. I'm not sure this is the nightmare people think it will be. In my (admittedly fairly small-scale) experience with operating v6 on real networks, being able to figure out a prefix from a schema such as ARIN:ARIN:SITE:VLAN::/64 makes things a lot easier. Having to remember ...::1, or ...::2, or ...:3 for the statically-numbered routers on the VLAN doesn't exactly make things much harder. Mix in some special cases (e.g. VLAN=0 for loopbacks) and you have a recipe that's pretty trivial to remember. [This is how Stephen Stuart and Paul Vixie set things up within 2001:4f8::/32 back when I was chasing packets at ISC, and I've followed the model ever since.] It's easier to figure out 2607:f2c0:1::1 in these terms than it is to remember 206.248.155.244. For me, at least :-) I appreciate the full mess of EUI-64 for devices using autoconf requires cut and paste, but that's why you hard-wire the host bits for things you refer to frequently. Joe From ryan at deadfrog.net Sun Feb 6 18:18:14 2011 From: ryan at deadfrog.net (Ryan Wilkins) Date: Sun, 6 Feb 2011 18:18:14 -0600 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <30423.88286.qm@web121602.mail.ne1.yahoo.com> References: <5817196.4787.1296792606407.JavaMail.root@benjamin.baylink.com> <9D145C3C-2D3A-4D73-997C-6346B6EF402A@deadfrog.net> <30423.88286.qm@web121602.mail.ne1.yahoo.com> Message-ID: On Feb 6, 2011, at 8:57 AM, isabel dias wrote: > do you have a satellite dish? what are your dish pointing coordinates......we just need to find out what is going on the air interface ... I don't personally have one but of of the companies that I contract to is in the satellite networks business. It wouldn't take much to pack up a 1.2m antenna, LNB, BUC, iDirect router, cables, and be on the air. The 3.8m would be a bit more difficult to pack up. ;-) As for pointing, pick a Ku-band satellite viewable from Chicago and I could be on it. There's a bunch of them. The iDirect 7350 router will do iDirect TDMA or SCPC. Regards, Ryan Wilkins From jbates at brightok.net Sun Feb 6 18:40:43 2011 From: jbates at brightok.net (Jack Bates) Date: Sun, 06 Feb 2011 18:40:43 -0600 Subject: quietly.... In-Reply-To: References: <31501371.4291.1296707494566.JavaMail.root@benjamin.baylink.com> <4D4B3C53.5080507@paulgraydon.co.uk> Message-ID: <4D4F3F8B.3090706@brightok.net> On 2/6/2011 6:13 PM, Joe Abley wrote: > > I'm not sure this is the nightmare people think it will be. > > In my (admittedly fairly small-scale) experience with operating v6 on real networks, being able to figure out a prefix from a schema such as > > ARIN:ARIN:SITE:VLAN::/64 > > makes things a lot easier. Having to remember ...::1, or ...::2, or ...:3 for the statically-numbered routers on the VLAN doesn't exactly make things much harder. Mix in some special cases (e.g. VLAN=0 for loopbacks) and you have a recipe that's pretty trivial to remember. > As an ISP, we reserved the first /48 of several of our /32's for specific purposes, which makes it even easier. Our helpdesk will be running ping by number tests (for detecting IPv6 connectivity but DNS being broken) using: ARIN:ARIN::/64 Which makes it as easy as IPv4. This was made easier by the fact that our allocation has no letters. Jack From randy at psg.com Sun Feb 6 18:51:26 2011 From: randy at psg.com (Randy Bush) Date: Sun, 06 Feb 2011 16:51:26 -0800 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <20110205193328.GC22325@vacation.karoshi.com> <08F8827D-D8C3-4922-AC39-6C71ADBE8BDB@corp.arin.net> <20110206014014.GG22325@vacation.karoshi.com> <849FDB3F-EE29-48D6-8ECD-70AE6EB0B157@virtualized.org> <585A8651-6C2E-4B16-9D03-6C756CC9E77D@arin.net> <57B939FE-3B74-4B70-8AD5-71176551C2BF@virtualized.org> <302202D5-A0C2-4BD9-B08B-A376A3174926@arin.net> Message-ID: it is both amusing and horrifying to watch two old dogs argue about details of written rules as if common sense had died in october 1998. what is good for the internet? what is simple? what is pragmatic? if the answer is not simple and obvious, we should go break something else. randy From jcurran at arin.net Sun Feb 6 19:25:10 2011 From: jcurran at arin.net (John Curran) Date: Mon, 7 Feb 2011 01:25:10 +0000 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <20110205193328.GC22325@vacation.karoshi.com> <08F8827D-D8C3-4922-AC39-6C71ADBE8BDB@corp.arin.net> <20110206014014.GG22325@vacation.karoshi.com> <849FDB3F-EE29-48D6-8ECD-70AE6EB0B157@virtualized.org> <585A8651-6C2E-4B16-9D03-6C756CC9E77D@arin.net> <57B939FE-3B74-4B70-8AD5-71176551C2BF@virtualized.org> <302202D5-A0C2-4BD9-B08B-A376A3174926@arin.net> Message-ID: <29A461FE-306C-4536-93DF-73B6BD4C13B0@arin.net> On Feb 6, 2011, at 7:51 PM, Randy Bush wrote: > it is both amusing and horrifying to watch two old dogs argue about > details of written rules as if common sense had died in october 1998. > what is good for the internet? what is simple? what is pragmatic? if > the answer is not simple and obvious, we should go break something else. Actually, I'm in full agreement with you: the goal needs to be to keep the Internet running. Alas, I've run a few networks, but that's a few years back, and I'll be the first to admit that my particular graybeard views on what is best for the Internet lacks current operational insights. Also note that, as CEO of ARIN, it is not my role to preempt discussion by proposing solutions, but instead to encourage good discussion of the issues. So, what exactly is broken and needs to be changed? I do know that we can't have the basic premises of the system completely set on a regional basis, but we also have to allow for regional differences in policy since operators face different challenges. While the discussion is ongoing, we're keeping to the principles of aggregation, conservation, and registration, and looking forward to any consensus that emerges from the operator community to change these principles. /John John Curran President and CEO ARIN From charles at knownelement.com Sun Feb 6 19:29:18 2011 From: charles at knownelement.com (Charles N Wyble) Date: Sun, 06 Feb 2011 17:29:18 -0800 Subject: Top webhosters offering v6 too? In-Reply-To: <20110206221521.364F89B9C2B@drugs.dv.isc.org> References: <16975AA8-ABEB-402E-BA05-1BE51138A133@ecs.soton.ac.uk> <20110206221521.364F89B9C2B@drugs.dv.isc.org> Message-ID: <4D4F4AEE.3080504@knownelement.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/06/2011 02:15 PM, Mark Andrews wrote: > In message , Fred > Richards writes: >> I ran across this link a while back, it shows, of the top 100k >> websites (according to Alexa), which ones are IPv6 enabled: >> >> http://www.atoomnet.net/ipv6_enabled_popular_websites.php?complete_list=3Dt= >> rue > > And 1.5% of AAAA lookups, in the Alexa top 1000000, fail as the SOA > is in the wrong section or the wrong SOA is returned or timeout or > return NXDOMAIN when A returns a answer. GLB vendors have a lot > to answer for as almost all of these errors involve a GLB being > installed. Either their products are broken or their documentation > is so poor that people can't configure their boxes properly. Given that v6 is probably an afterthought for these vendors, I'm guessing the documentation is at fault. I know the docs for some of the brands I've worked with were bad enough for tier-1 features. Bah. I'm in the process of putting together a fully software based system to do GLB. Presenting on it in a couple of weeks in the Los Angeles area. Hit me off list for details. It seems fairly straightforward to put the system together. Spent this weekend doing the research and architecture design for it. I'll send the slide link to the list after I give the talk. Maybe I'll present it in person at one of the upcoming NANOG meetings if I can get my employer to sponsor travel. :) Unfortunately it will be all v4. I have v6 turned up via he.net (as I alluded to a while back), but it's not at the same level as v4 is. I'm currently going through the learning process with v6. However that's an incredibly high priority for me, and I hope to be at parity with v4 by end of Q1. I'll probably do a separate "ipv6 for datacenter/application operators" presentation at some point in Q2. I know there will be one at SCALE this year, by one of our frequent v6 posters. :) - -- Charles N Wyble (charles at knownelement.com) Systems craftsman for the stars http://www.knownelement.com Mobile: 626 539 4344 Office: 310 929 8793 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNT0rqAAoJEMvvG/TyLEAtURcP+wbsYil0YufyEWsOlbtqcWDF kpoBgikyCPSazH/aM8trKsPFdWpo7HPX2RDHh+aJwRN3WEOPAdMzN+uchD28bvj8 1X0W4oJ+Tyrq0770iy7kcNmN0YJL7DpJlfiA8401lsPmsHBWrE55hEjcDz/lXjHA kfu7NOygoQ9PtQS8XgOrIpPVZ3Juv9ae/XUuwYEPkvGuwhn8ZdIBTKzSEIujPYOV dpMOxrXkaKrZILybUd9tmaFAKk4jML3+IqcziWYaDiJUWrrjLK18jMDOVr4WM8Pb TK8kz86B3oTNworxeVT9/oWyWMoPf0FDSCWCeEgdj4YvvlPlbq7skC2djvRvpPBE DtdOqw1gz8Buw3wvIrUfFsZgvOIrDRBCeXVvG0MoErpK18TubA79ZM8x58/aXAAY 3bnoiIfdJQGCnO5IscMEOijmPq60UI9fl1u4KTGd30nIEVFN1jPPKXXWDBPEFSA4 ylEJLKRP6CKNETURcfiMo9hi25IMiVjf4GvWGz1VPTqBhewh7ZxCEJkXrdQ7cAnh uZhbX76e/AGkeSiBvWdSDPlrUkFES5utoghswwZ8yCPaQguoF4NUMaDtMNfwlk8X F3YR8ocCn9HKvBhAEPezkvR4n0SMy+ybAJJkUsJ0QVZifWCNFdz0oJLuy7OVtmGt Uw2dQluyXu8c24UfuIhI =nX8D -----END PGP SIGNATURE----- From msa at latt.net Sun Feb 6 19:34:32 2011 From: msa at latt.net (Majdi S. Abbas) Date: Sun, 6 Feb 2011 18:34:32 -0700 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: References: <20110205193328.GC22325@vacation.karoshi.com> <08F8827D-D8C3-4922-AC39-6C71ADBE8BDB@corp.arin.net> <20110206014014.GG22325@vacation.karoshi.com> <849FDB3F-EE29-48D6-8ECD-70AE6EB0B157@virtualized.org> <585A8651-6C2E-4B16-9D03-6C756CC9E77D@arin.net> <57B939FE-3B74-4B70-8AD5-71176551C2BF@virtualized.org> <302202D5-A0C2-4BD9-B08B-A376A3174926@arin.net> Message-ID: <20110207013432.GP90833@puck.nether.net> On Sun, Feb 06, 2011 at 04:51:26PM -0800, Randy Bush wrote: > it is both amusing and horrifying to watch two old dogs argue about > details of written rules as if common sense had died in october 1998. > what is good for the internet? what is simple? what is pragmatic? if > the answer is not simple and obvious, we should go break something else. Randy, I'll bite. I'll take "Who cares? Let's keep on' keepin' on..." for $200. Deck chairs indeed. --msa From asr+nanog at latency.net Sun Feb 6 21:08:32 2011 From: asr+nanog at latency.net (Adam Rothschild) Date: Sun, 6 Feb 2011 22:08:32 -0500 Subject: Top webhosters offering v6 too? In-Reply-To: References: <16975AA8-ABEB-402E-BA05-1BE51138A133@ecs.soton.ac.uk> Message-ID: <20110207030831.GA6896@latency.net> We (voxel.net, AS 29791) offer dual-stack on all server and cloud products. As others have pointed out, SoftLayer is an excellent example of a hosting provider that Gets It on a large scale. Sadly, v6 support on popular "cloud-only" services is suspiciously absent. Terremark vCoudExpress, Savvis, Amazon EC2, among others don't support it today, or on any public roadmaps... -a From joelja at bogus.com Sun Feb 6 21:21:41 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 06 Feb 2011 19:21:41 -0800 Subject: Top webhosters offering v6 too? In-Reply-To: <20110207030831.GA6896@latency.net> References: <16975AA8-ABEB-402E-BA05-1BE51138A133@ecs.soton.ac.uk> <20110207030831.GA6896@latency.net> Message-ID: <4D4F6545.7090703@bogus.com> On 2/6/11 7:08 PM, Adam Rothschild wrote: > We (voxel.net, AS 29791) offer dual-stack on all server and cloud > products. As others have pointed out, SoftLayer is an excellent > example of a hosting provider that Gets It on a large scale. > > Sadly, v6 support on popular "cloud-only" services is suspiciously > absent. Terremark vCoudExpress, Savvis, Amazon EC2, among others > don't support it today, or on any public roadmaps... It's worth noting that the address space used in the large public clouds almost certainly overlaps with one's own private numbering plan, and having had to interconnect with some "public cloud" I can tell you that I do not appreciate having to 1:1 nat several thousand potential systems. I poked several about v6 support it would be greately appreciated if other people would likewise contact your account reps. > -a > From cb.list6 at gmail.com Sun Feb 6 21:36:53 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Sun, 6 Feb 2011 19:36:53 -0800 Subject: Top webhosters offering v6 too? In-Reply-To: <4D4F6545.7090703@bogus.com> References: <16975AA8-ABEB-402E-BA05-1BE51138A133@ecs.soton.ac.uk> <20110207030831.GA6896@latency.net> <4D4F6545.7090703@bogus.com> Message-ID: On Sun, Feb 6, 2011 at 7:21 PM, Joel Jaeggli wrote: > On 2/6/11 7:08 PM, Adam Rothschild wrote: >> We (voxel.net, AS 29791) offer dual-stack on all server and cloud >> products. ?As others have pointed out, SoftLayer is an excellent >> example of a hosting provider that Gets It on a large scale. >> >> Sadly, v6 support on popular "cloud-only" services is suspiciously >> absent. ?Terremark vCoudExpress, Savvis, Amazon EC2, among others >> don't support it today, or on any public roadmaps... > > It's worth noting that the address space used in the large public clouds > ?almost certainly overlaps with one's own private numbering plan, and > having had to interconnect with some "public cloud" I can tell you that > I do not appreciate having to 1:1 nat several thousand potential systems. > > I poked several about v6 support it would be greately appreciated if > other people would likewise contact your account reps. > No need friend. The AWS support thread on IPv6 goes back to 2007 ... and still no support. I'd give up and move on ... just like an ISP that does not support IPv6 today. It's a fight not worth picking. Between Voxel and Softlayer, i assume nearly any need can be met ... and the VPS market is pretty cut throat and customers can move quick. We cannot talk blue in the face about how people should support IPv6, that time has passed. Many organizations do support IPv6, they have had the forethought, and we should really vote with our dollars and not yet another round of posturing about how important v6 is and how X company should add IPv6 to their roadmap. Cloud and mobile are 2 very fast growing edges ... and you cannot do any level of network planning for these fast growing edges and overlook IPv6. Cameron ======== T-Mobile USA IPv6 Beta http://groups.google.com/group/tmoipv6beta ======== From frnkblk at iname.com Sun Feb 6 21:58:30 2011 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 6 Feb 2011 21:58:30 -0600 Subject: Top webhosters offering v6 too? In-Reply-To: References: <16975AA8-ABEB-402E-BA05-1BE51138A133@ecs.soton.ac.uk> Message-ID: <014d01cbc67b$485072e0$d8f158a0$@iname.com> Here's one list: http://www.sixxs.net/wiki/IPv6_Enabled_Hosting Frank -----Original Message----- From: Tim Chown [mailto:tjc at ecs.soton.ac.uk] Sent: Sunday, February 06, 2011 8:53 AM To: NANOG list Subject: Top webhosters offering v6 too? Which of the big boys are doing it? Tim From carlosm3011 at gmail.com Sun Feb 6 22:21:38 2011 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Sun, 6 Feb 2011 20:21:38 -0800 Subject: Top webhosters offering v6 too? In-Reply-To: <014d01cbc67b$485072e0$d8f158a0$@iname.com> References: <16975AA8-ABEB-402E-BA05-1BE51138A133@ecs.soton.ac.uk> <014d01cbc67b$485072e0$d8f158a0$@iname.com> Message-ID: BlueHost, which while maybe not a great quality web host, by all measures is a big one, not only does not support IPv6 but they denied my request to create a AAAA record pointing to a friend's IPv6 page for a domain I host there. BH, are you listening??? -. Carlos On Sun, Feb 6, 2011 at 7:58 PM, Frank Bulk wrote: > Here's one list: > http://www.sixxs.net/wiki/IPv6_Enabled_Hosting > > Frank > > -----Original Message----- > From: Tim Chown [mailto:tjc at ecs.soton.ac.uk] > Sent: Sunday, February 06, 2011 8:53 AM > To: NANOG list > Subject: Top webhosters offering v6 too? > > Which of the big boys are doing it? > > Tim > > > > -- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net ========================= From henry at AegisInfoSys.com Sun Feb 6 23:36:41 2011 From: henry at AegisInfoSys.com (Henry Yen) Date: Mon, 7 Feb 2011 00:36:41 -0500 Subject: Top webhosters offering v6 too? In-Reply-To: <20110207030831.GA6896@latency.net> References: <16975AA8-ABEB-402E-BA05-1BE51138A133@ecs.soton.ac.uk> <20110207030831.GA6896@latency.net> Message-ID: <20110207053641.GQ16405@nntp.AegisInfoSys.com> On Sun, Feb 06, 2011 at 22:08:32PM -0500, Adam Rothschild wrote: > As others have pointed out, SoftLayer is an excellent > example of a hosting provider that Gets It on a large scale. An excellent example of a provider that Spams on a large scale, too. -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York (800) 234-4700 From porgie217 at gmail.com Mon Feb 7 00:16:34 2011 From: porgie217 at gmail.com (Michael Coxe) Date: Sun, 06 Feb 2011 22:16:34 -0800 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <9FCDBED3-FA1E-47F2-8939-A083B1CA0E2B@cisco.com> References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> <96503CEA-C922-47A6-9691-FCF157DF15D5@internode.com.au> <10A940BA-6D90-4663-B942-5FFF2CB49D7A@internode.com.au> <4D4BAD13.9090301@gmail.com> <88BC6885D33A9D42A1CCB45E8749525E013CBC58@pigeon.sandiego.nextlevelinternet.com> <72609B8A-05D2-4039-85C4-A0578B9E6911@cisco.com> <4D4E0361.3060505@dcrocker.net> <9FCDBED3-FA1E-47F2-8939-A083B1CA0E2B@cisco.com> Message-ID: <4D4F8E42.3040908@gmail.com> On 02-05-11 8:29 PM, Fred Baker wrote: > > On Feb 5, 2011, at 6:11 PM, Dave CROCKER wrote: > >> >> >> On 2/5/2011 6:43 AM, Fred Baker wrote: >>> On Feb 4, 2011, at 9:49 PM, Hayden Katzenellenbogen wrote: >>>> Not sure if it has been said already but wasn't one of the key >>>> point for the creation of the internet to create and >>>> infrastructure that would survive in the case of all out war >>>> and massive destruction. (strategic nuclear strikes) >>> >>> Urban legend, although widely believed. Someone probably made the >>> observation. >> >> >> Maybe not quite an UL... >> >> >> >> On the average, The Rand Corp is extremely careful about what it >> publishes, yet here it is, repeating the claim. > > But Len Kleinrock adamantly disputes it. > >> Back in the '70s, I always heard "survive hostile battlefield >> conditions" and never heard anyone talk about comms survival of a >> nuclear event, but I wasn't in any interesting conversations, such >> as in front of funding agencies... > > To survive an EMP, electronics needs some fancy circuitry. I've never > worked with a bit of equipment that had it. It would therefore have > to have been through path redundancy. For more specifics from Paul Baran himself, you may read his interview with Stewart Brand. Lots of good stuff circa late 50s - early 60s. http://www.wired.com/wired/archive/9.03/baran_pr.html one fun excerpt, re: asking the phone co to build a packet switch: ---- SB: How seriously did AT&T look at the proposal? PB: The response was most interesting. The story I tell is of the time I went over to AT&T headquarters - one of many, many times - and there's a group of old graybeards. I start describing how this works. One stops me and says, "Wait a minute, son. Are you trying to tell us that you open the switch up in the middle of the conversation?" I say, "Yes." His eyeballs roll as he looks at his associates and shakes his head. We just weren't on the same wavelength. ---- Paul's memory is backed up by his meticulous records. I worked at Com21 1997-2K and heard similar recounts from Paul over Com21 BBQ lunches at the company's Tasman site. I wished for a while he'd write a history but came to understand he's always been a doer not a historian. Cheers, - Michael From sethm at rollernet.us Mon Feb 7 00:47:27 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 06 Feb 2011 22:47:27 -0800 Subject: Top webhosters offering v6 too? In-Reply-To: References: <16975AA8-ABEB-402E-BA05-1BE51138A133@ecs.soton.ac.uk> <014d01cbc67b$485072e0$d8f158a0$@iname.com> Message-ID: <4D4F957F.6040600@rollernet.us> On 2/6/11 8:21 PM, Carlos Martinez-Cagnazzo wrote: > BlueHost, which while maybe not a great quality web host, by all > measures is a big one, not only does not support IPv6 but they denied > my request to create a AAAA record pointing to a friend's IPv6 page > for a domain I host there. > > BH, are you listening??? > There are plenty of providers that support IPv6 and would be happy to have a new customer that's interested in IPv6. If your current host does not support it and you want it, just drop them already and move on to one that does. ~Seth From igor at ergens.org Mon Feb 7 01:18:08 2011 From: igor at ergens.org (Igor Ybema) Date: Mon, 7 Feb 2011 08:18:08 +0100 Subject: Top webhosters offering v6 too? In-Reply-To: <4D4F957F.6040600@rollernet.us> References: <16975AA8-ABEB-402E-BA05-1BE51138A133@ecs.soton.ac.uk> <014d01cbc67b$485072e0$d8f158a0$@iname.com> <4D4F957F.6040600@rollernet.us> Message-ID: Oxilion, dutch based provider (AS48539), also provides cloud services based on RHEV. They do provide IPv6 also. See for a redhat notice about this: http://www.redhat.com/about/news/prarchive/2010/oxilion.html Their site is mostly dutch, however this one is in English also http://oxilion.nl/virtual-datacenter-en regards, Igor From iljitsch at muada.com Mon Feb 7 02:50:55 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 7 Feb 2011 09:50:55 +0100 Subject: Failure modes: NAT vs SPI In-Reply-To: References: <13040078.4555.1296760192315.JavaMail.root@benjamin.baylink.com> <1BC162C5-2535-48F0-8CA3-CDCD1490E568@muada.com> Message-ID: On 4 feb 2011, at 22:02, Dave Cardwell wrote: > Without wanting to get into whether NAT provides security to hosts > that exist on the inside. I am curious if the potential to overflow > ND caches with incomplete* entries exists on currently shipping CPE > hardware and if NAT helps prevent this? > e.g. > In v4 with a /24 on the inside an attacker can send a single packet to > each consecutive address causing at most 254 arp requests to be sent > on the lan segment and upto 253 incomplete entries, until they > timeout. > In v6 with a /64 on the inside it seems like the same tactic would > lead to more outstanding ND requests than any realistically sized > cache would support. Ok, I had a hard time making up my mind whether a sarcastic or a factual response was in order... This is of course a very big problem, and one of the reasons why everyone who's tried IPv6 immediately turns it off again: script kiddies are continuously scanning the entire IPv6 address space so this happens to regular IPv6 users all the time. Since this is a problem that is inherent to the ND protocol that is impossible to fix without modifying the IPv6 standards significantly, the easiest way to solve this with the least amount of impact to applications, the ability to host services and the end-to-end model in particular is to use a single public IPv6 address and NAT all local stuff behind it. (BTW, there have been some discussions on NAT66 in the IETF, but that wouldn't be a port overloading 1-to-many NAT, but rather a 1-to-1 NAT, because with IPv6, there obviously isn't any reason to use address sharing. The thinking is that such a 1-to-1 NAT is less harmful than a port overloading 1-to-many NAT so it would be beneficial to specify the former to avoid the latter. But many people within the IETF don't support that strategy.) From owen at delong.com Mon Feb 7 03:33:23 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 7 Feb 2011 01:33:23 -0800 Subject: Failure modes: NAT vs SPI In-Reply-To: References: <13040078.4555.1296760192315.JavaMail.root@benjamin.baylink.com> <1BC162C5-2535-48F0-8CA3-CDCD1490E568@muada.com> Message-ID: <5D2BCD6C-894B-40C2-94A9-DAD0F8EC2865@delong.com> On Feb 7, 2011, at 12:50 AM, Iljitsch van Beijnum wrote: > On 4 feb 2011, at 22:02, Dave Cardwell wrote: > >> Without wanting to get into whether NAT provides security to hosts >> that exist on the inside. I am curious if the potential to overflow >> ND caches with incomplete* entries exists on currently shipping CPE >> hardware and if NAT helps prevent this? > >> e.g. >> In v4 with a /24 on the inside an attacker can send a single packet to >> each consecutive address causing at most 254 arp requests to be sent >> on the lan segment and upto 253 incomplete entries, until they >> timeout. >> In v6 with a /64 on the inside it seems like the same tactic would >> lead to more outstanding ND requests than any realistically sized >> cache would support. > > Ok, I had a hard time making up my mind whether a sarcastic or a factual response was in order... > > This is of course a very big problem, and one of the reasons why everyone who's tried IPv6 immediately turns it off again: script kiddies are continuously scanning the entire IPv6 address space so this happens to regular IPv6 users all the time. > Uh, no. 1. Scanning even an entire /64 at 1,000 pps will take 18,446,744,073,709,551 seconds which is 213,503,982,334 days or 584,542,000 years. I would posit that since most networks cannot absorb a 1,000 pps attack even without the deleterious effect of incomplete ND on the router, no network has yet had even a complete /64 scanned. IPv6 simply hasn't been around that long. Claiming that anyone (or any collection of random people) is even capable of continuously scanning the entire IPv6 address space is absurd. 2. The few scanning attacks we've seen haven't gotten very far before giving up. We've not had any negative ND effects as a result. > Since this is a problem that is inherent to the ND protocol that is impossible to fix without modifying the IPv6 standards significantly, the easiest way to solve this with the least amount of impact to applications, the ability to host services and the end-to-end model in particular is to use a single public IPv6 address and NAT all local stuff behind it. > That's a horrible solution. For one thing, it breaks the end-to-end model you claim you are protecting. Further, it doesn't really help and there are much better solutions. For example, on point-to-point links, block traffic to addresses outside of the assigned addresses on the link. Fast flushing of incomplete ND entries can also help here. That may require a software upgrade in some routers, but, it doesn't require a rewrite of the protocol standards. Finally, an SPI firewall shouldn't be permitting most of that traffic in, since it should only be permitting packets in to hosts that have legitimate external services on them. As such the sweep should only generate ND traffic for hosts that exist and provide external services. > (BTW, there have been some discussions on NAT66 in the IETF, but that wouldn't be a port overloading 1-to-many NAT, but rather a 1-to-1 NAT, because with IPv6, there obviously isn't any reason to use address sharing. The thinking is that such a 1-to-1 NAT is less harmful than a port overloading 1-to-many NAT so it would be beneficial to specify the former to avoid the latter. But many people within the IETF don't support that strategy.) A 1:1 NAT wouldn't solve your ND problem. The traffic will be dutifully translated and still generate a sweep of ND packets. Owen From denys at visp.net.lb Mon Feb 7 05:39:27 2011 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Mon, 7 Feb 2011 13:39:27 +0200 Subject: US Warships jamming Lebanon Internet Message-ID: <201102071339.27793.denys@visp.net.lb> Hi I'm sysadmin of Lebanese ISP. Almost at same time i got heavy interference on few of my C-Band carriers, and it looks like electronic warfare jamming, because i can see phase modulated, very weak signal, but it is completely breaking almost any communications on my carriers. Strange thing, that our uplink station confirm that interference is not local on my side, but on satellite carrier. If this will be confirmed, that means it is not just miscommunication between authorities about frequency usage, it will be intentional damage for Lebanese communications. Sure it can be coincidence in time or something else, but last 6 years i experience similar terrible interference only during 2006 Lebanon vs Israel war. >Lebanon's Telecom minister is claiming that US Navy radar is blocking the >country's Internet.. > >http://www.naharnet.com/domino/tn/NewsDesk.nsf/0/93A95CA1A4E42178C225782E007371AF > >>"The problem, however, is due to a coordination error related to waves," >> Nahhas told OTV, adding that an investigation was underway to find out >> whether this act is "intentional or not." > > >also at >http://www.naharnet.com/domino/tn/NewsDesk.nsf/Lebanon/EFCEF203B3C315A5C225782E0020C75F From jamie at photon.com Mon Feb 7 08:25:01 2011 From: jamie at photon.com (Jamie Bowden) Date: Mon, 7 Feb 2011 09:25:01 -0500 Subject: What's really needed is a routing slot market (was: Using IPv6 withprefixes shorter than a /64 on a LAN) In-Reply-To: References: <4D3F0144.70107@sohonet.co.uk><58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com><20110126043722.GA4110@skywalker.creative.net.au><1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar><4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org><4D4C0D25.70408@brightok.net><20110204231134.3AA029B2B39@drugs.dv.isc.org><4D4C8AF8.1030703@brightok.net><20110205004517.371F99B3B3C@drugs.dv.isc.org><4D4CA1B1.5060002@brightok.net><20110205124710.059259B4E31@drugs.dv.isc.org><4D4D5FFC.6020905@brightok.net><20110206010145.9DCD99B60B9@drugs.dv.isc.org><4D4DF75E.1040109@brightok.net><20110206024051.D60349B6D50@drugs.dv.isc.org> Message-ID: <5C836A1A98186142A6BEC393FD5E2A8601579F@hal.photon.com> It would help if we weren't shipping the routing equivalent of the pre DNS /etc/hosts all over the network (it's automated, but it's still the equivalent). There has to be a better way to handle routing information than what's currently being done. The old voice telephony guys built a system that built SVCs on the fly from any phone in the world to any other phone in the world; it (normally) took less than a second for it to do it between any pair of phones under the NANPA, and only slightly longer for international outside the US and Canada. There have to be things to be learned from there. Jamie -----Original Message----- From: John Curran [mailto:jcurran at istaff.org] Sent: Sunday, February 06, 2011 11:00 AM To: Mark Andrews Cc: NANOG list Subject: What's really needed is a routing slot market (was: Using IPv6 withprefixes shorter than a /64 on a LAN) On Feb 5, 2011, at 9:40 PM, Mark Andrews wrote: > What's really needed is seperate the routing slot market from the > address allocation market. Bingo! In fact, having an efficient market for obtaining routing of a given prefix, combined with IPv6 vast identifier space, could actually satisfy the primary goals that we hold for a long-term scalable address architecture, and enable doing it in a highly distributed, automatable fashion: Aggregation would be encouraged, since use of non-aggregatable address space would entail addition costs. These costs might be seen as minimal for some organizations that desire addressing autonomy, but others might decide treating their address space portable and routable results in higher cost than is desired. Decisions about changing prefixes with ISPs can be made based on a rational tradeoff of costs, rather than in a thicket of ISP and registry policies. Conservation would actually be greatly improved, since address space would only be sought after because of the need for additional unique identifiers, rather than obtaining an address block of a given size to warrant implied routability. In light of IPv6's vast address space, it actually would be possible to provide minimally-sized but assured unique prefixes automatically via nearly any mechanism (i.e. let your local user or trade association be a registry if they want) With a significantly reduced policy framework, Registration could be fully automated, with issuance being as simple as assurance the right level of verification of requester identity (You might even get rid of this, if you can assure that ISPs obtain clear identity of clients before serving them but that would preclude any form of reputation systems based on IP address prefix such as we have in use today...) Just think: the savings in storage costs alone (from the reduction in address policy-related email on all our mailing lists) could probably fund the system. :-) Oh well, one project at a time... /John From jra at baylink.com Mon Feb 7 10:15:51 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 7 Feb 2011 11:15:51 -0500 (EST) Subject: Failure modes: NAT vs SPI In-Reply-To: Message-ID: <25213878.5499.1297095351131.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Iljitsch van Beijnum" > On 4 feb 2011, at 22:02, Dave Cardwell wrote: > > Without wanting to get into whether NAT provides security to hosts > > that exist on the inside. I am curious if the potential to overflow > > ND caches with incomplete* entries exists on currently shipping CPE > > hardware and if NAT helps prevent this? > > > e.g. > > In v4 with a /24 on the inside an attacker can send a single packet to > > each consecutive address causing at most 254 arp requests to be sent > > on the lan segment and upto 253 incomplete entries, until they > > timeout. > > In v6 with a /64 on the inside it seems like the same tactic would > > lead to more outstanding ND requests than any realistically sized > > cache would support. > > Ok, I had a hard time making up my mind whether a sarcastic or a > factual response was in order... I see you decided to go with "sarcastic". > This is of course a very big problem, and one of the reasons why > everyone who's tried IPv6 immediately turns it off again: script > kiddies are continuously scanning the entire IPv6 address space so > this happens to regular IPv6 users all the time. I'm sure it's clear to you that "no one's doing it now" is not a valid response to prophylactic secure network planning... > Since this is a problem that is inherent to the ND protocol that is > impossible to fix without modifying the IPv6 standards significantly, > the easiest way to solve this with the least amount of impact to > applications, the ability to host services and the end-to-end model in > particular is to use a single public IPv6 address and NAT all local > stuff behind it. So, you're not going to actually address the problem seriously? Got it. Cheers, -- jra From andrea at ripe.net Mon Feb 7 03:31:06 2011 From: andrea at ripe.net (Andrea Cima) Date: Mon, 07 Feb 2011 10:31:06 +0100 Subject: New IPv4 block allocated to RIPE NCC Message-ID: <4D4FBBDA.8040704@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [Apologies for duplicate mails] Dear Colleagues, The RIPE NCC has received the IPv4 address range 185/8 from the IANA. This is the final allocation of IPv4 address space that the RIPE NCC will receive from the IANA as stated in ripe-436, "Global Policy for the Allocation of the Remaining IPv4 Address Space". The minimum allocation size for this /8 has been set at /22. You may wish to adjust any filters you have in place accordingly. More information on the IP address space administered by the RIPE NCC can be found on our website at: https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html Additionally, please note that three "pilot" prefixes will be announced from this /8. The prefixes are: 185.0.0.0/16 185.1.0.0/21 185.1.24.0/24 They all originate in AS12654. The pingable addresses will be: 185.0.0.1 185.1.0.1 185.1.24.1 More information on this activity is available in the document "De-Bogonising New Address Blocks", which can be found at: http://www.ripe.net/ripe/docs/ripe-351.html Kind regards, Andrea Cima Registration Services Manager RIPE NCC -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAk1Pu9kACgkQXOgsmPkFrjM9FgCgsaT8cFxK0YKTFUFzj41L0PQT N1AAoIgmL1zUY8JjkCSa05xt0t8oppgP =woX5 -----END PGP SIGNATURE----- From bill at herrin.us Mon Feb 7 10:30:05 2011 From: bill at herrin.us (William Herrin) Date: Mon, 7 Feb 2011 11:30:05 -0500 Subject: What's really needed is a routing slot market (was: Using IPv6 withprefixes shorter than a /64 on a LAN) In-Reply-To: <5C836A1A98186142A6BEC393FD5E2A8601579F@hal.photon.com> References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org> <4D4C0D25.70408@brightok.net> <20110204231134.3AA029B2B39@drugs.dv.isc.org> <4D4C8AF8.1030703@brightok.net> <20110205004517.371F99B3B3C@drugs.dv.isc.org> <4D4CA1B1.5060002@brightok.net> <20110205124710.059259B4E31@drugs.dv.isc.org> <4D4D5FFC.6020905@brightok.net> <20110206010145.9DCD99B60B9@drugs.dv.isc.org> <4D4DF75E.1040109@brightok.net> <20110206024051.D60349B6D50@drugs.dv.isc.org> <5C836A1A98186142A6BEC393FD5E2A8601579F@hal.photon.com> Message-ID: On Mon, Feb 7, 2011 at 9:25 AM, Jamie Bowden wrote: > It would help if we weren't shipping the routing equivalent of the pre > DNS /etc/hosts all over the network (it's automated, but it's still the > equivalent). ?There has to be a better way to handle routing information > than what's currently being done. Hi Jamie, Consensus in the routing research arena is that it's a layer boundary problem. Layer 4/5 (TCP, various UDP-based protocols) intrudes to deeply into layer 3. Sessions are statically bound at creation to the layer 3 address. Unlike the dynamic MAC to IP bindings (with ARP) the TCP to IP bindings can't change during the potentially long-lived session. Thus route proliferation is needed to maintain them. Much better routing protocols are possible, but you first either have to break layer 3 in half (with a dynamic binding between the two halves that renders the lower half inaccessible to layer 4) or you have to redesign TCP with dynamic bindings to the layer 3 address. Ideas like LISP take the former approach. Ideas like SCTP and Multipath TCP take the latter. The deployment prospects are not promising. Modest improvements like FIB compression are in the pipeline for DFZ routing, but don't expect any earth shattering improvements. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From lowen at pari.edu Mon Feb 7 10:31:20 2011 From: lowen at pari.edu (Lamar Owen) Date: Mon, 7 Feb 2011 11:31:20 -0500 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <9FCDBED3-FA1E-47F2-8939-A083B1CA0E2B@cisco.com> References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> Message-ID: <201102071131.20271.lowen@pari.edu> On Saturday, February 05, 2011 11:29:44 pm Fred Baker wrote: > To survive an EMP, electronics needs some fancy circuitry. I've never worked with a bit of equipment that had it. It would therefore have to have been through path redundancy. Surviving EMP is similar to surviving several (dozen) direct lightning strikes, and requires the same sort of protection, both in terms of shielding and in terms of filtering, as well as the methods used for connections, etc. There is plenty of documentation out there on how to do this, even with commercial stuff, if you look. The biggest issue in EMP is power, however, since the grid in the affected area will likely be down. From drc at virtualized.org Mon Feb 7 10:40:55 2011 From: drc at virtualized.org (David Conrad) Date: Mon, 7 Feb 2011 06:40:55 -1000 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <20110205193328.GC22325@vacation.karoshi.com> <08F8827D-D8C3-4922-AC39-6C71ADBE8BDB@corp.arin.net> <20110206014014.GG22325@vacation.karoshi.com> <849FDB3F-EE29-48D6-8ECD-70AE6EB0B157@virtualized.org> <585A8651-6C2E-4B16-9D03-6C756CC9E77D@arin.net> <57B939FE-3B74-4B70-8AD5-71176551C2BF@virtualized.org> <302202D5-A0C2-4BD9-B08B-A376A3174926@arin.net> Message-ID: <8FF448C1-C0CA-4C9F-B843-1D7AD81A2DBF@virtualized.org> On Feb 6, 2011, at 2:51 PM, Randy Bush wrote: > it is both amusing and horrifying to watch two old dogs argue about > details of written rules as if common sense had died in october 1998. http://xkcd.com/386/ > what is good for the internet? what is simple? what is pragmatic? if > the answer is not simple and obvious, we should go break something else. As would seem apparent, what is simple and obvious to some may be insane and Byzantine to others. Increasingly nteresting times. Regards, -drc From Valdis.Kletnieks at vt.edu Mon Feb 7 10:43:44 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 07 Feb 2011 11:43:44 -0500 Subject: Failure modes: NAT vs SPI In-Reply-To: Your message of "Mon, 07 Feb 2011 11:15:51 EST." <25213878.5499.1297095351131.JavaMail.root@benjamin.baylink.com> References: <25213878.5499.1297095351131.JavaMail.root@benjamin.baylink.com> Message-ID: <28579.1297097024@localhost> On Mon, 07 Feb 2011 11:15:51 EST, Jay Ashworth said: > > From: "Iljitsch van Beijnum" > > This is of course a very big problem, and one of the reasons why > > everyone who's tried IPv6 immediately turns it off again: script > > kiddies are continuously scanning the entire IPv6 address space so > > this happens to regular IPv6 users all the time. > > I'm sure it's clear to you that "no one's doing it now" is not a valid > response to prophylactic secure network planning... Iljitsch's claim is that enough script kiddies *are* doing it now that people's routers crash and they turn off IPv6, not that "people are so scare of it they panic and turn it off before they see if it's a problem". For what it's worth, I've never seen an IPv6 scan cause a problem for our network. Not saying that such a scan *wouldn't* cause a problem, but the fact we've been doing it for over a decade and not seen a big problem seems to go counter to "everyone who turns on IPv6 gets hit by it". -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jbates at brightok.net Mon Feb 7 10:47:47 2011 From: jbates at brightok.net (Jack Bates) Date: Mon, 07 Feb 2011 10:47:47 -0600 Subject: What's really needed is a routing slot market In-Reply-To: References: <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org> <4D4C0D25.70408@brightok.net> <20110204231134.3AA029B2B39@drugs.dv.isc.org> <4D4C8AF8.1030703@brightok.net> <20110205004517.371F99B3B3C@drugs.dv.isc.org> <4D4CA1B1.5060002@brightok.net> <20110205124710.059259B4E31@drugs.dv.isc.org> <4D4D5FFC.6020905@brightok.net> <20110206010145.9DCD99B60B9@drugs.dv.isc.org> <4D4DF75E.1040109@brightok.net> <20110206024051.D60349B6D50@drugs.dv.isc.org> <5C836A1A98186142A6BEC393FD5E2A8601579F@hal.photon.com> Message-ID: <4D502233.8070207@brightok.net> On 2/7/2011 10:30 AM, William Herrin wrote: > Ideas like LISP take the former approach. Ideas like SCTP and > Multipath TCP take the latter. The deployment prospects are not > promising. I'm rusty on LISP, but I believe it was designed to solve the DFZ problem itself, while SCTP and Multipath TCP solve issues such as being able to change the layer3 address on an existing connection (supporting rapid renumbering and multipath failover/loadbalancing utilizing multiple layer 3 addresses (1 per path). In an ideal world, we'd be using both. Jack From jbates at brightok.net Mon Feb 7 10:52:57 2011 From: jbates at brightok.net (Jack Bates) Date: Mon, 07 Feb 2011 10:52:57 -0600 Subject: Failure modes: NAT vs SPI In-Reply-To: <28579.1297097024@localhost> References: <25213878.5499.1297095351131.JavaMail.root@benjamin.baylink.com> <28579.1297097024@localhost> Message-ID: <4D502369.7070901@brightok.net> On 2/7/2011 10:43 AM, Valdis.Kletnieks at vt.edu wrote: > For what it's worth, I've never seen an IPv6 scan cause a problem for our > network. Not saying that such a scan*wouldn't* cause a problem, but the fact > we've been doing it for over a decade and not seen a big problem seems to go > counter to "everyone who turns on IPv6 gets hit by it". I think it becomes a problem only in certain architectures. ie, providing /64 subnets without SPI can lead to a scan actually able to create effect ND. This implies that many networks aren't necessarily effected by it, as they implement a certain level of security. I'd also surmise that IPv6 scanning isn't as prevalent today as it will be at some point. Nachi was an interesting (even if illegal) concept except for being overly aggressive. Jack From sethm at rollernet.us Mon Feb 7 12:17:42 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 07 Feb 2011 10:17:42 -0800 Subject: It's the end of IPv4 as we know it... and I feel fine.. In-Reply-To: References: <532030EB-3A85-4E86-ACEC-ED273183BE3C@puck.nether.net> <4D4AD77A.4050705@rollernet.us> Message-ID: <4D503746.103@rollernet.us> On 2/3/2011 08:38, Josh Smith wrote: > Seth, > What sort of ISP do your "not technically inclined" parents have that > offers native ipv6? :-) > I'm doing it via fixed wireless. They'll actually be my second access customer to get native IPv6. My parents are a good test case for the kind of user who doesn't care about the difference between IPv4 or IPv6 or the debates whether to /64 or not, only that the internet works. ~Seth From joshua.klubi at gmail.com Mon Feb 7 12:18:23 2011 From: joshua.klubi at gmail.com (Joshua William Klubi) Date: Mon, 7 Feb 2011 18:18:23 +0000 Subject: Web Server and Firewall Hellp Message-ID: Hi, I run a web-server based on ubuntu server and the LAMP stack. I used Ubuntu's UFW firewall model and have enabled only Web and SSH ports. Namely port 80 and port 22 only. Unfortunately once a while some guys get to inject some content onto our web pages. Now managements are looking at getting a well proven infrastructure to counter that. But I also think i can fall on this community to help me get the right stuff done. Where i can protect the server from such attack. I want to know what measure i can do on the server to get it protected which mysql protection I should implement. since i can see that it might be a php or mysql injection that is been used. Currently I run these security measures on it. Ubuntu UFW Fail2ban PHP model security Apache security Joshua From joshua.klubi at gmail.com Mon Feb 7 12:23:17 2011 From: joshua.klubi at gmail.com (Joshua William Klubi) Date: Mon, 7 Feb 2011 18:23:17 +0000 Subject: WebServer and Firewall Help Message-ID: Hi, I run a web-server based on ubuntu server and the LAMP stack. I used Ubuntu's UFW firewall model and have enabled only Web and SSH ports. Namely port 80 and port 22 only. Unfortunately once a while some guys get to inject some content onto our web pages. Now managements are looking at getting a well proven infrastructure to counter that. But I also think i can fall on this community to help me get the right stuff done. Where i can protect the server from such attack. I want to know what measure i can do on the server to get it protected which mysql protection I should implement. since i can see that it might be a php or mysql injection that is been used. Currently I run these security measures on it. Ubuntu UFW Fail2ban PHP model security Apache security Joshua From randy at psg.com Mon Feb 7 12:25:06 2011 From: randy at psg.com (Randy Bush) Date: Mon, 07 Feb 2011 10:25:06 -0800 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <29A461FE-306C-4536-93DF-73B6BD4C13B0@arin.net> References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <20110205193328.GC22325@vacation.karoshi.com> <08F8827D-D8C3-4922-AC39-6C71ADBE8BDB@corp.arin.net> <20110206014014.GG22325@vacation.karoshi.com> <849FDB3F-EE29-48D6-8ECD-70AE6EB0B157@virtualized.org> <585A8651-6C2E-4B16-9D03-6C756CC9E77D@arin.net> <57B939FE-3B74-4B70-8AD5-71176551C2BF@virtualized.org> <302202D5-A0C2-4BD9-B08B-A376A3174926@arin.net> <29A461FE-306C-4536-93DF-73B6BD4C13B0@arin.net> Message-ID: > So, what exactly is broken and needs to be changed? the policy making process. we have created a minor industry in telling other people how to run their network. how about no more ipv4 policy proposals and charge $1,000 to file an ipv6 policy proposal? randy From tshaw at oitc.com Mon Feb 7 12:26:39 2011 From: tshaw at oitc.com (TR Shaw) Date: Mon, 7 Feb 2011 13:26:39 -0500 Subject: Web Server and Firewall Hellp In-Reply-To: References: Message-ID: On Feb 7, 2011, at 1:18 PM, Joshua William Klubi wrote: > Hi, > > I run a web-server based on ubuntu server and the LAMP stack. > I used Ubuntu's UFW firewall model and have enabled only Web and SSH ports. > Namely port 80 and port 22 only. > > Unfortunately once a while some guys get to inject some content onto our web > pages. > > Now managements are looking at getting a well proven infrastructure to > counter that. > But I also think i can fall on this community to help me get the right stuff > done. Where > i can protect the server from such attack. > > > I want to know what measure i can do on the server to get it protected which > mysql protection > I should implement. since i can see that it might be a php or mysql > injection that is been used. > > Currently I run these security measures on it. > Ubuntu UFW > Fail2ban > PHP model security > Apache security Josh Patch your lamps , collab env, builtin boards and everything, make sure mySQL has a password on it since it doesn't out of the box, also update all passwords to hard ones and change all updates in the future to not use ftp first. Close firewall ports you are not useing and then check your logs to see what vulnerabilities you still have if any. Tom From petermaccauley at yahoo.com Mon Feb 7 12:27:29 2011 From: petermaccauley at yahoo.com (Peter Maccauley) Date: Mon, 7 Feb 2011 10:27:29 -0800 (PST) Subject: "Leasing" of space via non-connectivity providers Message-ID: <727377.55500.qm@web120703.mail.ne1.yahoo.com> All this talk of ARIN's power and rights versus others is rather despairing. I will now explain what we, a 'non-connectivity' ISP, are providing as useful service. Many of customers value anonymity/pseudonymity. We can provide these things. Sure, there is a great potential for abuse, but we take steps to prevent this, such as careful control over port 25. Our customers can appear on the net from one of several IPv4 addresses in various places, which can be used for testing location-based services. Yes, this could be abused. We can aggregate broadband connections at our router, or provide instant switchover. This is useful for various people and organizations which have to use low-grade broadband (consumer quality, or often consumer quality relabeled 'business' and sold at a higher price). We find a way for people to use their legacy space. A few hobbyist types with their legacy Class Cs are customers. We've managed to get around some censorship blocks. Private http proxies to facebook/youtube and other less-known sites have an IP in some of our space. This is not saying these named organizations are our customers (nor am I saying they are not). We remain quiet at the moment because we do not have the infrastructure in place to handle any more traffic than the people who have found out about us by word-of-mouth. Maintaining a low profile also allows us to escape being added to lists of those censors of one type or another. It has allowed us to avoid spammers, thieves and crackers as customers I hope that many of you will see our use of IP space as a legitimate one. Like many of the rest of you, we provide services which may be valuable to spammers/crackers, but this doesn't mean we're in bed with them. If ARIN/RIPE etc ever decide to edit their databases in a way that interferes with our valuable services, I hope that some of you will raise an alarm in our defense. From khelms at ispalliance.net Mon Feb 7 12:47:58 2011 From: khelms at ispalliance.net (Scott Helms) Date: Mon, 07 Feb 2011 13:47:58 -0500 Subject: It's the end of IPv4 as we know it... and I feel fine.. In-Reply-To: <4D503746.103@rollernet.us> References: <532030EB-3A85-4E86-ACEC-ED273183BE3C@puck.nether.net> <4D4AD77A.4050705@rollernet.us> <4D503746.103@rollernet.us> Message-ID: <4D503E5E.5000300@ispalliance.net> On 2/7/2011 1:17 PM, Seth Mattinen wrote: > On 2/3/2011 08:38, Josh Smith wrote: >> Seth, >> What sort of ISP do your "not technically inclined" parents have that >> offers native ipv6? :-) >> > > I'm doing it via fixed wireless. They'll actually be my second access > customer to get native IPv6. My parents are a good test case for the > kind of user who doesn't care about the difference between IPv4 or IPv6 > or the debates whether to /64 or not, only that the internet works. > > ~Seth > > Ahh, that makes them like 99.99% of all retail internet users. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From randy at psg.com Mon Feb 7 12:54:37 2011 From: randy at psg.com (Randy Bush) Date: Mon, 07 Feb 2011 10:54:37 -0800 Subject: US Warships jamming Lebanon Internet In-Reply-To: <201102071339.27793.denys@visp.net.lb> References: <201102071339.27793.denys@visp.net.lb> Message-ID: i can not ping the in-country secondries for the LB cctld. been the same for a few days. i visited last (northern) fall. what a beautiful country with such a tragic layer nine. randy From brandon.kim at brandontek.com Mon Feb 7 13:36:29 2011 From: brandon.kim at brandontek.com (Brandon Kim) Date: Mon, 7 Feb 2011 14:36:29 -0500 Subject: Web Server and Firewall Hellp In-Reply-To: References: , Message-ID: If you're getting SQL injections through your website, then you have to look at the programming of your website. It has nothing to do with your firewall. Definitely patch and update all your software running LAMP, but also have to check how you allow input on your websites..... > Subject: Re: Web Server and Firewall Hellp > From: tshaw at oitc.com > Date: Mon, 7 Feb 2011 13:26:39 -0500 > To: joshua.klubi at gmail.com > CC: nanog at nanog.org > > > On Feb 7, 2011, at 1:18 PM, Joshua William Klubi wrote: > > > Hi, > > > > I run a web-server based on ubuntu server and the LAMP stack. > > I used Ubuntu's UFW firewall model and have enabled only Web and SSH ports. > > Namely port 80 and port 22 only. > > > > Unfortunately once a while some guys get to inject some content onto our web > > pages. > > > > Now managements are looking at getting a well proven infrastructure to > > counter that. > > But I also think i can fall on this community to help me get the right stuff > > done. Where > > i can protect the server from such attack. > > > > > > I want to know what measure i can do on the server to get it protected which > > mysql protection > > I should implement. since i can see that it might be a php or mysql > > injection that is been used. > > > > Currently I run these security measures on it. > > Ubuntu UFW > > Fail2ban > > PHP model security > > Apache security > > Josh > > Patch your lamps , collab env, builtin boards and everything, make sure mySQL has a password on it since it doesn't out of the box, also update all passwords to hard ones and change all updates in the future to not use ftp first. Close firewall ports you are not useing and then check your logs to see what vulnerabilities you still have if any. > > Tom > > From joe.abley at icann.org Mon Feb 7 13:41:59 2011 From: joe.abley at icann.org (Joe Abley) Date: Mon, 07 Feb 2011 19:41:59 +0000 Subject: Root Zone DNSSEC KSK Ceremony 4 Message-ID: KSK CEREMONY 4 The fourth KSK ceremony for the root zone will take place in El Segundo, CA, USA on Monday 2011-02-07. The ceremony is scheduled to begin at 1300 local time (1700 UTC) and is expected to end by 1900 local time (2300 UTC). Video from Ceremony 4 will be recorded for audit purposes. Video and associated audit materials will be published 1 to 2 weeks after the ceremony, and will be available as usual by following the "KSK Ceremony Materials" link at . ICANN will operate a separate camera whose video will not be retained for audit purposes, but which will instead be streamed live in order to provide remote observers an opportunity to watch the ceremony. The live stream will be provided on a best-effort basis. The live video stream will be available at . Ceremony 4 will include processing of a Key Signing Request (KSR) generated by VeriSign, and the resulting Signed Key Response (SKR) will contain signatures for Q2 2011, for use in the root zone between 2011-04-01 and 2011-07-05. CONTACT INFORMATION We'd like to hear from you. If you have feedback for us, please send it to rootsign at icann.org. From joe.abley at icann.org Mon Feb 7 13:46:06 2011 From: joe.abley at icann.org (Joe Abley) Date: Mon, 07 Feb 2011 19:46:06 +0000 Subject: Root Zone DNSSEC KSK Ceremony 4 (UTC correction) Message-ID: > KSK CEREMONY 4 > > The fourth KSK ceremony for the root zone will take place in El > Segundo, CA, USA on Monday 2011-02-07. The ceremony is scheduled > to begin at 1300 local time (1700 UTC) and is expected to end by > 1900 local time (2300 UTC). Apologies for the time zone miscalculation. El Segundo is in the Pacific time zone, UTC-8. The ceremony is scheduled to begin at 1300 local time (2100 UTC) and is expected to end by 1900 local time (2011-02-08 0300 UTC). Joe From if at xip.at Mon Feb 7 14:00:46 2011 From: if at xip.at (Ingo Flaschberger) Date: Mon, 7 Feb 2011 21:00:46 +0100 (CET) Subject: Web Server and Firewall Hellp In-Reply-To: References: , Message-ID: >>> I run a web-server based on ubuntu server and the LAMP stack. >>> I used Ubuntu's UFW firewall model and have enabled only Web and SSH ports. >>> Namely port 80 and port 22 only. >>> >>> Unfortunately once a while some guys get to inject some content onto our web >>> pages. >>> >>> Now managements are looking at getting a well proven infrastructure to >>> counter that. >>> But I also think i can fall on this community to help me get the right stuff >>> done. Where >>> i can protect the server from such attack. >>> >>> >>> I want to know what measure i can do on the server to get it protected which >>> mysql protection >>> I should implement. since i can see that it might be a php or mysql >>> injection that is been used. >>> >>> Currently I run these security measures on it. >>> Ubuntu UFW >>> Fail2ban >>> PHP model security >>> Apache security have a look at mod_security, helps very successfull against outdated, exploitable user webpages. mod_security ist a layer 7 firewall wich runs as a apache module. Kind regards, Ingo Flaschberger From owen at delong.com Mon Feb 7 14:04:06 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 7 Feb 2011 12:04:06 -0800 Subject: What's really needed is a routing slot market (was: Using IPv6 withprefixes shorter than a /64 on a LAN) In-Reply-To: References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org> <4D4C0D25.70408@brightok.net> <20110204231134.3AA029B2B39@drugs.dv.isc.org> <4D4C8AF8.1030703@brightok.net> <20110205004517.371F99B3B3C@drugs.dv.isc.org> <4D4CA1B1.5060002@brightok.net> <20110205124710.059259B4E31@drugs.dv.isc.org> <4D4D5FFC.6020905@brightok.net> <20110206010145.9DCD99B60B9@drugs.dv.isc.org> <4D4DF75E.1040109@brightok.net> <20110206024051.D60349B6D50@drugs.dv.isc.org> <5C836A1A98186142A6BEC393FD5E2A8601579F@! hal.photon.com> Message-ID: On Feb 7, 2011, at 8:30 AM, William Herrin wrote: > On Mon, Feb 7, 2011 at 9:25 AM, Jamie Bowden wrote: >> It would help if we weren't shipping the routing equivalent of the pre >> DNS /etc/hosts all over the network (it's automated, but it's still the >> equivalent). There has to be a better way to handle routing information >> than what's currently being done. > > Hi Jamie, > > Consensus in the routing research arena is that it's a layer boundary > problem. Layer 4/5 (TCP, various UDP-based protocols) intrudes to > deeply into layer 3. Sessions are statically bound at creation to the > layer 3 address. Unlike the dynamic MAC to IP bindings (with ARP) the > TCP to IP bindings can't change during the potentially long-lived > session. Thus route proliferation is needed to maintain them. > > Much better routing protocols are possible, but you first either have > to break layer 3 in half (with a dynamic binding between the two > halves that renders the lower half inaccessible to layer 4) or you > have to redesign TCP with dynamic bindings to the layer 3 address. > Ideas like LISP take the former approach. Ideas like SCTP and > Multipath TCP take the latter. The deployment prospects are not > promising. > > Modest improvements like FIB compression are in the pipeline for DFZ > routing, but don't expect any earth shattering improvements. > On the other hand, when we can deprecate global routing of IPv4, we will see an earth shattering improvement as the current 10:1 prefix to provider ratio (300,000 prefixes for ~30,000 active ASNs) drops to something more like 2:1 in IPv6 due to providers not having to constantly run back to the RIR for additional slow-start allocations. Owen From mpetach at netflight.com Mon Feb 7 14:19:16 2011 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 7 Feb 2011 12:19:16 -0800 Subject: What's really needed is a routing slot market (was: Using IPv6 withprefixes shorter than a /64 on a LAN) In-Reply-To: References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org> <4D4C0D25.70408@brightok.net> <20110204231134.3AA029B2B39@drugs.dv.isc.org> <4D4C8AF8.1030703@brightok.net> <20110205004517.371F99B3B3C@drugs.dv.isc.org> <4D4CA1B1.5060002@brightok.net> <20110205124710.059259B4E31@drugs.dv.isc.org> <4D4D5FFC.6020905@brightok.net> <20110206010145.9DCD99B60B9@drugs.dv.isc.org> <4D4DF75E.1040109@brightok.net> <20110206024051.D60349B6D50@drugs.dv.isc.org> Message-ID: On Mon, Feb 7, 2011 at 12:04 PM, Owen DeLong wrote: > ... > On the other hand, when we can deprecate global routing of IPv4, we > will see an earth shattering improvement as the current 10:1 prefix > to provider ratio (300,000 prefixes for ~30,000 active ASNs) drops > to something more like 2:1 in IPv6 due to providers not having to > constantly run back to the RIR for additional slow-start allocations. > > Owen I suspect as we start seeing the CIDR report for IPv6, we'll see that ASNs are announcing considerably more prefixes than that, in order to localize traffic better. I don't think it'll be 300,000 prefixes, but I'd be willing to bet it'll be more than 100,000--not exactly "earth shattering improvement". Matt (hopeless deaggregator) From owen at delong.com Mon Feb 7 14:40:41 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 7 Feb 2011 12:40:41 -0800 Subject: Membership model Message-ID: <393F6490-A035-4A3B-853D-8F8DAC8C9981@delong.com> I'll happily join Newnog/NANOG and pay my dues when I can reach the web site to do so on IPv6 rather than legacy IPv4. Owen From owen at delong.com Mon Feb 7 14:44:39 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 7 Feb 2011 12:44:39 -0800 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <20110205193328.GC22325@vacation.karoshi.com> <08F8827D-D8C3-4922-AC39-6C71ADBE8BDB@corp.arin.net> <20110206014014.GG22325@vacation.karoshi.com> <849FDB3F-EE29-48D6-8ECD-70AE6EB0B157@virtualized.org> <585A8651-6C2E-4B16-9D03-6C756CC9E77D@arin.net> <57B939FE-3B74-4B70-8AD5-71176551C2BF@virtualized.org> <302202D5-A0C2-4BD9-B08B-A376A3174926@arin.net> <29A461FE-306C-4536-93DF-73B6BD4C13B0@arin.net> Message-ID: <347DA9A9-28AB-41A7-B6A6-5F6A723DE4F8@delong.com> On Feb 7, 2011, at 10:25 AM, Randy Bush wrote: >> So, what exactly is broken and needs to be changed? > > the policy making process. we have created a minor industry in telling > other people how to run their network. > > how about no more ipv4 policy proposals and charge $1,000 to file an > ipv6 policy proposal? > > randy If you believe this is a good idea, submit it to ARIN Consultation and Suggestion Process. If not, then I'm willing to bet you could actually find something more constructive to do than making comments like this. Owen From kris.foster at gmail.com Mon Feb 7 14:49:51 2011 From: kris.foster at gmail.com (kris foster) Date: Mon, 7 Feb 2011 12:49:51 -0800 Subject: Membership model In-Reply-To: <393F6490-A035-4A3B-853D-8F8DAC8C9981@delong.com> References: <393F6490-A035-4A3B-853D-8F8DAC8C9981@delong.com> Message-ID: <4848CCA3-82E1-44E6-A18C-FBC913BF89FE@gmail.com> On Feb 7, 2011, at 12:40 PM, Owen DeLong wrote: > I'll happily join Newnog/NANOG and pay my dues when I can reach the web site to do so > on IPv6 rather than legacy IPv4. http://newnog.org/wg.php I'm sure the technical WG will be happy to hear you're volunteering. -- kris From iljitsch at muada.com Mon Feb 7 15:07:26 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 7 Feb 2011 22:07:26 +0100 Subject: Failure modes: NAT vs SPI In-Reply-To: <25213878.5499.1297095351131.JavaMail.root@benjamin.baylink.com> References: <25213878.5499.1297095351131.JavaMail.root@benjamin.baylink.com> Message-ID: <71F9B75F-3A87-4EAA-97CB-A4B7D8066557@muada.com> On 7 feb 2011, at 17:15, Jay Ashworth wrote: >> Ok, I had a hard time making up my mind whether a sarcastic or a >> factual response was in order... > I see you decided to go with "sarcastic". Not sure if Owen noticed... :-) > I'm sure it's clear to you that "no one's doing it now" is not a valid > response to prophylactic secure network planning... Well, no and yes. There's only a few panes of glass keeping people out of most houses. We know glass is easy to break. We know it gets broken and people get in who aren't wanted there once in a while. Still only a few people see the need to install steel bars in front of their windows. In real life we take risks all the time. In the networked world somehow it always has to be all or nothing, with few people occupying the reasonable middle ground. But in this case, we know there's a potential problem and waiting for it to become acute is not the best approach. > So, you're not going to actually address the problem seriously? Vendors should modify their neighbor discovery implementations such that it still works even when large numbers of addresses are scanned. The easiest way would be to keep only a limited number of incomplete ND cache entries and throw those away on an LRU base, but create a full ND cache entry that is kept around when a neighbor advertisement is received, even if there is no incomplete ND cache entry at that time. AFAIK the incomplete ND cache entries don't do anything we can't do without. "Solving" this with NAT is the classic example of shooting a mosquito with a canon. I also don't think any protocol modifications are necessary. From owen at delong.com Mon Feb 7 15:10:07 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 7 Feb 2011 13:10:07 -0800 Subject: What's really needed is a routing slot market (was: Using IPv6 withprefixes shorter than a /64 on a LAN) In-Reply-To: References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org> <4D4C0D25.70408@brightok.net> <20110204231134.3AA029B2B39@drugs.dv.isc.org> <4D4C8AF8.1030703@brightok.net> <20110205004517.371F99B3B3C@drugs.dv.isc.org> <4D4CA1B1.5060002@brightok.net> <20110205124710.059259B4E31@drugs.dv.isc.org> <4D4D5FFC.6020905@brightok.net> <20110206010145.9DCD99B60B9@drugs.dv.isc.org> <4D4DF75E.1040109@brightok.net> <20110206024051.D60349B6D50@drugs.dv.isc.org> Message-ID: On Feb 7, 2011, at 12:19 PM, Matthew Petach wrote: > On Mon, Feb 7, 2011 at 12:04 PM, Owen DeLong wrote: >> > ... >> On the other hand, when we can deprecate global routing of IPv4, we >> will see an earth shattering improvement as the current 10:1 prefix >> to provider ratio (300,000 prefixes for ~30,000 active ASNs) drops >> to something more like 2:1 in IPv6 due to providers not having to >> constantly run back to the RIR for additional slow-start allocations. >> >> Owen > > I suspect as we start seeing the CIDR report for IPv6, we'll see that > ASNs are announcing considerably more prefixes than that, in order > to localize traffic better. I don't think it'll be 300,000 prefixes, but > I'd be willing to bet it'll be more than 100,000--not exactly "earth > shattering improvement". > > Matt > (hopeless deaggregator) Currently: 3,134 IPv6 ASNs active. Currently: 4,265 IPv6 prefixes. Looks like less than 2:1 to me. That's as close as I think I can get to an IPv6 CIDR report for the moment. Owen From packetgrrl at gmail.com Mon Feb 7 15:25:56 2011 From: packetgrrl at gmail.com (cja@daydream.com) Date: Mon, 7 Feb 2011 14:25:56 -0700 Subject: What's really needed is a routing slot market (was: Using IPv6 withprefixes shorter than a /64 on a LAN) In-Reply-To: References: <4D3F0144.70107@sohonet.co.uk> <58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com> <20110126043722.GA4110@skywalker.creative.net.au> <1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar> <4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org> <4D4C0D25.70408@brightok.net> <20110204231134.3AA029B2B39@drugs.dv.isc.org> <4D4C8AF8.1030703@brightok.net> <20110205004517.371F99B3B3C@drugs.dv.isc.org> <4D4CA1B1.5060002@brightok.net> <20110205124710.059259B4E31@drugs.dv.isc.org> <4D4D5FFC.6020905@brightok.net> <20110206010145.9DCD99B60B9@drugs.dv.isc.org> <4D4DF75E.1040109@brightok.net> <20110206024051.D60349B6D50@drugs.dv.isc.org> Message-ID: If you look at Gert Doering's slides that I presented at NANOG (in the IPv6 Deployment Experiences track) I believe it is 1.4 prefixes per ASN in IPv6 and something like 10.5 prefixes per ASN in IPv4. There are also descriptions of the reasons for some of these multiple advertisements in IPv6 as well as how many ASNs have just one and how many have 2 etc. The slides are here http://www.nanog.org/meetings/nanog51/presentations/Monday/NANOG51.Talk13.Aronson-doring-v6-table.pdf Enjoy! -----Cathy On Mon, Feb 7, 2011 at 2:10 PM, Owen DeLong wrote: > > On Feb 7, 2011, at 12:19 PM, Matthew Petach wrote: > > > On Mon, Feb 7, 2011 at 12:04 PM, Owen DeLong wrote: > >> > > ... > >> On the other hand, when we can deprecate global routing of IPv4, we > >> will see an earth shattering improvement as the current 10:1 prefix > >> to provider ratio (300,000 prefixes for ~30,000 active ASNs) drops > >> to something more like 2:1 in IPv6 due to providers not having to > >> constantly run back to the RIR for additional slow-start allocations. > >> > >> Owen > > > > I suspect as we start seeing the CIDR report for IPv6, we'll see that > > ASNs are announcing considerably more prefixes than that, in order > > to localize traffic better. I don't think it'll be 300,000 prefixes, but > > I'd be willing to bet it'll be more than 100,000--not exactly "earth > > shattering improvement". > > > > Matt > > (hopeless deaggregator) > > Currently: 3,134 IPv6 ASNs active. > Currently: 4,265 IPv6 prefixes. > > Looks like less than 2:1 to me. > > That's as close as I think I can get to an IPv6 CIDR report for the moment. > > Owen > > > From msa at latt.net Mon Feb 7 15:28:41 2011 From: msa at latt.net (Majdi S. Abbas) Date: Mon, 7 Feb 2011 14:28:41 -0700 Subject: Membership model In-Reply-To: <393F6490-A035-4A3B-853D-8F8DAC8C9981@delong.com> References: <393F6490-A035-4A3B-853D-8F8DAC8C9981@delong.com> Message-ID: <20110207212841.GB80833@puck.nether.net> On Mon, Feb 07, 2011 at 12:40:41PM -0800, Owen DeLong wrote: > I'll happily join Newnog/NANOG and pay my dues when I can reach the > web site ot do so on IPv6 rather than legacy IPv4. I noticed that too, but shoot, I'm not even sure their host supports it. Besides, you'd still be v4 to Paypal. I opted to use IPv0 and mail them a check. --msa From mksmith at adhost.com Mon Feb 7 15:34:36 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Mon, 7 Feb 2011 21:34:36 +0000 Subject: Membership model In-Reply-To: <20110207212841.GB80833@puck.nether.net> References: <393F6490-A035-4A3B-853D-8F8DAC8C9981@delong.com> <20110207212841.GB80833@puck.nether.net> Message-ID: > -----Original Message----- > From: Majdi S. Abbas [mailto:msa at latt.net] > Sent: Monday, February 07, 2011 1:29 PM > To: Owen DeLong > Cc: NANOG list > Subject: Re: Membership model > > On Mon, Feb 07, 2011 at 12:40:41PM -0800, Owen DeLong wrote: > > I'll happily join Newnog/NANOG and pay my dues when I can reach the > > web site ot do so on IPv6 rather than legacy IPv4. > > I noticed that too, but shoot, I'm not even sure their > host supports it. > > Besides, you'd still be v4 to Paypal. > > I opted to use IPv0 and mail them a check. > > --msa Yes it does. 2001:4970:EEEE:7777::2 I'm bugging the powers-that-be about getting forward records working. [root at wa-geeks ~]# host 2001:4970:eeee:7777::2 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.7.7.7.7.e.e.e.e.0.7.9.4.1.0.0.2.ip6.arpa domain name pointer www.newnog.org. Mike -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) From surfer at mauigateway.com Mon Feb 7 15:45:02 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 7 Feb 2011 13:45:02 -0800 Subject: Membership model Message-ID: <20110207134502.F4601931@resin12.mta.everyone.net> --------------------------------------- > On Mon, Feb 07, 2011 at 12:40:41PM -0800, Owen DeLong wrote: > > > I'll happily join Newnog/NANOG and pay my dues when I can reach the > > web site ot do so on IPv6 rather than legacy IPv4. Yes it does. 2001:4970:EEEE:7777::2 I'm bugging the powers-that-be about getting forward records working. [root at wa-geeks ~]# host 2001:4970:eeee:7777::2 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.7.7.7.7.e.e.e.e.0.7.9.4.1.0.0.2.ip6.arpa domain name pointer www.newnog.org. -------------------------------------------------- Now your only question is check or pay pal... :-) scott From andrew.koch at tdstelecom.com Mon Feb 7 15:45:30 2011 From: andrew.koch at tdstelecom.com (Koch, Andrew) Date: Mon, 7 Feb 2011 15:45:30 -0600 Subject: What's really needed is a routing slot market (was: Using IPv6 withprefixes shorter than a /64 on a LAN) In-Reply-To: Message-ID: <84F7634862692847B463C7934B86ECD9E3E68E5F@CMX001.corp.tds.local> On Mon, Feb 7, 2011 at 3:10 PM, Owen DeLong > That's as close as I think I can get to an IPv6 CIDR report > for the moment. Looks like Geoff has you already setup. http://www.cidr-report.org/v6/as2.0/ Andy Koch From juicewvu at gmail.com Mon Feb 7 15:53:00 2011 From: juicewvu at gmail.com (Josh Smith) Date: Mon, 7 Feb 2011 16:53:00 -0500 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <9D145C3C-2D3A-4D73-997C-6346B6EF402A@deadfrog.net> References: <5817196.4787.1296792606407.JavaMail.root@benjamin.baylink.com> <9D145C3C-2D3A-4D73-997C-6346B6EF402A@deadfrog.net> Message-ID: On Thu, Feb 3, 2011 at 11:46 PM, Ryan Wilkins wrote: > > On Feb 3, 2011, at 10:10 PM, Jay Ashworth wrote: > >> ---- Original Message ----- >>> What do you do when you get home to put it back on the air -- let's >>> say email as a base service, since it is -- do you have the gear laying around, >>> and how long would it take? >> >> Focus on this part, BTW, folks; let's ignore the politics behind the >> shutdown. ?:-) >> > > So if I get what you're saying, I could have something operational from scratch in a few hours. ?I've got a variety of Cisco routers and switches, Linux and Mac OS X boxes in various shapes and sizes, and a five CPE + one AP 5 GHz Mikrotik RouterOS-based radio system, 802.11b/g wireless AP, 800' of Cat 5e cable, connectors, and crimpers. ?The radios, if well placed, could allow me to connect up several strategic locations, or perhaps use them to connect to other sources of Internet access, if available. ?If it really came down to it, I could probably gather enough satellite communications gear from the office to allow me to stand up satellite Internet to someone. ?Of course, the trick would be to talk to that "someone" to coordinate connectivity over the satellite which may be hard to do given the communications outage you described. ?I wouldn't be so worried about transmitting to the satellite, in this case I'd just transmit without authorization, but someone needs to be receiving my transmission and vice versa for this to be useful. ?At a minimum, I could enable communications between my neighbors. > > Regards, > Ryan Wilkins > I agree that setting up "local" connectivity between the folks in my neighborhood wouldn't be too much of a challenge. Getting anything much beyond that up and running would be a stretch. -- Josh Smith KD8HRX email/jabber:? juicewvu at gmail.com phone:? 304.237.9369(c) From owen at delong.com Mon Feb 7 15:55:55 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 7 Feb 2011 13:55:55 -0800 Subject: Membership model In-Reply-To: <20110207134502.F4601931@resin12.mta.everyone.net> References: <20110207134502.F4601931@resin12.mta.everyone.net> Message-ID: <2E97D000-FF52-466C-B96F-9EC07E2F3F32@delong.com> Reaching the web site requires more than an ip6.arpa record. It requires an AAAA record: baikal:owen (68) ~ % host -t AAAA www.newnog.org 2011/02/07 13:51:23 www.newnog.org has no AAAA record And it requires the host answer on port 80 at its IPv6 address, which does appear to already be the case. So, when I'm informed that the AAAA record is up, I'll retest. Owen On Feb 7, 2011, at 1:45 PM, Scott Weeks wrote: > > > --------------------------------------- >> On Mon, Feb 07, 2011 at 12:40:41PM -0800, Owen DeLong wrote: >> >>> I'll happily join Newnog/NANOG and pay my dues when I can reach the >>> web site ot do so on IPv6 rather than legacy IPv4. > > Yes it does. 2001:4970:EEEE:7777::2 I'm bugging the powers-that-be about getting forward records working. > > [root at wa-geeks ~]# host 2001:4970:eeee:7777::2 > 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.7.7.7.7.e.e.e.e.0.7.9.4.1.0.0.2.ip6.arpa domain name pointer www.newnog.org. > -------------------------------------------------- > > > > Now your only question is check or pay pal... :-) > > scott From ryan at deadfrog.net Mon Feb 7 16:01:22 2011 From: ryan at deadfrog.net (Ryan Wilkins) Date: Mon, 7 Feb 2011 16:01:22 -0600 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: References: <5817196.4787.1296792606407.JavaMail.root@benjamin.baylink.com> <9D145C3C-2D3A-4D73-997C-6346B6EF402A@deadfrog.net> Message-ID: <93A7CF3C-D075-4AC5-A829-64AA860993BA@deadfrog.net> On Feb 7, 2011, at 3:53 PM, Josh Smith wrote: > I agree that setting up "local" connectivity between the folks in my > neighborhood wouldn't be too much of a challenge. Getting anything > much beyond that up and running would be a stretch. Yeah, but the more people communicating the better. I don't know what all my neighbors are capable of doing. Some of them may be capable of helping the cause in ways that I hadn't considered. Regards, Ryan Wilkins From tvhawaii at shaka.com Mon Feb 7 16:06:04 2011 From: tvhawaii at shaka.com (Michael Painter) Date: Mon, 7 Feb 2011 12:06:04 -1000 Subject: US Warships jamming Lebanon Internet References: <201102071339.27793.denys@visp.net.lb> Message-ID: <5DBAD830D46E4F6D83545E653D8FB732@DELL16> Denys Fedoryshchenko wrote: > Hi > > I'm sysadmin of Lebanese ISP. > Almost at same time i got heavy interference on few of my C-Band carriers, and > it looks like electronic warfare jamming, because i can see phase modulated, > very weak signal, but it is completely breaking almost any communications on > my carriers. > > Strange thing, that our uplink station confirm that interference is not local > on my side, but on satellite carrier. If this will be confirmed, that means it > is not just miscommunication between authorities about frequency usage, it > will be intentional damage for Lebanese communications. > > Sure it can be coincidence in time or something else, but last 6 years i > experience similar terrible interference only during 2006 Lebanon vs Israel > war. Hi Denys I doubt it's intentional jamming since I've had the same problem. Aegis radar is very high power in full radiate mode and as such creates problems for Low Noise Amplifiers listening at 3.4-4.2 GHz. Someone needs to talk to Microwave Filter Company. http://www.microwavefilter.com/c-band_radar_elimination.htm --Michael > >> Lebanon's Telecom minister is claiming that US Navy radar is blocking the >> country's Internet.. >> >> http://www.naharnet.com/domino/tn/NewsDesk.nsf/0/93A95CA1A4E42178C225782E007371AF >> >>> "The problem, however, is due to a coordination error related to waves," >>> Nahhas told OTV, adding that an investigation was underway to find out >>> whether this act is "intentional or not." >> >> >> also at >> http://www.naharnet.com/domino/tn/NewsDesk.nsf/Lebanon/EFCEF203B3C315A5C225782E0020C75F From patrick at ianai.net Mon Feb 7 16:10:05 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 7 Feb 2011 17:10:05 -0500 Subject: Membership model In-Reply-To: <2E97D000-FF52-466C-B96F-9EC07E2F3F32@delong.com> References: <20110207134502.F4601931@resin12.mta.everyone.net> <2E97D000-FF52-466C-B96F-9EC07E2F3F32@delong.com> Message-ID: [Reply-To: set to -futures@, as I don't think this is an operational issue.] On Feb 7, 2011, at 4:55 PM, Owen DeLong wrote: > Reaching the web site requires more than an ip6.arpa record. > > It requires an AAAA record: In the e-mail to which you are replying (and top-posting, no less :), Mike said: "I'm bugging the powers-that-be about getting forward records working." While I agree doing v6 is nice and all, I think brow-beating an un-paid volunteer on something they already said they were trying to get working is a bit much. Remember, this is a community effort. The people running the web & name servers are donating their time & their companies' resources to the community. If you believe they are doing it wrong, please step up and help. Input is great, encouraged even. Help is better. Complaining about NewNOG (soon to be NANOG) is complaining about -yourself-. If you are reading this message, you ARE NewNOG. -- TTFN, patrick > baikal:owen (68) ~ % host -t AAAA www.newnog.org 2011/02/07 13:51:23 > www.newnog.org has no AAAA record > > And it requires the host answer on port 80 at its IPv6 address, which > does appear to already be the case. > > So, when I'm informed that the AAAA record is up, I'll retest. > > Owen > > > On Feb 7, 2011, at 1:45 PM, Scott Weeks wrote: > >> >> >> --------------------------------------- >>> On Mon, Feb 07, 2011 at 12:40:41PM -0800, Owen DeLong wrote: >>> >>>> I'll happily join Newnog/NANOG and pay my dues when I can reach the >>>> web site ot do so on IPv6 rather than legacy IPv4. >> >> Yes it does. 2001:4970:EEEE:7777::2 I'm bugging the powers-that-be about getting forward records working. >> >> [root at wa-geeks ~]# host 2001:4970:eeee:7777::2 >> 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.7.7.7.7.e.e.e.e.0.7.9.4.1.0.0.2.ip6.arpa domain name pointer www.newnog.org. >> -------------------------------------------------- >> >> >> >> Now your only question is check or pay pal... :-) >> >> scott > > From nick at foobar.org Mon Feb 7 16:11:12 2011 From: nick at foobar.org (Nick Hilliard) Date: Mon, 07 Feb 2011 22:11:12 +0000 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: References: <5817196.4787.1296792606407.JavaMail.root@benjamin.baylink.com> <9D145C3C-2D3A-4D73-997C-6346B6EF402A@deadfrog.net> Message-ID: <4D506E00.5030904@foobar.org> On 07/02/2011 21:53, Josh Smith wrote: > I agree that setting up "local" connectivity between the folks in my > neighborhood wouldn't be too much of a challenge. Getting anything > much beyond that up and running would be a stretch. I can't help noticing some irony in seeing one nanog thread about working around a supposed government internet kill switch by using wireless transmission kit, and another about the US Navy reputedly trashing connectivity in an entire country by, uh, jamming wireless transmission links. Nick From jra at baylink.com Mon Feb 7 16:18:17 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 7 Feb 2011 17:18:17 -0500 (EST) Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <4D506E00.5030904@foobar.org> Message-ID: <1024976.5761.1297117097356.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Nick Hilliard" > Subject: Re: Weekend Gedankenexperiment - The Kill Switch > On 07/02/2011 21:53, Josh Smith wrote: > > I agree that setting up "local" connectivity between the folks in my > > neighborhood wouldn't be too much of a challenge. Getting anything > > much beyond that up and running would be a stretch. > > I can't help noticing some irony in seeing one nanog thread about > working around a supposed government internet kill switch by using wireless > transmission kit, and another about the US Navy reputedly trashing > connectivity in an entire country by, uh, jamming wireless > transmission links. Irony != coincidence. One is the government interrupting communications, and the other one is ... the government interrupting communications. Oh look: those even came out in the same character positions. :-) Cheers, -- jra From bensons at queuefull.net Mon Feb 7 16:22:06 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Mon, 7 Feb 2011 16:22:06 -0600 Subject: Membership model In-Reply-To: References: <20110207134502.F4601931@resin12.mta.everyone.net> <2E97D000-FF52-466C-B96F-9EC07E2F3F32@delong.com> Message-ID: We all know that many people have no IPv6 connectivity. But I've only heard about future Internet-users without IPv4 connectivity... I didn't realize it was reality for Owen today. (Even my IPv6 phone via T-Mobile has NAT64 connectivity to www.newnog.org.) Cheers, -Benson On Feb 7, 2011, at 4:10 PM, Patrick W. Gilmore wrote: > [Reply-To: set to -futures@, as I don't think this is an operational issue.] > > On Feb 7, 2011, at 4:55 PM, Owen DeLong wrote: > >> Reaching the web site requires more than an ip6.arpa record. >> >> It requires an AAAA record: > > In the e-mail to which you are replying (and top-posting, no less :), Mike said: "I'm bugging the powers-that-be about getting forward records working." While I agree doing v6 is nice and all, I think brow-beating an un-paid volunteer on something they already said they were trying to get working is a bit much. > > Remember, this is a community effort. The people running the web & name servers are donating their time & their companies' resources to the community. If you believe they are doing it wrong, please step up and help. Input is great, encouraged even. Help is better. > > Complaining about NewNOG (soon to be NANOG) is complaining about -yourself-. If you are reading this message, you ARE NewNOG. > > -- > TTFN, > patrick > > >> baikal:owen (68) ~ % host -t AAAA www.newnog.org 2011/02/07 13:51:23 >> www.newnog.org has no AAAA record >> >> And it requires the host answer on port 80 at its IPv6 address, which >> does appear to already be the case. >> >> So, when I'm informed that the AAAA record is up, I'll retest. >> >> Owen >> >> >> On Feb 7, 2011, at 1:45 PM, Scott Weeks wrote: >> >>> >>> >>> --------------------------------------- >>>> On Mon, Feb 07, 2011 at 12:40:41PM -0800, Owen DeLong wrote: >>>> >>>>> I'll happily join Newnog/NANOG and pay my dues when I can reach the >>>>> web site ot do so on IPv6 rather than legacy IPv4. >>> >>> Yes it does. 2001:4970:EEEE:7777::2 I'm bugging the powers-that-be about getting forward records working. >>> >>> [root at wa-geeks ~]# host 2001:4970:eeee:7777::2 >>> 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.7.7.7.7.e.e.e.e.0.7.9.4.1.0.0.2.ip6.arpa domain name pointer www.newnog.org. >>> -------------------------------------------------- >>> >>> >>> >>> Now your only question is check or pay pal... :-) >>> >>> scott >> >> > > From ryan at deadfrog.net Mon Feb 7 16:23:24 2011 From: ryan at deadfrog.net (Ryan Wilkins) Date: Mon, 7 Feb 2011 16:23:24 -0600 Subject: US Warships jamming Lebanon Internet In-Reply-To: <5DBAD830D46E4F6D83545E653D8FB732@DELL16> References: <201102071339.27793.denys@visp.net.lb> <5DBAD830D46E4F6D83545E653D8FB732@DELL16> Message-ID: <86DC8395-2588-445C-AF78-CDB0605FFA56@deadfrog.net> On Feb 7, 2011, at 4:06 PM, Michael Painter wrote: > > Hi Denys > I doubt it's intentional jamming since I've had the same problem. > Aegis radar is very high power in full radiate mode and as such creates problems for Low Noise Amplifiers listening at 3.4-4.2 GHz. > Someone needs to talk to Microwave Filter Company. > http://www.microwavefilter.com/c-band_radar_elimination.htm > > --Michael +1 for Microwave Filter. They've helped me out in a couples jams before. They're very responsive and the products are good, too. Ryan Wilkins From owen at delong.com Mon Feb 7 16:23:58 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 7 Feb 2011 14:23:58 -0800 Subject: Membership model In-Reply-To: References: <20110207134502.F4601931@resin12.mta.everyone.net> <2E97D000-FF52-466C-B96F-9EC07E2F3F32@delong.com> Message-ID: <24B61259-438C-4D9A-867A-E3AA9DE8CD55@delong.com> Apologies to Mike, It was not my intention to brow-beat him publicly. Indeed, I acknowledge that he has the problem well in hand and is actively working on resolving the issue. My only intent was to point out to the person who claimed an ip6.arpa record and a host which had an IPv6 address on its interface alone were not a web site accessible on IPv6. I fully expect the AAAA record to be placed soon and it looks like that is the last remaining hurdle. Once that is done, I will pay my dues. Owen On Feb 7, 2011, at 2:10 PM, Patrick W. Gilmore wrote: > [Reply-To: set to -futures@, as I don't think this is an operational issue.] > > On Feb 7, 2011, at 4:55 PM, Owen DeLong wrote: > >> Reaching the web site requires more than an ip6.arpa record. >> >> It requires an AAAA record: > > In the e-mail to which you are replying (and top-posting, no less :), Mike said: "I'm bugging the powers-that-be about getting forward records working." While I agree doing v6 is nice and all, I think brow-beating an un-paid volunteer on something they already said they were trying to get working is a bit much. > > Remember, this is a community effort. The people running the web & name servers are donating their time & their companies' resources to the community. If you believe they are doing it wrong, please step up and help. Input is great, encouraged even. Help is better. > > Complaining about NewNOG (soon to be NANOG) is complaining about -yourself-. If you are reading this message, you ARE NewNOG. > > -- > TTFN, > patrick > > >> baikal:owen (68) ~ % host -t AAAA www.newnog.org 2011/02/07 13:51:23 >> www.newnog.org has no AAAA record >> >> And it requires the host answer on port 80 at its IPv6 address, which >> does appear to already be the case. >> >> So, when I'm informed that the AAAA record is up, I'll retest. >> >> Owen >> >> >> On Feb 7, 2011, at 1:45 PM, Scott Weeks wrote: >> >>> >>> >>> --------------------------------------- >>>> On Mon, Feb 07, 2011 at 12:40:41PM -0800, Owen DeLong wrote: >>>> >>>>> I'll happily join Newnog/NANOG and pay my dues when I can reach the >>>>> web site ot do so on IPv6 rather than legacy IPv4. >>> >>> Yes it does. 2001:4970:EEEE:7777::2 I'm bugging the powers-that-be about getting forward records working. >>> >>> [root at wa-geeks ~]# host 2001:4970:eeee:7777::2 >>> 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.7.7.7.7.e.e.e.e.0.7.9.4.1.0.0.2.ip6.arpa domain name pointer www.newnog.org. >>> -------------------------------------------------- >>> >>> >>> >>> Now your only question is check or pay pal... :-) >>> >>> scott >> >> > From juicewvu at gmail.com Mon Feb 7 16:49:36 2011 From: juicewvu at gmail.com (Josh Smith) Date: Mon, 7 Feb 2011 17:49:36 -0500 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <93A7CF3C-D075-4AC5-A829-64AA860993BA@deadfrog.net> References: <5817196.4787.1296792606407.JavaMail.root@benjamin.baylink.com> <9D145C3C-2D3A-4D73-997C-6346B6EF402A@deadfrog.net> <93A7CF3C-D075-4AC5-A829-64AA860993BA@deadfrog.net> Message-ID: On Mon, Feb 7, 2011 at 5:01 PM, Ryan Wilkins wrote: > > On Feb 7, 2011, at 3:53 PM, Josh Smith wrote: > >> I agree that setting up "local" connectivity between the folks in my >> neighborhood wouldn't be too much of a challenge. ?Getting anything >> much beyond that up and running would be a stretch. > > Yeah, but the more people communicating the better. ?I don't know what all my neighbors are capable of doing. ?Some of them may be capable of helping the cause in ways that I hadn't considered. > > Regards, > Ryan Wilkins > > Ryan, I agree the more people communicating the better. I was just commenting on what my own, and suspect many others on the list's capabilities are. While I would love to have access to a satellite type of data service as a backup link its simply not in my budget and even if it was I suspect any service available via satellite might suffer from similar problems if the methods used to disrupt connectivity in Egypt were employed here. Thanks, -- Josh Smith KD8HRX email/jabber: juicewvu at gmail.com phone: 304.237.9369(c) From blake at ispn.net Mon Feb 7 16:52:14 2011 From: blake at ispn.net (Blake Hudson) Date: Mon, 07 Feb 2011 16:52:14 -0600 Subject: My upstream ISP does not support IPv6 In-Reply-To: <18699589.266.1296788654238.JavaMail.franck@franck-martins-macbook-pro.local> References: <18699589.266.1296788654238.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4D50779E.40804@ispn.net> -------- Original Message -------- Subject: My upstream ISP does not support IPv6 From: Franck Martin To: nanog at nanog.org Date: Thursday, February 03, 2011 9:04:14 PM > The biggest complaint that I hear from ISPs, is that their upstream ISP does not support IPv6 or will not provide them with a native IPv6 circuit. > > Is that bull? > > I thought the whole backbone is IPv6 now, and it is only the residential ISPs that are still figuring it out because CPE are still not there yet. > > Where can I get more information? Any list of peering ISPs that have IPv6 as part of their products? > > It seems to me the typical answer sales people say when asked about IPv6: "Gosh, this is the first time I'm asked this one". We've been checking with our two regional upstreams and the answer seems to vary between 'not yet...', 'testing...', 'we're planning...' etc. I've been checking with my technical contacts, vs sales people. Perhaps if there was a drive from the sales perspective I could get more traction - money talks. In the mean time, we've setup a tunnel with HE. At least our network will be tested and ready to go whenever native transit is available. --Blake From james.cutler at consultant.com Mon Feb 7 16:59:47 2011 From: james.cutler at consultant.com (Cutler James R) Date: Mon, 7 Feb 2011 17:59:47 -0500 Subject: My upstream ISP does not support IPv6 In-Reply-To: <4D50779E.40804@ispn.net> References: <18699589.266.1296788654238.JavaMail.franck@franck-martins-macbook-pro.local> <4D50779E.40804@ispn.net> Message-ID: <4607E2A3-6C20-4FCF-A842-37497C5558B9@consultant.com> All this talk about CPE is wasted until folks like ATT have someone on the retail interface (store, phone, or, web) who even knows what is this "IPv6" thing. Exploring this issue with DSL providers and Uverse is like that old exercise with combat boots. It feels much better when I stop. James R. Cutler james.cutler at consultant.com My ISP can't answer the question. From rcarpen at network1.net Mon Feb 7 17:16:52 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Mon, 7 Feb 2011 18:16:52 -0500 (EST) Subject: Membership model In-Reply-To: <393F6490-A035-4A3B-853D-8F8DAC8C9981@delong.com> Message-ID: <765193297.3390.1297120612619.JavaMail.root@zimbra.network1.net> ----- Original Message ----- > I'll happily join Newnog/NANOG and pay my dues when I can reach the > web site to do so > on IPv6 rather than legacy IPv4. > > Owen I'd be happy if https://newnog.org/join.php loaded a page instead of an SSL error. -Randy From tagno25 at gmail.com Mon Feb 7 17:23:32 2011 From: tagno25 at gmail.com (Philip Dorr) Date: Mon, 7 Feb 2011 17:23:32 -0600 Subject: Membership model In-Reply-To: <765193297.3390.1297120612619.JavaMail.root@zimbra.network1.net> References: <393F6490-A035-4A3B-853D-8F8DAC8C9981@delong.com> <765193297.3390.1297120612619.JavaMail.root@zimbra.network1.net> Message-ID: No SSL errors here using Chrome, IE, or Firefox. On Mon, Feb 7, 2011 at 5:16 PM, Randy Carpenter wrote: > ----- Original Message ----- >> I'll happily join Newnog/NANOG and pay my dues when I can reach the >> web site to do so >> on IPv6 rather than legacy IPv4. >> >> Owen > > I'd be happy if https://newnog.org/join.php loaded a page instead of an SSL error. > > -Randy > > > From jvanoppen at spectrumnet.us Mon Feb 7 17:23:57 2011 From: jvanoppen at spectrumnet.us (John van Oppen) Date: Mon, 7 Feb 2011 23:23:57 +0000 Subject: Membership model In-Reply-To: <765193297.3390.1297120612619.JavaMail.root@zimbra.network1.net> References: <393F6490-A035-4A3B-853D-8F8DAC8C9981@delong.com> <765193297.3390.1297120612619.JavaMail.root@zimbra.network1.net> Message-ID: >>>I'd be happy if https://newnog.org/join.php loaded a page instead of an SSL error. Good to see that you have working v6 connectivity. :) This is being worked on now, it is ironically only broken in v6. John From marka at isc.org Mon Feb 7 17:26:16 2011 From: marka at isc.org (Mark Andrews) Date: Tue, 08 Feb 2011 10:26:16 +1100 Subject: It's the end of IPv4 as we know it... and I feel fine.. In-Reply-To: Your message of "Mon, 07 Feb 2011 13:47:58 CDT." <4D503E5E.5000300@ispalliance.net> References: <532030EB-3A85-4E86-ACEC-ED273183BE3C@puck.nether.net> <4D4AD77A.4050705@rollernet.us> <4D503746.103@rollernet.us> <4D503E5E.5000300@ispalliance.net> Message-ID: <20110207232616.797C89C3FDA@drugs.dv.isc.org> In message <4D503E5E.5000300 at ispalliance.net>, Scott Helms writes: > On 2/7/2011 1:17 PM, Seth Mattinen wrote: > > On 2/3/2011 08:38, Josh Smith wrote: > >> Seth, > >> What sort of ISP do your "not technically inclined" parents have that > >> offers native ipv6? :-) > >> > > > > I'm doing it via fixed wireless. They'll actually be my second access > > customer to get native IPv6. My parents are a good test case for the > > kind of user who doesn't care about the difference between IPv4 or IPv6 > > or the debates whether to /64 or not, only that the internet works. > > > > ~Seth > > > > > Ahh, that makes them like 99.99% of all retail internet users. But please have them daisy chain CPE devices so that they are in the X% that have more than one CPE devices connected today. I agree it should just work. I've seen more that one household of non geeks with multiple CPE devices. e.g. cable/adsl CPE wired CPE wireless Mark > -- > Scott Helms > Vice President of Technology > ISP Alliance, Inc. DBA ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From rcarpen at network1.net Mon Feb 7 17:32:14 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Mon, 7 Feb 2011 18:32:14 -0500 (EST) Subject: Membership model In-Reply-To: Message-ID: <1196431235.3398.1297121534745.JavaMail.root@zimbra.network1.net> ----- Original Message ----- > >>>I'd be happy if https://newnog.org/join.php loaded a page instead > >>>of an SSL error. > > Good to see that you have working v6 connectivity. :) This is being > worked on now, it is ironically only broken in v6. > > > John Ahhh... that makes sense :-) Will check back later. -Randy From barney at databus.com Mon Feb 7 17:36:27 2011 From: barney at databus.com (Barney Wolff) Date: Mon, 7 Feb 2011 18:36:27 -0500 Subject: It's the end of IPv4 as we know it... and I feel fine.. In-Reply-To: <20110207232616.797C89C3FDA@drugs.dv.isc.org> References: <532030EB-3A85-4E86-ACEC-ED273183BE3C@puck.nether.net> <4D4AD77A.4050705@rollernet.us> <4D503746.103@rollernet.us> <4D503E5E.5000300@ispalliance.net> <20110207232616.797C89C3FDA@drugs.dv.isc.org> Message-ID: <20110207233627.GA64731@pit.databus.com> On Tue, Feb 08, 2011 at 10:26:16AM +1100, Mark Andrews wrote: > ... > > But please have them daisy chain CPE devices so that they are in > the X% that have more than one CPE devices connected today. I agree > it should just work. I've seen more that one household of non geeks > with multiple CPE devices. > > e.g. > cable/adsl CPE wired CPE wireless When I do that, I use a lan port on CPE2 rather than the wan port. Using CPE2 as just a switch rather than a router/natbox makes life much simpler. -- Barney Wolff I never met a computer I didn't like. From george.herbert at gmail.com Mon Feb 7 17:42:42 2011 From: george.herbert at gmail.com (George Herbert) Date: Mon, 7 Feb 2011 15:42:42 -0800 Subject: US Warships jamming Lebanon Internet In-Reply-To: <86DC8395-2588-445C-AF78-CDB0605FFA56@deadfrog.net> References: <201102071339.27793.denys@visp.net.lb> <5DBAD830D46E4F6D83545E653D8FB732@DELL16> <86DC8395-2588-445C-AF78-CDB0605FFA56@deadfrog.net> Message-ID: On Mon, Feb 7, 2011 at 2:23 PM, Ryan Wilkins wrote: > > On Feb 7, 2011, at 4:06 PM, Michael Painter wrote: >> >> Hi Denys >> I doubt it's intentional jamming since I've had the same problem. >> Aegis radar is very high power in full radiate mode and as such creates problems for Low Noise Amplifiers listening at 3.4-4.2 GHz. >> Someone needs to talk to Microwave Filter Company. >> http://www.microwavefilter.com/c-band_radar_elimination.htm >> >> --Michael > > +1 for Microwave Filter. ?They've helped me out in a couples jams before. ?They're very responsive and the products are good, too. I think people in San Diego and near Norfolk, VA have the same problems. The C-band frequencies are 2x those of the S-band (4-8 GHz for C, 2-4 GHz for S); if the SPY-1 / SPY-1D radar is frequency hopping it may well step on someone's C-band links at twice the radar's basic frequency. Just need a filter to remove actual S-band frequencies from C-band feeds. -- -george william herbert george.herbert at gmail.com From owen at delong.com Mon Feb 7 17:38:31 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 7 Feb 2011 15:38:31 -0800 Subject: Membership model In-Reply-To: References: <393F6490-A035-4A3B-853D-8F8DAC8C9981@delong.com> <765193297.3390.1297120612619.JavaMail.root@zimbra.network1.net> Message-ID: <923ACBFA-331A-4BC3-AF51-642286147284@delong.com> On Feb 7, 2011, at 3:23 PM, John van Oppen wrote: >>>> I'd be happy if https://newnog.org/join.php loaded a page instead of an SSL error. > > Good to see that you have working v6 connectivity. :) This is being worked on now, it is ironically only broken in v6. > > > John > Cool... Guess there is an issue beyond the AAAA record to getting the web site on IPv6. Anyway, glad they're working on it. I do want to join. Owen From chris at getsprocket.com Mon Feb 7 18:08:11 2011 From: chris at getsprocket.com (Christopher Wolff) Date: Mon, 07 Feb 2011 17:08:11 -0700 Subject: Time Warner Transit Message-ID: <4D50896B.6030702@getsprocket.com> Hey guys, What are you thinking about Time Warner transit lately? They claim to be fully ready to support IPv6. Thanks in advance, you can hit me offlist if you're not able to share your TWTC opinion publicly. Christopher From marka at isc.org Mon Feb 7 18:33:20 2011 From: marka at isc.org (Mark Andrews) Date: Tue, 08 Feb 2011 11:33:20 +1100 Subject: It's the end of IPv4 as we know it... and I feel fine.. In-Reply-To: Your message of "Mon, 07 Feb 2011 18:36:27 CDT." <20110207233627.GA64731@pit.databus.com> References: <532030EB-3A85-4E86-ACEC-ED273183BE3C@puck.nether.net> <4D4AD77A.4050705@rollernet.us> <4D503746.103@rollernet.us> <4D503E5E.5000300@ispalliance.net> <20110207232616.797C89C3FDA@drugs.dv.isc.org> <20110207233627.GA64731@pit.databus.com> Message-ID: <20110208003320.73B799C5036@drugs.dv.isc.org> In message <20110207233627.GA64731 at pit.databus.com>, Barney Wolff writes: > On Tue, Feb 08, 2011 at 10:26:16AM +1100, Mark Andrews wrote: > > > ... > > > > But please have them daisy chain CPE devices so that they are in > > the X% that have more than one CPE devices connected today. I agree > > it should just work. I've seen more that one household of non geeks > > with multiple CPE devices. > > > > e.g. > > cable/adsl CPE wired CPE wireless > > When I do that, I use a lan port on CPE2 rather than the wan port. > Using CPE2 as just a switch rather than a router/natbox makes life > much simpler. Then you may as well have bought a access point. > -- > Barney Wolff I never met a computer I didn't like. > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From owen at delong.com Mon Feb 7 18:36:17 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 7 Feb 2011 16:36:17 -0800 Subject: It's the end of IPv4 as we know it... and I feel fine.. In-Reply-To: <20110207233627.GA64731@pit.databus.com> References: <532030EB-3A85-4E86-ACEC-ED273183BE3C@puck.nether.net> <4D4AD77A.4050705@rollernet.us> <4D503746.103@rollernet.us> <4D503E5E.5000300@ispalliance.net> <20110207232616.797C89C3FDA@drugs.dv.isc.org> <20110207233627.GA64731@pit.databus.com> Message-ID: On Feb 7, 2011, at 3:36 PM, Barney Wolff wrote: > On Tue, Feb 08, 2011 at 10:26:16AM +1100, Mark Andrews wrote: >> > ... >> >> But please have them daisy chain CPE devices so that they are in >> the X% that have more than one CPE devices connected today. I agree >> it should just work. I've seen more that one household of non geeks >> with multiple CPE devices. >> >> e.g. >> cable/adsl CPE wired CPE wireless > > When I do that, I use a lan port on CPE2 rather than the wan port. > Using CPE2 as just a switch rather than a router/natbox makes life > much simpler. > > -- > Barney Wolff I never met a computer I didn't like. > Unless you want to enforce policy between wired and wireless. As soon as you want that, you need to put the wired on the WAN port of the wireless. You also have to be careful about which boxes you purchase since many will hard-coded assume that the wireless is the internal trusted side of the equation. Owen From charles at knownelement.com Mon Feb 7 19:59:05 2011 From: charles at knownelement.com (Charles N Wyble) Date: Mon, 07 Feb 2011 17:59:05 -0800 Subject: BGP Looking glass and monitoring In-Reply-To: References: Message-ID: <4D50A369.5000004@knownelement.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/03/2011 03:59 PM, Bret Palsson wrote: > I'm interested to know what tools everyone uses for the following: > > Looking Glass server. I think there was a recent thread on this subject. From this month maybe. Not sure. Check the archives. > BGP Monitoring Can you expand on this? Something like bgpmon? > BGP Management, ie. cost/preferred path management. Not sure what is meant by this. > > Does anyone use tools to make changes to configurations? For example svn. > How do you push changes? Manually, approval process, scripts? I've used Network Authority Inventory. Looking at nocproject.org now. > > Currently the only thing we use is subversion to track changes in configurations. Hey that's a step up from a lot of shops. :) Now that we are up to around 20 routers and growing we are looking for better methods to manage our infrastructure. Sure. I'm sure folks here will have much to share. If we have any subscribers after the last couple v6 wars. I guess I spoke too soon when I said the threads seemed less trollish/childish. :) > > Thanks guys! Thanks for brining up a solid operational topic and giving us a break. :) - -- Charles N Wyble (charles at knownelement.com) Systems craftsman for the stars http://www.knownelement.com Mobile: 626 539 4344 Office: 310 929 8793 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNUKNgAAoJEMvvG/TyLEAtT/cQAIxi4JtuvRlIhg6oQwCiaQR1 mZQMexUIqTxO9k4DqnImgpCQNoRpwZGS6cm3/r1syutGWz2oBy1UdsswwXvDumxN O9ktI2pCEcRAIHwWh94p/eHR4VY48AlHwLQX6FYAbsxj8m2cV2IE4F393cuy/Q0X KvPVIJ73e+Db7eE+iUtZ8h6GoLuK2M6Imt2yoGew8FP4hvcaC+Ief6GQvU+RRyCY LCnausBA4l/lZzvXfBhzp/C8eIvU7KYo5AQDUx7qmHjWtHu4DnkajdInSuej96wY 1mJ2UNMx/Eb5Tci89hH9oe4dhoL362qI/8Q3Ot2mvxKUBbBtYcFKlbv5Ve8AS1SF P/KMcY2PJhRc67H9SmvF8HbZnn5YlPo64YHWezEV/rotRngJmwBzQ98uIk1zk9qM pUApV4R52WS5D1IavnOtHE2b8ZS/ZpYE7Cr9sQcWfnVyVj+O/tRvXztLSF2ze43k HZSH5qoBmlF+2W2Jz96eKqtmS/AF2Gz2J5FNnwqvrJzHW9yuCoZ64AOS1wHovMps yQ62ovO2u6mwUDnk5pJcaEvd46ao8n1PgVA5+jKuzi7gGdo7yOGqr8hKTejF4pcC LJYdpzbCQQrcBfJtpGhH3dyRU1wD2VI6XRAo4fLvKhcwJLkD4hgJXB0MJYF0mmH6 PYjPfjckrxfwhxHZm1I8 =sQbK -----END PGP SIGNATURE----- From owen at delong.com Mon Feb 7 21:37:09 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 7 Feb 2011 19:37:09 -0800 Subject: I've joined NEWNOG Message-ID: <438D737A-4F9E-49BB-88B4-D9A04D4C2D51@delong.com> OK... They got the IPv6 issues resolved, the page is working great now. Yes, Paypal broke when I clicked the pay now button with IPv4 turned off. However, everything else worked. I've now paid my fee and joined NEWNOG. Thanks to the technical crew for addressing this issue so promptly and showing leadership in this area. Welcome NEWNOG to the NEW NET. Owen From Valdis.Kletnieks at vt.edu Mon Feb 7 22:11:40 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 07 Feb 2011 23:11:40 -0500 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: Your message of "Mon, 07 Feb 2011 17:49:36 EST." References: <5817196.4787.1296792606407.JavaMail.root@benjamin.baylink.com> <9D145C3C-2D3A-4D73-997C-6346B6EF402A@deadfrog.net> <93A7CF3C-D075-4AC5-A829-64AA860993BA@deadfrog.net> Message-ID: <12173.1297138300@localhost> On Mon, 07 Feb 2011 17:49:36 EST, Josh Smith said: > even if it was I suspect any service available via satellite might > suffer from similar problems if the methods used to disrupt > connectivity in Egypt were employed here. The real question isn't "If they shut you down, can you restart?". The real question is "If they shut you down, can you restart in a way that avoids them attempting a second shutdown with a bullet?" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From andrew.wallace at rocketmail.com Tue Feb 8 00:35:57 2011 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Mon, 7 Feb 2011 22:35:57 -0800 (PST) Subject: Weekend Gedankenexperiment - The Kill Switch Message-ID: <93740.21050.qm@web59604.mail.ac4.yahoo.com> On Tue, Feb 8, 2011 at 4:11 AM, wrote: > On Mon, 07 Feb 2011 17:49:36 EST, Josh Smith said: > >> even if it was I suspect any service available via satellite might >> suffer from similar problems if the methods used to disrupt >> connectivity in Egypt were employed here. > > The real question isn't "If they shut you down, can you restart?". > > The real question is "If they shut you down, can you restart in a way that > avoids them attempting a second shutdown with a bullet?" > > > May I suggest - A bunker built for Scottish Office staff in the event of a nuclear attack is up for sale. The complex at Cultybraggan Camp near Comrie, Perthshire, was completed in 1990 and is believed to be one of the most advanced structures of its kind. It was built to house 150 people and protect them from nuclear, biological and electromagnetic attacks. http://www.bbc.co.uk/news/uk-scotland-tayside-central-12311164 Andrew From denys at visp.net.lb Tue Feb 8 05:59:38 2011 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Tue, 8 Feb 2011 13:59:38 +0200 Subject: US Warships jamming Lebanon Internet Message-ID: <201102081359.39100.denys@visp.net.lb> On Tuesday 08 February 2011 01:42:42 George Herbert wrote: > On Mon, Feb 7, 2011 at 2:23 PM, Ryan Wilkins wrote: > > On Feb 7, 2011, at 4:06 PM, Michael Painter wrote: > >> Hi Denys > >> I doubt it's intentional jamming since I've had the same problem. > >> Aegis radar is very high power in full radiate mode and as such creates > >> problems for Low Noise Amplifiers listening at 3.4-4.2 GHz. Someone > >> needs to talk to Microwave Filter Company. > >> http://www.microwavefilter.com/c-band_radar_elimination.htm > >> > >> --Michael > > > > +1 for Microwave Filter. They've helped me out in a couples jams before. > > They're very responsive and the products are good, too. > > I think people in San Diego and near Norfolk, VA have the same problems. > > The C-band frequencies are 2x those of the S-band (4-8 GHz for C, 2-4 > GHz for S); if the SPY-1 / SPY-1D radar is frequency hopping it may > well step on someone's C-band links at twice the radar's basic > frequency. Just need a filter to remove actual S-band frequencies > from C-band feeds. I try to install C-Band bandpass filter, no effect at all, so it is in-band interference. Putting foil (yes i try almost everything) near LNB doesn't affect interference level too. From adrian at creative.net.au Tue Feb 8 06:18:59 2011 From: adrian at creative.net.au (Adrian Chadd) Date: Tue, 8 Feb 2011 20:18:59 +0800 Subject: US Warships jamming Lebanon Internet In-Reply-To: <201102081359.39100.denys@visp.net.lb> References: <201102081359.39100.denys@visp.net.lb> Message-ID: <20110208121859.GB2861@skywalker.creative.net.au> On Tue, Feb 08, 2011, Denys Fedoryshchenko wrote: > I try to install C-Band bandpass filter, no effect at all, so it is in-band > interference. Putting foil (yes i try almost everything) near LNB doesn't > affect interference level too. Can you get access to some kind of spectrum analyser kit to see what the kind of interference is? Adrian From hescominsoon at emmanuelcomputerconsulting.com Tue Feb 8 06:21:29 2011 From: hescominsoon at emmanuelcomputerconsulting.com (William Warren) Date: Tue, 08 Feb 2011 07:21:29 -0500 Subject: WebServer and Firewall Help In-Reply-To: References: Message-ID: <4D513549.8020307@emmanuelcomputerconsulting.com> On 2/7/2011 1:23 PM, Joshua William Klubi wrote: > Hi, > > I run a web-server based on ubuntu server and the LAMP stack. > I used Ubuntu's UFW firewall model and have enabled only Web and SSH ports. > Namely port 80 and port 22 only. > > Unfortunately once a while some guys get to inject some content onto our web > pages. > > Now managements are looking at getting a well proven infrastructure to > counter that. > But I also think i can fall on this community to help me get the right stuff > done. Where > i can protect the server from such attack. > > > I want to know what measure i can do on the server to get it protected which > mysql protection > I should implement. since i can see that it might be a php or mysql > injection that is been used. > > Currently I run these security measures on it. > Ubuntu UFW > Fail2ban > PHP model security > Apache security > > Joshua the problem may not be your operating system but the web application running. what web application/s are on that box? From tshaw at oitc.com Tue Feb 8 06:34:58 2011 From: tshaw at oitc.com (TR Shaw) Date: Tue, 8 Feb 2011 07:34:58 -0500 Subject: US Warships jamming Lebanon Internet In-Reply-To: <201102081359.39100.denys@visp.net.lb> References: <201102081359.39100.denys@visp.net.lb> Message-ID: On Feb 8, 2011, at 6:59 AM, Denys Fedoryshchenko wrote: > On Tuesday 08 February 2011 01:42:42 George Herbert wrote: >> On Mon, Feb 7, 2011 at 2:23 PM, Ryan Wilkins wrote: >>> On Feb 7, 2011, at 4:06 PM, Michael Painter wrote: >>>> Hi Denys >>>> I doubt it's intentional jamming since I've had the same problem. >>>> Aegis radar is very high power in full radiate mode and as such creates >>>> problems for Low Noise Amplifiers listening at 3.4-4.2 GHz. Someone >>>> needs to talk to Microwave Filter Company. >>>> http://www.microwavefilter.com/c-band_radar_elimination.htm >>>> >>>> --Michael >>> >>> +1 for Microwave Filter. They've helped me out in a couples jams before. >>> They're very responsive and the products are good, too. >> >> I think people in San Diego and near Norfolk, VA have the same problems. >> >> The C-band frequencies are 2x those of the S-band (4-8 GHz for C, 2-4 >> GHz for S); if the SPY-1 / SPY-1D radar is frequency hopping it may >> well step on someone's C-band links at twice the radar's basic >> frequency. Just need a filter to remove actual S-band frequencies >> from C-band feeds. > I try to install C-Band bandpass filter, no effect at all, so it is in-band > interference. Putting foil (yes i try almost everything) near LNB doesn't > affect interference level too. > It can come in from other places as well. Inductance via unfiltered/poorly-filtered power, poor I/F cabling as well as via other sources. Have you tried using a spectrum analyzer to characterize the signal in the ether and compare it to what you are seeing in your systems? Tom From denys at visp.net.lb Tue Feb 8 06:26:49 2011 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Tue, 8 Feb 2011 14:26:49 +0200 Subject: US Warships jamming Lebanon Internet In-Reply-To: <20110208121859.GB2861@skywalker.creative.net.au> References: <201102081359.39100.denys@visp.net.lb> <20110208121859.GB2861@skywalker.creative.net.au> Message-ID: <201102081426.50043.denys@visp.net.lb> On Tuesday 08 February 2011 14:18:59 Adrian Chadd wrote: > On Tue, Feb 08, 2011, Denys Fedoryshchenko wrote: > > I try to install C-Band bandpass filter, no effect at all, so it is > > in-band > > > > interference. Putting foil (yes i try almost everything) near LNB doesn't > > affect interference level too. > > Can you get access to some kind of spectrum analyser kit to see what the > kind of interference is? > > > > Adrian Yes, on short (few minutes) sweeps it is clean. During long time run, with 100 Khz resolution, if we run few hours we can catch anomalies on the carrier. Important note: this snapshot done on spectrum analyser in Europe, same transponder, and results similar, so it looks like interference is on transponder. Issue start to affect us at same time when people in Lebanon got local interference issues. Here is snapshot of carrier spectrum with anomaly: http//www.nuclearcat.com/PICTURES/interference.jpg From adrian at creative.net.au Tue Feb 8 06:41:29 2011 From: adrian at creative.net.au (Adrian Chadd) Date: Tue, 8 Feb 2011 20:41:29 +0800 Subject: US Warships jamming Lebanon Internet In-Reply-To: <201102081426.50043.denys@visp.net.lb> References: <201102081359.39100.denys@visp.net.lb> <20110208121859.GB2861@skywalker.creative.net.au> <201102081426.50043.denys@visp.net.lb> Message-ID: <20110208124129.GC2861@skywalker.creative.net.au> On Tue, Feb 08, 2011, Denys Fedoryshchenko wrote: > On Tuesday 08 February 2011 14:18:59 Adrian Chadd wrote: > > On Tue, Feb 08, 2011, Denys Fedoryshchenko wrote: > > > I try to install C-Band bandpass filter, no effect at all, so it is > > > in-band > > > > > > interference. Putting foil (yes i try almost everything) near LNB doesn't > > > affect interference level too. > > > > Can you get access to some kind of spectrum analyser kit to see what the > > kind of interference is? > > > > > > > > Adrian > Yes, on short (few minutes) sweeps it is clean. During long time run, with 100 > Khz resolution, if we run few hours we can catch anomalies on the carrier. > Important note: this snapshot done on spectrum analyser in Europe, same > transponder, and results similar, so it looks like interference is on > transponder. Issue start to affect us at same time when people in Lebanon got > local interference issues. > > Here is snapshot of carrier spectrum with anomaly: > http//www.nuclearcat.com/PICTURES/interference.jpg And does this interference similarly screw up being able to RX data from the transponder whilst in Europe? (eg, if you stick a modem on RX-only in Europe (ie, no uplink) and then just lock onto the signal and decode whatever happens, do you suffer the same problem?) Adrian -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA - From denys at visp.net.lb Tue Feb 8 06:32:27 2011 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Tue, 8 Feb 2011 14:32:27 +0200 Subject: US Warships jamming Lebanon Internet In-Reply-To: References: <201102081359.39100.denys@visp.net.lb> Message-ID: <201102081432.28130.denys@visp.net.lb> On Tuesday 08 February 2011 14:34:58 TR Shaw wrote: > On Feb 8, 2011, at 6:59 AM, Denys Fedoryshchenko wrote: > > On Tuesday 08 February 2011 01:42:42 George Herbert wrote: > >> On Mon, Feb 7, 2011 at 2:23 PM, Ryan Wilkins wrote: > >>> On Feb 7, 2011, at 4:06 PM, Michael Painter wrote: > >>>> Hi Denys > >>>> I doubt it's intentional jamming since I've had the same problem. > >>>> Aegis radar is very high power in full radiate mode and as such > >>>> creates problems for Low Noise Amplifiers listening at 3.4-4.2 GHz. > >>>> Someone needs to talk to Microwave Filter Company. > >>>> http://www.microwavefilter.com/c-band_radar_elimination.htm > >>>> > >>>> --Michael > >>> > >>> +1 for Microwave Filter. They've helped me out in a couples jams > >>> before. They're very responsive and the products are good, too. > >> > >> I think people in San Diego and near Norfolk, VA have the same problems. > >> > >> The C-band frequencies are 2x those of the S-band (4-8 GHz for C, 2-4 > >> GHz for S); if the SPY-1 / SPY-1D radar is frequency hopping it may > >> well step on someone's C-band links at twice the radar's basic > >> frequency. Just need a filter to remove actual S-band frequencies > >> from C-band feeds. > > > > I try to install C-Band bandpass filter, no effect at all, so it is > > in-band interference. Putting foil (yes i try almost everything) near > > LNB doesn't affect interference level too. > > It can come in from other places as well. Inductance via > unfiltered/poorly-filtered power, poor I/F cabling as well as via other > sources. > > Have you tried using a spectrum analyzer to characterize the signal in the > ether and compare it to what you are seeing in your systems? Yes, for sure i did. I am running C-Band at this location not first years, and know very well how industrial sources looks on spectrum analyser, and it is easy to triangulate them (i can go up to 9Ghz). Vessel radars also relatively easy to catch, especially with sound demodulation. > > Tom From denys at visp.net.lb Tue Feb 8 06:34:38 2011 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Tue, 8 Feb 2011 14:34:38 +0200 Subject: US Warships jamming Lebanon Internet In-Reply-To: <20110208124129.GC2861@skywalker.creative.net.au> References: <201102081359.39100.denys@visp.net.lb> <201102081426.50043.denys@visp.net.lb> <20110208124129.GC2861@skywalker.creative.net.au> Message-ID: <201102081434.38609.denys@visp.net.lb> On Tuesday 08 February 2011 14:41:29 Adrian Chadd wrote: > On Tue, Feb 08, 2011, Denys Fedoryshchenko wrote: > > On Tuesday 08 February 2011 14:18:59 Adrian Chadd wrote: > > > On Tue, Feb 08, 2011, Denys Fedoryshchenko wrote: > > > > I try to install C-Band bandpass filter, no effect at all, so it is > > > > in-band > > > > > > > > interference. Putting foil (yes i try almost everything) near LNB > > > > doesn't affect interference level too. > > > > > > Can you get access to some kind of spectrum analyser kit to see what > > > the kind of interference is? > > > > > > > > > > > > Adrian > > > > Yes, on short (few minutes) sweeps it is clean. During long time run, > > with 100 Khz resolution, if we run few hours we can catch anomalies on > > the carrier. Important note: this snapshot done on spectrum analyser in > > Europe, same transponder, and results similar, so it looks like > > interference is on transponder. Issue start to affect us at same time > > when people in Lebanon got local interference issues. > > > > Here is snapshot of carrier spectrum with anomaly: > > http//www.nuclearcat.com/PICTURES/interference.jpg > > And does this interference similarly screw up being able to RX data from > the transponder whilst in Europe? > > (eg, if you stick a modem on RX-only in Europe (ie, no uplink) and then > just lock onto the signal and decode whatever happens, do you suffer > the same problem?) Difficult, in Europe EIRP of transponder is too low, to try. By the way interference almost disappeared yesterday, and it's much better today. From tmagill at providecommerce.com Tue Feb 8 07:26:01 2011 From: tmagill at providecommerce.com (Thomas Magill) Date: Tue, 8 Feb 2011 13:26:01 +0000 Subject: US Warships jamming Lebanon Internet In-Reply-To: References: <201102071339.27793.denys@visp.net.lb> <5DBAD830D46E4F6D83545E653D8FB732@DELL16> <86DC8395-2588-445C-AF78-CDB0605FFA56@deadfrog.net> Message-ID: I'm in San Diego and at my last company we had to replace all 2.4Ghz wireless with 5Ghz when we started getting hammered across that range by a signal about 90db higher than our APs by something. We were never able to identify what it was, but the signal looked odd and an ex-navy coworker said it looked like encrypted navy traffic. It always came in burst and would disconnect every user when it happened. Too bad they weren't doing it the day we did our site survey. -----Original Message----- From: George Herbert [mailto:george.herbert at gmail.com] Sent: Monday, February 07, 2011 3:43 PM To: Ryan Wilkins Cc: nanog at nanog.org Subject: Re: US Warships jamming Lebanon Internet On Mon, Feb 7, 2011 at 2:23 PM, Ryan Wilkins wrote: > > On Feb 7, 2011, at 4:06 PM, Michael Painter wrote: >> >> Hi Denys >> I doubt it's intentional jamming since I've had the same problem. >> Aegis radar is very high power in full radiate mode and as such creates problems for Low Noise Amplifiers listening at 3.4-4.2 GHz. >> Someone needs to talk to Microwave Filter Company. >> http://www.microwavefilter.com/c-band_radar_elimination.htm >> >> --Michael > > +1 for Microwave Filter. ?They've helped me out in a couples jams before. ?They're very responsive and the products are good, too. I think people in San Diego and near Norfolk, VA have the same problems. The C-band frequencies are 2x those of the S-band (4-8 GHz for C, 2-4 GHz for S); if the SPY-1 / SPY-1D radar is frequency hopping it may well step on someone's C-band links at twice the radar's basic frequency. Just need a filter to remove actual S-band frequencies from C-band feeds. -- -george william herbert george.herbert at gmail.com From tshaw at oitc.com Tue Feb 8 07:46:31 2011 From: tshaw at oitc.com (TR Shaw) Date: Tue, 8 Feb 2011 08:46:31 -0500 Subject: US Warships jamming Lebanon Internet In-Reply-To: <201102081434.38609.denys@visp.net.lb> References: <201102081359.39100.denys@visp.net.lb> <201102081426.50043.denys@visp.net.lb> <20110208124129.GC2861@skywalker.creative.net.au> <201102081434.38609.denys@visp.net.lb> Message-ID: <052C3BF4-13C9-4AE1-BF5E-DC5AF16179C7@oitc.com> On Feb 8, 2011, at 7:34 AM, Denys Fedoryshchenko wrote: > On Tuesday 08 February 2011 14:41:29 Adrian Chadd wrote: >> On Tue, Feb 08, 2011, Denys Fedoryshchenko wrote: >>> On Tuesday 08 February 2011 14:18:59 Adrian Chadd wrote: >>>> On Tue, Feb 08, 2011, Denys Fedoryshchenko wrote: >>>>> I try to install C-Band bandpass filter, no effect at all, so it is >>>>> in-band >>>>> >>>>> interference. Putting foil (yes i try almost everything) near LNB >>>>> doesn't affect interference level too. >>>> >>>> Can you get access to some kind of spectrum analyser kit to see what >>>> the kind of interference is? >>>> >>>> >>>> >>>> Adrian >>> >>> Yes, on short (few minutes) sweeps it is clean. During long time run, >>> with 100 Khz resolution, if we run few hours we can catch anomalies on >>> the carrier. Important note: this snapshot done on spectrum analyser in >>> Europe, same transponder, and results similar, so it looks like >>> interference is on transponder. Issue start to affect us at same time >>> when people in Lebanon got local interference issues. >>> >>> Here is snapshot of carrier spectrum with anomaly: >>> http//www.nuclearcat.com/PICTURES/interference.jpg >> >> And does this interference similarly screw up being able to RX data from >> the transponder whilst in Europe? >> >> (eg, if you stick a modem on RX-only in Europe (ie, no uplink) and then >> just lock onto the signal and decode whatever happens, do you suffer >> the same problem?) > Difficult, in Europe EIRP of transponder is too low, to try. > By the way interference almost disappeared yesterday, and it's much better > today. > BTW, here is some comments on the pict from my office mate... It doesn't show what the sweep span is ... If it's the full transponder, could be narrow band carriers ... The gain slope across the pass band looks like CRAP ... He must have a funky LNB ... If this is one carrier, then obviously there?s interference ? If the spikes are there, it could be radar or it could be some type of burst TDMA junk ... I have articles talking about C Band inband interference in Europe somewhere ... Brian From denys at visp.net.lb Tue Feb 8 07:41:23 2011 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Tue, 8 Feb 2011 15:41:23 +0200 Subject: US Warships jamming Lebanon Internet In-Reply-To: <052C3BF4-13C9-4AE1-BF5E-DC5AF16179C7@oitc.com> References: <201102081359.39100.denys@visp.net.lb> <201102081434.38609.denys@visp.net.lb> <052C3BF4-13C9-4AE1-BF5E-DC5AF16179C7@oitc.com> Message-ID: <201102081541.23651.denys@visp.net.lb> On Tuesday 08 February 2011 15:46:31 TR Shaw wrote: > On Feb 8, 2011, at 7:34 AM, Denys Fedoryshchenko wrote: > > On Tuesday 08 February 2011 14:41:29 Adrian Chadd wrote: > >> On Tue, Feb 08, 2011, Denys Fedoryshchenko wrote: > >>> On Tuesday 08 February 2011 14:18:59 Adrian Chadd wrote: > >>>> On Tue, Feb 08, 2011, Denys Fedoryshchenko wrote: > >>>>> I try to install C-Band bandpass filter, no effect at all, so it is > >>>>> in-band > >>>>> > >>>>> interference. Putting foil (yes i try almost everything) near LNB > >>>>> doesn't affect interference level too. > >>>> > >>>> Can you get access to some kind of spectrum analyser kit to see what > >>>> the kind of interference is? > >>>> > >>>> > >>>> > >>>> Adrian > >>> > >>> Yes, on short (few minutes) sweeps it is clean. During long time run, > >>> with 100 Khz resolution, if we run few hours we can catch anomalies on > >>> the carrier. Important note: this snapshot done on spectrum analyser in > >>> Europe, same transponder, and results similar, so it looks like > >>> interference is on transponder. Issue start to affect us at same time > >>> when people in Lebanon got local interference issues. > >>> > >>> Here is snapshot of carrier spectrum with anomaly: > >>> http//www.nuclearcat.com/PICTURES/interference.jpg > >> > >> And does this interference similarly screw up being able to RX data from > >> the transponder whilst in Europe? > >> > >> (eg, if you stick a modem on RX-only in Europe (ie, no uplink) and then > >> just lock onto the signal and decode whatever happens, do you suffer > >> the same problem?) > > > > Difficult, in Europe EIRP of transponder is too low, to try. > > By the way interference almost disappeared yesterday, and it's much > > better today. > > BTW, here is some comments on the pict from my office mate... > > It doesn't show what the sweep span is ... If it's the full transponder, > could be narrow band carriers ... The gain slope across the pass band > looks like CRAP ... He must have a funky LNB ... If this is one carrier, > then obviously there?s interference ? If the spikes are there, it could be > radar or it could be some type of burst TDMA junk ... I have articles > talking about C Band inband interference in Europe somewhere ... Brian It is PLL LNB, one carrier, we are using full transponder 36 Mhz. There is almost no other users on this satellite (inclined more than 1.5 degree), and other carriers center frequency 100Mhz away. From hank at efes.iucc.ac.il Tue Feb 8 08:15:52 2011 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 08 Feb 2011 16:15:52 +0200 Subject: US Warships jamming Lebanon Internet In-Reply-To: <201102081359.39100.denys@visp.net.lb> Message-ID: <5.1.0.14.2.20110208161329.00bfaa38@efes.iucc.ac.il> At 13:59 08/02/2011 +0200, Denys Fedoryshchenko wrote: >On Tuesday 08 February 2011 01:42:42 George Herbert wrote: > > On Mon, Feb 7, 2011 at 2:23 PM, Ryan Wilkins wrote: > > > On Feb 7, 2011, at 4:06 PM, Michael Painter wrote: > > >> Hi Denys > > >> I doubt it's intentional jamming since I've had the same problem. > > >> Aegis radar is very high power in full radiate mode and as such creates > > >> problems for Low Noise Amplifiers listening at 3.4-4.2 GHz. Someone > > >> needs to talk to Microwave Filter Company. > > >> http://www.microwavefilter.com/c-band_radar_elimination.htm > > >> > > >> --Michael > > > > > > +1 for Microwave Filter. They've helped me out in a couples jams before. > > > They're very responsive and the products are good, too. > > > > I think people in San Diego and near Norfolk, VA have the same problems. > > > > The C-band frequencies are 2x those of the S-band (4-8 GHz for C, 2-4 > > GHz for S); if the SPY-1 / SPY-1D radar is frequency hopping it may > > well step on someone's C-band links at twice the radar's basic > > frequency. Just need a filter to remove actual S-band frequencies > > from C-band feeds. > I try to install C-Band bandpass filter, no effect at all, so it is in-band >interference. Putting foil (yes i try almost everything) near LNB doesn't >affect interference level too. Been there in 2007- different disruptor, though . See: http://en.wikipedia.org/wiki/Yes_%28Israel%29#Technical_problems_.28autumn_2007.29 http://www.haaretz.com/print-edition/business/a-nation-steps-up-to-rescue-yes-1.230782 -Hank From gb10hkzo-nanog at yahoo.co.uk Tue Feb 8 08:35:45 2011 From: gb10hkzo-nanog at yahoo.co.uk (gb10hkzo-nanog at yahoo.co.uk) Date: Tue, 8 Feb 2011 14:35:45 +0000 (GMT) Subject: Post-Exhaustion-phase "punishment" for early adopters Message-ID: <91338.18733.qm@web24704.mail.ird.yahoo.com> > Hint: even IPs not pingable from the Internet are being used. Not > everyone is an ISP/Webhoster ... with public services. I thought that was why we have RFC1918 ? From jared at puck.nether.net Tue Feb 8 08:42:41 2011 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 8 Feb 2011 09:42:41 -0500 Subject: Post-Exhaustion-phase "punishment" for early adopters In-Reply-To: <91338.18733.qm@web24704.mail.ird.yahoo.com> References: <91338.18733.qm@web24704.mail.ird.yahoo.com> Message-ID: Before arin etc it was possible to request ip space and on the form specify you would not be connecting to the Internet. Jared Mauch On Feb 8, 2011, at 9:35 AM, gb10hkzo-nanog at yahoo.co.uk wrote: >> Hint: even IPs not pingable from the Internet are being used. Not >> everyone is an ISP/Webhoster ... with public services. > > I thought that was why we have RFC1918 ? > > > > > From sam at spacething.org Tue Feb 8 09:25:42 2011 From: sam at spacething.org (Sam Stickland) Date: Tue, 8 Feb 2011 15:25:42 +0000 Subject: Post-Exhaustion-phase "punishment" for early adopters In-Reply-To: <91338.18733.qm@web24704.mail.ird.yahoo.com> References: <91338.18733.qm@web24704.mail.ird.yahoo.com> Message-ID: <1E8620FE-BC2C-4750-885B-63706D1853E1@spacething.org> I've worked in plenty of places where registered address was used on private interconnections between organisations to avoid overlaps, but never announced globally. S On 8 Feb 2011, at 14:35, gb10hkzo-nanog at yahoo.co.uk wrote: >> Hint: even IPs not pingable from the Internet are being used. Not >> everyone is an ISP/Webhoster ... with public services. > > I thought that was why we have RFC1918 ? > > > > > From bblackford at gmail.com Tue Feb 8 09:36:03 2011 From: bblackford at gmail.com (Bill Blackford) Date: Tue, 8 Feb 2011 07:36:03 -0800 Subject: Time Warner Transit In-Reply-To: <4D50896B.6030702@getsprocket.com> References: <4D50896B.6030702@getsprocket.com> Message-ID: They route well as compared to some in the same league. Latency is low. They must not over subscribe or run too congested. Paths in and out of PTLDOR appear fairly optimal. Have no data on other geo's. NOC support could be a bit more proactive. -b On Mon, Feb 7, 2011 at 4:08 PM, Christopher Wolff wrote: > Hey guys, > > What are you thinking about Time Warner transit lately? ?They claim to be > fully ready to support IPv6. > > Thanks in advance, you can hit me offlist if you're not able to share your > TWTC opinion publicly. > Christopher > > -- Bill Blackford Network Engineer Logged into reality and abusing my sudo privileges..... From neil at tonal.clara.co.uk Tue Feb 8 10:01:13 2011 From: neil at tonal.clara.co.uk (Neil Harris) Date: Tue, 08 Feb 2011 16:01:13 +0000 Subject: What's really needed is a routing slot market In-Reply-To: <5C836A1A98186142A6BEC393FD5E2A8601579F@hal.photon.com> References: <4D3F0144.70107@sohonet.co.uk><58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com><20110126043722.GA4110@skywalker.creative.net.au><1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar><4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org><4D4C0D25.70408@brightok.net><20110204231134.3AA029B2B39@drugs.dv.isc.org><4D4C8AF8.1030703@brightok.net><20110205004517.371F99B3B3C@drugs.dv.isc.org><4D4CA1B1.5060002@brightok.net><20110205124710.059259B4E31@drugs.dv.isc.org><4D4D5FFC.6020905@brightok.net><20110206010145.9DCD99B60B9@drugs.dv.isc.org><4D4DF75E.1040109@brightok.net><20110206024051.D60349B6D50@drugs.dv.isc.org> <5C836A1A98186142A6BEC393FD5E2A8601579F@hal.photon.com> Message-ID: <4D5168C9.6090808@tonal.clara.co.uk> On 07/02/11 14:25, Jamie Bowden wrote: > It would help if we weren't shipping the routing equivalent of the pre > DNS /etc/hosts all over the network (it's automated, but it's still the > equivalent). There has to be a better way to handle routing information > than what's currently being done. The old voice telephony guys built a > system that built SVCs on the fly from any phone in the world to any > other phone in the world; it (normally) took less than a second for it > to do it between any pair of phones under the NANPA, and only slightly > longer for international outside the US and Canada. There have to be > things to be learned from there. > > Jamie They did indeed, but they did it by centrally precomputing and then downloading centrally-built routing tables to each exchange, with added statically-configured routing between telco provider domains, and then doing step-by-step call setup, with added load balancing and crankback on the most-favoured links in the static routing table at each stage. All this works fine in a fairly static environment where there are only a few, well-known, and fairly trustworthy officially-endorsed entities involved within each country, and topology changes could be centrally planned. BGP is a hack, but it's a hack that works. I'm not sure how PSTN-style routing could have coped with the explosive growth of the Internet, with its very large number or routing participants with no central planning or central authority to establish trust, and an endlessly-churning routing topology. Still, every good old idea is eventually reinvented, so it may have its time again one day. -- Neil From rs at seastrom.com Tue Feb 8 10:07:26 2011 From: rs at seastrom.com (Robert E. Seastrom) Date: Tue, 08 Feb 2011 11:07:26 -0500 Subject: Membership model In-Reply-To: <24B61259-438C-4D9A-867A-E3AA9DE8CD55@delong.com> (Owen DeLong's message of "Mon, 7 Feb 2011 14:23:58 -0800") References: <20110207134502.F4601931@resin12.mta.everyone.net> <2E97D000-FF52-466C-B96F-9EC07E2F3F32@delong.com> <24B61259-438C-4D9A-867A-E3AA9DE8CD55@delong.com> Message-ID: <867hdao6gx.fsf@seastrom.com> Owen DeLong writes: > I fully expect the AAAA record to be placed soon and it looks like that > is the last remaining hurdle. Once that is done, I will pay my dues. There have been AAAA records in the zone for ages. I don't have a problem with you calling out our oversight on a public mailing list, but failure to CC the email address in the SOA's RNAME loses you a bit of best-practices high ground, don't you think? rs at bifrost [13] % rcsdiff -c -r1.4 -r1.5 newnog.org.db =================================================================== RCS file: RCS/newnog.org.db,v retrieving revision 1.4 retrieving revision 1.5 diff -c -r1.4 -r1.5 *** newnog.org.db 2010/05/24 22:46:54 1.4 --- newnog.org.db 2010/06/22 09:57:02 1.5 *************** *** 1,4 **** ! ; $Id: newnog.org.db,v 1.4 2010/05/24 22:46:54 rs Exp $ $ORIGIN newnog.org. --- 1,4 ---- ! ; $Id: newnog.org.db,v 1.5 2010/06/22 09:57:02 rs Exp $ $ORIGIN newnog.org. *************** *** 21,26 **** --- 21,29 ---- calendar IN CNAME ghs.google.com. sites IN CNAME ghs.google.com. + mailman IN A 216.211.130.244 + IN AAAA 2001:4970:eeee:7777::2 + _xmpp-server._tcp IN SRV 5 0 5269 xmpp-server.l.google.com. _xmpp-server._tcp IN SRV 20 0 5269 xmpp-server1.l.google.com. _xmpp-server._tcp IN SRV 20 0 5269 xmpp-server2.l.google.com. rs at bifrost [14] % I trust you are on top of sorting out Teh Paypal? Volunteering to help out with NANOG's educational outreach? Don't bother with cake; I can't eat it. -r PS: RCS is kicking it old-school, I know. From matt at conundrum.com Tue Feb 8 10:16:17 2011 From: matt at conundrum.com (Matthew Pounsett) Date: Tue, 8 Feb 2011 11:16:17 -0500 Subject: Upcoming DNS-OARC Workshop Message-ID: <373C21C4-7A38-4FCA-A29F-B547D978F37D@conundrum.com> Morning all, From all reports the recent DNS BoF at the Miami NANOG was well received. As a follow up, I'd like to the a moment to let everybody know about the upcoming DNS-OARC Workshop March 13th and 14th in San Francisco durning the ICANN 40 meeting. Both days are open to the public but attendees will have to register for the ICANN Meeting (free). This will be a joint workshop with the ccTLD Tech Day, a workshop put on by members of the ccNSO. The workshop brings together a wide range of DNS operators and experts for two days of presentations and discussion. Details on the meeting, venue and travel details can be found at . We are looking for speakers and there is a option on the Registration form to indicate your interest should you have a topic that you wish to present. Thanks in advance to the folks at ICANN for hosting us and to the ccNSO Tech Day team (Dr. Eberhard W Lisse, Jay Daley) for supporting the joint meeting. For those unfamiliar with DNS-OARC, we are a non-profit organization that was created to provide a trusted platform for members of the DNS community to share information. Our members include the DNS Root Operators, TLD and ccTLD operators, commercial ISPs and research organizations. More details on DNS-OARC can be found at . For more information, feel free to contact Wayne MacLaurin, Executive Director of DNS-OARC at wayne at dns-oarc.net. From paul at telcodata.us Tue Feb 8 10:36:12 2011 From: paul at telcodata.us (Paul Timmins) Date: Tue, 08 Feb 2011 11:36:12 -0500 Subject: What's really needed is a routing slot market In-Reply-To: <4D5168C9.6090808@tonal.clara.co.uk> References: <4D3F0144.70107@sohonet.co.uk><58166C50-0B72-43A0-8AB8-25E803EA1619@delong.com><20110126043722.GA4110@skywalker.creative.net.au><1296089078.6522.194.camel@karl> <4D4A40E0.6020806@gont.com.ar><4D4B3777.8020800@gont.com.ar> <20110204110304.GP23560@leitl.org><4D4C0D25.70408@brightok.net><20110204231134.3AA029B2B39@drugs.dv.isc.org><4D4C8AF8.1030703@brightok.net><20110205004517.371F99B3B3C@drugs.dv.isc.org><4D4CA1B1.5060002@brightok.net><20110205124710.059259B4E31@drugs.dv.isc.org><4D4D5FFC.6020905@brightok.net><20110206010145.9DCD99B60B9@drugs.dv.isc.org><4D4DF75E.1040109@brightok.net><20110206024051.D60349B6D50@drugs.dv.isc.org> <5C836A1A98186142A6BEC393FD5E2A8601579F@hal.photon.com> <4D5168C9.6090808@tonal.clara.co.uk> Message-ID: <4D5170FC.90405@telcodata.us> On 02/08/2011 11:01 AM, Neil Harris wrote: > > They did indeed, but they did it by centrally precomputing and then > downloading centrally-built routing tables to each exchange, with > added statically-configured routing between telco provider domains, > and then doing step-by-step call setup, with added load balancing and > crankback on the most-favoured links in the static routing table at > each stage. > > All this works fine in a fairly static environment where there are > only a few, well-known, and fairly trustworthy officially-endorsed > entities involved within each country, and topology changes could be > centrally planned. > > BGP is a hack, but it's a hack that works. I'm not sure how PSTN-style > routing could have coped with the explosive growth of the Internet, > with its very large number or routing participants with no central > planning or central authority to establish trust, and an > endlessly-churning routing topology. > > Still, every good old idea is eventually reinvented, so it may have > its time again one day. The way LNP works is a good example of PSTN style routing scaling. Each carrier has to have at least one NPA/NXX pair per switch, of which they pick one number they will never port out, and never assign to an end user, and declare that number as their LRN. There's nothing super special about this LRN, except that it's part of that NPA/NXX that's directly allocated to the carrier's switch as the original assignee. When a phone call is made, a TCAP query is launched by the originating switch to a set of STPs that then route it to an LNP database, that has a full list of every ported number, and its LRN, and a few other tidbits of info. The switch then sees the LRN in the response, sets the called party number to the LRN, and then sets the "Generic Address Parameter" parameter in the ISUP message to the originally dialed number. This tunnels it through a network that is unaware of LNP, and when the terminating switch sees its own LRN as the destination, it moves the Generic Address Parameter back to the Called Party Number and continues processing. -Paul From john.mason.jr at cox.net Tue Feb 8 10:39:39 2011 From: john.mason.jr at cox.net (John Mason Jr) Date: Tue, 08 Feb 2011 11:39:39 -0500 Subject: WebServer and Firewall Help In-Reply-To: <4D513549.8020307@emmanuelcomputerconsulting.com> References: <4D513549.8020307@emmanuelcomputerconsulting.com> Message-ID: <4D5171CB.5060900@cox.net> On 2/8/2011 7:21 AM, William Warren wrote: > On 2/7/2011 1:23 PM, Joshua William Klubi wrote: >> Hi, >> >> I run a web-server based on ubuntu server and the LAMP stack. >> I used Ubuntu's UFW firewall model and have enabled only Web and SSH >> ports. >> Namely port 80 and port 22 only. >> >> Unfortunately once a while some guys get to inject some content onto >> our web >> pages. >> >> Now managements are looking at getting a well proven infrastructure to >> counter that. >> But I also think i can fall on this community to help me get the >> right stuff >> done. Where >> i can protect the server from such attack. >> >> >> I want to know what measure i can do on the server to get it >> protected which >> mysql protection >> I should implement. since i can see that it might be a php or mysql >> injection that is been used. >> >> Currently I run these security measures on it. >> Ubuntu UFW >> Fail2ban >> PHP model security >> Apache security >> >> Joshua > the problem may not be your operating system but the web application > running. what web application/s are on that box? > > > Might also take a look at http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project John From matthew at matthew.at Tue Feb 8 11:17:38 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 08 Feb 2011 09:17:38 -0800 Subject: Post-Exhaustion-phase "punishment" for early adopters In-Reply-To: <1E8620FE-BC2C-4750-885B-63706D1853E1@spacething.org> References: <91338.18733.qm@web24704.mail.ird.yahoo.com> <1E8620FE-BC2C-4750-885B-63706D1853E1@spacething.org> Message-ID: <4D517AB2.7000105@matthew.at> On 2/8/2011 7:25 AM, Sam Stickland wrote: > I've worked in plenty of places where registered address was used on private interconnections between organisations to avoid overlaps, but never announced globally. There's no such thing as "globally" anyway. Your view of the Internet routing table != my view of the Internet routing table except in very limited circumstances. Matthew Kaufman From skurylo+nanog at gmail.com Tue Feb 8 11:48:26 2011 From: skurylo+nanog at gmail.com (Steven Kurylo) Date: Tue, 8 Feb 2011 09:48:26 -0800 Subject: Random Port Blocking at Hotels (was: Re: quietly....) In-Reply-To: References: <20110205150005.40621.qmail@joyce.lan> <20110206011404.A19A99B625C@drugs.dv.isc.org> Message-ID: On Sat, Feb 5, 2011 at 5:34 PM, Derek J. Balling wrote: > > On Feb 5, 2011, at 8:14 PM, Mark Andrews wrote: >> I have told a hotel they need to install equipment that supports RA >> guard as I've checked out. ?This was a hotel that only offered IPv4. > > Wow... Could that be any more of a waste of yours and their time? > > This is like telling the cashier at the hospital when you're being discharged, "y'know, I'm not sure that they're using the proper stitch-knot in the ER. You should have someone look at that." > > Do you honestly think that feedback is even *understood*, let alone passed on to anyone even close to the problem? > Well, around here the front desk would pass it along and it would reach me; more so if they don't understand it. Though if it wasn't in writing, it would probably become unintelligible. Am I in a position to do something about it? Probably not. From jbates at brightok.net Tue Feb 8 12:53:14 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 08 Feb 2011 12:53:14 -0600 Subject: US Warships jamming Lebanon Internet In-Reply-To: <201102081541.23651.denys@visp.net.lb> References: <201102081359.39100.denys@visp.net.lb> <201102081434.38609.denys@visp.net.lb> <052C3BF4-13C9-4AE1-BF5E-DC5AF16179C7@oitc.com> <201102081541.23651.denys@visp.net.lb> Message-ID: <4D51911A.2060008@brightok.net> On 2/8/2011 7:41 AM, Denys Fedoryshchenko wrote: > It is PLL LNB, one carrier, we are using full transponder 36 Mhz. There is > almost no other users on this satellite (inclined more than 1.5 degree), and > other carriers center frequency 100Mhz away. > Since no one else will, "I blame solar flares!" Jack From joshua.klubi at gmail.com Tue Feb 8 14:00:55 2011 From: joshua.klubi at gmail.com (Joshua Klubi) Date: Tue, 8 Feb 2011 20:00:55 +0000 Subject: WebServer and Firewall Help In-Reply-To: <4D513549.8020307@emmanuelcomputerconsulting.com> References: <4D513549.8020307@emmanuelcomputerconsulting.com> Message-ID: It is a LAMP. Stack Joshua Sent from my iPhone On Feb 8, 2011, at 12:21, William Warren wrote: > On 2/7/2011 1:23 PM, Joshua William Klubi wrote: >> Hi, >> >> I run a web-server based on ubuntu server and the LAMP stack. >> I used Ubuntu's UFW firewall model and have enabled only Web and SSH ports. >> Namely port 80 and port 22 only. >> >> Unfortunately once a while some guys get to inject some content onto our web >> pages. >> >> Now managements are looking at getting a well proven infrastructure to >> counter that. >> But I also think i can fall on this community to help me get the right stuff >> done. Where >> i can protect the server from such attack. >> >> >> I want to know what measure i can do on the server to get it protected which >> mysql protection >> I should implement. since i can see that it might be a php or mysql >> injection that is been used. >> >> Currently I run these security measures on it. >> Ubuntu UFW >> Fail2ban >> PHP model security >> Apache security >> >> Joshua > the problem may not be your operating system but the web application running. what web application/s are on that box? > From johnl at iecc.com Tue Feb 8 14:13:35 2011 From: johnl at iecc.com (John Levine) Date: 8 Feb 2011 20:13:35 -0000 Subject: Telco style routing, was What's really needed is a routing slot market In-Reply-To: <4D5170FC.90405@telcodata.us> Message-ID: <20110208201335.86633.qmail@joyce.lan> >The way LNP works is a good example of PSTN style routing scaling. ... >When a phone call is made, a TCAP query is launched by the originating >switch to a set of STPs that then route it to an LNP database, that has >a full list of every ported number, and its LRN, and a few other tidbits >of info. Right. That works great in an environment where the regulators require that every telco pay Neustar to maintain the LNP databases, and send all the updates promptly when a number is ported or disconnected. The telcos pay Neustar $300 million a year to run the database. I'm sure they'd be delighted to run a similar database for IP networks at a similar price. Of course, that just handles the networks in the U.S. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From joe.abley at icann.org Tue Feb 8 14:27:15 2011 From: joe.abley at icann.org (Joe Abley) Date: Tue, 08 Feb 2011 20:27:15 +0000 Subject: Root Zone DNSSEC KSK Ceremony 4 Completed Message-ID: KSK CEREMONY 4 The fourth KSK ceremony for the root zone took place in El Segundo, CA, USA on Monday 2011-02-07. The Ceremony Administrator was Mehmet Akcin. The ceremony was completed successfully. Video from Ceremony 4 was recorded for audit purposes. Video and associated audit materials will be published in 1 to 2 weeks, and will be available as usual by following the "KSK Ceremony Materials" link at . Ceremony 4 included processing of a Key Signing Request (KSR) generated by VeriSign, and the resulting Signed Key Response (SKR) contained signatures for Q2 2011, for use in the root zone between 2011-04-01 and 2011-07-05. CONTACT INFORMATION We'd like to hear from you. If you have feedback for us, please send it to rootsign at icann.org. From nathan at atlasnetworks.us Tue Feb 8 14:55:05 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Tue, 8 Feb 2011 20:55:05 +0000 Subject: Telco style routing, was What's really needed is a routing slot market In-Reply-To: <20110208201335.86633.qmail@joyce.lan> References: <4D5170FC.90405@telcodata.us> <20110208201335.86633.qmail@joyce.lan> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B365A92@ex-mb-1.corp.atlasnetworks.us> > Right. That works great in an environment where the regulators require that > every telco pay Neustar to maintain the LNP databases, and send all the > updates promptly when a number is ported or disconnected. > > The telcos pay Neustar $300 million a year to run the database. I'm sure > they'd be delighted to run a similar database for IP networks at a similar > price. Of course, that just handles the networks in the U.S. One of the challenges in the VOIP world these days IS call routing based on destination DID. It's easy to ship calls out trunks; it's far more compelling to send them to the destination PBX directly over UDP/IP. Sadly, the best mechanism anyone has come up with is manual number publishing in an rDNS style database, and the results are less than stellar... Nathan From marka at isc.org Tue Feb 8 16:04:42 2011 From: marka at isc.org (Mark Andrews) Date: Wed, 09 Feb 2011 09:04:42 +1100 Subject: Post-Exhaustion-phase "punishment" for early adopters In-Reply-To: Your message of "Tue, 08 Feb 2011 09:17:38 -0800." <4D517AB2.7000105@matthew.at> References: <91338.18733.qm@web24704.mail.ird.yahoo.com> <1E8620FE-BC2C-4750-885B-63706D1853E1@spacething.org><4D517AB2.7000105@matthew.at> Message-ID: <20110208220442.90F889D4BED@drugs.dv.isc.org> I wish people would actually read RFC 1918. Category 1: hosts that do not require access to hosts in other enterprises or the Internet at large; hosts within this category may use IP addresses that are unambiguous within an enterprise, but may be ambiguous between enterprises. Category 2: hosts that need access to a limited set of outside services (e.g., E-mail, FTP, netnews, remote login) which can be handled by mediating gateways (e.g., application layer gateways). For many hosts in this category an unrestricted external access (provided via IP connectivity) may be unnecessary and even undesirable for privacy/security reasons. Just like hosts within the first category, such hosts may use IP addresses that are unambiguous within an enterprise, but may be ambiguous between enterprises. Category 3: hosts that need network layer access outside the enterprise (provided via IP connectivity); hosts in the last category require IP addresses that are globally unambiguous. RFC 1918 addresses for machines that fall in Categories 1 and 2. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From brandon at rd.bbc.co.uk Tue Feb 8 16:46:34 2011 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Tue, 8 Feb 2011 22:46:34 GMT Subject: Post-Exhaustion-phase "punishment" for early adopters Message-ID: <201102082246.WAA19334@sunf10.rd.bbc.co.uk> > Before arin etc it was possible to request ip space and on the > form specify you would not be connecting to the Internet. So those off net users can't complain if ARIN allocated the same ranges on net. Not that it's worth doing so now. V6, drive fast. brandon From george.herbert at gmail.com Tue Feb 8 16:59:12 2011 From: george.herbert at gmail.com (George Herbert) Date: Tue, 8 Feb 2011 14:59:12 -0800 Subject: Post-Exhaustion-phase "punishment" for early adopters In-Reply-To: <20110208220442.90F889D4BED@drugs.dv.isc.org> References: <91338.18733.qm@web24704.mail.ird.yahoo.com> <1E8620FE-BC2C-4750-885B-63706D1853E1@spacething.org> <4D517AB2.7000105@matthew.at> <20110208220442.90F889D4BED@drugs.dv.isc.org> Message-ID: On Tue, Feb 8, 2011 at 2:04 PM, Mark Andrews wrote: > > I wish people would actually read RFC 1918. > > ? ? ?Category 1: hosts that do not require access to hosts in other > ? ? ? ? ? ? ? ? ?enterprises or the Internet at large; hosts within > ? ? ? ? ? ? ? ? ?this category may use IP addresses that are > ? ? ? ? ? ? ? ? ?unambiguous within an enterprise, but may be > ? ? ? ? ? ? ? ? ?ambiguous between enterprises. > > ? ? ?Category 2: hosts that need access to a limited set of outside > ? ? ? ? ? ? ? ? ?services (e.g., E-mail, FTP, netnews, remote login) > ? ? ? ? ? ? ? ? ?which can be handled by mediating gateways (e.g., > ? ? ? ? ? ? ? ? ?application layer gateways). For many hosts in this > ? ? ? ? ? ? ? ? ?category an unrestricted external access (provided > ? ? ? ? ? ? ? ? ?via IP connectivity) may be unnecessary and even > ? ? ? ? ? ? ? ? ?undesirable for privacy/security reasons. Just like > ? ? ? ? ? ? ? ? ?hosts within the first category, such hosts may use > ? ? ? ? ? ? ? ? ?IP addresses that are unambiguous within an > ? ? ? ? ? ? ? ? ?enterprise, but may be ambiguous between > ? ? ? ? ? ? ? ? ?enterprises. > > ? ? ?Category 3: hosts that need network layer access outside the > ? ? ? ? ? ? ? ? ?enterprise (provided via IP connectivity); hosts in > ? ? ? ? ? ? ? ? ?the last category require IP addresses that are > ? ? ? ? ? ? ? ? ?globally unambiguous. > > RFC 1918 addresses for machines that fall in Categories 1 and 2. You're assuming there that people followed the directions. That is demonstrably false. It's easy to say "Well, foo on them", but for those of us who provide services or consulting to those who failed to follow the directions, we still have to deal with it. -- -george william herbert george.herbert at gmail.com From Valdis.Kletnieks at vt.edu Tue Feb 8 17:08:13 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 08 Feb 2011 18:08:13 -0500 Subject: Post-Exhaustion-phase "punishment" for early adopters In-Reply-To: Your message of "Tue, 08 Feb 2011 14:59:12 PST." References: <91338.18733.qm@web24704.mail.ird.yahoo.com> <1E8620FE-BC2C-4750-885B-63706D1853E1@spacething.org> <4D517AB2.7000105@matthew.at> <20110208220442.90F889D4BED@drugs.dv.isc.org> Message-ID: <46347.1297206493@localhost> On Tue, 08 Feb 2011 14:59:12 PST, George Herbert said: > It's easy to say "Well, foo on them", but for those of us who provide > services or consulting to those who failed to follow the directions, > we still have to deal with it. Just remember that if they *had* followed the directions, your billable hours would drop... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From shrdlu at deaddrop.org Tue Feb 8 17:12:09 2011 From: shrdlu at deaddrop.org (Lynda) Date: Tue, 08 Feb 2011 15:12:09 -0800 Subject: Post-Exhaustion-phase "punishment" for early adopters In-Reply-To: <201102082246.WAA19334@sunf10.rd.bbc.co.uk> References: <201102082246.WAA19334@sunf10.rd.bbc.co.uk> Message-ID: <4D51CDC9.8010709@deaddrop.org> On 2/8/2011 2:46 PM, Brandon Butterworth wrote: >> Before arin etc it was possible to request ip space and on the >> form specify you would not be connecting to the Internet. > > So those off net users can't complain if ARIN allocated the > same ranges on net. Not that it's worth doing so now. I hoped I was going to be able to resist answering this. I can't. There are networks out there that are large, and interconnected, and using valid, assigned IP addresses, that have never been seen on a public router. Never will, either. It's more convenient to use real addresses than 1918 blocks. It works better in the DNS, and it's easier to wrap your mind around when you're working math problems about how much to delegate, and where. Those blocks remain allocated to the original recipients. I just looked (via whois). They are all still there. I remain amazed that I have them all still memorized. I guess Alzheimer's hasn't struck yet. -- Amor fati. Vale. (Seneca) From george.herbert at gmail.com Tue Feb 8 17:49:09 2011 From: george.herbert at gmail.com (George Herbert) Date: Tue, 8 Feb 2011 15:49:09 -0800 Subject: Post-Exhaustion-phase "punishment" for early adopters In-Reply-To: <46347.1297206493@localhost> References: <91338.18733.qm@web24704.mail.ird.yahoo.com> <1E8620FE-BC2C-4750-885B-63706D1853E1@spacething.org> <4D517AB2.7000105@matthew.at> <20110208220442.90F889D4BED@drugs.dv.isc.org> <46347.1297206493@localhost> Message-ID: On Tue, Feb 8, 2011 at 3:08 PM, wrote: > On Tue, 08 Feb 2011 14:59:12 PST, George Herbert said: > >> It's easy to say "Well, foo on them", but for those of us who provide >> services or consulting to those who failed to follow the directions, >> we still have to deal with it. > > Just remember that if they *had* followed the directions, your > billable hours would drop... I had intended a snappy response including mention of ponies, however, while I was considering whether it was list-appropriate or not a coworker emailed me in response to this thread and reminded me of the mutual former client who grabbed 2/8 a few years ago and used it extensively internally. "Let's just grab 2/8, it's not routed on the Internet..." Whose actual perpetrator was allegedly another NANOGer, so it wasn't even brute ignorance (I am not sure it was them, so if not my apologies). In slight defense, this was to handle problems with extensive conflicts where this company and a number of telcos were having widespread 10/8 1918 space collisions and had no good solutions to it (apparently, the telcos failed to read 1918 closely enough and consider that any partner might ever need to route to their internal allocations). Thank you, anonymous coworker, for reminding me how glad I am that A) I'm not there at that client anymore, B) That it's turning that net off this year. *twitch* *twitch* -george -- -george william herbert george.herbert at gmail.com From cmaurand at xyonet.com Tue Feb 8 18:14:32 2011 From: cmaurand at xyonet.com (Curtis Maurand) Date: Tue, 08 Feb 2011 19:14:32 -0500 Subject: WebServer and Firewall Help In-Reply-To: References: <4D513549.8020307@emmanuelcomputerconsulting.com> Message-ID: <4D51DC68.6070007@xyonet.com> On 2/8/2011 3:00 PM, Joshua Klubi wrote: > >>> I want to know what measure i can do on the server to get it protected which >>> mysql protection >>> I should implement. since i can see that it might be a php or mysql >>> injection that is been used. >>> >>> Currently I run these security measures on it. >>> Ubuntu UFW >>> Fail2ban >>> PHP model security >>> Apache security >>> >>> Joshua >> the problem may not be your operating system but the web application running. what web application/s are on that box? >> I agree, you've got other problems. I would look at defending against sql injection attacks and I would look to making sure that all the passwords get changed. From bensons at queuefull.net Tue Feb 8 18:46:05 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Tue, 8 Feb 2011 18:46:05 -0600 Subject: Post-Exhaustion-phase "punishment" for early adopters In-Reply-To: <4D51CDC9.8010709@deaddrop.org> References: <201102082246.WAA19334@sunf10.rd.bbc.co.uk> <4D51CDC9.8010709@deaddrop.org> Message-ID: <9EC66058-357E-48E7-A839-829367E240E4@queuefull.net> On Feb 8, 2011, at 5:12 PM, Lynda wrote: > On 2/8/2011 2:46 PM, Brandon Butterworth wrote: >>> Before arin etc it was possible to request ip space and on the >>> form specify you would not be connecting to the Internet. >> >> So those off net users can't complain if ARIN allocated the >> same ranges on net. Not that it's worth doing so now. > > I hoped I was going to be able to resist answering this. I can't. > > There are networks out there that are large, and interconnected, and using valid, assigned IP addresses, that have never been seen on a public router. Never will, either. It's more convenient to use real addresses than 1918 blocks. It works better in the DNS, and it's easier to wrap your mind around when you're working math problems about how much to delegate, and where. > > Those blocks remain allocated to the original recipients. I just looked (via whois). They are all still there. I remain amazed that I have them all still memorized. I guess Alzheimer's hasn't struck yet. It's not just a case of convenience, either. Try connecting hundreds of private networks (each running their own context of 1918 space) to a common network-based service without using globally unique addresses. Not even NAT can help you, if your centralized servers have the same addresses as the network participants. And the uniqueness requirements don't change just because this "little i" internet isn't routed on the "big I" Internet. Cheers, -Benson From cmaurand at xyonet.com Tue Feb 8 18:46:12 2011 From: cmaurand at xyonet.com (Curtis Maurand) Date: Tue, 08 Feb 2011 19:46:12 -0500 Subject: Last of ipv4 /8's allocated In-Reply-To: <580612789.1585.1296611569925.JavaMail.root@zimbra.network1.net> References: <580612789.1585.1296611569925.JavaMail.root@zimbra.network1.net> Message-ID: <4D51E3D4.8030302@xyonet.com> > Touch?! That could theoretically happen. I think Apple should buy HPQDEC just so they can announce 16/7 :-) > > None of the RIR blocks are going to be routed that way on purpose, though :-) > > -Randy > > I agree. Many of those corporations would have a hard time justifying an entire /8, even IBM. They just don't run large public networks any longer. Much of what they do is done on private nets. I would make all of the corporate legacy networks justify their /8's. I'll almost bet none of them can justify them any longer. I worked for a large medical company (30,000 seats) and we didn't use an entire /24. --Curtis From owen at delong.com Tue Feb 8 18:58:24 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 8 Feb 2011 16:58:24 -0800 Subject: Last of ipv4 /8's allocated In-Reply-To: <4D51E3D4.8030302@xyonet.com> References: <580612789.1585.1296611569925.JavaMail.root@zimbra.network1.net> <4D51E3D4.8030302@xyonet.com> Message-ID: On Feb 8, 2011, at 4:46 PM, Curtis Maurand wrote: > > >> Touch?! That could theoretically happen. I think Apple should buy HPQDEC just so they can announce 16/7 :-) >> >> None of the RIR blocks are going to be routed that way on purpose, though :-) >> >> -Randy >> >> > I agree. Many of those corporations would have a hard time justifying an entire /8, even IBM. They just don't run large public networks any longer. Much of what they do is done on private nets. I would make all of the corporate legacy networks justify their /8's. I'll almost bet none of them can justify them any longer. I worked for a large medical company (30,000 seats) and we didn't use an entire /24. > > --Curtis > > It doesn't have to be a public network to need globally unique addresses. There is NO policy requirement to use NAT or RFC-1918 for private networks. Just a suggestion that folks be considerate of the community where they can. I'll bet most of them would have no problem under current policy. They only need to show need for ~8,000,000 hosts, including subnet overhead. If you wanted to, your medical company could have easily justified at least a /17 and probably a /16 under current policy. There's really nothing to be gained from attempting to go after what might be reclaimed from the legacy block holders. EIther they will return their addresses or contribute them to the market or they won't. Attempts at forced reclamation will only make that situation worse and are unlikely to result in any actual reclamation of addresses before the conclusion of protracted and ugly law suits that would be very expensive. Such lawsuits are unlikely to reach conclusion before the need for massive quantities of IPv4 address space is in the past. Owen From mpetach at netflight.com Tue Feb 8 18:59:51 2011 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 8 Feb 2011 16:59:51 -0800 Subject: What's really needed is a routing slot market (was: Using IPv6 withprefixes shorter than a /64 on a LAN) In-Reply-To: <84F7634862692847B463C7934B86ECD9E3E68E5F@CMX001.corp.tds.local> References: <84F7634862692847B463C7934B86ECD9E3E68E5F@CMX001.corp.tds.local> Message-ID: On Mon, Feb 7, 2011 at 1:45 PM, Koch, Andrew wrote: > On Mon, Feb 7, 2011 at 3:10 PM, Owen DeLong > >> That's as close as I think I can get to an IPv6 CIDR report >> for the moment. > > Looks like Geoff has you already setup. > > http://www.cidr-report.org/v6/as2.0/ > > Andy Koch Excellent, thanks! Exactly what I was hoping to see get developed. ^_^ Wow. Did _not_ expect to see Google at the top of the evil list. ^_^;; ASnum NetsNow NetsAggr NetGain % Gain Description AS15169 38 8 30 78.9% GOOGLE - Google Inc. Makes my deaggregation seem almost not worth worrying about. :D Matt From cmaurand at xyonet.com Tue Feb 8 19:17:44 2011 From: cmaurand at xyonet.com (Curtis Maurand) Date: Tue, 08 Feb 2011 20:17:44 -0500 Subject: Last of ipv4 /8's allocated In-Reply-To: References: <580612789.1585.1296611569925.JavaMail.root@zimbra.network1.net> <4D51E3D4.8030302@xyonet.com> Message-ID: <4D51EB38.101@xyonet.com> On 2/8/2011 7:58 PM, Owen DeLong wrote: > > It doesn't have to be a public network to need globally unique addresses. > > There is NO policy requirement to use NAT or RFC-1918 for private networks. Just a suggestion that folks be considerate of the community where they can. > > I'll bet most of them would have no problem under current policy. They only need to show need for ~8,000,000 hosts, including subnet overhead. > > If you wanted to, your medical company could have easily justified at least a /17 and probably a /16 under current policy. > > There's really nothing to be gained from attempting to go after what might be reclaimed from the legacy block holders. EIther > they will return their addresses or contribute them to the market or they won't. Attempts at forced reclamation will only make > that situation worse and are unlikely to result in any actual reclamation of addresses before the conclusion of protracted > and ugly law suits that would be very expensive. Such lawsuits are unlikely to reach conclusion before the need for > massive quantities of IPv4 address space is in the past. > > Owen > Point taken. --C From Ben.Kessler at zenetra.com Tue Feb 8 20:43:28 2011 From: Ben.Kessler at zenetra.com (R. Benjamin Kessler) Date: Wed, 9 Feb 2011 02:43:28 +0000 Subject: Post-Exhaustion-phase "punishment" for early adopters In-Reply-To: References: <91338.18733.qm@web24704.mail.ird.yahoo.com> <1E8620FE-BC2C-4750-885B-63706D1853E1@spacething.org> <4D517AB2.7000105@matthew.at> <20110208220442.90F889D4BED@drugs.dv.isc.org> <46347.1297206493@localhost> Message-ID: <0CFF54003CD92945994CF0C0F90D81B670647E@EXCH1-FWA1.zenetra.local> >>From: George Herbert [mailto:george.herbert at gmail.com] >>"Let's just grab 2/8, it's not routed on the Internet..." +1 I was consulting for a financial services firm in the late '90s that was acquired by a large east-coast bank; the bank's brilliant scheme was to renumber all new acquisitions *out* of RFC1918 space and into (at the time) bogon space. If I recall, some of the arguments were "they were too big to fit into RFC1918 space" and by having all of their divisions in non-RFC1918 space it would make it easier for them to acquire new companies who used RFC1918 space internally. I wonder what they're doing now... From thegameiam at yahoo.com Tue Feb 8 20:54:25 2011 From: thegameiam at yahoo.com (David Barak) Date: Tue, 8 Feb 2011 18:54:25 -0800 (PST) Subject: Post-Exhaustion-phase "punishment" for early adopters In-Reply-To: <0CFF54003CD92945994CF0C0F90D81B670647E@EXCH1-FWA1.zenetra.local> References: <91338.18733.qm@web24704.mail.ird.yahoo.com> <1E8620FE-BC2C-4750-885B-63706D1853E1@spacething.org> <4D517AB2.7000105@matthew.at> <20110208220442.90F889D4BED@drugs.dv.isc.org> <46347.1297206493@localhost> <0CFF54003CD92945994CF0C0F90D81B670647E@EXCH1-FWA1.zenetra.local> Message-ID: <715917.52283.qm@web31802.mail.mud.yahoo.com> ? >From: R. Benjamin Kessler >>From: George Herbert [mailto:george.herbert at gmail.com] >>"Let's just grab 2/8, it's not routed on the Internet..." >+1 >I was consulting for a financial services firm in the late '90s that was >acquired by a large east-coast bank; the bank's brilliant scheme >was to >renumber all new acquisitions *out* of RFC1918 space and into (at the time) >bogon space.? > >If I recall, some of the arguments were "they were too big to fit into RFC1918 >space" and by having all of their divisions in non->RFC1918 space it would make >it easier for them to acquire new companies who used RFC1918 space internally. >I wonder what they're doing now... If we make the assumption that the hosts which were numbered in the space formerly known as bogon are typical enterprise hosts, it wouldn't be surprising if they were just?fine: they probably don't *want* to have end-to-end connectivity, and are perfectly happy with the proxy-everything approach. If you're going to NAT everything anyway, then the damage done by having 2/8 on both sides of the NAT isn't any worse than having 10/8 on both sides of the NAT.? If it turns out that they start running across the hosts in 2/8 as customers, those can get NATted into some third block, with probably a lot less effort and confusion than trying to sort out the chunks of overlapping 10/8s. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com From ryan.finnesey at HarrierInvestments.com Tue Feb 8 21:36:21 2011 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Tue, 8 Feb 2011 19:36:21 -0800 Subject: Sales - Global Crossing or Colt? Message-ID: <6EFFEFBAC68377459A2E972105C759EC0353A129@EXVBE005-2.exch005intermedia.net> Would anyone have a carrier sales contact at Global Crossing or Colt? It is very important I get someone that is within the carrier/wholesale group sales From george.herbert at gmail.com Tue Feb 8 22:21:02 2011 From: george.herbert at gmail.com (George Herbert) Date: Tue, 8 Feb 2011 20:21:02 -0800 Subject: Post-Exhaustion-phase "punishment" for early adopters In-Reply-To: <715917.52283.qm@web31802.mail.mud.yahoo.com> References: <91338.18733.qm@web24704.mail.ird.yahoo.com> <1E8620FE-BC2C-4750-885B-63706D1853E1@spacething.org> <4D517AB2.7000105@matthew.at> <20110208220442.90F889D4BED@drugs.dv.isc.org> <46347.1297206493@localhost> <0CFF54003CD92945994CF0C0F90D81B670647E@EXCH1-FWA1.zenetra.local> <715917.52283.qm@web31802.mail.mud.yahoo.com> Message-ID: On Tue, Feb 8, 2011 at 6:54 PM, David Barak wrote: > > >>From: R. Benjamin Kessler > >>>From: George Herbert [mailto:george.herbert at gmail.com] > >>>"Let's just grab 2/8, it's not routed on the Internet..." > >>+1 > >>I was consulting for a financial services firm in the late '90s that was >>acquired by a large east-coast bank; the bank's brilliant scheme >was to >>renumber all new acquisitions *out* of RFC1918 space and into (at the time) >>bogon space. >> > >>If I recall, some of the arguments were "they were too big to fit into RFC1918 >>space" and by having all of their divisions in non->RFC1918 space it would make >>it easier for them to acquire new companies who used RFC1918 space internally. > >>I wonder what they're doing now... > > > > If we make the assumption that the hosts which were numbered in the space > formerly known as bogon are typical enterprise hosts, it wouldn't be surprising > if they were just?fine: they probably don't *want* to have end-to-end > connectivity, and are perfectly happy with the proxy-everything approach. > > If you're going to NAT everything anyway, then the damage done by having 2/8 on > both sides of the NAT isn't any worse than having 10/8 on both sides of the > NAT.? If it turns out that they start running across the hosts in 2/8 as > customers, those can get NATted into some third block, with probably a lot less > effort and confusion than trying to sort out the chunks of overlapping 10/8s. If you could really proxy everything, you'd be able to use 10/8 everywhere and never hit problems, even if two private peers overlap in usage within 10/8. I can assure you that the "proxy everything" statement breaks down with every enterprise-to-enterprise interconnection project I've run into. There are some protocols that are just not meant to do that. -- -george william herbert george.herbert at gmail.com From vikassharmas at gmail.com Tue Feb 8 22:24:35 2011 From: vikassharmas at gmail.com (Vikas Sharma) Date: Wed, 9 Feb 2011 09:54:35 +0530 Subject: Ipv6 addressing for Core network Message-ID: Hi, I am looking for the recommendation for core interfaces IP addressing schema for Ipv6. Some different views are (PE- P - PE, point to point link) as below - 1- Use Public Ipv6 with /122 and do not advertise to Internet 2- Use Public Ipv6 with /127 and do not advertise to Internet 3- Use Unique local ipv6 address 4- Use Public Ipv6 with /64 Also I am interested to understand the impact on TCAM ... Regards, Vikas From gbonser at seven.com Wed Feb 9 00:41:47 2011 From: gbonser at seven.com (George Bonser) Date: Tue, 8 Feb 2011 22:41:47 -0800 Subject: Ipv6 addressing for Core network In-Reply-To: References: Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC1393F@RWC-EX1.corp.seven.com> > I am looking for the recommendation for core interfaces IP addressing > schema > for Ipv6. Some different views are (PE- P - PE, point to point link) as > below - > > 1- Use Public Ipv6 with /122 and do not advertise to Internet > 2- Use Public Ipv6 with /127 and do not advertise to Internet > 3- Use Unique local ipv6 address > 4- Use Public Ipv6 with /64 > > Also I am interested to understand the impact on TCAM ... > > Regards, > Vikas I would use a /64 with ND turned off and static neighbors configured. TCAM impact will depend on vendor. Some vendors give you the option of storing the first 64 bits of a V6 IP or the entire address. Using a /64 means your CAM usage might be less depending on your vendor. If the addresses on the point-to-point links never accept or source direct traffic to/from outside your net, you can use whatever you want on them. ULA might be ok there. I am using public IPs but I filter traffic destined for them at the edge but to each their own choice. But if you use ULA you aren't going to be able to ping anything outside your net if you source the pings from the ULA interface. Just something to keep in mind. What you are asking is a matter of individual preference. From lear at cisco.com Wed Feb 9 00:42:09 2011 From: lear at cisco.com (Eliot Lear) Date: Wed, 09 Feb 2011 07:42:09 +0100 Subject: What's really needed is a routing slot market In-Reply-To: <20110206211644.34560.qmail@joyce.lan> References: <20110206211644.34560.qmail@joyce.lan> Message-ID: <4D523741.8090704@cisco.com> Hi everyone, Responding to multiple messages here: On 2/6/11 10:16 PM, John Levine wrote: >>> What's really needed is seperate the routing slot market from the >>> address allocation market. >> Bingo! In fact, having an efficient market for obtaining routing of a >> given prefix, combined with IPv6 vast identifier space, could >> actually satisfy the primary goals that we hold for a long-term >> scalable address architecture, and enable doing it in a highly >> distributed, automatable fashion Indeed as John Curran may recall, there was a presentation at either the BGPD/CIDRD or ALE working group at an IETF meeting by a gentleman from Bell Labs on the idea of a routing slot market, back about 15 years ago. I thought it was a great presentation, but a number of factors came into play, and chief amongst them was that it would require substantial "cooperation" amongst service providers to refuse to carry customer routes, and that just wasn't happening. Have times changed since then? > This is not unlike the oft made comment that if you could just charge > a fraction of a cent for every mail message, there would be no spam > problem. They're both bad ideas that just won't go away. > > Here's some thought experiments: > > 1) You get a note from the owner of jidaw.com, a large ISP in Nigeria, > telling you that they have two defaultless routers so they'd like a > share of the route fees. Due to the well known fraud problem in > Nigeria, please pay them into the company's account in the Channel > Islands. What do you do? (Helpful hint: there are plenty of > legitimate reasons for non-residents to have accounts in the Channel > Islands. I have a few.) > > 2) Google says here's our routes, we won't be paying anything. What > do you do? > > 2a) If you insist no pay, no route, what do you tell your users when > they call and complain? > > 2b) If you make a special case for Google, what do you do when Yahoo, > AOL, and Baidu do the same thing? > > I can imagine some technical backpressure, particularly against networks > that don't aggregate their routes, but money? Forget about it, unless > perhaps you want to mix them into the peering/transit negotiations. These are great questions. Approaches that due away with this scarcity seem more feasible. Eliot From mysidia at gmail.com Wed Feb 9 01:33:52 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 9 Feb 2011 01:33:52 -0600 Subject: Ipv6 addressing for Core network In-Reply-To: References: Message-ID: On Tue, Feb 8, 2011 at 10:24 PM, Vikas Sharma wrote: > Hi, > I am looking for the recommendation for core interfaces IP addressing schema > for Ipv6. Some different views are (PE- P - PE, point to point link) as > below - > 1- ?Use Public Ipv6 with /122 and do not advertise to Internet > 2- ?Use Public Ipv6 with /127 and do not advertise to Internet /122 and /127 do not lie on a nibble boundary. Not recommended, try /124 or /120 instead. Especially if you intend to have multiple such PtP networks share the same /64. > 3- ?Use Unique local ipv6 address I recommend against non-public addressing for V6 point to point links, if these links are used directly for internet connectivity; there can be issues that creates for network diagnostics such as ping/traceroute. Especially in regards to sourcing pings from the PtP interface. > 4- Use Public Ipv6 with /64 I would give that a provisional thumbs up: subnetting at the /64 boundary is what is indicated by RFC in regards to IPv6 addressing architecture; it doesn't matter that PtP links only have 2 hosts, the IPv6 addressing architecture calls for a 64-bit interface ID and 64-bit network ID, meaning /64. The provisional condition, is that there are other considerations besides consistent addressing. For now, there are reasons to configure a longer /120 prefix for those interfaces, even while addressing on /64 boundaries. Suggesting: set aside a dedicated /64, within public announced allocation, and pick some /120 inside that /64 for the actual link. /64 subnet, with /120 mask on the link. Recommendation is a combination of (1) and (4). For now, long configured netmasks for such links ensure SLAAC does not operate on them, and may head off some possible DoS risk in regards to sweep attacks / NDP table overflow, which can be of substantial concern for at least some devices. -- -JH From iljitsch at muada.com Wed Feb 9 03:15:12 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 9 Feb 2011 10:15:12 +0100 Subject: IPv6 addressing for core network In-Reply-To: References: Message-ID: <49F6C292-C26D-41E6-953D-F7316D795237@muada.com> On 9 feb 2011, at 5:24, Vikas Sharma wrote: > I am looking for the recommendation for core interfaces IP addressing schema > for Ipv6. Some different views are (PE- P - PE, point to point link) as > below - Is there a NANOG FAQ we can add this to? > 1- Use Public Ipv6 with /122 and do not advertise to Internet > 2- Use Public Ipv6 with /127 and do not advertise to Internet The all zeros address is the all routers anycast address so on most non-Cisco routers you can't use it, ruling out /127. The top 128 addresses in any subnet are also reserved anycast addresses although they don't do much in practice. So the longest prefix length you should use is /120 and only use addresses 1 - 127. I recommend /112 because that way the part of the address after the last colon is the subnet. > 3- Use Unique local ipv6 address Not recommended, because now traceroute replies and, if applicable, much worse, PMTUD responses come from bogon space so some people will filter them. So absolutely do not do this if you have any non-1500-byte MTUs in your network. > 4- Use Public Ipv6 with /64 /64 has the advantage that you can use EUI-64 addressing so you don't have to remember which exact address each router has, just let that be filled in from the MAC address. The IPv6 addressing architecture RFCs also say you must use /64 but no reason for this is given so I don't feel bound by that. But having a global scope address on your router-to-router interfaces is such IPv4 thinking. You don't need that with IPv6 unless you want to be able to ping individual interfaces. Routing protocols only use the link local addresses and when ICMP messages have to be generated a global scope address is borrowed from another interface, such as the loopback interface. From sthaug at nethelp.no Wed Feb 9 03:48:04 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 09 Feb 2011 10:48:04 +0100 (CET) Subject: IPv6 addressing for core network In-Reply-To: <49F6C292-C26D-41E6-953D-F7316D795237@muada.com> References: <49F6C292-C26D-41E6-953D-F7316D795237@muada.com> Message-ID: <20110209.104804.74661138.sthaug@nethelp.no> > Is there a NANOG FAQ we can add this to? > > > 1- Use Public Ipv6 with /122 and do not advertise to Internet > > 2- Use Public Ipv6 with /127 and do not advertise to Internet > > The all zeros address is the all routers anycast address so on most non-Cisco routers you can't use it, ruling out /127. The top 128 addresses in any subnet are also reserved anycast addresses although they don't do much in practice. So the longest prefix length you should use is /120 and only use addresses 1 - 127. A /127 mask is still the best way to handle real point-to-point links like SDH/SONET today, to avoid the ping-pong problem. Works fine with Cisco and Juniper, not tried with other vendors. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From iljitsch at muada.com Wed Feb 9 03:59:24 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 9 Feb 2011 10:59:24 +0100 Subject: IPv6 addressing for core network In-Reply-To: <20110209.104804.74661138.sthaug@nethelp.no> References: <49F6C292-C26D-41E6-953D-F7316D795237@muada.com> <20110209.104804.74661138.sthaug@nethelp.no> Message-ID: <18C2B7E6-BA15-4922-9724-C37D97306ECA@muada.com> On 9 feb 2011, at 10:48, sthaug at nethelp.no wrote: >> The all zeros address is the all routers anycast address so on most non-Cisco routers you can't use it, ruling out /127. The top 128 addresses in any subnet are also reserved anycast addresses although they don't do much in practice. So the longest prefix length you should use is /120 and only use addresses 1 - 127. > A /127 mask is still the best way to handle real point-to-point links > like SDH/SONET today, to avoid the ping-pong problem. Works fine with > Cisco and Juniper, not tried with other vendors. I know it's immature, but I can't wait for some new hire at vendor C or vendor J to reread the RFCs and implement the all routers anycast address according to spect and then see sparks fly. Like I said, global scope addresses on your router-to-router interfaces is such IPv4 thinking. From sthaug at nethelp.no Wed Feb 9 04:16:30 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 09 Feb 2011 11:16:30 +0100 (CET) Subject: IPv6 addressing for core network In-Reply-To: <18C2B7E6-BA15-4922-9724-C37D97306ECA@muada.com> References: <49F6C292-C26D-41E6-953D-F7316D795237@muada.com> <20110209.104804.74661138.sthaug@nethelp.no> <18C2B7E6-BA15-4922-9724-C37D97306ECA@muada.com> Message-ID: <20110209.111630.41722263.sthaug@nethelp.no> > > A /127 mask is still the best way to handle real point-to-point links > > like SDH/SONET today, to avoid the ping-pong problem. Works fine with > > Cisco and Juniper, not tried with other vendors. > > I know it's immature, but I can't wait for some new hire at vendor C or vendor J to reread the RFCs and implement the all routers anycast address according to spect and then see sparks fly. > > Like I said, global scope addresses on your router-to-router interfaces is such IPv4 thinking. Global scope addresses on router-to-router interfaces are necessary today for traceroute to work. Some ISPs are *requiring* working traceroute (without MPLS hiding of intermediate hops) in RFPs to transit providers. If you can get router ICMP handling changed such that the ICMP packet generated by traceroute is sent from the loopback address, we might be able to do without global scope addresses on router-to-router interfaces. But until then... Steinar Haug, Nethelp consulting, sthaug at nethelp.no From mohacsi at niif.hu Wed Feb 9 04:50:32 2011 From: mohacsi at niif.hu (Mohacsi Janos) Date: Wed, 9 Feb 2011 11:50:32 +0100 (CET) Subject: IPv6 addressing for core network In-Reply-To: <20110209.111630.41722263.sthaug@nethelp.no> References: <49F6C292-C26D-41E6-953D-F7316D795237@muada.com> <20110209.104804.74661138.sthaug@nethelp.no> <18C2B7E6-BA15-4922-9724-C37D97306ECA@muada.com> <20110209.111630.41722263.sthaug@nethelp.no> Message-ID: On Wed, 9 Feb 2011, sthaug at nethelp.no wrote: >>> A /127 mask is still the best way to handle real point-to-point links >>> like SDH/SONET today, to avoid the ping-pong problem. Works fine with >>> Cisco and Juniper, not tried with other vendors. >> >> I know it's immature, but I can't wait for some new hire at vendor C or vendor J to reread the RFCs and implement the all routers anycast address according to spect and then see sparks fly. >> >> Like I said, global scope addresses on your router-to-router interfaces is such IPv4 thinking. > > Global scope addresses on router-to-router interfaces are necessary > today for traceroute to work. Some ISPs are *requiring* working > traceroute (without MPLS hiding of intermediate hops) in RFPs to > transit providers. > > If you can get router ICMP handling changed such that the ICMP packet > generated by traceroute is sent from the loopback address, we might > be able to do without global scope addresses on router-to-router > interfaces. But until then... You can do it on C and J vendor. Without link-local ICMPv6 will use loopback0. Example on C: ipv6 unnumbered loopback0 Best Regards, Janos Mohacsi From nanogwp at gmail.com Wed Feb 9 05:00:27 2011 From: nanogwp at gmail.com (Robert Lusby) Date: Wed, 9 Feb 2011 11:00:27 +0000 Subject: IPv6 - a noobs prespective Message-ID: As part of my role, I'm responsible, for a small (20 - 25 machine) network in the UK. When it comes to IPv6 I'm a complete noob. So ok - this is how I stand for IPv6: I "get" IPv4, I get NAT, I get why it's needed, and I get why it's evil. I know my IPv4 network inside and out, how DHCP runs and assigns addresses, how that ties in with our VPN, how everything gets channeled via the NAT to our ISP etc ... I also get why we need IPv6, that it means removing the NAT (which, surprise surprise also runs our Firewall), and I that I might need new kit for it. I am however *terrified* of making that move. There is so many new phrases, words, things to think about etc I want to, I'm keen to, and I know we have to, move to IPv6 - but at the moment it just seems so complicated - not least without affecting any IPv4 stuff. Just my own two pence from a noobie point of view. * On a side note - what's the best guide for upgrading a simple Windows network to run on IPv6? I'll take a read. From sthaug at nethelp.no Wed Feb 9 05:17:25 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 09 Feb 2011 12:17:25 +0100 (CET) Subject: IPv6 addressing for core network In-Reply-To: References: <18C2B7E6-BA15-4922-9724-C37D97306ECA@muada.com> <20110209.111630.41722263.sthaug@nethelp.no> Message-ID: <20110209.121725.71182614.sthaug@nethelp.no> > > Global scope addresses on router-to-router interfaces are necessary > > today for traceroute to work. Some ISPs are *requiring* working > > traceroute (without MPLS hiding of intermediate hops) in RFPs to > > transit providers. > > > > If you can get router ICMP handling changed such that the ICMP packet > > generated by traceroute is sent from the loopback address, we might > > be able to do without global scope addresses on router-to-router > > interfaces. But until then... > > You can do it on C and J vendor. Without link-local ICMPv6 will use > loopback0. Example on C: > ipv6 unnumbered loopback0 I'm afraid I don't consider this an alternative. I *like* global link addresses for our core routers - and so does our NOC. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From iljitsch at muada.com Wed Feb 9 05:47:31 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 9 Feb 2011 12:47:31 +0100 Subject: IPv6 addressing for core network In-Reply-To: <20110209.111630.41722263.sthaug@nethelp.no> References: <49F6C292-C26D-41E6-953D-F7316D795237@muada.com> <20110209.104804.74661138.sthaug@nethelp.no> <18C2B7E6-BA15-4922-9724-C37D97306ECA@muada.com> <20110209.111630.41722263.sthaug@nethelp.no> Message-ID: <5D84F828-E09A-4F26-87DB-4A1AE32A614E@muada.com> On 9 feb 2011, at 11:16, sthaug at nethelp.no wrote: > If you can get router ICMP handling changed such that the ICMP packet > generated by traceroute is sent from the loopback address, we might > be able to do without global scope addresses on router-to-router > interfaces. But until then... I'm pretty sure this is standard behavior for routers, and especially Cisco routers. However, I can't find any documentation for this real quick, either in an RFC or Cisco documentation. From owen at delong.com Wed Feb 9 06:08:22 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Feb 2011 04:08:22 -0800 Subject: IPv6 - a noobs prespective In-Reply-To: References: Message-ID: On Feb 9, 2011, at 3:00 AM, Robert Lusby wrote: > As part of my role, I'm responsible, for a small (20 - 25 machine) network > in the UK. > > When it comes to IPv6 I'm a complete noob. So ok - this is how I stand for > IPv6: > > I "get" IPv4, I get NAT, I get why it's needed, and I get why it's evil. > > I know my IPv4 network inside and out, how DHCP runs and assigns addresses, > how that ties in with our VPN, how everything gets channeled via the NAT to > our ISP etc ... > > I also get why we need IPv6, that it means removing the NAT (which, surprise > surprise also runs our Firewall), and I that I might need new kit for it. > Well, I'll question that a little bit. I think your Firewall, in addition to translating addresses (NAT) also filters packets. Would that, perhaps, be a more accurate description? Most firewalls (other than trivial home gateways) can do all the stateful inspection (the actual packet filtering and state-table stuff) without having to do NAT. If it supports IPv6 at all, it should be ready to do that without needing new kit. If it doesn't support IPv6 at all, then, yes, you needed new kit anyway, no? Personally, I'm pretty happy with the SRX-series kit from Juniper. It's pretty inexpensive and has most of the IPv6 features you are likely to need, including stateful inspection without NAT for IPv6 and with NAT for IPv4. > I am however *terrified* of making that move. There is so many new phrases, > words, things to think about etc > > I want to, I'm keen to, and I know we have to, move to IPv6 - but at the > moment it just seems so complicated - not least without affecting any IPv4 > stuff. > Build a test lab and start experimenting. You'll find that for the most part, it's just 96 more bits and very little magic. Owen From sam at spacething.org Wed Feb 9 06:35:41 2011 From: sam at spacething.org (Sam Stickland) Date: Wed, 9 Feb 2011 12:35:41 +0000 Subject: Post-Exhaustion-phase "punishment" for early adopters In-Reply-To: <0CFF54003CD92945994CF0C0F90D81B670647E@EXCH1-FWA1.zenetra.local> References: <91338.18733.qm@web24704.mail.ird.yahoo.com> <1E8620FE-BC2C-4750-885B-63706D1853E1@spacething.org> <4D517AB2.7000105@matthew.at> <20110208220442.90F889D4BED@drugs.dv.isc.org> <46347.1297206493@localhost> <0CFF54003CD92945994CF0C0F90D81B670647E@EXCH1-FWA1.zenetra.local> Message-ID: On 9 Feb 2011, at 02:43, "R. Benjamin Kessler" wrote: >>> From: George Herbert [mailto:george.herbert at gmail.com] > >>> "Let's just grab 2/8, it's not routed on the Internet..." > > +1 > > I was consulting for a financial services firm in the late '90s that was acquired by a large east-coast bank; the bank's brilliant scheme was to renumber all new acquisitions *out* of RFC1918 space and into (at the time) bogon space. > > If I recall, some of the arguments were "they were too big to fit into RFC1918 space" and by having all of their divisions in non-RFC1918 space it would make it easier for them to acquire new companies who used RFC1918 space internally. > You don't have to trawl back to the late 90's to find this, I know of at least 3 or 4 large enterprises using large chunks of public address (multiple /8's) that aren't their's /today/. This "works" because 1) the Internet is only accessed through proxies, 2) devices that require direct Internet access are addressed out of registered address space (or NATed to registered address space), and 3) third party connections to others enterprises are usually src/dst NATTed to the enterprise's own ranges (with the added benefit that this NAT at 3rd party boundaries helps ensure symmetric traffic flow through firewalls). And I've only worked at 3 or 4 large enterprises so it's probably safe to assume there's more! With my SP background I was shocked and I'm not trying to defend this practice, but in the enterprise land it seems accepted. Sam From sam at spacething.org Wed Feb 9 07:35:03 2011 From: sam at spacething.org (Sam Stickland) Date: Wed, 9 Feb 2011 13:35:03 +0000 Subject: IPv6 addressing for core network In-Reply-To: <20110209.104804.74661138.sthaug@nethelp.no> References: <49F6C292-C26D-41E6-953D-F7316D795237@muada.com> <20110209.104804.74661138.sthaug@nethelp.no> Message-ID: <93AA0E79-76BF-439C-BD37-05AEAA401BC9@spacething.org> On 9 Feb 2011, at 09:48, sthaug at nethelp.no wrote: >> Is there a NANOG FAQ we can add this to? >> >>> 1- Use Public Ipv6 with /122 and do not advertise to Internet >>> 2- Use Public Ipv6 with /127 and do not advertise to Internet >> >> The all zeros address is the all routers anycast address so on most non-Cisco routers you can't use it, ruling out /127. The top 128 addresses in any subnet are also reserved anycast addresses although they don't do much in practice. So the longest prefix length you should use is /120 and only use addresses 1 - 127. > > A /127 mask is still the best way to handle real point-to-point links > like SDH/SONET today, to avoid the ping-pong problem. Works fine with > Cisco and Juniper, not tried with other vendors. > Can you elaborate on this? What's the ping-pong problem? Sam (who's experience is pretty much mostly ethernet) From sthaug at nethelp.no Wed Feb 9 07:45:52 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 09 Feb 2011 14:45:52 +0100 (CET) Subject: IPv6 addressing for core network In-Reply-To: <93AA0E79-76BF-439C-BD37-05AEAA401BC9@spacething.org> References: <49F6C292-C26D-41E6-953D-F7316D795237@muada.com> <20110209.104804.74661138.sthaug@nethelp.no> <93AA0E79-76BF-439C-BD37-05AEAA401BC9@spacething.org> Message-ID: <20110209.144552.74723697.sthaug@nethelp.no> > > A /127 mask is still the best way to handle real point-to-point links > > like SDH/SONET today, to avoid the ping-pong problem. Works fine with > > Cisco and Juniper, not tried with other vendors. > > > > Can you elaborate on this? What's the ping-pong problem? This has been well covered in the past. See http://tools.ietf.org/html/draft-ietf-ipngwg-p2p-pingpong-00 http://tools.ietf.org/html/draft-kohno-ipv6-prefixlen-p2p-01 http://archive.apnic.net/meetings/26/program/apops/matsuzaki-ipv6-p2p.pdf It's a problem for real point-to-point links like SDH/SONET which don't use Neighbor Discovery. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From joelja at bogus.com Wed Feb 9 11:21:09 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 09 Feb 2011 09:21:09 -0800 Subject: Post-Exhaustion-phase "punishment" for early adopters In-Reply-To: References: <91338.18733.qm@web24704.mail.ird.yahoo.com> <1E8620FE-BC2C-4750-885B-63706D1853E1@spacething.org> <4D517AB2.7000105@matthew.at> <20110208220442.90F889D4BED@drugs.dv.isc.org> <46347.1297206493@localhost> <0CFF54003CD92945994CF0C0F90D81B670647E@EXCH1-FWA1.zenetra.local> Message-ID: <4D52CD05.9020106@bogus.com> On 2/9/11 4:35 AM, Sam Stickland wrote: > > > On 9 Feb 2011, at 02:43, "R. Benjamin Kessler" > wrote: > >>>> From: George Herbert [mailto:george.herbert at gmail.com] >> >>>> "Let's just grab 2/8, it's not routed on the Internet..." >> >> +1 >> >> I was consulting for a financial services firm in the late '90s >> that was acquired by a large east-coast bank; the bank's brilliant >> scheme was to renumber all new acquisitions *out* of RFC1918 space >> and into (at the time) bogon space. >> >> If I recall, some of the arguments were "they were too big to fit >> into RFC1918 space" and by having all of their divisions in >> non-RFC1918 space it would make it easier for them to acquire new >> companies who used RFC1918 space internally. >> > > You don't have to trawl back to the late 90's to find this, I know of > at least 3 or 4 large enterprises using large chunks of public > address (multiple /8's) that aren't their's /today/. > > This "works" because 1) the Internet is only accessed through > proxies, 2) devices that require direct Internet access are addressed > out of registered address space (or NATed to registered address > space), and 3) third party connections to others enterprises are > usually src/dst NATTed to the enterprise's own ranges (with the added > benefit that this NAT at 3rd party boundaries helps ensure symmetric > traffic flow through firewalls). sotime it works... if you are natted (from your public scoped but overlapping ipv4 address) but don't go through a proxy, or you go through a transparent proxy you may still be dead because the internal route covers you destination. Those aren't just enterprises either, some fairly common offenders are ISPs or wireless carriers and they did use just one or two additional /8s... joel > And I've only worked at 3 or 4 large enterprises so it's probably > safe to assume there's more! With my SP background I was shocked and > I'm not trying to defend this practice, but in the enterprise land it > seems accepted. > > Sam > From david.freedman at uk.clara.net Wed Feb 9 11:30:55 2011 From: david.freedman at uk.clara.net (David Freedman) Date: Wed, 09 Feb 2011 17:30:55 +0000 Subject: IPv6 addressing for core network In-Reply-To: <20110209.144552.74723697.sthaug@nethelp.no> References: <49F6C292-C26D-41E6-953D-F7316D795237@muada.com> <20110209.104804.74661138.sthaug@nethelp.no> <93AA0E79-76BF-439C-BD37-05AEAA401BC9@spacething.org> <20110209.144552.74723697.sthaug@nethelp.no> Message-ID: I think the solution to all of these problems is really to use public addressing but filter access to it at your edge (yes, even ICMP TOOBIG can be filtered safely if you have designed things in a sane way) Dave. -- David Freedman Group Network Engineering Claranet Group From iljitsch at muada.com Wed Feb 9 11:44:40 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 9 Feb 2011 18:44:40 +0100 Subject: Too bigs are sacred, was: Re: IPv6 addressing for core network In-Reply-To: References: <49F6C292-C26D-41E6-953D-F7316D795237@muada.com> <20110209.104804.74661138.sthaug@nethelp.no> <93AA0E79-76BF-439C-BD37-05AEAA401BC9@spacething.org> <20110209.144552.74723697.sthaug@nethelp.no> Message-ID: <29708DA0-57F6-4AFD-B11A-ED5AD399FFF6@muada.com> On 9 feb 2011, at 18:30, David Freedman wrote: > (yes, even ICMP TOOBIG > can be filtered safely if you have designed things in a sane way) NO. Even if you run with 1280-byte MTUs everywhere so you'd think path MTU discovery wouldn't be needed, this can still cause problems with IPv6-to-IPv4 translators. From david.freedman at uk.clara.net Wed Feb 9 11:50:35 2011 From: david.freedman at uk.clara.net (David Freedman) Date: Wed, 09 Feb 2011 17:50:35 +0000 Subject: Too bigs are sacred, was: Re: IPv6 addressing for core network In-Reply-To: <29708DA0-57F6-4AFD-B11A-ED5AD399FFF6@muada.com> References: <49F6C292-C26D-41E6-953D-F7316D795237@muada.com> <20110209.104804.74661138.sthaug@nethelp.no> <93AA0E79-76BF-439C-BD37-05AEAA401BC9@spacething.org> <20110209.144552.74723697.sthaug@nethelp.no> <29708DA0-57F6-4AFD-B11A-ED5AD399FFF6@muada.com> Message-ID: Iljitsch van Beijnum wrote: > On 9 feb 2011, at 18:30, David Freedman wrote: > >> (yes, even ICMP TOOBIG >> can be filtered safely if you have designed things in a sane way) > > NO. > > Even if you run with 1280-byte MTUs everywhere so you'd think path MTU discovery wouldn't be needed, this can still cause problems with IPv6-to-IPv4 translators. > Calm down, I think you misunderstand, I'm suggesting that you don't design your infrastructure in such a way that your backbone/infrastructure links ever have to receive TOOBIG messages from outside your AS and work with these, your backbone links are of course free to send TOOBIG out! Dave. -- David Freedman Group Network Engineering Claranet Group From jjeffries at labs.net Wed Feb 9 11:56:54 2011 From: jjeffries at labs.net (jason jeffries) Date: Wed, 9 Feb 2011 12:56:54 -0500 Subject: verizon (as701/mci/worldcom/alternet/uunet) ipv6 contact needed Message-ID: <201102091256.AA1097859118@labs.net> I hate to do this to ya'll again... but I need to talk to someone in as701/Verizon-land that can get us IPv6 connectivity on our existing circuit. The unfailingly awesome technical persons behind the help email addresses at 701 told us to take it to our account rep, and therein lies the problem. Verizon _used to be_ the ILEC here, and we ordered this circuit in some CLECy way that apparently means we don't have any of the usual credentials or account managers and blahblahlblah other things that I don't care about. What it comes down to is: Multiple attempts by our suited idiots to contact your suited idiots have failed. If a technical-type person can point me in the right direction, it'd be much appreciated. thanks! jason jeffries - jjeffries labs.net labyrinth solutions - as26097 From bill at herrin.us Wed Feb 9 12:03:01 2011 From: bill at herrin.us (William Herrin) Date: Wed, 9 Feb 2011 13:03:01 -0500 Subject: IPv6 - a noobs prespective In-Reply-To: References: Message-ID: On Wed, Feb 9, 2011 at 6:00 AM, Robert Lusby wrote: > I also get why we need IPv6, that it means removing the NAT (which, surprise > surprise also runs our Firewall), and I that I might need new kit for it. > > I am however *terrified* of making that move. There is so many new phrases, > words, things to think about etc The thing that terrifies me about deploying IPv6 is that apps compatible with both are programmed to attempt IPv6 before IPv4. This means my first not-quite-correct IPv6 deployments are going to break my apps that are used to not having and therefore not trying IPv6. But that's not the worst part... as the folks my customers interact with over the next couple of years make their first not-quite-correct IPv6 deployments, my access to them is going to break again. And again. And again. And I won't have the foggiest idea who's next until I get the call that such-and-such isn't working right. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From heather.schiller at verizonbusiness.com Wed Feb 9 12:17:36 2011 From: heather.schiller at verizonbusiness.com (Schiller, Heather A) Date: Wed, 09 Feb 2011 18:17:36 +0000 Subject: verizon (as701/mci/worldcom/alternet/uunet) ipv6 contact needed In-Reply-To: <201102091256.AA1097859118@labs.net> References: <201102091256.AA1097859118@labs.net> Message-ID: Hey - send me what info you do have about your account and I will try to point you in the right direction. (Same goes for anyone else having similar v6 probs) --Heather -----Original Message----- From: jason jeffries [mailto:jjeffries at labs.net] Sent: Wednesday, February 09, 2011 12:57 PM To: nanog at nanog.org Subject: verizon (as701/mci/worldcom/alternet/uunet) ipv6 contact needed I hate to do this to ya'll again... but I need to talk to someone in as701/Verizon-land that can get us IPv6 connectivity on our existing circuit. The unfailingly awesome technical persons behind the help email addresses at 701 told us to take it to our account rep, and therein lies the problem. Verizon _used to be_ the ILEC here, and we ordered this circuit in some CLECy way that apparently means we don't have any of the usual credentials or account managers and blahblahlblah other things that I don't care about. What it comes down to is: Multiple attempts by our suited idiots to contact your suited idiots have failed. If a technical-type person can point me in the right direction, it'd be much appreciated. thanks! jason jeffries - jjeffries labs.net labyrinth solutions - as26097 From franck at genius.com Wed Feb 9 12:19:18 2011 From: franck at genius.com (Franck Martin) Date: Thu, 10 Feb 2011 07:19:18 +1300 (FJST) Subject: IPv6 - a noobs prespective In-Reply-To: Message-ID: <11606677.346.1297275556677.JavaMail.franck@franck-martins-macbook-pro.local> This is dual stack, my recommendation is disable IPv6 on your servers (so your clients will still talk to them on IPv4 only), and let your client goes IPv6 first. Once you understand what is happening, get on IPv6 on your servers. Alternatively, use someone else network to understand IPv6. Attend, NANOG, ICANN, IETF, they always have IPv6 enabled, you can better understand how your machine reacts, what tools you have, how to do ping, debug, packet capture,... For the firewall, shorewall does IPv4 and IPv6, with a relatively simple interface and is free... ----- Original Message ----- From: "William Herrin" To: "Robert Lusby" Cc: nanog at nanog.org Sent: Thursday, 10 February, 2011 7:03:01 AM Subject: Re: IPv6 - a noobs prespective On Wed, Feb 9, 2011 at 6:00 AM, Robert Lusby wrote: > I also get why we need IPv6, that it means removing the NAT (which, surprise > surprise also runs our Firewall), and I that I might need new kit for it. > > I am however *terrified* of making that move. There is so many new phrases, > words, things to think about etc The thing that terrifies me about deploying IPv6 is that apps compatible with both are programmed to attempt IPv6 before IPv4. This means my first not-quite-correct IPv6 deployments are going to break my apps that are used to not having and therefore not trying IPv6. But that's not the worst part... as the folks my customers interact with over the next couple of years make their first not-quite-correct IPv6 deployments, my access to them is going to break again. And again. And again. And I won't have the foggiest idea who's next until I get the call that such-and-such isn't working right. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jbates at brightok.net Wed Feb 9 12:22:38 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 09 Feb 2011 12:22:38 -0600 Subject: IPv6 - a noobs prespective In-Reply-To: References: Message-ID: <4D52DB6E.9080009@brightok.net> On 2/9/2011 12:03 PM, William Herrin wrote: > The thing that terrifies me about deploying IPv6 is that apps > compatible with both are programmed to attempt IPv6 before IPv4. This > means my first not-quite-correct IPv6 deployments are going to break > my apps that are used to not having and therefore not trying IPv6. But > that's not the worst part... as the folks my customers interact with > over the next couple of years make their first not-quite-correct IPv6 > deployments, my access to them is going to break again. And again. And > again. And I won't have the foggiest idea who's next until I get the > call that such-and-such isn't working right. What scares me most is that every time I upgrade a router to support needed hardware or some badly needed IPv6 feature, something else breaks. Sometimes it's just the router crashes on a specific IPv6 command entered at CLI (C) or as nasty as NSR constantly crashing the slave (J); the fixes generally requiring me to upgrade again to the latest cutting edge releases which everyone hates (where I'm sure I'll find MORE bugs). The worst is when you're the first to find the bug(which I'm not even sure how it's possible given how simplistic my configs are, isis multitopology, iBGP, NSR, a few acls and route-maps/policies), it takes 3-6 months or so to track it down, and then it's put only in the next upcoming release (not out yet) and backported to the last release. Jack (hates all routers equally, doesn't matter who makes it) From alh-ietf at tndh.net Wed Feb 9 12:30:05 2011 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 9 Feb 2011 10:30:05 -0800 Subject: IPv6 - a noobs prespective In-Reply-To: <11606677.346.1297275556677.JavaMail.franck@franck-martins-macbook-pro.local> References: <11606677.346.1297275556677.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <24a701cbc887$618d9540$24a8bfc0$@net> Franck Martin wrote: > This is dual stack, my recommendation is disable IPv6 on your servers > (so your clients will still talk to them on IPv4 only), and let your > client goes IPv6 first. Once you understand what is happening, get on > IPv6 on your servers. You don't have to disable IPv6 on the servers, just don't put a AAAA in dns. The simplest way to move forward is to get the entire path in place without the key to knowing is there, then for a few test subjects either provide a different dns response, or distribute a host file. Making the mass change of enabling the servers at the point you expect service to work is just asking for support calls... > > Alternatively, use someone else network to understand IPv6. Attend, > NANOG, ICANN, IETF, they always have IPv6 enabled, you can better > understand how your machine reacts, what tools you have, how to do > ping, debug, packet capture,... > > For the firewall, shorewall does IPv4 and IPv6, with a relatively > simple interface and is free... > > ----- Original Message ----- > From: "William Herrin" > To: "Robert Lusby" > Cc: nanog at nanog.org > Sent: Thursday, 10 February, 2011 7:03:01 AM > Subject: Re: IPv6 - a noobs prespective > > On Wed, Feb 9, 2011 at 6:00 AM, Robert Lusby wrote: > > I also get why we need IPv6, that it means removing the NAT (which, > surprise > > surprise also runs our Firewall), and I that I might need new kit for > it. > > > > I am however *terrified* of making that move. There is so many new > phrases, > > words, things to think about etc > > The thing that terrifies me about deploying IPv6 is that apps > compatible with both are programmed to attempt IPv6 before IPv4. This > means my first not-quite-correct IPv6 deployments are going to break > my apps that are used to not having and therefore not trying IPv6. But > that's not the worst part... as the folks my customers interact with > over the next couple of years make their first not-quite-correct IPv6 > deployments, my access to them is going to break again. And again. And > again. And I won't have the foggiest idea who's next until I get the > call that such-and-such isn't working right. > > Regards, > Bill Herrin > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 From mike.lyon at gmail.com Wed Feb 9 12:30:55 2011 From: mike.lyon at gmail.com (Mike Lyon) Date: Wed, 9 Feb 2011 10:30:55 -0800 Subject: IPv6 - a noobs prespective In-Reply-To: <4D52DB6E.9080009@brightok.net> References: <4D52DB6E.9080009@brightok.net> Message-ID: With the recent allocation of the last existing IPv4 /8s (which now kind of puts pressure on going v6), it would be wonderful if at the next couple of NANOGs if there could be an IPv6 for dummies session or two :) -Mike On Wed, Feb 9, 2011 at 10:22 AM, Jack Bates wrote: > On 2/9/2011 12:03 PM, William Herrin wrote: > >> The thing that terrifies me about deploying IPv6 is that apps >> compatible with both are programmed to attempt IPv6 before IPv4. This >> means my first not-quite-correct IPv6 deployments are going to break >> my apps that are used to not having and therefore not trying IPv6. But >> that's not the worst part... as the folks my customers interact with >> over the next couple of years make their first not-quite-correct IPv6 >> deployments, my access to them is going to break again. And again. And >> again. And I won't have the foggiest idea who's next until I get the >> call that such-and-such isn't working right. >> > > What scares me most is that every time I upgrade a router to support needed > hardware or some badly needed IPv6 feature, something else breaks. Sometimes > it's just the router crashes on a specific IPv6 command entered at CLI (C) > or as nasty as NSR constantly crashing the slave (J); the fixes generally > requiring me to upgrade again to the latest cutting edge releases which > everyone hates (where I'm sure I'll find MORE bugs). > > The worst is when you're the first to find the bug(which I'm not even sure > how it's possible given how simplistic my configs are, isis multitopology, > iBGP, NSR, a few acls and route-maps/policies), it takes 3-6 months or so to > track it down, and then it's put only in the next upcoming release (not out > yet) and backported to the last release. > > > Jack (hates all routers equally, doesn't matter who makes it) > > From bill at herrin.us Wed Feb 9 12:37:31 2011 From: bill at herrin.us (William Herrin) Date: Wed, 9 Feb 2011 13:37:31 -0500 Subject: IPv6 - a noobs prespective In-Reply-To: <11606677.346.1297275556677.JavaMail.franck@franck-martins-macbook-pro.local> References: <11606677.346.1297275556677.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On Wed, Feb 9, 2011 at 1:19 PM, Franck Martin wrote: > From: "William Herrin" >> The thing that terrifies me about deploying IPv6 is that apps >> compatible with both are programmed to attempt IPv6 before IPv4. >> [...] is going to break again. And again. And again. > > This is dual stack, my recommendation is disable > IPv6 on your servers (so your clients will still talk to > them on IPv4 only), and let your client goes IPv6 first. > Once you understand what is happening, get on IPv6 > on your servers. That advice reminds me of a limerick I once heard: A host is a host >From coast to coast And nobody talks to a host that's close Unless the host that isn't close Is busy, hung or dead. Thanks, but it doesn't really speak to the problem I fear. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From franck at genius.com Wed Feb 9 12:37:20 2011 From: franck at genius.com (Franck Martin) Date: Thu, 10 Feb 2011 07:37:20 +1300 (FJST) Subject: IPv6 - a noobs prespective In-Reply-To: Message-ID: <7000830.352.1297276636748.JavaMail.franck@franck-martins-macbook-pro.local> You missed the IPv6 hour at Nanog42: http://www.civil-tongue.net/grandx/wiki/nanog42 https://wiki.tools.isoc.org/IETF71_IPv4_Outage May be another one is needed? ----- Original Message ----- From: "Mike Lyon" To: "Jack Bates" Cc: nanog at nanog.org Sent: Thursday, 10 February, 2011 7:30:55 AM Subject: Re: IPv6 - a noobs prespective With the recent allocation of the last existing IPv4 /8s (which now kind of puts pressure on going v6), it would be wonderful if at the next couple of NANOGs if there could be an IPv6 for dummies session or two :) -Mike On Wed, Feb 9, 2011 at 10:22 AM, Jack Bates wrote: From wmaton at ryouko.imsb.nrc.ca Wed Feb 9 12:39:45 2011 From: wmaton at ryouko.imsb.nrc.ca (William F. Maton Sotomayor) Date: Wed, 9 Feb 2011 13:39:45 -0500 (EST) Subject: IPv6 - a noobs prespective In-Reply-To: References: <4D52DB6E.9080009@brightok.net> Message-ID: On Wed, 9 Feb 2011, Mike Lyon wrote: > With the recent allocation of the last existing IPv4 /8s (which now kind of > puts pressure on going v6), it would be wonderful if at the next couple of > NANOGs if there could be an IPv6 for dummies session or two :) I think these could be pretty valuable in the light of the last of thae allocations, and I would expect that even the RIRs through their outreach have done the same. NANOG archives, especially of previous sessions (look for the Sunday tutorials) will help. > > -Mike > > > On Wed, Feb 9, 2011 at 10:22 AM, Jack Bates wrote: > >> On 2/9/2011 12:03 PM, William Herrin wrote: >> >>> The thing that terrifies me about deploying IPv6 is that apps >>> compatible with both are programmed to attempt IPv6 before IPv4. This >>> means my first not-quite-correct IPv6 deployments are going to break >>> my apps that are used to not having and therefore not trying IPv6. But >>> that's not the worst part... as the folks my customers interact with >>> over the next couple of years make their first not-quite-correct IPv6 >>> deployments, my access to them is going to break again. And again. And >>> again. And I won't have the foggiest idea who's next until I get the >>> call that such-and-such isn't working right. >>> >> >> What scares me most is that every time I upgrade a router to support needed >> hardware or some badly needed IPv6 feature, something else breaks. Sometimes >> it's just the router crashes on a specific IPv6 command entered at CLI (C) >> or as nasty as NSR constantly crashing the slave (J); the fixes generally >> requiring me to upgrade again to the latest cutting edge releases which >> everyone hates (where I'm sure I'll find MORE bugs). >> >> The worst is when you're the first to find the bug(which I'm not even sure >> how it's possible given how simplistic my configs are, isis multitopology, >> iBGP, NSR, a few acls and route-maps/policies), it takes 3-6 months or so to >> track it down, and then it's put only in the next upcoming release (not out >> yet) and backported to the last release. >> >> >> Jack (hates all routers equally, doesn't matter who makes it) >> >> > wfms From jbates at brightok.net Wed Feb 9 12:40:35 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 09 Feb 2011 12:40:35 -0600 Subject: IPv6 - a noobs prespective In-Reply-To: <24a701cbc887$618d9540$24a8bfc0$@net> References: <11606677.346.1297275556677.JavaMail.franck@franck-martins-macbook-pro.local> <24a701cbc887$618d9540$24a8bfc0$@net> Message-ID: <4D52DFA3.5030805@brightok.net> On 2/9/2011 12:30 PM, Tony Hain wrote: > You don't have to disable IPv6 on the servers, just don't put a AAAA > in dns. The simplest way to move forward is to get the entire path in > place without the key to knowing is there, then for a few test > subjects either provide a different dns response, or distribute a > host file. Making the mass change of enabling the servers at the > point you expect service to work is just asking for support calls... From an ISP perspective, since connectivity is not always a client/server model, the best option is to roll it through the core, have the servers you control ready and tested, and trial small groups of customers (who preferably ask for it and thus will be aware when things break). When you have your own kinks worked out and the core pathing to most networks looks good, you can start looking at switch flipping region by region. And don't forget to train your helpdesks. The marketing/sales people are probably hopeless (but give them a nice, "Yes we have IPv6, but if you use this service, you understand that some things might break and you'll have to work with us and third parties to try and fix such problems"). Jack From iljitsch at muada.com Wed Feb 9 12:41:06 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 9 Feb 2011 19:41:06 +0100 Subject: IPv6 - a noobs prespective In-Reply-To: <24a701cbc887$618d9540$24a8bfc0$@net> References: <11606677.346.1297275556677.JavaMail.franck@franck-martins-macbook-pro.local> <24a701cbc887$618d9540$24a8bfc0$@net> Message-ID: <272600C1-1405-4276-A8B2-B2C8B3277770@muada.com> On 9 feb 2011, at 19:30, Tony Hain wrote: > Making the mass change of enabling the servers at the point you expect service to work is just asking for support calls... Do that on june 8 like everyone else. :-) http://isoc.org/wp/worldipv6day/ From Josh.Stephens at solarwinds.com Wed Feb 9 12:46:11 2011 From: Josh.Stephens at solarwinds.com (Stephens, Josh) Date: Wed, 9 Feb 2011 18:46:11 +0000 Subject: Looking for an IPv6 naysayer... Message-ID: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> Not something I'd typically use this list for but I have an opportunity to host a debate of sorts on IPv6 where I'm taking a very pro IPv6 stance and I need someone who wants to argue the other side - effectively that most people don't need to worry about it for a long time still or until someone makes them. Any takers feel free to ping me directly... Thanks, Josh From bmanning at vacation.karoshi.com Wed Feb 9 13:01:22 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 9 Feb 2011 19:01:22 +0000 Subject: Looking for an IPv6 naysayer... In-Reply-To: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> Message-ID: <20110209190122.GA10392@vacation.karoshi.com.> i'm an IPv6 pragmatist. I've used IPv6 from its very beginings. i am not a zelot, like so many are. IPv6 has its uses - but most of the actual value in IPv6 has been stripped. for most practical, current use, IPv4 will meet your needs now and for the forseeable future. NAT is your lifeline here. IF (a big one) there are actual changes in regulatory models, transmission models, and reduced dependence on centralized control, IPv6 has a chance to shine and truely become the "next generation". Until then - same old, same old... 96 more bits - no majik. --bill On Wed, Feb 09, 2011 at 06:46:11PM +0000, Stephens, Josh wrote: > Not something I'd typically use this list for but I have an opportunity to host a debate of sorts on IPv6 where I'm taking a very pro IPv6 stance and I need someone who wants to argue the other side - effectively that most people don't need to worry about it for a long time still or until someone makes them. > > Any takers feel free to ping me directly... > > Thanks, > Josh From brunner at nic-naa.net Wed Feb 9 13:06:03 2011 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Wed, 09 Feb 2011 14:06:03 -0500 Subject: Looking for an IPv6 naysayer... In-Reply-To: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> Message-ID: <4D52E59B.4070904@nic-naa.net> well, i've argued new gtld registry operators in general do not benefit from a manditory v6 reachability requirement at transition to delegation, a position unpopular with v6 evangelicals and others who suppose that new gtld registry operators will exist to serve "the next billion users" rather than to offer alternate name space views to the existing {b,m}illions of v4 addressed spindles. related, i've argue that new gtld registry operators in general do not benefit from a manditory dnssec requirement, a position unpopular with dnssec evangelicals and others who suppose that new gtld registry operators will exist to serve ecommerce with sufficient generality, persistence, and volume to make them more attractive targets for rational economic exploits than existing, unsigned zones. for those not keeping track, icann's laundry list of mandatory to implements includes v6 reachibility, and dnssec, shortly after the date of contract, so significantly prior to the operator acquiring operational experience, and of course, cctlds, and existing gtlds, are under no obligation to sign their zones. i don't think of these positions as "naysaing" either v6 or dnssec, just the it-must-be-done-now claims of urgency and universality of some of the respective advocates for "sensible stuff", who because they hold the right opinion, inform icann's ssac. -e From franck at genius.com Wed Feb 9 13:17:50 2011 From: franck at genius.com (Franck Martin) Date: Thu, 10 Feb 2011 08:17:50 +1300 (FJST) Subject: IPv6 - a noobs prespective In-Reply-To: Message-ID: <217225.366.1297279069898.JavaMail.franck@franck-martins-macbook-pro.local> Don't think as IPv6 the same as IPv4. You do not need to have all your IPv4 gear to support IPv6. IPv6 is a separate network that runs on the same Ethernet wires as IPv4. You will see that a few of your machine, in fact do not support IPv6 and will not till the end of the year (think load balancers from a famous vendor), http://www.theipv6experts.net/2011/ipv6-ipv4/ Just build a separate IPv6 network, with firewall, routing gear, etc... that reaches the same machines on your network. The deployment of IPv6 at Google, was I think to put some separate IPv6 only customer facing machines. As the load on IPv6 is still small, then you can start by a small set (best is if you can have same machines do IPv4 and IPv6, but you are not obliged to think it, it is the same network). Why I don't recommend your servers to go IPv6 first, well get IPv6 to your engineers, the people that develop your applications and configure the servers, get them to be familiar with it, give them a sandbox, and then when everyone stop to run like headless chicken, plan your transition. ----- Original Message ----- From: "William Herrin" To: "Franck Martin" Cc: nanog at nanog.org, "Robert Lusby" Sent: Thursday, 10 February, 2011 7:37:31 AM Subject: Re: IPv6 - a noobs prespective On Wed, Feb 9, 2011 at 1:19 PM, Franck Martin wrote: > From: "William Herrin" >> The thing that terrifies me about deploying IPv6 is that apps >> compatible with both are programmed to attempt IPv6 before IPv4. >> [...] is going to break again. And again. And again. > > This is dual stack, my recommendation is disable > IPv6 on your servers (so your clients will still talk to > them on IPv4 only), and let your client goes IPv6 first. > Once you understand what is happening, get on IPv6 > on your servers. That advice reminds me of a limerick I once heard: A host is a host >From coast to coast And nobody talks to a host that's close Unless the host that isn't close Is busy, hung or dead. Thanks, but it doesn't really speak to the problem I fear. From lists at quux.de Wed Feb 9 13:21:27 2011 From: lists at quux.de (Jens Link) Date: Wed, 09 Feb 2011 20:21:27 +0100 Subject: IPv6 - a noobs prespective In-Reply-To: (William Herrin's message of "Wed, 9 Feb 2011 13:03:01 -0500") References: Message-ID: <87r5bhm2tk.fsf@oban.berlin.quux.de> William Herrin writes: > The thing that terrifies me about deploying IPv6 is that apps > compatible with both are programmed to attempt IPv6 before IPv4. This > means my first not-quite-correct IPv6 deployments are going to break > my apps that are used to not having and therefore not trying IPv6. On the bright side you'll notice that something is broken. The other way around you'd notice something is wrong when the first IPv6 only connection is used. > But that's not the worst part... as the folks my customers interact > with over the next couple of years make their first not-quite-correct > IPv6 deployments, my access to them is going to break again. Well www.heise.de has quite a lot of visitors, they are running dual-stacked for several month without any big problems (I'm aware of) IPv6 is coming, people have to get used to the fact and should have started learning an implementing IPv6 a couple of years ago. Not that I complain, my schedule is filling up with IPv6 related training's and consulting jobs. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From khelms at ispalliance.net Wed Feb 9 13:21:38 2011 From: khelms at ispalliance.net (Scott Helms) Date: Wed, 09 Feb 2011 14:21:38 -0500 Subject: Looking for an IPv6 naysayer... In-Reply-To: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> Message-ID: <4D52E942.5000607@ispalliance.net> IPv6 for some ISPs will be extraordinarily painful because of legacy layer 2 gear (usually DSLAMs that drop any frame with IPv6 in the EtherType field), inability to upgrade customer gear efficiently (again mainly a DSL problem where TR-069 isn't in use), and the requirement to replace PPPoE/oA termination gear (like Redback SMSs) means that a small telco (say 3000 DSL lines) could be facing a multi-million dollar expense to enable IPv6 for customers. For ISPs in this circumstance the choice will be CGNAT rather than IPv6 for a number of years because the cost is much lower and according to the vendors selling CGNAT solutions the impact to end users is (almost) unnoticeable. On 2/9/2011 1:46 PM, Stephens, Josh wrote: > Not something I'd typically use this list for but I have an opportunity to host a debate of sorts on IPv6 where I'm taking a very pro IPv6 stance and I need someone who wants to argue the other side - effectively that most people don't need to worry about it for a long time still or until someone makes them. > > Any takers feel free to ping me directly... > > Thanks, > Josh > -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From lists at quux.de Wed Feb 9 13:32:36 2011 From: lists at quux.de (Jens Link) Date: Wed, 09 Feb 2011 20:32:36 +0100 Subject: IPv6 - a noobs prespective In-Reply-To: (Owen DeLong's message of "Wed, 9 Feb 2011 04:08:22 -0800") References: Message-ID: <87d3n1knqj.fsf@oban.berlin.quux.de> Owen DeLong writes: > Build a test lab and start experimenting. You'll find that for the > most part, it's just 96 more bits and very little magic. Unfortunately most people think that IPv6 is dark magic an are deeply afraid of it. Sadly many of these people cannot be convinced of the opposite. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From nathan at atlasnetworks.us Wed Feb 9 13:38:09 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Wed, 9 Feb 2011 19:38:09 +0000 Subject: Looking for an IPv6 naysayer... In-Reply-To: <4D52E942.5000607@ispalliance.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B368DA6@ex-mb-1.corp.atlasnetworks.us> > according to the > vendors selling CGNAT solutions the impact to end users is (almost) > unnoticeable. And according to a used car salesman, this here pickup truck was only gently driven by a little old lady to the shop once a week. There's going to be a lot of snake oil in the next couple years as very small ISPs struggle to implement native IPv6 over those aging DSLAMs and GPON systems that don't and won't support it. Nathan From lists at quux.de Wed Feb 9 13:44:28 2011 From: lists at quux.de (Jens Link) Date: Wed, 09 Feb 2011 20:44:28 +0100 Subject: Looking for an IPv6 naysayer... In-Reply-To: <4D52E942.5000607@ispalliance.net> (Scott Helms's message of "Wed, 09 Feb 2011 14:21:38 -0500") References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> Message-ID: <87sjvxhu1v.fsf@oban.berlin.quux.de> Scott Helms writes: > IPv6 for some ISPs will be extraordinarily painful because of legacy > layer 2 gear I don't feel sorry for them. We know that IPv6 is coming for how long? 15years? 10year? 5years? Well if you only read the mainstream media you should have read something about this new Internet thing about two years ago. And still many people fear IPv6 or think the can still wait for another couple of years. > For ISPs in this circumstance the choice will be CGNAT rather than IPv6 > for a number of years because the cost is much lower and according to > the vendors selling CGNAT solutions the impact to end users is (almost) > unnoticeable. Cost's might be lower but service will be worse. NAT breaks a lot of applications file sharing will not work properly and running your own web server at home will not work properly. Well you always get what you pay for and people will buy any crap if it is cheap enough. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From tshaw at oitc.com Wed Feb 9 13:46:45 2011 From: tshaw at oitc.com (TR Shaw) Date: Wed, 9 Feb 2011 14:46:45 -0500 Subject: Looking for an IPv6 naysayer... In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B368DA6@ex-mb-1.corp.atlasnetworks.us> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <8C26A4FDAE599041A13EB499117D3C286B368DA6@ex-mb-1.corp.atlasnetworks.us> Message-ID: On Feb 9, 2011, at 2:38 PM, Nathan Eisenberg wrote: >> according to the >> vendors selling CGNAT solutions the impact to end users is (almost) >> unnoticeable. > > And according to a used car salesman, this here pickup truck was only gently driven by a little old lady to the shop once a week. There's going to be a lot of snake oil in the next couple years as very small ISPs struggle to implement native IPv6 over those aging DSLAMs and GPON systems that don't and won't support it. LOL just try your cell phone... Mine works fine over office wifi but not over cellular. Its not just small ISPs; its tier1's as well. Tom From lists at quux.de Wed Feb 9 13:48:35 2011 From: lists at quux.de (Jens Link) Date: Wed, 09 Feb 2011 20:48:35 +0100 Subject: Top webhosters offering v6 too? In-Reply-To: (Tim Chown's message of "Sun, 6 Feb 2011 14:52:41 +0000") References: <16975AA8-ABEB-402E-BA05-1BE51138A133@ecs.soton.ac.uk> Message-ID: <87oc6lhtv0.fsf@oban.berlin.quux.de> Tim Chown writes: > Which of the big boys are doing it? Strato in Germany. They offer IPv6 for dedicated server now. I was told that the implementation for their shared hosting (about one million domains) is almost finished and that they also offer IPv6 for virtual servers (problems with the vendor). Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From jbates at brightok.net Wed Feb 9 13:52:25 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 09 Feb 2011 13:52:25 -0600 Subject: Looking for an IPv6 naysayer... In-Reply-To: <4D52E942.5000607@ispalliance.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> Message-ID: <4D52F079.7010907@brightok.net> On 2/9/2011 1:21 PM, Scott Helms wrote: > IPv6 for some ISPs will be extraordinarily painful because of legacy > layer 2 gear (usually DSLAMs that drop any frame with IPv6 in the > EtherType field), inability to upgrade customer gear efficiently (again > mainly a DSL problem where TR-069 isn't in use), and the requirement to > replace PPPoE/oA termination gear (like Redback SMSs) means that a small > telco (say 3000 DSL lines) could be facing a multi-million dollar > expense to enable IPv6 for customers. > Oh, that's not the WORST of it. ... 3+ years ago ... IPv6 is coming. All gear needs to support it. Here are the basic models of security from the router that we can use and pros and cons for each. You do NOT want DSLAMs which enforce their own security. ... each year after ... *repeat* ... 1 year ago ... Engineer: I disapprove of that DSLAM. It has IPv4 security measures you can't disable (PPPoE and DHCP security! Wow!), doesn't support enough q-in-q support to use an isolation model, and doesn't have IPv6 support itself to make up for what it breaks. Telco: Well, we're buying millions of dollars worth, so we'll just have to make it work. Vendor says it'll be IPv6 ready later this year. ... 1 year later .... Telco: Why did we do this? They say it will be ready later this year. The problems we've had with this vendor have been awful. We should have used someone else. Engineer: No worries. I'm sure they'll get the support ready for you in time. I'll have my side sitting here waiting on them or worst case you'll spend some money to work around/replace them. *snickers* Jack From bill at herrin.us Wed Feb 9 13:53:12 2011 From: bill at herrin.us (William Herrin) Date: Wed, 9 Feb 2011 14:53:12 -0500 Subject: Looking for an IPv6 naysayer... In-Reply-To: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> Message-ID: On Wed, Feb 9, 2011 at 1:46 PM, Stephens, Josh wrote: > Not something I'd typically use this list for but I have > an opportunity to host a debate of sorts on IPv6 where > I'm taking a very pro IPv6 stance and I need someone > who wants to argue the other side - effectively that most > people don't need to worry about it for a long time still or > until someone makes them. http://bill.herrin.us/network/ipxl.html Joking, but only half joking. What kind of debate? Live debate doesn't work for me; I have the answers 15 minutes later. Personally, I'm leaning IPv6, but I can tell you the arguments opposed.... * Timing means we have to do carrier NAT anyway. Why go to both expenses? * Carrier NAT buys us enough years to build an IPv4 successor that actually solves some of the intractable IPv4 problems. Deploying IPv6 as it exists today requires massive amounts of manpower yet solves none of IPv4's problems save for the larger address space. Worse, it even doesn't appear to create the opportunity to solve those problems. * High disruption risk deploying IPv6 as implemented. May be smarter to wait until we have a protocol without the design errors that make IPv6 such a high deployment risk. * Will have learned enough in an aborted IPv6 transition to do the next one with minimal disruption. Things like host and network level configuration of protocol priorities so we have a better ability to stagger the cut-over process. * IPv6 remains half-baked with key technologies like enterprise NAT missing from the products. It isn't really ready for wide deployment; it's only being driven by IPv4 address exhaustion -- which we can defer for a couple decades through carrier NAT and other address reclamation enablers. * Next protocol should really be designed to support interoperability with the old one from the bottom up. IPv6 does not, requiring expensive and indefinite dual stack. * Can solve the multihoming/mobility problems we see in v4 if we ditch TCP with the next protocol and build something with multilevel dynamic addressing at the heart. Those problems remain intractable if we don't... and for IPv6 we didn't. and so on. -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From drais at icantclick.org Wed Feb 9 13:58:34 2011 From: drais at icantclick.org (david raistrick) Date: Wed, 9 Feb 2011 14:58:34 -0500 (EST) Subject: Looking for an IPv6 naysayer... In-Reply-To: <4D52E942.5000607@ispalliance.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> Message-ID: On Wed, 9 Feb 2011, Scott Helms wrote: > For ISPs in this circumstance the choice will be CGNAT rather than IPv6 for a > number of years because the cost is much lower and according to the vendors > selling CGNAT solutions the impact to end users is (almost) unnoticeable. Anyone care to define CGNAT? Google results for this are either unrelated or "CGNAT will save us" or "CGNAT doesnt count" - no rfcs, no explainations, nothing.... -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From dorn at hetzel.org Wed Feb 9 13:59:36 2011 From: dorn at hetzel.org (Dorn Hetzel) Date: Wed, 9 Feb 2011 14:59:36 -0500 Subject: Looking for an IPv6 naysayer... In-Reply-To: <87sjvxhu1v.fsf@oban.berlin.quux.de> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> Message-ID: I don't know. We're pretty far down the road now, but there might be things that could have done with NAT/PAT to make them suck less, at least for eyeball networks. Just being the devils advocate here. What if dynamic address assignment by eyeball ISPs had been modified to allow a "fractional" IP address reservation. 1/2 IP, 1/4 IP, ..., 1/16 IP, down to maybe 1/256 IP. Each one would represent a range of ports, dividing up the available port range in 2^k pieces. This wouldn't really represent a layer of NAT, just an agreement by the CPE device to only use a specific range of ports within the assigned routable IP address (this is the fractional IP part). Of course, the upstream router could enforce that port restriction. The "low" fraction in each IP would tend to have the standard server ports available, so one server on standard ports could be accomodated per routable IP, but eyeball boxes shouldn't care that much, and everybody would have a fixed port range, so P2P services that are port flexible could still have ports to map in through. Ok, it's kind of ugly, but the PC's inside it wouldn't feel much worse off than they do today. the CPE could even map static ports all the way through to pc's on the lan... On Wed, Feb 9, 2011 at 2:44 PM, Jens Link wrote: > Scott Helms writes: > > > IPv6 for some ISPs will be extraordinarily painful because of legacy > > layer 2 gear > > I don't feel sorry for them. We know that IPv6 is coming for how long? > 15years? 10year? 5years? Well if you only read the mainstream media you > should have read something about this new Internet thing about two years > ago. And still many people fear IPv6 or think the can still wait for > another couple of years. > > > For ISPs in this circumstance the choice will be CGNAT rather than IPv6 > > for a number of years because the cost is much lower and according to > > the vendors selling CGNAT solutions the impact to end users is (almost) > > unnoticeable. > > Cost's might be lower but service will be worse. NAT breaks a lot of > applications file sharing will not work properly and running your own > web server at home will not work properly. Well you always get what you > pay for and people will buy any crap if it is cheap enough. > > Jens > -- > ------------------------------------------------------------------------- > | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | > | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | > ------------------------------------------------------------------------- > > From drais at icantclick.org Wed Feb 9 14:00:52 2011 From: drais at icantclick.org (david raistrick) Date: Wed, 9 Feb 2011 15:00:52 -0500 (EST) Subject: Looking for an IPv6 naysayer... In-Reply-To: <87sjvxhu1v.fsf@oban.berlin.quux.de> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> Message-ID: On Wed, 9 Feb 2011, Jens Link wrote: > Scott Helms writes: > >> IPv6 for some ISPs will be extraordinarily painful because of legacy >> layer 2 gear > > I don't feel sorry for them. We know that IPv6 is coming for how long? > 15years? 10year? 5years? Well if you only read the mainstream media you And at what point during that time did they have any vendor gear they could purchase that -would- support v6? At -best- during the last 5 years, but I'd put money on that even today they can't purchase gear with adequate v6 support. -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From jbates at brightok.net Wed Feb 9 14:04:47 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 09 Feb 2011 14:04:47 -0600 Subject: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> Message-ID: <4D52F35F.30003@brightok.net> On 2/9/2011 1:58 PM, david raistrick wrote: > Anyone care to define CGNAT? Google results for this are either > unrelated or "CGNAT will save us" or "CGNAT doesnt count" - no rfcs, no > explainations, nothing.... CGNAT, CGN (carrier grade nat, technically a marketing term), LSN (large scale NAT), NAT44[4..].... Jack From iljitsch at muada.com Wed Feb 9 14:05:50 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 9 Feb 2011 21:05:50 +0100 Subject: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> Message-ID: <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> On 9 feb 2011, at 20:53, William Herrin wrote: > * Carrier NAT buys us enough years to build an IPv4 successor You're kidding, right? How long did it take exactly to get where we are now with IPv6? 18, 19 years? And yet there's still all kinds of stuff that isn't really ready for prime time yet. > * Next protocol should really be designed to support interoperability > with the old one from the bottom up. IPv6 does not That's because it's not the headers that aren't incompatible (the protocol translation is ok even though it could have been a bit better) but the addresses. A system that knows about 32-bit addresses will just not talk to a system with a 128-bit address. Once we're at 128-bit addresses then we can migrate to IPvA (7 - 9 are already taken) without much trouble. But then, 32-bit ASes interoperate with 16-bit ones with no trouble and still after a decade the support for that is not nearly good enough, either. From jbates at brightok.net Wed Feb 9 14:08:10 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 09 Feb 2011 14:08:10 -0600 Subject: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> Message-ID: <4D52F42A.3070002@brightok.net> On 2/9/2011 2:00 PM, david raistrick wrote: > And at what point during that time did they have any vendor gear they > could purchase that -would- support v6? At -best- during the last 5 > years, but I'd put money on that even today they can't purchase gear > with adequate v6 support. Supply and demand. There was no demand (most of my vendors didn't get any requests/questions concerning IPv6 until roughly 6 months ago). J and C have had considerable support (though still a work in progress) for some time, though I'd agree that 5 years sounds about right (it takes 1 large core network to push C/J into implementing base IPv6, but it was originally around that customer's desires and not multipurpose). Jack From jason at i6ix.com Wed Feb 9 14:09:16 2011 From: jason at i6ix.com (Jason Bertoch) Date: Wed, 09 Feb 2011 15:09:16 -0500 Subject: Looking for an IPv6 naysayer... In-Reply-To: <87sjvxhu1v.fsf@oban.berlin.quux.de> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> Message-ID: <4D52F46C.1070909@i6ix.com> On 2011/02/09 2:44 PM, Jens Link wrote: >> IPv6 for some ISPs will be extraordinarily painful because of legacy >> > layer 2 gear > I don't feel sorry for them. We know that IPv6 is coming for how long? > 15years? 10year? 5years? Well if you only read the mainstream media you > should have read something about this new Internet thing about two years > ago. And still many people fear IPv6 or think the can still wait for > another couple of years. > I'm not sure about your part of the world, but the economy has been terrible in mine. Even in a good economy, DSL margins don't afford the ability to replace your network every two years. In fact, spending on new gear all but halted for us over the last 6 years. While everyone is still figuring out best practices for IPv6 rollout today, how difficult would it have been to plan and purchase the exact equipment that long ago? Was the right equipment even available for a production environment? Not only that, but cheap CPE equipment that supports IPv6 still hardly exists today, and all of that will need replacing. In addition, what about IP phones and the customer that just replaced their entire phone system? Are they going to want to do that all over again by the end of the year? No, IPv6 rollout is going to be extremely expensive and will likely put a number of smaller operations out of business. -- /Jason From lists at quux.de Wed Feb 9 14:11:49 2011 From: lists at quux.de (Jens Link) Date: Wed, 09 Feb 2011 21:11:49 +0100 Subject: Looking for an IPv6 naysayer... In-Reply-To: (david raistrick's message of "Wed, 9 Feb 2011 15:00:52 -0500 (EST)") References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> Message-ID: <87oc6ldl2y.fsf@oban.berlin.quux.de> david raistrick writes: > And at what point during that time did they have any vendor gear they > could purchase that -would- support v6? At -best- during the last 5 > years, but I'd put money on that even today they can't purchase gear > with adequate v6 support. Another chicken and egg problem here. Customers have no demand for IPv6, vendors don't implement it. Vendors don't implement it, customers don't use it. Sad but true. Right now I have two TAC request open with Cisco regarding IPv6 problems on the ASA. Ever tried traceroute to a dual-stacked or IPv6 only host? ;-) Jens BTW: No need to cc me I'm reading the list. -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From iljitsch at muada.com Wed Feb 9 14:17:14 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 9 Feb 2011 21:17:14 +0100 Subject: Looking for an IPv6 naysayer... In-Reply-To: <4D52E942.5000607@ispalliance.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> Message-ID: <523E030F-CF84-4700-A92D-D281D599F37A@muada.com> On 9 feb 2011, at 20:21, Scott Helms wrote: > IPv6 for some ISPs will be extraordinarily painful because of legacy layer 2 gear (usually DSLAMs that drop any frame with IPv6 in the EtherType field), inability to upgrade customer gear efficiently [...] > For ISPs in this circumstance the choice will be CGNAT rather than IPv6 for a number of years because the cost is much lower and according to the vendors selling CGNAT solutions the impact to end users is (almost) unnoticeable. The good thing is that as an ISP, you don't have to give everyone the same thing. For the content people, it's either an AAAA record in the DNS or no AAAA record in the DNS. But as an ISP, you can keep your existing customers on existing IPv4 using existing hardware, while you roll out CGNAT + IPv6 for new customers using new gear. (Yes, that's still going to be annoying, but annoying in the sort of "I wish I didn't have to but I guess I do" kind of way rather than the "this will bankrupt the company" kind of way.) As long as your "legacy" users have an IPv4 address they can always use tunneling to get IPv6 (you may want to set up a tunnel termination box for this) if they need IPv6. But they won't really _need_ IPv6 (at least not very soon) because they can set up port mappings etc and everything they need can work over IPv4. For the new users, there are no port mappings behind the CGNAT so they do need IPv6 for hosting services and for VoIP and peer-to-peer file sharing. They also can't get a protocol 41 tunnel so you, their ISP, has to provide them with IPv6. But just CGNAT with no IPv6 is going to be very bad. Maybe 95% of your users won't notice, but do you really want the other 5% to tie up your support lines? From george.herbert at gmail.com Wed Feb 9 14:17:42 2011 From: george.herbert at gmail.com (George Herbert) Date: Wed, 9 Feb 2011 12:17:42 -0800 Subject: Looking for an IPv6 naysayer... In-Reply-To: <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> Message-ID: On Wed, Feb 9, 2011 at 12:05 PM, Iljitsch van Beijnum wrote: > [...] Once we're at 128-bit addresses then we can migrate to IPvA (7 - 9 are already taken) without much trouble. But then, 32-bit ASes interoperate with 16-bit ones with no trouble and still after a decade the support for that is not nearly good enough, either. I know about IPv8 (sigh), and the Chinese abortive IPv9 claim, but when did 7 happen? There's a Google hit on Tim Wilson posting about IPv4 replacements in an informational RFC from 1993 using IPv7, but that's all I found. -- -george william herbert george.herbert at gmail.com From mike at mtcc.com Wed Feb 9 14:20:19 2011 From: mike at mtcc.com (Michael Thomas) Date: Wed, 09 Feb 2011 12:20:19 -0800 Subject: Looking for an IPv6 naysayer... In-Reply-To: <4D52F42A.3070002@brightok.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> <4D52F42A.3070002@brightok.net> Message-ID: <4D52F703.10902@mtcc.com> On 02/09/2011 12:08 PM, Jack Bates wrote: > > > On 2/9/2011 2:00 PM, david raistrick wrote: >> And at what point during that time did they have any vendor gear they >> could purchase that -would- support v6? At -best- during the last 5 >> years, but I'd put money on that even today they can't purchase gear >> with adequate v6 support. > > Supply and demand. There was no demand (most of my vendors didn't get > any requests/questions concerning IPv6 until roughly 6 months ago). J > and C have had considerable support (though still a work in progress) > for some time, though I'd agree that 5 years sounds about right (it > takes 1 large core network to push C/J into implementing base IPv6, > but it was originally around that customer's desires and not > multipurpose). Ultimately vendors only kneejerk when they're told to kneejerk. It's not like we didn't know about it 10 years ago too, but when the feature mill was prioritized... around the merry-go-round we go. So let's lay blame where everybody can agree: suits. Mike From grobe0ba at gmail.com Wed Feb 9 14:23:17 2011 From: grobe0ba at gmail.com (Atticus) Date: Wed, 9 Feb 2011 15:23:17 -0500 Subject: pf not redirecting packets In-Reply-To: References: Message-ID: I did indeed. I found an error in the file I attatched, but fixing it made no difference. Remove quick from 'block in on wm0' On Feb 9, 2011 2:00 PM, "bart sikkes" wrote: if NAT works it probably isn't this, but who knows, did you turn packet forwarding on? net.inet.ip.forwarding=1 bart On Tue, Feb 8, 2011 at 4:34 PM, Atticus wrote: > Okay, so maybe I'm just retar... From gbonser at seven.com Wed Feb 9 14:23:30 2011 From: gbonser at seven.com (George Bonser) Date: Wed, 9 Feb 2011 12:23:30 -0800 Subject: Looking for an IPv6 naysayer... In-Reply-To: <87sjvxhu1v.fsf@oban.berlin.quux.de> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com> > Cost's might be lower but service will be worse. NAT breaks a lot of > applications file sharing will not work properly and running your own > web server at home will not work properly. Well you always get what you > pay for and people will buy any crap if it is cheap enough. > > Jens While that is true, it is no worse than the situation right now. In the US, the vast majority of users are already behind a NAT (I would say over 90% of them are) so they are already experiencing this breakage. From iljitsch at muada.com Wed Feb 9 14:24:26 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 9 Feb 2011 21:24:26 +0100 Subject: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> Message-ID: <3E5A5A66-B733-405B-9BE9-0B5CABC725BB@muada.com> On 9 feb 2011, at 21:17, George Herbert wrote: >> Once we're at 128-bit addresses then we can migrate to IPvA (7 - 9 are already taken) without much trouble. > I know about IPv8 (sigh), and the Chinese abortive IPv9 claim, but > when did 7 happen? RFC 1475, apparently: http://www.iana.org/assignments/version-numbers/version-numbers.xhtml From bill at herrin.us Wed Feb 9 14:26:16 2011 From: bill at herrin.us (William Herrin) Date: Wed, 9 Feb 2011 15:26:16 -0500 Subject: Looking for an IPv6 naysayer... In-Reply-To: <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> Message-ID: On Wed, Feb 9, 2011 at 3:05 PM, Iljitsch van Beijnum wrote: > On 9 feb 2011, at 20:53, William Herrin wrote: >> * Carrier NAT buys us enough years to build an IPv4 successor > > You're kidding, right? How long did it take exactly to get where > we are now with IPv6? 18, 19 years? Tech like carrier NAT theoretically yeilds address reclamation in excess of 80%. Internet-facing servers must consume IP address. It's convenient for client computers to do so as well, but not critical to the general function of the Internet. 20 years is about what that level of reclamation buys before we're out of addresses again. As you say -- enough time to develop a protocol and get it into the software and hardware. >> * Next protocol should really be designed to support interoperability >> with the old one from the bottom up. IPv6 does not > > That's because it's not the headers that aren't incompatible (the > protocol translation is ok even though it could have been a bit > better) but the addresses. No, it's because decisions were made to try to abandon the old DFZ table along with IPv4 and institute /64 as a standard subnet mask. But for those choices, you could directly translate the IPv4 and IPv6 headers back and forth, at least until one of the addresses topped 32 bits. The transition to IPv6 could be little different than the transition to 32-bit AS numbers -- a nuisance, not a crisis. You recompile your software with the new IN_ADDR size and add IP header translation to the routers, but there's no configuration change, no new commands to learn, etc. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From lists at quux.de Wed Feb 9 14:33:35 2011 From: lists at quux.de (Jens Link) Date: Wed, 09 Feb 2011 21:33:35 +0100 Subject: Looking for an IPv6 naysayer... In-Reply-To: <4D52F46C.1070909@i6ix.com> (Jason Bertoch's message of "Wed, 09 Feb 2011 15:09:16 -0500") References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> <4D52F46C.1070909@i6ix.com> Message-ID: <87fwrxc5i8.fsf@oban.berlin.quux.de> Jason Bertoch writes: > I'm not sure about your part of the world, but the economy has been > terrible in mine. Even in a good economy, DSL margins don't afford the > ability to replace your network every two years. Same thing here in Germany. DSL providers fighting for the lowest price and customers thinking that free service is still too expensive. > In fact, spending on new gear all but halted for us over the last 6 > years. While everyone is still figuring out best practices for IPv6 > rollout today, how difficult would it have been to plan and purchase > the exact equipment that long ago? Yeah. But they could have made plans and demanded working equipment from the vendors. > Was the right equipment even available for a production environment? No, an in some case it is still not available today. > Not only that, but cheap CPE equipment that supports IPv6 still hardly > exists today, and all of that will need replacing. In Europe: Fritzbox from AVM. Almost all the big vendors have their own branded version of it. And the latter versions do support IPv6 quite well. > In addition, what about IP phones and the customer that just replaced > their entire phone system? Are they going to want to do that all over > again by the end of the year? You don't have to replace everything at once. But you have to start somewhere. > No, IPv6 rollout is going to be extremely expensive and will likely put > a number of smaller operations out of business. I know several smaller ISPs which offer IPV6 for years. Sure the eyeball providers can hardly beat the cheap prices of the big players. But they do offer individual and good service. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From iljitsch at muada.com Wed Feb 9 14:33:51 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 9 Feb 2011 21:33:51 +0100 Subject: Looking for an IPv6 naysayer... In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> <5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com> Message-ID: <3A3CBEC3-97FC-4709-B649-F7C90BBB0F9C@muada.com> On 9 feb 2011, at 21:23, George Bonser wrote: > While that is true, it is no worse than the situation right now. In the > US, the vast majority of users are already behind a NAT (I would say > over 90% of them are) so they are already experiencing this breakage. There's a big difference between being able to have uPNP IGD or NAT-PMP open up holes in the NAT (or do it manually) and being 100% incapable of getting any and all incoming sessions. And between having 64k ports for a home and having 64k ports for 100, 1000, 10000 ? homes. From lists at quux.de Wed Feb 9 14:38:24 2011 From: lists at quux.de (Jens Link) Date: Wed, 09 Feb 2011 21:38:24 +0100 Subject: Looking for an IPv6 naysayer... In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com> (George Bonser's message of "Wed, 9 Feb 2011 12:23:30 -0800") References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> <5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com> Message-ID: <8762stc5a7.fsf@oban.berlin.quux.de> "George Bonser" writes: > While that is true, it is no worse than the situation right now. In the > US, the vast majority of users are already behind a NAT (I would say > over 90% of them are) so they are already experiencing this breakage. I never thought it was that bad. In some 3G/wireless networks in Germany the providers use NAT and transparent HTTP-proxy. But this is only wireless. I'm not aware of any DSL or Cable provider NATing their customers. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From jared at puck.nether.net Wed Feb 9 14:43:35 2011 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 9 Feb 2011 15:43:35 -0500 Subject: IPv6 - a noobs prespective In-Reply-To: <4D52DB6E.9080009@brightok.net> References: <4D52DB6E.9080009@brightok.net> Message-ID: On Feb 9, 2011, at 1:22 PM, Jack Bates wrote: > On 2/9/2011 12:03 PM, William Herrin wrote: >> The thing that terrifies me about deploying IPv6 is that apps >> compatible with both are programmed to attempt IPv6 before IPv4. This >> means my first not-quite-correct IPv6 deployments are going to break >> my apps that are used to not having and therefore not trying IPv6. But >> that's not the worst part... as the folks my customers interact with >> over the next couple of years make their first not-quite-correct IPv6 >> deployments, my access to them is going to break again. And again. And >> again. And I won't have the foggiest idea who's next until I get the >> call that such-and-such isn't working right. > > What scares me most is that every time I upgrade a router to support needed hardware or some badly needed IPv6 feature, something else breaks. Sometimes it's just the router crashes on a specific IPv6 command entered at CLI (C) or as nasty as NSR constantly crashing the slave (J); the fixes generally requiring me to upgrade again to the latest cutting edge releases which everyone hates (where I'm sure I'll find MORE bugs). > > The worst is when you're the first to find the bug(which I'm not even sure how it's possible given how simplistic my configs are, isis multitopology, iBGP, NSR, a few acls and route-maps/policies), it takes 3-6 months or so to track it down, and then it's put only in the next upcoming release (not out yet) and backported to the last release. > > > Jack (hates all routers equally, doesn't matter who makes it) Welcome to the life of being a network operator. :) I know we have had to regularly upgrade for SIRT/PSIRT issues in the past that only impacted our network due to our deployment of IPv6, but it also has allowed us years of additional outages/upgrade justifications. I've not been happy any time we've had this come around, as honestly, nobody wants to be chasing these, but it's also a good experience to view the entire set of risks that we face in the network. I'd rather be upgrading because of a known threat than be hit by an unknown one... I've found it imperative in my life to always have a device running the (so called) latest and greatest software in the network. Sometimes this has caused great pain, other times it's reduced the pain when a forced upgrade comes upon us (for new hardware, or PSIRT). Making sure that the entire team understands these requirements, and following the usual advisories will help you manage this risk. (and hopefully with a great deal of success). - Jared From franck at genius.com Wed Feb 9 14:48:21 2011 From: franck at genius.com (Franck Martin) Date: Thu, 10 Feb 2011 09:48:21 +1300 (FJST) Subject: Looking for an IPv6 naysayer... In-Reply-To: <4D52F46C.1070909@i6ix.com> Message-ID: <13687308.379.1297284463389.JavaMail.franck@franck-martins-macbook-pro.local> ----- Original Message ----- > From: "Jason Bertoch" > To: nanog at nanog.org > Sent: Thursday, 10 February, 2011 9:09:16 AM > Subject: Re: Looking for an IPv6 naysayer... > On 2011/02/09 2:44 PM, Jens Link wrote: > No, IPv6 rollout is going to be extremely expensive and will likely > put > a number of smaller operations out of business. > You put your finger exactly on the reasons for advocating IPv6. If you look at the OECD report and some others... You have to move to IPv6, not because it has new features, not because it is great, but because if you don't, you will loose your economical advantage over your competitors (and other economies). Who spoke about the SEC requiring mandatory fillings re state of IPv6 deployment for business continuity plan requirements? From jbates at brightok.net Wed Feb 9 14:50:12 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 09 Feb 2011 14:50:12 -0600 Subject: Looking for an IPv6 naysayer... In-Reply-To: <523E030F-CF84-4700-A92D-D281D599F37A@muada.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <523E030F-CF84-4700-A92D-D281D599F37A@muada.com> Message-ID: <4D52FE04.9080901@brightok.net> On 2/9/2011 2:17 PM, Iljitsch van Beijnum wrote: > But just CGNAT with no IPv6 is going to be very bad. Maybe 95% of > your users won't notice, but do you really want the other 5% to tie > up your support lines? Yes, as that will cause them to produce an IPv6 product for those customers (even if it's a specialized CPE they ship to those 5% that does a tunnel back to an ISP server which connects to native IPv6). You must have demand and pressure to push companies to spend money. Helpdesk calls count. Let the phones ring. The suits will listen then. Jack From gbonser at seven.com Wed Feb 9 14:50:44 2011 From: gbonser at seven.com (George Bonser) Date: Wed, 9 Feb 2011 12:50:44 -0800 Subject: Looking for an IPv6 naysayer... In-Reply-To: <8762stc5a7.fsf@oban.berlin.quux.de> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><4D52E942.5000607@ispalliance.net><87sjvxhu1v.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com> <8762stc5a7.fsf@oban.berlin.quux.de> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> > > I never thought it was that bad. In some 3G/wireless networks in > Germany > the providers use NAT and transparent HTTP-proxy. But this is only > wireless. I'm not aware of any DSL or Cable provider NATing their > customers. > > Jens Practically all broadband providers NAT their customers in the US. If you look at the largest ones which are probably Comcast, Verizon, and AT&T, you have the majority of US broadband subscribers right there. From sds at dcs.gla.ac.uk Wed Feb 9 14:54:27 2011 From: sds at dcs.gla.ac.uk (Stephen D. Strowes) Date: Wed, 09 Feb 2011 20:54:27 +0000 Subject: Top webhosters offering v6 too? In-Reply-To: References: <16975AA8-ABEB-402E-BA05-1BE51138A133@ecs.soton.ac.uk> Message-ID: <1297284867.22210.2.camel@ikeq> On Sun, 2011-02-06 at 14:52 +0000, Tim Chown wrote: > Which of the big boys are doing it? Unsure of how big they are in the grand scheme, but I use Dreamhost. They quietly started offering IPv6 on all accounts about a week ago. -S. From khelms at ispalliance.net Wed Feb 9 14:56:00 2011 From: khelms at ispalliance.net (Scott Helms) Date: Wed, 09 Feb 2011 15:56:00 -0500 Subject: Looking for an IPv6 naysayer... In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><4D52E942.5000607@ispalliance.net><87sjvxhu1v.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com> <8762stc5a7.fsf@oban.berlin.quux.de> <5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> Message-ID: <4D52FF60.1090102@ispalliance.net> On 2/9/2011 3:50 PM, George Bonser wrote: > > Practically all broadband providers NAT their customers in the US. If > you look at the largest ones which are probably Comcast, Verizon, and > AT&T, you have the majority of US broadband subscribers right there. > > > > Hmm, I am not aware of Comcast (or any other large MSO) doing any NAT on large scale. Having said that almost all of the DSL customers in the US are being NAT'ed, but on the edge device (DSL modem) rather than in the core. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From stephend at gmail.com Wed Feb 9 14:59:06 2011 From: stephend at gmail.com (Stephen Davis) Date: Thu, 10 Feb 2011 09:59:06 +1300 Subject: Looking for an IPv6 naysayer... In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> <5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com> <8762stc5a7.fsf@oban.berlin.quux.de> <5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> Message-ID: > Practically all broadband providers NAT their customers in the US. ?If > you look at the largest ones which are probably Comcast, Verizon, and > AT&T, you have the majority of US broadband subscribers right there. You mean they provide CPE which does NAT? Or the CPE actually has a RFC1918 address on the WAN? From Sam.Crooks at experian.com Wed Feb 9 14:59:31 2011 From: Sam.Crooks at experian.com (Crooks, Sam) Date: Wed, 9 Feb 2011 14:59:31 -0600 Subject: Is it permissible to advertise number resources allocated by one RIR to a ISP in a region governed by a different RIR? Practical? Message-ID: Is it permissible, from a policy perspective, for a multi-homed end user to announce the numbering resource allocation received from one RIR (for discussion purposes, let's say ARIN) to upstream service providers in a different region (for example, in the RIPE region)? Is it feasible from a practical perspective? I've looked through IANA and ARIN policy and can't find anything which covers such a scenario. I have seen some things about transferring number resources from one RIR to another RIR, which is similar, but not exactly the same. Rationale: Suppose you are a large global enterprise, truly globalized in practice, not in mere name, and performance concerns aside, you provide failover for Internet access of enterprise users in one region by failing over to internet access in a different region. Since you probably are using 10/8 addressing within your network and you NAT the private IPv4 addresses to a public IPv4 address before sending the traffic on.., so this works. Given lack of NAT66, and the best practice IPv6 numbering which is purported to use globally routable IPv6 addresses within your enterprise network, the achievable way to accomplish the same use possible today in IPv4 would seem to be to advertise the IPv6 addressing from one RIR to a ISP in a region governed by a different RIR (or LIR). From juicewvu at gmail.com Wed Feb 9 15:00:26 2011 From: juicewvu at gmail.com (Josh Smith) Date: Wed, 9 Feb 2011 16:00:26 -0500 Subject: Looking for an IPv6 naysayer... In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> <5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com> <8762stc5a7.fsf@oban.berlin.quux.de> <5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> Message-ID: On Wed, Feb 9, 2011 at 3:50 PM, George Bonser wrote: >> >> I never thought it was that bad. In some 3G/wireless networks in >> Germany >> the providers use NAT and transparent HTTP-proxy. But this is only >> wireless. I'm not aware of any DSL or Cable provider NATing their >> customers. >> >> Jens > > Practically all broadband providers NAT their customers in the US. ?If > you look at the largest ones which are probably Comcast, Verizon, and > AT&T, you have the majority of US broadband subscribers right there. > > > > Are you sure about that - I'm a comcast subscriber and see no signs that I am being natted? Thanks, -- Josh Smith KD8HRX email/jabber:? juicewvu at gmail.com phone:? 304.237.9369(c) From gbonser at seven.com Wed Feb 9 15:17:11 2011 From: gbonser at seven.com (George Bonser) Date: Wed, 9 Feb 2011 13:17:11 -0800 Subject: Looking for an IPv6 naysayer... In-Reply-To: <4D52FF60.1090102@ispalliance.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><4D52E942.5000607@ispalliance.net><87sjvxhu1v.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com> <8762stc5a7.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> <4D52FF60.1090102@ispalliance.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13980@RWC-EX1.corp.seven.com> > Hmm, I am not aware of Comcast (or any other large MSO) doing any NAT > on > large scale. Having said that almost all of the DSL customers in the > US > are being NAT'ed, but on the edge device (DSL modem) rather than in the > core. > > -- > Scott Helms > Vice President of Technology > ISP Alliance, Inc. DBA ZCorum How many instances of 10/8 did they say they were running? I was behind a NAT when I had Comcast service. I am behind a NAT currently with my AT&T service. Note that the NAT was done on the "cable modem" in both cases and not further in to their network. That said, from my reading of some industry large scale NAT devices (the A10 AX series is one which I am familiar with), they do things such as full cone NAT so it will still work with many applications that might break with conventional overload dynamic NAT. From jlewis at lewis.org Wed Feb 9 15:17:14 2011 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 9 Feb 2011 16:17:14 -0500 (EST) Subject: Is it permissible to advertise number resources allocated by one RIR to a ISP in a region governed by a different RIR? Practical? In-Reply-To: References: Message-ID: On Wed, 9 Feb 2011, Crooks, Sam wrote: > Is it permissible, from a policy perspective, for a multi-homed end user > to announce the numbering resource allocation received from one RIR (for > discussion purposes, let's say ARIN) to upstream service providers in a > different region (for example, in the RIPE region)? Nope. The RIR-police will shut you down. Just kidding. I'm in ARIN's region and have a customer in Africa for whom we're announcing AFRINIC space. It happens. As long as you have authorization from the registrant (I'd say owner, but the RIR-semantics police would come for me) of the space, I wouldn't worry about utilizing "out of region" numbering resources. This sort of thing probably happens quite a bit more than you'd guess...both legitmately and not. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From gbonser at seven.com Wed Feb 9 15:18:08 2011 From: gbonser at seven.com (George Bonser) Date: Wed, 9 Feb 2011 13:18:08 -0800 Subject: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><4D52E942.5000607@ispalliance.net><87sjvxhu1v.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com><8762stc5a7.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13981@RWC-EX1.corp.seven.com> > > You mean they provide CPE which does NAT? Or the CPE actually has a > RFC1918 address on the WAN? Correct, the CPE does NAT. But regardless, the user's platform (and hence all the applications running on it) are going through a dynamic NAT. From gbonser at seven.com Wed Feb 9 15:18:45 2011 From: gbonser at seven.com (George Bonser) Date: Wed, 9 Feb 2011 13:18:45 -0800 Subject: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><4D52E942.5000607@ispalliance.net><87sjvxhu1v.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com><8762stc5a7.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13982@RWC-EX1.corp.seven.com> > Are you sure about that - I'm a comcast subscriber and see no signs > that I am being natted? > Josh, maybe it is different in different markets. When I had Comcast, I was behind a NAT. From bicknell at ufp.org Wed Feb 9 15:23:43 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 9 Feb 2011 13:23:43 -0800 Subject: Is it permissible to advertise number resources allocated by one RIR to a ISP in a region governed by a different RIR? Practical? In-Reply-To: References: Message-ID: <20110209212343.GA42747@ussenterprise.ufp.org> In a message written on Wed, Feb 09, 2011 at 02:59:31PM -0600, Crooks, Sam wrote: > Is it permissible, from a policy perspective, for a multi-homed end user > to announce the numbering resource allocation received from one RIR (for > discussion purposes, let's say ARIN) to upstream service providers in a > different region (for example, in the RIPE region)? There are probably thousands if not tens of thousands of prefixes announced in multiple regions, or even just different regions then they were allocated. Perfectly normal. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From rs at seastrom.com Wed Feb 9 15:24:28 2011 From: rs at seastrom.com (Robert E. Seastrom) Date: Wed, 09 Feb 2011 16:24:28 -0500 Subject: Is it permissible to advertise number resources allocated by one RIR to a ISP in a region governed by a different RIR? Practical? In-Reply-To: (Sam Crooks's message of "Wed, 9 Feb 2011 14:59:31 -0600") References: Message-ID: <86tygc7vg3.fsf@seastrom.com> "Crooks, Sam" writes: > Is it permissible, from a policy perspective, for a multi-homed end user > to announce the numbering resource allocation received from one RIR (for > discussion purposes, let's say ARIN) to upstream service providers in a > different region (for example, in the RIPE region)? Yes. > Is it feasible from a practical perspective? Sure, people advertise prefixes allocated by ARIN in RIPE and APNIC territory all the time. If that didn't work, multinational networks wouldn't work so well would they? > I've looked through IANA and ARIN policy and can't find anything which > covers such a scenario. I have seen some things about transferring > number resources from one RIR to another RIR, which is similar, but not > exactly the same. That's because the Internet is global in scope. > Suppose you are a large global enterprise, truly globalized in practice, > not in mere name, and performance concerns aside, you provide failover > for Internet access of enterprise users in one region by failing over to > internet access in a different region. Since you probably are using > 10/8 addressing within your network and you NAT the private IPv4 > addresses to a public IPv4 address before sending the traffic on.., so > this works. Given lack of NAT66, and the best practice IPv6 numbering > which is purported to use globally routable IPv6 addresses within your > enterprise network, the achievable way to accomplish the same use > possible today in IPv4 would seem to be to advertise the IPv6 addressing > from one RIR to a ISP in a region governed by a different RIR (or LIR). I have worked for multiple companies where this (or something similar, like anycast, multiple discrete networks, or even international pipes) happens. No problemo. -r From george.herbert at gmail.com Wed Feb 9 15:27:48 2011 From: george.herbert at gmail.com (George Herbert) Date: Wed, 9 Feb 2011 13:27:48 -0800 Subject: Is it permissible to advertise number resources allocated by one RIR to a ISP in a region governed by a different RIR? Practical? In-Reply-To: References: Message-ID: On Wed, Feb 9, 2011 at 1:17 PM, Jon Lewis wrote: > On Wed, 9 Feb 2011, Crooks, Sam wrote: > >> Is it permissible, from a policy perspective, for a multi-homed end user >> to announce the numbering resource allocation received from one RIR (for >> discussion purposes, let's say ARIN) to upstream service providers in a >> different region (for example, in the RIPE region)? > > Nope. ?The RIR-police will shut you down. Mean, Jon. Mean. 8-) > Just kidding. ?I'm in ARIN's region and have a customer in Africa for whom > we're announcing AFRINIC space. ?It happens. ?As long as you have > authorization from the registrant (I'd say owner, but the RIR-semantics > police would come for me) of the space, I wouldn't worry about utilizing > "out of region" numbering resources. > > This sort of thing probably happens quite a bit more than you'd guess...both > legitmately and not. I believe all the big multihomed multinational organizations generally all do this; the ones I've worked with (banks) all did. It would sort of defeat the purpose of multihoming if you couldn't announce not just to other providers, but in some circumstances multi-geographically. If my multihoming crosses a RIR boundary it's still multihoming. One of those RIRs is probably "home territory" to ask for allocations from, but in any case there shouldn't be a technical or policy block to anouncing ARIN space in RIPE land, or any similar variation thereof. -- -george william herbert george.herbert at gmail.com From khelms at ispalliance.net Wed Feb 9 15:28:11 2011 From: khelms at ispalliance.net (Scott Helms) Date: Wed, 09 Feb 2011 16:28:11 -0500 Subject: Looking for an IPv6 naysayer... In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13980@RWC-EX1.corp.seven.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><4D52E942.5000607@ispalliance.net><87sjvxhu1v.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com> <8762stc5a7.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> <4D52FF60.1090102@ispalliance.net> <5A6D953473350C4B9995546AFE9939EE0BC13980@RWC-EX1.corp.seven.com> Message-ID: <4D5306EB.3030203@ispalliance.net> George, Comcast, like all(?) DOCSIS systems uses 10/8 or one of the other defined non-routable blocks for cable modems, which (if its a DOCSIS certified device) will be a bridge only and will not do NAT. If you we're NAT'ed on a cable modem system it must have been a proprietary system, of which there once was a ton before DOCSIS caught on, that Comcast hadn't phased out. I don't believe that any of the large MSO's (and none of the small ones I know) are doing NAT on edge devices or the core at this point, however your point is still valid since virtually all of the ADSL lines deployed are being NAT'ed at the modem level and that means that millions of people are being NAT'ed without a choice. That also means that a lot of people are already going through two NAT translations since they have plugged in a small router behind their DSL modem and both are NAT'ing their buggy little hearts out. We also have to think about the tremendous number of people on all kinds of networks that are voluntarily, like me, NAT'ing through one device of their own (usually not educated) choice. > How many instances of 10/8 did they say they were running? I was behind > a NAT when I had Comcast service. I am behind a NAT currently with my > AT&T service. > > Note that the NAT was done on the "cable modem" in both cases and not > further in to their network. That said, from my reading of some > industry large scale NAT devices (the A10 AX series is one which I am > familiar with), they do things such as full cone NAT so it will still > work with many applications that might break with conventional overload > dynamic NAT. > > > -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From gbonser at seven.com Wed Feb 9 15:33:51 2011 From: gbonser at seven.com (George Bonser) Date: Wed, 9 Feb 2011 13:33:51 -0800 Subject: Looking for an IPv6 naysayer... In-Reply-To: <4D5306EB.3030203@ispalliance.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><4D52E942.5000607@ispalliance.net><87sjvxhu1v.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com> <8762stc5a7.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> <4D52FF60.1090102@ispalliance.net> <5A6D953473350C4B9995546AFE9939EE0BC13980@RWC-EX1.corp.seven.com> <4D5306EB.3030203@ispalliance.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13984@RWC-EX1.corp.seven.com> > > Comcast, like all(?) DOCSIS systems uses 10/8 or one of the other > defined non-routable blocks for cable modems, which (if its a DOCSIS > certified device) will be a bridge only and will not do NAT. If you > we're NAT'ed on a cable modem system it must have been a proprietary > system, of which there once was a ton before DOCSIS caught on, that > Comcast hadn't phased out. > > I don't believe that any of the large MSO's (and none of the small ones > I know) are doing NAT on edge devices or the core at this point, > however > your point is still valid since virtually all of the ADSL lines I can log in to the Two Wire device on my AT&T Uverse service and see the NAT configuration. It has a global IP on the Internet side and it has a DHCP server handing out RFC1918 addresses on the inside network. I can also configure some settings which allow certain applications inside to map to specific ports on the global IP. When I had Comcast, I am not positive where the NAT was being done, but my computer got an RFC1918 IP when it did DHCP. From iljitsch at muada.com Wed Feb 9 15:35:59 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 9 Feb 2011 22:35:59 +0100 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> Message-ID: <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> On 9 feb 2011, at 21:26, William Herrin wrote: >> You're kidding, right? How long did it take exactly to get where >> we are now with IPv6? 18, 19 years? > Tech like carrier NAT theoretically yeilds address reclamation in > excess of 80%. Most IPv4 space is unused anyway, but it's not being reclaimed much despite that. (How many IP addresses does the US federal government need? Few people would think ~ 10 /8s. Especially since many of them aren't even lit up.) >>> * Next protocol should really be designed to support interoperability >>> with the old one from the bottom up. IPv6 does not >> That's because it's not the headers that aren't incompatible (the >> protocol translation is ok even though it could have been a bit >> better) but the addresses. > No, it's because decisions were made to try to abandon the old DFZ > table along with IPv4 and institute /64 as a standard subnet mask. But > for those choices, you could directly translate the IPv4 and IPv6 > headers back and forth, at least until one of the addresses topped 32 > bits. The transition to IPv6 could be little different than the > transition to 32-bit AS numbers -- a nuisance, not a crisis. You > recompile your software with the new IN_ADDR size and add IP header > translation to the routers, but there's no configuration change, no > new commands to learn, etc. It's not that simple. But I agree on one thing: it could have been better. What needs to be done to move from IPv4 to IPv6 is three things: 1. the headers 2. the addresses 3. the applications Today, only IPv6 applications can use IPv6 addresses and only when IPv6 applications use IPv6 addresses will there be IPv6 headers. It would have been better to roll out the headers first. That would have meant changes to routers, because routers touch the headers. But if translating between IPv6 with 32-bit addresses and IPv4 can be done with low overhead (which is more or less the case today, BTW) then it would have been possible to upgrade from IPv4 to IPv6 subnet by subnet. This way, there wouldn't have had to be any dual stack, and once people had deployed IPv6 they would have kept using it. Today, and especially some years ago, IPv6 would/will often atrophy after having been deployed initially because of lack of use. Apps could have been upgraded the same way they have now, with the only difference that using an IPv4-mapped IPv6 address meant generating an IPv6 packet, not an IPv4 packet as is done today. Once 128-bit addresses are being used going from an IPv6 subnet to an IPv4 subnet becomes problematic, but this can be solved with stateful translation so most stuff keeps working anyway. And remember, servers and apps that can't work through a stateful translator can still get 32-bit addresses so everything keeps working without trouble. However, it's easy to come up with all of this in 2011. In 1993 the world was very different, and many things we take for granted today were still open questions then. It's very illuminating to read up on the mailinglist discussions from back then. People complained about IPv6 a decade or half a decade ago, too. Back then there may have been a chance to come up with a different protocol as a successor for IPv4, but it's way too late for that now. Anyway, most non-legacy applications support 128-bit addresses now and we have a pretty decent NAT64 spec sitting in the RFC editor queue (even if I do say so myself) so it's just a matter of sitting tight until we're through the painful part of the transition. From ka at pacific.net Wed Feb 9 15:36:31 2011 From: ka at pacific.net (Ken A) Date: Wed, 09 Feb 2011 15:36:31 -0600 Subject: Looking for an IPv6 naysayer... In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13980@RWC-EX1.corp.seven.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><4D52E942.5000607@ispalliance.net><87sjvxhu1v.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com> <8762stc5a7.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> <4D52FF60.1090102@ispalliance.net> <5A6D953473350C4B9995546AFE9939EE0BC13980@RWC-EX1.corp.seven.com> Message-ID: <4D5308DF.9020400@pacific.net> On 2/9/2011 3:17 PM, George Bonser wrote: >> Hmm, I am not aware of Comcast (or any other large MSO) doing any NAT >> on >> large scale. Having said that almost all of the DSL customers in the >> US >> are being NAT'ed, but on the edge device (DSL modem) rather than in > the >> core. >> >> -- >> Scott Helms >> Vice President of Technology >> ISP Alliance, Inc. DBA ZCorum > > > How many instances of 10/8 did they say they were running? I was behind > a NAT when I had Comcast service. I am behind a NAT currently with my > AT&T service. > > Note that the NAT was done on the "cable modem" in both cases and not > further in to their network. 10/8 is the management network on my cable modem. The cable modem bridges your wan 'real' ip(s) through to your PC or router. At least that's how Suddenlink does it here. The customer is normally 'locked out' of the cable modem, unlike a dsl modem. The largest NATs are presumably w/mobile carriers. I've never been behind NAT (except one I controlled) on a consumer dsl or cable link in the US. Ken That said, from my reading of some > industry large scale NAT devices (the A10 AX series is one which I am > familiar with), they do things such as full cone NAT so it will still > work with many applications that might break with conventional overload > dynamic NAT. > > > > > -- Ken Anderson Pacific Internet - http://www.pacific.net From owen at delong.com Wed Feb 9 15:38:06 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Feb 2011 13:38:06 -0800 Subject: Post-Exhaustion-phase "punishment" for early adopters In-Reply-To: References: <91338.18733.qm@web24704.mail.ird.yahoo.com> <1E8620FE-BC2C-4750-885B-63706D1853E1@spacething.org> <4D517AB2.7000105@matthew.at> <20110208220442.90F889D4BED@drugs.dv.isc.org> <46347.1297206493@localhost> <0CFF54003CD92945994CF0C0F90D81B670647E@EXCH1-FWA1.zenetra.local> Message-ID: <07159315-628C-4014-8265-684FD244B60C@delong.com> On Feb 9, 2011, at 4:35 AM, Sam Stickland wrote: > > > On 9 Feb 2011, at 02:43, "R. Benjamin Kessler" wrote: > >>>> From: George Herbert [mailto:george.herbert at gmail.com] >> >>>> "Let's just grab 2/8, it's not routed on the Internet..." >> >> +1 >> >> I was consulting for a financial services firm in the late '90s that was acquired by a large east-coast bank; the bank's brilliant scheme was to renumber all new acquisitions *out* of RFC1918 space and into (at the time) bogon space. >> >> If I recall, some of the arguments were "they were too big to fit into RFC1918 space" and by having all of their divisions in non-RFC1918 space it would make it easier for them to acquire new companies who used RFC1918 space internally. >> > > You don't have to trawl back to the late 90's to find this, I know of at least 3 or 4 large enterprises using large chunks of public address (multiple /8's) that aren't their's /today/. > > This "works" because 1) the Internet is only accessed through proxies, 2) devices that require direct Internet access are addressed out of registered address space (or NATed to registered address space), and 3) third party connections to others enterprises are usually src/dst NATTed to the enterprise's own ranges (with the added benefit that this NAT at 3rd party boundaries helps ensure symmetric traffic flow through firewalls). > > And I've only worked at 3 or 4 large enterprises so it's probably safe to assume there's more! With my SP background I was shocked and I'm not trying to defend this practice, but in the enterprise land it seems accepted. > > Sam On the freeways in the US, it's quite common for people to be doing 5-15 MPH over the speed limit. This practice seems accepted. I don't think there's a whole lot of sympathy, however, when someone receives a ticket for it. Owen From nathan at atlasnetworks.us Wed Feb 9 15:42:14 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Wed, 9 Feb 2011 21:42:14 +0000 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> > Most IPv4 space is unused anyway, but it's not being reclaimed much despite > that. (How many IP addresses does the US federal government need? Few > people would think ~ 10 /8s. Especially since many of them aren't even lit > up.) What do you mean, lit up? You mean they're not in the routing tables that you get from your carriers? I'd argue that's no indication of whether they're in use or not. From khelms at ispalliance.net Wed Feb 9 15:50:39 2011 From: khelms at ispalliance.net (Scott Helms) Date: Wed, 09 Feb 2011 16:50:39 -0500 Subject: Looking for an IPv6 naysayer... In-Reply-To: <4D5308DF.9020400@pacific.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><4D52E942.5000607@ispalliance.net><87sjvxhu1v.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com> <8762stc5a7.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> <4D52FF60.1090102@ispalliance.net> <5A6D953473350C4B9995546AFE9939EE0BC13980@RWC-EX1.corp.seven.com> <4D5308DF.9020400@pacific.net> Message-ID: <4D530C2F.5050003@ispalliance.net> On 2/9/2011 4:36 PM, Ken A wrote: > > > 10/8 is the management network on my cable modem. The cable modem > bridges your wan 'real' ip(s) through to your PC or router. At least > that's how Suddenlink does it here. The customer is normally 'locked > out' of the cable modem, unlike a dsl modem. The largest NATs are > presumably w/mobile carriers. I've never been behind NAT (except one I > controlled) on a consumer dsl or cable link in the US. > Ken > Agreed on the cable side (DOCSIS at least) but most of the DSL systems I've seen are doing NAT on virtually all of the end user gear. Bell South, SBC, Verizon, and Pac Bell are all doing or in the recent past did most/all of their DSL installs this way. Bell South tried using a brouter (only one I've seen in the wild) that did PPPoE on the WAN side and then handed out the same address it was assigned via DHCP on the LAN interface, but it was problematic (imagine that) and they stopped using it some years before the AT&T purchase/merger. The smaller telcos are almost universally doing NAT as well providers like Alltel, Centurytel, Frontier, Finepoint, as well as the smaller ILEC's simply don't do bridging on their CPE gear since they seldom had their DSLAMs set up to deal with Q-in-Q or isolation methods. That's not to say I don't know some that are the exception since I do know of a few telcos that run PPPoE clients on the client PC and a handful that did get port isolation working but they are not the norm in the US. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From joelja at bogus.com Wed Feb 9 16:08:49 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 09 Feb 2011 14:08:49 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> Message-ID: <4D531071.4030207@bogus.com> On 2/9/11 1:42 PM, Nathan Eisenberg wrote: >> Most IPv4 space is unused anyway, but it's not being reclaimed much >> despite that. (How many IP addresses does the US federal government >> need? Few people would think ~ 10 /8s. Especially since many of >> them aren't even lit up.) > > What do you mean, lit up? You mean they're not in the routing tables > that you get from your carriers? I'd argue that's no indication of > whether they're in use or not. Especially given that they're know to be in use. e.g. it's not a secret, they just don't appear in your internet. > > From owen at delong.com Wed Feb 9 16:06:40 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Feb 2011 14:06:40 -0800 Subject: IPv6 addressing for core network In-Reply-To: References: <49F6C292-C26D-41E6-953D-F7316D795237@muada.com> <20110209.104804.74661138.sthaug@nethelp.no> <93AA0E79-76BF-439C-BD37-05AEAA401BC9@spacething.org> <20110209.144552.74723697.sthaug@nethelp.no> Message-ID: On Feb 9, 2011, at 9:30 AM, David Freedman wrote: > I think the solution to all of these problems is really to use public > addressing but filter access to it at your edge (yes, even ICMP TOOBIG > can be filtered safely if you have designed things in a sane way) > Filtering ICMP TOOBIG is actually bad. No matter how sane your design is, you can't count on someone further down the road not having a smaller MTU (unless you're running a 1280 MTU). Owen From owen at delong.com Wed Feb 9 16:11:32 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Feb 2011 14:11:32 -0800 Subject: Too bigs are sacred, was: Re: IPv6 addressing for core network In-Reply-To: References: <49F6C292-C26D-41E6-953D-F7316D795237@muada.com> <20110209.104804.74661138.sthaug@nethelp.no> <93AA0E79-76BF-439C-BD37-05AEAA401BC9@spacething.org> <20110209.144552.74723697.sthaug@nethelp.no> <29708DA0-57F6-4AFD-B11A-ED5AD399FFF6@muada.com> Message-ID: <85C23ECB-3C90-42CF-9ACF-FD23CE58FAD0@delong.com> On Feb 9, 2011, at 9:50 AM, David Freedman wrote: > Iljitsch van Beijnum wrote: >> On 9 feb 2011, at 18:30, David Freedman wrote: >> >>> (yes, even ICMP TOOBIG >>> can be filtered safely if you have designed things in a sane way) >> >> NO. >> >> Even if you run with 1280-byte MTUs everywhere so you'd think path MTU discovery wouldn't be needed, this can still cause problems with IPv6-to-IPv4 translators. >> > > Calm down, I think you misunderstand, > > I'm suggesting that you don't design your infrastructure in such a way > that your backbone/infrastructure links ever have to receive TOOBIG > messages from outside your AS and work with these, your backbone links > are of course free to send TOOBIG out! > > Dave. > > -- > > > David Freedman > Group Network Engineering > Claranet Group > Unless every packet you emit is ? the minimum MTU (1280), then, you need to be able to receive TOOBIG messages. Owen From owen at delong.com Wed Feb 9 16:16:26 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Feb 2011 14:16:26 -0800 Subject: IPv6 - a noobs prespective In-Reply-To: References: Message-ID: <4ABCB63C-5527-44A0-B3E6-6A6E20043DDA@delong.com> On Feb 9, 2011, at 10:03 AM, William Herrin wrote: > On Wed, Feb 9, 2011 at 6:00 AM, Robert Lusby wrote: >> I also get why we need IPv6, that it means removing the NAT (which, surprise >> surprise also runs our Firewall), and I that I might need new kit for it. >> >> I am however *terrified* of making that move. There is so many new phrases, >> words, things to think about etc > > The thing that terrifies me about deploying IPv6 is that apps > compatible with both are programmed to attempt IPv6 before IPv4. This > means my first not-quite-correct IPv6 deployments are going to break > my apps that are used to not having and therefore not trying IPv6. But > that's not the worst part... as the folks my customers interact with > over the next couple of years make their first not-quite-correct IPv6 > deployments, my access to them is going to break again. And again. And > again. And I won't have the foggiest idea who's next until I get the > call that such-and-such isn't working right. Cower in fear and wait for the world to pass you by, or, move forward and get past it. The choice is yours. So far, I've had pretty minimal problems since deploying IPv6 on my stuff and none of the web sites I host have noticed any significant problems. Owen From owen at delong.com Wed Feb 9 16:22:21 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Feb 2011 14:22:21 -0800 Subject: IPv6 - a noobs prespective In-Reply-To: References: <4D52DB6E.9080009@brightok.net> Message-ID: <6BE7CFD2-8B36-41A2-9262-5EB926234F11@delong.com> There have been IPv6 for dummies sessions at many past NANOGs. If NANOG is willing to provide time and space for them at future events, I will be happy to conduct the tutorial sessions. Owen On Feb 9, 2011, at 10:30 AM, Mike Lyon wrote: > With the recent allocation of the last existing IPv4 /8s (which now kind of > puts pressure on going v6), it would be wonderful if at the next couple of > NANOGs if there could be an IPv6 for dummies session or two :) > > -Mike > > > On Wed, Feb 9, 2011 at 10:22 AM, Jack Bates wrote: > >> On 2/9/2011 12:03 PM, William Herrin wrote: >> >>> The thing that terrifies me about deploying IPv6 is that apps >>> compatible with both are programmed to attempt IPv6 before IPv4. This >>> means my first not-quite-correct IPv6 deployments are going to break >>> my apps that are used to not having and therefore not trying IPv6. But >>> that's not the worst part... as the folks my customers interact with >>> over the next couple of years make their first not-quite-correct IPv6 >>> deployments, my access to them is going to break again. And again. And >>> again. And I won't have the foggiest idea who's next until I get the >>> call that such-and-such isn't working right. >>> >> >> What scares me most is that every time I upgrade a router to support needed >> hardware or some badly needed IPv6 feature, something else breaks. Sometimes >> it's just the router crashes on a specific IPv6 command entered at CLI (C) >> or as nasty as NSR constantly crashing the slave (J); the fixes generally >> requiring me to upgrade again to the latest cutting edge releases which >> everyone hates (where I'm sure I'll find MORE bugs). >> >> The worst is when you're the first to find the bug(which I'm not even sure >> how it's possible given how simplistic my configs are, isis multitopology, >> iBGP, NSR, a few acls and route-maps/policies), it takes 3-6 months or so to >> track it down, and then it's put only in the next upcoming release (not out >> yet) and backported to the last release. >> >> >> Jack (hates all routers equally, doesn't matter who makes it) >> >> From owen at delong.com Wed Feb 9 16:32:51 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Feb 2011 14:32:51 -0800 Subject: Looking for an IPv6 naysayer... In-Reply-To: <4D52E59B.4070904@nic-naa.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E59B.4070904@nic-naa.net> Message-ID: <6E2D8385-77A1-4408-B12B-A7F61FDCC3EF@delong.com> On Feb 9, 2011, at 11:06 AM, Eric Brunner-Williams wrote: > well, i've argued new gtld registry operators in general do not benefit from a manditory v6 reachability requirement at transition to delegation, a position unpopular with v6 evangelicals and others who suppose that new gtld registry operators will exist to serve "the next billion users" rather than to offer alternate name space views to the existing {b,m}illions of v4 addressed spindles. > I disagree... I think that offering alternate name space views to the existing {b,m}illions of v4 addressed spindles requires IPv6 reachability as well since those will also be adding IPv6 capabilities in the next year or two. It's not that I think you only serve the future. It's that we think you are failing to recognize that IPv6 is now and that what is IPv4 today will be at least dual-stack tomorrow. > related, i've argue that new gtld registry operators in general do not benefit from a manditory dnssec requirement, a position unpopular with dnssec evangelicals and others who suppose that new gtld registry operators will exist to serve ecommerce with sufficient generality, persistence, and volume to make them more attractive targets for rational economic exploits than existing, unsigned zones. > > for those not keeping track, icann's laundry list of mandatory to implements includes v6 reachibility, and dnssec, shortly after the date of contract, so significantly prior to the operator acquiring operational experience, and of course, cctlds, and existing gtlds, are under no obligation to sign their zones. > The latter part of that paragraph is an unfortunate artifact of a pre-existing contract without those requirements. I would expect those requirements to be added at contract renewal. > i don't think of these positions as "naysaing" either v6 or dnssec, just the it-must-be-done-now claims of urgency and universality of some of the respective advocates for "sensible stuff", who because they hold the right opinion, inform icann's ssac. > I think that the requirements are reasonable and that it is unfortunate that they cannot be added to the existing GTLD contracts. Owen From jbates at brightok.net Wed Feb 9 16:37:12 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 09 Feb 2011 16:37:12 -0600 Subject: Looking for an IPv6 naysayer... In-Reply-To: <4D530C2F.5050003@ispalliance.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><4D52E942.5000607@ispalliance.net><87sjvxhu1v.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com> <8762stc5a7.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> <4D52FF60.1090102@ispalliance.net> <5A6D953473350C4B9995546AFE9939EE0BC13980@RWC-EX1.corp.seven.com> <4D5308DF.9020400@pacific.net> <4D530C2F.5050003@ispalliance.net> Message-ID: <4D531718.9090104@brightok.net> On 2/9/2011 3:50 PM, Scott Helms wrote: > The smaller telcos are almost universally doing NAT as well providers > like Alltel, Centurytel, Frontier, Finepoint, as well as the smaller > ILEC's simply don't do bridging on their CPE gear since they seldom had > their DSLAMs set up to deal with Q-in-Q or isolation methods. That's > not to say I don't know some that are the exception since I do know of a > few telcos that run PPPoE clients on the client PC and a handful that > did get port isolation working but they are not the norm in the US. Yeah, but CPE NAT with uPNP and other protocols is a far cry from LSN. Don't get me wrong, I love the fact that over 90% of my network is bridged (even have some cpe's bridging 802.11 in, which really through the vendors for a loop, but they did it). However, LSN doesn't have a lot of the capabilities that CPEs have for dealing with NAT breakage. Jack From ka at pacific.net Wed Feb 9 16:46:34 2011 From: ka at pacific.net (Ken A) Date: Wed, 09 Feb 2011 16:46:34 -0600 Subject: Looking for an IPv6 naysayer... In-Reply-To: <4D530C2F.5050003@ispalliance.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><4D52E942.5000607@ispalliance.net><87sjvxhu1v.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com> <8762stc5a7.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> <4D52FF60.1090102@ispalliance.net> <5A6D953473350C4B9995546AFE9939EE0BC13980@RWC-EX1.corp.seven.com> <4D5308DF.9020400@pacific.net> <4D530C2F.5050003@ispalliance.net> Message-ID: <4D53194A.80804@pacific.net> On 2/9/2011 3:50 PM, Scott Helms wrote: > On 2/9/2011 4:36 PM, Ken A wrote: >> >> >> 10/8 is the management network on my cable modem. The cable modem >> bridges your wan 'real' ip(s) through to your PC or router. At least >> that's how Suddenlink does it here. The customer is normally 'locked >> out' of the cable modem, unlike a dsl modem. The largest NATs are >> presumably w/mobile carriers. I've never been behind NAT (except one I >> controlled) on a consumer dsl or cable link in the US. >> Ken >> > > Agreed on the cable side (DOCSIS at least) but most of the DSL systems > I've seen are doing NAT on virtually all of the end user gear. End user gear = gear I control.. so I can 'make it work', poke holes where needed, no worries, 64k ports, etc. I thought we were talking about CGNAT taking over the world due to v4 scarcity. Ken Bell > South, SBC, Verizon, and Pac Bell are all doing or in the recent past > did most/all of their DSL installs this way. Bell South tried using a > brouter (only one I've seen in the wild) that did PPPoE on the WAN side > and then handed out the same address it was assigned via DHCP on the LAN > interface, but it was problematic (imagine that) and they stopped using > it some years before the AT&T purchase/merger. > > The smaller telcos are almost universally doing NAT as well providers > like Alltel, Centurytel, Frontier, Finepoint, as well as the smaller > ILEC's simply don't do bridging on their CPE gear since they seldom had > their DSLAMs set up to deal with Q-in-Q or isolation methods. That's not > to say I don't know some that are the exception since I do know of a few > telcos that run PPPoE clients on the client PC and a handful that did > get port isolation working but they are not the norm in the US. > -- Ken Anderson Pacific Internet - http://www.pacific.net From owen at delong.com Wed Feb 9 16:46:45 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Feb 2011 14:46:45 -0800 Subject: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> Message-ID: <07A419EF-649C-4FB6-9341-179AF49EE4A9@delong.com> Try looking for the expanded terms: Large Scale NAT Carrier Grade NAT NAT444 Owen On Feb 9, 2011, at 11:58 AM, david raistrick wrote: > On Wed, 9 Feb 2011, Scott Helms wrote: > >> For ISPs in this circumstance the choice will be CGNAT rather than IPv6 for a number of years because the cost is much lower and according to the vendors selling CGNAT solutions the impact to end users is (almost) unnoticeable. > > Anyone care to define CGNAT? Google results for this are either unrelated or "CGNAT will save us" or "CGNAT doesnt count" - no rfcs, no explainations, nothing.... > > > > -- > david raistrick http://www.netmeister.org/news/learn2quote.html > drais at icantclick.org http://www.expita.com/nomime.html > From owen at delong.com Wed Feb 9 16:48:06 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Feb 2011 14:48:06 -0800 Subject: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> Message-ID: <833804CE-80D9-4CED-8672-CF0870317E8C@delong.com> On Feb 9, 2011, at 12:00 PM, david raistrick wrote: > On Wed, 9 Feb 2011, Jens Link wrote: > >> Scott Helms writes: >> >>> IPv6 for some ISPs will be extraordinarily painful because of legacy >>> layer 2 gear >> >> I don't feel sorry for them. We know that IPv6 is coming for how long? >> 15years? 10year? 5years? Well if you only read the mainstream media you > > And at what point during that time did they have any vendor gear they could purchase that -would- support v6? At -best- during the last 5 years, but I'd put money on that even today they can't purchase gear with adequate v6 support. > This is largely the result of the fact that they did not demand it from their vendors during that time. Owen From khelms at ispalliance.net Wed Feb 9 16:55:14 2011 From: khelms at ispalliance.net (Scott Helms) Date: Wed, 09 Feb 2011 17:55:14 -0500 Subject: Looking for an IPv6 naysayer... In-Reply-To: <833804CE-80D9-4CED-8672-CF0870317E8C@delong.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> <833804CE-80D9-4CED-8672-CF0870317E8C@delong.com> Message-ID: <4D531B52.70404@ispalliance.net> On 2/9/2011 5:48 PM, Owen DeLong wrote: > On Feb 9, 2011, at 12:00 PM, david raistrick wrote: > >> On Wed, 9 Feb 2011, Jens Link wrote: >> >>> Scott Helms writes: >>> >>>> IPv6 for some ISPs will be extraordinarily painful because of legacy >>>> layer 2 gear >>> I don't feel sorry for them. We know that IPv6 is coming for how long? >>> 15years? 10year? 5years? Well if you only read the mainstream media you >> And at what point during that time did they have any vendor gear they could purchase that -would- support v6? At -best- during the last 5 years, but I'd put money on that even today they can't purchase gear with adequate v6 support. >> > This is largely the result of the fact that they did not demand it from their > vendors during that time. > > Owen > > > Absolutely, just as the ISPs didn't see demand, and don't today, from their users and thus the circle of blame is complete :) -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From sethm at rollernet.us Wed Feb 9 17:03:48 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 09 Feb 2011 15:03:48 -0800 Subject: Looking for an IPv6 naysayer... In-Reply-To: <4D531B52.70404@ispalliance.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> <833804CE-80D9-4CED-8672-CF0870317E8C@delong.com> <4D531B52.70404@ispalliance.net> Message-ID: <4D531D54.9030102@rollernet.us> On 2/9/2011 14:55, Scott Helms wrote: > Absolutely, just as the ISPs didn't see demand, and don't today, from > their users and thus the circle of blame is complete :) > And they never will. Their users demand "the internets", not a specific version of some protocol that users don't care about. ~Seth From brunner at nic-naa.net Wed Feb 9 17:08:53 2011 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Wed, 09 Feb 2011 18:08:53 -0500 Subject: Looking for an IPv6 naysayer... In-Reply-To: <6E2D8385-77A1-4408-B12B-A7F61FDCC3EF@delong.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E59B.4070904@nic-naa.net> <6E2D8385-77A1-4408-B12B-A7F61FDCC3EF@delong.com> Message-ID: <4D531E85.3000005@nic-naa.net> > I disagree... I think that offering alternate name space views to the existing {b,m}illions of v4 addressed spindles requires IPv6 reachability as well since those will also be adding IPv6 capabilities in the next year or two. so your claim is that to have a .cat, serving registrants currently using v4 provisioned hosting services, and end-users currently using v4 provisioned eyeball networks, and initially address and resources (but not names) currently extant in the com/net/org/biz/info namespaces [1], the .cat registry first has to be v6 reachable. and this claim is true because the webhosting operators, primarily in Catalonia, who have v4 now, will themselves be v6 reachable in the next year or two ... i think this requires either the existing hosting operators abandon vhosting as a service model or abandon their existing v4 allocations. now rinse and repeat for .nyc. the claim is somehow that the market for hosting operators (ok, the hosting lines of business of godaddy, tucows, enom, netsol, ... and their downstream resellers, which is statistically likely to have 51% of all .nyc registrations), and/or (your choice) the eyeball network operators for the tri-state area, are going to either abandon vhosting as a service model or abandon their existing v4 allocations ... where the v6 ab initio convinces me some is the area i currently work on -- developing economies. nigeria is a good example, fewer than 10^^5 computers, a population of 15x10^^7, and cell phone penetration rate approaching 1 in 3. even so, the number of v6 prefixes in afnic's inventory of allocations is ... very small ... for all of africa as a region. > It's not that I think you only serve the future. It's that we think you are failing to recognize that IPv6 is now > and that what is IPv4 today will be at least dual-stack tomorrow. if the window for applications opens 4 months after icann-41 (amman, jordan), in q42011, then delegations will occur as soon as q32012. is your claim that registry operators where v6 is _sparce_, and/or where v6 eyeball networks are _sparce_, two years from today, are properly failed for technical reasons, two years from today, for lack of v6 capability? if your claim is that v6 is mandatory to implement sometime soon, i'm fine with that rather flexible temporal requirement, but icann's current rules of the road are an application that isn't v6 ready at transition to delegation (roughly two years from now) fails. pessimally, the requirement is present at the date when applications are submitted, that is, a year from today. now there's still 24 months for icann legal staff to acquire clue, and for last week's press event to galvanize operators everywhere, so perhaps this (and its cognate, dnssec at transition to delegation) can be elided, but it is irresponsible to assert [2], independent of the purpose and position of a registry, that it must have a feature due to the universalist claims of advocates for a particular technology. thanks for your difference, -e [1] after four years of operation, more than half of the new .cat registrations are for names which do not exist in the cnobi (& .es) set of name spaces. [2] except for evangelicals who's job is to sell something. From drais at icantclick.org Wed Feb 9 17:16:43 2011 From: drais at icantclick.org (david raistrick) Date: Wed, 9 Feb 2011 18:16:43 -0500 (EST) Subject: Looking for an IPv6 naysayer... In-Reply-To: <833804CE-80D9-4CED-8672-CF0870317E8C@delong.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> <833804CE-80D9-4CED-8672-CF0870317E8C@delong.com> Message-ID: On Wed, 9 Feb 2011, Owen DeLong wrote: >>> I don't feel sorry for them. We know that IPv6 is coming for how long? >>> 15years? 10year? 5years? Well if you only read the mainstream media you >> >> And at what point during that time did they have any vendor gear they could purchase that -would- support v6? At -best- during the last 5 years, but I'd put money on that even today they can't purchase gear with adequate v6 support. >> > This is largely the result of the fact that they did not demand it from their > vendors during that time. I was purchasing for and building small SP networks during that time. Requiring v6 of our vendors would have meant we just never got anything, so we'd have never provided service. Come to think if it, maybe it -would- have been better for everyone involved (except those of us who just got paychecks and experience out of it) to just simply not do it - but we didn't know that at the time 15 years ago! Vendor C and J don't provide gear that fits into all network topologies (WISPs, MTU DSL, and smallish ADSL roll outs come to mind, certain during the time period in question. Sure, they eventually bought products in those markets...but even still, I had sub 6 figure budgets to build with - I certainly had no leverage). -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From owen at delong.com Wed Feb 9 17:21:31 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Feb 2011 15:21:31 -0800 Subject: Looking for an IPv6 naysayer... In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><4D52E942.5000607@ispalliance.net><87sjvxhu1v.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com> <8762stc5a7.fsf@oban.berlin.quux.de> <5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> Message-ID: On Feb 9, 2011, at 12:50 PM, George Bonser wrote: >> >> I never thought it was that bad. In some 3G/wireless networks in >> Germany >> the providers use NAT and transparent HTTP-proxy. But this is only >> wireless. I'm not aware of any DSL or Cable provider NATing their >> customers. >> >> Jens > > Practically all broadband providers NAT their customers in the US. If > you look at the largest ones which are probably Comcast, Verizon, and > AT&T, you have the majority of US broadband subscribers right there. > > No. Almost none of the broadband providers in the US NAT their customers. Most of them provide a single public IP address to their residential customers. Most broadband customers use their own NAT to extend that single public IP address from the provider to multiple addresses within the site. This is a very very different thing from LSN with a lot less breakage. Owen From david.freedman at uk.clara.net Wed Feb 9 17:26:46 2011 From: david.freedman at uk.clara.net (David Freedman) Date: Wed, 09 Feb 2011 23:26:46 +0000 Subject: Too bigs are sacred, was: Re: IPv6 addressing for core network In-Reply-To: <85C23ECB-3C90-42CF-9ACF-FD23CE58FAD0@delong.com> Message-ID: > Unless every packet you emit is ? the minimum MTU (1280), then, you need > to be able to receive TOOBIG messages. Can you think of a packet type I will emit from my publically numbered backbone interface which may solicit a TOOBIG that I'll have to care about? I can only think of three cases, all ICMP: 1. An unreachable of some kind (I don't care if this is delivered or not, and why would I be sending them from the backbone? Even rate-limited? If I send them at all this is the responsibility of the edge) 2. A Time Exceed, again, don't care if this is delivered or not 3. A TOOBIG, if I'm getting a TOOBIG in response to my TOOBIG then we all have bigger problems to worry about :) Dave. > > Owen > -- David Freedman Claranet http://www.clara.net From gbonser at seven.com Wed Feb 9 17:43:29 2011 From: gbonser at seven.com (George Bonser) Date: Wed, 9 Feb 2011 15:43:29 -0800 Subject: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><4D52E942.5000607@ispalliance.net><87sjvxhu1v.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com> <8762stc5a7.fsf@oban.berlin.quux.de> <5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC1399F@RWC-EX1.corp.seven.com> > Almost none of the broadband providers in the US NAT their customers. Well, I suppose I have been unlucky then because every single one I have had has NATed me. I had a "real" IP when I had dialup, but I got NAT when I went broadband. I have a friend that has another service and she is NATed too. Boot up in her network and you get 192.168.1.x From gbonser at seven.com Wed Feb 9 17:47:34 2011 From: gbonser at seven.com (George Bonser) Date: Wed, 9 Feb 2011 15:47:34 -0800 Subject: Looking for an IPv6 naysayer... In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC1399F@RWC-EX1.corp.seven.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><4D52E942.5000607@ispalliance.net><87sjvxhu1v.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com><8762stc5a7.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1399F@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC139A0@RWC-EX1.corp.seven.com> > > > Almost none of the broadband providers in the US NAT their customers. > > Well, I suppose I have been unlucky then because every single one I > have > had has NATed me. I had a "real" IP when I had dialup, but I got NAT > when I went broadband. I have a friend that has another service and > she > is NATed too. Boot up in her network and you get 192.168.1.x In other words, the broadband provider provides a single global IP to the "always up" CPE. That CPE does DHCP to user stations and hands out 1918 addresses and NATs them to the single global IP. I have had 3 broadband providers over the past 10 years, all three have done that. I have a friend on a fourth provider that also does that. I have yet to see a broadband provider that configures a network so that individual nodes in the home network get global IPs. From tshaw at oitc.com Wed Feb 9 17:48:39 2011 From: tshaw at oitc.com (TR Shaw) Date: Wed, 9 Feb 2011 18:48:39 -0500 Subject: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><4D52E942.5000607@ispalliance.net><87sjvxhu1v.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com> <8762stc5a7.fsf@oban.berlin.quux.de> <5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> Message-ID: <8E9D7F59-EB26-4DE4-91D9-FE81D03BBFB0@oitc.com> On Feb 9, 2011, at 6:21 PM, Owen DeLong wrote: > > On Feb 9, 2011, at 12:50 PM, George Bonser wrote: > >>> >>> I never thought it was that bad. In some 3G/wireless networks in >>> Germany >>> the providers use NAT and transparent HTTP-proxy. But this is only >>> wireless. I'm not aware of any DSL or Cable provider NATing their >>> customers. >>> >>> Jens >> >> Practically all broadband providers NAT their customers in the US. If >> you look at the largest ones which are probably Comcast, Verizon, and >> AT&T, you have the majority of US broadband subscribers right there. >> >> > No. > > Almost none of the broadband providers in the US NAT their customers. > > Most of them provide a single public IP address to their residential > customers. > > Most broadband customers use their own NAT to extend that single > public IP address from the provider to multiple addresses within > the site. > > This is a very very different thing from LSN with a lot less breakage. Owen This maybe true of all the big boys but I can tell you that rural telcos providing internet connectivity (personal experience in Northern MN) do and heavily. They may run fiber to the house but they do LSN big time. Tom From rs at seastrom.com Wed Feb 9 17:56:15 2011 From: rs at seastrom.com (Robert E. Seastrom) Date: Wed, 09 Feb 2011 18:56:15 -0500 Subject: Looking for an IPv6 naysayer... In-Reply-To: <4D52E942.5000607@ispalliance.net> (Scott Helms's message of "Wed, 09 Feb 2011 14:21:38 -0500") References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> Message-ID: <86lj1ohie8.fsf@seastrom.com> Scott Helms writes: > IPv6 for some ISPs will be extraordinarily painful because of legacy > layer 2 gear (usually DSLAMs that drop any frame with IPv6 in the > EtherType field), inability to upgrade customer gear efficiently > (again mainly a DSL problem where TR-069 isn't in use), and the > requirement to replace PPPoE/oA termination gear (like Redback SMSs) > means that a small telco (say 3000 DSL lines) could be facing a > multi-million dollar expense to enable IPv6 for customers. > > For ISPs in this circumstance the choice will be CGNAT rather than > IPv6 Or 6rd and go native on their permanent prefix as the forklift upgrade schedule allows. Oh well, it's better than nothing or Crummier Grade NAT. -r From jbates at brightok.net Wed Feb 9 18:00:19 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 09 Feb 2011 18:00:19 -0600 Subject: Looking for an IPv6 naysayer... In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC139A0@RWC-EX1.corp.seven.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><4D52E942.5000607@ispalliance.net><87sjvxhu1v.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com><8762stc5a7.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1399F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC139A0@RWC-EX1.corp.seven.com> Message-ID: <4D532A93.50504@brightok.net> On 2/9/2011 5:47 PM, George Bonser wrote: > I have yet to see a broadband provider that configures a network so that > individual nodes in the home network get global IPs. Bridge only CPE's given off this node. 1043 IP addresses handed out 1024 Unique interfaces Looks like customers aren't always big on more than 1 IP. :) Jack From marka at isc.org Wed Feb 9 18:00:45 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 10 Feb 2011 11:00:45 +1100 Subject: Looking for an IPv6 naysayer... In-Reply-To: Your message of "Wed, 09 Feb 2011 15:00:52 CDT." References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> Message-ID: <20110210000045.EA41D9DCA79@drugs.dv.isc.org> In message , david rai strick writes: > On Wed, 9 Feb 2011, Jens Link wrote: > > > Scott Helms writes: > > > >> IPv6 for some ISPs will be extraordinarily painful because of legacy > >> layer 2 gear > > > > I don't feel sorry for them. We know that IPv6 is coming for how long? > > 15years? 10year? 5years? Well if you only read the mainstream media you > > And at what point during that time did they have any vendor gear they > could purchase that -would- support v6? At -best- during the last 5 > years, but I'd put money on that even today they can't purchase gear with > adequate v6 support. And who's fault is that? The ISP's and the vendors. The ISP's could have been requesting IPv6 support. The ISP's could have been running trials and providing feedback to the vendors. The vendors could have asked the ISP's to trail their IPv6 products. We have been saying for years "make sure you are ready". That means buying and testing equipment. Lots of those that tested went on to production years ago. As a vendor we like feedback on our products, good or bad. It's hard to work in a vacuum. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jbates at brightok.net Wed Feb 9 18:01:46 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 09 Feb 2011 18:01:46 -0600 Subject: Looking for an IPv6 naysayer... In-Reply-To: <86lj1ohie8.fsf@seastrom.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> Message-ID: <4D532AEA.2090505@brightok.net> On 2/9/2011 5:56 PM, Robert E. Seastrom wrote: > Or 6rd and go native on their permanent prefix as the forklift upgrade > schedule allows. Oh well, it's better than nothing or Crummier Grade NAT. ds-lite tends to be friendlier LSN from various tests, and is native v6. Jack From marka at isc.org Wed Feb 9 18:07:26 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 10 Feb 2011 11:07:26 +1100 Subject: Looking for an IPv6 naysayer... In-Reply-To: Your message of "Wed, 09 Feb 2011 12:23:30 -0800." <5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com> Message-ID: <20110210000726.3CABE9DCC09@drugs.dv.isc.org> In message <5A6D953473350C4B9995546AFE9939EE0BC1397D at RWC-EX1.corp.seven.com>, " George Bonser" writes: > > Cost's might be lower but service will be worse. NAT breaks a lot of > > applications file sharing will not work properly and running your own > > web server at home will not work properly. Well you always get what > you > > pay for and people will buy any crap if it is cheap enough. > >=20 > > Jens > > While that is true, it is no worse than the situation right now. In the > US, the vast majority of users are already behind a NAT (I would say > over 90% of them are) so they are already experiencing this breakage. =20 But for the most part they can work around breakages with a single NAT. Double NAT prevents most of the work arounds working. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From joelja at bogus.com Wed Feb 9 18:08:10 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 09 Feb 2011 16:08:10 -0800 Subject: Looking for an IPv6 naysayer... In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC1399F@RWC-EX1.corp.seven.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><4D52E942.5000607@ispalliance.net><87sjvxhu1v.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com> <8762stc5a7.fsf@oban.berlin.quux.de> <5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1399F@RWC-EX1.corp.seven.com> Message-ID: <4D532C6A.20209@bogus.com> On 2/9/11 3:43 PM, George Bonser wrote: >> Almost none of the broadband providers in the US NAT their customers. > > Well, I suppose I have been unlucky then because every single one I have > had has NATed me. I had a "real" IP when I had dialup, but I got NAT > when I went broadband. I have a friend that has another service and she > is NATed too. Boot up in her network and you get 192.168.1.x The the cpe... In all likelihood it has a public ip on the outside. > > > From owen at delong.com Wed Feb 9 18:10:46 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Feb 2011 16:10:46 -0800 Subject: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> <833804CE-80D9-4CED-8672-CF0870317E8C@delong.com> Message-ID: <582356A9-5ADC-4244-8BA0-EE1F2F3EF388@delong.com> On Feb 9, 2011, at 3:16 PM, david raistrick wrote: > On Wed, 9 Feb 2011, Owen DeLong wrote: > >>>> I don't feel sorry for them. We know that IPv6 is coming for how long? >>>> 15years? 10year? 5years? Well if you only read the mainstream media you >>> >>> And at what point during that time did they have any vendor gear they could purchase that -would- support v6? At -best- during the last 5 years, but I'd put money on that even today they can't purchase gear with adequate v6 support. >>> >> This is largely the result of the fact that they did not demand it from their >> vendors during that time. > > > I was purchasing for and building small SP networks during that time. > > Requiring v6 of our vendors would have meant we just never got anything, so we'd have never provided service. Come to think if it, maybe it -would- have been better for everyone involved (except those of us who just got paychecks and experience out of it) to just simply not do it - but we didn't know that at the time 15 years ago! > Requiring it delivered day one, sure. Putting in a requirement for "Will support" so that they are required to provide an upgrade path, OTOH, to me seemed like it was basic good business sense. It worked out pretty well for the organizations I was working for back then. We got upgradeable hardware and the vendors got awareness of the demand. Admittedly, I wasn't working in the last mile arena. However, pressuring vendors is possible without sacrificing immediate needs. > > Vendor C and J don't provide gear that fits into all network topologies (WISPs, MTU DSL, and smallish ADSL roll outs come to mind, certain during the time period in question. Sure, they eventually bought products in those markets...but even still, I had sub 6 figure budgets to build with - I certainly had no leverage). > I don't think that networks with sub-6-figure buildouts are the ones we're too worried about right now. They can probably upgrade for sub-6-figure amounts. Owen From marka at isc.org Wed Feb 9 18:22:31 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 10 Feb 2011 11:22:31 +1100 Subject: Looking for an IPv6 naysayer... In-Reply-To: Your message of "Wed, 09 Feb 2011 17:55:14 CDT." <4D531B52.70404@ispalliance.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> <833804CE-80D9-4CED-8672-CF0870317E8C@delong.com><4D531B52.70404@ispalliance.net> Message-ID: <20110210002231.23F0E9DCFDD@drugs.dv.isc.org> In message <4D531B52.70404 at ispalliance.net>, Scott Helms writes: > On 2/9/2011 5:48 PM, Owen DeLong wrote: > > On Feb 9, 2011, at 12:00 PM, david raistrick wrote: > > > >> On Wed, 9 Feb 2011, Jens Link wrote: > >> > >>> Scott Helms writes: > >>> > >>>> IPv6 for some ISPs will be extraordinarily painful because of legacy > >>>> layer 2 gear > >>> I don't feel sorry for them. We know that IPv6 is coming for how long? > >>> 15years? 10year? 5years? Well if you only read the mainstream media you > >> And at what point during that time did they have any vendor gear they coul > d purchase that -would- support v6? At -best- during the last 5 years, but > I'd put money on that even today they can't purchase gear with adequate v6 su > pport. > >> > > This is largely the result of the fact that they did not demand it from the > ir > > vendors during that time. > > > > Owen > > > > > > > Absolutely, just as the ISPs didn't see demand, and don't today, from > their users and thus the circle of blame is complete :) And some of their customers have been asking for IPv6 all along. I started asking my ISP at home in 2003. I suspect if all the ISPs here were honest they would say that they have had a trickle of IPv6 requests for the last 8 years. Mark Date: Mon, 16 Jun 2003 09:54:05 +1000 To: Mark_Andrews at isc.org From: cablesupport at optusnet.com.au Subject: Re: [TT#6556559] HELPDESK Feedback Form - Mon Jun 16 09:52:50 2003 Return-Path: nobody at pts.optusnet.com.au Delivery-Date: Mon Jun 16 10:00:00 2003 Return-Path: X-Original-To: marka at farside.isc.org Delivered-To: marka at farside.isc.org X-Loop: pts Reply-To: cablesupport at optusnet.com.au Hello, Thank you for your email regarding the OptusNet Cable service. At the moment there are no plans for any IPv6 deployment, when this is due to happen we will notify all customers. Regards, Alex OptusNet Cable Technical Support -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From matthew at matthew.at Wed Feb 9 18:27:51 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 09 Feb 2011 16:27:51 -0800 Subject: Looking for an IPv6 naysayer... In-Reply-To: <4D532A93.50504@brightok.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><4D52E942.5000607@ispalliance.net><87sjvxhu1v.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com><8762stc5a7.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1399F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC139A0@RWC-EX1.corp.seven.com> <4D532A93.50504@brightok.net> Message-ID: <4D533107.5010202@matthew.at> On 2/9/2011 4:00 PM, Jack Bates wrote: > On 2/9/2011 5:47 PM, George Bonser wrote: >> I have yet to see a broadband provider that configures a network so that >> individual nodes in the home network get global IPs. > Bridge only CPE's given off this node. > > 1043 IP addresses handed out > 1024 Unique interfaces > > Looks like customers aren't always big on more than 1 IP. :) > > > Jack > > And meanwhile Comcast has announced one /64-per-household service for IPv6... guess they didn't get the memo from Owen about how every class of home appliances will need its own subnet. Matthew Kaufman From joelja at bogus.com Wed Feb 9 18:29:54 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 09 Feb 2011 16:29:54 -0800 Subject: IPv6 - a noobs prespective In-Reply-To: <6BE7CFD2-8B36-41A2-9262-5EB926234F11@delong.com> References: <4D52DB6E.9080009@brightok.net> <6BE7CFD2-8B36-41A2-9262-5EB926234F11@delong.com> Message-ID: <4D533182.6020505@bogus.com> On 2/9/11 2:22 PM, Owen DeLong wrote: > There have been IPv6 for dummies sessions at many past NANOGs. > > If NANOG is willing to provide time and space for them at future events, I will > be happy to conduct the tutorial sessions. program committee would no doubt love to hear from you. > Owen > > On Feb 9, 2011, at 10:30 AM, Mike Lyon wrote: > >> With the recent allocation of the last existing IPv4 /8s (which now kind of >> puts pressure on going v6), it would be wonderful if at the next couple of >> NANOGs if there could be an IPv6 for dummies session or two :) >> >> -Mike >> >> >> On Wed, Feb 9, 2011 at 10:22 AM, Jack Bates wrote: >> >>> On 2/9/2011 12:03 PM, William Herrin wrote: >>> >>>> The thing that terrifies me about deploying IPv6 is that apps >>>> compatible with both are programmed to attempt IPv6 before IPv4. This >>>> means my first not-quite-correct IPv6 deployments are going to break >>>> my apps that are used to not having and therefore not trying IPv6. But >>>> that's not the worst part... as the folks my customers interact with >>>> over the next couple of years make their first not-quite-correct IPv6 >>>> deployments, my access to them is going to break again. And again. And >>>> again. And I won't have the foggiest idea who's next until I get the >>>> call that such-and-such isn't working right. >>>> >>> >>> What scares me most is that every time I upgrade a router to support needed >>> hardware or some badly needed IPv6 feature, something else breaks. Sometimes >>> it's just the router crashes on a specific IPv6 command entered at CLI (C) >>> or as nasty as NSR constantly crashing the slave (J); the fixes generally >>> requiring me to upgrade again to the latest cutting edge releases which >>> everyone hates (where I'm sure I'll find MORE bugs). >>> >>> The worst is when you're the first to find the bug(which I'm not even sure >>> how it's possible given how simplistic my configs are, isis multitopology, >>> iBGP, NSR, a few acls and route-maps/policies), it takes 3-6 months or so to >>> track it down, and then it's put only in the next upcoming release (not out >>> yet) and backported to the last release. >>> >>> >>> Jack (hates all routers equally, doesn't matter who makes it) >>> >>> > > > From jbates at brightok.net Wed Feb 9 18:30:46 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 09 Feb 2011 18:30:46 -0600 Subject: Looking for an IPv6 naysayer... In-Reply-To: <4D533107.5010202@matthew.at> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><4D52E942.5000607@ispalliance.net><87sjvxhu1v.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com><8762stc5a7.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1399F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC139A0@RWC-EX1.corp.seven.com> <4D532A93.50504@brightok.net> <4D533107.5010202@matthew.at> Message-ID: <4D5331B6.60902@brightok.net> On 2/9/2011 6:27 PM, Matthew Kaufman wrote: > > And meanwhile Comcast has announced one /64-per-household service for > IPv6... guess they didn't get the memo from Owen about how every class > of home appliances will need its own subnet. I wonder if their RIR justification was for /64 to household or /48. :) Jack From jbates at brightok.net Wed Feb 9 18:32:16 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 09 Feb 2011 18:32:16 -0600 Subject: Looking for an IPv6 naysayer... In-Reply-To: <582356A9-5ADC-4244-8BA0-EE1F2F3EF388@delong.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> <833804CE-80D9-4CED-8672-CF0870317E8C@delong.com> <582356A9-5ADC-4244-8BA0-EE1F2F3EF388@delong.com> Message-ID: <4D533210.8080407@brightok.net> On 2/9/2011 6:10 PM, Owen DeLong wrote: > I don't think that networks with sub-6-figure buildouts are the ones we're too worried about right now. > They can probably upgrade for sub-6-figure amounts. sub-6-figure buildouts 15 years ago, is most likely over 6 figures today. 7 figures probably won't get you much out of C and J today. The small to middle guys are at the mercy of the large guys applying pressure to vendors. In addition, there's a lot of finger crossing that those large guys deploy something similar to your setup so the vendor will support that layout. I've had to re-engineer a lot of my networks for IPv6 support due to limited vendor support. You may not worry about my network (and I'll admit that I'm still worried about the core networks), but me and every other small to middle network has to worry about their own network. I know. I know. Forget us. All our users should just go to the big networks. :P Jack From owen at delong.com Wed Feb 9 18:42:01 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Feb 2011 16:42:01 -0800 Subject: Looking for an IPv6 naysayer... In-Reply-To: <4D533107.5010202@matthew.at> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><4D52E942.5000607@ispalliance.net><87sjvxhu1v.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com><8762stc5a7.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1399F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC139A0@RWC-EX1.corp.seven.com> <4D532A93.50504@brightok.net> <4D533107.5010202@matthew.at> Message-ID: <71648DBE-5FD0-4E73-8BC0-2CFA1686BA20@delong.com> On Feb 9, 2011, at 4:27 PM, Matthew Kaufman wrote: > On 2/9/2011 4:00 PM, Jack Bates wrote: >> On 2/9/2011 5:47 PM, George Bonser wrote: >>> I have yet to see a broadband provider that configures a network so that >>> individual nodes in the home network get global IPs. >> Bridge only CPE's given off this node. >> >> 1043 IP addresses handed out >> 1024 Unique interfaces >> >> Looks like customers aren't always big on more than 1 IP. :) >> >> >> Jack >> >> > And meanwhile Comcast has announced one /64-per-household service for IPv6... guess they didn't get the memo from Owen about how every class of home appliances will need its own subnet. > > Matthew Kaufman Actually Comcast is willing to give out more than a /64 to a home, they're waiting for the CPE to catch up. I've had some very good discussions with John Brzozowski on the subject. While we don't see completely eye-to-eye on the matter, I think that Comcast is trying to do reasonably well by their customers in the IPv6 addressing realm. I expect that they will eventually come around to giving out /48s, but, for now they seem to feel they need to see the use case develop before they deploy it. It's not ideal in my opinion, but, it's much better than it could be. FWIW, Comcast is transporting the /48 from my home nicely, even if they don't know they're doing it. Owen From jg at freedesktop.org Wed Feb 9 18:45:54 2011 From: jg at freedesktop.org (Jim Gettys) Date: Wed, 09 Feb 2011 19:45:54 -0500 Subject: Looking for an IPv6 naysayer... In-Reply-To: <4D533107.5010202@matthew.at> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><4D52E942.5000607@ispalliance.net><87sjvxhu1v.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com><8762stc5a7.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1399F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC139A0@RWC-EX1.corp.seven.com> <4D532A93.50504@brightok.net> <4D533107.5010202@matthew.at> Message-ID: <4D533542.9060204@freedesktop.org> On 02/09/2011 07:27 PM, Matthew Kaufman wrote: >> > And meanwhile Comcast has announced one /64-per-household service for > IPv6... guess they didn't get the memo from Owen about how every class > of home appliances will need its own subnet. > Huh? I don't think Comcast has stated what their plans on household allocation is. I merely noted (in response to a bogus claim that they'd be allocating *less* than a /64, that the current allocation in their 6rd trial, as observed by me, is a /64. - Jim From marka at isc.org Wed Feb 9 18:50:30 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 10 Feb 2011 11:50:30 +1100 Subject: Looking for an IPv6 naysayer... In-Reply-To: Your message of "Wed, 09 Feb 2011 15:47:34 -0800." <5A6D953473350C4B9995546AFE9939EE0BC139A0@RWC-EX1.corp.seven.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><4D52E942.5000607@ispalliance.net><87sjvxhu1v.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com><8762stc5a7.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1399F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC139A0@RWC-EX1.corp.seven.com> Message-ID: <20110210005030.59F739DD24B@drugs.dv.isc.org> In message <5A6D953473350C4B9995546AFE9939EE0BC139A0 at RWC-EX1.corp.seven.com>, " George Bonser" writes: > >=20 > > > Almost none of the broadband providers in the US NAT their > customers. > >=20 > > Well, I suppose I have been unlucky then because every single one I > > have > > had has NATed me. I had a "real" IP when I had dialup, but I got NAT > > when I went broadband. I have a friend that has another service and > > she > > is NATed too. Boot up in her network and you get 192.168.1.x > > In other words, the broadband provider provides a single global IP to > the "always up" CPE. That CPE does DHCP to user stations and hands out > 1918 addresses and NATs them to the single global IP. > > I have had 3 broadband providers over the past 10 years, all three have > done that. I have a friend on a fourth provider that also does that. > > I have yet to see a broadband provider that configures a network so that > individual nodes in the home network get global IPs. It's only because they delivered the service using a integrated modem/router to save the customer buying a seperate NAT box. I suspect that you could request a actual modem and connect you own equipment to if you want if you don't like the box they supplied. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jeffm at iglou.com Wed Feb 9 18:52:11 2011 From: jeffm at iglou.com (Jeff McAdams) Date: Wed, 09 Feb 2011 19:52:11 -0500 Subject: Looking for an IPv6 naysayer... In-Reply-To: <4D533210.8080407@brightok.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> <833804CE-80D9-4CED-8672-CF0870317E8C@delong.com> <582356A9-5ADC-4244-8BA0-EE1F2F3EF388@delong.com> <4D533210.8080407@brightok.net> Message-ID: <4D5336BB.8020602@iglou.com> On 02/09/2011 07:32 PM, Jack Bates wrote: > The small to middle guys are at the mercy of the large guys applying > pressure to vendors. I'm gonna just pick on this one thing. This just isn't true. I've always worked in small to middle sized shops, and I have always found that I've been able to yell and scream about IPv6 (and other features) loud enough, and long enough that I get heard by someone in a decision making position for product features (usually along the lines of a product manager or so). And every time I've made the effort to do that (admittedly, not a small effort), that product or line of product has had IPv6 available for it within about a year or so (if not sooner). Every single time. Were the big guys pushing as well? Perhaps, but I *know* that my voice gets heard when I put the effort into it. If you're not being heard by your vendor, you're not yelling loud enough. You're the customer, if your question/concern/request/demand about IPv6 gets blown off by your rep, talk to their boss, and keep demanding to talk to bosses until you get to someone that can give you a solid answer one way or the other, and if the answer is, "no, we won't support IPv6" run, don't walk, away from that vendor. It is absolutely doable, and I would argue that if you haven't reached this point in your purchasing decisions, you're being negligent. -- Jeff From marka at isc.org Wed Feb 9 19:01:15 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 10 Feb 2011 12:01:15 +1100 Subject: Looking for an IPv6 naysayer... In-Reply-To: Your message of "Wed, 09 Feb 2011 18:01:46 MDT." <4D532AEA.2090505@brightok.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com><4D532AEA.2090505@brightok.net> Message-ID: <20110210010116.0CB0F9DD351@drugs.dv.isc.org> In message <4D532AEA.2090505 at brightok.net>, Jack Bates writes: > On 2/9/2011 5:56 PM, Robert E. Seastrom wrote: > > Or 6rd and go native on their permanent prefix as the forklift upgrade > > schedule allows. Oh well, it's better than nothing or Crummier Grade NAT. > > ds-lite tends to be friendlier LSN from various tests, and is native v6. > > Jack DS-Lite over 6rd using RFC 1918 / multi-use ISP assigned block (I'd love to be able to say class E here) provides a single NAT translation for IPv4 and public IPv6. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From juicewvu at gmail.com Wed Feb 9 19:37:29 2011 From: juicewvu at gmail.com (Josh Smith) Date: Wed, 9 Feb 2011 20:37:29 -0500 Subject: Looking for an IPv6 naysayer... In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13982@RWC-EX1.corp.seven.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> <5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com> <8762stc5a7.fsf@oban.berlin.quux.de> <5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC13982@RWC-EX1.corp.seven.com> Message-ID: On Wed, Feb 9, 2011 at 4:18 PM, George Bonser wrote: >> Are you sure about that - I'm a comcast subscriber and see no signs >> that I am being natted? >> > > Josh, maybe it is different in different markets. ?When I had Comcast, I was behind a NAT. > > > George, Perhaps I misunderstood you - I am not behind any sort of large scale NAT, however my CPE, self supplied router (actually an old sun blade 100 running openbsd) does provide nat for the other devices on my home LAN. Thanks, Josh Smith KD8HRX email/jabber: juicewvu at gmail.com phone: 304.237.9369(c) From gbonser at seven.com Wed Feb 9 19:38:18 2011 From: gbonser at seven.com (George Bonser) Date: Wed, 9 Feb 2011 17:38:18 -0800 Subject: Looking for an IPv6 naysayer... In-Reply-To: <4D5336BB.8020602@iglou.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> <833804CE-80D9-4CED-8672-CF0870317E8C@delong.com> <582356A9-5ADC-4244-8BA0-EE1F2F3EF388@delong.com><4D533210.8080407@brightok.net> <4D5336BB.8020602@iglou.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC139AC@RWC-EX1.corp.seven.com> > If you're not being heard by your vendor, you're not yelling loud > enough. Or you aren't big enough of a customer. I was at one manufacturer within the past few months and asked about the lack of v6 support at layer 3 in one of their product lines as I had an application for that line but the lack of v6 layer 3 disqualified that solution. I was told that $HUGE_CUSTOMER had placed $HUGE_ORDER and was needing layer 2 features as their highest priority and so that is where they were focusing right now and that layer 3 ipv6 would be out later this year. They did say that it was getting more difficult to sell the gear without the layer 3 features and that the "real soon now" excuse was having trouble getting any traction with potential customers but right now the largest dollar amount of business hinged on layer 2 features. From marka at isc.org Wed Feb 9 19:44:10 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 10 Feb 2011 12:44:10 +1100 Subject: IPv6 - a noobs prespective In-Reply-To: Your message of "Wed, 09 Feb 2011 13:03:01 CDT." References: Message-ID: <20110210014410.9EF149DE681@drugs.dv.isc.org> In message , Will iam Herrin writes: > On Wed, Feb 9, 2011 at 6:00 AM, Robert Lusby wrote: > > I also get why we need IPv6, that it means removing the NAT (which, surpr= > ise > > surprise also runs our Firewall), and I that I might need new kit for it. > > > > I am however *terrified* of making that move. There is so many new phrase= > s, > > words, things to think about etc > > The thing that terrifies me about deploying IPv6 is that apps > compatible with both are programmed to attempt IPv6 before IPv4. This > means my first not-quite-correct IPv6 deployments are going to break > my apps that are used to not having and therefore not trying IPv6. But > that's not the worst part... as the folks my customers interact with > over the next couple of years make their first not-quite-correct IPv6 > deployments, my access to them is going to break again. And again. And > again. And I won't have the foggiest idea who's next until I get the > call that such-and-such isn't working right. > > Regards, > Bill Herrin Well complain to your app developers. They don't have to suck when part of the network breaks. http://www.isc.org/community/blog/201101/how-to-connect-to-a-multi-homed-server-over-tcp If you just make sure your IPv6 path works that's 99.999% of the problem solved even with buggy apps. Also most broken apps will just be slow not fail completely. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jeffm at iglou.com Wed Feb 9 19:49:50 2011 From: jeffm at iglou.com (Jeff McAdams) Date: Wed, 09 Feb 2011 20:49:50 -0500 Subject: Looking for an IPv6 naysayer... In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC139AC@RWC-EX1.corp.seven.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> <833804CE-80D9-4CED-8672-CF0870317E8C@delong.com> <582356A9-5ADC-4244-8BA0-EE1F2F3EF388@delong.com><4D533210.8080407@brightok.net> <4D5336BB.8020602@iglou.com> <5A6D953473350C4B9995546AFE9939EE0BC139AC@RWC-EX1.corp.seven.com> Message-ID: <4D53443E.8080206@iglou.com> On 02/09/2011 08:38 PM, George Bonser wrote: >> If you're not being heard by your vendor, you're not yelling loud >> enough. > Or you aren't big enough of a customer. I was at one manufacturer > within the past few months and asked about the lack of v6 support at > layer 3 in one of their product lines as I had an application for that > line but the lack of v6 layer 3 disqualified that solution. I was told > that $HUGE_CUSTOMER had placed $HUGE_ORDER and was needing layer 2 > features as their highest priority and so that is where they were > focusing right now and that layer 3 ipv6 would be out later this year. > They did say that it was getting more difficult to sell the gear without > the layer 3 features and that the "real soon now" excuse was having > trouble getting any traction with potential customers but right now the > largest dollar amount of business hinged on layer 2 features. That's at least an honest and significant answer. At that point, its up to you whether you're willing to wait. At this point, I'm not willing to, but 2 years ago, I probably would have. My main point is that, if you're getting answers like, "We don't hear any customers asking about it." then you need to push harder. I found its very easy to ask about IPv6, get that answer, and then ask again in 6 months and still get the same answer. My response then would be, ", I asked about it 6 months ago, you're just not paying attention, now get me a product manager on the phone so that I can bend their ear and make sure that I'm heard this time." -- Jeff From fredr at geexology.org Wed Feb 9 19:58:52 2011 From: fredr at geexology.org (Fred Richards) Date: Wed, 9 Feb 2011 20:58:52 -0500 Subject: IPv6 - a noobs prespective In-Reply-To: <217225.366.1297279069898.JavaMail.franck@franck-martins-macbook-pro.local> References: <217225.366.1297279069898.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: I completely agree with Franck. If you wanted to try a new acme thingamawidget on your network, what would you do? You'd probably isolate it onto its own vlan, and assign a subnet. Route that subnet, and then prevent access in either your L3 device or firewall if you didn't want it interfering with the rest of your network. If you were truly excited about the device, and wanted to try it out, you could set this up in no time. There would be nothing stopping you if you were motivated. So why is ipv6 any different? Personally, my plan is to create an ipv6 vlan and assign virtual nics to virtual machines. A machine is dual stack if it has a v4 nic and v6 nic. Use something like reflexive acls as a simple firewall, blocking inbound access to certain /64s. I'm already doing this at home and at work. They can coexist, without being fully "dual stack". You just have a ipv6 network layered on the same equipment you're using for the current ipv4 network. What is the network besides a tool for logical grouping and managed organization? IPv6 is just another piece of the overall toolset. I don't think it's practical to jump into ipv6 completely replacing ipv4, but rather they coexist for a while. Those prepared to support that scenario are going to be ahead of the curve. Someday ipv4 will seem like a joke, and our kids will laugh at us. On Wed, Feb 9, 2011 at 2:17 PM, Franck Martin wrote: > Don't think as IPv6 the same as IPv4. You do not need to have all your IPv4 gear to support IPv6. > > IPv6 is a separate network that runs on the same Ethernet wires as IPv4. > > You will see that a few of your machine, in fact do not support IPv6 and will not till the end of the year (think load balancers from a famous vendor), http://www.theipv6experts.net/2011/ipv6-ipv4/ > > Just build a separate IPv6 network, with firewall, routing gear, etc... that reaches the same machines on your network. The deployment of IPv6 at Google, was I think to put some separate IPv6 only customer facing machines. As the load on IPv6 is still small, then you can start by a small set (best is if you can have same machines do IPv4 and IPv6, but you are not obliged to think it, it is the same network). > > Why I don't recommend your servers to go IPv6 first, well get IPv6 to your engineers, the people that develop your applications and configure the servers, get them to be familiar with it, give them a sandbox, and then when everyone stop to run like headless chicken, plan your transition. > > ----- Original Message ----- > From: "William Herrin" > To: "Franck Martin" > Cc: nanog at nanog.org, "Robert Lusby" > Sent: Thursday, 10 February, 2011 7:37:31 AM > Subject: Re: IPv6 - a noobs prespective > > On Wed, Feb 9, 2011 at 1:19 PM, Franck Martin wrote: >> From: "William Herrin" >>> The thing that terrifies me about deploying IPv6 is that apps >>> compatible with both are programmed to attempt IPv6 before IPv4. >>> [...] is going to break again. And again. And again. >> >> This is dual stack, my recommendation is disable >> IPv6 on your servers (so your clients will still talk to >> them on IPv4 only), and let your client goes IPv6 first. >> Once you understand what is happening, get on IPv6 >> on your servers. > > That advice reminds me of a limerick I once heard: > > A host is a host > >From coast to coast > And nobody talks to a host that's close > Unless the host that isn't close > Is busy, hung or dead. > > Thanks, but it doesn't really speak to the problem I fear. > > > -- ? ? ? ? ? ? ? ? ? ? ? Fred From jj at diamondtech.ca Wed Feb 9 20:05:34 2011 From: jj at diamondtech.ca (Jeff Johnstone) Date: Wed, 9 Feb 2011 18:05:34 -0800 Subject: Looking for an IPv6 naysayer... In-Reply-To: <4D53443E.8080206@iglou.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> <833804CE-80D9-4CED-8672-CF0870317E8C@delong.com> <582356A9-5ADC-4244-8BA0-EE1F2F3EF388@delong.com> <4D533210.8080407@brightok.net> <4D5336BB.8020602@iglou.com> <5A6D953473350C4B9995546AFE9939EE0BC139AC@RWC-EX1.corp.seven.com> <4D53443E.8080206@iglou.com> Message-ID: On Wed, Feb 9, 2011 at 5:49 PM, Jeff McAdams wrote: > My response then would be, ", I asked about it 6 months ago, >> you're just not paying attention, now get me a product manager on the phone >> so that I can bend their ear and make sure that I'm heard this time." > > > -- > Jeff > > What I can't believe is that not one single $VENDOR_OF_CHOICE has realized the potential windfall that is NANOG. They have a captive audience here of 1,000's of the most influential technical people here who would I'm sure encourage any Vendor who came forward and said "WE WILL" to the IPV6/IPV4 situation. The depth of technical knowledge available here that could be utilized to develop a standard home CPE Unit or variations for example is huge. Not to mention the opportunity to become the "BigBlue" of the 20Teens. I still remember when it was "safe" for any IT career to go "BigBlue" no matter what technical situation you were in (If only I'd listened back then and stayed away from this Linux/Unix stuff). :) Ah well, back to trying to get my IPV6 working inside a NATed IPV4 only ISP (They will at least give you a real IPV4 IP if you wish to do you'r own NATing, default now is NAT from them). Cheers Jeff From jj at diamondtech.ca Wed Feb 9 20:07:58 2011 From: jj at diamondtech.ca (Jeff Johnstone) Date: Wed, 9 Feb 2011 18:07:58 -0800 Subject: Looking for an IPv6 naysayer... In-Reply-To: <4D53443E.8080206@iglou.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> <833804CE-80D9-4CED-8672-CF0870317E8C@delong.com> <582356A9-5ADC-4244-8BA0-EE1F2F3EF388@delong.com> <4D533210.8080407@brightok.net> <4D5336BB.8020602@iglou.com> <5A6D953473350C4B9995546AFE9939EE0BC139AC@RWC-EX1.corp.seven.com> <4D53443E.8080206@iglou.com> Message-ID: On Wed, Feb 9, 2011 at 5:49 PM, Jeff McAdams wrote: > My response then would be, ", I asked about it 6 months ago, >> you're just not paying attention, now get me a product manager on the phone >> so that I can bend their ear and make sure that I'm heard this time." > > > -- > Jeff > > What I can't believe is that not one single $VENDOR_OF_CHOICE has realized the potential windfall that is NANOG. They have a captive audience here of 1,000's of the most influential technical people here who would I'm sure encourage any Vendor who came forward and said "WE WILL" to the IPV6/IPV4 situation. The depth of technical knowledge available here that could be utilized to develop a standard home CPE Unit or variations for example is huge. Not to mention the opportunity to become the "BigBlue" of the 20Teens. I still remember when it was "safe" for any IT career to go "BigBlue" no matter what technical situation you were in (If only I'd listened back then and stayed away from this Linux/Unix stuff). :) Ah well, back to trying to get my IPV6 working inside a NATed IPV4 only ISP (They will at least give you a real IPV4 IP if you wish to do you'r own NATing, default now is NAT from them). Cheers Jeff From fredr at geexology.org Wed Feb 9 20:11:59 2011 From: fredr at geexology.org (Fred Richards) Date: Wed, 9 Feb 2011 21:11:59 -0500 Subject: Looking for an IPv6 naysayer... In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC139A0@RWC-EX1.corp.seven.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> <5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com> <8762stc5a7.fsf@oban.berlin.quux.de> <5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1399F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC139A0@RWC-EX1.corp.seven.com> Message-ID: On Wed, Feb 9, 2011 at 6:47 PM, George Bonser wrote: > I have yet to see a broadband provider that configures a network so that > individual nodes in the home network get global IPs. > One huge reason to adopt ipv6. -- ? ? ? ? ? ? ? ? ? ? ? Fred From fredr at geexology.org Wed Feb 9 20:16:57 2011 From: fredr at geexology.org (Fred Richards) Date: Wed, 9 Feb 2011 21:16:57 -0500 Subject: Top webhosters offering v6 too? In-Reply-To: <20110206221521.364F89B9C2B@drugs.dv.isc.org> References: <16975AA8-ABEB-402E-BA05-1BE51138A133@ecs.soton.ac.uk> <20110206221521.364F89B9C2B@drugs.dv.isc.org> Message-ID: On Sun, Feb 6, 2011 at 5:15 PM, Mark Andrews wrote: > > In message , Fred > ?Richards writes: >> I ran across this link a while back, it shows, of the top 100k >> websites (according to Alexa), which ones are IPv6 enabled: >> >> http://www.atoomnet.net/ipv6_enabled_popular_websites.php?complete_list=3Dt= >> rue > > And 1.5% of AAAA lookups, in the Alexa top 1000000, fail as the SOA > is in the wrong section or the wrong SOA is returned or timeout or > return NXDOMAIN when A returns a answer. ?GLB vendors have a lot > to answer for as almost all of these errors involve a GLB being > installed. ?Either their products are broken or their documentation > is so poor that people can't configure their boxes properly. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 ? ? ? ? ? ? ? ? INTERNET: marka at isc.org > Hey, maybe all we need is an analysis site which says "warning: your ipv6 is broken!". And give reasons ... point out misconfiguration like your examples above, regardless of whether it's dns or global load balancers. We'll see v6 adoption skyrocket overnight. ;) -- ? ? ? ? ? ? ? ? ? ? ? Fred From fredr at geexology.org Wed Feb 9 20:21:19 2011 From: fredr at geexology.org (Fred Richards) Date: Wed, 9 Feb 2011 21:21:19 -0500 Subject: Is your ASN advertising v6 prefixes? Message-ID: Mine is. Well? -- ? ? ? ? ? ? ? ? ? ? ? Fred From nathan at atlasnetworks.us Wed Feb 9 20:30:36 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Thu, 10 Feb 2011 02:30:36 +0000 Subject: Looking for an IPv6 naysayer... In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC139A0@RWC-EX1.corp.seven.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><4D52E942.5000607@ispalliance.net><87sjvxhu1v.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com><8762stc5a7.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1399F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC139A0@RWC-EX1.corp.seven.com> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B369BB8@ex-mb-1.corp.atlasnetworks.us> > I have yet to see a broadband provider that configures a network so > that > individual nodes in the home network get global IPs. On the residential properties that $EMPLOYER provides triple play to, the nodes behind each CPE can maintain up to 5 leases. And there are a few homes that actually use them - mostly homes that have webcams on them. But most homes go the overloaded NAT route and just translate different ports to different RFC1918 addresses... But at least in theory, what you're saying you haven't seen, is done up to some limit already at some ISPs. Nathan From franck at genius.com Wed Feb 9 20:35:15 2011 From: franck at genius.com (Franck Martin) Date: Thu, 10 Feb 2011 15:35:15 +1300 (FJST) Subject: IPv6 status In-Reply-To: <13983574.541.1297305276163.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <19043357.543.1297305313281.JavaMail.franck@franck-martins-macbook-pro.local> Looking at the recent exchange on the list re IPv6, it seems we are in the "whose fault is it?" ? Denial (this isn't happening to me!) ? Anger (why is this happening to me ?) ? Bargaining (I promise I'll be a better person if ...) ? Depression (I don't care anymore) ? Acceptance ( I'm ready for whatever comes) So I guess we progressed from last year which was denial! Can we move on with the program and get to the bargaining phase? From jbates at brightok.net Wed Feb 9 20:41:41 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 09 Feb 2011 20:41:41 -0600 Subject: Is your ASN advertising v6 prefixes? In-Reply-To: References: Message-ID: <4D535065.1050301@brightok.net> On 2/9/2011 8:21 PM, Fred Richards wrote: > Mine is. > Well? > http://www.cidr-report.org/cgi-bin/as-report?as=8025&view=2.0&v=6 Love that tool! Jack From franck at genius.com Wed Feb 9 20:55:35 2011 From: franck at genius.com (Franck Martin) Date: Thu, 10 Feb 2011 15:55:35 +1300 (FJST) Subject: Is your ASN advertising v6 prefixes? In-Reply-To: <4D535065.1050301@brightok.net> Message-ID: <13706182.547.1297306522641.JavaMail.franck@franck-martins-macbook-pro.local> I like that tool: http://bgp.he.net/AS55327 ----- Original Message ----- From: "Jack Bates" To: nanog at nanog.org Sent: Thursday, 10 February, 2011 3:41:41 PM Subject: Re: Is your ASN advertising v6 prefixes? On 2/9/2011 8:21 PM, Fred Richards wrote: > Mine is. > Well? > http://www.cidr-report.org/cgi-bin/as-report?as=8025&view=2.0&v=6 Love that tool! Jack From charles at knownelement.com Wed Feb 9 20:57:23 2011 From: charles at knownelement.com (Charles N Wyble) Date: Wed, 09 Feb 2011 18:57:23 -0800 Subject: IPv6 status In-Reply-To: <19043357.543.1297305313281.JavaMail.franck@franck-martins-macbook-pro.local> References: <19043357.543.1297305313281.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4D535413.4040909@knownelement.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/09/2011 06:35 PM, Franck Martin wrote: > Looking at the recent exchange on the list re IPv6, it seems we are in the "whose fault is it?" > > ? Denial (this isn't happening to me!) > ? Anger (why is this happening to me ?) > ? Bargaining (I promise I'll be a better person if ...) > ? Depression (I don't care anymore) > ? Acceptance ( I'm ready for whatever comes) > > So I guess we progressed from last year which was denial! > > Can we move on with the program and get to the bargaining phase? Isn't that CGNAT? :) - -- Charles N Wyble (charles at knownelement.com) Systems craftsman for the stars http://www.knownelement.com Mobile: 626 539 4344 Office: 310 929 8793 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNU1QNAAoJEMvvG/TyLEAtc8AP/3HJGd1kO+Ji+G5rjn3vzRrf qeCLtfRrW1lyHHnFGztOvbNvya8+aaWwsb20YISp2uVZwC3kLtBdkLExooUe2Rqw u5WgV2OuhNfK0/O2857YiKy+OHiANg48TPj0fohUjZB+RC3niSStm0c6bZZrvkjF bEgOg877h3i0IsVvOABWujx7rfyhJuP08dVyeSF5N52Rj+qVaJkf9/OMeWDcLyjF GihA2Bm2rNaqgHdORwJi944WrW2a7PwLoTgMKxtPWPOEQeLwv2NJYq8h+/NKrdWI XJ28KJegGC0MwUbFZEbnIjE9FRM2Q3tOmG3tvH3N67ShKEcls5P3XxFoOQgTxL+k /revVbVaNKmHHJt7CjNQTSv7q6EqQ2emY5ES2wGasS6BOyWsgWejISkbCEioPPHv kqWXE0OeCrmHUW0YxjcozlEUJLx1NnPmuOayoJyQKx1/xt56Fn9FwYH6Vt1Z7Bh5 2NALQviXOBMPkLTLuWVLgf1DUHC/dWRb0Rj5ZmTbQjnG7+7AvmddiseEMm/9vjZz 4MYYOO5B9HEC0VLdfBX62NyDM9HsN/WF0i/+jPgDadafVVpwcXm2qL0iOa2Q7f5E RPlpna4qhl8ZWWonVLMR/CEAeDDO+YaTqLHOf8zT9sQHgN+RDS2fEPjnr6vwzkDJ mXjPAkpwWV+SMh5jW8wL =tW4o -----END PGP SIGNATURE----- From franck at genius.com Wed Feb 9 21:02:12 2011 From: franck at genius.com (Franck Martin) Date: Thu, 10 Feb 2011 16:02:12 +1300 (FJST) Subject: IPv6 status In-Reply-To: <4D535413.4040909@knownelement.com> Message-ID: <1305542.551.1297306929563.JavaMail.franck@franck-martins-macbook-pro.local> ----- Original Message ----- > From: "Charles N Wyble" > To: nanog at nanog.org > Sent: Thursday, 10 February, 2011 3:57:23 PM > Subject: Re: IPv6 status > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 02/09/2011 06:35 PM, Franck Martin wrote: > > Looking at the recent exchange on the list re IPv6, it seems we are > > in the "whose fault is it?" > > > > ? Denial (this isn't happening to me!) > > ? Anger (why is this happening to me ?) > > ? Bargaining (I promise I'll be a better person if ...) > > ? Depression (I don't care anymore) > > ? Acceptance ( I'm ready for whatever comes) > > > > So I guess we progressed from last year which was denial! > > > > Can we move on with the program and get to the bargaining phase? > > Isn't that CGNAT? :) > I have a friend, each time someone tells him "our gear is carrier grade", he asks them "Is it that bad?" From owen at delong.com Wed Feb 9 21:32:21 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Feb 2011 19:32:21 -0800 Subject: Looking for an IPv6 naysayer... In-Reply-To: <4D531E85.3000005@nic-naa.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E59B.4070904@nic-naa.net> <6E2D8385-77A1-4408-B12B-A7F61FDCC3EF@delong.com> <4D531E85.3000005@nic-naa.net> Message-ID: <0CA94927-95DB-4C36-9B55-C891151729FB@delong.com> On Feb 9, 2011, at 3:08 PM, Eric Brunner-Williams wrote: >> I disagree... I think that offering alternate name space views to the existing {b,m}illions of v4 addressed spindles requires IPv6 reachability as well since those will also be adding IPv6 capabilities in the next year or two. > > so your claim is that to have a .cat, serving registrants currently using v4 provisioned hosting services, and end-users currently using v4 provisioned eyeball networks, and initially address and resources (but not names) currently extant in the com/net/org/biz/info namespaces [1], the .cat registry first has to be v6 reachable. > My claim is that about the time these zones are rolling out, the registrants currently using v4 provisioned hosting services and end users currently using v4 provisioned eyeball networks will also, at least in some cases, be using dual stack and/or v6 services. > and this claim is true because the webhosting operators, primarily in Catalonia, who have v4 now, will themselves be v6 reachable in the next year or two ... i think this requires either the existing hosting operators abandon vhosting as a service model or abandon their existing v4 allocations. > You do not have to abandon v4 to deploy v6. That's an absurd claim. > now rinse and repeat for .nyc. the claim is somehow that the market for hosting operators (ok, the hosting lines of business of godaddy, tucows, enom, netsol, ... and their downstream resellers, which is statistically likely to have 51% of all .nyc registrations), and/or (your choice) the eyeball network operators for the tri-state area, are going to either abandon vhosting as a service model or abandon their existing v4 allocations ... > Again, the need for v6 is not predicated on the abandonment of v4. > where the v6 ab initio convinces me some is the area i currently work on -- developing economies. nigeria is a good example, fewer than 10^^5 computers, a population of 15x10^^7, and cell phone penetration rate approaching 1 in 3. even so, the number of v6 prefixes in afnic's inventory of allocations is ... very small ... for all of africa as a region. > I believe AfriNIC has a /12 like any other RIR. I'm not sure what you are saying here. >> It's not that I think you only serve the future. It's that we think you are failing to recognize that IPv6 is now >> and that what is IPv4 today will be at least dual-stack tomorrow. > > if the window for applications opens 4 months after icann-41 (amman, jordan), in q42011, then delegations will occur as soon as q32012. > Yes. > is your claim that registry operators where v6 is _sparce_, and/or where v6 eyeball networks are _sparce_, two years from today, are properly failed for technical reasons, two years from today, for lack of v6 capability? > I'm not sure what you mean by _sparce_. My claim is that by 4q2012, I expect we will see much much wider IPv6 deployment and potentially eyeball networks that are primarily or exclusively IPv6 with at best limited or degraded IPv4 support through multiple layers of NAT. As such, I think that registries spinning up in 3q2012 should be required to have IPv6 support. yes. > if your claim is that v6 is mandatory to implement sometime soon, i'm fine with that rather flexible temporal requirement, but icann's current rules of the road are an application that isn't v6 ready at transition to delegation (roughly two years from now) fails. > If you define soon as prior to 2q2012, then, yes, I'm fine with that. However, that seems to be about a quarter earlier than you think these things will be starting up. Since you seem to be claiming they should get some period beyond that where they don't need to run IPv6 (I'm not sure where they're supposed to get their addresses to run on IPv4 by then, frankly), I think your definition of soon and mine are probably not compatible. > pessimally, the requirement is present at the date when applications are submitted, that is, a year from today. > I don't think that 1q2012 is especially out of line given a 2q2012 target date. > now there's still 24 months for icann legal staff to acquire clue, and for last week's press event to galvanize operators everywhere, so perhaps this (and its cognate, dnssec at transition to delegation) can be elided, but it is irresponsible to assert [2], independent of the purpose and position of a registry, that it must have a feature due to the universalist claims of advocates for a particular technology. > I think it is irresponsible at this point to consider deploying any major network infrastructure without requiring IPv6 capabilities at deployment. IANA is already out of IPv4. If you expect these systems to start getting deployed in 3q2012, then, you're talking about a time which is likely to be well past RIR exhaustion in most cases. I suppose they can get a /22 from APNIC, but, other than that, where do you expect these organizations to even get IPv4 to work with? > thanks for your difference, > -e > Any time. Owen From mpetach at netflight.com Wed Feb 9 22:14:17 2011 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 9 Feb 2011 20:14:17 -0800 Subject: Is your ASN advertising v6 prefixes? In-Reply-To: References: Message-ID: On Wed, Feb 9, 2011 at 6:21 PM, Fred Richards wrote: > Mine is. > Well? > > -- > ? ? ? ? ? ? ? ? ? ? ? Fred > eh...not many. http://bgp.he.net/AS10310 From mpetach at netflight.com Wed Feb 9 22:17:01 2011 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 9 Feb 2011 20:17:01 -0800 Subject: IPv6 status In-Reply-To: <19043357.543.1297305313281.JavaMail.franck@franck-martins-macbook-pro.local> References: <13983574.541.1297305276163.JavaMail.franck@franck-martins-macbook-pro.local> <19043357.543.1297305313281.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On Wed, Feb 9, 2011 at 6:35 PM, Franck Martin wrote: > Looking at the recent exchange on the list re IPv6, it seems we are in the "whose fault is it?" ... > Can we move on with the program and get to the bargaining phase? Bargaining? I'll trade you a v6 /32 for a v4 /16... ;-P Matt From vixie at isc.org Wed Feb 9 22:17:33 2011 From: vixie at isc.org (Paul Vixie) Date: Thu, 10 Feb 2011 04:17:33 +0000 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <849FDB3F-EE29-48D6-8ECD-70AE6EB0B157@virtualized.org> (David Conrad's message of "Sat, 5 Feb 2011 20:25:04 -1000") References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <20110205193328.GC22325@vacation.karoshi.com> <08F8827D-D8C3-4922-AC39-6C71ADBE8BDB@corp.arin.net> <20110206014014.GG22325@vacation.karoshi.com> <849FDB3F-EE29-48D6-8ECD-70AE6EB0B157@virtualized.org> Message-ID: <71571.1297311453@nsa.vix.com> David Conrad writes: > I'm curious: when HP acquired the assets of Compaq (or when Compaq > acquired the assets of Digital), is it your position that HP (or Compaq) > "met the same criteria as if they were requesting an IP address directly > from the IR." for 16.0.0.0/8? since i was the guy to do the initial carving on 16.0.0.0/8 i pondered this at the time of the CPQ and HP acquisitions. my research revealed that the network that DEC had numbered using 16.0.0.0/8 was still in existence and had been part of the acquisition process. there's an interesting question as to whether the acquirer should have had to renumber, since the acquirer had their own /8 and probably had the ability to contain both the old and new networks in the same /8. there's another interesting question as to whether either DEC or HP could have qualified for a /8 under current rules, since the basis for these (pre-RIR) allocations was that they needed more than a /16 and these were the days before CIDR. (at the time i received the /8 allocation at DEC, we had a half dozen /16's several dozen /24's that we wanted to stop using because we worried about the size of the global routing table... what whacky kids we all were. hint: i had hair back then.) -- Paul Vixie KI6YSY From charles at knownelement.com Wed Feb 9 22:42:46 2011 From: charles at knownelement.com (Charles N Wyble) Date: Wed, 09 Feb 2011 20:42:46 -0800 Subject: Top webhosters offering v6 too? In-Reply-To: References: <16975AA8-ABEB-402E-BA05-1BE51138A133@ecs.soton.ac.uk> <20110206221521.364F89B9C2B@drugs.dv.isc.org> Message-ID: <4D536CC6.1030204@knownelement.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/09/2011 06:16 PM, Fred Richards wrote: > On Sun, Feb 6, 2011 at 5:15 PM, Mark Andrews wrote: >> >> In message , Fred >> Richards writes: >>> I ran across this link a while back, it shows, of the top 100k >>> websites (according to Alexa), which ones are IPv6 enabled: >>> >>> http://www.atoomnet.net/ipv6_enabled_popular_websites.php?complete_list=3Dt= >>> rue >> >> And 1.5% of AAAA lookups, in the Alexa top 1000000, fail as the SOA >> is in the wrong section or the wrong SOA is returned or timeout or >> return NXDOMAIN when A returns a answer. GLB vendors have a lot >> to answer for as almost all of these errors involve a GLB being >> installed. Either their products are broken or their documentation >> is so poor that people can't configure their boxes properly. >> >> Mark >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org >> > > Hey, maybe all we need is an analysis site which says "warning: your > ipv6 is broken!". And give reasons ... point out misconfiguration > like your examples above, regardless of whether it's dns or global > load balancers. We'll see v6 adoption skyrocket overnight. ;) http://test-ipv6.com/ is a good start for basic sanity checks. I need to get my v6 content provider stuff done and write up a blog post and/or do a presentation. Soon.... - -- Charles N Wyble (charles at knownelement.com) Systems craftsman for the stars http://www.knownelement.com Mobile: 626 539 4344 Office: 310 929 8793 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNU2zGAAoJEMvvG/TyLEAtteYQAMGr6P0zmW5or0rYUfAh4cVk xVvH7x6SvcvygKZArM9BYqYaOo8qvD1yQ11tKn4/OUaNynwE24kF1w03KUbftf+v jmg1jN6cS2rTKIJr9esf4RD0z2Y9r1TO/lp6r0hz7QAfAnqwfek7C6Wr8U8QDp35 QdTly/tZbAnCegCOW4KDMGnjusqzK1zl5OU3N546X6NI5JXaqrw8iEZVbMMF61B1 2XCK03DRVAqiASN1wA274DWy641pPDy/W40a2jMU2+TvfgnQQN5eLgdiRmm9b4BA Zyt6fquBLDOpD8/PzIlgWMZS/PVmeo9lDXl5c09cOsGs+ryDTCCcniEiv9uaMBVs t0/BVmLh87Srqxcjt6BL/dHl0msJX3AEhsZObMp9zjtmGKJ1boBMeXIuOYuag7C7 nyPLa3WOIw8j+zdeux2aJc8VQ6f00gUg4L716m36yApig/DfsiAAD4+drDEsqkJh NeYO3zLo++91b//a/UmK+a/HiNcwjw0/1rOaO9n/+6HAW2YNl55LoeWNn7dpCo5U iBwou+RRz0w/YvnEB+FiysDier4/iS+cRxiV0X1g+RGtbQ3+BgnQmxSBxbshsijw h9A22uwsjmcoU8Ns6OunJpVMG+epE0ohq5ynejqjwi0aJ7Ck/v7lzHjU1h6zCbFd e+8t3cGc9at795oLSulP =5vQz -----END PGP SIGNATURE----- From jfbeam at gmail.com Wed Feb 9 23:10:52 2011 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 10 Feb 2011 00:10:52 -0500 Subject: Looking for an IPv6 naysayer... In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC139A0@RWC-EX1.corp.seven.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> <5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com> <8762stc5a7.fsf@oban.berlin.quux.de> <5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1399F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC139A0@RWC-EX1.corp.seven.com> Message-ID: On Wed, 09 Feb 2011 18:47:34 -0500, George Bonser wrote: > In other words, the broadband provider provides a single global IP to > the "always up" CPE. That CPE does DHCP to user stations and hands out > 1918 addresses and NATs them to the single global IP. Correct. The distinction you seem unware of (or unwilling to accept) is that the ISP did not assign you a private address. Your CPE did. The ISP gave you a single public IPv4 address. With the notable exception of Uverse, you can put that address on any device you want. But you only have the one public address, so you'll have to resort to NAT inside your network to support more than one machine. (DSL and cable modems can be set to pure bridged mode, thus turning off their routing/NAT engine. You cannot do that with Uverse due to their authentication method.) This is *very* different from the ISP doing the NAT... one device doing NAT for thousands of customers, vs. a device in the customer's hands doing the NAT. > I have yet to see a broadband provider that configures a network so that > individual nodes in the home network get global IPs. Open your eyes. Many cable networks will sell you access to more than one address -- TW (RR) has done this for over a decade. AT&T Uverse will provide a /29 for free. --Ricky From jfbeam at gmail.com Wed Feb 9 23:15:52 2011 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 10 Feb 2011 00:15:52 -0500 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> Message-ID: On Wed, 09 Feb 2011 16:42:14 -0500, Nathan Eisenberg wrote: > What do you mean, lit up? You mean they're not in the routing tables > that you get from your carriers? I'd argue that's no indication of > whether they're in use or not. That's pretty much the definition of "in use". If they don't appear in the global routing table, then they aren't being used. I cannot send traffic to them; they cannot send traffic to me. In my recent probe of route servers, I found 22 legacy /8's that were partly or completely unused. I'm a little surprised ARIN/ICANN thinks it's a waste of time to even try to reclaim them. --Ricky From ios.run at gmail.com Wed Feb 9 23:45:28 2011 From: ios.run at gmail.com (Raul Rodriguez) Date: Wed, 9 Feb 2011 21:45:28 -0800 Subject: Is your ASN advertising v6 prefixes? In-Reply-To: References: Message-ID: http://www.ris.ripe.net/mt/asdashboard.html?as=26773 >From http://lg.retn.net/ inet6.0: 4536 destinations, 6600 routes (4536 active, 0 holddown, 0 hidden) Restart Complete + = Active Route, - = Last Active, * = Both A Destination P Prf Metric 1 Metric 2 Next hop AS path * 2607:f508::/32 B 170 100 100 >87.245.233.22 26773 I >From RouteViews route-views>sh ip bgp ipv6 unicast regexp _26773_ BGP table version is 11676900, local router ID is 128.223.51.103 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * 2607:F508::/32 2001:B08:2:280::4:100 0 3277 3267 2603 6939 26773 i *> 2001:470:0:1A::1 0 6939 26773 i * 2001:418:0:1000::F016 5 0 2914 6939 26773 i * 2001:1860::223 0 101 101 6939 26773 i * 2001:388:1::16 0 7575 6939 26773 i * 90E4:F182:5022:14D0:4AB6:86B8:8:50 0 1239 6939 26773 i * 2001:918:0:5::1 0 3303 6939 26773 i * 2001:590::451F:6FF4 0 0 4436 6939 26773 i * 2001:388:1::13 0 7575 6939 26773 i * 2001:468:D01:FD::A Network Next Hop Metric LocPrf Weight Path 0 3582 4600 11537 11164 6939 26773 i route-views> -RR <--Always up for IPv6 peering at LAIIX and Any2/LAX On Wed, Feb 9, 2011 at 6:21 PM, Fred Richards wrote: > Mine is. > Well? > > -- > ? ? ? ? ? ? ? ? ? ? ? Fred > From gbonser at seven.com Wed Feb 9 23:51:28 2011 From: gbonser at seven.com (George Bonser) Date: Wed, 9 Feb 2011 21:51:28 -0800 Subject: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> <5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com> <8762stc5a7.fsf@oban.berlin.quux.de> <5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1399F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC139A0@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC139C3@RWC-EX1.corp.seven.com> > > On Wed, 09 Feb 2011 18:47:34 -0500, George Bonser > wrote: > > In other words, the broadband provider provides a single global IP to > > the "always up" CPE. That CPE does DHCP to user stations and hands > out > > 1918 addresses and NATs them to the single global IP. > > Correct. The distinction you seem unware of (or unwilling to accept) > is > that the ISP did not assign you a private address. Your CPE did. The > ISP > gave you a single public IPv4 address. > --Ricky My comment was addressed to a poster from Europe who seemed surprised that there were home users behind a NAT at all. From jfesler at gigo.com Wed Feb 9 23:56:26 2011 From: jfesler at gigo.com (Jason Fesler) Date: Wed, 9 Feb 2011 21:56:26 -0800 (PST) Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> Message-ID: > In my recent probe of route servers, I found 22 legacy /8's that were partly > or completely unused. I'm a little surprised ARIN/ICANN thinks it's a waste > of time to even try to reclaim them. How long would that be tied up in legal issues before they were freed? From marka at isc.org Thu Feb 10 00:09:19 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 10 Feb 2011 17:09:19 +1100 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: Your message of "Wed, 09 Feb 2011 21:56:26 -0800." References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> Message-ID: <20110210060919.F1DEE9E0AB7@drugs.dv.isc.org> In message , Jason Fesler wri tes: > > In my recent probe of route servers, I found 22 legacy /8's that were partly > > > or completely unused. I'm a little surprised ARIN/ICANN thinks it's a waste > > > of time to even try to reclaim them. Because it is a waste of time and money. > How long would that be tied up in legal issues before they were freed? > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From frnkblk at iname.com Thu Feb 10 00:10:35 2011 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 10 Feb 2011 00:10:35 -0600 Subject: My upstream ISP does not support IPv6 In-Reply-To: <4607E2A3-6C20-4FCF-A842-37497C5558B9@consultant.com> References: <18699589.266.1296788654238.JavaMail.franck@franck-martins-macbook-pro.local> <4D50779E.40804@ispn.net> <4607E2A3-6C20-4FCF-A842-37497C5558B9@consultant.com> Message-ID: <018201cbc8e9$3b641120$b22c3360$@iname.com> I'm not sure what you mean -- once the ISP identifies CPE that works on their network, couldn't early adopters who are interested in the technology be pointed to a short list? Frank -----Original Message----- From: Cutler James R [mailto:james.cutler at consultant.com] Sent: Monday, February 07, 2011 5:00 PM To: NANOG list Subject: Re: My upstream ISP does not support IPv6 All this talk about CPE is wasted until folks like ATT have someone on the retail interface (store, phone, or, web) who even knows what is this "IPv6" thing. Exploring this issue with DSL providers and Uverse is like that old exercise with combat boots. It feels much better when I stop. James R. Cutler james.cutler at consultant.com My ISP can't answer the question. From owen at delong.com Thu Feb 10 00:26:00 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Feb 2011 22:26:00 -0800 Subject: My upstream ISP does not support IPv6 In-Reply-To: <018201cbc8e9$3b641120$b22c3360$@iname.com> References: <18699589.266.1296788654238.JavaMail.franck@franck-martins-macbook-pro.local> <4D50779E.40804@ispn.net> <4607E2A3-6C20-4FCF-A842-37497C5558B9@consultant.com> <018201cbc8e9$3b641120$b22c3360$@iname.com> Message-ID: <474CF0FC-1A42-4141-87A2-CDAD566AF8E1@delong.com> The problem is conversations like this: AT&T Customer Service: "AT&T uVerse, how can I help you?" Customer: "Yes, I have uVerse service and I'd like to get IPv6." AT&T Customer Service: "I pea vee what? Is this a prank call?" Owen On Feb 9, 2011, at 10:10 PM, Frank Bulk wrote: > I'm not sure what you mean -- once the ISP identifies CPE that works on > their network, couldn't early adopters who are interested in the technology > be pointed to a short list? > > Frank > > -----Original Message----- > From: Cutler James R [mailto:james.cutler at consultant.com] > Sent: Monday, February 07, 2011 5:00 PM > To: NANOG list > Subject: Re: My upstream ISP does not support IPv6 > > All this talk about CPE is wasted until folks like ATT have someone on the > retail interface (store, phone, or, web) who even knows what is this "IPv6" > thing. Exploring this issue with DSL providers and Uverse is like that old > exercise with combat boots. It feels much better when I stop. > > James R. Cutler > james.cutler at consultant.com > > My ISP can't answer the question. > > From mmc at internode.com.au Thu Feb 10 00:35:42 2011 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Thu, 10 Feb 2011 06:35:42 +0000 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <20110210060919.F1DEE9E0AB7@drugs.dv.isc.org> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <20110210060919.F1DEE9E0AB7@drugs.dv.isc.org> Message-ID: <8FAA4ED3-4AB6-431D-8635-7A3C10C3E586@internode.com.au> On 10/02/2011, at 4:39 PM, Mark Andrews wrote: > > In message , Jason Fesler wri > tes: >>> In my recent probe of route servers, I found 22 legacy /8's that were partly >> >>> or completely unused. I'm a little surprised ARIN/ICANN thinks it's a waste >> >>> of time to even try to reclaim them. > > Because it is a waste of time and money. That's an assertion I've heard, but has anyone quantified it? How much time and money would it take? Has anyone just asked the 22 /8 holders mentioned above nicely if they might just like to give them back for some good publicity? You know, US DoD migrates to IPv6 and returns X /8s for the good of the American people (assume ARIN) so that broadband might continue to grow and thrive in the land of the free? MMC From surfer at mauigateway.com Thu Feb 10 00:37:24 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 9 Feb 2011 22:37:24 -0800 Subject: Is your ASN advertising v6 prefixes? Message-ID: <20110209223724.F4602E77@resin17.mta.everyone.net> --- ios.run at gmail.com wrote: From: Raul Rodriguez http://www.ris.ripe.net/mt/asdashboard.html?as=26773 -------------------------------------------------- http://www.ris.ripe.net/mt/no_cookies.html?success_args=as;success_args=26773;success_url=%2Fmt%2Fasdashboard.html "Please turn on the cookies on your browser to view this site. " No, fix your site or I go elsewhere. scott From surfer at mauigateway.com Thu Feb 10 00:42:41 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 9 Feb 2011 22:42:41 -0800 Subject: Is your ASN advertising v6 prefixes? Message-ID: <20110209224241.F4602F9C@resin17.mta.everyone.net> --- mpetach at netflight.com wrote: From: Matthew Petach On Wed, Feb 9, 2011 at 6:21 PM, Fred Richards wrote: > Mine is. eh...not many. http://bgp.he.net/AS10310 ---------------------------------------- Prefixes Originated (v6): 4 Why 4? scott From jbates at brightok.net Thu Feb 10 00:53:34 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 10 Feb 2011 00:53:34 -0600 Subject: Is your ASN advertising v6 prefixes? In-Reply-To: <20110209223724.F4602E77@resin17.mta.everyone.net> References: <20110209223724.F4602E77@resin17.mta.everyone.net> Message-ID: <4D538B6E.8000408@brightok.net> On 2/10/2011 12:37 AM, Scott Weeks wrote: > No, fix your site or I go elsewhere. I'm pretty sure if it's between their use of session cookies (RIPE_NCC_DB_SESSION) and you going elsewhere, they'll stick with using the session cookies for the database. They could be a little less sloppy, though. I mean RIPE_COOKIE_TEST? Really? And some of the graphs don't seem to be working right with FF (get a pretty display of them all and then they vanish and can't find them in the various menus). Jack From jbates at brightok.net Thu Feb 10 00:55:35 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 10 Feb 2011 00:55:35 -0600 Subject: Is your ASN advertising v6 prefixes? In-Reply-To: <20110209224241.F4602F9C@resin17.mta.everyone.net> References: <20110209224241.F4602F9C@resin17.mta.everyone.net> Message-ID: <4D538BE7.40208@brightok.net> On 2/10/2011 12:42 AM, Scott Weeks wrote: > > Prefixes Originated (v6): 4 > > > Why 4? > Click on the v6 prefixes tab and look at them. There's a US, Taiwan and Europe /32's, and then one additional /48 out of the US /32. Jack From mysidia at gmail.com Thu Feb 10 01:13:49 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 10 Feb 2011 01:13:49 -0600 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <71571.1297311453@nsa.vix.com> References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <20110205193328.GC22325@vacation.karoshi.com> <08F8827D-D8C3-4922-AC39-6C71ADBE8BDB@corp.arin.net> <20110206014014.GG22325@vacation.karoshi.com> <849FDB3F-EE29-48D6-8ECD-70AE6EB0B157@virtualized.org> <71571.1297311453@nsa.vix.com> Message-ID: On Wed, Feb 9, 2011 at 10:17 PM, Paul Vixie wrote: > David Conrad writes: > whether either DEC or HP could have qualified for a /8 under current rules, > since the basis for these (pre-RIR) allocations was that they needed more > than a /16 and these were the days before CIDR. ?(at the time i received > the /8 allocation at DEC, we had a half dozen /16's several dozen /24's that With them not requiring a /8 in the first place (after CIDR); one begins to wonder how much of their /8 allocations they actually touched in any meaningful way. Perhaps the RIRs should personally and directly ask each /8 legacy holder to provide account of their utilization (which portions of the allocation is used, how many hosts), and ASK for each unused /22 [or shorter] to be returned. The legacy holders might (or might not) refuse. They might (or might not) tell the RIRs "Hell no" In any case, the registry should ASK and publish an indication for each legacy /8 at least. So the community will know which (if any) legacy /8 holders are likely to be returning the community's IPv4 addresses that they obtained but don't have need for. The community should also know which /8 legacy holders say "Hell no, we're keeping all our /8s, and not telling you how much of the community's IPv4 resources we're actually using". -- -JH From Valdis.Kletnieks at vt.edu Thu Feb 10 01:37:38 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 10 Feb 2011 02:37:38 -0500 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: Your message of "Thu, 10 Feb 2011 06:35:42 GMT." <8FAA4ED3-4AB6-431D-8635-7A3C10C3E586@internode.com.au> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <20110210060919.F1DEE9E0AB7@drugs.dv.isc.org> <8FAA4ED3-4AB6-431D-8635-7A3C10C3E586@internode.com.au> Message-ID: <21862.1297323458@localhost> On Thu, 10 Feb 2011 06:35:42 GMT, Matthew Moyle-Croft said: > That's an assertion I've heard, but has anyone quantified it? How much time > and money would it take? Has anyone just asked the 22 /8 holders mentioned > above nicely if they might just like to give them back for some good publicity? There's only two minor problems with the idea: 1) How long will 22 /8's delay the inevitable if they were all available immediately? How much good will they do if only 3 or 4 actually return their /8? How much good will any of them do if they take 6 or 12 months to become available? If you get 2 a quarter from 4Q11 till 3Q13, how much does that change the basic point that people really should be deploying IPv6 rather than rearranging the deck chairs on the Titanic? 2) "Little Red Hen, Inc just completed a multi-hundred-thousand dollar project to renumber their entire network to return a /8 to benefit the lamb, the cat, and the pig, while Ant Co completed their own renumbering to return a /8 to benefit the grasshopper. The lamb, cat, pig, and grasshopper were all grateful for the ability to avoid deploying IPv6 even longer". Is that the sort of publicity you really want, and is it good enough to justify the cost of renumbering your entire network? At least in the current US climate, if a corporation has a /8 allocation, it's really hard to make the business case that you should spend money to renumber out of it, to the benefit of your competitors who then get to *not* spend money deploying IPv6. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From owen at delong.com Thu Feb 10 01:43:53 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Feb 2011 23:43:53 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <8FAA4ED3-4AB6-431D-8635-7A3C10C3E586@internode.com.au> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <20110210060919.F1DEE9E0AB7@drugs.dv.isc.org> <8FAA4ED3-4AB6-431D-8635-7A3C10C3E586@internode.com.au> Message-ID: <3DB10DB0-282B-4303-9347-C947AE204CEE@delong.com> On Feb 9, 2011, at 10:35 PM, Matthew Moyle-Croft wrote: > > On 10/02/2011, at 4:39 PM, Mark Andrews wrote: > >> >> In message , Jason Fesler wri >> tes: >>>> In my recent probe of route servers, I found 22 legacy /8's that were partly >>> >>>> or completely unused. I'm a little surprised ARIN/ICANN thinks it's a waste >>> >>>> of time to even try to reclaim them. >> >> Because it is a waste of time and money. > > > That's an assertion I've heard, but has anyone quantified it? How much time and money would it take? Has anyone just asked the 22 /8 holders mentioned above nicely if they might just like to give them back for some good publicity? You know, US DoD migrates to IPv6 and returns X /8s for the good of the American people (assume ARIN) so that broadband might continue to grow and thrive in the land of the free? > > MMC Multiple times. The most optimistic estimates are on the order of 4 years. The most optimistic estimates of the return rate are on the order of 6-8 /8s (not the 100% of 22 /8s you are postulating). The legal expenses would be extreme. So, for $ALOT and 4 years of effort, you might get back as much as 4 months of address space. Next? Owen From tvhawaii at shaka.com Thu Feb 10 01:53:56 2011 From: tvhawaii at shaka.com (Michael Painter) Date: Wed, 9 Feb 2011 21:53:56 -1000 Subject: Is your ASN advertising v6 prefixes? References: <20110209223724.F4602E77@resin17.mta.everyone.net> <4D538B6E.8000408@brightok.net> Message-ID: <2941728C357848B6A392A804D5683B08@DELL16> Jack Bates wrote: > On 2/10/2011 12:37 AM, Scott Weeks wrote: >> No, fix your site or I go elsewhere. > > I'm pretty sure if it's between their use of session cookies > (RIPE_NCC_DB_SESSION) and you going elsewhere, they'll stick with using > the session cookies for the database. They could be a little less > sloppy, though. I mean RIPE_COOKIE_TEST? Really? And some of the graphs > don't seem to be working right with FF (get a pretty display of them all > and then they vanish and can't find them in the various menus). > > Jack Same exact problem with IE8, btw. From owen at delong.com Thu Feb 10 01:49:57 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Feb 2011 23:49:57 -0800 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <20110205193328.GC22325@vacation.karoshi.com> <08F8827D-D8C3-4922-AC39-6C71ADBE8BDB@corp.arin.net> <20110206014014.GG22325@vacation.karoshi.com> <849FDB3F-EE29-48D6-8ECD-70AE6EB0B157@virtualized.org> <71571.1297311453@nsa.vix.com> Message-ID: <5E52FD88-2232-4038-9953-69E9011E9529@delong.com> On Feb 9, 2011, at 11:13 PM, Jimmy Hess wrote: > On Wed, Feb 9, 2011 at 10:17 PM, Paul Vixie wrote: >> David Conrad writes: > >> whether either DEC or HP could have qualified for a /8 under current rules, >> since the basis for these (pre-RIR) allocations was that they needed more >> than a /16 and these were the days before CIDR. (at the time i received >> the /8 allocation at DEC, we had a half dozen /16's several dozen /24's that > > With them not requiring a /8 in the first place (after CIDR); one > begins to wonder how much of > their /8 allocations they actually touched in any meaningful way. > > Perhaps the RIRs should personally and directly ask each /8 legacy > holder to provide > account of their utilization (which portions of the allocation is > used, how many hosts), > and ASK for each unused /22 [or shorter] to be returned. > > The legacy holders might (or might not) refuse. They might (or > might not) tell the RIRs "Hell no" > In any case, the registry should ASK and publish an indication > for each legacy /8 at least. > That depends on whether you want honest answers from the legacy holders or a blanket "We're using the space, move along, these aren't the droids you're looking for." If the RIRs are going to ask, they RIRs should be able to keep the data and provide generalized statistics, or, at least each organization should have the option of opting in to any identifying statistics. Otherwise, you create an incredible motivation for organizations to simply stonewall the RIRs and refuse to tell them anything. > So the community will know which (if any) legacy /8 holders are > likely to be returning the community's > IPv4 addresses that they obtained but don't have need for. > If they are inclined to return anything, the community will find out what is returned soon enough. There's no real gain to this witch hunt other than feeling like you put pressure on legacy holders to do what you think is the right thing. It may create some small amount of personal satisfaction, but, it won't actually help get addresses freed up. In fact, I think it would be counter-productive. > The community should also know which /8 legacy holders say "Hell no, > we're keeping all our /8s, > and not telling you how much of the community's IPv4 resources we're > actually using". > Yeah, this is a sure path to having all of them say exactly that in unison. Do you want to be right? Or would you prefer to be effective? Owen From henk at ripe.net Thu Feb 10 01:42:17 2011 From: henk at ripe.net (Henk Uijterwaal) Date: Thu, 10 Feb 2011 08:42:17 +0100 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> Message-ID: <4D5396D9.6070904@ripe.net> On 10/02/2011 06:15, Ricky Beam wrote: > On Wed, 09 Feb 2011 16:42:14 -0500, Nathan Eisenberg > wrote: >> What do you mean, lit up? You mean they're not in the routing tables that you >> get from your carriers? I'd argue that's no indication of whether they're in >> use or not. > > That's pretty much the definition of "in use". If they don't appear in the > global routing table, then they aren't being used. I cannot send traffic to > them; they cannot send traffic to me. I don't think that this is a correct definition. The question should be if there is a need for a globally unique number for a device. > In my recent probe of route servers, I found 22 legacy /8's that were partly or > completely unused. I'm a little surprised ARIN/ICANN thinks it's a waste of > time to even try to reclaim them. If all 22 /8 that aren't in use would be reclaimed, that would only postpone the problem by a few years, it would not solve problem that IPv4 address space is limited and we will, sooner or later, run out. Reclaiming will take a considerable amount of time and effort from everybody, I think this is better spent working on a solution that will solve the problem forever. Henk (Speaking for myself, not for my employer). -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ I confirm today what I denied yesterday. Anonymous Politician. From lists at quux.de Thu Feb 10 02:59:49 2011 From: lists at quux.de (Jens Link) Date: Thu, 10 Feb 2011 09:59:49 +0100 Subject: Looking for an IPv6 naysayer... In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC139A0@RWC-EX1.corp.seven.com> (George Bonser's message of "Wed, 9 Feb 2011 15:47:34 -0800") References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> <5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com> <8762stc5a7.fsf@oban.berlin.quux.de> <5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1399F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC139A0@RWC-EX1.corp.seven.com> Message-ID: <87lj1o6z96.fsf@oban.berlin.quux.de> "George Bonser" writes: > In other words, the broadband provider provides a single global IP to > the "always up" CPE. That CPE does DHCP to user stations and hands out > 1918 addresses and NATs them to the single global IP. Ah there is the misunderstanding. Same her in good old Europe. If you pay for it you'll get more than one public IP. I though you were talking about the CPE getting an RFC1918 address and than hand out RFC1918 addresses to the inside as well and (maybe) another instance of NAT along the way. Well yes, there are providers which are already doing this. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From nanog at maunier.org Thu Feb 10 03:10:59 2011 From: nanog at maunier.org (Pierre-Yves Maunier) Date: Thu, 10 Feb 2011 10:10:59 +0100 Subject: Is your ASN advertising v6 prefixes? In-Reply-To: <4D535065.1050301@brightok.net> References: <4D535065.1050301@brightok.net> Message-ID: 2011/2/10 Jack Bates > On 2/9/2011 8:21 PM, Fred Richards wrote: > >> Mine is. >> Well? >> >> http://www.cidr-report.org/cgi-bin/as-report?as=8025&view=2.0&v=6 > > Love that tool! > > > Jack > > Love that one : http://www.sixxs.net/tools/grh/dfp/all/ -- Pierre-Yves Maunier From lists at quux.de Thu Feb 10 03:15:07 2011 From: lists at quux.de (Jens Link) Date: Thu, 10 Feb 2011 10:15:07 +0100 Subject: Looking for an IPv6 naysayer... In-Reply-To: <20110210010116.0CB0F9DD351@drugs.dv.isc.org> (Mark Andrews's message of "Thu, 10 Feb 2011 12:01:15 +1100") References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <20110210010116.0CB0F9DD351@drugs.dv.isc.org> Message-ID: <87pqr05jz8.fsf@oban.berlin.quux.de> Mark Andrews writes: > DS-Lite over 6rd using RFC 1918 / multi-use ISP assigned block > (I'd love to be able to say class E here) provides a single NAT > translation for IPv4 and public IPv6. Okay, it's 10:15 in the morning and I really want a drink know. ;-) Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From lists at internetpolicyagency.com Thu Feb 10 03:24:52 2011 From: lists at internetpolicyagency.com (Roland Perry) Date: Thu, 10 Feb 2011 09:24:52 +0000 Subject: IPv6 - a noobs prespective In-Reply-To: <7000830.352.1297276636748.JavaMail.franck@franck-martins-macbook-pro.local> References: <7000830.352.1297276636748.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: In article <7000830.352.1297276636748.JavaMail.franck at franck-martins-macbook-pro.loc al>, Franck Martin writes >You missed the IPv6 hour at Nanog42: > >http://www.civil-tongue.net/grandx/wiki/nanog42 >https://wiki.tools.isoc.org/IETF71_IPv4_Outage > >May be another one is needed? If you are going to debug very much (and/or undertake a "dummies" course") it's probably going to take more than an hour, at one of those venues - useful though the hour is for other purposes. What these meetings need is an "IPV6 room", where you have several days to work through all the issues (hopefully with some help - I've seen people struggle to get IPv6 working on a Windows XP laptop, for example). Roland. >----- Original Message ----- >From: "Mike Lyon" >To: "Jack Bates" >Cc: nanog at nanog.org >Sent: Thursday, 10 February, 2011 7:30:55 AM >Subject: Re: IPv6 - a noobs prespective > >With the recent allocation of the last existing IPv4 /8s (which now kind of >puts pressure on going v6), it would be wonderful if at the next couple of >NANOGs if there could be an IPv6 for dummies session or two :) > >-Mike > > >On Wed, Feb 9, 2011 at 10:22 AM, Jack Bates wrote: > > -- Roland Perry From lists at quux.de Thu Feb 10 03:32:28 2011 From: lists at quux.de (Jens Link) Date: Thu, 10 Feb 2011 10:32:28 +0100 Subject: Strange L2 failure In-Reply-To: <4D4485A6.3040203@brightok.net> (Jack Bates's message of "Sat, 29 Jan 2011 15:24:54 -0600") References: <4D4485A6.3040203@brightok.net> Message-ID: <87ei7g5j6b.fsf@oban.berlin.quux.de> Jack Bates writes: Hi, a little late, but just catching up the list. > Has anyone seen issues with IOS where certain MACs fail? > > 54:52:00 (kvm) fails out an old 10mbit port on a 7206 running 12.2 > SRE. I've never seen anything like this. DHCP worked, ARP worked, and > arp debugging showed responses for arp to the MAC, however, tcpdump on > the host system I had something similar using a Catalyst 3550. Very simple setup: Host ----- Cat3550 ----- Router You could see arp-request from the host to the router and arp-replies from the router using tcpdump, but the arp-replies didn't make it to the host. No change in the interface counters on the switch either. When using a static arp-entry on the host and then ping the router you could the echo-request and echo-replies there but still no answers. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From Brent.Roberts at progressive-solutions.com Thu Feb 10 03:33:50 2011 From: Brent.Roberts at progressive-solutions.com (Roberts, Brent) Date: Thu, 10 Feb 2011 09:33:50 +0000 Subject: 10GBASE-T Switches Message-ID: <12EFAA890B74E14782EFB259E5A63ABC21458A4B@GEMINI2.psi.corp> Looking for feedback/recommendations on higher density Switch?s in the 10GBASE-T arena. Preferably TOR switches if possible. Minimum 16 ports usable for Rack Server connectivity + Uplinks to Collapsed Twin Distro/Core setup. Found the Arista 7X00 family to have the density I am looking for but others of similar spec would be appreciated. Any Thoughts and/or suggestions would be greatly appreciated. ________________________________ This email and any attached files may contain confidential and/or privileged material and is intended solely for the use of the person to whom it is addressed. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender immediately and delete it and all attachments from your computer. Progressive Solutions is not liable for any errors or omissions in the content or transmission of this email. From lists at quux.de Thu Feb 10 03:59:46 2011 From: lists at quux.de (Jens Link) Date: Thu, 10 Feb 2011 10:59:46 +0100 Subject: Looking for an IPv6 naysayer... In-Reply-To: <87pqr05jz8.fsf@oban.berlin.quux.de> (Jens Link's message of "Thu, 10 Feb 2011 10:15:07 +0100") References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <20110210010116.0CB0F9DD351@drugs.dv.isc.org> <87pqr05jz8.fsf@oban.berlin.quux.de> Message-ID: <8762ss43cd.fsf@oban.berlin.quux.de> Jens Link writes: > Okay, it's 10:15 in the morning and I really want a drink know. ;-) s/know/now/ I think I'll need more coffee. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From tshaw at oitc.com Thu Feb 10 05:45:24 2011 From: tshaw at oitc.com (TR Shaw) Date: Thu, 10 Feb 2011 06:45:24 -0500 Subject: My upstream ISP does not support IPv6 In-Reply-To: <018201cbc8e9$3b641120$b22c3360$@iname.com> References: <18699589.266.1296788654238.JavaMail.franck@franck-martins-macbook-pro.local> <4D50779E.40804@ispn.net> <4607E2A3-6C20-4FCF-A842-37497C5558B9@consultant.com> <018201cbc8e9$3b641120$b22c3360$@iname.com> Message-ID: On Feb 10, 2011, at 1:10 AM, Frank Bulk wrote: > I'm not sure what you mean -- once the ISP identifies CPE that works on > their network, couldn't early adopters who are interested in the technology > be pointed to a short list? > > Frank > > -----Original Message----- > From: Cutler James R [mailto:james.cutler at consultant.com] > Sent: Monday, February 07, 2011 5:00 PM > To: NANOG list > Subject: Re: My upstream ISP does not support IPv6 > > All this talk about CPE is wasted until folks like ATT have someone on the > retail interface (store, phone, or, web) who even knows what is this "IPv6" > thing. Exploring this issue with DSL providers and Uverse is like that old > exercise with combat boots. It feels much better when I stop. Would if att (and others) would support IPv6 (via dedicated, residential or even cellular). Where I am, all contact people I have spoken to don't have a clue. The best I got was "call back late summer and we'll know something) Their residential and cellular folks couldn't even spell IPv6. Tom From iljitsch at muada.com Thu Feb 10 05:58:02 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 10 Feb 2011 12:58:02 +0100 Subject: Too bigs are sacred, was: Re: IPv6 addressing for core network In-Reply-To: References: Message-ID: <4DF2E248-56E9-41E6-A680-8C37FCFFADCC@muada.com> On 10 feb 2011, at 0:26, David Freedman wrote: >> Unless every packet you emit is ? the minimum MTU (1280), then, you need >> to be able to receive TOOBIG messages. > Can you think of a packet type I will emit from my publically numbered > backbone interface which may solicit a TOOBIG that I'll have to care about? What if you're trying to connect to your routers with 1500-byte+ POS, ATM, ethernet jumbo or what have you interfaces from some system with a big fat jumboframe MTU but some 100 Mbps ethernet firewall or office network in the middle? If you're willing to accept TCP or UDP from somewhere, it's a bad idea to filter ICMP coming in from that same place. From iljitsch at muada.com Thu Feb 10 06:08:06 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 10 Feb 2011 13:08:06 +0100 Subject: Looking for an IPv6 naysayer... In-Reply-To: <4D5336BB.8020602@iglou.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> <833804CE-80D9-4CED-8672-CF0870317E8C@delong.com> <582356A9-5ADC-4244-8BA0-EE1F2F3EF388@delong.com> <4D533210.8080407@brightok.net> <4D5336BB.8020602@iglou.com> Message-ID: <0DB039C3-CD06-4AE1-AB51-0774BE71DD6D@muada.com> On 10 feb 2011, at 1:52, Jeff McAdams wrote: > I've always worked in small to middle sized shops, and I have always found that I've been able to yell and scream about IPv6 (and other features) loud enough, and long enough that I get heard by someone in a decision making position for product features (usually along the lines of a product manager or so). And every time I've made the effort to do that (admittedly, not a small effort), that product or line of product has had IPv6 available for it within about a year or so (if not sooner). About 10 years ago I was involved in a project where we were looking for one or two dozen or so gigabit ethernet switches. That order would have barely broken into six figure territory. One sales engineer came around with their product and I remarked "no jumboframe support? your competitors all do 9000 bytes!" A week later, he was back with a newer version of the same box... with 64000-byte jumboframe support. :-) From david.freedman at uk.clara.net Thu Feb 10 06:15:52 2011 From: david.freedman at uk.clara.net (David Freedman) Date: Thu, 10 Feb 2011 12:15:52 +0000 Subject: Too bigs are sacred, was: Re: IPv6 addressing for core network In-Reply-To: <4DF2E248-56E9-41E6-A680-8C37FCFFADCC@muada.com> References: <4DF2E248-56E9-41E6-A680-8C37FCFFADCC@muada.com> Message-ID: Iljitsch van Beijnum wrote: > On 10 feb 2011, at 0:26, David Freedman wrote: > >>> Unless every packet you emit is ? the minimum MTU (1280), then, you need >>> to be able to receive TOOBIG messages. > >> Can you think of a packet type I will emit from my publically numbered >> backbone interface which may solicit a TOOBIG that I'll have to care about? > > What if you're trying to connect to your routers with 1500-byte+ POS, ATM, ethernet jumbo or what have you interfaces from some system with a big fat jumboframe MTU but some 100 Mbps ethernet firewall or office network in the middle? > > If you're willing to accept TCP or UDP from somewhere, it's a bad idea to filter ICMP coming in from that same place. > I think the point I'm making is, that I'm not, I wont accept any traffic to these backbone interfaces from outside the AS, this means no management sessions from outside the network! (and in the rare, emergency cases where something does need to get in from the outside, policy may dictate acl hole-punching to support it) In the case of people having an unreachable core (i.e MPLS hidden or RFC1918/ULA/LinkLocal), this happens already, if they decide to expose this somehow (MPLS TTL propagation, and/or allowing the ICMP out) then it is only to assist troubleshooting (not that I accept RFC1918/ULA sourced traffic from such networks at my edge , anyway), these people are doing this by design, I think thats the point I'm trying to get across, if you will never need to process TOOBIG in your design, there is no need to accept it. -- David Freedman Group Network Engineering Claranet Group From tshaw at oitc.com Thu Feb 10 06:50:36 2011 From: tshaw at oitc.com (TR Shaw) Date: Thu, 10 Feb 2011 07:50:36 -0500 Subject: My upstream ISP does not support IPv6 In-Reply-To: <474CF0FC-1A42-4141-87A2-CDAD566AF8E1@delong.com> References: <18699589.266.1296788654238.JavaMail.franck@franck-martins-macbook-pro.local> <4D50779E.40804@ispn.net> <4607E2A3-6C20-4FCF-A842-37497C5558B9@consultant.com> <018201cbc8e9$3b641120$b22c3360$@iname.com> <474CF0FC-1A42-4141-87A2-CDAD566AF8E1@delong.com> Message-ID: On Feb 10, 2011, at 1:26 AM, Owen DeLong wrote: > The problem is conversations like this: > > AT&T Customer Service: "AT&T uVerse, how can I help you?" > > Customer: "Yes, I have uVerse service and I'd like to get IPv6." > > AT&T Customer Service: "I pea vee what? Is this a prank call?" > > Owen > The ATT cellular folks respond... ATT: "ATT Wireless. My name is ____ and I'm here to help" User: "My iPhone web browser can't reach sites like ipv6.google.com via your cellular network but it can over my wifi at home." ATT: "So you are having problems with your uVerse wireless connection?" ... after escalating to L2 support.... ATT: "So we will start be reseting your iPhone and then configure it for data access...." ...after 45 minutes... ATT: "Are you sure the website is valid? Let me check that website on my desktop here."... "Well, thats the problem! http://ipv6.google.com/ doesn't exist. I can't get to it via my desktop here at support. You need to use www instead of ipv6 and everything will be fine. Is there anything else I can help you with today?" From tom at ninjabadger.net Thu Feb 10 07:15:19 2011 From: tom at ninjabadger.net (Tom Hill) Date: Thu, 10 Feb 2011 13:15:19 +0000 Subject: 10GBASE-T Switches In-Reply-To: <12EFAA890B74E14782EFB259E5A63ABC21458A4B@GEMINI2.psi.corp> References: <12EFAA890B74E14782EFB259E5A63ABC21458A4B@GEMINI2.psi.corp> Message-ID: <1297343719.27507.53.camel@teh-desktop> On Thu, 2011-02-10 at 09:33 +0000, Roberts, Brent wrote: > Looking for feedback/recommendations on higher density Switch?s in the > 10GBASE-T arena. > Preferably TOR switches if possible. > Minimum 16 ports usable for Rack Server connectivity + Uplinks to > Collapsed Twin Distro/Core setup. > Found the Arista 7X00 family to have the density I am looking for but > others of similar spec would be appreciated. > Any Thoughts and/or suggestions would be greatly appreciated. Dell sell (I doubt they make it) their '8024' 24-port 10GBASE-T switch. http://dell.to/dJP1ka I've not used one myself, and it's probably not pretty, but it fits your description. Tom From james.cutler at consultant.com Thu Feb 10 07:31:23 2011 From: james.cutler at consultant.com (Cutler James R) Date: Thu, 10 Feb 2011 08:31:23 -0500 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> Message-ID: On Feb 10, 2011, at 12:15 AM, Ricky Beam wrote: > On Wed, 09 Feb 2011 16:42:14 -0500, Nathan Eisenberg wrote: >> What do you mean, lit up? You mean they're not in the routing tables that you get from your carriers? I'd argue that's no indication of whether they're in use or not. > > That's pretty much the definition of "in use". If they don't appear in the global routing table, then they aren't being used. I cannot send traffic to them; they cannot send traffic to me. > > In my recent probe of route servers, I found 22 legacy /8's that were partly or completely unused. I'm a little surprised ARIN/ICANN thinks it's a waste of time to even try to reclaim them. > > --Ricky This dead horse keep coming back for another beating. The purpose of a global registry of numbers is to provide a common source for unique numbers. The definition of "in use" by internet registries does not require appearance in your routing tables or even in the route servers. Not only that, the "users" may not even want or need to exchange traffic with you. As a survivor of many network consolidations due to corporate acquisitions, I have many scars from trying to get separate RFC 1918 islands to interwork properly. That is the reason that even so-called private networks need unique IP addressing. And now, since IPv6 is actually being deployed and used, there is absolutely no economic incentive to continue to fight the "IPv4 addresses not in my routing table are not 'in use'" battle any more. It is a waste of time and money. James R. Cutler james.cutler at consultant.com From jbates at brightok.net Thu Feb 10 07:54:21 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 10 Feb 2011 07:54:21 -0600 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <5E52FD88-2232-4038-9953-69E9011E9529@delong.com> References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <20110205193328.GC22325@vacation.karoshi.com> <08F8827D-D8C3-4922-AC39-6C71ADBE8BDB@corp.arin.net> <20110206014014.GG22325@vacation.karoshi.com> <849FDB3F-EE29-48D6-8ECD-70AE6EB0B157@virtualized.org> <71571.1297311453@nsa.vix.com> <5E52FD88-2232-4038-9953-69E9011E9529@delong.com> Message-ID: <4D53EE0D.80307@brightok.net> On 2/10/2011 1:49 AM, Owen DeLong wrote: > Yeah, this is a sure path to having all of them say exactly that in > unison. Do you want to be right? Or would you prefer to be effective? > I think he wants to know which bogons will continue to be safe to use. :P Jack From bensons at queuefull.net Thu Feb 10 08:36:54 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Thu, 10 Feb 2011 08:36:54 -0600 Subject: Looking for an IPv6 naysayer... In-Reply-To: <4D532AEA.2090505@brightok.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> Message-ID: On Feb 9, 2011, at 6:01 PM, Jack Bates wrote: > On 2/9/2011 5:56 PM, Robert E. Seastrom wrote: >> Or 6rd and go native on their permanent prefix as the forklift upgrade >> schedule allows. Oh well, it's better than nothing or Crummier Grade NAT. > > ds-lite tends to be friendlier LSN from various tests, and is native v6. DS-lite is still CGN. You may be thinking of the comparison versus NAT444 described in draft-donley-nat444-impacts (https://datatracker.ietf.org/doc/draft-donley-nat444-impacts/). But you should read the criticisms of that draft on the BEHAVE mailing list, http://www.ietf.org/mail-archive/web/behave/current/msg09027.html and http://www.ietf.org/mail-archive/web/behave/current/msg09030.html. Cheers, -Benson From khelms at ispalliance.net Thu Feb 10 08:58:08 2011 From: khelms at ispalliance.net (Scott Helms) Date: Thu, 10 Feb 2011 09:58:08 -0500 Subject: Looking for an IPv6 naysayer... In-Reply-To: <20110210002231.23F0E9DCFDD@drugs.dv.isc.org> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> <833804CE-80D9-4CED-8672-CF0870317E8C@delong.com><4D531B52.70404@ispalliance.net> <20110210002231.23F0E9DCFDD@drugs.dv.isc.org> Message-ID: <4D53FD00.40900@ispalliance.net> On 2/9/2011 7:22 PM, Mark Andrews wrote: > > And some of their customers have been asking for IPv6 all along. > > I started asking my ISP at home in 2003. I suspect if all the ISPs > here were honest they would say that they have had a trickle of > IPv6 requests for the last 8 years. > > Mark Mark, I don't doubt that but request levels have to rise to a certain point. I still get a trickle of requests for UUCP service along with other very low volume features/products. Its the same thing as when you guys get a feature request for BIND or ISC DHCP that only a tiny fraction of your customers will use. Everyone has to prioritize and given that all of the tech folks who wanted to get an IPv6 connection could do so via tunneling there has been absolutely 0 pressure from residential customers and very very little from commercial customers. The federal government's requirement generated a few months of interest until everyone figured out they could satisfy their requirements by setting a tunnel with HE. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From brunner at nic-naa.net Thu Feb 10 09:00:50 2011 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Thu, 10 Feb 2011 10:00:50 -0500 Subject: Looking for an IPv6 naysayer... In-Reply-To: <0CA94927-95DB-4C36-9B55-C891151729FB@delong.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E59B.4070904@nic-naa.net> <6E2D8385-77A1-4408-B12B-A7F61FDCC3EF@delong.com> <4D531E85.3000005@nic-naa.net> <0CA94927-95DB-4C36-9B55-C891151729FB@delong.com> Message-ID: <4D53FDA2.8050304@nic-naa.net> On 2/9/11 10:32 PM, Owen DeLong wrote: > > On Feb 9, 2011, at 3:08 PM, Eric Brunner-Williams wrote: > >>> I disagree... I think that offering alternate name space views to the existing {b,m}illions of v4 addressed spindles requires IPv6 reachability as well since those will also be adding IPv6 capabilities in the next year or two. >> >> so your claim is that to have a .cat, serving registrants currently using v4 provisioned hosting services, and end-users currently using v4 provisioned eyeball networks, and initially address and resources (but not names) currently extant in the com/net/org/biz/info namespaces [1], the .cat registry first has to be v6 reachable. >> > My claim is that about the time these zones are rolling out, the registrants currently using v4 provisioned hosting services and end users currently using v4 provisioned eyeball networks will also, at least in some cases, be using dual stack and/or v6 services. "in some cases" is a poor motivation for a general mandatory-to-implement requirement. a "v6 where required (by other market actors than icann's legal staff in marina del rey)" form would be appropriate -- but you're making a universal claim, so on we go... inter alia, that both ends of the chain of resolution (stub resolver on an eyeball network and mapped resource in a hosting provider rack) may be using dual-stack fails to motivate why the authoritative name to address resolver must be v6 reachable. >> and this claim is true because the webhosting operators, primarily in Catalonia, who have v4 now, will themselves be v6 reachable in the next year or two ... i think this requires either the existing hosting operators abandon vhosting as a service model or abandon their existing v4 allocations. >> > You do not have to abandon v4 to deploy v6. That's an absurd claim. yet it is the claim you are making. the resource must be v6 reachable, and you're not offering arbitrary capriciousness of some evangelically unbalanced lawyers in a high-rise in marina del ray as a rational, so you must have a material necessity rational. >> now rinse and repeat for .nyc. the claim is somehow that the market for hosting operators (ok, the hosting lines of business of godaddy, tucows, enom, netsol, ... and their downstream resellers, which is statistically likely to have 51% of all .nyc registrations), and/or (your choice) the eyeball network operators for the tri-state area, are going to either abandon vhosting as a service model or abandon their existing v4 allocations ... >> > Again, the need for v6 is not predicated on the abandonment of v4. you've managed to elide responding to both (a) an actual new (in 2005) registry, with existing v4 provisioning, and (b) a pending new (in 2012) registry, again with existing v4 provisioning. i look forward to learning why .cat failed for lack of v6, and why .nyc will fail, for lack of v6, in a sentence that doesn't contain a reference to lawyers in a high-rise in marina del ray. >> where the v6 ab initio convinces me some is the area i currently work on -- developing economies. nigeria is a good example, fewer than 10^^5 computers, a population of 15x10^^7, and cell phone penetration rate approaching 1 in 3. even so, the number of v6 prefixes in afnic's inventory of allocations is ... very small ... for all of africa as a region. >> > I believe AfriNIC has a /12 like any other RIR. I'm not sure what you are saying here. try looking beyond what the iana has allocated to a rir, and look at what prefixes the rir has allocated. alternatively, something along the lines of trivial pursuits, name the data centers and/or eyeball networks in africa in which v6 was deployed in q42010. >>> It's not that I think you only serve the future. It's that we think you are failing to recognize that IPv6 is now >>> and that what is IPv4 today will be at least dual-stack tomorrow. >> >> if the window for applications opens 4 months after icann-41 (amman, jordan), in q42011, then delegations will occur as soon as q32012. >> > Yes. > >> is your claim that registry operators where v6 is _sparce_, and/or where v6 eyeball networks are _sparce_, two years from today, are properly failed for technical reasons, two years from today, for lack of v6 capability? >> > I'm not sure what you mean by _sparce_. See africa, v6 availability, above. > My claim is that by 4q2012, I expect we will see much much wider IPv6 deployment and potentially eyeball > networks that are primarily or exclusively IPv6 with at best limited or degraded IPv4 support through multiple > layers of NAT. now that is an interesting claim. suppose it is true and there is "at best limited or degraded IPv4" on eyeball networks. why is a once per session trip up and down the chain of resolution sufficient to motivate anything? further, why do you suppose that new gtld registries, but not existing gtld registries, have an affirmative duty to be v6 reachable from resolvers on v6-only eyeball networks? what is the point of partitioning content along "legacy v4 provisioned content, and its v4 provisioned access demographic" and "new gtld mapped content and its v6 provisioned access demographic"? to be really convincing, it would help if you'd make the case that existing v4-reachable-only registries must be v6 reachable or fail, just as you'd fail a new gtld applicant lacking v6. > As such, I think that registries spinning up in 3q2012 should be required to have IPv6 support. yes. see above. > >> if your claim is that v6 is mandatory to implement sometime soon, i'm fine with that rather flexible temporal requirement, but icann's current rules of the road are an application that isn't v6 ready at transition to delegation (roughly two years from now) fails. >> > If you define soon as prior to 2q2012, then, yes, I'm fine with that. However, that seems to be about a quarter > earlier than you think these things will be starting up. Since you seem to be claiming they should get some > period beyond that where they don't need to run IPv6 (I'm not sure where they're supposed to get their > addresses to run on IPv4 by then, frankly), I think your definition of soon and mine are probably not > compatible. first, refer to the statistical likelihood date of v4 exhaustion in the afnic region. there's a nice graph available that shows very broad shoulders, several years of availability. second, registries are critical internet infrastructure, and in the arin region prop 125, which you know about having commented on it, there exists a policy of reserve for ci requirements, and 125 provides for three (3) years of resource availability to the allocation receiving ci requester. requesting a 125-similar policy for the rir with the next most proximal statistical likelihood date of v4 exhaustion, the ripe region, is on my todo list. note however, that few applications for registries located in the arin or ripe regions, where the statistical likelihood date of v4 exhaustion is both most proximal, and the confidence level narrowest, are likely to meet the general reading of the icann board of directors' resolution #20 (nairobi), expressing an interest in forms of cost-reduction assistance to needy applicants, e.g., from "developing countries". >> pessimally, the requirement is present at the date when applications are submitted, that is, a year from today. >> > I don't think that 1q2012 is especially out of line given a 2q2012 target date. > >> now there's still 24 months for icann legal staff to acquire clue, and for last week's press event to galvanize operators everywhere, so perhaps this (and its cognate, dnssec at transition to delegation) can be elided, but it is irresponsible to assert [2], independent of the purpose and position of a registry, that it must have a feature due to the universalist claims of advocates for a particular technology. >> > I think it is irresponsible at this point to consider deploying any major network infrastructure without requiring IPv6 capabilities at deployment. IANA is already out of IPv4. If you expect these systems to start getting deployed in 3q2012, then, you're talking about a time which is likely to be well past RIR exhaustion in most cases. I suppose they can get a /22 from APNIC, but, other than that, where do you expect these organizations to even get IPv4 to work with? just how many endpoint identifiers do you think a registry requires? i don't think this is your best argument, as it requires a suspension of belief that there is a market, or markets, in allocations sufficient to provision anything from a half-rack to multiple racks in a standard cage, and the margin on a registry footprint is lower than the margin on most other hosting operations. if you're going to swing for the fence, don't try to argue lack of something that can still be bought for some time to come. make the claim that registrants (other than ppc registrants, that's a separate case you may want to make, and if so, don't forget the eyeball network operator as a beneficiary from systemic synthetic return, a la verisign's sitefinder) demand that their resources be resolvable by v6 only paths because there is sufficient revenue in v6 reachability, or that v6 only registrations will, in the twelve quarters of operation, provide more revenue, or at least enough to cover costs and reduce the likelihood of registry failure, than the v4 only registrations. having made any case based upon benefit, it would be illuminating to opine why no existing registry operator is experiencing v6 uptake by its registrants supporting a registrant beneficiary theory. >> thanks for your difference, >> -e >> > Any time. less religion, more near-term numbers. t.i.a. -e From cra at WPI.EDU Thu Feb 10 09:05:54 2011 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 10 Feb 2011 10:05:54 -0500 Subject: 10GBASE-T Switches In-Reply-To: <12EFAA890B74E14782EFB259E5A63ABC21458A4B@GEMINI2.psi.corp> References: <12EFAA890B74E14782EFB259E5A63ABC21458A4B@GEMINI2.psi.corp> Message-ID: <20110210150554.GB8961@angus.ind.WPI.EDU> On Thu, Feb 10, 2011 at 09:33:50AM +0000, Roberts, Brent wrote: > Looking for feedback/recommendations on higher density Switch?s in the 10GBASE-T arena. > Preferably TOR switches if possible. > Minimum 16 ports usable for Rack Server connectivity + Uplinks to Collapsed Twin Distro/Core setup. > Found the Arista 7X00 family to have the density I am looking for but others of similar spec would be appreciated. > Any Thoughts and/or suggestions would be greatly appreciated. Juniper EX4500 has 40 fixed SFP/SFP+ ports plus 2 uplink modules that can contain 4 SFP/SFP+ ports each for a total of 48 10GBASE-X ports. Need to buy SFP+ modules or use direct-attach SFP+ cables though. From bblackford at gmail.com Thu Feb 10 09:12:40 2011 From: bblackford at gmail.com (Bill Blackford) Date: Thu, 10 Feb 2011 07:12:40 -0800 Subject: 10GBASE-T Switches In-Reply-To: <20110210150554.GB8961@angus.ind.WPI.EDU> References: <12EFAA890B74E14782EFB259E5A63ABC21458A4B@GEMINI2.psi.corp> <20110210150554.GB8961@angus.ind.WPI.EDU> Message-ID: > Juniper EX4500 has 40 fixed SFP/SFP+ ports plus 2 uplink modules that > can contain 4 SFP/SFP+ ports each for a total of 48 10GBASE-X ports. > Need to buy SFP+ modules or use direct-attach SFP+ cables though. And is now shipping with a model that can stack and/or join a EX4200 VC stack. It's either EX4500-40F-VC1-BF or EX4500-40F-VC1-FB depending on whether you want Front-to-Back or Back-to-Front airflow. -b -- Bill Blackford Network Engineer Logged into reality and abusing my sudo privileges..... From vikassharmas at gmail.com Thu Feb 10 09:13:38 2011 From: vikassharmas at gmail.com (Vikas Sharma) Date: Thu, 10 Feb 2011 20:43:38 +0530 Subject: Ipv6 addressing for Core network In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC1393F@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0BC1393F@RWC-EX1.corp.seven.com> Message-ID: HI Geroge, Thanks for the input. Appreciate some more info wrt TCAM usuage if possible. Another thought, I agree ip schema is individual preference, but I want to know the best practise (vague term best practice). Personally even I am in favor of /64 p-t-p. Regards, Vikas On Wed, Feb 9, 2011 at 12:11 PM, George Bonser wrote: > > I am looking for the recommendation for core interfaces IP addressing > > schema > > for Ipv6. Some different views are (PE- P - PE, point to point link) > as > > below - > > > > 1- Use Public Ipv6 with /122 and do not advertise to Internet > > 2- Use Public Ipv6 with /127 and do not advertise to Internet > > 3- Use Unique local ipv6 address > > 4- Use Public Ipv6 with /64 > > > > Also I am interested to understand the impact on TCAM ... > > > > Regards, > > Vikas > > I would use a /64 with ND turned off and static neighbors configured. > TCAM impact will depend on vendor. Some vendors give you the option of > storing the first 64 bits of a V6 IP or the entire address. Using a /64 > means your CAM usage might be less depending on your vendor. > > If the addresses on the point-to-point links never accept or source > direct traffic to/from outside your net, you can use whatever you want > on them. ULA might be ok there. I am using public IPs but I filter > traffic destined for them at the edge but to each their own choice. But > if you use ULA you aren't going to be able to ping anything outside your > net if you source the pings from the ULA interface. Just something to > keep in mind. > > What you are asking is a matter of individual preference. > > From vixie at isc.org Thu Feb 10 09:13:51 2011 From: vixie at isc.org (Paul Vixie) Date: Thu, 10 Feb 2011 15:13:51 +0000 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: Your message of "Thu, 10 Feb 2011 01:13:49 CST." References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <20110205193328.GC22325@vacation.karoshi.com> <08F8827D-D8C3-4922-AC39-6C71ADBE8BDB@corp.arin.net> <20110206014014.GG22325@vacation.karoshi.com> <849FDB3F-EE29-48D6-8ECD-70AE6EB0B157@virtualized.org> <71571.1297311453@nsa.vix.com> Message-ID: <7472.1297350831@nsa.vix.com> > Date: Thu, 10 Feb 2011 01:13:49 -0600 > From: Jimmy Hess > > With them not requiring a /8 in the first place (after CIDR); one > begins to wonder how much of their /8 allocations they actually > touched in any meaningful way. i expect that after final depletion there will be some paid transfers from some of the large legacy blocks. i have no personal knowledge of HP's situation or indeed any /8 holder's situation, but if the market value of these transfers ever meaningfully exceeds the renumbering penalty then their beancounters will find a way to get it done. that's the way of the world. i can imagine this NOT happening. most businesses are looking for long term strategic investments not quick-fix short-term band-aids. a buddy loaned me a macbook after my thinkpad was stolen, and i loved it, and i went down to the apple store to buy one of my own just like my buddy's loaner and they said "we only sell that with the chicklet keyboard now" and i tried it and hated it. i could buy my buddy's laptop but without applecare and without the ability to replace it if it's lost/stolen i'm not willing to make that investment. so for me it's another thinkpad. so if a company who traditionally needs a lot of IPv4 to grow their network knows that they can get one last quarter's worth of it from some legacy /8 holder, they might do some kind of paid transfer, or they might just hum some dire straits and keep moving with their ipv6 plans. Now it's past last call for alcohol Past recall has been here and gone The landlord finally paid us all The satin jazzmen have put away their horns And we're standing outside of this wonderland Looking so bereaved and so bereft Like a Bowery bum when he finally understands The bottle's empty and there's nothing left (Your Latest Trick) for some IPv4 based businesses a /8 would be more than a lifetime supply, but there's a value ceiling imposed by the space other people can get. (when everybody else has made other arrangements, the relative value of one's own hoard decreases.) > Perhaps the RIRs should personally and directly ask each /8 legacy > holder to provide account of their utilization (which portions of the > allocation is used, how many hosts), and ASK for each unused /22 [or > shorter] to be returned. > > The legacy holders might (or might not) refuse. They might (or might > not) tell the RIRs "Hell no" In any case, the registry should ASK and > publish an indication for each legacy /8 at least. > > So the community will know which (if any) legacy /8 holders are likely > to be returning the community's IPv4 addresses that they obtained but > don't have need for. > > The community should also know which /8 legacy holders say "Hell no, > we're keeping all our /8s, and not telling you how much of the > community's IPv4 resources we're actually using". this gets into the controversial topic of an RIR's standing with respect to legacy space, and i'll leave that to the lawyers to talk about. but as owen and others have said, if a legacy holder were approached in this way knowing that their answer was going to be on the public record in the way, they probably would see no incentive at all to answer the question. From tshaw at oitc.com Thu Feb 10 09:42:43 2011 From: tshaw at oitc.com (TR Shaw) Date: Thu, 10 Feb 2011 10:42:43 -0500 Subject: My upstream ISP does not support IPv6 In-Reply-To: <006588F1-6B46-4318-8E40-8C326E44E493@oitc.com> References: <18699589.266.1296788654238.JavaMail.franck@franck-martins-macbook-pro.local> <4D50779E.40804@ispn.net> <4607E2A3-6C20-4FCF-A842-37497C5558B9@consultant.com> <018201cbc8e9$3b641120$b22c3360$@iname.com> <474CF0FC-1A42-4141-87A2-CDAD566AF8E1@delong.com> <006588F1-6B46-4318-8E40-8C326E44E493@oitc.com> Message-ID: On Feb 10, 2011, at 10:28 AM, Cameron Byrne wrote: > T-mobile USA has a nationwide ipv6 beta. You can google it. Regarding iphone, its more an iPhone issue than anything else > Nope its ATT. My iPhone works fine on IPv6. I connect wifi at home and can go anywhere but on on ATT wireless. Tom From Valdis.Kletnieks at vt.edu Thu Feb 10 09:42:48 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 10 Feb 2011 10:42:48 -0500 Subject: Too bigs are sacred, was: Re: IPv6 addressing for core network In-Reply-To: Your message of "Thu, 10 Feb 2011 12:15:52 GMT." References: <4DF2E248-56E9-41E6-A680-8C37FCFFADCC@muada.com> Message-ID: <42284.1297352568@localhost> On Thu, 10 Feb 2011 12:15:52 GMT, David Freedman said: > these people are doing this by design, I think thats the point I'm > trying to get across, if you will never need to process TOOBIG in your > design, there is no need to accept it. And how many networks break PMTUD because their design says they never need to deal with ICMP so there's no need to accept it, or break DNS because TCP/53 is only used for zone transfers that should never happen, or... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From joelja at bogus.com Thu Feb 10 09:48:32 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 10 Feb 2011 07:48:32 -0800 Subject: My upstream ISP does not support IPv6 In-Reply-To: References: <18699589.266.1296788654238.JavaMail.franck@franck-martins-macbook-pro.local> <4D50779E.40804@ispn.net> <4607E2A3-6C20-4FCF-A842-37497C5558B9@consultant.com> <018201cbc8e9$3b641120$b22c3360$@iname.com> <474CF0FC-1A42-4141-87A2-CDAD566AF8E1@delong.com> <006588F1-6B46-4318-8E40-8C326E44E493@oitc.com> Message-ID: <4D5408D0.9060802@bogus.com> On 2/10/11 7:42 AM, TR Shaw wrote: > On Feb 10, 2011, at 10:28 AM, Cameron Byrne wrote: > >> T-mobile USA has a nationwide ipv6 beta. You can google it. >> Regarding iphone, its more an iPhone issue than anything else >> > Nope its ATT. My iPhone works fine on IPv6. I connect wifi at home > and can go anywhere but on on ATT wireless. Your iphone supports v6 in the operating system that runs the user facing side of it. It's baseband radio controller (with a seperate processor and operating system) does not support v6 and thus the cellular side of the device cannot. > Tom > > From msa at latt.net Thu Feb 10 09:49:06 2011 From: msa at latt.net (Majdi S. Abbas) Date: Thu, 10 Feb 2011 08:49:06 -0700 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: References: <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <20110205193328.GC22325@vacation.karoshi.com> <08F8827D-D8C3-4922-AC39-6C71ADBE8BDB@corp.arin.net> <20110206014014.GG22325@vacation.karoshi.com> <849FDB3F-EE29-48D6-8ECD-70AE6EB0B157@virtualized.org> <71571.1297311453@nsa.vix.com> Message-ID: <20110210154906.GF6879@puck.nether.net> On Thu, Feb 10, 2011 at 01:13:49AM -0600, Jimmy Hess wrote: > Perhaps the RIRs should personally and directly ask each /8 legacy > holder to provide > account of their utilization (which portions of the allocation is > used, how many hosts), > and ASK for each unused /22 [or shorter] to be returned. And then they (read: their attorneys) fire back a "okay, who are you, and why do you have the right to ask us this question?" Or they cheerfully engage in some vigorous handwaving. Most of us living in a dual stack world really do not need any more prefixes advertised, so cutting a bunch of discrete /22s out of a /8 is not helpful. The only people this benefits are the very few that might get some of the space. Even in the best possible situation (an entire /8 returned,) which they'd be under NO obligation to consider doing -- it'd last a few weeks. Under your scenario, you might scrounge together enough /22s to last an RIR a couple of days. Then what? That's an awful lot of pain for not much benefit. Can we move on and stop trying to squeeze prefixes from legacy holders? What's done is done. --msa From jbates at brightok.net Thu Feb 10 09:53:24 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 10 Feb 2011 09:53:24 -0600 Subject: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> Message-ID: <4D5409F4.4070907@brightok.net> On 2/10/2011 8:36 AM, Benson Schliesser wrote: > DS-lite is still CGN. It is still LSN, but it is not NAT444, and the failure rate reduces because of that. Also, DS-Lite guarantees that you have IPv6 connectivity. NAT444 makes no such assertion. Jack From lowen at pari.edu Thu Feb 10 09:53:58 2011 From: lowen at pari.edu (Lamar Owen) Date: Thu, 10 Feb 2011 10:53:58 -0500 Subject: Failure modes: NAT vs SPI In-Reply-To: <5D2BCD6C-894B-40C2-94A9-DAD0F8EC2865@delong.com> References: <13040078.4555.1296760192315.JavaMail.root@benjamin.baylink.com> Message-ID: <201102101053.59300.lowen@pari.edu> On Monday, February 07, 2011 04:33:23 am Owen DeLong wrote: > 1. Scanning even an entire /64 at 1,000 pps will take 18,446,744,073,709,551 seconds > which is 213,503,982,334 days or 584,542,000 years. > > I would posit that since most networks cannot absorb a 1,000 pps attack even without > the deleterious effect of incomplete ND on the router, no network has yet had even > a complete /64 scanned. IPv6 simply hasn't been around that long. Sounds like a job for a 600 million node botnet. You don't think this hasn't already crossed botnet ops minds? From bensons at queuefull.net Thu Feb 10 10:05:54 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Thu, 10 Feb 2011 10:05:54 -0600 Subject: Looking for an IPv6 naysayer... In-Reply-To: <4D5409F4.4070907@brightok.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> Message-ID: On Feb 10, 2011, at 9:53 AM, Jack Bates wrote: > On 2/10/2011 8:36 AM, Benson Schliesser wrote: >> DS-lite is still CGN. > > It is still LSN, but it is not NAT444, and the failure rate reduces because of that. Also, DS-Lite guarantees that you have IPv6 connectivity. NAT444 makes no such assertion. DS-lite *uses* IPv6 connectivity, it doesn't provide it. That's like saying 6rd or 6to4 "guarantees you have IPv4 connectivity". As for NAT444 (or double-NAT): One could just as easily deploy DS-lite with a NAT444 configuration. Or deploy CGN without NAT444 (e.g. CGN44, by managing subnets delegated to each subscriber). The two topics are related but separate. In terms of CGN44 versus NAT444, I'd like to see evidence of something that breaks in NAT444 but not CGN44. People seem to have a gut expectation that this is the case, and I'm open to the possibility. But testing aimed at demonstrating that breakage hasn't been very scientific, as discussed in the URLs I posted with my previous message. Cheers, -Benson From jbates at brightok.net Thu Feb 10 10:18:39 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 10 Feb 2011 10:18:39 -0600 Subject: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> Message-ID: <4D540FDF.8080405@brightok.net> On 2/10/2011 10:05 AM, Benson Schliesser wrote: > DS-lite *uses* IPv6 connectivity, it doesn't provide it. That's like > saying 6rd or 6to4 "guarantees you have IPv4 connectivity". > Who in their right mind would feed IPv6 to a CPE, deploy a CPE that supports DS-Lite, and NOT give out prefixes? > In terms of CGN44 versus NAT444, I'd like to see evidence of > something that breaks in NAT444 but not CGN44. People seem to have a > gut expectation that this is the case, and I'm open to the > possibility. But testing aimed at demonstrating that breakage hasn't > been very scientific, as discussed in the URLs I posted with my > previous message. To even determine your public IP address, you must ask someone on the other side of the NAT, this applies also when you are doing udp hole punches. So what happens when you try and talk to you neighbor? Who's going to tell you what you need to know between your NAT and the providers NAT? This is one way that NAT444 breaks more than NAT44 (even in LSN configurations) And yes, I find that neighbors do like to play with one another, and most LSNs don't support hair pinning translations between customers (most NAT in general won't support that). Jack From matthew at matthew.at Thu Feb 10 10:43:50 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 10 Feb 2011 08:43:50 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> Message-ID: <4D5415C6.80700@matthew.at> On 2/9/2011 9:15 PM, Ricky Beam wrote: > On Wed, 09 Feb 2011 16:42:14 -0500, Nathan Eisenberg > wrote: >> What do you mean, lit up? You mean they're not in the routing tables >> that you get from your carriers? I'd argue that's no indication of >> whether they're in use or not. > > That's pretty much the definition of "in use". If they don't appear > in the global routing table, then they aren't being used. There is no one universal "global routing table". They probably appear in someone's routing table, somewhere... just not yours. If Cogent stops peering with you (I picked them, because that's not out of the question) and you stop seeing all their downstream routes, did those addresses suddenly become available for reassignment? > I cannot send traffic to them; they cannot send traffic to me. That's true of almost all addresses these days, what with firewalls and all. > > In my recent probe of route servers, I found 22 legacy /8's that were > partly or completely unused. I'm a little surprised ARIN/ICANN thinks > it's a waste of time to even try to reclaim them. How many days do you think a single /8 lasts at current assignment rates? How would ARIN/ICANN go about reclaiming addresses that someone believes they are using but that you don't think are in use? Matthew Kaufman From owen at delong.com Thu Feb 10 11:13:28 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 10 Feb 2011 09:13:28 -0800 Subject: My upstream ISP does not support IPv6 In-Reply-To: References: <18699589.266.1296788654238.JavaMail.franck@franck-martins-macbook-pro.local> <4D50779E.40804@ispn.net> <4607E2A3-6C20-4FCF-A842-37497C5558B9@consultant.com> <018201cbc8e9$3b641120$b22c3360$@iname.com> <474CF0FC-1A42-4141-87A2-CDAD566AF8E1@delong.com> Message-ID: <5C6FDF78-F803-4090-ABD9-14CBA33ABB8E@delong.com> On Feb 10, 2011, at 4:50 AM, TR Shaw wrote: > > On Feb 10, 2011, at 1:26 AM, Owen DeLong wrote: > >> The problem is conversations like this: >> >> AT&T Customer Service: "AT&T uVerse, how can I help you?" >> >> Customer: "Yes, I have uVerse service and I'd like to get IPv6." >> >> AT&T Customer Service: "I pea vee what? Is this a prank call?" >> >> Owen >> > > The ATT cellular folks respond... > > ATT: "ATT Wireless. My name is ____ and I'm here to help" > > User: "My iPhone web browser can't reach sites like ipv6.google.com via your cellular network but it can over my wifi at home." > > ATT: "So you are having problems with your uVerse wireless connection?" > > ... after escalating to L2 support.... > > ATT: "So we will start be reseting your iPhone and then configure it for data access...." > > ...after 45 minutes... > > ATT: "Are you sure the website is valid? Let me check that website on my desktop here."... "Well, thats the problem! http://ipv6.google.com/ doesn't exist. I can't get to it via my desktop here at support. You need to use www instead of ipv6 and everything will be fine. Is there anything else I can help you with today?" > > > Seems equally problematic, no? Owen From kwallace at pcconnection.com Thu Feb 10 11:20:15 2011 From: kwallace at pcconnection.com (Wallace Keith) Date: Thu, 10 Feb 2011 12:20:15 -0500 Subject: Comcast BGP issue? Message-ID: <0E8773C725A1674E9F7B35EABB5EEEB10B4C9654@MKA134.pcc.int> Not quite sure what the issue is, but I suspect Comcast announcements are not quite right? Trying to get from Verizon Business to a Comcast address in NH (on 75.15.64.0/18), and it's going through San Jose. Anyone else having similar issues or suggestions? Opened a ticket with Comcast, but they want to check the cable modem (sigh) 6 6 ms 6 ms 6 ms 0.so-3-2-0.XL3.BOS4.ALTER.NET [152.63.22.178] 7 13 ms 14 ms 13 ms 0.xe-6-1-2.XL3.NYC4.ALTER.NET [152.63.0.166] 8 14 ms 46 ms 13 ms 0.ae3.BR3.NYC4.ALTER.NET [152.63.16.181] 9 14 ms 14 ms 13 ms te-7-0-0.edge2.NewYork2.level3.net [4.68.110.69] 10 13 ms 13 ms 14 ms vlan52.ebr2.NewYork2.Level3.net [4.69.138.254] 11 14 ms 14 ms 14 ms ae-6-6.ebr2.NewYork1.Level3.net [4.69.141.21] 12 85 ms 88 ms 90 ms ae-2-2.ebr4.SanJose1.Level3.net [4.69.135.185] 13 85 ms 85 ms 89 ms ae-94-94.csw4.SanJose1.Level3.net [4.69.134.254] 14 83 ms 83 ms 84 ms ae-4-99.edge1.SanJose1.Level3.net [4.68.18.206] 15 97 ms 95 ms 95 ms COMCAST-IP.edge1.SanJose1.Level3.net [4.79.43.134] 16 125 ms 125 ms 124 ms pos-0-14-0-0-cr01.denver.co.ibone.comcast.net [68.86.85.129] 17 135 ms 129 ms 125 ms pos-0-14-0-0-cr01.chicago.il.ibone.comcast.net [68.86.85.117] 18 122 ms 121 ms 121 ms pos-1-15-0-0-ar01.woburn.ma.boston.comcast.net [68.86.93.122] 19 128 ms 127 ms 127 ms po-66-ur02.manchester.nh.boston.comcast.net [68.85.69.170] 20 123 ms 121 ms 121 ms 68.85.161.226 21 116 ms 118 ms 119 ms x-x-x-x-newengland.hfc.comcastbusiness.net [75.150.80.x] -Keith From kwallace at pcconnection.com Thu Feb 10 12:15:02 2011 From: kwallace at pcconnection.com (Wallace Keith) Date: Thu, 10 Feb 2011 13:15:02 -0500 Subject: Comcast BGP issue? In-Reply-To: <0E8773C725A1674E9F7B35EABB5EEEB10B4C9654@MKA134.pcc.int> References: <0E8773C725A1674E9F7B35EABB5EEEB10B4C9654@MKA134.pcc.int> Message-ID: <0E8773C725A1674E9F7B35EABB5EEEB10B4C9725@MKA134.pcc.int> Sorry, my typo. The Net is 75.150.64.0/18 -----Original Message----- From: Wallace Keith Sent: Thursday, February 10, 2011 12:20 PM To: nanog at nanog.org Subject: Comcast BGP issue? Not quite sure what the issue is, but I suspect Comcast announcements are not quite right? Trying to get from Verizon Business to a Comcast address in NH (on 75.15.64.0/18), and it's going through San Jose. Anyone else having similar issues or suggestions? Opened a ticket with Comcast, but they want to check the cable modem (sigh) 6 6 ms 6 ms 6 ms 0.so-3-2-0.XL3.BOS4.ALTER.NET [152.63.22.178] 7 13 ms 14 ms 13 ms 0.xe-6-1-2.XL3.NYC4.ALTER.NET [152.63.0.166] 8 14 ms 46 ms 13 ms 0.ae3.BR3.NYC4.ALTER.NET [152.63.16.181] 9 14 ms 14 ms 13 ms te-7-0-0.edge2.NewYork2.level3.net [4.68.110.69] 10 13 ms 13 ms 14 ms vlan52.ebr2.NewYork2.Level3.net [4.69.138.254] 11 14 ms 14 ms 14 ms ae-6-6.ebr2.NewYork1.Level3.net [4.69.141.21] 12 85 ms 88 ms 90 ms ae-2-2.ebr4.SanJose1.Level3.net [4.69.135.185] 13 85 ms 85 ms 89 ms ae-94-94.csw4.SanJose1.Level3.net [4.69.134.254] 14 83 ms 83 ms 84 ms ae-4-99.edge1.SanJose1.Level3.net [4.68.18.206] 15 97 ms 95 ms 95 ms COMCAST-IP.edge1.SanJose1.Level3.net [4.79.43.134] 16 125 ms 125 ms 124 ms pos-0-14-0-0-cr01.denver.co.ibone.comcast.net [68.86.85.129] 17 135 ms 129 ms 125 ms pos-0-14-0-0-cr01.chicago.il.ibone.comcast.net [68.86.85.117] 18 122 ms 121 ms 121 ms pos-1-15-0-0-ar01.woburn.ma.boston.comcast.net [68.86.93.122] 19 128 ms 127 ms 127 ms po-66-ur02.manchester.nh.boston.comcast.net [68.85.69.170] 20 123 ms 121 ms 121 ms 68.85.161.226 21 116 ms 118 ms 119 ms x-x-x-x-newengland.hfc.comcastbusiness.net [75.150.80.x] -Keith From rubensk at gmail.com Thu Feb 10 13:27:26 2011 From: rubensk at gmail.com (Rubens Kuhl) Date: Thu, 10 Feb 2011 17:27:26 -0200 Subject: Self-referential whois queries Message-ID: I'm noticing an increase in getting "query rate exceeded" at whois services that might be connected to a symptom described by ARIN at NANOG 48/ARIN XXV and ARIN XXVI where machines ask for the whois record of their own IP address. Are there any clues of what is causing this ? Rubens From dr at cluenet.de Thu Feb 10 13:33:43 2011 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 10 Feb 2011 20:33:43 +0100 Subject: 10GBASE-T Switches In-Reply-To: <20110210150554.GB8961@angus.ind.WPI.EDU> References: <12EFAA890B74E14782EFB259E5A63ABC21458A4B@GEMINI2.psi.corp> <20110210150554.GB8961@angus.ind.WPI.EDU> Message-ID: <20110210193343.GA16971@srv03.cluenet.de> On Thu, Feb 10, 2011 at 10:05:54AM -0500, Chuck Anderson wrote: > Juniper EX4500 has 40 fixed SFP/SFP+ ports plus 2 uplink modules that > can contain 4 SFP/SFP+ ports each for a total of 48 10GBASE-X ports. Be aware, that IGMP snooping breaks some(!) IPv6 multicast (e.g. DHCPv6). Affects whole EX-series and current plan is to fix it sometime end of year (Q4 release). If you use IPv4 multicast and need IGMP snooping to prevent flooding and plan to use e.g. stateful DHCPv6, that might be a showstopper for now and the VLANs where IGMP snooping is enabled. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From ADWebb at dstsystems.com Thu Feb 10 13:38:35 2011 From: ADWebb at dstsystems.com (ADWebb at dstsystems.com) Date: Thu, 10 Feb 2011 13:38:35 -0600 Subject: ARIN and IPv6 Requests Message-ID: Why does ARIN require detailed usage of IPv4 space when requesting IPv6 space? Seems completely irrelevant to me. -- Adam Webb EN & ES Team desk: 816.737.9717 cell: 916.949.1345 --------------------------------------- The biggest secret of innovation is that anyone can do it. --------------------------------------- ----------------------------------------- Please consider the environment before printing this email and any attachments. This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system. From dr at cluenet.de Thu Feb 10 13:42:52 2011 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 10 Feb 2011 20:42:52 +0100 Subject: 10GBASE-T Switches In-Reply-To: <20110210193343.GA16971@srv03.cluenet.de> References: <12EFAA890B74E14782EFB259E5A63ABC21458A4B@GEMINI2.psi.corp> <20110210150554.GB8961@angus.ind.WPI.EDU> <20110210193343.GA16971@srv03.cluenet.de> Message-ID: <20110210194252.GB16971@srv03.cluenet.de> On Thu, Feb 10, 2011 at 08:33:43PM +0100, Daniel Roesen wrote: > On Thu, Feb 10, 2011 at 10:05:54AM -0500, Chuck Anderson wrote: > > Juniper EX4500 has 40 fixed SFP/SFP+ ports plus 2 uplink modules that > > can contain 4 SFP/SFP+ ports each for a total of 48 10GBASE-X ports. > > Be aware, that IGMP snooping breaks some(!) IPv6 multicast (e.g. > DHCPv6). Affects whole EX-series and current plan is to fix it sometime > end of year (Q4 release). If you use IPv4 multicast and need IGMP > snooping to prevent flooding and plan to use e.g. stateful DHCPv6, that > might be a showstopper for now and the VLANs where IGMP snooping is > enabled. I should add that we're quite happy with the EX4500 on the features it has (want QinQ yesterday, prettypretty please). No datacenter usage though. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From nick at flhsi.com Thu Feb 10 13:40:51 2011 From: nick at flhsi.com (Nick Olsen) Date: Thu, 10 Feb 2011 14:40:51 -0500 Subject: ARIN and IPv6 Requests Message-ID: <6aacabfd$67a3507c$6792f96a$@com> We requested our initial allocation without any such questions. Is this your initial or additional? Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: ADWebb at dstsystems.com Sent: Thursday, February 10, 2011 2:38 PM To: nanog at nanog.org Subject: ARIN and IPv6 Requests Why does ARIN require detailed usage of IPv4 space when requesting IPv6 space? Seems completely irrelevant to me. -- Adam Webb EN & ES Team desk: 816.737.9717 cell: 916.949.1345 --------------------------------------- The biggest secret of innovation is that anyone can do it. --------------------------------------- ----------------------------------------- Please consider the environment before printing this email and any attachments. This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system. From dr at cluenet.de Thu Feb 10 13:50:01 2011 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 10 Feb 2011 20:50:01 +0100 Subject: IPv6 - a noobs prespective In-Reply-To: References: <4D52DB6E.9080009@brightok.net> Message-ID: <20110210195001.GC16971@srv03.cluenet.de> On Wed, Feb 09, 2011 at 03:43:35PM -0500, Jared Mauch wrote: > > Jack (hates all routers equally, doesn't matter who makes it) > > Welcome to the life of being a network operator. :) That's called "carrier grade" these days by all those vendors! :-) SCNR, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From ADWebb at dstsystems.com Thu Feb 10 13:50:02 2011 From: ADWebb at dstsystems.com (ADWebb at dstsystems.com) Date: Thu, 10 Feb 2011 13:50:02 -0600 Subject: ARIN and IPv6 Requests In-Reply-To: <6aacabfd$67a3507c$6792f96a$@com> References: <6aacabfd$67a3507c$6792f96a$@com> Message-ID: Initial. Documenting IPv4 usage is in the request template. -- Adam Webb From: "Nick Olsen" To: Date: 02/10/2011 01:45 PM Subject: re: ARIN and IPv6 Requests We requested our initial allocation without any such questions. Is this your initial or additional? Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: ADWebb at dstsystems.com Sent: Thursday, February 10, 2011 2:38 PM To: nanog at nanog.org Subject: ARIN and IPv6 Requests Why does ARIN require detailed usage of IPv4 space when requesting IPv6 space? Seems completely irrelevant to me. -- Adam Webb EN & ES Team desk: 816.737.9717 cell: 916.949.1345 --------------------------------------- The biggest secret of innovation is that anyone can do it. --------------------------------------- ----------------------------------------- Please consider the environment before printing this email and any attachments. This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system. From kauer at biplane.com.au Thu Feb 10 13:52:07 2011 From: kauer at biplane.com.au (Karl Auer) Date: Fri, 11 Feb 2011 06:52:07 +1100 Subject: 10GBASE-T Switches In-Reply-To: <20110210193343.GA16971@srv03.cluenet.de> References: <12EFAA890B74E14782EFB259E5A63ABC21458A4B@GEMINI2.psi.corp> <20110210150554.GB8961@angus.ind.WPI.EDU> <20110210193343.GA16971@srv03.cluenet.de> Message-ID: <1297367527.25439.23.camel@karl> On Thu, 2011-02-10 at 20:33 +0100, Daniel Roesen wrote: > Be aware, that IGMP snooping breaks some(!) IPv6 multicast (e.g. > DHCPv6). Affects whole EX-series and current plan is to fix it sometime > end of year (Q4 release). If you use IPv4 multicast and need IGMP > snooping to prevent flooding and plan to use e.g. stateful DHCPv6, that > might be a showstopper for now and the VLANs where IGMP snooping is > enabled. Not disagreeing, I've never met this device, just curious about the problem and wondering if it is a generic class of problem. Is this device supposed to be IPv6-capable? If so, IGMP snooping and MLD snooping should be able to coexist, I'd have thought. In fact, it will be a major blow for the future of dual-stacking if they can't. So is the problem of which you speak just a bug, or is it an artifact of the switch not being IPv6 capable and so limiting broadcasts at the ethernet level to IGMP-discovered listeners only, ignoring IPv6 multicast listeners? Or something :-) Also. why does it only affect DHCPv6? Or was that just an example of a service that would be affected by the problem? Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From exstatica at gmail.com Thu Feb 10 14:01:51 2011 From: exstatica at gmail.com (Andrew Matthews) Date: Thu, 10 Feb 2011 12:01:51 -0800 Subject: box.net network engineer Message-ID: Can someone with the box.net engineering group email me off list. I have a peering issue with you guys at any2 in socal. Thanks, Drew From owen at delong.com Thu Feb 10 14:09:39 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 10 Feb 2011 12:09:39 -0800 Subject: Looking for an IPv6 naysayer... In-Reply-To: <4D53FDA2.8050304@nic-naa.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E59B.4070904@nic-naa.net> <6E2D8385-77A1-4408-B12B-A7F61FDCC3EF@delong.com> <4D531E85.3000005@nic-naa.net> <0CA94927-95DB-4C36-9B55-C891151729FB@delong.com> <4D53FDA2.8050304@nic-naa.net> Message-ID: <7D5EC021-DD50-4E3A-9916-8CE32C840645@delong.com> On Feb 10, 2011, at 7:00 AM, Eric Brunner-Williams wrote: > On 2/9/11 10:32 PM, Owen DeLong wrote: >> >> On Feb 9, 2011, at 3:08 PM, Eric Brunner-Williams wrote: >> >>>> I disagree... I think that offering alternate name space views to the existing {b,m}illions of v4 addressed spindles requires IPv6 reachability as well since those will also be adding IPv6 capabilities in the next year or two. >>> >>> so your claim is that to have a .cat, serving registrants currently using v4 provisioned hosting services, and end-users currently using v4 provisioned eyeball networks, and initially address and resources (but not names) currently extant in the com/net/org/biz/info namespaces [1], the .cat registry first has to be v6 reachable. >>> >> My claim is that about the time these zones are rolling out, the registrants currently using v4 provisioned hosting services and end users currently using v4 provisioned eyeball networks will also, at least in some cases, be using dual stack and/or v6 services. > > "in some cases" is a poor motivation for a general mandatory-to-implement requirement. a "v6 where required (by other market actors than icann's legal staff in marina del rey)" form would be appropriate -- but you're making a universal claim, so on we go... > I said "at least in some cases". Since we know that it will be a monotonically increasing set of "some cases" which will rapidly grow to a very high fraction of "some cases", yes, it is a good motivation for a general mandatory-to-implement requirement. > inter alia, that both ends of the chain of resolution (stub resolver on an eyeball network and mapped resource in a hosting provider rack) may be using dual-stack fails to motivate why the authoritative name to address resolver must be v6 reachable. > We can agree to disagree about this. >>> and this claim is true because the webhosting operators, primarily in Catalonia, who have v4 now, will themselves be v6 reachable in the next year or two ... i think this requires either the existing hosting operators abandon vhosting as a service model or abandon their existing v4 allocations. >>> >> You do not have to abandon v4 to deploy v6. That's an absurd claim. > > yet it is the claim you are making. the resource must be v6 reachable, and you're not offering arbitrary capriciousness of some evangelically unbalanced lawyers in a high-rise in marina del ray as a rational, so you must have a material necessity rational. > No, it is not. I am claiming that you need to have IPv6 capabilities on critical internet infrastructure because: + The internet is moving to IPv6. + We will be out of free IPv4 addresses by the time these services are being deployed. + A monotonically increasing number of clients will have no or limited/degraded IPv4 access at or soon after deployment of these new GTLDs. >>> now rinse and repeat for .nyc. the claim is somehow that the market for hosting operators (ok, the hosting lines of business of godaddy, tucows, enom, netsol, ... and their downstream resellers, which is statistically likely to have 51% of all .nyc registrations), and/or (your choice) the eyeball network operators for the tri-state area, are going to either abandon vhosting as a service model or abandon their existing v4 allocations ... >>> >> Again, the need for v6 is not predicated on the abandonment of v4. > > you've managed to elide responding to both (a) an actual new (in 2005) registry, with existing v4 provisioning, and (b) a pending new (in 2012) registry, again with existing v4 provisioning. > > i look forward to learning why .cat failed for lack of v6, and why .nyc will fail, for lack of v6, in a sentence that doesn't contain a reference to lawyers in a high-rise in marina del ray. > I never claimed that .cat failed because of lack of IPv6 as I have no first hand knowledge of the failure of .cat. I never claimed that .nyc would fail because of lack of IPv6. I don't know whether either of those claims is true. If either claim is true, then, certainly, it would be evidence that we need IPv6 for new deployments of critical infrastructure that it is a valid requirement for new GTLDs. However, even if both claims are false, it does not eliminate the need for new GTLDs to provide support for IPV6. There are no lawyers in Marina Del Rey in these statements: + The internet is moving to IPv6. + We will be out of free IPv4 addresses by the time these services are being deployed. + A monotonically increasing number of clients will have no or limited/degraded IPv4 access at or soon after deployment of these new GTLDs. + In a world where there are IPv4 only, IPv4/IPv6 dual stack and IPv6 only hosts, critical infrastructure such as GTLD services should be required to be dual-stack. >>> where the v6 ab initio convinces me some is the area i currently work on -- developing economies. nigeria is a good example, fewer than 10^^5 computers, a population of 15x10^^7, and cell phone penetration rate approaching 1 in 3. even so, the number of v6 prefixes in afnic's inventory of allocations is ... very small ... for all of africa as a region. >>> >> I believe AfriNIC has a /12 like any other RIR. I'm not sure what you are saying here. > > try looking beyond what the iana has allocated to a rir, and look at what prefixes the rir has allocated. alternatively, something along the lines of trivial pursuits, name the data centers and/or eyeball networks in africa in which v6 was deployed in q42010. > I guess your point is that AfriNIC and Africa in general is behind the rest of the world in IPv6 deployment? I'm not sure how that is relevant to the fact that IPv6 is a valid requirement for new GTLD infrastructure other than to say that dropping this requirement might impact Africa less than other parts of the world. >>>> It's not that I think you only serve the future. It's that we think you are failing to recognize that IPv6 is now >>>> and that what is IPv4 today will be at least dual-stack tomorrow. >>> >>> if the window for applications opens 4 months after icann-41 (amman, jordan), in q42011, then delegations will occur as soon as q32012. >>> >> Yes. >> >>> is your claim that registry operators where v6 is _sparce_, and/or where v6 eyeball networks are _sparce_, two years from today, are properly failed for technical reasons, two years from today, for lack of v6 capability? >>> >> I'm not sure what you mean by _sparce_. > > See africa, v6 availability, above. > Oh, you mean sparse and the_..._ is for emphasis. I thought it was offsetting some special word. Sorry for the misunderstanding. My claim is that if you are running GTLD services, then, you are dealing not with any particular region, but, with providing global infrastructure. The sparseness of IPv6 infrastructure in Africa is not particularly relevant to the question of whether or not global infrastructure needs to support IPv6 going forward. >> My claim is that by 4q2012, I expect we will see much much wider IPv6 deployment and potentially eyeball >> networks that are primarily or exclusively IPv6 with at best limited or degraded IPv4 support through multiple >> layers of NAT. > > now that is an interesting claim. suppose it is true and there is "at best limited or degraded IPv4" on eyeball networks. why is a once per session trip up and down the chain of resolution sufficient to motivate anything? > Are you serious? If it's not, then we don't really need GTLDs at all, do we? > further, why do you suppose that new gtld registries, but not existing gtld registries, have an affirmative duty to be v6 reachable from resolvers on v6-only eyeball networks? > I never said existing gtld registries don't have such an affirmative duty. I think ICANN severely erred in not including IPv6 in the provisions of earlier contracts. I have said that before this topic ever came up. The fact that ICANN made a mistake previously does not mean we should expand that mistake or continue making that mistake. > what is the point of partitioning content along "legacy v4 provisioned content, and its v4 provisioned access demographic" and "new gtld mapped content and its v6 provisioned access demographic"? > What? I'm not trying to partition anything. I'm trying to make sure that any new GTLDs support access from the entire internet and not just the limited and diminishing proportion of the internet that has IPv4 going forward. > to be really convincing, it would help if you'd make the case that existing v4-reachable-only registries must be v6 reachable or fail, just as you'd fail a new gtld applicant lacking v6. > I absolutely think that existing v4-reachable-only registries must be v6 reachable or fail. They may not fail quite so immediately, but, again, I absolutely believe ICANN erred in not making this a requirement for those registries. I certainly don't see using a previous mistake as a reason that we should extend or expand that mistake to new registries. >> As such, I think that registries spinning up in 3q2012 should be required to have IPv6 support. yes. > > see above. See answers above. >> >>> if your claim is that v6 is mandatory to implement sometime soon, i'm fine with that rather flexible temporal requirement, but icann's current rules of the road are an application that isn't v6 ready at transition to delegation (roughly two years from now) fails. >>> >> If you define soon as prior to 2q2012, then, yes, I'm fine with that. However, that seems to be about a quarter >> earlier than you think these things will be starting up. Since you seem to be claiming they should get some >> period beyond that where they don't need to run IPv6 (I'm not sure where they're supposed to get their >> addresses to run on IPv4 by then, frankly), I think your definition of soon and mine are probably not >> compatible. > > first, refer to the statistical likelihood date of v4 exhaustion in the afnic region. there's a nice graph available that shows very broad shoulders, several years of availability. > We're talking about GTLD registries, not African CCTLD registries. GTLDs are GLOBAL. Look at the v4 exhaustion graphs for APNIC, ARIN, and RIPE. The fact that you can point to a single region that some prognosticators say will have space for a few years longer than everyone else really isn't a relevant argument against the need for GTLDs to support IPv6. > second, registries are critical internet infrastructure, and in the arin region prop 125, which you know about having commented on it, there exists a policy of reserve for ci requirements, and 125 provides for three (3) years of resource availability to the allocation receiving ci requester. requesting a 125-similar policy for the rir with the next most proximal statistical likelihood date of v4 exhaustion, the ripe region, is on my todo list. > Again, not seeing relevance here. I have no belief that registries don't need IPv4 support. GTLD registries should absolutely be required to support both protocols until such time as IPv4 can be deprecated in general. > note however, that few applications for registries located in the arin or ripe regions, where the statistical likelihood date of v4 exhaustion is both most proximal, and the confidence level narrowest, are likely to meet the general reading of the icann board of directors' resolution #20 (nairobi), expressing an interest in forms of cost-reduction assistance to needy applicants, e.g., from "developing countries". > I really don't see how that is relevant to whether GTLD registries should be required to have IPv6 support or not. Regardless of where the registry is based, they are providing a global service. They should be required to support the global internet. >>> pessimally, the requirement is present at the date when applications are submitted, that is, a year from today. >>> >> I don't think that 1q2012 is especially out of line given a 2q2012 target date. >> >>> now there's still 24 months for icann legal staff to acquire clue, and for last week's press event to galvanize operators everywhere, so perhaps this (and its cognate, dnssec at transition to delegation) can be elided, but it is irresponsible to assert [2], independent of the purpose and position of a registry, that it must have a feature due to the universalist claims of advocates for a particular technology. >>> >> I think it is irresponsible at this point to consider deploying any major network infrastructure without requiring IPv6 capabilities at deployment. IANA is already out of IPv4. If you expect these systems to start getting deployed in 3q2012, then, you're talking about a time which is likely to be well past RIR exhaustion in most cases. I suppose they can get a /22 from APNIC, but, other than that, where do you expect these organizations to even get IPv4 to work with? > > just how many endpoint identifiers do you think a registry requires? > I don't know. I presume that they need a handful for DNS servers, some for web servers, some for miscellaneous infrastructure. > i don't think this is your best argument, as it requires a suspension of belief that there is a market, or markets, in allocations sufficient to provision anything from a half-rack to multiple racks in a standard cage, and the margin on a registry footprint is lower than the margin on most other hosting operations. > You're right. For the time being, it probably won't be hard for them to obtain IPv4 resources and that really isn't relevant to whether or not they need to provide services over IPv6. The relevant part is the number of potential people trying to use their services that may not have IPv4 access. > if you're going to swing for the fence, don't try to argue lack of something that can still be bought for some time to come. make the claim that registrants (other than ppc registrants, that's a separate case you may want to make, and if so, don't forget the eyeball network operator as a beneficiary from systemic synthetic return, a la verisign's sitefinder) demand that their resources be resolvable by v6 only paths because there is sufficient revenue in v6 reachability, or that v6 only registrations will, in the twelve quarters of operation, provide more revenue, or at least enough to cover costs and reduce the likelihood of registry failure, than the v4 only registrations. > As I said. I think that registries should be required to support both protocols as a simple matter of compatibility with the state of the global internet during the time of their service. It would be absurd to allow a registry with support only for IPX. A such, in the internet that will exist during the terms of these contracts, it would be absurd to allow a registry without support for both IPv4 and IPv6. However, I can see the possibility of a case where a registry is actually unable to get sufficient IPv4 resources during the contract period. In such a case, I do not believe that inability should be held against them. However, with regards to IPv6, there is no such excuse. > having made any case based upon benefit, it would be illuminating to opine why no existing registry operator is experiencing v6 uptake by its registrants supporting a registrant beneficiary theory. > The case for benefit is not there yet. However, as you pointed out, everything we're talking about is 18-24 months away from operations, so, the case will change a lot in that time. The case that is there now is the fact that we all know the internet is changing and that IPv4 addresses are becoming scarce. Deployment of critical infrastructure without dual stack (or at least IPv6) support at this point is irresponsible going forward. >>> thanks for your difference, >>> -e >>> >> Any time. > > less religion, more near-term numbers. t.i.a. > No problem. Owen From jtk at cymru.com Thu Feb 10 14:17:59 2011 From: jtk at cymru.com (John Kristoff) Date: Thu, 10 Feb 2011 14:17:59 -0600 Subject: Self-referential whois queries In-Reply-To: References: Message-ID: <20110210141759.46f7dd5c@t61p> On Thu, 10 Feb 2011 17:27:26 -0200 Rubens Kuhl wrote: > I'm noticing an increase in getting "query rate exceeded" at whois > services that might be connected to a symptom described by ARIN at > NANOG 48/ARIN XXV and ARIN XXVI where machines ask for the whois > record of their own IP address. > > Are there any clues of what is causing this ? Some spam bots do these automated self-referential queries, but if you are seeing those rate exceeded messages when you perform queries from your client, you may simply be probably bumping up against a limit for the source host or network in question. John From jason.iannone at gmail.com Thu Feb 10 14:18:45 2011 From: jason.iannone at gmail.com (Jason Iannone) Date: Thu, 10 Feb 2011 13:18:45 -0700 Subject: ARIN and IPv6 Requests In-Reply-To: References: <6aacabfd$67a3507c$6792f96a$@com> Message-ID: It also looks like there isn't a policy for orgs with multiple multihomed sites to get a /48 per site. Is there an exception policy somewhere? On Thu, Feb 10, 2011 at 12:50 PM, wrote: > Initial. Documenting IPv4 usage is in the request template. > > -- > Adam Webb > > > > > > From: > "Nick Olsen" > To: > > Date: > 02/10/2011 01:45 PM > Subject: > re: ARIN and IPv6 Requests > > > > We requested our initial allocation without any such questions. Is this > your initial or additional? > > Nick Olsen > Network Operations > (855) FLSPEED ?x106 > > ---------------------------------------- > > From: ADWebb at dstsystems.com > Sent: Thursday, February 10, 2011 2:38 PM > To: nanog at nanog.org > Subject: ARIN and IPv6 Requests > > Why does ARIN require detailed usage of IPv4 space when requesting IPv6 > space? Seems completely irrelevant to me. > > -- > Adam Webb > EN & ES Team > desk: 816.737.9717 > cell: 916.949.1345 > --------------------------------------- > The biggest secret of innovation is that anyone can do it. > --------------------------------------- > > ----------------------------------------- > Please consider the environment before printing this email and any > attachments. > > This e-mail and any attachments are intended only for the > individual or company to which it is addressed and may contain > information which is privileged, confidential and prohibited from > disclosure or unauthorized use under applicable law. ?If you are > not the intended recipient of this e-mail, you are hereby notified > that any use, dissemination, or copying of this e-mail or the > information contained in this e-mail is strictly prohibited by the > sender. ?If you have received this transmission in error, please > return the material received to the sender and delete all copies > from your system. > > > From cabenth at gmail.com Thu Feb 10 14:25:57 2011 From: cabenth at gmail.com (Eric Clark) Date: Thu, 10 Feb 2011 12:25:57 -0800 Subject: ARIN and IPv6 Requests In-Reply-To: References: <6aacabfd$67a3507c$6792f96a$@com> Message-ID: Don't remember about the v4 part, but 3 years ago they issued me a /48, specifically for my first site and indicated that a block was reserved for additional sites. I can probably dig that up. Sent from my iPad On Feb 10, 2011, at 12:18 PM, Jason Iannone wrote: > It also looks like there isn't a policy for orgs with multiple > multihomed sites to get a /48 per site. Is there an exception policy > somewhere? > > On Thu, Feb 10, 2011 at 12:50 PM, wrote: >> Initial. Documenting IPv4 usage is in the request template. >> >> -- >> Adam Webb >> >> >> >> >> >> From: >> "Nick Olsen" >> To: >> >> Date: >> 02/10/2011 01:45 PM >> Subject: >> re: ARIN and IPv6 Requests >> >> >> >> We requested our initial allocation without any such questions. Is this >> your initial or additional? >> >> Nick Olsen >> Network Operations >> (855) FLSPEED x106 >> >> ---------------------------------------- >> >> From: ADWebb at dstsystems.com >> Sent: Thursday, February 10, 2011 2:38 PM >> To: nanog at nanog.org >> Subject: ARIN and IPv6 Requests >> >> Why does ARIN require detailed usage of IPv4 space when requesting IPv6 >> space? Seems completely irrelevant to me. >> >> -- >> Adam Webb >> EN & ES Team >> desk: 816.737.9717 >> cell: 916.949.1345 >> --------------------------------------- >> The biggest secret of innovation is that anyone can do it. >> --------------------------------------- >> >> ----------------------------------------- >> Please consider the environment before printing this email and any >> attachments. >> >> This e-mail and any attachments are intended only for the >> individual or company to which it is addressed and may contain >> information which is privileged, confidential and prohibited from >> disclosure or unauthorized use under applicable law. If you are >> not the intended recipient of this e-mail, you are hereby notified >> that any use, dissemination, or copying of this e-mail or the >> information contained in this e-mail is strictly prohibited by the >> sender. If you have received this transmission in error, please >> return the material received to the sender and delete all copies >> from your system. >> >> >> > From dr at cluenet.de Thu Feb 10 14:28:22 2011 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 10 Feb 2011 21:28:22 +0100 Subject: 10GBASE-T Switches In-Reply-To: <1297367527.25439.23.camel@karl> References: <12EFAA890B74E14782EFB259E5A63ABC21458A4B@GEMINI2.psi.corp> <20110210150554.GB8961@angus.ind.WPI.EDU> <20110210193343.GA16971@srv03.cluenet.de> <1297367527.25439.23.camel@karl> Message-ID: <20110210202822.GB19790@srv03.cluenet.de> Hi, On Fri, Feb 11, 2011 at 06:52:07AM +1100, Karl Auer wrote: > Not disagreeing, I've never met this device, just curious about the > problem and wondering if it is a generic class of problem. > > Is this device supposed to be IPv6-capable? We're using EX switches currently only in L2-only roles, cannot comment on L3. > If so, IGMP snooping and MLD snooping should be able to coexist, I'd > have thought. MLD snooping wasn't enabled (EX4500 doesn't even support it yet) so that's no factor. Expected behaviour would be to flood any IPv6 multicast frames to all ports in a VLAN. We've found the bug on EX3200-24T btw. but JTAC confirms it affects all EX series. > So is the problem of which you speak just a bug, or is it an artifact of > the switch not being IPv6 capable and so limiting broadcasts at the > ethernet level to IGMP-discovered listeners only, ignoring IPv6 > multicast listeners? Or something :-) > > Also. why does it only affect DHCPv6? Or was that just an example of a > service that would be affected by the problem? Example of a frame (DHCPv6 SOLICIT) which is not being passed with IGMP snooping enabled: 00:1a:64:99:0f:5c > 33:33:00:01:00:02, ethertype 802.1Q (0x8100), length 118: vlan 633, p 0, ethertype IPv6, (hlim 1, next-header UDP (17) payload length: 60) fe80::21a:64ff:fe99:f5c.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=be0a2d (client-ID hwaddr/time type 1 time 345579243 001a64990f5c) (option-request DNS DNS-name) (elapsed-time 725) (IA_NA IAID:1687752540 T1:3600 T2:5400)) L3/L2 destination address is all-dhcpv6-agents. IPv6 RA (destination "all nodes") are being passed just fine, e.g.: 20:24:35.480395 00:26:cb:d5:8b:d9 > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 86: (class 0xe0, hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::226:cbff:fed5:8bd9 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 32 My guess is that L2 filters aren't being properly handled by the IGMP snooping feature - not permitting 33:33:*, but e.g. only 33:33:00:00:00:* or so. We didn't poke around to find out exactly which multicast destination MACs do work and which don't. What surprises me, that this hasn't come up in "enterprise LAN" type of testing IGMP+MLDv2 snooping I'd consider a "must" there, and DHCPv6 a basic requirement in enterprise IPv6 deployments. PR/456700 Looks like that bug will see its second birthday in summer. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From rubensk at gmail.com Thu Feb 10 14:38:47 2011 From: rubensk at gmail.com (Rubens Kuhl) Date: Thu, 10 Feb 2011 18:38:47 -0200 Subject: Self-referential whois queries In-Reply-To: <20110210141759.46f7dd5c@t61p> References: <20110210141759.46f7dd5c@t61p> Message-ID: >> I'm noticing an increase in getting "query rate exceeded" at whois >> services that might be connected to a symptom described by ARIN at >> NANOG 48/ARIN XXV and ARIN XXVI where machines ask for the whois >> record of their own IP address. >> >> Are there any clues of what is causing this ? > > Some spam bots do these automated self-referential queries, but if you > are seeing those rate exceeded messages when you perform queries from > your client, you may simply be probably bumping up against a limit for > the source host or network in question. The ceil seems to be at the joint whois chain, where a RIR can ask another RIR or NIR about an IP. RIRs/NIRs answering such queries with "It's you!" or "Self-referential queries not allowed" would be too harsh or a reasonable approach ? Rubens From bill at herrin.us Thu Feb 10 14:41:40 2011 From: bill at herrin.us (William Herrin) Date: Thu, 10 Feb 2011 15:41:40 -0500 Subject: ARIN and IPv6 Requests In-Reply-To: References: Message-ID: On Thu, Feb 10, 2011 at 2:38 PM, wrote: > Why does ARIN require detailed usage of IPv4 space when requesting IPv6 > space? Seems completely irrelevant to me. Hi Adam, I think it's a basic "who are you and why are you speaking to us?" question. If ARIN already knows you from previous registration activity (question 11) then you skip questions 13 and 14 (list IPv4 usage). Kind of like: why does a cop ask for your vehicle registration? He's already plugged your license plate into his computer, so he knows everything that's on the card. It's a spot check, an opportunity to see that something is amiss, requiring a closer look. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Thu Feb 10 14:52:08 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 10 Feb 2011 12:52:08 -0800 Subject: Failure modes: NAT vs SPI In-Reply-To: <201102101053.59300.lowen@pari.edu> References: <13040078.4555.1296760192315.JavaMail.root@benjamin.baylink.com> <201102101053.59300.lowen@pari.edu> Message-ID: <5ABC3394-4F04-4048-8F8C-6CA4509CC44A@delong.com> On Feb 10, 2011, at 7:53 AM, Lamar Owen wrote: > On Monday, February 07, 2011 04:33:23 am Owen DeLong wrote: >> 1. Scanning even an entire /64 at 1,000 pps will take 18,446,744,073,709,551 seconds >> which is 213,503,982,334 days or 584,542,000 years. >> >> I would posit that since most networks cannot absorb a 1,000 pps attack even without >> the deleterious effect of incomplete ND on the router, no network has yet had even >> a complete /64 scanned. IPv6 simply hasn't been around that long. > > Sounds like a job for a 600 million node botnet. You don't think this hasn't already crossed botnet ops minds? The point is that you DOS the network on traffic before you can usefully scan it. A 600 million node botnet scanning a /64 on a gigabit ethernet can still only successfully inject ~1,000,000 PPS or less. Even if we assum 1,000,000 pps success rate, you've only reduced the scan time to 584,542 years. Even if you're somehow able to get 600 million nodes to successfully inject 1,000,000,000 packets per second (an unachievable number in any present day technology) you still need 584 years to scan a single /64 subnet. Owen From owen at delong.com Thu Feb 10 14:58:20 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 10 Feb 2011 12:58:20 -0800 Subject: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> Message-ID: <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> On Feb 10, 2011, at 8:05 AM, Benson Schliesser wrote: > > On Feb 10, 2011, at 9:53 AM, Jack Bates wrote: > >> On 2/10/2011 8:36 AM, Benson Schliesser wrote: >>> DS-lite is still CGN. >> >> It is still LSN, but it is not NAT444, and the failure rate reduces because of that. Also, DS-Lite guarantees that you have IPv6 connectivity. NAT444 makes no such assertion. > > DS-lite *uses* IPv6 connectivity, it doesn't provide it. That's like saying 6rd or 6to4 "guarantees you have IPv4 connectivity". > > As for NAT444 (or double-NAT): One could just as easily deploy DS-lite with a NAT444 configuration. Or deploy CGN without NAT444 (e.g. CGN44, by managing subnets delegated to each subscriber). The two topics are related but separate. > I think that at the point where you go to NAT444 instead of tunneling the IPv4, it's Dual-Stack, but, not Dual-Stack-Lite. > In terms of CGN44 versus NAT444, I'd like to see evidence of something that breaks in NAT444 but not CGN44. People seem to have a gut expectation that this is the case, and I'm open to the possibility. But testing aimed at demonstrating that breakage hasn't been very scientific, as discussed in the URLs I posted with my previous message. > Technologies which depend on a rendezvous host that can know about both sides of both NATs in a private->public->private scenario will break in a private->private2->public->private2->private scenario. There are technologies and applications which depend on this. (I believe, among others, that's how many of the p2p systems work, no?) Owen From Ben.Kessler at zenetra.com Thu Feb 10 15:05:08 2011 From: Ben.Kessler at zenetra.com (R. Benjamin Kessler) Date: Thu, 10 Feb 2011 21:05:08 +0000 Subject: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> Message-ID: <0CFF54003CD92945994CF0C0F90D81B670B3F7@EXCH1-FWA1.zenetra.local> >From: William Herrin [mailto:bill at herrin.us] >* Carrier NAT... I spend most of my days fighting with "carriers" to actually carry bits from point A to point B like they're paid to do. I'm sick and tired of them blaming CPE for circuit bounces and outages that are magically "fixed" without us doing anything to CPE. I have absolutely ZERO confidence that the carriers can implement NAT on a global scale such that it works and actually provides decent customer service. (realizing that this broad characterization is probably unfair to many smaller carriers who actually give a crap; my daily pain is generally caused by the "Tier 1" guys) From bensons at queuefull.net Thu Feb 10 15:17:28 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Thu, 10 Feb 2011 15:17:28 -0600 Subject: NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> Message-ID: <4C060A07-4FA7-467B-8BA8-8D4D04A0BA9A@queuefull.net> On Feb 10, 2011, at 2:58 PM, Owen DeLong wrote: >> In terms of CGN44 versus NAT444, I'd like to see evidence of something that breaks in NAT444 but not CGN44. People seem to have a gut expectation that this is the case, and I'm open to the possibility. But testing aimed at demonstrating that breakage hasn't been very scientific, as discussed in the URLs I posted with my previous message. >> > Technologies which depend on a rendezvous host that can know about both sides of both NATs in a private->public->private > scenario will break in a private->private2->public->private2->private scenario. There are technologies and applications which > depend on this. (I believe, among others, that's how many of the p2p systems work, no?) This is an oft-repeated rumor, but as I stated in my recent message: the evidence doesn't support the theory. NAT traversal architectures that leverage "public" rendezvous such as STUN, etc, should continue to work and testing demonstrates this. The tiering of NAT does mean that "neighborhood-local" traffic must traverse the CGN, which is sub-optimal but not broken. Dynamic control protocols like UPNP are the only source of problems I'm aware of. Frequently, the solution for a given app is as simple as turning off UPNP. But in the near future, PCP will replace and/or augment UPNP and is more scalable. If you have more experience (not including rumors) that suggests otherwise, I'd very much like to hear about it. I'm open to the possibility that NAT444 breaks stuff - that feels right in my gut - but I haven't found any valid evidence of this. Regardless, I think we can agree that IPv6 is the way to avoid NAT-related growing pains. We've known this for a long time. Cheers, -Benson From george.herbert at gmail.com Thu Feb 10 15:19:04 2011 From: george.herbert at gmail.com (George Herbert) Date: Thu, 10 Feb 2011 13:19:04 -0800 Subject: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> <5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com> <8762stc5a7.fsf@oban.berlin.quux.de> <5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1399F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC139A0@RWC-EX1.corp.seven.com> Message-ID: On Wed, Feb 9, 2011 at 6:11 PM, Fred Richards wrote: > On Wed, Feb 9, 2011 at 6:47 PM, George Bonser wrote: > >> I have yet to see a broadband provider that configures a network so that >> individual nodes in the home network get global IPs. >> > > One huge reason to adopt ipv6. Any of the ones I've used at home do provide global IPv4s to the home networks. I'm kinda selective, though. -- -george william herbert george.herbert at gmail.com From ryan at u13.net Thu Feb 10 15:34:04 2011 From: ryan at u13.net (Ryan Rawdon) Date: Thu, 10 Feb 2011 16:34:04 -0500 Subject: BCP38 considerations in IPv6 Message-ID: Hello NANOGers - What considerations should be made with respect to implementing egress filtering based on source IPv6 addresses? Things like allowing traffic sourced from fe80::/10 in said filters for on-link communication (for the interface that the filter is applied to). Is there anything else that should be taken into account while implementing BCP38 egress filtering in IPv6? Ryan From ka at pacific.net Thu Feb 10 15:35:56 2011 From: ka at pacific.net (Ken A) Date: Thu, 10 Feb 2011 15:35:56 -0600 Subject: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> <5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com> <8762stc5a7.fsf@oban.berlin.quux.de> <5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1399F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC139A0@RWC-EX1.corp.seven.com> Message-ID: <4D545A3C.4030304@pacific.net> On 2/10/2011 3:19 PM, George Herbert wrote: > On Wed, Feb 9, 2011 at 6:11 PM, Fred Richards wrote: >> On Wed, Feb 9, 2011 at 6:47 PM, George Bonser wrote: >> >>> I have yet to see a broadband provider that configures a network so that >>> individual nodes in the home network get global IPs. >>> >> >> One huge reason to adopt ipv6. Maybe Roku will add the "ipv6 tunnel endpoint channel" next? Seems like an opportunity? Ken > > Any of the ones I've used at home do provide global IPv4s to the home networks. > > I'm kinda selective, though. > -- Ken Anderson Pacific Internet - http://www.pacific.net From jfbeam at gmail.com Thu Feb 10 15:46:00 2011 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 10 Feb 2011 16:46:00 -0500 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <8FAA4ED3-4AB6-431D-8635-7A3C10C3E586@internode.com.au> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <20110210060919.F1DEE9E0AB7@drugs.dv.isc.org> <8FAA4ED3-4AB6-431D-8635-7A3C10C3E586@internode.com.au> Message-ID: On Thu, 10 Feb 2011 01:35:42 -0500, Matthew Moyle-Croft wrote: >> Because it is a waste of time and money. > > That's an assertion I've heard, but has anyone quantified it? ... Not that I've ever seen. All the bitching I've seen here and elsewhere boils down to it being more involved than sending an email, so they won't bother. To be fair, it *is* a lot more work than sending an email. For starters, just finding out *who* to email. Many companies that were given assignments have been sold or went out of business. Determining the proper holder can be as much work as getting the space back. Given the current state of affairs, getting any legacy holders to hand over the space is "not going to happen." That space is now worth more than anti-matter. Had they started the process a deacde ago instead of complaining that it's too much work, not worth it, etc., etc., then some of it might have been reclaimed by now. (and at current ARIN rates, a /8 is worth ~1.2mil/yr. on the open market, it's worth much more than that. esp. since legacy holders don't pay ANYTHING for it.) --Ricky From marka at isc.org Thu Feb 10 15:50:46 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 11 Feb 2011 08:50:46 +1100 Subject: BCP38 considerations in IPv6 In-Reply-To: Your message of "Thu, 10 Feb 2011 16:34:04 CDT." References: Message-ID: <20110210215046.53DEC9E2E7B@drugs.dv.isc.org> In message , Ryan Rawdon writes : > > Hello NANOGers - > > What considerations should be made with respect to implementing egress > filtering based on source IPv6 addresses? Things like allowing traffic > sourced from fe80::/10 in said filters for on-link communication (for the > interface that the filter is applied to). Is there anything else that > should be taken into account while implementing BCP38 egress filtering in > IPv6? > > Ryan You should definitely make sure you block ULA prefixes leaving your site by default. e.g. add unreach admin all from any to fc00::/7 via gif0 add unreach admin all from fc00::/7 to any via gif0 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From iljitsch at muada.com Thu Feb 10 15:51:48 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 10 Feb 2011 22:51:48 +0100 Subject: BCP38 considerations in IPv6 In-Reply-To: References: Message-ID: <6388DFAC-E74D-469C-AEF4-B3013A2A35B8@muada.com> On 10 feb 2011, at 22:34, Ryan Rawdon wrote: > What considerations should be made with respect to implementing egress > filtering based on source IPv6 addresses? Things like allowing traffic > sourced from fe80::/10 in said filters for on-link communication (for the > interface that the filter is applied to). Is there anything else that > should be taken into account while implementing BCP38 egress filtering in > IPv6? There's a lot of language in the RFCs about this type of addresses not being forwarded by routers, so filtering shouldn't be necessary. I know that Cisco lets neighbor discovery through before the implicit deny is applied, so specifically allowing link locals for neighbor discovery isn't necessary either. (I would assume other vendors do the same, but it's of course a good idea to check.) The only time you have to be careful is when you do a deny all, because you need neighbor discovery unless you use static neighbor cache entries. ND also uses multicast, so you need to let that through as appropriate, too. From wmaton at ryouko.imsb.nrc.ca Thu Feb 10 15:55:34 2011 From: wmaton at ryouko.imsb.nrc.ca (William F. Maton Sotomayor) Date: Thu, 10 Feb 2011 16:55:34 -0500 (EST) Subject: BCP38 considerations in IPv6 In-Reply-To: References: Message-ID: On Thu, 10 Feb 2011, Ryan Rawdon wrote: > What considerations should be made with respect to implementing egress > filtering based on source IPv6 addresses? Things like allowing traffic > sourced from fe80::/10 in said filters for on-link communication (for the > interface that the filter is applied to). Is there anything else that > should be taken into account while implementing BCP38 egress filtering in > IPv6? That's a consideration, and one other candidate which has already been welcomed to my black-hole server: 2001:DB8::/32. I'll leave that as an exercise to everyone to see who's block that is. :-) wfms From owen at delong.com Thu Feb 10 16:05:44 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 10 Feb 2011 14:05:44 -0800 Subject: ARIN and IPv6 Requests In-Reply-To: References: <6aacabfd$67a3507c$6792f96a$@com> Message-ID: Some policies allow you to use your IPv4 usage as justification of your need for IPv6. If you are applying under one of those policies, you need to fill in that information. If you are applying under a different qualification criteria, I believe you can leave that section blank. Owen On Feb 10, 2011, at 11:50 AM, ADWebb at dstsystems.com wrote: > Initial. Documenting IPv4 usage is in the request template. > > -- > Adam Webb > > > > > > From: > "Nick Olsen" > To: > > Date: > 02/10/2011 01:45 PM > Subject: > re: ARIN and IPv6 Requests > > > > We requested our initial allocation without any such questions. Is this > your initial or additional? > > Nick Olsen > Network Operations > (855) FLSPEED x106 > > ---------------------------------------- > > From: ADWebb at dstsystems.com > Sent: Thursday, February 10, 2011 2:38 PM > To: nanog at nanog.org > Subject: ARIN and IPv6 Requests > > Why does ARIN require detailed usage of IPv4 space when requesting IPv6 > space? Seems completely irrelevant to me. > > -- > Adam Webb > EN & ES Team > desk: 816.737.9717 > cell: 916.949.1345 > --------------------------------------- > The biggest secret of innovation is that anyone can do it. > --------------------------------------- > > ----------------------------------------- > Please consider the environment before printing this email and any > attachments. > > This e-mail and any attachments are intended only for the > individual or company to which it is addressed and may contain > information which is privileged, confidential and prohibited from > disclosure or unauthorized use under applicable law. If you are > not the intended recipient of this e-mail, you are hereby notified > that any use, dissemination, or copying of this e-mail or the > information contained in this e-mail is strictly prohibited by the > sender. If you have received this transmission in error, please > return the material received to the sender and delete all copies > from your system. > From owen at delong.com Thu Feb 10 16:15:53 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 10 Feb 2011 14:15:53 -0800 Subject: ARIN and IPv6 Requests In-Reply-To: References: <6aacabfd$67a3507c$6792f96a$@com> Message-ID: <7466222E-131F-46E2-883C-A22BD7BD704B@delong.com> From the NRPM: 6.11. IPv6 Multiple Discrete Networks Organizations with multiple discrete IPv6 networks desiring to request new or additional address space under a single Organization ID must meet the following criteria: The organization shall be a single entity and not a consortium of smaller independent entities. The organization must have compelling criteria for creating discrete networks. Examples of a discrete network might include: Regulatory restrictions for data transmission, Geographic distance and diversity between networks, Autonomous multihomed discrete networks. The organization must keep detailed records on how it has allocated space to each location, including the date of each allocation. The organization should notify ARIN at the time of the request their desire to apply this policy to their account. Requests for additional space: Organization must specify on the application which discreet network(s) the request applies to Each network will be judged against the existing utilization criteria specified in 6.5.2 as if it were a separate organization, rather than collectively as would be done for requests outside of this policy If that doesn't meet your need, please contact me off list with more information. Owen On Feb 10, 2011, at 12:18 PM, Jason Iannone wrote: > It also looks like there isn't a policy for orgs with multiple > multihomed sites to get a /48 per site. Is there an exception policy > somewhere? > > On Thu, Feb 10, 2011 at 12:50 PM, wrote: >> Initial. Documenting IPv4 usage is in the request template. >> >> -- >> Adam Webb >> >> >> >> >> >> From: >> "Nick Olsen" >> To: >> >> Date: >> 02/10/2011 01:45 PM >> Subject: >> re: ARIN and IPv6 Requests >> >> >> >> We requested our initial allocation without any such questions. Is this >> your initial or additional? >> >> Nick Olsen >> Network Operations >> (855) FLSPEED x106 >> >> ---------------------------------------- >> >> From: ADWebb at dstsystems.com >> Sent: Thursday, February 10, 2011 2:38 PM >> To: nanog at nanog.org >> Subject: ARIN and IPv6 Requests >> >> Why does ARIN require detailed usage of IPv4 space when requesting IPv6 >> space? Seems completely irrelevant to me. >> >> -- >> Adam Webb >> EN & ES Team >> desk: 816.737.9717 >> cell: 916.949.1345 >> --------------------------------------- >> The biggest secret of innovation is that anyone can do it. >> --------------------------------------- >> >> ----------------------------------------- >> Please consider the environment before printing this email and any >> attachments. >> >> This e-mail and any attachments are intended only for the >> individual or company to which it is addressed and may contain >> information which is privileged, confidential and prohibited from >> disclosure or unauthorized use under applicable law. If you are >> not the intended recipient of this e-mail, you are hereby notified >> that any use, dissemination, or copying of this e-mail or the >> information contained in this e-mail is strictly prohibited by the >> sender. If you have received this transmission in error, please >> return the material received to the sender and delete all copies >> from your system. >> >> >> From ADWebb at dstsystems.com Thu Feb 10 16:23:09 2011 From: ADWebb at dstsystems.com (ADWebb at dstsystems.com) Date: Thu, 10 Feb 2011 16:23:09 -0600 Subject: ARIN and IPv6 Requests In-Reply-To: References: <6aacabfd$67a3507c$6792f96a$@com> Message-ID: But how is it relevant? Ever? It's like a bank asking you to justify your need for a loan by asking you how many apples you can pick in an hour. -- Adam Webb From: Owen DeLong To: ADWebb at dstsystems.com Cc: nanog at nanog.org Date: 02/10/2011 04:10 PM Subject: Re: ARIN and IPv6 Requests Some policies allow you to use your IPv4 usage as justification of your need for IPv6. If you are applying under one of those policies, you need to fill in that information. If you are applying under a different qualification criteria, I believe you can leave that section blank. Owen On Feb 10, 2011, at 11:50 AM, ADWebb at dstsystems.com wrote: > Initial. Documenting IPv4 usage is in the request template. > > -- > Adam Webb > > > > > > From: > "Nick Olsen" > To: > > Date: > 02/10/2011 01:45 PM > Subject: > re: ARIN and IPv6 Requests > > > > We requested our initial allocation without any such questions. Is this > your initial or additional? > > Nick Olsen > Network Operations > (855) FLSPEED x106 > > ---------------------------------------- > > From: ADWebb at dstsystems.com > Sent: Thursday, February 10, 2011 2:38 PM > To: nanog at nanog.org > Subject: ARIN and IPv6 Requests > > Why does ARIN require detailed usage of IPv4 space when requesting IPv6 > space? Seems completely irrelevant to me. > > -- > Adam Webb > EN & ES Team > desk: 816.737.9717 > cell: 916.949.1345 > --------------------------------------- > The biggest secret of innovation is that anyone can do it. > --------------------------------------- > > ----------------------------------------- > Please consider the environment before printing this email and any > attachments. > > This e-mail and any attachments are intended only for the > individual or company to which it is addressed and may contain > information which is privileged, confidential and prohibited from > disclosure or unauthorized use under applicable law. If you are > not the intended recipient of this e-mail, you are hereby notified > that any use, dissemination, or copying of this e-mail or the > information contained in this e-mail is strictly prohibited by the > sender. If you have received this transmission in error, please > return the material received to the sender and delete all copies > from your system. > From mpetach at netflight.com Thu Feb 10 16:24:23 2011 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 10 Feb 2011 14:24:23 -0800 Subject: Is your ASN advertising v6 prefixes? In-Reply-To: <4D538BE7.40208@brightok.net> References: <20110209224241.F4602F9C@resin17.mta.everyone.net> <4D538BE7.40208@brightok.net> Message-ID: On Wed, Feb 9, 2011 at 10:55 PM, Jack Bates wrote: > On 2/10/2011 12:42 AM, Scott Weeks wrote: >> >> Prefixes Originated (v6): 4 >> >> >> Why 4? >> > > Click on the v6 prefixes tab and look at them. There's a US, Taiwan and > Europe /32's, and then one additional /48 out of the US /32. > > Jack more specifically, we did an initial /48 test deployment, to make sure we weren't going to screw things up royally, then we anchored a /32 in each registry region we do business in, and announced those out. Now that the testbed phase is over, I can probably go back and remove that more specific, since the covering /32 is in place; but the other 3 /32s can't be aggregated. Matt From mksmith at adhost.com Thu Feb 10 16:31:12 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Thu, 10 Feb 2011 22:31:12 +0000 Subject: ARIN and IPv6 Requests In-Reply-To: References: <6aacabfd$67a3507c$6792f96a$@com> Message-ID: Hello Adam: You may want to post this on the ARIN PPML list since the policy folks are all there. They will be able to point your directly to the portion of the NPRM that applies. In addition, this would be the appropriate list to submit policy changes if you don't like the way things are being done now. Regards, Mike -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) > -----Original Message----- > From: ADWebb at dstsystems.com [mailto:ADWebb at dstsystems.com] > Sent: Thursday, February 10, 2011 2:23 PM > To: Owen DeLong > Cc: nanog at nanog.org > Subject: Re: ARIN and IPv6 Requests > > But how is it relevant? Ever? It's like a bank asking you to justify your > need for a loan by asking you how many apples you can pick in an hour. > > -- > Adam Webb > > > > > > From: > Owen DeLong > To: > ADWebb at dstsystems.com > Cc: > nanog at nanog.org > Date: > 02/10/2011 04:10 PM > Subject: > Re: ARIN and IPv6 Requests > > > > Some policies allow you to use your IPv4 usage as justification of your > need > for IPv6. If you are applying under one of those policies, you need to > fill in > that information. If you are applying under a different qualification > criteria, > I believe you can leave that section blank. > > Owen > > On Feb 10, 2011, at 11:50 AM, ADWebb at dstsystems.com wrote: > > > Initial. Documenting IPv4 usage is in the request template. > > > > -- > > Adam Webb > > > > > > > > > > > > From: > > "Nick Olsen" > > To: > > > > Date: > > 02/10/2011 01:45 PM > > Subject: > > re: ARIN and IPv6 Requests > > > > > > > > We requested our initial allocation without any such questions. Is this > > your initial or additional? > > > > Nick Olsen > > Network Operations > > (855) FLSPEED x106 > > > > ---------------------------------------- > > > > From: ADWebb at dstsystems.com > > Sent: Thursday, February 10, 2011 2:38 PM > > To: nanog at nanog.org > > Subject: ARIN and IPv6 Requests > > > > Why does ARIN require detailed usage of IPv4 space when requesting IPv6 > > space? Seems completely irrelevant to me. > > > > -- > > Adam Webb > > EN & ES Team > > desk: 816.737.9717 > > cell: 916.949.1345 > > --------------------------------------- > > The biggest secret of innovation is that anyone can do it. > > --------------------------------------- > > > > ----------------------------------------- > > Please consider the environment before printing this email and any > > attachments. > > > > This e-mail and any attachments are intended only for the > > individual or company to which it is addressed and may contain > > information which is privileged, confidential and prohibited from > > disclosure or unauthorized use under applicable law. If you are > > not the intended recipient of this e-mail, you are hereby notified > > that any use, dissemination, or copying of this e-mail or the > > information contained in this e-mail is strictly prohibited by the > > sender. If you have received this transmission in error, please > > return the material received to the sender and delete all copies > > from your system. > > > > From bill at herrin.us Thu Feb 10 16:30:57 2011 From: bill at herrin.us (William Herrin) Date: Thu, 10 Feb 2011 17:30:57 -0500 Subject: ARIN and IPv6 Requests In-Reply-To: References: <6aacabfd$67a3507c$6792f96a$@com> Message-ID: On Thu, Feb 10, 2011 at 5:23 PM, wrote: > But how is it relevant? Ever? It's like a bank asking you to justify your > need for a loan by asking you how many apples you can pick in an hour. You're asking for a loan to plant an orchard. Oranges this time, but you've only ever grown apples. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From drc at virtualized.org Thu Feb 10 16:40:20 2011 From: drc at virtualized.org (David Conrad) Date: Thu, 10 Feb 2011 12:40:20 -1000 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <20110210060919.F1DEE9E0AB7@drugs.dv.isc.org> <8FAA4ED3-4AB6-431D-8635-7A3C10C3E586@internode.com.au> Message-ID: On Feb 10, 2011, at 11:46 AM, Ricky Beam wrote: > Had they started the process a deacde ago instead of complaining that it's too much work, not worth it, etc., etc., then some of it might have been reclaimed by now. How about 15 years ago: http://tools.ietf.org/html/rfc1917 Regards, -drc From mksmith at adhost.com Thu Feb 10 16:40:35 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Thu, 10 Feb 2011 22:40:35 +0000 Subject: ANNOUNCE: NANOG List and Website Downtime Message-ID: Hello All: The NANOG website and NANOG mailing list will be unavailable during the times listed below. There is an issue with the present location within the University of Michigan environment that requires a physical move of the NANOG servers to a discrete location. We apologize for the short notice and will do our best to minimize the associated downtime. If you have any questions, feel free to let me know or you can address it on nanog-futures as well. Date of Outage: Sunday, February 13th, 2011 Start of Outage: 0500 EST (GMT -5) End of Outage: 0900 EST (GMT -5) Impact: www.nanog.org will be unavailable and the NANOG mailing list will not accept mail. Regards, Mike On behalf of the NANOG Communications Committee -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) From marka at isc.org Thu Feb 10 16:41:23 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 11 Feb 2011 09:41:23 +1100 Subject: Looking for an IPv6 naysayer... In-Reply-To: Your message of "Thu, 10 Feb 2011 09:58:08 CDT." <4D53FD00.40900@ispalliance.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> <833804CE-80D9-4CED-8672-CF0870317E8C@delong.com><4D531B52.70404@ispalliance.net> <20110210002231.23F0E9DCFDD@drugs.dv.isc.org> <4D53FD00.40900@ispalliance.net> Message-ID: <20110210224123.539B09E32CF@drugs.dv.isc.org> In message <4D53FD00.40900 at ispalliance.net>, Scott Helms writes: > On 2/9/2011 7:22 PM, Mark Andrews wrote: > > > > And some of their customers have been asking for IPv6 all along. > > > > I started asking my ISP at home in 2003. I suspect if all the ISPs > > here were honest they would say that they have had a trickle of > > IPv6 requests for the last 8 years. > > > > Mark > > Mark, I don't doubt that but request levels have to rise to a certain > point. I still get a trickle of requests for UUCP service along with > other very low volume features/products. Its the same thing as when you > guys get a feature request for BIND or ISC DHCP that only a tiny > fraction of your customers will use. Everyone has to prioritize and > given that all of the tech folks who wanted to get an IPv6 connection > could do so via tunneling there has been absolutely 0 pressure from > residential customers and very very little from commercial customers. > The federal government's requirement generated a few months of interest > until everyone figured out they could satisfy their requirements by > setting a tunnel with HE. We sometime react on a single request. Also IPv6 is not something that only a few of our customers will ever use. Close to 100% of our customers will use IPv6. We put IPv6 support, transport and records, into BIND over a decade ago. F was running and answering on IPv6 addresses for years before the AAAA were added. We have been using IPv6 for production services for nearly a decade now. I've had a IPv6 tunnel from home to HE for 7 or 8 years and have been reaching the work machines over that for just as long. ISPs know it takes years to move a customer base. They should have been ready years ago. They still arn't ready. I was asking for what features to look for in a new CPE so that it won't need to be replaced when they turn on IPv6 and got this as a answer. It really isn't helpful. Mark ??Subject IPv6 support ?? ??Discussion Thread ??Response Via Email (Russell) 07/02/2011 02.04 PM Dear Mark, Thank you for your email. IPv6 deployment within Optus has not been broadly discussed. At this point in time Optus has no immediate plans for implementation. Kind Regards, Optus Technical Support -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Thu Feb 10 16:53:32 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 11 Feb 2011 09:53:32 +1100 Subject: Looking for an IPv6 naysayer... In-Reply-To: Your message of "Thu, 10 Feb 2011 10:00:50 CDT." <4D53FDA2.8050304@nic-naa.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E59B.4070904@nic-naa.net> <6E2D8385-77A1-4408-B12B-A7F61FDCC3EF@delong.com> <4D531E85.3000005@nic-naa.net> <0CA94927-95DB-4C36-9B55-C891151729FB@delong.com><4D53FDA2.8050304@nic-naa.net> Message-ID: <20110210225332.8B5849E3427@drugs.dv.isc.org> I'd argue that all TLD registries should be reachable over IPv6 by now and all TLD should be reachable over IPv6 by now. It's not that hard nor is it any more expensive. It just requires will to turn it on. Requiring that new TLDs and the registry infrastucture be reachable over IPv6 from day one is perfectly reasonable. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mohacsi at niif.hu Thu Feb 10 16:56:27 2011 From: mohacsi at niif.hu (Mohacsi Janos) Date: Thu, 10 Feb 2011 23:56:27 +0100 (CET) Subject: BCP38 considerations in IPv6 In-Reply-To: References: Message-ID: On Thu, 10 Feb 2011, Ryan Rawdon wrote: > > Hello NANOGers - > > What considerations should be made with respect to implementing egress > filtering based on source IPv6 addresses? Things like allowing traffic > sourced from fe80::/10 in said filters for on-link communication (for the > interface that the filter is applied to). Is there anything else that > should be taken into account while implementing BCP38 egress filtering in > IPv6? Have look at some icmpv6 consideration in RFC 4890. Regards, Janos From dr at cluenet.de Thu Feb 10 17:08:19 2011 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 11 Feb 2011 00:08:19 +0100 Subject: Looking for an IPv6 naysayer... In-Reply-To: <20110210000726.3CABE9DCC09@drugs.dv.isc.org> References: <5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com> <20110210000726.3CABE9DCC09@drugs.dv.isc.org> Message-ID: <20110210230819.GA30629@srv03.cluenet.de> On Thu, Feb 10, 2011 at 11:07:26AM +1100, Mark Andrews wrote: > Double NAT prevents most of the work arounds working. And quite important for residential ISPs of some size: have fun teaching your call centers diagnosing double-NAT failure modes. NAT444 is a hell I don't want to visit really. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From dr at cluenet.de Thu Feb 10 17:11:16 2011 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 11 Feb 2011 00:11:16 +0100 Subject: Looking for an IPv6 naysayer... In-Reply-To: <4D532AEA.2090505@brightok.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> Message-ID: <20110210231116.GB30629@srv03.cluenet.de> On Wed, Feb 09, 2011 at 06:01:46PM -0600, Jack Bates wrote: > ds-lite tends to be friendlier LSN from various tests, Any pointers to study reports etc. heartly welcome. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From tom.pipes at t6mail.com Thu Feb 10 15:44:04 2011 From: tom.pipes at t6mail.com (Tom Pipes) Date: Thu, 10 Feb 2011 15:44:04 -0600 Subject: ARIN and IPv6 Requests In-Reply-To: References: Message-ID: Here's the template we just completed last week, and we received our /32 minimum allocation within a couple of days. No justification for initial allocation, only "subsequent" v6 allocations. https://www.arin.net/resources/templates/v6-isp.txt Tom Pipes T6 Broadband On Thu, Feb 10, 2011 at 1:38 PM, wrote: > Why does ARIN require detailed usage of IPv4 space when requesting IPv6 > space? Seems completely irrelevant to me. > > -- > Adam Webb > EN & ES Team > desk: 816.737.9717 > cell: 916.949.1345 > --------------------------------------- > The biggest secret of innovation is that anyone can do it. > --------------------------------------- > > > ----------------------------------------- > Please consider the environment before printing this email and any > attachments. > > This e-mail and any attachments are intended only for the > individual or company to which it is addressed and may contain > information which is privileged, confidential and prohibited from > disclosure or unauthorized use under applicable law. If you are > not the intended recipient of this e-mail, you are hereby notified > that any use, dissemination, or copying of this e-mail or the > information contained in this e-mail is strictly prohibited by the > sender. If you have received this transmission in error, please > return the material received to the sender and delete all copies > from your system. > -- Tom Pipes T6 Broadband Office: 815-380-3773 Direct: 815-544-1882 Fax: 815-380-6513 From jeroen at mompl.net Thu Feb 10 17:37:10 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Thu, 10 Feb 2011 15:37:10 -0800 Subject: Looking for an IPv6 naysayer... In-Reply-To: <8762stc5a7.fsf@oban.berlin.quux.de> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> <5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com> <8762stc5a7.fsf@oban.berlin.quux.de> Message-ID: <4D5476A6.1090206@mompl.net> Jens Link wrote: > I never thought it was that bad. In some 3G/wireless networks in Germany > the providers use NAT and transparent HTTP-proxy. But this is only > wireless. I'm not aware of any DSL or Cable provider NATing their > customers. I guess in the early days of DSL and Cable internet this was more common (until clue sinked in). I know xs4all in the Netherlands used some NAT flavour or another. Although come to think of it, it was probably the telco (KPN) who did that and the ISP just had to abide. They quickly got rid of that whole idea. It's a strange idea that the telco provides NAT'ing on DSL but I am pretty sure it was that way for a while. KPN since bought xs4all, but that's another story. -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From dr at cluenet.de Thu Feb 10 17:50:45 2011 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 11 Feb 2011 00:50:45 +0100 Subject: Looking for an IPv6 naysayer... In-Reply-To: <71648DBE-5FD0-4E73-8BC0-2CFA1686BA20@delong.com> References: <5A6D953473350C4B9995546AFE9939EE0BC1399F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC139A0@RWC-EX1.corp.seven.com> <4D532A93.50504@brightok.net> <4D533107.5010202@matthew.at> <71648DBE-5FD0-4E73-8BC0-2CFA1686BA20@delong.com> Message-ID: <20110210235045.GD30629@srv03.cluenet.de> On Wed, Feb 09, 2011 at 04:42:01PM -0800, Owen DeLong wrote: > Actually Comcast is willing to give out more than a /64 to a home, > they're waiting for the CPE to catch up. Catch up to what? Are there dualstack CPE routers out there only able to handle /64 prefix delegation? > I expect that they will eventually come around to giving out /48s, > but, for now they seem to feel they need to see the use case develop > before they deploy it. Well-known (in Germany) CPE router vendor AVM supports running WiFi in either bridged or routed mode. In routed mode, LAN ports get the first /64 from the DHCPv6-PD delegated prefix, and the WiFi domain gets the second /64. Et voila, there is the first use case. ;-) This is also why their 6RD implementation doesn't accept anything less than a /63. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From drais at icantclick.org Thu Feb 10 18:06:45 2011 From: drais at icantclick.org (david raistrick) Date: Thu, 10 Feb 2011 19:06:45 -0500 (EST) Subject: My upstream ISP does not support IPv6 In-Reply-To: References: <1127264403.2346.1296791643752.JavaMail.root@zimbra.network1.net> Message-ID: On Fri, 4 Feb 2011, david raistrick wrote: > Amazon AWS - "No." But I'm asking again, that's a few months old. To follow up on this: "We are investigating IP v6 but, unfortunately, have no plans that are available for sharing at present" -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From jcurran at arin.net Thu Feb 10 18:07:52 2011 From: jcurran at arin.net (John Curran) Date: Fri, 11 Feb 2011 00:07:52 +0000 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <20110205193328.GC22325@vacation.karoshi.com> <08F8827D-D8C3-4922-AC39-6C71ADBE8BDB@corp.arin.net> <20110206014014.GG22325@vacation.karoshi.com> <849FDB3F-EE29-48D6-8ECD-70AE6EB0B157@virtualized.org> <71571.1297311453@nsa.vix.com> Message-ID: <26604DDB-1EC5-43B4-B60F-EEF7CEF4132D@corp.arin.net> On Feb 10, 2011, at 3:13 AM, Jimmy Hess wrote: > Perhaps the RIRs should personally and directly ask each /8 legacy > holder to provide > account of their utilization (which portions of the allocation is > used, how many hosts), > and ASK for each unused /22 [or shorter] to be returned. I've done close: contacted each one, explained the situation, and asked for whatever resources they can return to please return. This has yielded results. I have not asked for an account of their utilization. > The legacy holders might (or might not) refuse. They might (or > might not) tell the RIRs "Hell no" > In any case, the registry should ASK and publish an indication > for each legacy /8 at least. I asked them all. Some have been returned, some are in progress, some are opted to hold them to be monetized via the Specified Transfer policy. > So the community will know which (if any) legacy /8 holders are > likely to be returning the community's > IPv4 addresses that they obtained but don't have need for. There is likely to be another fractional /8 being returned, but not much more. > The community should also know which /8 legacy holders say "Hell no, > we're keeping all our /8s, > and not telling you how much of the community's IPv4 resources we're > actually using". As I did not explain in advance to each to the parties that their responses would be public, it would not be proper to publicly post the information. Discussions with individual resource holders is treated as confidential information. FYI, /John John Curran President and CEO ARIN From lists at quux.de Thu Feb 10 18:15:19 2011 From: lists at quux.de (Jens Link) Date: Fri, 11 Feb 2011 01:15:19 +0100 Subject: Looking for an IPv6 naysayer... In-Reply-To: <20110210230819.GA30629@srv03.cluenet.de> (Daniel Roesen's message of "Fri, 11 Feb 2011 00:08:19 +0100") References: <5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com> <20110210000726.3CABE9DCC09@drugs.dv.isc.org> <20110210230819.GA30629@srv03.cluenet.de> Message-ID: <871v3fo294.fsf@oban.berlin.quux.de> Daniel Roesen writes: > And quite important for residential ISPs of some size: have fun teaching > your call centers diagnosing double-NAT failure modes. > > NAT444 is a hell I don't want to visit really. No it's great! It's secure! It's easy to implement! It's the only way to do it right! Till the end of the month I'm working for a rather large enterprise customer and they use NAT, NAT NAT, NAT NAT NAT, and even even NAT NAT NAT NAT connections for their VPN. They claim that it's easy. I think it isn't and I relay need to get drunk after troubleshooting such a problem. So I must be stupid, because NAT is so *easy*. On the other hand, when you tell them about IPv6 they say it's to complicated and that they don't need it. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From jbates at brightok.net Thu Feb 10 20:10:04 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 10 Feb 2011 20:10:04 -0600 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <26604DDB-1EC5-43B4-B60F-EEF7CEF4132D@corp.arin.net> References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <20110205193328.GC22325@vacation.karoshi.com> <08F8827D-D8C3-4922-AC39-6C71ADBE8BDB@corp.arin.net> <20110206014014.GG22325@vacation.karoshi.com> <849FDB3F-EE29-48D6-8ECD-70AE6EB0B157@virtualized.org> <71571.1297311453@nsa.vix.com> <26604DDB-1EC5-43B4-B60F-EEF7CEF4132D@corp.arin.net> Message-ID: <4D549A7C.1000708@brightok.net> On 2/10/2011 6:07 PM, John Curran wrote: > As I did not explain in advance to each to the parties that their responses > would be public, it would not be proper to publicly post the information. > Discussions with individual resource holders is treated as confidential > information. Since you have gone through the process before. It would be nice (especially concerning the DoD networks) if you could ask if they plan to keep them (not monetize) and if you could make such a statement publicly. I mention this, as DoD is most common bogons utilized by people who need to steal IP addressing. Locking in a statement that there is no intention to ever sell, transfer, or return those blocks would ease possible concerns on using them. As a side effect, it also kills any need of any proposals in various institutions to reserve virgin space for utilization of LSN and such. Jack From jbates at brightok.net Thu Feb 10 20:13:39 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 10 Feb 2011 20:13:39 -0600 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <4D549A7C.1000708@brightok.net> References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <20110205193328.GC22325@vacation.karoshi.com> <08F8827D-D8C3-4922-AC39-6C71ADBE8BDB@corp.arin.net> <20110206014014.GG22325@vacation.karoshi.com> <849FDB3F-EE29-48D6-8ECD-70AE6EB0B157@virtualized.org> <71571.1297311453@nsa.vix.com> <26604DDB-1EC5-43B4-B60F-EEF7CEF4132D@corp.arin.net> <4D549A7C.1000708@brightok.net> Message-ID: <4D549B53.5040209@brightok.net> On 2/10/2011 8:10 PM, Jack Bates wrote: > > As a side effect, it also kills any need of any proposals in various > institutions to reserve virgin space for utilization of LSN and such. > It might not be too far fetched that they might even endorse us reusing their addressing with permission for such private, non-routed purposes. Jack From jcurran at arin.net Thu Feb 10 20:15:47 2011 From: jcurran at arin.net (John Curran) Date: Fri, 11 Feb 2011 02:15:47 +0000 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <4D549A7C.1000708@brightok.net> References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <20110205193328.GC22325@vacation.karoshi.com> <08F8827D-D8C3-4922-AC39-6C71ADBE8BDB@corp.arin.net> <20110206014014.GG22325@vacation.karoshi.com> <849FDB3F-EE29-48D6-8ECD-70AE6EB0B157@virtualized.org> <71571.1297311453@nsa.vix.com> <26604DDB-1EC5-43B4-B60F-EEF7CEF4132D@corp.arin.net> <4D549A7C.1000708@brightok.net> Message-ID: On Feb 10, 2011, at 10:10 PM, Jack Bates wrote: > Since you have gone through the process before. It would be nice (especially concerning the DoD networks) if you could ask if they plan to keep them (not monetize) and if you could make such a statement publicly. > > I mention this, as DoD is most common bogons utilized by people who need to steal IP addressing. Locking in a statement that there is no intention to ever sell, transfer, or return those blocks would ease possible concerns on using them. I'm not certain that you could rely on any organizations statements made today to provide any assurance that circumstances would not change in the future and result in the address space being returned to ARIN or transferred per current policy. /John John Curran President and CEO ARIN From jbates at brightok.net Thu Feb 10 20:31:32 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 10 Feb 2011 20:31:32 -0600 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <20110205193328.GC22325@vacation.karoshi.com> <08F8827D-D8C3-4922-AC39-6C71ADBE8BDB@corp.arin.net> <20110206014014.GG22325@vacation.karoshi.com> <849FDB3F-EE29-48D6-8ECD-70AE6EB0B157@virtualized.org> <71571.1297311453@nsa.vix.com> <26604DDB-1EC5-43B4-B60F-EEF7CEF4132D@corp.arin.net> <4D549A7C.1000708@brightok.net> Message-ID: <4D549F84.4030200@brightok.net> On 2/10/2011 8:15 PM, John Curran wrote: > I'm not certain that you could rely on any organizations statements made today > to provide any assurance that circumstances would not change in the future and > result in the address space being returned to ARIN or transferred per current > policy. An official statement from the DoD? I'm sure we could hold them to it as a community. Is it too much for us to ask the US government to give us assurance that we can safely utilize huge chunks of address space assigned to them for purposes such as LSN without fear? :) Jack From jcurran at arin.net Thu Feb 10 20:44:46 2011 From: jcurran at arin.net (John Curran) Date: Fri, 11 Feb 2011 02:44:46 +0000 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <4D549F84.4030200@brightok.net> References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <20110205193328.GC22325@vacation.karoshi.com> <08F8827D-D8C3-4922-AC39-6C71ADBE8BDB@corp.arin.net> <20110206014014.GG22325@vacation.karoshi.com> <849FDB3F-EE29-48D6-8ECD-70AE6EB0B157@virtualized.org> <71571.1297311453@nsa.vix.com> <26604DDB-1EC5-43B4-B60F-EEF7CEF4132D@corp.arin.net> <4D549A7C.1000708@brightok.net> <4D549F84.4030200@brightok.net> Message-ID: <78697910-F7A6-4D53-AD93-377FCE66006D@arin.net> On Feb 10, 2011, at 10:31 PM, Jack Bates wrote: > On 2/10/2011 8:15 PM, John Curran wrote: >> I'm not certain that you could rely on any organizations statements made today >> to provide any assurance that circumstances would not change in the future and >> result in the address space being returned to ARIN or transferred per current >> policy. > > An official statement from the DoD? I'm sure we could hold them to it as a community. Is it too much for us to ask the US government to give us assurance that we can safely utilize huge chunks of address space assigned to them for purposes such as LSN without fear? :) In organizations of all sizes, positions and policies change, with revised statements as a result. One thing that does not change, however, is contractual commitments, and in this one case I can state that there is a commitment to return IPv4 address blocks to ARIN for reuse by the community if they no longer needed. If you'd like to reserve a large block for purposes of LSN without any concern of future address conflict, it would be best to actually reserve it via community-developed policy. FYI, /John John Curran President and CEO ARIN From jbates at brightok.net Thu Feb 10 20:54:36 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 10 Feb 2011 20:54:36 -0600 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <78697910-F7A6-4D53-AD93-377FCE66006D@arin.net> References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <20110205193328.GC22325@vacation.karoshi.com> <08F8827D-D8C3-4922-AC39-6C71ADBE8BDB@corp.arin.net> <20110206014014.GG22325@vacation.karoshi.com> <849FDB3F-EE29-48D6-8ECD-70AE6EB0B157@virtualized.org> <71571.1297311453@nsa.vix.com> <26604DDB-1EC5-43B4-B60F-EEF7CEF4132D@corp.arin.net> <4D549A7C.1000708@brightok.net> <4D549F84.4030200@brightok.net> <78697910-F7A6-4D53-AD93-377FCE66006D@arin.net> Message-ID: <4D54A4EC.5060209@brightok.net> On 2/10/2011 8:44 PM, John Curran wrote: > > If you'd like to reserve a large block for purposes of LSN > without any concern of future address conflict, it would be > best to actually reserve it via community-developed policy. > When there are X /8 networks reserved by the USG, it seems extremely wasteful to reserve from what little space we have a large block dedicated to LSN when the USG can give assurances that 1) We won't route this, so use it 2) We won't be giving it back or allocating it to someone else where it might be routed. All proposals concerning reserving a /8 of unallocated space for LSN purposes was seen as obscene, and many proposals compromised with a /10, which some feel is too small. I don't think it would hurt for someone with appropriate connections to ask the USG on the matter. It is, after all, in the USG's interest and doesn't conflict with their current practices. Many don't consider it a concern (shown by wide use of DoD space already deployed), yet some do apparently have concern since there has been multiple requests for a new allocation for LSN purposes (in the IETF and in RIRs). Jack From jared at puck.nether.net Thu Feb 10 21:00:30 2011 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 10 Feb 2011 22:00:30 -0500 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <78697910-F7A6-4D53-AD93-377FCE66006D@arin.net> References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <20110205193328.GC22325@vacation.karoshi.com> <08F8827D-D8C3-4922-AC39-6C71ADBE8BDB@corp.arin.net> <20110206014014.GG22325@vacation.karoshi.com> <849FDB3F-EE29-48D6-8ECD-70AE6EB0B157@virtualized.org> <71571.1297311453@nsa.vix.com> <26604DDB-1EC5-43B4-B60F-EEF7CEF4132D@corp.arin.net> <4D549A7C.1000708@brightok.net> <4D549F84.4030200@brightok.net> <78697910-F7A6-4D53-AD93-377FCE66006D@arin.net> Message-ID: <0327E4DC-C430-4826-B15B-FBB5B47AF5EA@puck.nether.net> On Feb 10, 2011, at 9:44 PM, John Curran wrote: > On Feb 10, 2011, at 10:31 PM, Jack Bates wrote: > >> On 2/10/2011 8:15 PM, John Curran wrote: >>> I'm not certain that you could rely on any organizations statements made today >>> to provide any assurance that circumstances would not change in the future and >>> result in the address space being returned to ARIN or transferred per current >>> policy. >> >> An official statement from the DoD? I'm sure we could hold them to it as a community. Is it too much for us to ask the US government to give us assurance that we can safely utilize huge chunks of address space assigned to them for purposes such as LSN without fear? :) > > In organizations of all sizes, positions and policies change, > with revised statements as a result. One thing that does not > change, however, is contractual commitments, and in this one > case I can state that there is a commitment to return IPv4 > address blocks to ARIN for reuse by the community if they no > longer needed. > > If you'd like to reserve a large block for purposes of LSN > without any concern of future address conflict, it would be > best to actually reserve it via community-developed policy. I would have to say I agree. Anything short of a posting in the federal register is just a statement of the short-term future. US Gov 201: The federal register from the GPO is the primary source of rule making and RFI the government will use prior to regulation that is not purely legislative. It may be worthwhile to subscribe, or periodically read/search. - Jared From jra at baylink.com Thu Feb 10 20:56:02 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 10 Feb 2011 21:56:02 -0500 (EST) Subject: Semi-Annual 'System Status Page' solicitation Message-ID: <19585128.6612.1297392962677.JavaMail.root@benjamin.baylink.com> If you work for a backbone, content, access, or service provider, and you know that your company has a publicly accessible System/Service/Network Status Page available on the web, we'd love it if you'd add it to the Outages Dashboard, at http://wiki.outages.org/index.php/Dashboard If you have an account on the wiki, you can add it directly; if not, you can add it to the associated Talk page, or email it to me off list, and I'll be happy to add it for you. You're perfectly welcome to add any other pages we don't have listed as well, as long as they're publicly accessible. This was a recording. Cheers, -- jra From ck at sandcastl.es Thu Feb 10 14:13:56 2011 From: ck at sandcastl.es (christian koch) Date: Thu, 10 Feb 2011 12:13:56 -0800 Subject: box.net network engineer In-Reply-To: References: Message-ID: On Thu, Feb 10, 2011 at 12:01 PM, Andrew Matthews wrote: > Can someone with the box.net engineering group email me off list. > > I have a peering issue with you guys at any2 in socal. > One would think, if you are interconnecting with another network you should have some contact info for them. Or know where to find the information necessary for situations like this. https://www.peeringdb.com/private/participant_view.php?id=1904 $ whois -h whois.radb.net as33011 aut-num: AS33011 as-name: BOXNET descr: Box.net, Inc. import: from AS-ANY accept ANY export: to AS-ANY announce AS33011 AND NOT {0.0.0.0/0} admin-c: JQU26-ARIN tech-c: GCG-ARIN notify: noc at box.net mnt-by: MNT-BOXNE-1 changed: ggong at box.net 20080513 source: ARIN > Thanks, > Drew > From jared at puck.nether.net Thu Feb 10 21:11:32 2011 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 10 Feb 2011 22:11:32 -0500 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <4D54A4EC.5060209@brightok.net> References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <20110205193328.GC22325@vacation.karoshi.com> <08F8827D-D8C3-4922-AC39-6C71ADBE8BDB@corp.arin.net> <20110206014014.GG22325@vacation.karoshi.com> <849FDB3F-EE29-48D6-8ECD-70AE6EB0B157@virtualized.org> <71571.1297311453@nsa.vix.com> <26604DDB-1EC5-43B4-B60F-EEF7CEF4132D@corp.arin.net> <4D549A7C.1000708@brightok.net> <4D549F84.4030200@brightok.net> <78697910-F7A6-4D53-AD93-377FCE66006D@arin.net> <4D54A4EC.5060209@brightok.net> Message-ID: <102CB5C2-D884-4089-A275-0D9187E9C7BA@puck.nether.net> On Feb 10, 2011, at 9:54 PM, Jack Bates wrote: > On 2/10/2011 8:44 PM, John Curran wrote: >> >> If you'd like to reserve a large block for purposes of LSN >> without any concern of future address conflict, it would be >> best to actually reserve it via community-developed policy. >> > > When there are X /8 networks reserved by the USG, it seems extremely wasteful to reserve from what little space we have a large block dedicated to LSN when the USG can give assurances that > > 1) We won't route this, so use it > > 2) We won't be giving it back or allocating it to someone else where it might be routed. > > All proposals concerning reserving a /8 of unallocated space for LSN purposes was seen as obscene, and many proposals compromised with a /10, which some feel is too small. I don't think it would hurt for someone with appropriate connections to ask the USG on the matter. It is, after all, in the USG's interest and doesn't conflict with their current practices. Many don't consider it a concern (shown by wide use of DoD space already deployed), yet some do apparently have concern since there has been multiple requests for a new allocation for LSN purposes (in the IETF and in RIRs). Jack, I was explaining to my wife today how it felt like the nanog list went to 3x the typical mail volume recently with all the IPv6 stuff this month. Why the pro-IPv6 crowd was happy, the anti-IPv6 crowd is groaning (including those that truly despise the whole thing, etc..) I honestly think that the LSN situations won't be as bad as some of us think. The big carriers have already been doing some flavor of this with their cellular/data networks. Doing this on some of the consumer networks will likely not be "that much" pain. Obviously the pain will vary per subscriber/home. I think despite everyones dislike, distaste and wish that the IPv6 situation didn't smell quite as bad as it does, we're certainly stuck with it. I don't see anyone deploying a new solution anytime soon, and it having broad market acceptance/coding. Many of us wish that IPv6 didn't have a lot of "unecessary/ugly" stuff. I wish that the network situation wasn't as ugly, but none of this will make it so. We will have to continue to improve and augment the autoconf, dhcpv6, etc environment. The existing hosts need to be fixed (eg: my laptop won't do ipv6 over pptp/vpn properly without a hack), etc.. IPv4 is "dead" in my opinion. Not dead as in useless, but to the point where I don't think there is value in spending a lot of time worrying about the v4 side of the world when so much needs to be fixed in IPv6 land. Please make sure you list IPv6 *first* in your RFPs, and the IPv4 capabilities under the 'legacy protocols' for 2011. If we're truly going to have the promise of the Internet, we need these market forces to drive the carriers and SME/Prosumer markets to lead the way for the grandparents to still get to their "Google, Bing" et al, and not just those of us who know there will be an IPv6 day and have our mailboxes filled with IPv6 "spam" this month. - Jared From jcurran at arin.net Thu Feb 10 21:15:35 2011 From: jcurran at arin.net (John Curran) Date: Fri, 11 Feb 2011 03:15:35 +0000 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <4D54A4EC.5060209@brightok.net> References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <20110205193328.GC22325@vacation.karoshi.com> <08F8827D-D8C3-4922-AC39-6C71ADBE8BDB@corp.arin.net> <20110206014014.GG22325@vacation.karoshi.com> <849FDB3F-EE29-48D6-8ECD-70AE6EB0B157@virtualized.org> <71571.1297311453@nsa.vix.com> <26604DDB-1EC5-43B4-B60F-EEF7CEF4132D@corp.arin.net> <4D549A7C.1000708@brightok.net> <4D549F84.4030200@brightok.net> <78697910-F7A6-4D53-AD93-377FCE66006D@arin.net> <4D54A4EC.5060209@brightok.net> Message-ID: <17F7273E-BBBF-4B60-A3F4-5A2BAB220684@arin.net> On Feb 10, 2011, at 10:54 PM, Jack Bates wrote: > When there are X /8 networks reserved by the USG, it seems extremely wasteful to reserve from what little space we have a large block dedicated to LSN when the USG can give assurances that > > 1) We won't route this, so use it > > 2) We won't be giving it back or allocating it to someone else where it might be routed. > > All proposals concerning reserving a /8 of unallocated space for LSN purposes was seen as obscene, and many proposals compromised with a /10, which some feel is too small. I don't think it would hurt for someone with appropriate connections to ask the USG on the matter. It is, after all, in the USG's interest and doesn't conflict with their current practices. Many don't consider it a concern (shown by wide use of DoD space already deployed), yet some do apparently have concern since there has been multiple requests for a new allocation for LSN purposes (in the IETF and in RIRs). Indeed, that does sound simple. Obtaining such a commitment may prove to be a little more difficult, since it permanently encumbers use of one or more address blocks. I am happy to ask, however, if there is a strong level of support to do so. Alternatively, there is valid contact information listed in WHOIS for US DOD and other commercial /8 address block holders if you wish to ask one directly. /John John Curran President and CEO ARIN p.s. Considering that we've collectively allocated the 95%+ of the address space which was made available outside of DoD's original blocks, and the DoD additionally returned 2 more /8's for the community (noted here: ), they may actually have a different perspective us coming back to impair some of the remaining space they still hold. I'm happy to discuss it, but wanted to point out the long history and potential different perspective. From jbates at brightok.net Thu Feb 10 21:28:40 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 10 Feb 2011 21:28:40 -0600 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <102CB5C2-D884-4089-A275-0D9187E9C7BA@puck.nether.net> References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <20110205193328.GC22325@vacation.karoshi.com> <08F8827D-D8C3-4922-AC39-6C71ADBE8BDB@corp.arin.net> <20110206014014.GG22325@vacation.karoshi.com> <849FDB3F-EE29-48D6-8ECD-70AE6EB0B157@virtualized.org> <71571.1297311453@nsa.vix.com> <26604DDB-1EC5-43B4-B60F-EEF7CEF4132D@corp.arin.net> <4D549A7C.1000708@brightok.net> <4D549F84.4030200@brightok.net> <78697910-F7A6-4D53-AD93-377FCE66006D@arin.net> <4D54A4EC.5060209@brightok.net> <102CB5C2-D884-4089-A275-0D9187E9C7BA@puck.nether.net> Message-ID: <4D54ACE8.1080902@brightok.net> On 2/10/2011 9:11 PM, Jared Mauch wrote: > I was explaining to my wife today how it felt like the nanog list went to 3x the typical mail volume recently with all the IPv6 stuff this month. Why the pro-IPv6 crowd was happy, the anti-IPv6 crowd is groaning (including those that truly despise the whole thing, etc..) I was having fun discussing with my wife how ARIN stuff ended up on NANOG, NANOG stuff ended up on PPML, and I've been listening and participating in debates concerning IPv6 and CGN (apparently BEHAVE WG adopted CGN over LSN) on 4 different mailing lists. To be honest, though. I'm pro-IPv6, but I'm not happy. Anyone who is happy doesn't care about those innocent people who are ignorant of what is going on and why. > I honestly think that the LSN situations won't be as bad as some of us think. The big carriers have already been doing some flavor of this with their cellular/data networks. Doing this on some of the consumer networks will likely not be "that much" pain. Obviously the pain will vary per subscriber/home. > IPv4 is "dead" in my opinion. Not dead as in useless, but to the point where I don't think there is value in spending a lot of time worrying about the v4 side of the world when so much needs to be fixed in IPv6 land. Service requirements in cellular networks are considerably different than wireline. Apparently, most cell customers don't hook a CPE router into their cell network and play their game consoles over it, along with many other situations. This actually means that most often, they are running a single stage NAT44 LSN (which still breaks stuff, but most of the things it would break aren't normally transiting the cellular networks). I agree. However, because the largest networks and corporations decided (and some still do) to wait until the last moment to deal with IPv6, we will have to deal with IPv4 in much worse conditions. I know that there are large cellular networks which use DoD bogons behind huge LSN implementations. I know that some networks apparently aren't happy with using DoD bogons and would like to waste even more space. The best solution for such a case (and to solve all arguments on the matter) is to secure assurances on the bogons so that they can be safely used. Jack From jfbeam at gmail.com Thu Feb 10 21:46:04 2011 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 10 Feb 2011 22:46:04 -0500 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <4D5415C6.80700@matthew.at> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> Message-ID: On Thu, 10 Feb 2011 11:43:50 -0500, Matthew Kaufman wrote: > There is no one universal "global routing table". They probably appear > in someone's routing table, somewhere... just not yours. Using public address space for private networking is a gross misuse of the resource. Go to any registry and ask for address space for your private networking that you do not intend to announce to the internet. They will laugh at you, and point you to RFC1918. (and likely flag you as someone to whom address space should never be assigned.) The only reason legacy holders get away with such crap is because there's no clear contract governing their assignment. > How many days do you think a single /8 lasts at current assignment rates? APNIC says the last 2 /8's they were assigned (triggering the dead-man clause) would last ~6mo. With responsible use, 22 /8's would last several years. (3-5 best guess. Of course, there could be a land-rush and all of it disappear next week -- see also: responsible use) > How would ARIN/ICANN go about reclaiming addresses that someone believes > they are using but that you don't think are in use? First off, someone will have to do a lot more than 5 minutes of poking router-servers to see just how sparsely used ("announced") the space really is. That includes digging through BGP histories to see if it's ever been announced. Then research who should be in control of the space (announced or not.) Then send out nasty sounding letters informing whomever that X address space has not been announced to the public internet in Y years; on Z date, the space will reenter the IANA/ICANN free pool for reassignment. (cue lawyers :-)) They'd also be highly motivated to return unused space if they were being billing for it. As the powers that be have drug their feet for over a decade already, I really doubt they'll even take 5 minutes to look at *a single* route server. As for this "not fixing the problem", IPv4 is going to be a problem for MANY years to come. IPv6 deployment is glacially slow. IPv4 being "out of space" is getting news attention now, but will fade from the spotlight shortly. The people who have space will continue to have it and generally not notice the lack of availablity. The likes of Facebook, etc., have jumped on IPv6 because they have a reason to... they have volumes of IPv6 connected eyeballs. Yet the likes of Amazon and Akamai, aren't supporting IPv6 (and have no published plans to.) Almost all of the major ISPs in the country still don't fully support IPv6 -- the few that do embrace v6 make it a pain in the ass to get it setup. I don't support IPv6 (since elink killed their experiment); I can get everywhere I care to go, and everyone who cares to get to me does. I, like many/most others, will fix that problem when it *is* a problem. (For the record... TWTC: not supported, Speakeasy: not supported, VZB: not recommended for an existing connection (if you want it to stay working)) --Ricky From jbates at brightok.net Thu Feb 10 22:06:39 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 10 Feb 2011 22:06:39 -0600 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> Message-ID: <4D54B5CF.9030608@brightok.net> On 2/10/2011 9:46 PM, Ricky Beam wrote: > On Thu, 10 Feb 2011 11:43:50 -0500, Matthew Kaufman > wrote: >> There is no one universal "global routing table". They probably >> appear in someone's routing table, somewhere... just not yours. > > Using public address space for private networking is a gross misuse of > the resource. Go to any registry and ask for address space for your > private networking that you do not intend to announce to the > internet. They will laugh at you, and point you to RFC1918. (and > likely flag you as someone to whom address space should never be > assigned.) The only reason legacy holders get away with such crap is > because there's no clear contract governing their assignment. > https://www.arin.net/policy/nrpm.html#four35 Encourages use of RFC1918, but does not require it, especially when private peering with other networks is involved. >> How many days do you think a single /8 lasts at current assignment >> rates? > > APNIC says the last 2 /8's they were assigned (triggering the dead-man > clause) would last ~6mo. With responsible use, 22 /8's would last > several years. (3-5 best guess. Of course, there could be a land-rush > and all of it disappear next week -- see also: responsible use) > If all 22 /8's were free to use, yes, 3-5 years. However, it violates existing RIR policies if those addresses are in use, even if not routed publicly. > First off, someone will have to do a lot more than 5 minutes of poking > router-servers to see just how sparsely used ("announced") the space > really is. That includes digging through BGP histories to see if it's > ever been announced. Then research who should be in control of the > space (announced or not.) Then send out nasty sounding letters > informing whomever that X address space has not been announced to the > public internet in Y years; on Z date, the space will reenter the > IANA/ICANN free pool for reassignment. (cue lawyers :-)) They'd also > be highly motivated to return unused space if they were being billing > for it. > All of this would have to be accomplished in less than 6-9 months, but no one is going to wait in the hopes it might be accomplished, as failure would mean ruin. So the networks will deploy counter measures before the 6-9 month mark. They are already in the process. > > As for this "not fixing the problem", IPv4 is going to be a problem > for MANY years to come. IPv6 deployment is glacially slow. IPv4 > being "out of space" is getting news attention now, but will fade from > the spotlight shortly. The people who have space will continue to > have it and generally not notice the lack of availablity. The likes > of Facebook, etc., have jumped on IPv6 because they have a reason > to... they have volumes of IPv6 connected eyeballs. Yet the likes of > Amazon and Akamai, aren't supporting IPv6 (and have no published plans > to.) Almost all of the major ISPs in the country still don't fully > support IPv6 -- the few that do embrace v6 make it a pain in the ass > to get it setup. I don't support IPv6 (since elink killed their > experiment); I can get everywhere I care to go, and everyone who cares > to get to me does. I, like many/most others, will fix that problem > when it *is* a problem. > IPv4 will not be a problem for MANY years to come. If it survives 5 years in the DFZ, I'll be shocked. Errr, wasn't it this list that Akamai said they were testing and working on IPv6 deployments less than a week ago? Also, just because I have space (currently a /19 free), only means I have until that space runs out (assigning a /22 to a telco tomorrow morning as they just hit 98% utilization tonight, technically 100%, but I managed to free up a few). After that, IPv4 requires CGN or IPv6 with NAT64/DNS64. Neither option is pretty. Jack From jeroen at mompl.net Thu Feb 10 22:37:56 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Thu, 10 Feb 2011 20:37:56 -0800 Subject: Cruzio peering Message-ID: <4D54BD24.8090809@mompl.net> A Cruzio employee kindly provided me with the following information regarding their peering and connectivity. I pasted it below (with permission) because I thought it might be of use to others: "Cruzio maintains a backbone of wireless points of presence (POP) on various mountain tops overlooking the Monterey Bay, South San Francisco Bay, and Silicon Valley Regions. Cruzio wireless POPs are present on Mount Umunhum, Mount Allison, Loma Prieta and Black Mountain to name a few. Cruzio wireless POPs are fed from the Equinix San Jose facility. At Equinix, Cruzio is cross connected into a peering exchange to an aggregate of content providers which include Google, You Tube and several others. Non-peered connectivity is provided by Above.net who is also colocated in that facility. Cruzio leases dark fiber on the cable built and owned by Sunesys, which is also used by UCSC. This fiber cable links the Cruzio facility at 877 Cedar Street in downtown Santa Cruz with the Level 3 Sunnyvale facility 46 miles away. Connectivity to the Internet is provided by Level 3 and Cogent. A high-speed/high-bandwidth wireless link connects the Cruzio 877 Cedar facility with the Equinix San Jose facility via Mount Umunhum to provide a wireless failover to the fiber in event of a fiber outage. Cruzio wholesales AT&T DSL. All DSL traffic is aggregated over AT&T fiber to the 200 Paul Avenue facility where it is connected to the Internet through a variety of providers. While the fiber and new data center are being turned up and tested, Cruzio hosted servers remain connected over AT&T fiber to the he.net Fremont 1 facility. Connectivity to the Internet is through he.net, who are themselves connected and peered to multiple Tier 1 providers." -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From jeroen at mompl.net Thu Feb 10 22:46:24 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Thu, 10 Feb 2011 20:46:24 -0800 Subject: Looking for an IPv6 naysayer... In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC139A0@RWC-EX1.corp.seven.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><4D52E942.5000607@ispalliance.net><87sjvxhu1v.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com><8762stc5a7.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1399F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC139A0@RWC-EX1.corp.seven.com> Message-ID: <4D54BF20.2030903@mompl.net> On 02/09/2011 03:47 PM, George Bonser wrote: > I have yet to see a broadband provider that configures a network so that > individual nodes in the home network get global IPs. The big providers probably categorise a static IP in their "enterprise/business" offerings. But both my provider here (Cruzio) as well as xs4all back in the Netherlands provide a static IP with configurable rDNS. For no fee or a minimal fee. I guess it depends more on which type of provider you choose and their lousy el cheapo offerings. There are more providers than comcast, verizon and at&t. And I bet the majority of them are more knowledgeable (and less likely to do nasty things with your traffic). Regards, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From gbonser at seven.com Thu Feb 10 22:52:40 2011 From: gbonser at seven.com (George Bonser) Date: Thu, 10 Feb 2011 20:52:40 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com><245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com><8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> > As for this "not fixing the problem", IPv4 is going to be a problem for > MANY years to come. IPv6 deployment is glacially slow. IPv4 being > "out > of space" is getting news attention now, but will fade from the > spotlight > shortly I don't know about that. Yes, v4 will be around for a long time but considering the oligopolies we have in both eyeball and content networks, ones a dozen or so very large networks switch, there is the vast majority of Internet traffic right there. It will be around for a very long time handling a tiny bit of traffic. Facebook alone accounts for 25% of internet traffic in the US. Netflix is estimated to be over 20% and YouTube at 10%. So that's 55% of Internet traffic right there. At the other end of the transaction you have AT&T with 15.7 million, Comcast at 15.9 million, Verizon at 9.2 million and Time Warner at 8.9 million (early 2010 numbers). That's 50 million of the estimated 83 million US broadband subscribers. So once three content providers and four subscriber nets switch, that is over 25% of US internet traffic on v6 (more than half the users and more than half the content they look at). I don't think the growth of v6 traffic is going to be gradual, I think it will increase in steps. You will wake up one morning to find your v6 traffic doubled and some other morning it will double again. From bonomi at mail.r-bonomi.com Thu Feb 10 23:19:49 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Thu, 10 Feb 2011 23:19:49 -0600 (CST) Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <4D549F84.4030200@brightok.net> Message-ID: <201102110519.p1B5Jnkk045759@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Thu Feb 10 20:35:01 2011 > Date: Thu, 10 Feb 2011 20:31:32 -0600 > From: Jack Bates > To: John Curran > Subject: Re: "Leasing" of space via non-connectivity providers > Cc: NANOG > > On 2/10/2011 8:15 PM, John Curran wrote: > > I'm not certain that you could rely on any organizations statements > > made today to provide any assurance that circumstances would not change > > in the future and result in the address space being returned to ARIN or > > transferred per current policy. > > An official statement from the DoD? I'm sure we could hold them to it as > a community. Is it too much for us to ask the US government to give us > assurance that we can safely utilize huge chunks of address space > assigned to them for purposes such as LSN without fear? :) Even the DoD cannot say "for sure" that they would never route some of that space 'in time of need' over the public internet. From drc at virtualized.org Thu Feb 10 23:31:21 2011 From: drc at virtualized.org (David Conrad) Date: Thu, 10 Feb 2011 19:31:21 -1000 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> Message-ID: On Feb 10, 2011, at 5:46 PM, Ricky Beam wrote: > On Thu, 10 Feb 2011 11:43:50 -0500, Matthew Kaufman wrote: >> There is no one universal "global routing table". They probably appear in someone's routing table, somewhere... just not yours. > Using public address space for private networking is a gross misuse of the resource. Amusingly enough, I personally (along with others) made arguments along these lines back in 1995 or so when the IAB was coming out with http://www.ietf.org/rfc/rfc1814.txt. Given the publication of 1814, you can probably guess how far those arguments fared. > Go to any registry and ask for address space for your private networking that you do not intend to announce to the internet. They will laugh at you, and point you to RFC1918. (and likely flag you as someone to whom address space should never be assigned.) The only reason legacy holders get away with such crap is because there's no clear contract governing their assignment. I haven't looked recently but I believe all the RIRs have policies that requires them to allocate unique numbers regardless of whether those addresses will be used on the Internet, as long as the requester documents appropriate utilization. > Then send out nasty sounding letters informing whomever that X address space has not been announced to the public internet in Y years; on Z date, the space will reenter the IANA/ICANN free pool for reassignment. (cue lawyers :-)) I gather you're volunteering to pay higher fees to cover the increased legal costs? Regards, -drc From marka at isc.org Thu Feb 10 23:45:35 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 11 Feb 2011 16:45:35 +1100 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: Your message of "Fri, 11 Feb 2011 02:44:46 -0000." <78697910-F7A6-4D53-AD93-377FCE66006D@arin.net> References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <20110205193328.GC22325@vacation.karoshi.com> <08F8827D-D8C3-4922-AC39-6C71ADBE8BDB@corp.arin.net> <20110206014014.GG22325@vacation.karoshi.com> <849FDB3F-EE29-48D6-8ECD-70AE6EB0B157@virtualized.org> <71571.1297311453@nsa.vix.com> <26604DDB-1EC5-43B4-B60F-EEF7CEF4132D@corp.arin.net> <4D549A7C.1000708@brightok.net> <4D549F84.4030200@brightok.net> <78697910-F7A6-4D53-AD93-377FCE66006D@arin.net> Message-ID: <20110211054535.BE21D9E76C9@drugs.dv.isc.org> In message <78697910-F7A6-4D53-AD93-377FCE66006D at arin.net>, John Curran writes: > On Feb 10, 2011, at 10:31 PM, Jack Bates wrote: > > > On 2/10/2011 8:15 PM, John Curran wrote: > >> I'm not certain that you could rely on any organizations statements made= > today > >> to provide any assurance that circumstances would not change in the futu= > re and > >> result in the address space being returned to ARIN or transferred per cu= > rrent > >> policy. > >=20 > > An official statement from the DoD? I'm sure we could hold them to it as = > a community. Is it too much for us to ask the US government to give us assu= > rance that we can safely utilize huge chunks of address space assigned to t= > hem for purposes such as LSN without fear? :) > > In organizations of all sizes, positions and policies change,=20 > with revised statements as a result. One thing that does not > change, however, is contractual commitments, and in this one > case I can state that there is a commitment to return IPv4=20 > address blocks to ARIN for reuse by the community if they no=20 > longer needed. > > If you'd like to reserve a large block for purposes of LSN=20 > without any concern of future address conflict, it would be=20 > best to actually reserve it via community-developed policy. The first half of Class E would work. There are 134+ million addresses there and you only have to be able to route it between the CPE and the LSN / 6rd BR. The CPE signals that it support Class E (DHCP/PPP option) and the ISP only assigns a address from the block if it knows the path is Class E clean. Anyone that can't work with double NAT would clear the option and it would be on by default. It should be possible to patch all existing CPE devices to support this without flash memory constraints. The same can't be said for upgrading then to support IPv6. It does require the whole world to upgrade to be useful. It can be done incrementally. It will significiantly reduce the remaining IPv4 consumption rate. Those CPE's that turn on 6to4 automatically now have another well known address range where it is known not to work. It doesn't clash with address ranges already in use by customers. It can be used with 6rd so that IPv6 can be deployed over it for ISP's that have boxes that can't be upgraded to IPv6. It gives them a little more breathing room. > FYI, > /John > > John Curran > President and CEO > ARIN -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From joelja at bogus.com Fri Feb 11 00:40:05 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 10 Feb 2011 22:40:05 -0800 Subject: Failure modes: NAT vs SPI In-Reply-To: <201102101053.59300.lowen@pari.edu> References: <13040078.4555.1296760192315.JavaMail.root@benjamin.baylink.com> <201102101053.59300.lowen@pari.edu> Message-ID: <4D54D9C5.7060501@bogus.com> On 2/10/11 7:53 AM, Lamar Owen wrote: > On Monday, February 07, 2011 04:33:23 am Owen DeLong wrote: >> 1. Scanning even an entire /64 at 1,000 pps will take 18,446,744,073,709,551 seconds >> which is 213,503,982,334 days or 584,542,000 years. >> >> I would posit that since most networks cannot absorb a 1,000 pps attack even without >> the deleterious effect of incomplete ND on the router, no network has yet had even >> a complete /64 scanned. IPv6 simply hasn't been around that long. > > Sounds like a job for a 600 million node botnet. You don't think this hasn't already crossed botnet ops minds? There are more useful things to do with the compute cycles... From jfbeam at gmail.com Fri Feb 11 00:51:04 2011 From: jfbeam at gmail.com (Ricky Beam) Date: Fri, 11 Feb 2011 01:51:04 -0500 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> Message-ID: On Fri, 11 Feb 2011 00:31:21 -0500, David Conrad wrote: > Amusingly enough, I personally (along with others) made arguments along > these lines back in 1995 or so when the IAB was coming out with > http://www.ietf.org/rfc/rfc1814.txt. Given the publication of 1814, you > can probably guess how far those arguments fared. You missed the "anticipates external connectivity to the Internet" part. Networks that never touch the internet have RFC1918 address space to use. (and that works 99.999% of the time.) > I haven't looked recently but I believe all the RIRs have policies that > requires them to allocate unique numbers regardless of whether those > addresses will be used on the Internet, as long as the requester > documents appropriate utilization. Per the wording of ARIN's policy, they require justification for such an allocation. (i.e. a damn good reason 1918 addresses aren't going to work for you.) --Ricky From joelja at bogus.com Fri Feb 11 00:51:11 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 10 Feb 2011 22:51:11 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> Message-ID: <4D54DC5F.7090609@bogus.com> On 2/10/11 5:31 AM, Cutler James R wrote: > > On Feb 10, 2011, at 12:15 AM, Ricky Beam wrote: > >> On Wed, 09 Feb 2011 16:42:14 -0500, Nathan Eisenberg >> wrote: >>> What do you mean, lit up? You mean they're not in the routing >>> tables that you get from your carriers? I'd argue that's no >>> indication of whether they're in use or not. >> >> That's pretty much the definition of "in use". If they don't >> appear in the global routing table, then they aren't being used. I >> cannot send traffic to them; they cannot send traffic to me. >> >> In my recent probe of route servers, I found 22 legacy /8's that >> were partly or completely unused. I'm a little surprised >> ARIN/ICANN thinks it's a waste of time to even try to reclaim >> them. >> >> --Ricky > > This dead horse keep coming back for another beating. The purpose of > a global registry of numbers is to provide a common source for unique > numbers. The definition of "in use" by internet registries does not > require appearance in your routing tables or even in the route > servers. Not only that, the "users" may not even want or need to > exchange traffic with you. > > As a survivor of many network consolidations due to corporate > acquisitions, I have many scars from trying to get separate RFC 1918 > islands to interwork properly. That is the reason that even so-called > private networks need unique IP addressing. more to the point, every partner / customer integration exercise that involves backend networks has rfc 1918 somewhere, e.g. it's not justd M&A and the pain doesn't go away. intersecticing address assignments for hundreds and potentiatly thousands of hosts when it comes to public cloud integration are a signficant drag on opertations, involve not just nat but additional split horizons and so fourth... This is not just speculation, this stuff happens in our environment virtually every-day. > And now, since IPv6 is actually being deployed and used, there is > absolutely no economic incentive to continue to fight the "IPv4 > addresses not in my routing table are not 'in use'" battle any more. > It is a waste of time and money. > > James R. Cutler james.cutler at consultant.com > > > > > > From owen at delong.com Fri Feb 11 00:57:21 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 10 Feb 2011 22:57:21 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> Message-ID: <7FFF8D72-43E7-47EB-B53D-894F0EFD32C5@delong.com> On Feb 10, 2011, at 7:46 PM, Ricky Beam wrote: > On Thu, 10 Feb 2011 11:43:50 -0500, Matthew Kaufman wrote: >> There is no one universal "global routing table". They probably appear in someone's routing table, somewhere... just not yours. > > Using public address space for private networking is a gross misuse of the resource. Go to any registry and ask for address space for your private networking that you do not intend to announce to the internet. They will laugh at you, and point you to RFC1918. (and likely flag you as someone to whom address space should never be assigned.) The only reason legacy holders get away with such crap is because there's no clear contract governing their assignment. > Um... From the ARIN NRPM: 4.3.5. Non-connected Networks End-users not currently connected to an ISP and/or not planning to be connected to the Internet are encouraged to use private IP address numbers reserved for non-connected networks (see RFC 1918). When private, non-connected networks require interconnectivity and the private IP address numbers are ineffective, globally unique addresses may be requested and used to provide this interconnectivity. Notice how it specifically allows a non-connected network to request and use globally unique addresses? If you think that should be changed, then, you need to get on PPML and submit a policy proposal to change that. For now, no, they will not laugh at you (at least not at ARIN), they will actually issue the numbers if you approach them with an appropriate justification. >> How many days do you think a single /8 lasts at current assignment rates? > > APNIC says the last 2 /8's they were assigned (triggering the dead-man clause) would last ~6mo. With responsible use, 22 /8's would last several years. (3-5 best guess. Of course, there could be a land-rush and all of it disappear next week -- see also: responsible use) > That's 1 of 5 RIRs, so, even if you consider them a straw-man model, that's 20 /8s per year. Please tell me how a consumption rate of 20 /8s per year can take 3-5 years to consume 22 /8s You seem to be particularly bad at math or you don't understand the RIR system. I'm not sure which. Also, note that at the time APNIC got their last 2 /8s all of the other RIRs were 2 or more months ahead of them in exhausting their last IANA allocations. >> How would ARIN/ICANN go about reclaiming addresses that someone believes they are using but that you don't think are in use? > > First off, someone will have to do a lot more than 5 minutes of poking router-servers to see just how sparsely used ("announced") the space really is. That includes digging through BGP histories to see if it's ever been announced. Then research who should be in control of the space (announced or not.) Then send out nasty sounding letters informing whomever that X address space has not been announced to the public internet in Y years; on Z date, the space will reenter the IANA/ICANN free pool for reassignment. (cue lawyers :-)) They'd also be highly motivated to return unused space if they were being billing for it. > As multiple people have pointed out to you, never announced in a visible way is not the same as not in use. ARIN policy specifically allows use for non-connected networks. If you don't like that fact, you can attempt to change ARIN policy. Such a change being applied retro-actively, however, is unlikely to succeed IMHO. If you can't apply it retroactively, then, the existing networks that are using unique addresses on their private networks will not be forced to return them. > As the powers that be have drug their feet for over a decade already, I really doubt they'll even take 5 minutes to look at *a single* route server. > This isn't foot-dragging. This is recognizing the art of the possible and understanding the reality of the situation. I realize you are apparently loathe to do so. > As for this "not fixing the problem", IPv4 is going to be a problem for MANY years to come. IPv6 deployment is glacially slow. IPv4 being "out of space" is getting news attention now, but will fade from the spotlight shortly. The IPv4 will be a problem for a few years. This will not improve that fact. IPv6 deployment has been glacially slow, but, is accelerating rapidly, especially since 1/31. > people who have space will continue to have it and generally not notice the lack of availablity. The likes of People who have space may not notice a need for space on their networks, but, they will absolutely notice a need for access to or from up and coming IPv6-only networks where users have limited, degraded, or no connectivity to IPv4. > Facebook, etc., have jumped on IPv6 because they have a reason to... they have volumes of IPv6 connected eyeballs. Yet the likes of Amazon and Akamai, aren't supporting IPv6 (and have no published plans to.) Almost all of http://www.akamai.com/ipv6 Looks like a public announcement on IPv6 from Akamai to me. I am not sure about Amazon. I couldn't find anything in a quick google search. Certainly it would be good if they had a plan and better if they announced it. > the major ISPs in the country still don't fully support IPv6 -- the few that do embrace v6 make it a pain in the ass to get it setup. I don't support IPv6 (since elink killed their experiment); I can get everywhere I care to go, and everyone who cares to get to me does. I, like many/most others, will fix that problem when it *is* a problem. > Actually, the major ISPs do support IPv6 on some level. There are several providers, Hurricane Electric included, where you can get IPv6 easily set up and it is relatively painless, actually. There are others that are still debugging their business processes around IPv6. I suspect this will rapidly improve in the coming months. > (For the record... TWTC: not supported, Speakeasy: not supported, VZB: not recommended for an existing connection (if you want it to stay working)) > For the record: TWTC: Supported, TWC: Working on it. VZB: Actually, I know a few people that have working dual-stack connections with VZB and did not have any major issues with the conversion from IPv4 to dual stack. This is by no means any sort of exhaustive list of major providers or even a top 3. It's a rather odd choice of 3 as near as I can tell. A somewhat out of date, but, more detailed perspective is here: http://en.wikipedia.org/wiki/IPv6_deployment There are a number of providers offering Native IPv6 not listed there. Owen From joelja at bogus.com Fri Feb 11 01:34:41 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 10 Feb 2011 23:34:41 -0800 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <4D54A4EC.5060209@brightok.net> References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205105731.GA20900@vacation.karoshi.com> <9FD4A48D-B17D-461B-8EF9-0D3F94CAB98F@arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <20110205193328.GC22325@vacation.karoshi.com> <08F8827D-D8C3-4922-AC39-6C71ADBE8BDB@corp.arin.net> <20110206014014.GG22325@vacation.karoshi.com> <849FDB3F-EE29-48D6-8ECD-70AE6EB0B157@virtualized.org> <71571.1297311453@nsa.vix.com> <26604DDB-1EC5-43B4-B60F-EEF7CEF4132D@corp.arin.net> <4D549A7C.1000708@brightok.net> <4D549F84.4030200@brightok.net> <78697910-F7A6-4D53-AD93-377FCE66006D@arin.net> <4D54A4EC.5060209@brightok.net> Message-ID: <4D54E691.7030109@bogus.com> On 2/10/11 6:54 PM, Jack Bates wrote: > On 2/10/2011 8:44 PM, John Curran wrote: >> >> If you'd like to reserve a large block for purposes of LSN >> without any concern of future address conflict, it would be >> best to actually reserve it via community-developed policy. >> > > When there are X /8 networks reserved by the USG, it seems extremely > wasteful to reserve from what little space we have a large block > dedicated to LSN when the USG can give assurances that reserved and assigned are different. The prefixes are assigned. > 1) We won't route this, so use it > > 2) We won't be giving it back or allocating it to someone else where it > might be routed. > > All proposals concerning reserving a /8 of unallocated space for LSN > purposes was seen as obscene, and many proposals compromised with a /10, > which some feel is too small. I don't think it would hurt for someone > with appropriate connections to ask the USG on the matter. It is, after > all, in the USG's interest and doesn't conflict with their current > practices. Many don't consider it a concern (shown by wide use of DoD > space already deployed), yet some do apparently have concern since there > has been multiple requests for a new allocation for LSN purposes (in the > IETF and in RIRs). > > > Jack > From a.harrowell at gmail.com Fri Feb 11 02:16:09 2011 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Fri, 11 Feb 2011 08:16:09 +0000 Subject: "Leasing" of space via non-connectivity providers In-Reply-To: <4D54ACE8.1080902@brightok.net> References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <20110205162221.GE20900@vacation.karoshi.com> <1CC2F3D8-8417-46FF-9AD4-A6FB2453D407@istaff.org> <1BE05D2B-A910-4F45-AB6D-DABC06F19580@pch.net> <20110205182734.GB22325@vacation.karoshi.com> <3867203A-05E5-478B-B467-ABA371027743@pch.net> <20110205193328.GC22325@vacation.karoshi.com> <08F8827D-D8C3-4922-AC39-6C71ADBE8BDB@corp.arin.net> <20110206014014.GG22325@vacation.karoshi.com> <849FDB3F-EE29-48D6-8ECD-70AE6EB0B157@virtualized.org> <71571.1297311453@nsa.vix.com> <26604DDB-1EC5-43B4-B60F-EEF7CEF4132D@corp.arin.net> <4D549A7C.1000708@brightok.net> <4D549F84.4030200@brightok.net> <78697910-F7A6-4D53-AD93-377FCE66006D@arin.net> <4D54A4EC.5060209@brightok.net> <102CB5C2-D884-4089-A275-0D9187E9C7BA@puck.nether.net> <4D54ACE8.1080902@brightok.net> Message-ID: <76621102-fd03-43b6-b5ee-4c9be9d82945@email.android.com> There are major GSM-land wireless operators who provide service to devices like Novatel's line of pocket-size WLAN hotspots. You can just buy one and stick a SIM in it, but some of the ops offer them as part of a business user package. I hope that means they get a proper IP or more handed out from the SGSN, as otherwise this would be a true orgy of NAT. (Top posting on mobile) "Jack Bates" wrote: >On 2/10/2011 9:11 PM, Jared Mauch wrote: >> I was explaining to my wife today how it felt like the nanog list >went to 3x the typical mail volume recently with all the IPv6 stuff >this month. Why the pro-IPv6 crowd was happy, the anti-IPv6 crowd is >groaning (including those that truly despise the whole thing, etc..) > >I was having fun discussing with my wife how ARIN stuff ended up on >NANOG, NANOG stuff ended up on PPML, and I've been listening and >participating in debates concerning IPv6 and CGN (apparently BEHAVE WG >adopted CGN over LSN) on 4 different mailing lists. > >To be honest, though. I'm pro-IPv6, but I'm not happy. Anyone who is >happy doesn't care about those innocent people who are ignorant of what > >is going on and why. > >> I honestly think that the LSN situations won't be as bad as some of >us think. The big carriers have already been doing some flavor of this >with their cellular/data networks. Doing this on some of the consumer >networks will likely not be "that much" pain. Obviously the pain will >vary per subscriber/home. > > >> IPv4 is "dead" in my opinion. Not dead as in useless, but to the >point where I don't think there is value in spending a lot of time >worrying about the v4 side of the world when so much needs to be fixed >in IPv6 land. >Service requirements in cellular networks are considerably different >than wireline. Apparently, most cell customers don't hook a CPE router >into their cell network and play their game consoles over it, along >with >many other situations. This actually means that most often, they are >running a single stage NAT44 LSN (which still breaks stuff, but most of > >the things it would break aren't normally transiting the cellular >networks). > > > >I agree. However, because the largest networks and corporations decided > >(and some still do) to wait until the last moment to deal with IPv6, we > >will have to deal with IPv4 in much worse conditions. I know that there > >are large cellular networks which use DoD bogons behind huge LSN >implementations. I know that some networks apparently aren't happy with > >using DoD bogons and would like to waste even more space. The best >solution for such a case (and to solve all arguments on the matter) is >to secure assurances on the bogons so that they can be safely used. > > > > >Jack -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From arturo.servin at gmail.com Fri Feb 11 05:07:26 2011 From: arturo.servin at gmail.com (Arturo Servin) Date: Fri, 11 Feb 2011 09:07:26 -0200 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> Message-ID: On 11 Feb 2011, at 04:51, Ricky Beam wrote: > On Fri, 11 Feb 2011 00:31:21 -0500, David Conrad wrote: >> Amusingly enough, I personally (along with others) made arguments along these lines back in 1995 or so when the IAB was coming out with http://www.ietf.org/rfc/rfc1814.txt. Given the publication of 1814, you can probably guess how far those arguments fared. > > You missed the "anticipates external connectivity to the Internet" part. Networks that never touch the internet have RFC1918 address space to use. (and that works 99.999% of the time.) > Except in acquisitions and private peering. as From juicewvu at gmail.com Fri Feb 11 07:42:07 2011 From: juicewvu at gmail.com (Josh Smith) Date: Fri, 11 Feb 2011 08:42:07 -0500 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> Message-ID: On Fri, Feb 11, 2011 at 6:07 AM, Arturo Servin wrote: > > On 11 Feb 2011, at 04:51, Ricky Beam wrote: > >> On Fri, 11 Feb 2011 00:31:21 -0500, David Conrad wrote: >>> Amusingly enough, I personally (along with others) made arguments along these lines back in 1995 or so when the IAB was coming out with http://www.ietf.org/rfc/rfc1814.txt. ?Given the publication of 1814, you can probably guess how far those arguments fared. >> >> You missed the "anticipates external connectivity to the Internet" part. ?Networks that never touch the internet have RFC1918 address space to use. (and that works 99.999% of the time.) >> > > ? ? ? ?Except in acquisitions and private peering. > > as Especially during acquisitions, my $EMPLOYEER has made several acquisitions recently and every one of them was wrought with painful RFC1918 overlap problems. Thanks, Josh Smith KD8HRX email/jabber:? juicewvu at gmail.com phone:? 304.237.9369(c) From khelms at ispalliance.net Fri Feb 11 08:38:02 2011 From: khelms at ispalliance.net (Scott Helms) Date: Fri, 11 Feb 2011 09:38:02 -0500 Subject: Looking for an IPv6 naysayer... In-Reply-To: <20110210224123.539B09E32CF@drugs.dv.isc.org> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> <833804CE-80D9-4CED-8672-CF0870317E8C@delong.com><4D531B52.70404@ispalliance.net> <20110210002231.23F0E9DCFDD@drugs.dv.isc.org> <4D53FD00.40900@ispalliance.net> <20110210224123.539B09E32CF@drugs.dv.isc.org> Message-ID: <4D5549CA.2080409@ispalliance.net> > ISPs know it takes years to move a customer base. They should have > been ready years ago. They still arn't ready. I was asking for > what features to look for in a new CPE so that it won't need to be > replaced when they turn on IPv6 and got this as a answer. It really > isn't helpful. Mark, I certainly wasn't trying to be flip or short and for that I apologize. To answer the specific question on a CPE that depends both on what kind of access network you're connecting to as well as if its a service provider installed/supported device or one that a technical end user can support him/herself as those are very different use cases. The point I am trying to communicate is that CPE issue not simple, straightforward, or cheap because in almost all of the non-DOCSIS cases we're looking at forklift upgrades. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From khelms at ispalliance.net Fri Feb 11 09:00:57 2011 From: khelms at ispalliance.net (Scott Helms) Date: Fri, 11 Feb 2011 10:00:57 -0500 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com><245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com><8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> Message-ID: <4D554F29.8070903@ispalliance.net> > I don't know about that. Yes, v4 will be around for a long time but > considering the oligopolies we have in both eyeball and content > networks, ones a dozen or so very large networks switch, there is the > vast majority of Internet traffic right there. It will be around for a > very long time handling a tiny bit of traffic. > Agreed, V4 traffic levels are likely to drop and stay at low levels for decades. > Facebook alone accounts for 25% of internet traffic in the US. Netflix > is estimated to be over 20% and YouTube at 10%. So that's 55% of > Internet traffic right there. At the other end of the transaction you > have AT&T with 15.7 million, Comcast at 15.9 million, Verizon at 9.2 > million and Time Warner at 8.9 million (early 2010 numbers). That's 50 > million of the estimated 83 million US broadband subscribers. So once > three content providers and four subscriber nets switch, that is over > 25% of US internet traffic on v6 (more than half the users and more than > half the content they look at). Comcast, nor the other large MSOs, are not as monolithic as they may appear from the outside. In most cases the large MSOs are divided into regions that are more or less autonomous and that doesn't count the outlier properties that haven't been brought into the fold of the region they are in for various, usually cost related, reasons so don't expect a large block of any of those guys to suddenly be at 60% of their users can get IPv6 addresses. While Facebook working over IPv6 will be a big deal you won't get all of their traffic since a significant fraction of that traffic is from mobile devices which are going to take much longer than PCs to get to using IPv6 in large numbers. Also, Netflix is even more problematic since the bulk of their traffic, and the fastest growing segment as well, is coming from Xboxes, Tivos, other gaming consoles, and TVs with enough embedded brains to talk directly. Those devices will also seriously lag behind PCs in IPv6 support. > I don't think the growth of v6 traffic is going to be gradual, I think > it will increase in steps. You will wake up one morning to find your > v6 traffic doubled and some other morning it will double again. They'll be jumps, but they will be fairly smallish jumps since both the content maker, the ISP, and the device consuming the content all have to be ready. Since I don't imagine we will see any pure IPv6 deployments any time soon many/most of the IPv6 deploys will be dual stack and so we are still at the mercy of the AAAA record returning before the A record does. > > > > > > > > -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From a.harrowell at gmail.com Fri Feb 11 09:13:54 2011 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Fri, 11 Feb 2011 15:13:54 +0000 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <4D554F29.8070903@ispalliance.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> <4D554F29.8070903@ispalliance.net> Message-ID: <201102111514.07572.a.harrowell@gmail.com> On Friday 11 February 2011 15:00:57 Scott Helms wrote: > While Facebook working over IPv6 will be a big deal you won't get all of > their traffic since a significant fraction of that traffic is from > mobile devices which are going to take much longer than PCs to get to > using IPv6 in large numbers. Also, Netflix is even more problematic > since the bulk of their traffic, and the fastest growing segment as > well, is coming from Xboxes, Tivos, other gaming consoles, and TVs with > enough embedded brains to talk directly. Those devices will also > seriously lag behind PCs in IPv6 support Recommendation: if you're doing some sort of under-the-TV device, if it does 6to4 or some other kind of IPv6 tunnelling (like Apple Airports), colocate your relay/vpn host/tunnel exit points with content CDN servers rather than sending everything via your head office location. If you're snooping on the traffic, you can always configure the nodes to do that:-{0 -- The only thing worse than e-mail disclaimers...is people who send e-mail to lists complaining about them -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From jfbeam at gmail.com Fri Feb 11 10:02:07 2011 From: jfbeam at gmail.com (Ricky Beam) Date: Fri, 11 Feb 2011 11:02:07 -0500 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <4D554F29.8070903@ispalliance.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> <4D554F29.8070903@ispalliance.net> Message-ID: On Fri, Feb 11, 2011 at 10:00 AM, Scott Helms wrote: > Agreed, V4 traffic levels are likely to drop and stay at low levels for > decades. I seriously doubt v4 traffic is going to fall off a cliff. That would require IPv6 adoption on a large scale over a relatively short period. To date, nothing in the v6 verse has happened *quickly*. Replacement or software upgrades to millions of CPEs in hundreds of network is not something that will happen overnight. Even then, that will not instantly switch everyone and every device to IPv6. How many "connected" devices do you think there are in the average home? TV? DVR (stb)? Game console(s)? Netflix streaming thing? If you're using Windows 7, you're already "IPv6 connected"... IPv6 is installed by default (and in fact cannot be uninstalled) and configured with Teredo. So a lot of people could be using v6 already and not even know it. >> Facebook ... So that's 55% of Internet traffic right there. and making a dent in it means residential transition. 50mil (or 83mil) devices is a lot of shit to replace or reprogram. Not to forget the thousands of devices that feed them. > ... mobile devices i.e. cellphones... the two largest groups there (iPhone and Android) support IPv6 already. (in certain versions) I was saying the same thing about netflix. PC based streaming can already be done via IPv6. (ipv6.netflix.com?) I'm not sure any of my media devices (tv, consoles, tivo) can do IPv6. I'd be disappointed if SONY didn't have the PS3 doing v6. Tivo doesn't do v6 -- unless the premier does. DTV receiver doesn't. DISH doesn't. (Wii, don't care. :-)) --Ricky From bill at herrin.us Fri Feb 11 10:51:40 2011 From: bill at herrin.us (William Herrin) Date: Fri, 11 Feb 2011 11:51:40 -0500 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> Message-ID: On Thu, Feb 10, 2011 at 10:46 PM, Ricky Beam wrote: > On Thu, 10 Feb 2011 11:43:50 -0500, Matthew Kaufman > wrote: >> There is no one universal "global routing table". They probably appear in >> someone's routing table, somewhere... just not yours. > > Using public address space for private networking is a gross misuse of the > resource. Ricky, One example I heard was a generic financial exchange connected to perhaps a hundred other companies. Those companies also connect to the Internet but the exchange itself does not. It's valuable for the exchange to use addressing which will not conflict with any of its customers' RFC1918 use or overlap any Internet destinations they want to access. This is why ULA in IPv6 has statistical uniqueness -- so that organizations with similar requirements don't need to use Internet-routable addresses. We can't backport ULA into IPv4 private addressing; there aren't enough addresses for the math to work. So we either make such folks jump through all kinds of hoops to get their networks to function, or we assign addresses that could otherwise be used on the big-I Internet. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From gbonser at seven.com Fri Feb 11 11:20:59 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 11 Feb 2011 09:20:59 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com><245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com><8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at><5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com><4D554F29.8070903@ispalliance.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13A3E@RWC-EX1.corp.seven.com> > On Fri, Feb 11, 2011 at 10:00 AM, Scott Helms > wrote: > > Agreed, V4 traffic levels are likely to drop and stay at low levels > for > > decades. > > I seriously doubt v4 traffic is going to fall off a cliff. That would > require IPv6 adoption on a large scale over a relatively short period. The thing is that a very few networks account for a very large amount of traffic. So it depends on what you mean by "adoption on a large scale". <1% of the networks account for >50% of the traffic. If a handful of networks move to v6, then we have a very large amount of v6 traffic and a significant decrease in v4 traffic. It depends on if you mean large numbers of different endpoints or large numbers of packets when you say "adoption on a large scale". Joe's Fish Farm might and all the other Fish Farms might stay v4 for a decade or more but that traffic accounts for an insignificant portion of traffic in the context of internet traffic as a whole. > To date, nothing in the v6 verse has happened *quickly*. Replacement > or software upgrades to millions of CPEs in hundreds of network is not > something that will happen overnight. What is the natural "churn" rate for CPE for one of the large MSOs? What portion of the MSOs have v6 capable CPE in place right now but v6 just isn't in use but is planned to go into v6 service soon? You don't need to migrate "hundreds" of networks to account for the majority of eyeball internet traffic in North America, you only need about five. It could be that v6 capable CPE has been in the process of being rolled out already and has been for months to possibly years. > Even then, that will not > instantly switch everyone and every device to IPv6. How many > "connected" devices do you think there are in the average home? TV? > DVR (stb)? Game console(s)? Netflix streaming thing? Ok, we have been watching our DNS servers for who is requesting AAAA records. The vast majority of our connections come from a very small number of networks. We are seeing requests for AAAA records. The next step is to put a v6 only DNS server into whois but hand out only A records for a while. But the idea is to see what of the requests for AAAA records actually arrive via IPv6. Once we profile that for a while, we will return AAAA records for the largest requester but only for requests arriving by IPv6 requesting AAAA records. The next step is to see that the requests actually result in connections to the service address handed out by the AAAA records and let that "bake" for a while and see if any service oddities are noticed. We happen to be in a unique position in that requests from different remote networks request a unique service address for that remote network and most others don't have that luxury. So if one remote network is v6 clean, we can change one IP address to AAAA records and "migrate" that remote network to v6 without impacting others simply by changing the DNS record for their service IP. If another network has issues, is requesting AAAA records but can't really talk over v6, we can roll back to A records for that service IP associated with that particular remote network. Other providers don't have that luxury and I understand that. But still, once two of those remote networks switch to v6, that is a very significant portion of our traffic. It will be possible, depending on which remote networks migrate and at what speed, for traffic to migrate in "chunks" as we migrate those AAAA records. We might go from 0% of traffic on v6 to 25% of traffic on v6 in less than a calendar quarter depending on the behavior of the remote nets. Also, once THEY see more successful traffic migration to v6, it gives impetus for them to move faster in that direction for additional services. > > >> Facebook ... So that's 55% of Internet traffic right there. > > and making a dent in it means residential transition. 50mil (or > 83mil) devices is a lot of shit to replace or reprogram. Not to > forget the thousands of devices that feed them. Yes, and I mentioned that. So once you have >50% of the potential content sources v6 capable and >50% of the potential eyeballs v6 capable, you have potentially 25% of internet traffic on v6. And that can be done with the migration of enough networks to count on your fingers. So again, are we talking number of networks or number of packets when we say "large scale adoption"? > > ... mobile devices > > i.e. cellphones... the two largest groups there (iPhone and Android) > support IPv6 already. (in certain versions) And are already being given native v6 IP addresses in some markets. Some markets are already doing NAT64 or something to get these devices to v4 content. George From mksmith at adhost.com Fri Feb 11 11:39:42 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Fri, 11 Feb 2011 17:39:42 +0000 Subject: Data Center Recommendations - Germany and China Message-ID: Hello All: I need to find rack space in data centers in Germany and China, although the China requirement is more for low(er) latency access into China rather than needing to be physically in-country. Both data centers have to have the local equivalent of a SAS 70 Type II validation. Please feel free to send these to me offlist and I will summarize if there is an interest. Regards, Mike -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) From bfehn at metcom.org Fri Feb 11 11:42:15 2011 From: bfehn at metcom.org (Robert J. Fehn) Date: Fri, 11 Feb 2011 12:42:15 -0500 Subject: automated response Message-ID: <11102111242.AA1979490138@metcom.org> I will be out of the office until Monday,Februay 21st. I will be checking email daily and, there's always the cell phone. METCOM: Any IT concerns can be handled by Christin Edwards at 301-373-4733 Ext 262 or, email her at: cedwards at metcom.org CALS: IT needs should be addressed to Ronny or Paul. BOD issues can come to me or Vice Chair, Stanis Inscoe PERSONAL: I'll get back to you within 24hrs. Thanks! Bob From mksmith at adhost.com Fri Feb 11 11:48:09 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Fri, 11 Feb 2011 17:48:09 +0000 Subject: Helpful hint from the NANOG Communications Committee Message-ID: Hello Everyone: If you receive an auto-responder message to a NANOG posting, please forward a copy to admins at nanog.org and we'll set the account to no-mail and contact the sender. If you don't send us a copy we won't see it necessarily, so feel free to do so. Regards, Mike NANOG Communications Committee Chair -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) From dmm at 1-4-5.net Fri Feb 11 08:50:16 2011 From: dmm at 1-4-5.net (David Meyer) Date: Fri, 11 Feb 2011 06:50:16 -0800 Subject: [NANOG-announce] NANOG 52 Call for Presentations Open! Message-ID: Please see http://nanog.org/meetings/nanog52/callforpresent.php Dates of interest: Presentation Abstracts and Draft Slides Due: 14 March 2011 Final Slides Due: 16 May 2011 Draft Program Published: 16 May 2011 Final Agenda Published: 11 June 2011 Lightning Talk Submissions Open (Abstracts Only Due): 6 June 2011 Please submit at http://pc.nanog.org, and see you all in Denver. Thanks, Dave _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From arturo.servin at gmail.com Fri Feb 11 12:19:11 2011 From: arturo.servin at gmail.com (Arturo Servin) Date: Fri, 11 Feb 2011 16:19:11 -0200 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> Message-ID: Lucky you. .as On 11 Feb 2011, at 11:42, Josh Smith wrote: > On Fri, Feb 11, 2011 at 6:07 AM, Arturo Servin wrote: >> >> On 11 Feb 2011, at 04:51, Ricky Beam wrote: >> >>> On Fri, 11 Feb 2011 00:31:21 -0500, David Conrad wrote: >>>> Amusingly enough, I personally (along with others) made arguments along these lines back in 1995 or so when the IAB was coming out with http://www.ietf.org/rfc/rfc1814.txt. Given the publication of 1814, you can probably guess how far those arguments fared. >>> >>> You missed the "anticipates external connectivity to the Internet" part. Networks that never touch the internet have RFC1918 address space to use. (and that works 99.999% of the time.) >>> >> >> Except in acquisitions and private peering. >> >> as > > Especially during acquisitions, my $EMPLOYEER has made several > acquisitions recently and every one of them was wrought with painful > RFC1918 overlap problems. > > Thanks, > Josh Smith > KD8HRX > email/jabber: juicewvu at gmail.com > phone: 304.237.9369(c) From cscora at apnic.net Fri Feb 11 12:26:34 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 12 Feb 2011 04:26:34 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201102111826.p1BIQYra022487@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 12 Feb, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 345778 Prefixes after maximum aggregation: 155766 Deaggregation factor: 2.22 Unique aggregates announced to Internet: 170953 Total ASes present in the Internet Routing Table: 35854 Prefixes per ASN: 9.64 Origin-only ASes present in the Internet Routing Table: 30896 Origin ASes announcing only one prefix: 14961 Transit ASes present in the Internet Routing Table: 4958 Transit-only ASes present in the Internet Routing Table: 124 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 31 Max AS path prepend of ASN (36992) 29 Prefixes from unregistered ASNs in the Routing Table: 332 Unregistered ASNs in the Routing Table: 131 Number of 32-bit ASNs allocated by the RIRs: 1110 Prefixes from 32-bit ASNs in the Routing Table: 1 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 205 Number of addresses announced to Internet: 2391302464 Equivalent to 142 /8s, 136 /16s and 97 /24s Percentage of available address space announced: 64.5 Percentage of allocated address space announced: 64.5 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 87.9 Total number of prefixes smaller than registry allocations: 142918 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 85341 Total APNIC prefixes after maximum aggregation: 28875 APNIC Deaggregation factor: 2.96 Prefixes being announced from the APNIC address blocks: 82125 Unique aggregates announced from the APNIC address blocks: 35753 APNIC Region origin ASes present in the Internet Routing Table: 4317 APNIC Prefixes per ASN: 19.02 APNIC Region origin ASes announcing only one prefix: 1203 APNIC Region transit ASes present in the Internet Routing Table: 690 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 17 Number of APNIC addresses announced to Internet: 587134752 Equivalent to 34 /8s, 254 /16s and 247 /24s Percentage of available APNIC address space announced: 74.5 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 139230 Total ARIN prefixes after maximum aggregation: 71212 ARIN Deaggregation factor: 1.96 Prefixes being announced from the ARIN address blocks: 110113 Unique aggregates announced from the ARIN address blocks: 44882 ARIN Region origin ASes present in the Internet Routing Table: 14196 ARIN Prefixes per ASN: 7.76 ARIN Region origin ASes announcing only one prefix: 5420 ARIN Region transit ASes present in the Internet Routing Table: 1476 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 23 Number of ARIN addresses announced to Internet: 786454144 Equivalent to 46 /8s, 224 /16s and 86 /24s Percentage of available ARIN address space announced: 62.5 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 81886 Total RIPE prefixes after maximum aggregation: 46434 RIPE Deaggregation factor: 1.76 Prefixes being announced from the RIPE address blocks: 75207 Unique aggregates announced from the RIPE address blocks: 48805 RIPE Region origin ASes present in the Internet Routing Table: 15293 RIPE Prefixes per ASN: 4.92 RIPE Region origin ASes announcing only one prefix: 7772 RIPE Region transit ASes present in the Internet Routing Table: 2377 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 30 Number of RIPE addresses announced to Internet: 459033920 Equivalent to 27 /8s, 92 /16s and 77 /24s Percentage of available RIPE address space announced: 73.9 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 31630 Total LACNIC prefixes after maximum aggregation: 7330 LACNIC Deaggregation factor: 4.32 Prefixes being announced from the LACNIC address blocks: 30383 Unique aggregates announced from the LACNIC address blocks: 15919 LACNIC Region origin ASes present in the Internet Routing Table: 1430 LACNIC Prefixes per ASN: 21.25 LACNIC Region origin ASes announcing only one prefix: 434 LACNIC Region transit ASes present in the Internet Routing Table: 258 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 19 Number of LACNIC addresses announced to Internet: 80671104 Equivalent to 4 /8s, 206 /16s and 241 /24s Percentage of available LACNIC address space announced: 53.4 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 7471 Total AfriNIC prefixes after maximum aggregation: 1804 AfriNIC Deaggregation factor: 4.14 Prefixes being announced from the AfriNIC address blocks: 5880 Unique aggregates announced from the AfriNIC address blocks: 1832 AfriNIC Region origin ASes present in the Internet Routing Table: 435 AfriNIC Prefixes per ASN: 13.52 AfriNIC Region origin ASes announcing only one prefix: 131 AfriNIC Region transit ASes present in the Internet Routing Table: 93 Average AfriNIC Region AS path length visible: 5.3 Max AfriNIC Region AS path length visible: 31 Number of AfriNIC addresses announced to Internet: 21855488 Equivalent to 1 /8s, 77 /16s and 125 /24s Percentage of available AfriNIC address space announced: 32.6 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1991 9487 584 Korea Telecom (KIX) 7545 1633 301 84 TPG Internet Pty Ltd 4755 1412 633 161 TATA Communications formerly 17974 1408 467 28 PT TELEKOMUNIKASI INDONESIA 24560 1108 323 181 Bharti Airtel Ltd., Telemedia 4808 1042 2142 294 CNCGROUP IP network: China169 9583 1042 76 487 Sify Limited 17488 952 162 104 Hathway IP Over Cable Interne 18101 929 117 144 Reliance Infocom Ltd Internet 9829 898 763 42 BSNL National Internet Backbo Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3704 3855 264 bellsouth.net, inc. 4323 2625 1109 403 Time Warner Telecom 19262 1842 4951 283 Verizon Global Networks 1785 1786 697 131 PaeTec Communications, Inc. 20115 1529 1534 646 Charter Communications 6478 1500 296 62 AT&T Worldnet Services 7018 1353 6673 870 AT&T WorldNet Services 2386 1299 553 936 AT&T Data Communications Serv 11492 1282 236 73 Cable One 18566 1282 311 104 Covad Communications Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6830 511 1764 316 UPC Distribution Services 9198 465 266 14 Kazakhtelecom Data Network Ad 34984 456 97 137 BILISIM TELEKOM 3292 445 1996 387 TDC Tele Danmark 8866 440 133 23 Bulgarian Telecommunication C 3320 406 7620 355 Deutsche Telekom AG 8551 403 353 46 Bezeq International 20940 401 93 308 Akamai Technologies European 702 395 1800 308 UUNET - Commercial IP service 3301 383 1822 341 TeliaNet Sweden Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1371 255 165 TVCABLE BOGOTA 8151 1342 2663 359 UniNet S.A. de C.V. 28573 1237 961 82 NET Servicos de Comunicao S.A 6503 1189 355 78 AVANTEL, S.A. 7303 872 445 142 Telecom Argentina Stet-France 14420 638 57 92 CORPORACION NACIONAL DE TELEC 22047 543 310 15 VTR PUNTO NET S.A. 3816 503 220 94 Empresa Nacional de Telecomun 7738 478 922 30 Telecomunicacoes da Bahia S.A 27947 458 53 53 Telconet S.A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 771 445 11 TEDATA 24863 763 147 39 LINKdotNET AS number 36992 584 305 17 Etisalat MISR 3741 264 987 226 The Internet Solution 15475 220 56 9 Nile Online 24835 218 78 10 RAYA Telecom - Egypt 6713 205 199 12 Itissalat Al-MAGHRIB 33776 194 12 15 Starcomms Nigeria Limited 29571 193 19 11 Ci Telecom Autonomous system 16637 147 422 83 MTN Network Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3704 3855 264 bellsouth.net, inc. 4323 2625 1109 403 Time Warner Telecom 4766 1991 9487 584 Korea Telecom (KIX) 19262 1842 4951 283 Verizon Global Networks 1785 1786 697 131 PaeTec Communications, Inc. 7545 1633 301 84 TPG Internet Pty Ltd 20115 1529 1534 646 Charter Communications 6478 1500 296 62 AT&T Worldnet Services 4755 1412 633 161 TATA Communications formerly 17974 1408 467 28 PT TELEKOMUNIKASI INDONESIA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 2625 2222 Time Warner Telecom 1785 1786 1655 PaeTec Communications, Inc. 19262 1842 1559 Verizon Global Networks 7545 1633 1549 TPG Internet Pty Ltd 6478 1500 1438 AT&T Worldnet Services 4766 1991 1407 Korea Telecom (KIX) 17974 1408 1380 PT TELEKOMUNIKASI INDONESIA 4755 1412 1251 TATA Communications formerly 11492 1282 1209 Cable One 10620 1371 1206 TVCABLE BOGOTA Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.0.0.0/16 12654 RIPE NCC RIS Project 5.1.0.0/21 12654 RIPE NCC RIS Project 5.1.24.0/24 12654 RIPE NCC RIS Project 24.129.192.0/19 7922 Continental Cablevision 31.28.0.0/19 29076 Hoster.RU autonomous system 37.0.0.0/16 12654 RIPE NCC RIS Project 37.1.0.0/21 12654 RIPE NCC RIS Project 37.1.24.0/24 12654 RIPE NCC RIS Project 39.0.0.0/8 237 Merit Network 41.57.192.0/18 22750 BCSNET Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:21 /9:10 /10:26 /11:71 /12:215 /13:444 /14:764 /15:1364 /16:11492 /17:5636 /18:9315 /19:18823 /20:24344 /21:24767 /22:32958 /23:31632 /24:181055 /25:986 /26:1087 /27:570 /28:171 /29:16 /30:3 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2283 3704 bellsouth.net, inc. 6478 1454 1500 AT&T Worldnet Services 4323 1414 2625 Time Warner Telecom 10620 1262 1371 TVCABLE BOGOTA 18566 1260 1282 Covad Communications 11492 1239 1282 Cable One 7011 1062 1165 Citizens Utilities 1785 1055 1786 PaeTec Communications, Inc. 6503 966 1189 AVANTEL, S.A. 19262 954 1842 Verizon Global Networks Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:177 2:45 4:13 5:1 8:331 12:2028 13:1 14:412 15:15 16:3 17:8 20:9 23:1 24:1480 27:579 32:61 33:5 34:2 37:1 38:701 40:101 41:2285 44:3 46:585 47:5 49:145 50:82 52:12 55:7 56:2 57:32 58:868 59:477 60:391 61:1114 62:1095 63:1944 64:3781 65:2363 66:4163 67:1761 68:1025 69:2914 70:739 71:400 72:2006 73:1 74:2324 75:292 76:345 77:864 78:705 79:444 80:1048 81:824 82:538 83:471 84:645 85:1052 86:553 87:740 88:355 89:1574 90:156 91:3462 92:494 93:1040 94:1200 95:754 96:428 97:251 98:792 99:33 101:27 107:3 108:88 109:955 110:471 111:695 112:311 113:360 114:502 115:640 116:934 117:679 118:668 119:1021 120:239 121:702 122:1634 123:1061 124:1270 125:1225 128:264 129:153 130:172 131:570 132:109 133:20 134:217 135:49 136:216 137:147 138:291 139:117 140:492 141:196 142:358 143:387 144:483 145:51 146:431 147:202 148:635 149:274 150:161 151:229 152:306 153:179 154:3 155:350 156:176 157:342 158:129 159:380 160:314 161:205 162:272 163:161 164:486 165:339 166:498 167:422 168:742 169:151 170:750 171:69 172:2 173:1289 174:519 175:315 176:1 177:4 178:758 180:796 182:350 183:240 184:209 186:988 187:809 188:908 189:1044 190:4340 192:5797 193:4799 194:3504 195:2955 196:1177 197:3 198:3576 199:3829 200:5573 201:1580 202:8272 203:8432 204:4115 205:2337 206:2631 207:3081 208:3899 209:3496 210:2650 211:1334 212:1886 213:1731 214:756 215:62 216:4885 217:1612 218:532 219:376 220:1203 221:449 222:313 223:97 End of report From owen at delong.com Fri Feb 11 13:49:43 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 11 Feb 2011 11:49:43 -0800 Subject: Looking for an IPv6 naysayer... In-Reply-To: <4D5549CA.2080409@ispalliance.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> <833804CE-80D9-4CED-8672-CF0870317E8C@delong.com><4D531B52.70404@ispalliance.net> <20110210002231.23F0E9DCFDD@drugs.dv.isc.org> <4D53FD00.40900@ispalliance.net> <20110210224123.539B09E32CF@drugs.dv.isc.org> <4D5549CA.2080409@ispalliance.net> Message-ID: <67D897E2-EA22-450C-96DB-0D2256433439@delong.com> On Feb 11, 2011, at 6:38 AM, Scott Helms wrote: > >> ISPs know it takes years to move a customer base. They should have >> been ready years ago. They still arn't ready. I was asking for >> what features to look for in a new CPE so that it won't need to be >> replaced when they turn on IPv6 and got this as a answer. It really >> isn't helpful. > Mark, > > I certainly wasn't trying to be flip or short and for that I apologize. To answer the specific question on a CPE that depends both on what kind of access network you're connecting to as well as if its a service provider installed/supported device or one that a technical end user can support him/herself as those are very different use cases. > > The point I am trying to communicate is that CPE issue not simple, straightforward, or cheap because in almost all of the non-DOCSIS cases we're looking at forklift upgrades. > Yes, but, let's look at why that is... The Broadband Forum sat on its ass and ignored IPv6. They failed to publish IPv6 standards until November of last year. This delayed the implementations in PON and DSL systems. DOCSIS required forklift upgrades, too. The difference is that Cable Labs got out in front of the issue and IPv6 was one of many features that required an upgrade to DOCSIS 3. It's not like Broadband Forum didn't have this option. Sorry... I have little sympathy on that one. Owen From owen at delong.com Fri Feb 11 13:56:38 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 11 Feb 2011 11:56:38 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <4D554F29.8070903@ispalliance.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com><245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com><8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> <4D554F29.8070903@ispalliance.net> Message-ID: <116E791B-4F77-47C8-9A3A-0C8034FAD95C@delong.com> On Feb 11, 2011, at 7:00 AM, Scott Helms wrote: > >> I don't know about that. Yes, v4 will be around for a long time but >> considering the oligopolies we have in both eyeball and content >> networks, ones a dozen or so very large networks switch, there is the >> vast majority of Internet traffic right there. It will be around for a >> very long time handling a tiny bit of traffic. >> > Agreed, V4 traffic levels are likely to drop and stay at low levels for decades. I don't think it will be just a drop in traffic levels. I think that it will not be long before the internet is an IPv6 ocean with islands of IPv4, much like it was an ocean of IPv4 with islands of IPv6 years ago. >> Facebook alone accounts for 25% of internet traffic in the US. Netflix >> is estimated to be over 20% and YouTube at 10%. So that's 55% of >> Internet traffic right there. At the other end of the transaction you >> have AT&T with 15.7 million, Comcast at 15.9 million, Verizon at 9.2 >> million and Time Warner at 8.9 million (early 2010 numbers). That's 50 >> million of the estimated 83 million US broadband subscribers. So once >> three content providers and four subscriber nets switch, that is over >> 25% of US internet traffic on v6 (more than half the users and more than >> half the content they look at). > Comcast, nor the other large MSOs, are not as monolithic as they may appear from the outside. In most cases the large MSOs are divided into regions that are more or less autonomous and that doesn't count the outlier properties that haven't been brought into the fold of the region they are in for various, usually cost related, reasons so don't expect a large block of any of those guys to suddenly be at 60% of their users can get IPv6 addresses. > I think you'll be in for a surprise here. > While Facebook working over IPv6 will be a big deal you won't get all of their traffic since a significant fraction of that traffic is from mobile devices which are going to take much longer than PCs to get to using IPv6 in large numbers. Also, Netflix is even more problematic since the bulk of their traffic, and the fastest growing segment as well, is coming from Xboxes, Tivos, other gaming consoles, and TVs with enough embedded brains to talk directly. Those devices will also seriously lag behind PCs in IPv6 support. > I think you'll be in for a surprise here, too. The 4G transition is already underway. For the vendors where 4G means LTE, IPv6 is the native protocol and IPv4 requires a certain amount of hackery to operate. In the WiMax case (Gee, thanks, SPRINT), things are a bit murkier, but, I think you will see WiMax go IPv6 pretty quickly as well. Yes, it will take a little longer to retire the 3G system(s) than many other parts of the internet, but, I think you will see most of it going away in the 5-7 year range. >> I don't think the growth of v6 traffic is going to be gradual, I think >> it will increase in steps. You will wake up one morning to find your >> v6 traffic doubled and some other morning it will double again. > > They'll be jumps, but they will be fairly smallish jumps since both the content maker, the ISP, and the device consuming the content all have to be ready. Since I don't imagine we will see any pure IPv6 deployments any time soon many/most of the IPv6 deploys will be dual stack and so we are still at the mercy of the AAAA record returning before the A record does. You misunderstand how getaddrinfo() works under the hood. The code itself first does an AAAA lookup and then does an A lookup. DNS does not return both record sets at once. If there is an AAAA record, it will return first. Some OS have modified things to resort the getaddrinfo() returns based on the perceived type of IPv6 and IPv4 connectivity available as an attempt to reduce certain forms of brokenness. However, even in those cases, you should get the AAAA first if you have real IPv6 connectivity. Owen > From cb.list6 at gmail.com Fri Feb 11 14:17:40 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Fri, 11 Feb 2011 12:17:40 -0800 Subject: Looking for an IPv6 naysayer... In-Reply-To: <67D897E2-EA22-450C-96DB-0D2256433439@delong.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> <833804CE-80D9-4CED-8672-CF0870317E8C@delong.com> <4D531B52.70404@ispalliance.net> <20110210002231.23F0E9DCFDD@drugs.dv.isc.org> <4D53FD00.40900@ispalliance.net> <20110210224123.539B09E32CF@drugs.dv.isc.org> <4D5549CA.2080409@ispalliance.net> <67D897E2-EA22-450C-96DB-0D2256433439@delong.com> Message-ID: On Fri, Feb 11, 2011 at 11:49 AM, Owen DeLong wrote: > > On Feb 11, 2011, at 6:38 AM, Scott Helms wrote: > >> >>> ISPs know it takes years to move a customer base. ?They should have >>> been ready years ago. ?They still arn't ready. ?I was asking for >>> what features to look for in a new CPE so that it won't need to be >>> replaced when they turn on IPv6 and got this as a answer. ?It really >>> isn't helpful. >> Mark, >> >> ? ?I certainly wasn't trying to be flip or short and for that I apologize. ?To answer the specific question on a CPE that depends both on what kind of access network you're connecting to as well as if its a service provider installed/supported device or one that a technical end user can support him/herself as those are very different use cases. >> >> The point I am trying to communicate is that CPE issue not simple, straightforward, or cheap because in almost all of the non-DOCSIS cases we're looking at forklift upgrades. >> > Yes, but, let's look at why that is... > > The Broadband Forum sat on its ass and ignored IPv6. They failed to publish IPv6 standards > until November of last year. > > This delayed the implementations in PON and DSL systems. > > DOCSIS required forklift upgrades, too. The difference is that Cable Labs got out in front of the > issue and IPv6 was one of many features that required an upgrade to DOCSIS 3. > > It's not like Broadband Forum didn't have this option. > > Sorry... I have little sympathy on that one. 3GPP was in front of it too, IPv6 was accounted for 10 years ago... but IPv6 3G will require new handsets for all (excluding Nokia, in some cases) due to the OEMs. For us in mobile, the issue right now is largely one of handset availability. Now that Nokia is married to Windows Phone 7, i am concerned they are taking a step backwards since Windows Phone 7 does not support cellular IPv6. Cameron ++++++++ http://groups.google.com/group/tmoipv6beta ++++++++ From franck at genius.com Fri Feb 11 14:21:35 2011 From: franck at genius.com (Franck Martin) Date: Sat, 12 Feb 2011 09:21:35 +1300 (FJST) Subject: IPv6 is on the marketers radar Message-ID: <33020353.1007.1297454809458.JavaMail.franck@franck-martins-macbook-pro.local> http://www.marketingvox.com/under-the-microscope-what-the-end-of-ipv4-means-for-marketers-048657/ I can hear people, say oh no.... Interesting to see that marketers do not like CGNAT. From khelms at ispalliance.net Fri Feb 11 14:29:35 2011 From: khelms at ispalliance.net (Scott Helms) Date: Fri, 11 Feb 2011 15:29:35 -0500 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <116E791B-4F77-47C8-9A3A-0C8034FAD95C@delong.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com><245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com><8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> <4D554F29.8070903@ispalliance.net> <116E791B-4F77-47C8-9A3A-0C8034FAD95C@delong.com> Message-ID: <4D559C2F.5000006@ispalliance.net> >> Comcast, nor the other large MSOs, are not as monolithic as they may appear from the outside. In most cases the large MSOs are divided into regions that are more or less autonomous and that doesn't count the outlier properties that haven't been brought into the fold of the region they are in for various, usually cost related, reasons so don't expect a large block of any of those guys to suddenly be at 60% of their users can get IPv6 addresses. >> > I think you'll be in for a surprise here. We'll see, I have reasons to be (deeply) skeptical, but I hope you're right. Care to speculate on a time frame for when we might get a pleasant surprise? >> While Facebook working over IPv6 will be a big deal you won't get all of their traffic since a significant fraction of that traffic is from mobile devices which are going to take much longer than PCs to get to using IPv6 in large numbers. Also, Netflix is even more problematic since the bulk of their traffic, and the fastest growing segment as well, is coming from Xboxes, Tivos, other gaming consoles, and TVs with enough embedded brains to talk directly. Those devices will also seriously lag behind PCs in IPv6 support. >> > I think you'll be in for a surprise here, too. The 4G transition is already underway. For the vendors where 4G means LTE, IPv6 is the native protocol and IPv4 requires a certain amount of hackery to operate. LTE won't be "real" for the vast majority of subs until the they have an LTE handset, which won't happen until they replace their existing 3G phone. That won't happen unless Verizon and AT&T decide to suddenly give people upgrade credits before their contract would allow. What's worse the whole LTE isn't really 4G and will be replaced by LTE+ makes this worse. If you're a phone maker you're likely trying to decide if you've gone to far to delay your product launch or if you can wait for LTE+ chipsets before releasing your new phone. > In the WiMax case (Gee, thanks, SPRINT), things are a bit murkier, but, I think you will see WiMax go IPv6 pretty quickly as well. > > Yes, it will take a little longer to retire the 3G system(s) than many other parts of the internet, but, I think you will see most of it going away in the 5-7 year range. 3G will be around in substantial amounts for at least 10 years outside of the top 20 metro markets. > You misunderstand how getaddrinfo() works under the hood. The code itself first does an AAAA lookup and then does an A lookup. DNS does not return both record sets at once. If there is an AAAA record, it will return first. > > Some OS have modified things to resort the getaddrinfo() returns based on the perceived type of IPv6 and IPv4 connectivity available as an attempt to reduce certain forms of brokenness. However, even in those cases, you should get the AAAA first if you have real IPv6 connectivity. I haven't looked at the code so that it is entirely possible, but I am more concerned with what the content providers do. Does MS implement the POSIX function? I don't know, but if not whatever Win(XP-7) does is much more important to traffic than what all of the BSD and Linux variants do. Right now you can have a completely working dual stack set up and if your ISP's name server isn't on Google's (and a host of others) white list you'll never get the AAAA record no matter what order your client resolver code asks for the addresses in. http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 http://arstechnica.com/web/news/2010/03/yahoo-wants-two-faced-dns-to-aid-ipv6-deployment.ars The point here is that there are multiple hoops that have to navigated and if any one of them is missed the client will work over v4 and that will keep the ramp up of v6 traffic modest for a long time to come. BTW, I don't want to be right here but I know intimately how ISPs, CPE vendors, and customers behave. > > -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From cb.list6 at gmail.com Fri Feb 11 14:29:51 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Fri, 11 Feb 2011 12:29:51 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <116E791B-4F77-47C8-9A3A-0C8034FAD95C@delong.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> <4D554F29.8070903@ispalliance.net> <116E791B-4F77-47C8-9A3A-0C8034FAD95C@delong.com> Message-ID: On Fri, Feb 11, 2011 at 11:56 AM, Owen DeLong wrote: > > On Feb 11, 2011, at 7:00 AM, Scott Helms wrote: > >> >>> I don't know about that. ?Yes, v4 will be around for a long time but >>> considering the oligopolies we have in both eyeball and content >>> networks, ones a dozen or so very large networks switch, there is the >>> vast majority of Internet traffic right there. ?It will be around for a >>> very long time handling a tiny bit of traffic. >>> >> Agreed, V4 traffic levels are likely to drop and stay at low levels for decades. > > I don't think it will be just a drop in traffic levels. I think that it will not be long > before the internet is an IPv6 ocean with islands of IPv4, much like it was > an ocean of IPv4 with islands of IPv6 years ago. > >>> Facebook alone accounts for 25% of internet traffic in the US. Netflix >>> is estimated to be over 20% and YouTube at 10%. ?So that's 55% of >>> Internet traffic right there. ?At the other end of the transaction you >>> have AT&T with 15.7 million, Comcast at 15.9 million, Verizon at 9.2 >>> million and Time Warner at 8.9 million (early 2010 numbers). ?That's 50 >>> million of the estimated 83 million US broadband subscribers. ?So once >>> three content providers and four subscriber nets switch, that is over >>> 25% of US internet traffic on v6 (more than half the users and more than >>> half the content they look at). >> Comcast, nor the other large MSOs, are not as monolithic as they may appear from the outside. ?In most cases the large MSOs are divided into regions that are more or less autonomous and that doesn't count the outlier properties that haven't been brought into the fold of the region they are in for various, usually cost related, reasons so don't expect a large block of any of those guys to suddenly be at 60% of their users can get IPv6 addresses. >> > I think you'll be in for a surprise here. > >> While Facebook working over IPv6 will be a big deal you won't get all of their traffic since a significant fraction of that traffic is from mobile devices which are going to take much longer than PCs to get to using IPv6 in large numbers. ?Also, Netflix is even more problematic since the bulk of their traffic, and the fastest growing segment as well, is coming from Xboxes, Tivos, other gaming consoles, and ?TVs with enough embedded brains to talk directly. ?Those devices will also seriously lag behind PCs in IPv6 support. >> > I think you'll be in for a surprise here, too. The 4G transition is already underway. For the vendors where 4G means LTE, IPv6 is the native protocol and IPv4 requires a certain amount of hackery to operate. > > In the WiMax case (Gee, thanks, SPRINT), things are a bit murkier, but, I think you will see WiMax go IPv6 pretty quickly as well. > > Yes, it will take a little longer to retire the 3G system(s) than many other parts of the internet, but, I think you will see most of it going away in the 5-7 year range. > This is not quite the case. 2G / 3G / 4G largely refers to radio interface aspects, and the packet core that moves IP packets is largely the same. I have a 5 year old 2G/GSM Nokia phone that support IPv6 over cellular just fine on my network today. There are several LTE deployments around the world that are IPv4 only. There is no hackery require to make IPv4 work in LTE. LTE supports IPv4, IPv6, and IPv4v6 bearers all the same... its just an option from the core perspective, handset / chipset makers like to limit the options to keep cost and variability down. The pressure needs to be applied to the handset makers, they are squarely the "long pole in the tent" here. Cameron ====== http://groups.google.com/group/tmoipv6beta ====== >>> I don't think the growth of v6 traffic is going to be gradual, I think >>> it will increase in steps. ? You will wake up one morning to find your >>> v6 traffic doubled and some other morning it will double again. >> >> They'll be jumps, but they will be fairly smallish jumps since both the content maker, the ISP, and the device consuming the content all have to be ready. ?Since I don't imagine we will see any pure IPv6 deployments any time soon many/most of the IPv6 deploys will be dual stack and so we are still at the mercy of the AAAA record returning before the A record does. > > You misunderstand how getaddrinfo() works under the hood. The code itself first does an AAAA lookup and then does an A lookup. DNS does not return both record sets at once. If there is an AAAA record, it will return first. > > Some OS have modified things to resort the getaddrinfo() returns based on the perceived type of IPv6 and IPv4 connectivity available as an attempt to reduce certain forms of brokenness. However, even in those cases, you should get the AAAA first if you have real IPv6 connectivity. > > Owen >> > > > From JMacleod at alentus.com Fri Feb 11 14:41:05 2011 From: JMacleod at alentus.com (John Macleod) Date: Fri, 11 Feb 2011 13:41:05 -0700 Subject: SmartNet Alternatives Message-ID: <060EDFC2221B014B9504AC06B747F58A499BCC3B57@ex01.alentus.lan> Just interested in other peoples experience to companies offering alternatives to SmartNet? Pros/Cons/Tradeoffs? We currently have a mix of SmartNet and internal parts supply. John __ John Macleod Alentus UK Limited Seymour House South Street Bromley BR1 1RH +44 (0)208 315 5800 +44 (0)208 315 5801 fax alentus.co.uk | alentus.com "Please consider the environment before printing this e-mail This e-mail (and/or any attachment) contains information, which is confidential and intended solely for the attention and use of the named addressee(s). If you are not the intended recipient you must not copy, distribute or use it for any purpose or disclose the contents to any person. If you have received this e-mail in error, please immediately notify the sender. The information contained in this e-mail (and any attachments) is supplied in good faith, but the sender shall not be under any liability in damages or otherwise for any reliance that may be placed upon it by the recipient, nor does it constitute a contract in any way. Any comments or opinions expressed are those of the originator not of Alentus Corporation unless otherwise expressly stated." From fred at cisco.com Fri Feb 11 14:43:56 2011 From: fred at cisco.com (Fred Baker) Date: Fri, 11 Feb 2011 12:43:56 -0800 Subject: IPv6 is on the marketers radar In-Reply-To: <33020353.1007.1297454809458.JavaMail.franck@franck-martins-macbook-pro.local> References: <33020353.1007.1297454809458.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On Feb 11, 2011, at 12:21 PM, Franck Martin wrote: > http://www.marketingvox.com/under-the-microscope-what-the-end-of-ipv4-means-for-marketers-048657/ > > I can hear people, say oh no.... > > Interesting to see that marketers do not like CGNAT. They missed an important point. > Who Will Be Impacted: For more consumers, there will be negligible impact. "The ISPs will be handling much of this,? said Leo Vegoda, a researcher with ICANN. (via TechNewsWorld). Some technology users may experience some glitches, such as people using VPN software to connect with their offices or users of point-to-point software such as Skype, he adds. Anyone that uses a residential router (Linksys, D-Link, Netgear, etc) is likely to need to upgrade that, most likely by buying a new one. Set-top boxes are generally IPv4; anyone with a TV is likely to need to upgrade at least the software. Skype is not yet IPv6-capable, and will need one an update. "The ISPs will take care of this" is a really empty hope. The ISPs will take care of their part, but users should expect that there will be things jiggling over the coming couple of years. From jdfalk-lists at cybernothing.org Fri Feb 11 14:46:25 2011 From: jdfalk-lists at cybernothing.org (J.D. Falk) Date: Fri, 11 Feb 2011 12:46:25 -0800 Subject: IPv6 is on the marketers radar In-Reply-To: <33020353.1007.1297454809458.JavaMail.franck@franck-martins-macbook-pro.local> References: <33020353.1007.1297454809458.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4C98E9AF-6611-4F7D-885C-E259DC90B425@cybernothing.org> On Feb 11, 2011, at 12:21 PM, Franck Martin wrote: > http://www.marketingvox.com/under-the-microscope-what-the-end-of-ipv4-means-for-marketers-048657/ > > I can hear people, say oh no.... > > Interesting to see that marketers do not like CGNAT. Hmm, I recognize a lot of that article. If imitation is the sincerest form of flattery, what's heavy quoting and paraphrasing? http://www.returnpath.net/blog/received/2011/02/end-of-ipv4/ (I don't mind, really -- the word needs to get out, and marketers always resist technology unless there's either guaranteed ROI or guaranteed FUD.) -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From franck at genius.com Fri Feb 11 14:48:56 2011 From: franck at genius.com (Franck Martin) Date: Sat, 12 Feb 2011 09:48:56 +1300 (FJST) Subject: IPv6 is on the marketers radar In-Reply-To: Message-ID: <14962827.9.1297457334197.JavaMail.franck@franck-martins-macbook-pro.local> ----- Original Message ----- > From: "Fred Baker" > To: "Franck Martin" > Cc: nanog at nanog.org > Sent: Saturday, 12 February, 2011 9:43:56 AM > Subject: Re: IPv6 is on the marketers radar > On Feb 11, 2011, at 12:21 PM, Franck Martin wrote: > > > http://www.marketingvox.com/under-the-microscope-what-the-end-of-ipv4-means-for-marketers-048657/ > > > > I can hear people, say oh no.... > > > > Interesting to see that marketers do not like CGNAT. > > They missed an important point. > > > Who Will Be Impacted: For more consumers, there will be negligible > > impact. "The ISPs will be handling much of this,? said Leo Vegoda, a > > researcher with ICANN. (via TechNewsWorld). Some technology users > > may experience some glitches, such as people using VPN software to > > connect with their offices or users of point-to-point software such > > as Skype, he adds. > > Anyone that uses a residential router (Linksys, D-Link, Netgear, etc) > is likely to need to upgrade that, most likely by buying a new one. Speaking of which: http://www.networkworld.com/news/2011/020811-cisco-linksys-ipv6.html ;) From owen at delong.com Fri Feb 11 15:00:35 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 11 Feb 2011 13:00:35 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> <4D554F29.8070903@ispalliance.net> <116E791B-4F77-47C8-9A3A-0C8034FAD95C@delong.com> Message-ID: >>> >> I think you'll be in for a surprise here, too. The 4G transition is already underway. For the vendors where 4G means LTE, IPv6 is the native protocol and IPv4 requires a certain amount of hackery to operate. >> >> In the WiMax case (Gee, thanks, SPRINT), things are a bit murkier, but, I think you will see WiMax go IPv6 pretty quickly as well. >> >> Yes, it will take a little longer to retire the 3G system(s) than many other parts of the internet, but, I think you will see most of it going away in the 5-7 year range. >> > > This is not quite the case. 2G / 3G / 4G largely refers to radio > interface aspects, and the packet core that moves IP packets is > largely the same. I have a 5 year old 2G/GSM Nokia phone that support > IPv6 over cellular just fine on my network today. > Sure, there are some 3G systems that support IPv6, but, most carriers will probably roll IPv6 out as part of their 4G upgrade from what I have seen. > There are several LTE deployments around the world that are IPv4 only. > I think if you look under the hood, they may only provide internet routing for IPv4, but, I don't think they are IPv4 only across the radio. > There is no hackery require to make IPv4 work in LTE. LTE supports > IPv4, IPv6, and IPv4v6 bearers all the same... its just an option from > the core perspective, handset / chipset makers like to limit the > options to keep cost and variability down. > My understanding (admittedly second hand, so perhaps the engineer explaining it to me was mistaken) was that LTE was IPv6 and that IPv4 was implemented on the radio side essentially as a 4in6 tunnel with a very very short-term DHCP lease for the v4 address. > The pressure needs to be applied to the handset makers, they are > squarely the "long pole in the tent" here. > Yep. In the US, at least, the carriers have an unfortunately large ability to do that. In this case, it will prove helpful. In most cases, it has proven to be rather strongly contrary to the consumer's best interests. Owen From mloftis at wgops.com Fri Feb 11 15:26:56 2011 From: mloftis at wgops.com (Michael Loftis) Date: Fri, 11 Feb 2011 14:26:56 -0700 Subject: SmartNet Alternatives In-Reply-To: <060EDFC2221B014B9504AC06B747F58A499BCC3B57@ex01.alentus.lan> References: <060EDFC2221B014B9504AC06B747F58A499BCC3B57@ex01.alentus.lan> Message-ID: Cisco is making noises that they'll eventually be restricting software access to ONLY those devices which have an active SmartNet contract associated to your CCO account. I don't know where this currently stands, and it sure will be a huge pain in my rear if/when it happens. On Fri, Feb 11, 2011 at 1:41 PM, John Macleod wrote: > Just interested in other peoples experience to companies offering alternatives to SmartNet? > > Pros/Cons/Tradeoffs? > > We currently have a mix of SmartNet and internal parts supply. > > John > > > __ > John Macleod > Alentus UK Limited > Seymour House > South Street > Bromley > BR1 1RH > ?+44 (0)208 315 5800 > ?+44 (0)208 315 5801 fax > alentus.co.uk ?| ?alentus.com > > "Please consider the environment before printing this e-mail > > This e-mail (and/or any attachment) contains information, which is confidential and intended solely for the attention and use of the named addressee(s). If you are not the intended recipient you must not copy, distribute or use it for any purpose or disclose the contents to any person. If you have received this e-mail in error, please immediately notify the sender. The information contained in this e-mail (and any attachments) is supplied in good faith, but the sender shall not be under any liability in damages or otherwise for any reliance that may be placed upon it by the recipient, nor does it constitute a contract in any way. Any comments or opinions expressed are those of the originator not of Alentus Corporation unless otherwise expressly stated." > > From gbonser at seven.com Fri Feb 11 15:31:42 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 11 Feb 2011 13:31:42 -0800 Subject: IPv6 is on the marketers radar In-Reply-To: <14962827.9.1297457334197.JavaMail.franck@franck-martins-macbook-pro.local> References: <14962827.9.1297457334197.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13A58@RWC-EX1.corp.seven.com> > > They missed an important point. > > > > > Who Will Be Impacted: For more consumers, there will be negligible > > > impact. "The ISPs will be handling much of this,? said Leo Vegoda, > a > > > researcher with ICANN. (via TechNewsWorld). Some technology users > > > may experience some glitches, such as people using VPN software to > > > connect with their offices or users of point-to-point software such > > > as Skype, he adds. > > > > Anyone that uses a residential router (Linksys, D-Link, Netgear, etc) > > is likely to need to upgrade that, most likely by buying a new one. > > Speaking of which: http://www.networkworld.com/news/2011/020811-cisco- > linksys-ipv6.html > > ;) Key quote in that article from Cisco explains why they are still behind. "IPv6 is foundational to the next-generation Internet, enabling a range of new services and improved user experiences." Apparently they see IPv6 as some "next-generation Internet" thing. It isn't. It is imperative in keeping THIS generation of internet running. This has nothing to do with any new services or improving anyone's experience. This is about maintaining existing services and even being able to have an experience at all. It is going to become increasingly difficult to maintain ubiquitous v4 service. In fact, v6 is going to degrade some people's experience slightly because the larger protocol overhead means less payload for a given size packet meaning it will take more packets to transfer a given amount of data. Apparently some people in this world believe that IPv6 somehow creates a "different" internet. It doesn't. It simply adds more house numbers to the existing streets. From jbates at brightok.net Fri Feb 11 15:36:14 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 11 Feb 2011 15:36:14 -0600 Subject: IPv6 is on the marketers radar In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13A58@RWC-EX1.corp.seven.com> References: <14962827.9.1297457334197.JavaMail.franck@franck-martins-macbook-pro.local> <5A6D953473350C4B9995546AFE9939EE0BC13A58@RWC-EX1.corp.seven.com> Message-ID: <4D55ABCE.7030800@brightok.net> On 2/11/2011 3:31 PM, George Bonser wrote: > "IPv6 is foundational to the next-generation Internet, enabling a > range of new services and improved user experiences." > > Apparently they see IPv6 as some "next-generation Internet" thing. > It isn't. Reread what they wrote. IPv6 is "foundational" to the next-generation Internet. If it's not, then IETF should have added 96 bits and left the rest of it alone. I can't blame Cisco for making sure how they implement the linksys is appropriate for the long term. It's important that they get certain things right, as future improvements of the Internet DO depend on IPv6 being functional. Jack From franck at genius.com Fri Feb 11 15:38:37 2011 From: franck at genius.com (Franck Martin) Date: Sat, 12 Feb 2011 10:38:37 +1300 (FJST) Subject: IPv6 is on the marketers radar In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13A58@RWC-EX1.corp.seven.com> Message-ID: <32197767.16.1297460317131.JavaMail.franck@franck-martins-macbook-pro.local> ----- Original Message ----- > From: "George Bonser" > To: "Franck Martin" , "Fred Baker" > Cc: nanog at nanog.org > Sent: Saturday, 12 February, 2011 10:31:42 AM > Subject: RE: IPv6 is on the marketers radar > > > They missed an important point. > > > > > > > Who Will Be Impacted: For more consumers, there will be > > > > negligible > > > > impact. "The ISPs will be handling much of this,? said Leo > > > > Vegoda, > > a > > > > researcher with ICANN. (via TechNewsWorld). Some technology > > > > users > > > > may experience some glitches, such as people using VPN software > > > > to > > > > connect with their offices or users of point-to-point software > > > > such > > > > as Skype, he adds. > > > > > > Anyone that uses a residential router (Linksys, D-Link, Netgear, > > > etc) > > > is likely to need to upgrade that, most likely by buying a new > > > one. > > > > Speaking of which: > > http://www.networkworld.com/news/2011/020811-cisco- > > linksys-ipv6.html > > > > ;) > > Key quote in that article from Cisco explains why they are still > behind. > > "IPv6 is foundational to the next-generation Internet, enabling a > range of new services and improved user experiences." > > Apparently they see IPv6 as some "next-generation Internet" thing. It > isn't. It is imperative in keeping THIS generation of internet > running. This has nothing to do with any new services or improving > anyone's experience. This is about maintaining existing services and > even being able to have an experience at all. It is going to become > increasingly difficult to maintain ubiquitous v4 service. In fact, v6 > is going to degrade some people's experience slightly because the > larger protocol overhead means less payload for a given size packet > meaning it will take more packets to transfer a given amount of data. > > Apparently some people in this world believe that IPv6 somehow creates > a "different" internet. It doesn't. It simply adds more house numbers > to the existing streets. Thanks to ITU for bringing the Next Generation Network (NGN), which was in fact IPv6+License but then got everyone confused, side tracked, etc... From jfbeam at gmail.com Fri Feb 11 15:41:09 2011 From: jfbeam at gmail.com (Ricky Beam) Date: Fri, 11 Feb 2011 16:41:09 -0500 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13A3E@RWC-EX1.corp.seven.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> <4D554F29.8070903@ispalliance.net> <5A6D953473350C4B9995546AFE9939EE0BC13A3E@RWC-EX1.corp.seven.com> Message-ID: On Fri, 11 Feb 2011 12:20:59 -0500, George Bonser wrote: > The thing is that a very few networks account for a very large amount of > traffic. Traffic has to have two end points. Just because the content source supports IPv6 does not mean the content request will be. That's the "millions of eyeballs" (aka sheep.) You don't seem to grasp the full picture... There are 4 parts to the equation: 1. Content Source 2. Transit network(s) 3. CPE 4. Content Consumer Fixing the source (be it Facebook, Youtube, or netflix) is rather simple in concept -- it's just one network, and doesn't require touching millions of devices. Transit networks are hit-n-miss, but is becoming less of a burden. The CPE on the other hand is a whole other mess... there are thousands (into millions) that will need firmware upgrades or complete replacement to support IPv6. (That's the cablemodems, dsl modem, Uverse RGs, FiOS ONTs, and linksys's and netgears of the world.) And *then* the device that actually wants the content has to have support. (that'd be you roku, blu-ray player, console, laptop, cellphone, picture frame, etc.) > What is the natural "churn" rate for CPE for one of the large MSOs? How often MSO's replace CPE gear? "When it breaks" and "when it's no longer compat" I don't know about your cable company, but TW doesn't replace anything unless it's broken. I've had the same SB5100 for nearly a decade. (they did replace the SB3100/4100's a few years back, but they were no longer compatible with the network.) AT&T DSL also doesn't replace CPE's unless they break. (or you buy a new one.) In bridge mode, any modem will do. It's when the modem is also the router (which is most cases today) that it will need attention to support IPv6. (in bridge mode, you'll have to fix whatever it's plugged into, but that's the customer's problem... off to Best Buy for an IPv6 capable D-Link.) > What portion of the MSOs have v6 capable CPE in place right now... Unknown. I've not known any MSO to publish those numbers. Any sane MSO is handing out D3 modems even if they are still running a D2 network, so new connections (or replacements) should be D3. > you only need about five If you're thinking of five major cable operators, they aren't each "one network" but are a group of franchises/markets running more or less independent of each other. > Yes, and I mentioned that. So once you have >50% of the potential > content sources v6 capable and >50% of the potential eyeballs v6 > capable, you have potentially 25% of internet traffic on v6. And that > can be done with the migration of enough networks to count on your > fingers. Heh. No it can't. You grossly underestimate the work necessary to get the eyeballs v6 capable. If Comcast has to replace as little as 10% of their modems, that'd be over 1mil. That's not going to happen overnight. (or even a month.) --Ricky From wavetossed at googlemail.com Fri Feb 11 15:44:30 2011 From: wavetossed at googlemail.com (Michael Dillon) Date: Fri, 11 Feb 2011 13:44:30 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> Message-ID: > Using public address space for private networking is a gross misuse of the > resource. No it is not. IP was invented to enable internetworking. The IPv4 address registry was set up so that anyone who wanted to use IP for internetworking could get unique addresses. The key here, is internetworking, which refers to exchanging packets with other networks. It is possible to internetwork without ever exchanging packets with the public Internet. > ?Go to any registry and ask for address space for your private > networking that you do not intend to announce to the internet. ?They will > laugh at you, and point you to RFC1918. (and likely flag you as someone to > whom address space should never be assigned.) Not true. Two of my former employers went to ARIN every year or two and received blocks around a /16 in size, specifically for use on global IP networks that did not intend to ever announce those addresses on the Internet. There are several other companies which operate somewhat similar networks. Also, "announce to the Internet" doesn't mean what you think it does. First of all there is no Internet to announce to, only peers, There are a lot of smaller networks which do announce routes to a small number of regional peers, but those routes are NOT transitively announced to the rest of the public Internet. These networks *ARE* connected to the Internet, but you won't see their routes in any of the major views (routeviews, ris, etc) which are considered as the global routing table. >?The only reason legacy > holders get away with such crap is because there's no clear contract > governing their assignment. All of the companies that I am aware of who get RIR addresses with no intention of announcing it on the Internet, are paid up members in good standing of one or more RIRs. Legacy holders really don't play in this game except for the DOD. > First off, someone will have to do a lot more than 5 minutes of poking > router-servers to see just how sparsely used ("announced") the space really > is. ?That includes digging through BGP histories to see if it's ever been > announced. ?Then research who should be in control of the space (announced > or not.) ?Then send out nasty sounding letters informing whomever that X > address space has not been announced to the public internet in Y years; on Z > date, the space will reenter the IANA/ICANN free pool for reassignment. (cue > lawyers :-)) ?They'd also be highly motivated to return unused space if they > were being billing for it. First of all, tools like RIPE's RIS make checking BGP history child's play. Secondly, you left out the court cases where the companies all get injunctions against ARIN because ARIN did regularly give them addresses under ARIN policy and nothing has changed to justify pulling the addresses back. These addresses are in use, i.e. configured in devices that provide a commercial internetworking service with packets flowing 24 hours a day. --Michael Dillon From cb.list6 at gmail.com Fri Feb 11 15:45:56 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Fri, 11 Feb 2011 13:45:56 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> <4D554F29.8070903@ispalliance.net> <116E791B-4F77-47C8-9A3A-0C8034FAD95C@delong.com> Message-ID: On Fri, Feb 11, 2011 at 1:00 PM, Owen DeLong wrote: >>>> >>> I think you'll be in for a surprise here, too. The 4G transition is already underway. For the vendors where 4G means LTE, IPv6 is the native protocol and IPv4 requires a certain amount of hackery to operate. >>> >>> In the WiMax case (Gee, thanks, SPRINT), things are a bit murkier, but, I think you will see WiMax go IPv6 pretty quickly as well. >>> >>> Yes, it will take a little longer to retire the 3G system(s) than many other parts of the internet, but, I think you will see most of it going away in the 5-7 year range. >>> >> >> This is not quite the case. ?2G / 3G / 4G largely refers to radio >> interface aspects, and the packet core that moves IP packets is >> largely the same. ?I have a 5 year old 2G/GSM Nokia phone that support >> IPv6 over cellular just fine on my network today. >> > Sure, there are some 3G systems that support IPv6, but, most carriers will > probably roll IPv6 out as part of their 4G upgrade from what I have seen. > Yep, 4G projects should add IPv6, most people agree about this. >> There are several LTE deployments around the world that are IPv4 only. >> > I think if you look under the hood, they may only provide internet routing > for IPv4, but, I don't think they are IPv4 only across the radio. > Nope. >> There is no hackery require to make IPv4 work in LTE. ?LTE supports >> IPv4, IPv6, and IPv4v6 bearers all the same... its just an option from >> the core perspective, handset / chipset makers like to limit the >> options to keep cost and variability down. >> > My understanding (admittedly second hand, so perhaps the engineer > explaining it to me was mistaken) was that LTE was IPv6 and that IPv4 > was implemented on the radio side essentially as a 4in6 tunnel with a > very very short-term DHCP lease for the v4 address. > > Nope, it does not work this way. There are tunnels for mobility, and it is possible that IPv4 user plane packet get carried in IPv6 GTP packets but that is the same case for IPv6 user plane also being in IPv6 GTP packets.... but LTE generally does not use any DHCP to the user. Key point: LTE does not imply any mandatory IPv6 networks infrastructure or services, but it does work with IPv6 and should be deployed with IPv6. Cameron (who works in mobile, everyday) From Bryan at bryanfields.net Fri Feb 11 15:46:10 2011 From: Bryan at bryanfields.net (Bryan Fields) Date: Fri, 11 Feb 2011 16:46:10 -0500 Subject: SmartNet Alternatives In-Reply-To: References: <060EDFC2221B014B9504AC06B747F58A499BCC3B57@ex01.alentus.lan> Message-ID: <4D55AE22.9010501@bryanfields.net> On 2/11/2011 16:26, Michael Loftis wrote: > Cisco is making noises that they'll eventually be restricting software > access to ONLY those devices which have an active SmartNet contract > associated to your CCO account. I don't know where this currently > stands, and it sure will be a huge pain in my rear if/when it happens. They do this now. Unless the device type is under listed smartnet, you can't download software for it. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From khomyakov.andrey at gmail.com Fri Feb 11 15:49:55 2011 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Fri, 11 Feb 2011 16:49:55 -0500 Subject: SmartNet Alternatives In-Reply-To: <060EDFC2221B014B9504AC06B747F58A499BCC3B57@ex01.alentus.lan> References: <060EDFC2221B014B9504AC06B747F58A499BCC3B57@ex01.alentus.lan> Message-ID: If only Cisco would sell "software only" support. 3rd party smartNet alternatives are nice for parts replacement. They suck for support, imho, especially, when it comes down to declaring a problem to be a bug. On quite a few occasions I found bugs in IOS and TAC submitted those as bugs and fixed them reasonably fast. Andrey On Fri, Feb 11, 2011 at 3:41 PM, John Macleod wrote: > Just interested in other peoples experience to companies offering > alternatives to SmartNet? > > Pros/Cons/Tradeoffs? > > We currently have a mix of SmartNet and internal parts supply. > > John > > > __ > John Macleod > Alentus UK Limited > Seymour House > South Street > Bromley > BR1 1RH > +44 (0)208 315 5800 > +44 (0)208 315 5801 fax > alentus.co.uk | alentus.com > > "Please consider the environment before printing this e-mail > > This e-mail (and/or any attachment) contains information, which is > confidential and intended solely for the attention and use of the named > addressee(s). If you are not the intended recipient you must not copy, > distribute or use it for any purpose or disclose the contents to any person. > If you have received this e-mail in error, please immediately notify the > sender. The information contained in this e-mail (and any attachments) is > supplied in good faith, but the sender shall not be under any liability in > damages or otherwise for any reliance that may be placed upon it by the > recipient, nor does it constitute a contract in any way. Any comments or > opinions expressed are those of the originator not of Alentus Corporation > unless otherwise expressly stated." > > -- Andrey Khomyakov [khomyakov.andrey at gmail.com] From wavetossed at googlemail.com Fri Feb 11 15:56:35 2011 From: wavetossed at googlemail.com (Michael Dillon) Date: Fri, 11 Feb 2011 13:56:35 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> Message-ID: > One example I heard was a generic financial exchange connected to > perhaps a hundred other companies. Those companies also connect to the > Internet but the exchange itself does not. It's valuable for the > exchange to use addressing which will not conflict with any of its > customers' RFC1918 use or overlap any Internet destinations they want > to access. Sounds like SFTI in New York http://www.nyse.com/technologies/sfti/1223635951074.html In turn, SFTI is connected to the Radianz global IP network which allows financial industry companies in other countries to access the NYSE services on SFTI. And the Radianz global IP network has over 15,000 sites connected to it in some 200 countries. Probably all of the companies connected to Radianz also have an Internet connection, but nobody passes packets between Radianz and the Internet. Radianz is an example of a COIN (Community of Interest Network). Outside the Financial Services industry there are similar COINs in the air traffic industry (SITA) and the auto manufacturing industry. If you diagrammed these COINs on a typical Internet diagram, they would be a thin layer, one AS thick, wrapped around some portion of the cloud's perimeter. Invisible to most because they connect but do not exchange transit traffic. Zoom in an look at ASCustomer which peers with three ISP ASnumbers and also peers with ASRadianz. But the traffic from ASRadianz is controlled by firewalls and internal routing in ASCustomer so that it only goes to the trading workstations, while the Internet traffic is allowed pretty much everywhere. You could make various biological analogies such as the specialised layers of human skin cells or the micturating membrane in amphibians. --Michael Dillon From cidr-report at potaroo.net Fri Feb 11 16:00:02 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 11 Feb 2011 22:00:02 GMT Subject: BGP Update Report Message-ID: <201102112200.p1BM021J016097@wattle.apnic.net> BGP Update Report Interval: 03-Feb-11 -to- 10-Feb-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS47331 27931 1.5% 8.6 -- TTNET TTNet A.S. 2 - AS13609 20873 1.1% 80.0 -- ONECOM-C1 - One Communications Corporation 3 - AS32528 18941 1.0% 2367.6 -- ABBOTT Abbot Labs 4 - AS9829 16648 0.9% 18.6 -- BSNL-NIB National Internet Backbone 5 - AS33475 16218 0.9% 75.4 -- RSN-1 - RockSolid Network, Inc. 6 - AS11492 13923 0.7% 10.8 -- CABLEONE - CABLE ONE, INC. 7 - AS35931 12731 0.7% 2121.8 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 8 - AS1785 12694 0.7% 7.1 -- AS-PAETEC-NET - PaeTec Communications, Inc. 9 - AS17974 12356 0.7% 8.9 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 10 - AS9498 11901 0.6% 15.6 -- BBIL-AP BHARTI Airtel Ltd. 11 - AS6389 11640 0.6% 3.1 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 12 - AS6503 11031 0.6% 9.3 -- Axtel, S.A.B. de C.V. 13 - AS72 9930 0.5% 62.5 -- SCHLUMBERGER-AS Schlumberger Limited 14 - AS174 8963 0.5% 4.2 -- COGENT Cogent/PSI 15 - AS7011 8663 0.5% 7.4 -- FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. 16 - AS38714 8330 0.4% 2082.5 -- EVISION-AS-AP E-Vision Internet, 17 - AS14522 8222 0.4% 19.4 -- Satnet 18 - AS22995 8196 0.4% 59.8 -- BARR-XPLR-ASN - Barrett Xplore Inc 19 - AS17224 8087 0.4% 144.4 -- ATT-CERFNET-BLOCK - AT&T Enhanced Network Services 20 - AS9198 8072 0.4% 17.3 -- KAZTELECOM-AS JSC Kazakhtelecom TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS35738 4087 0.2% 4087.0 -- KVANT-AS Kvant ltd. 2 - AS32528 18941 1.0% 2367.6 -- ABBOTT Abbot Labs 3 - AS4829 2326 0.1% 2326.0 -- MYTELECOM-PL-AS-AU-AP My Telecom Holdings Pty. Ltd. 4 - AS49776 2250 0.1% 2250.0 -- GORSET-AS Gorodskaya Set Ltd. 5 - AS35931 12731 0.7% 2121.8 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 6 - AS4858 2099 0.1% 2099.0 -- CORPITA-AS-AP Corpita Pty Ltd 7 - AS38714 8330 0.4% 2082.5 -- EVISION-AS-AP E-Vision Internet, 8 - AS49600 1556 0.1% 1556.0 -- LASEDA La Seda de Barcelona, S.A 9 - AS29477 2430 0.1% 1215.0 -- EASTCOMM-AS East Telecom Autonomous System 10 - AS23681 3417 0.2% 1139.0 -- ITU-TRANSIT-AS-AP Paradox Digital ASN on behalf of IT Universe. To provide BGP interconnects to VIX and Paradox. 11 - AS6401 1011 0.1% 1011.0 -- ALLST-6401 - Allstream Corp. 12 - AS30119 3621 0.2% 905.2 -- 13 - AS34239 898 0.1% 898.0 -- INTERAMERICAN General Insurance Company 14 - AS19743 5325 0.3% 760.7 -- 15 - AS22525 697 0.0% 697.0 -- ATALANTA-SOSNOFF - Atalanta Sosnoff Capital, LLC 16 - AS45600 1300 0.1% 650.0 -- UPM-AS-AP University of the Philippines, Manila 17 - AS24923 6453 0.3% 586.6 -- SETTC South-East Transtelecom Joint Stock Co. 18 - AS27771 1029 0.1% 514.5 -- Instituto Venezolano de Investigaciones Cientificas 19 - AS25992 395 0.0% 395.0 -- PRODUCTION-NETWORK - Vericom Corporation 20 - AS45550 362 0.0% 362.0 -- NGT-AS-VN New Generations Telecommunications Corporation TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 130.36.34.0/24 9462 0.4% AS32528 -- ABBOTT Abbot Labs 2 - 130.36.35.0/24 9462 0.4% AS32528 -- ABBOTT Abbot Labs 3 - 63.211.68.0/22 8334 0.4% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 4 - 202.92.235.0/24 6951 0.3% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 5 - 216.126.136.0/22 6431 0.3% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 6 - 213.129.96.0/19 6405 0.3% AS24923 -- SETTC South-East Transtelecom Joint Stock Co. 7 - 198.140.43.0/24 4312 0.2% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 8 - 80.245.240.0/20 4091 0.2% AS15468 -- KLGELECS-AS ru.klgelecs Local Registry Autonomous System AS35738 -- KVANT-AS Kvant ltd. 9 - 68.65.152.0/22 3644 0.2% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 10 - 95.170.128.0/19 3554 0.2% AS25549 -- AVANTEL-AS JSC Avantel 11 - 202.153.174.0/24 3238 0.1% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 12 - 206.184.16.0/24 3183 0.1% AS174 -- COGENT Cogent/PSI 13 - 93.91.160.0/20 2972 0.1% AS25549 -- AVANTEL-AS JSC Avantel 14 - 192.190.209.0/24 2812 0.1% AS1221 -- ASN-TELSTRA Telstra Pty Ltd 15 - 192.190.214.0/24 2812 0.1% AS1221 -- ASN-TELSTRA Telstra Pty Ltd 16 - 223.206.0.0/16 2756 0.1% AS45629 -- JASTEL-NETWORK-TH-AP Jasmine International Tower AS45758 -- TRIPLETNET-AS-AP TripleT Internet Internet service provider Bangkok 17 - 183.88.0.0/16 2756 0.1% AS45629 -- JASTEL-NETWORK-TH-AP Jasmine International Tower AS45758 -- TRIPLETNET-AS-AP TripleT Internet Internet service provider Bangkok 18 - 203.153.192.0/20 2326 0.1% AS4829 -- MYTELECOM-PL-AS-AU-AP My Telecom Holdings Pty. Ltd. 19 - 202.61.252.0/24 2279 0.1% AS10113 -- DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD AS23681 -- ITU-TRANSIT-AS-AP Paradox Digital ASN on behalf of IT Universe. To provide BGP interconnects to VIX and Paradox. 20 - 202.61.212.0/24 2279 0.1% AS10113 -- DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD AS23681 -- ITU-TRANSIT-AS-AP Paradox Digital ASN on behalf of IT Universe. To provide BGP interconnects to VIX and Paradox. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Feb 11 16:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 11 Feb 2011 22:00:00 GMT Subject: The Cidr Report Message-ID: <201102112200.p1BM00wc016088@wattle.apnic.net> This report has been generated at Fri Feb 11 21:11:54 2011 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 04-02-11 345917 203345 05-02-11 346361 203582 06-02-11 346524 203630 07-02-11 346746 203680 08-02-11 346840 203697 09-02-11 347143 203702 10-02-11 347139 202986 11-02-11 347465 203232 AS Summary 36743 Number of ASes in routing system 15543 Number of ASes announcing only one prefix 3704 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 106679808 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 11Feb11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 347715 203188 144527 41.6% All ASes AS6389 3704 269 3435 92.7% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 2616 408 2208 84.4% TWTC - tw telecom holdings, inc. AS19262 1842 283 1559 84.6% VZGNI-TRANSIT - Verizon Online LLC AS4766 1991 602 1389 69.8% KIXS-AS-KR Korea Telecom AS6478 1500 208 1292 86.1% ATT-INTERNET3 - AT&T Services, Inc. AS22773 1277 87 1190 93.2% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS10620 1371 217 1154 84.2% Telmex Colombia S.A. AS4755 1414 339 1075 76.0% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS1785 1789 763 1026 57.4% AS-PAETEC-NET - PaeTec Communications, Inc. AS28573 1237 299 938 75.8% NET Servicos de Comunicao S.A. AS7545 1635 730 905 55.4% TPG-INTERNET-AP TPG Internet Pty Ltd AS18101 927 154 773 83.4% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS24560 1108 341 767 69.2% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS18566 1282 537 745 58.1% COVAD - Covad Communications Co. AS7303 891 153 738 82.8% Telecom Argentina S.A. AS6503 1190 456 734 61.7% Axtel, S.A.B. de C.V. AS4808 1046 323 723 69.1% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS3356 1188 487 701 59.0% LEVEL3 Level 3 Communications AS8151 1348 672 676 50.1% Uninet S.A. de C.V. AS17488 952 279 673 70.7% HATHWAY-NET-AP Hathway IP Over Cable Internet AS9498 759 121 638 84.1% BBIL-AP BHARTI Airtel Ltd. AS11492 1282 654 628 49.0% CABLEONE - CABLE ONE, INC. AS17676 651 70 581 89.2% GIGAINFRA Softbank BB Corp. AS855 633 58 575 90.8% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS7552 647 107 540 83.5% VIETEL-AS-AP Vietel Corporation AS36992 584 45 539 92.3% ETISALAT-MISR AS4780 763 226 537 70.4% SEEDNET Digital United Inc. AS14420 638 103 535 83.9% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS22047 543 29 514 94.7% VTR BANDA ANCHA S.A. AS3549 876 365 511 58.3% GBLX Global Crossing Ltd. Total 37684 9385 28299 75.1% Top 30 total Possible Bogus Routes 5.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 5.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 5.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 24.129.192.0/19 AS7922 COMCAST-7922 - Comcast Cable Communications, Inc. 37.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 37.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 37.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 39.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 45.127.0.0/16 AS13767 DBANK - DataBank Holdings, Ltd. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.18.224.0/20 AS12129 123NET - 123.Net, Inc. 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 72.22.32.0/19 AS33150 72.22.61.0/24 AS33150 72.22.62.0/24 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 96.45.161.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.162.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.163.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.164.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.165.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.166.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.167.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.168.0/21 AS3257 TINET-BACKBONE Tinet SpA 106.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 110.173.64.0/19 AS37963 CNNIC-ALIBABA-CN-NET-AP Alibaba (China) Technology Co., Ltd. 115.42.28.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.30.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.40.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.42.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.44.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.47.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.48.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.49.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.50.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.51.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.52.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.53.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.54.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.55.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.56.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.57.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.58.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.59.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.61.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.62.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.63.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 116.68.136.0/21 AS28045 Pantel Communications 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.54.160.0/24 AS38890 121.54.161.0/24 AS38890 121.54.162.0/24 AS38890 121.54.163.0/24 AS38890 121.54.164.0/24 AS38890 121.54.166.0/24 AS38890 121.54.167.0/24 AS38890 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 176.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.82.176.224/27 AS45976 CNYGE-AS-KR chungcheongnamdo yeongi office of education 181.82.177.0/26 AS45976 CNYGE-AS-KR chungcheongnamdo yeongi office of education 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.101.46.0/24 AS6503 Axtel, S.A.B. de C.V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.15.4.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.15.5.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.175.231.0/24 AS19262 VZGNI-TRANSIT - Verizon Online LLC 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.91.204.0/22 AS40727 TELENET - TELENET Informatique Inc. 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.24.73.0/24 AS26061 Equant Colombia 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.20.108.0/23 AS17885 JKTXLNET-AS-AP PT Excelcomindo Pratama 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.176.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.146.186.0/24 AS23655 SNAP-NZ-AS Snap Internet Limited 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.130.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.133.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.149.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.150.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.18.156.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.22.78.0/24 AS18117 HARBOURMSP-AU-AP Harbour MSP Pty. Ltd 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.27.123.0/24 AS4739 CIX-ADELAIDE-AS Internode Systems Pty Ltd 203.30.26.0/23 AS3491 BTN-ASN - Beyond The Network America, Inc. 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.10.232.0/21 AS33150 204.19.14.0/23 AS577 BACOM - Bell Canada 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 206.72.192.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.72.194.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.64.200.0/22 AS11730 CIL-ASN - Circle Internet LTD 208.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.73.160.0/24 AS32767 208.78.165.0/24 AS16565 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.89.60.0/22 AS40626 208.92.196.0/22 AS10929 NETELLIGENT - Netelligent Hosting Services Inc. 208.92.199.0/24 AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.10.235.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.10.236.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.238.160.0/20 AS20225 TELJET - TelJet 217.24.128.0/20 AS25144 TELEKOM-SRPSKE-AS Telekom Srpske Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From jbates at brightok.net Fri Feb 11 16:00:49 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 11 Feb 2011 16:00:49 -0600 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> <4D554F29.8070903@ispalliance.net> <5A6D953473350C4B9995546AFE9939EE0BC13A3E@RWC-EX1.corp.seven.com> Message-ID: <4D55B191.9030702@brightok.net> On 2/11/2011 3:41 PM, Ricky Beam wrote: > In bridge mode, any modem will do. It's when the modem is also the > router (which is most cases today) that it will need attention to > support IPv6. (in bridge mode, you'll have to fix whatever it's plugged > into, but that's the customer's problem... off to Best Buy for an IPv6 > capable D-Link.) I just finished discussing with the one telco in my network that deployed PPPoE. All customers will bring their modem into the office, where the front desk ladies will flash the config to bridge mode. It was that or replace thousands of CPE that never will support IPv6 in routed mode. Have a nice day. Jack From paul at paulgraydon.co.uk Fri Feb 11 16:14:04 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Fri, 11 Feb 2011 12:14:04 -1000 Subject: IPv6 is on the marketers radar In-Reply-To: <4C98E9AF-6611-4F7D-885C-E259DC90B425@cybernothing.org> References: <33020353.1007.1297454809458.JavaMail.franck@franck-martins-macbook-pro.local> <4C98E9AF-6611-4F7D-885C-E259DC90B425@cybernothing.org> Message-ID: <4D55B4AC.3000907@paulgraydon.co.uk> On 02/11/2011 10:46 AM, J.D. Falk wrote: > On Feb 11, 2011, at 12:21 PM, Franck Martin wrote: > >> http://www.marketingvox.com/under-the-microscope-what-the-end-of-ipv4-means-for-marketers-048657/ >> >> I can hear people, say oh no.... >> >> Interesting to see that marketers do not like CGNAT. > Hmm, I recognize a lot of that article. If imitation is the sincerest form of flattery, what's heavy quoting and paraphrasing? > > http://www.returnpath.net/blog/received/2011/02/end-of-ipv4/ > > (I don't mind, really -- the word needs to get out, and marketers always resist technology unless there's either guaranteed ROI or guaranteed FUD.) These are Internet marketers you're talking about, hardly the most honest souls in the world ;) Paul p.s. with apologies to any honest marketers. All 2 of you.. From gbonser at seven.com Fri Feb 11 16:21:49 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 11 Feb 2011 14:21:49 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> <4D554F29.8070903@ispalliance.net> <5A6D953473350C4B9995546AFE9939EE0BC13A3E@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13A5A@RWC-EX1.corp.seven.com> > > Fixing the source (be it Facebook, Youtube, or netflix) is rather > simple > in concept -- it's just one network, and doesn't require touching > millions > of devices. Transit networks are hit-n-miss, but is becoming less of a > burden. The CPE on the other hand is a whole other mess... there are > thousands (into millions) that will need firmware upgrades or complete > replacement to support IPv6. I would venture to say that it is likely that most of the CPE deployed over the past couple of years is capable of supporting v6 even if v6 is not currently deployed on that CPE. (That's the cablemodems, dsl modem, Uverse > RGs, FiOS ONTs, and linksys's and netgears of the world.) And *then* > the > device that actually wants the content has to have support. (that'd be > you > roku, blu-ray player, console, laptop, cellphone, picture frame, etc.) You are "frame dragging" what I said into something I didn't say. What I said was that it will take v6 deployment in only a tiny portion of the number of networks to account for a large amount of the traffic. There is a lot of v6 capability that is just sitting there at the moment. I never said v4 support would go away, in fact, I said it would be around for decades. > > What is the natural "churn" rate for CPE for one of the large MSOs? > > How often MSO's replace CPE gear? That is a different question. People are always moving, for example, turning in their old CPE and getting new. Old ones break and need to be replaced with a new one. Let's say the gear they have been handing out over the past couple of years has had v6 capability. So not only have all new deployments had the capability for v6 once the provider turns it up, a good number of legacy installations have been gaining v6 capability as old gear is changed out for new. How many CPE units does Comcast go through in a month? That would be about the rate of v6 capability being deployed out there even if v6 isn't turned up on it. > "When it breaks" and "when it's no > longer compat" I don't know about your cable company, but TW doesn't > replace anything unless it's broken. Correct, and a certain number of those break every month. With every passing month the amount of CPE out there that isn't v6 capable declines. > I've had the same SB5100 for > nearly > a decade. This isn't about you or me. It is about "the net" in aggregate. V4 will continue to work, and those with older stuff will get v4. But at some point there are going to be people who decide to deploy a site that is v6 only. It will be "cool" and only "certain" people will be able to get to the content. Probably college kids and aging hipsters. Then other people will start hearing about it and want access to it ... and will demand their ISP get them on v6 pronto ;) > Heh. No it can't. You grossly underestimate the work necessary to get > the eyeballs v6 capable. If Comcast has to replace as little as 10% of > their modems, that'd be over 1mil. That's not going to happen > overnight. > (or even a month.) > > --Ricky They are constantly replacing them, all the time. Every day they replace a few more. Someone moves, turns in their old cable box, gets a new one at the new place. Kid spills milk in it, it gets dropped, whatever. Old CPE attritions out of the installed base every day, I just don't know what the annual churn rate is. But I do believe that if IPv6 were enabled in a market today on some carrier, there would be an installed base of gear right now that could handle it on day one that would represent an amount of traffic that is not insignificant. From Valdis.Kletnieks at vt.edu Fri Feb 11 16:33:37 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 11 Feb 2011 17:33:37 -0500 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: Your message of "Fri, 11 Feb 2011 14:21:49 PST." <5A6D953473350C4B9995546AFE9939EE0BC13A5A@RWC-EX1.corp.seven.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> <4D554F29.8070903@ispalliance.net> <5A6D953473350C4B9995546AFE9939EE0BC13A3E@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC13A5A@RWC-EX1.corp.seven.com> Message-ID: <76284.1297463617@localhost> On Fri, 11 Feb 2011 14:21:49 PST, George Bonser said: > That is a different question. People are always moving, for example, > turning in their old CPE and getting new. Old ones break and need to be > replaced with a new one. Let's say the gear they have been handing out > over the past couple of years has had v6 capability. So riddle me this - what CPE stuff were they giving out in 2009 that was already v6-able? (and actually *tested* as being v6-able, rather than "It's supposed to work but since we don't do v6 on the live net, nobody's ever actually *tried* it...") -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bensons at queuefull.net Fri Feb 11 16:35:31 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 11 Feb 2011 16:35:31 -0600 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> Message-ID: On Feb 11, 2011, at 3:44 PM, Michael Dillon wrote: > Not true. Two of my former employers went to ARIN every year or two and > received blocks around a /16 in size, specifically for use on global IP networks > that did not intend to ever announce those addresses on the Internet. There > are several other companies which operate somewhat similar networks. > > Also, "announce to the Internet" doesn't mean what you think it does. Exactly. Further, just because it's announced doesn't mean it's reachable or even connected. Cheers, -Benson From chris at getsprocket.com Fri Feb 11 16:39:56 2011 From: chris at getsprocket.com (Christopher Wolff) Date: Fri, 11 Feb 2011 15:39:56 -0700 Subject: Level 3 Sales? Message-ID: <4D55BABC.9050107@getsprocket.com> Is there any magic incantation required to get a Level 3 sales contact? Business must be booming for them not to return a call. From gbonser at seven.com Fri Feb 11 16:39:34 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 11 Feb 2011 14:39:34 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <76284.1297463617@localhost> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> <4D554F29.8070903@ispalliance.net> <5A6D953473350C4B9995546AFE9939EE0BC13A3E@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC13A5A@RWC-EX1.corp.seven.com> <76284.1297463617@localhost> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13A5C@RWC-EX1.corp.seven.com> > So riddle me this - what CPE stuff were they giving out in 2009 that > was already v6-able? (and actually *tested* as being v6-able, rather > than "It's supposed to work but since we don't do v6 on the live net, > nobody's ever actually *tried* it...") I would venture to say the same as today's CPE if they are issuing today the same CPE to new customers that they were issuing in 2009. I do know that in my area it has changed since 2007. But I don't know when they started issuing the current CPE. From dorn at hetzel.org Fri Feb 11 16:52:57 2011 From: dorn at hetzel.org (Dorn Hetzel) Date: Fri, 11 Feb 2011 17:52:57 -0500 Subject: IPv6 is on the marketers radar In-Reply-To: <4D55B4AC.3000907@paulgraydon.co.uk> References: <33020353.1007.1297454809458.JavaMail.franck@franck-martins-macbook-pro.local> <4C98E9AF-6611-4F7D-885C-E259DC90B425@cybernothing.org> <4D55B4AC.3000907@paulgraydon.co.uk> Message-ID: > > > p.s. with apologies to any honest marketers. All 2 of you.. > > What's the difference between a used car salesman and a network equipment salesman? The used care salesman knows when he's lying to you :) From sethm at rollernet.us Fri Feb 11 17:11:10 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 11 Feb 2011 15:11:10 -0800 Subject: SmartNet Alternatives In-Reply-To: References: <060EDFC2221B014B9504AC06B747F58A499BCC3B57@ex01.alentus.lan> Message-ID: <4D55C20E.2030108@rollernet.us> On 2/11/2011 13:49, Andrey Khomyakov wrote: > If only Cisco would sell "software only" support. 3rd party smartNet > alternatives are nice for parts replacement. They suck for support, imho, > especially, when it comes down to declaring a problem to be a bug. > On quite a few occasions I found bugs in IOS and TAC submitted those as bugs > and fixed them reasonably fast. > I thought there already was a software-only smartnet option? ~Seth From owen at delong.com Fri Feb 11 17:24:54 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 11 Feb 2011 15:24:54 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> <4D554F29.8070903@ispalliance.net> <116E791B-4F77-47C8-9A3A-0C8034FAD95C@delong.com> Message-ID: > >>> There is no hackery require to make IPv4 work in LTE. LTE supports >>> IPv4, IPv6, and IPv4v6 bearers all the same... its just an option from >>> the core perspective, handset / chipset makers like to limit the >>> options to keep cost and variability down. >>> >> My understanding (admittedly second hand, so perhaps the engineer >> explaining it to me was mistaken) was that LTE was IPv6 and that IPv4 >> was implemented on the radio side essentially as a 4in6 tunnel with a >> very very short-term DHCP lease for the v4 address. >> >> > > Nope, it does not work this way. There are tunnels for mobility, and > it is possible that IPv4 user plane packet get carried in IPv6 GTP > packets but that is the same case for IPv6 user plane also being in > IPv6 GTP packets.... but LTE generally does not use any DHCP to the > user. > > Key point: LTE does not imply any mandatory IPv6 networks > infrastructure or services, but it does work with IPv6 and should be > deployed with IPv6. > > Cameron > (who works in mobile, everyday) OK... Thanks for the clarification. So did the other guy who gave me the other story. I won't pretend to be a mobile expert. Owen From owen at delong.com Fri Feb 11 17:34:48 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 11 Feb 2011 15:34:48 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> <4D554F29.8070903@ispalliance.net> <5A6D953473350C4B9995546AFE9939EE0BC13A3E@RWC-EX1.corp.seven.com> Message-ID: <93821BFB-BC61-4F32-A9D7-8D04E8FF7ED3@delong.com> On Feb 11, 2011, at 1:41 PM, Ricky Beam wrote: > On Fri, 11 Feb 2011 12:20:59 -0500, George Bonser wrote: >> The thing is that a very few networks account for a very large amount of >> traffic. > > Traffic has to have two end points. Just because the content source supports IPv6 does not mean the content request will be. That's the "millions of eyeballs" (aka sheep.) > > You don't seem to grasp the full picture... There are 4 parts to the equation: > 1. Content Source > 2. Transit network(s) > 3. CPE > 4. Content Consumer > > Fixing the source (be it Facebook, Youtube, or netflix) is rather simple in concept -- it's just one network, and doesn't require touching millions of devices. Transit networks are hit-n-miss, but is becoming less of a burden. The CPE on the other hand is a whole other mess... there are thousands (into millions) that will need firmware upgrades or complete replacement to support IPv6. (That's the cablemodems, dsl modem, Uverse RGs, FiOS ONTs, and linksys's and netgears of the world.) And *then* the device that actually wants the content has to have support. (that'd be you roku, blu-ray player, console, laptop, cellphone, picture frame, etc.) > The CPE is an expected problem that most providers have been doing some level of planning for. I'm quite certain it will get solved in one of the following ways: 1. Provider ships replacement box. 2. Provider tells customer "As of X date, your current CPE will no longer be supported. Go buy one of these:" followed by a list of qualified CPE devices. 3. Provider finds some other way to get CPE to customers. >> What is the natural "churn" rate for CPE for one of the large MSOs? > > How often MSO's replace CPE gear? "When it breaks" and "when it's no longer compat" I don't know about your cable company, but TW doesn't replace anything unless it's broken. I've had the same SB5100 for nearly a decade. (they did replace the SB3100/4100's a few years back, but they were no longer compatible with the network.) > When the provider needs their customers to be IPv6 compatible, then IPv4 gear will be "broken" for all practical purposes in the above sentence. This will happen much faster than you expect. > AT&T DSL also doesn't replace CPE's unless they break. (or you buy a new one.) In bridge mode, any modem will do. It's when the modem is also the router (which is most cases today) that it will need attention to support IPv6. (in bridge mode, you'll have to fix whatever it's plugged into, but that's the customer's problem... off to Best Buy for an IPv6 capable D-Link.) > See above. >> What portion of the MSOs have v6 capable CPE in place right now... > > Unknown. I've not known any MSO to publish those numbers. Any sane MSO is handing out D3 modems even if they are still running a D2 network, so new connections (or replacements) should be D3. > Yes... All D3 modems are required to be IPv6 ready. So, any plant where the customers have D3, it's a configuration issue to provide IPv6 once the rest of the network is ready. >> you only need about five > > If you're thinking of five major cable operators, they aren't each "one network" but are a group of franchises/markets running more or less independent of each other. > Not so much as you think on the IP side of things. >> Yes, and I mentioned that. So once you have >50% of the potential >> content sources v6 capable and >50% of the potential eyeballs v6 >> capable, you have potentially 25% of internet traffic on v6. And that >> can be done with the migration of enough networks to count on your >> fingers. > > Heh. No it can't. You grossly underestimate the work necessary to get the eyeballs v6 capable. If Comcast has to replace as little as 10% of their modems, that'd be over 1mil. That's not going to happen overnight. (or even a month.) > No, you grossly underestimate the motivation that will exist to get the eyeball networks v6 capable. Comcast has over 20 million subscribers. Their subscribers fall into two categories: 1. Subscribers with their own gear: Comcast will probably send them a note that tells them it's time to buy new gear with specifications on what to buy. 2. Subscribers that pay Comcast a monthly fee to "rent" that gear: Comcast will probably swap out their gear. Yes, it may be over a $million, but, Comcast collects $millions per month in gear rental fees from which that can easily be covered. There will be no real problem in terms of the cost here. On the flip side of the equation, all of them are going to have to start delivering new services on IPv6 equipment with IPv6 support pretty soon anyway. As such, bringing the existing customers forward becomes a cost reduction measure because it's always cheaper to manage a network were everyone is on a limited set of hardware choices than a more diverse network. Things that reduce costs are strong motivation in narrow-margin services like residential broadband. Owen From ml at kenweb.org Fri Feb 11 17:56:18 2011 From: ml at kenweb.org (ML) Date: Fri, 11 Feb 2011 18:56:18 -0500 Subject: Cruzio peering In-Reply-To: <4D54BD24.8090809@mompl.net> References: <4D54BD24.8090809@mompl.net> Message-ID: <4D55CCA2.50409@kenweb.org> On 2/10/2011 11:37 PM, Jeroen van Aart wrote: > A high-speed/high-bandwidth wireless link connects the Cruzio 877 Cedar > facility with the Equinix San Jose facility via Mount Umunhum to provide > a wireless failover to the fiber in event of a fiber outage. > Interesting. Do you know which wireless solution they went with? Licensed/Unlicensed spectrum? From jeroen at mompl.net Fri Feb 11 18:12:57 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Fri, 11 Feb 2011 16:12:57 -0800 Subject: Cruzio peering In-Reply-To: <4D55CCA2.50409@kenweb.org> References: <4D54BD24.8090809@mompl.net> <4D55CCA2.50409@kenweb.org> Message-ID: <4D55D089.6040800@mompl.net> ML wrote: > Interesting. Do you know which wireless solution they went with? > > Licensed/Unlicensed spectrum? I am sorry, I only know what I quoted. You can try and ask someone at Cruzio. Greetings, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From marka at isc.org Fri Feb 11 18:56:59 2011 From: marka at isc.org (Mark Andrews) Date: Sat, 12 Feb 2011 11:56:59 +1100 Subject: IPv6 is on the marketers radar In-Reply-To: Your message of "Fri, 11 Feb 2011 15:36:14 MDT." <4D55ABCE.7030800@brightok.net> References: <14962827.9.1297457334197.JavaMail.franck@franck-martins-macbook-pro.local> <5A6D953473350C4B9995546AFE9939EE0BC13A58@RWC-EX1.corp.seven.com><4D55ABCE.7030800@brightok.net> Message-ID: <20110212005659.3A5239EBB60@drugs.dv.isc.org> In message <4D55ABCE.7030800 at brightok.net>, Jack Bates writes: > On 2/11/2011 3:31 PM, George Bonser wrote: > > "IPv6 is foundational to the next-generation Internet, enabling a > > range of new services and improved user experiences." > > > > Apparently they see IPv6 as some "next-generation Internet" thing. > > It isn't. > > Reread what they wrote. IPv6 is "foundational" to the next-generation > Internet. If it's not, then IETF should have added 96 bits and left the > rest of it alone. > > I can't blame Cisco for making sure how they implement the linksys is > appropriate for the long term. It's important that they get certain > things right, as future improvements of the Internet DO depend on IPv6 > being functional. They have had a #@!@ decade to add IPv6 support. They shouldn't need anymore time. Part of the reason we are in this mess is their delay in delivering products. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jbates at brightok.net Fri Feb 11 19:22:10 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 11 Feb 2011 19:22:10 -0600 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <93821BFB-BC61-4F32-A9D7-8D04E8FF7ED3@delong.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> <4D554F29.8070903@ispalliance.net> <5A6D953473350C4B9995546AFE9939EE0BC13A3E@RWC-EX1.corp.seven.com> <93821BFB-BC61-4F32-A9D7-8D04E8FF7ED3@delong.com> Message-ID: <4D55E0C2.5080405@brightok.net> On 2/11/2011 5:34 PM, Owen DeLong wrote: > No, you grossly underestimate the motivation that will exist to get the > eyeball networks v6 capable. > eyeball networks... we hack and patch them together. Silly putty is very useful. IPv6 rollouts are no different. Just more silly putty. IPv4 support for all the applications and appliances that don't support IPv6 is what will suck. So, don't worry about the ISP. Core networks are gearing up super fast (they've actually been at it for years, just not rolled it out), eyeballs will hack and patch easy enough (CPEs aren't that large a deal, and 6rd even gets us around internal v4 only problems in those isolated areas), many standard services on the net are v6 capable. Those which aren't, that's their own fault. They've had decades. :) Jack From jbates at brightok.net Fri Feb 11 19:23:19 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 11 Feb 2011 19:23:19 -0600 Subject: IPv6 is on the marketers radar In-Reply-To: <20110212005659.3A5239EBB60@drugs.dv.isc.org> References: <14962827.9.1297457334197.JavaMail.franck@franck-martins-macbook-pro.local> <5A6D953473350C4B9995546AFE9939EE0BC13A58@RWC-EX1.corp.seven.com><4D55ABCE.7030800@brightok.net> <20110212005659.3A5239EBB60@drugs.dv.isc.org> Message-ID: <4D55E107.5040003@brightok.net> On 2/11/2011 6:56 PM, Mark Andrews wrote: > They have had a #@!@ decade to add IPv6 support. They shouldn't need > anymore time. Part of the reason we are in this mess is their delay > in delivering products. Nah. The network side of things probably won't be too bad. Corporate world will have it a little rough, and the applications/appliances which haven't bothered with IPv6 will have it the worst. Jack From tal at whatexit.org Fri Feb 11 19:29:53 2011 From: tal at whatexit.org (Tom Limoncelli) Date: Fri, 11 Feb 2011 20:29:53 -0500 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <116E791B-4F77-47C8-9A3A-0C8034FAD95C@delong.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> <4D554F29.8070903@ispalliance.net> <116E791B-4F77-47C8-9A3A-0C8034FAD95C@delong.com> Message-ID: On Fri, Feb 11, 2011 at 2:56 PM, Owen DeLong wrote: > I think you'll be in for a surprise here, too. The 4G transition is already underway. For the vendors where 4G means LTE, IPv6 is the native protocol and IPv4 requires a certain amount of hackery to operate. > I'm writing an article where I want to say that but I can't find an article I can reference to back it up. I don't want to accidentally encourage an urban legend or rumor. (For example, I can't find verification to the rumor that ARIN rejected a request from LTE providers for IPv4 space and instead told them to go straight to IPv6. I do others in this thread saying that native IPv4 on LTE is common, so unless someone can give me evidence, I'll have to update that part of the article. OMG i'd love to make that point; anyone have proof?). I could, instead, write, "most carriers will probably roll IPv6 out as part of their 4G upgrade" but that sounds wishy-washy. Thanks in advance, Tom -- http://EverythingSysadmin.com? -- my blog (new posts Mon and Wed) http://www.TomOnTime.com -- my advice (more videos coming soon) From swmike at swm.pp.se Fri Feb 11 20:31:10 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 12 Feb 2011 03:31:10 +0100 (CET) Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> <4D554F29.8070903@ispalliance.net> <116E791B-4F77-47C8-9A3A-0C8034FAD95C@delong.com> Message-ID: On Fri, 11 Feb 2011, Tom Limoncelli wrote: > On Fri, Feb 11, 2011 at 2:56 PM, Owen DeLong wrote: >> I think you'll be in for a surprise here, too. The 4G transition is >> already underway. For the vendors where 4G means LTE, IPv6 is the >> native protocol and IPv4 requires a certain amount of hackery to >> operate. >> > > I'm writing an article where I want to say that but I can't find an > article I can reference to back it up. We're an LTE operator and this is the first time I've heard about this. LTE supports IPv4 and IPv6 and as far as I can discern, that is a requirement, and there is no "hackery" to get IPv4 running. We have yet to see any LTE terminals (USB dongels so far) that support IPv6. There are a lot of other kinks to work out first, going IPv6 only here is definitely not the place. Remember, a lot of people buying this service is taking the USB dongle and attaching it to their corporate XP laptop. -- Mikael Abrahamsson email: swmike at swm.pp.se From mpetach at netflight.com Fri Feb 11 21:08:03 2011 From: mpetach at netflight.com (Matthew Petach) Date: Fri, 11 Feb 2011 19:08:03 -0800 Subject: My upstream ISP does not support IPv6 In-Reply-To: References: Message-ID: On Thu, Feb 3, 2011 at 6:08 PM, Peter Lothberg wrote: ... > (My mother has had IPv6 since 2007, and she lives in the boonies!) Just now catching up...and don't take this wrong way, Peter, but your mother has more bandwidth and better connectivity than many countries (and some continents!) do. :-P http://www.usatoday.com/tech/webguide/internetlife/2007-07-19-swedish-woman-fast-internet_N.htm *had to fight back the urge to turn it into a 'yo mamma' joke...* ^_^; Matt From kauer at biplane.com.au Fri Feb 11 21:18:52 2011 From: kauer at biplane.com.au (Karl Auer) Date: Sat, 12 Feb 2011 14:18:52 +1100 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <116E791B-4F77-47C8-9A3A-0C8034FAD95C@delong.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> <4D554F29.8070903@ispalliance.net> <116E791B-4F77-47C8-9A3A-0C8034FAD95C@delong.com> Message-ID: <1297480732.25439.34.camel@karl> On Fri, 2011-02-11 at 11:56 -0800, Owen DeLong wrote: > I think that it will not be long > before the internet is an IPv6 ocean with islands of IPv4 My company made up some t-shirts for a conference last year. We brainstormed the texts. I ended up with a sort of haiku: out of the puddle into the ocean IPv6 Sadly I realised too late that it should have had a footnote: "not to scale" :-) Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From mpetach at netflight.com Fri Feb 11 21:24:03 2011 From: mpetach at netflight.com (Matthew Petach) Date: Fri, 11 Feb 2011 19:24:03 -0800 Subject: My upstream ISP does not support IPv6 In-Reply-To: <185E6979-5F80-4F7A-8DE6-562132264990@delong.com> References: <1127264403.2346.1296791643752.JavaMail.root@zimbra.network1.net> <185E6979-5F80-4F7A-8DE6-562132264990@delong.com> Message-ID: On Fri, Feb 4, 2011 at 4:33 PM, Owen DeLong wrote: > I'll start.. > > Hurricane Electric ? ? ?Happily and readily provided me IPv6 Transit on request. > Layer42 ? ? ? ? ? ? ? ? ? ? ? ? Happily and readily provided me IPv6 Transit on request. > > Owen I'll second that--I've had native v6 connectivity with Layer42 at home, with a secondary path via HE tunnelbroker via a secondary physical path for many, many moons, and have had no complaints. For those with smaller-sized connectivity needs, it's likely you'll have better success getting v6 connectivity from a tier-2 provider, as there's less non-v6- compliant hardware and software that needs to be taken into consideration. There's also likely to be some level of impedance mismatch between the upgrade priority for high-bandwidth-customer gear and low-bandwidth-customer gear at large-sized ISPs, which may relegate you to a slower deployment scheduled than if you bring the question up with your local tier 2 provider. Matt From kauer at biplane.com.au Fri Feb 11 21:25:54 2011 From: kauer at biplane.com.au (Karl Auer) Date: Sat, 12 Feb 2011 14:25:54 +1100 Subject: IPv6 is on the marketers radar In-Reply-To: References: <33020353.1007.1297454809458.JavaMail.franck@franck-martins-macbook-pro.local> <4C98E9AF-6611-4F7D-885C-E259DC90B425@cybernothing.org> <4D55B4AC.3000907@paulgraydon.co.uk> Message-ID: <1297481154.25439.35.camel@karl> On Fri, 2011-02-11 at 17:52 -0500, Dorn Hetzel wrote: > > p.s. with apologies to any honest marketers. All 2 of you.. > What's the difference between a used car salesman and a network equipment > salesman? > > The used care salesman knows when he's lying to you :) And the used car saleman probably knows how to drive... Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From owen at delong.com Fri Feb 11 21:31:56 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 11 Feb 2011 19:31:56 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <1297480732.25439.34.camel@karl> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> <4D554F29.8070903@ispalliance.net> <116E791B-4F77-47C8-9A3A-0C8034FAD95C@delong.com> <1297480732.25439.34.camel@karl> Message-ID: <5AEE022A-CFA8-4F11-BDD1-6B0FD6DA077A@delong.com> On Feb 11, 2011, at 7:18 PM, Karl Auer wrote: > On Fri, 2011-02-11 at 11:56 -0800, Owen DeLong wrote: >> I think that it will not be long >> before the internet is an IPv6 ocean with islands of IPv4 > > My company made up some t-shirts for a conference last year. We > brainstormed the texts. I ended up with a sort of haiku: > > out of the puddle > into the ocean > IPv6 > > Sadly I realised too late that it should have had a footnote: "not to > scale" :-) True. If you want to compare masses, IPv4 = 7 liters of water. IPv6 = EARTH, including all rocks, trees, oceans, lakes, puddles, etc. Put another way, if subnets (IPv4 /24s, IPv6 /64s) were Almond M&Ms, IPv4 would cover approximately 70 yards of a regulation American Football field in a single layer of M&Ms. IPv6 would fill the great lakes. All of the great lakes. To the rim. In terms of host addresses per subnet, IPv4 gives you a large bag of M&Ms. IPv6 gives you the great lakes full of M&Ms. All of the great lakes. To the rim. Owen Disclaimer: Do not attempt to eat a /64 worth of any form of M&Ms as adverse health results are likely. From jbates at brightok.net Fri Feb 11 21:40:29 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 11 Feb 2011 21:40:29 -0600 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <5AEE022A-CFA8-4F11-BDD1-6B0FD6DA077A@delong.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> <4D554F29.8070903@ispalliance.net> <116E791B-4F77-47C8-9A3A-0C8034FAD95C@delong.com> <1297480732.25439.34.camel@karl> <5AEE022A-CFA8-4F11-BDD1-6B0FD6DA077A@delong.com> Message-ID: <4D56012D.3060606@brightok.net> On 2/11/2011 9:31 PM, Owen DeLong wrote: > If you want to compare masses, IPv4 = 7 liters of water. > IPv6 = EARTH, including all rocks, trees, oceans, lakes, puddles, > etc. Was trying to explain things to a telco VP today. Finally settled on, "The Internet is out of 10 digit phone numbers. We're upgrading to 40 digit phone numbers. Unfortunately, the two can't dial each other directly." After 51+ years in the telco industry, I think he gets that problem. Jack From jra at baylink.com Fri Feb 11 21:54:39 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 11 Feb 2011 22:54:39 -0500 (EST) Subject: PSTN address expansion (was: Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...) In-Reply-To: <4D56012D.3060606@brightok.net> Message-ID: <15369766.6992.1297482879815.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jack Bates" > On 2/11/2011 9:31 PM, Owen DeLong wrote: > > If you want to compare masses, IPv4 = 7 liters of water. > > IPv6 = EARTH, including all rocks, trees, oceans, lakes, puddles, > > etc. > > Was trying to explain things to a telco VP today. Finally settled on, > > "The Internet is out of 10 digit phone numbers. We're upgrading to 40 > digit phone numbers. Unfortunately, the two can't dial each other > directly." http://www.lincmad.com/future.html Cheers, -- jra From bosch at adacore.com Fri Feb 11 22:17:01 2011 From: bosch at adacore.com (Geert Bosch) Date: Fri, 11 Feb 2011 23:17:01 -0500 Subject: IPv6 is on the marketers radar In-Reply-To: References: <33020353.1007.1297454809458.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On Feb 11, 2011, at 15:43, Fred Baker wrote: > Anyone that uses a residential router (Linksys, D-Link, Netgear, etc) is likely to need to upgrade that, most likely by buying a new one. Set-top boxes are generally IPv4; anyone with a TV is likely to need to upgrade at least the software. Skype is not yet IPv6-capable, and will need one an update. "The ISPs will take care of this" is a really empty hope. The ISPs will take care of their part, but users should expect that there will be things jiggling over the coming couple of years. Honestly, I can't quite see the big deal for home users. I'm using an Apple Airport Extreme, and setting it up with a IPv6 tunnel from HE was quite straightforward. Sure, I don't expect the average user to go through these steps, but they could easily be automated and rolled out as part of a firmware update (which is a routine matter already) . If larger ISP's provide their own tunnels, they could use private IPv4 space for customers to tunnel IPv6 over, and the only issue would be a few router settings to change. According to test-ipv6.com my home network has now a score of 10/10 for both IPv4 and IPv6. Didn't take very long to do, maybe 10 minutes. Initial speed tests show only a marginal slowdown of IPv6 compared to IPv4. However, if I look at what would be involved at my $dayjob to support IPv6, that would be far more involved. What's more, I cannot justify the cost to support IPv6 only clients, as there are none yet. For the foreseeable future, people will have (NATed or not) IPv4 connectivity, so content providers are fine without IPv6. I won't have to worry about this until most major content providers support IPv6-only clients. So, I think we'll transition to a situation where for some purposes (Skype, gaming, file-sharing) there will be a benefit for (tunneled) IPv6 compared to (NATed) IPv4, but for simple content providers there will still be no incentive to leave IPv4. For the software there is a similar scenario. Clients typically use a web browser or other high-volume popular application. It is easy to add IPv6 support to these. However, content providers use many different pieces to provider their sites, including custom interfaces to databases etc. It's a huge task to make all of those work with IPv6. Again, it seems it is far easier to deal with the relatively homogeneous base of users for IPv6, compared to the fragmented and irregular market of content providers. -Geert From jbates at brightok.net Fri Feb 11 22:17:24 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 11 Feb 2011 22:17:24 -0600 Subject: PSTN address expansion In-Reply-To: <15369766.6992.1297482879815.JavaMail.root@benjamin.baylink.com> References: <15369766.6992.1297482879815.JavaMail.root@benjamin.baylink.com> Message-ID: <4D5609D4.9050404@brightok.net> On 2/11/2011 9:54 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Jack Bates" >> On 2/11/2011 9:31 PM, Owen DeLong wrote: >>> If you want to compare masses, IPv4 = 7 liters of water. >>> IPv6 = EARTH, including all rocks, trees, oceans, lakes, puddles, >>> etc. >> Was trying to explain things to a telco VP today. Finally settled on, >> >> "The Internet is out of 10 digit phone numbers. We're upgrading to 40 >> digit phone numbers. Unfortunately, the two can't dial each other >> directly." > http://www.lincmad.com/future.html > Bah, I substitute your short sighted 12 digits with 40 digit dialing! However, because the numbers are too long to remember, you only have to speak or type in the name of someone you want to call, and 15 digits can be assigned to every household or business site, and the phones will automatically number themselves, so if you plug your phone in somewhere else, only the first 25 digits change. Jack (hmm, I think the VP will be giving me funny looks now) From jbates at brightok.net Fri Feb 11 22:28:32 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 11 Feb 2011 22:28:32 -0600 Subject: PSTN address expansion In-Reply-To: <4D5609D4.9050404@brightok.net> References: <15369766.6992.1297482879815.JavaMail.root@benjamin.baylink.com> <4D5609D4.9050404@brightok.net> Message-ID: <4D560C70.7020705@brightok.net> On 2/11/2011 10:17 PM, Jack Bates wrote: > > Bah, I substitute your short sighted 12 digits with 40 digit dialing! > However, because the numbers are too long to remember, you only have > to speak or type in the name of someone you want to call, and 15 > digits can be assigned to every household or business site, and the > phones will automatically number themselves, so if you plug your phone > in somewhere else, only the first 25 digits change. > > Jack (hmm, I think the VP will be giving me funny looks now) My apologies for the error, it will actually be a 32 digit system, and we're switching to base-16, so all phones will have to be replaced with phones supporting 0-9A-F. Jack From jeff-kell at utc.edu Fri Feb 11 22:59:01 2011 From: jeff-kell at utc.edu (Jeff Kell) Date: Fri, 11 Feb 2011 23:59:01 -0500 Subject: PSTN address expansion In-Reply-To: <4D560C70.7020705@brightok.net> References: <15369766.6992.1297482879815.JavaMail.root@benjamin.baylink.com> <4D5609D4.9050404@brightok.net> <4D560C70.7020705@brightok.net> Message-ID: <4D561395.1060607@utc.edu> On 2/11/2011 11:28 PM, Jack Bates wrote: > My apologies for the error, it will actually be a 32 digit system, and > we're switching to base-16, so all phones will have to be replaced > with phones supporting 0-9A-F. Well, they already do, you just need a military phone or a linesman's handset to get the last 4 to actually dial :-) (Who needs the freakin' "*" and "#" anyway) Jeff From joelja at bogus.com Fri Feb 11 23:27:17 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 11 Feb 2011 21:27:17 -0800 Subject: PSTN address expansion In-Reply-To: <4D561395.1060607@utc.edu> References: <15369766.6992.1297482879815.JavaMail.root@benjamin.baylink.com> <4D5609D4.9050404@brightok.net> <4D560C70.7020705@brightok.net> <4D561395.1060607@utc.edu> Message-ID: <4D561A35.90406@bogus.com> On 2/11/11 8:59 PM, Jeff Kell wrote: > On 2/11/2011 11:28 PM, Jack Bates wrote: >> My apologies for the error, it will actually be a 32 digit system, and >> we're switching to base-16, so all phones will have to be replaced >> with phones supporting 0-9A-F. > > Well, they already do, you just need a military phone or a linesman's > handset to get the last 4 to actually dial :-) > > (Who needs the freakin' "*" and "#" anyway) you do need : and / joel > Jeff > From jcurran at arin.net Sat Feb 12 00:20:08 2011 From: jcurran at arin.net (John Curran) Date: Sat, 12 Feb 2011 06:20:08 +0000 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> <4D554F29.8070903@ispalliance.net> <116E791B-4F77-47C8-9A3A-0C8034FAD95C@delong.com> Message-ID: On Feb 11, 2011, at 8:29 PM, Tom Limoncelli wrote: > I don't want to accidentally encourage an urban legend or rumor. (For > example, I can't find verification to the rumor that ARIN rejected a > request from LTE providers for IPv4 space and instead told them to go > straight to IPv6. Not quite correct - A while back we did explain the policies regarding slow-start and the potential for operators to run into IPv4 depletion while still early in capital depreciation for their nextgen network. That's not rejection, just fair warning... :-) /John John Curran President and CEO ARIN From joelja at bogus.com Sat Feb 12 00:27:06 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 11 Feb 2011 22:27:06 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> <4D554F29.8070903@ispalliance.net> <116E791B-4F77-47C8-9A3A-0C8034FAD95C@delong.com> Message-ID: <4D56283A.7090402@bogus.com> On 2/11/11 6:31 PM, Mikael Abrahamsson wrote: > On Fri, 11 Feb 2011, Tom Limoncelli wrote: > >> On Fri, Feb 11, 2011 at 2:56 PM, Owen DeLong wrote: > >>> I think you'll be in for a surprise here, too. The 4G transition is >>> already underway. For the vendors where 4G means LTE, IPv6 is the >>> native protocol and IPv4 requires a certain amount of hackery to >>> operate. >>> >> >> I'm writing an article where I want to say that but I can't find an >> article I can reference to back it up. > > We're an LTE operator and this is the first time I've heard about this. > LTE supports IPv4 and IPv6 and as far as I can discern, that is a > requirement, and there is no "hackery" to get IPv4 running. 3gpp release 8 and later does not throw out the baby with the bathwater. v6 only contexts are certainly supported however and we know for a fact that there are certain entities that will use that in short order. > We have yet to see any LTE terminals (USB dongels so far) that support > IPv6. There are a lot of other kinks to work out first, going IPv6 only > here is definitely not the place. Remember, a lot of people buying this > service is taking the USB dongle and attaching it to their corporate XP > laptop. The current verizon lte sticks (sourced lg and pantech) do in fact provide v6 connectivity as do some of the embedded mini pci-e cards. I note with some entertainment for the future of mobile walled gardens the last bullet point on this page everytime I see it: https://www.lte.vzw.com/About4GLTE/VerizonWireless4GLTENetwork/tabid/6003/Default.aspx From ghira at mistral.co.uk Sat Feb 12 03:02:32 2011 From: ghira at mistral.co.uk (Adam Atkinson) Date: Sat, 12 Feb 2011 09:02:32 +0000 Subject: Looking for an IPv6 naysayer... In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC139A0@RWC-EX1.corp.seven.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><4D52E942.5000607@ispalliance.net><87sjvxhu1v.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com><8762stc5a7.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1399F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC139A0@RWC-EX1.corp.seven.com> Message-ID: <4D564CA8.9010206@mistral.co.uk> George Bonser wrote: > I have yet to see a broadband provider that configures a network so that > individual nodes in the home network get global IPs. When I switched to ADSL I'm pretty sure I was offered the choice of a single public IP address on the outside of my router, or a /29 public range for my home network (and presumably also a public address for the external interface of my router). I chose the former and don't regret having done so. I can do a mixture of static and dynamic NAT to allow things from the outside into particular internal hosts if I want do. This was in 2005, and I can very well believe this choice was not available some time later. From gbonser at seven.com Sat Feb 12 03:08:10 2011 From: gbonser at seven.com (George Bonser) Date: Sat, 12 Feb 2011 01:08:10 -0800 Subject: Looking for an IPv6 naysayer... In-Reply-To: <4D564CA8.9010206@mistral.co.uk> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><4D52E942.5000607@ispalliance.net><87sjvxhu1v.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com><8762stc5a7.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1399F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC139A0@RWC-EX1.corp.seven.com> <4D564CA8.9010206@mistral.co.uk> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13A74@RWC-EX1.corp.seven.com> > > When I switched to ADSL I'm pretty sure I was offered the choice of a > single public IP address on the outside of my router, or a /29 public > range for my home network (and presumably also a public address for the > external interface of my router). I chose the former and don't regret > having done so. I can do a mixture of static and dynamic NAT to allow > things from the outside into particular internal hosts if I want do. > > This was in 2005, and I can very well believe this choice was not > available some time later. I had a similar setup at one time, I believe it was from Speakeasy but I can't remember, might have been a Covad beta with another provider that my late wife was working for when ADSL was brand new. Not saying it can't be or isn't done; just that for the vast majority (probably something like 90% or more) it isn't. George From Valdis.Kletnieks at vt.edu Sat Feb 12 07:59:35 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 12 Feb 2011 08:59:35 -0500 Subject: Looking for an IPv6 naysayer... In-Reply-To: Your message of "Sat, 12 Feb 2011 09:02:32 GMT." <4D564CA8.9010206@mistral.co.uk> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <87sjvxhu1v.fsf@oban.berlin.quux.de> <5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com> <8762stc5a7.fsf@oban.berlin.quux.de> <5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1399F@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC139A0@RWC-EX1.corp.seven.com> <4D564CA8.9010206@mistral.co.uk> Message-ID: <31739.1297519175@localhost> On Sat, 12 Feb 2011 09:02:32 GMT, Adam Atkinson said: > When I switched to ADSL I'm pretty sure I was offered the choice of a > single public IP address on the outside of my router, or a /29 public > range for my home network (and presumably also a public address for the > external interface of my router). I chose the former and don't regret > having done so. I can do a mixture of static and dynamic NAT to allow > things from the outside into particular internal hosts if I want do. > > This was in 2005, and I can very well believe this choice was not > available some time later. It's more a business question. If you're an ADSL provider, you probably want to save "multiple public IP" as a feature so you can upsell customers to "business class". There's little business case for doing it by default for Joe Sixpack (especially in a world where public IP's are getting scarce). Fortunately, in IPv6 the bit boundaries have moved, so there's no scarcity issue and "give everybody a /48 (or at least a /56)" is a no-brainer. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From thomas at habets.se Sat Feb 12 09:49:08 2011 From: thomas at habets.se (Thomas Habets) Date: Sat, 12 Feb 2011 15:49:08 +0000 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> <4D554F29.8070903@ispalliance.net> Message-ID: On Fri, Feb 11, 2011 at 16:02, Ricky Beam wrote: > i.e. cellphones... the two largest groups there (iPhone and Android) > support IPv6 already. No they don't. Only Symbian and Maemo (MeeGo?) supports IPv6 *on the mobile side*. Not android, not iphone. Unless this has changed in the last month, it's still the case. Neither of the two have any public plans to support IPv6 either. Really. -- typedef struct me_s { ?char name[] ? ? ?= { "Thomas Habets" }; ?char email[] ? ? = { "thomas at habets.pp.se" }; ?char kernel[] ? ?= { "Linux" }; ?char *pgpKey[] ? = { "http://www.habets.pp.se/pubkey.txt" }; ?char pgp[] = { "A8A3 D1DD 4AE0 8467 7FDE ?0945 286A E90A AD48 E854" }; ?char coolcmd[] ? = { "echo '. ./_&. ./_'>_;. ./_" }; } me_t; From ak at list.ak.cx Sat Feb 12 10:34:31 2011 From: ak at list.ak.cx (Andre Keller) Date: Sat, 12 Feb 2011 17:34:31 +0100 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> <4D554F29.8070903@ispalliance.net> Message-ID: <4D56B697.3040103@list.ak.cx> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 My Milestone (android 2.1) uses IPv6 when connecting to a WLAN with stateless auto configuration enabled... (well at least basic connectivity when browsing web pages... Not sure about the rest...) Am 12.02.2011 16:49, schrieb Thomas Habets: > On Fri, Feb 11, 2011 at 16:02, Ricky Beam wrote: >> i.e. cellphones... the two largest groups there (iPhone and Android) >> support IPv6 already. > > No they don't. Only Symbian and Maemo (MeeGo?) supports IPv6 *on the > mobile side*. > > Not android, not iphone. > > Unless this has changed in the last month, it's still the case. > > Neither of the two have any public plans to support IPv6 either. > > Really. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1WtpcACgkQHTGv6cAMp2iYGQCgmY7LZLOCyaj0SloiyObyBHx+ Ts8AnAvnyRurC9a3eZgwV0BRJ2oiAvJe =+mZr -----END PGP SIGNATURE----- From jbates at brightok.net Sat Feb 12 10:42:48 2011 From: jbates at brightok.net (Jack Bates) Date: Sat, 12 Feb 2011 10:42:48 -0600 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <4D56B697.3040103@list.ak.cx> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> <4D554F29.8070903@ispalliance.net> <4D56B697.3040103@list.ak.cx> Message-ID: <4D56B888.2010809@brightok.net> On 2/12/2011 10:34 AM, Andre Keller wrote: > My Milestone (android 2.1) uses IPv6 when connecting to a WLAN with > stateless auto configuration enabled... Am 12.02.2011 16:49, schrieb Thomas Habets: > *on the mobile side*. From swmike at swm.pp.se Sat Feb 12 10:53:23 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 12 Feb 2011 17:53:23 +0100 (CET) Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> <4D554F29.8070903@ispalliance.net> Message-ID: On Sat, 12 Feb 2011, Thomas Habets wrote: > Really. Exactly. Can we PLEASE kill the myth that Android and iPhone has IPv6 support for mobile side. PLEASE. None do, and there are no publically available roadmaps when this might happen on either OSes. There are exactly two types of devices (afaik) that support IPv6 for mobile, and that's Nokia phones using Symbian and Maemo (afaik only N900). No other vendor has any IPv6 mobile side support, and even though Microsoft did the right thing for IPv6 on Vista and Win7, they've dropped the ball on Windows Phone 7 and have no IPv6 support there. I was very disappointed when I learnt that fact. I've been told it's to some extent a Qualcomm baseband issue. There are also no USB dongles with IPv6 support that I am aware of. This means that the incentive for mobile operators to support IPv6 is very close to zero even though a lot of them could do it fairly easily. I have native IPv6 in my Nokia N900, it works just fine within "my" own network, ie without roaming. -- Mikael Abrahamsson email: swmike at swm.pp.se From lowen at pari.edu Sat Feb 12 11:26:31 2011 From: lowen at pari.edu (Lamar Owen) Date: Sat, 12 Feb 2011 12:26:31 -0500 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <76284.1297463617@localhost> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> Message-ID: <201102121226.32079.lowen@pari.edu> On Friday, February 11, 2011 05:33:37 pm Valdis.Kletnieks at vt.edu wrote: > So riddle me this - what CPE stuff were they giving out in 2009 that was > already v6-able? (and actually *tested* as being v6-able, rather than "It's > supposed to work but since we don't do v6 on the live net, nobody's ever > actually *tried* it...") Well, while no one that I know 'gave out' Linksys WRT54G's capable of running OpenWRT or similar (Sveasoft firmware, too), a WRT54G of the right (read: old enough) version can run the IPv6 modules (ipkg's) for OpenWRT, and there was at least one version of the Sveasoft WRT firmware that could do IPv6. While I have a few WRT54G's lying around, I've never tried IPv6 on them, and would find it interesting if anyone has. Owen, in particular, should know, because one of the HOWTO's I found was posted on an HE forum.....back in April of 2009. I found a few other HOWTO's, some in 2006, some in 2005, detailing IPv6 setup for the WRT54G running either Sveasoft or OpenWRT (one was for DD-WRT, and another for Tomato). Yeah, only the tech-savvy customers will be able to use this, unless the ISP sets up a 'Golden' CPE firmware image and recycles all those WRT54G's into useful things.... and then, of course, the DSL/Cable gateway needs to be in bridge mode. I'm sure there are other Linux-based firmwares for other CPE that can run Linux and IPv6; they just need enough flash and RAM to do it. vxWorks boxen, not so sure. And then there's all the Zoom stuff out there..... My own Netgear DG834G can, too, with some interesting tinkering involved. So the firmware is out there to do this, it just requires flashing and configuring. From cb.list6 at gmail.com Sat Feb 12 11:37:07 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Sat, 12 Feb 2011 09:37:07 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> <4D554F29.8070903@ispalliance.net> Message-ID: On Sat, Feb 12, 2011 at 8:53 AM, Mikael Abrahamsson wrote: > On Sat, 12 Feb 2011, Thomas Habets wrote: > >> Really. > > Exactly. Can we PLEASE kill the myth that Android and iPhone has IPv6 > support for mobile side. PLEASE. None do, and there are no publically > available roadmaps when this might happen on either OSes. > > There are exactly two types of devices (afaik) that support IPv6 for mobile, > and that's Nokia phones using Symbian and Maemo (afaik only N900). > > No other vendor has any IPv6 mobile side support, and even though Microsoft > did the right thing for IPv6 on Vista and Win7, they've dropped the ball on > Windows Phone 7 and have no IPv6 support there. I was very disappointed when > I learnt that fact. I've been told it's to some extent a Qualcomm baseband > issue. There are also no USB dongles with IPv6 support that I am aware of. > I completely agree with this note from Mikael, but as Joel pointed out and I have confirmed before, Verizon Wireless does have dual-stack USB sticks for LTE. But it is only working on their itty bitty LTE network ... LTE is still developing a market and the economies of scale are not there, so things like this happen where small supply exceeds the growing demand. I believe the chipset cost for LTE are around $100 while they are $15 for HSPA ... (foggy memory) But, LTE is not the issue here. GSM/UMTS/HSPA+ all support IPv6 just as well as LTE. The issue is mobile OSs don't support IPv6 aside from Nokia. Mikael and I both have 3G networks with demonstrated IPv6 capabilities, perhaps people should request Google drive Android IPv6 support. Please point your IPv6 interest here http://code.google.com/p/android/issues/detail?id=3389 and comment and try and drive the IPv6 support for mobile into Android. Cameron > This means that the incentive for mobile operators to support IPv6 is very > close to zero even though a lot of them could do it fairly easily. > > I have native IPv6 in my Nokia N900, it works just fine within "my" own > network, ie without roaming. > > -- > Mikael Abrahamsson ? ?email: swmike at swm.pp.se > > From dougb at dougbarton.us Sat Feb 12 13:09:02 2011 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 12 Feb 2011 11:09:02 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <201102121226.32079.lowen@pari.edu> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <201102121226.32079.lowen@pari.edu> Message-ID: <4D56DACE.9080002@dougbarton.us> On 02/12/2011 09:26 AM, Lamar Owen wrote: > While I have a few WRT54G's lying around, I've never tried IPv6 on them, and would find it interesting if anyone has. http://www.tunnelbroker.net/forums/index.php?topic=106.0 -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From scott at doc.net.au Sat Feb 12 13:32:40 2011 From: scott at doc.net.au (Scott Howard) Date: Sat, 12 Feb 2011 11:32:40 -0800 Subject: [v6z] Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <201102121226.32079.lowen@pari.edu> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <5A6D953473350C4B9995546AFE9939EE0BC13A5A@RWC-EX1.corp.seven.com> <76284.1297463617@localhost> <201102121226.32079.lowen@pari.edu> Message-ID: On Sat, Feb 12, 2011 at 9:26 AM, Lamar Owen wrote: > While I have a few WRT54G's lying around, I've never tried IPv6 on them, > and would find it interesting if anyone has. > I used a WRT54G running DD-WRT for some time with a HE IPv6 tunnel (now replaced with a Cisco 877, but not due to any failing of the Linksys/DD-WRT) IPv6 support is actually broken in the latest version of DD-WRT, and it's been that way for some time (measured in years), however with some hacking you can get it to work. It's not at all user friendly, and definitely not consumer ready, but once it's working it's pretty much rock solid. All up I'd say I probably spent less time getting IPv6 working on DD-WRT than on my Cisco 877W (Hint: IOS 12.x doesn't support IPv6 on the bridge interface, the IOS 15.x Advanced Security feature set doesn't support IPv6 at all, and the flash requirements listed for 15.1 Advanced IP are wrong. Go Cisco!) Keep in mind that not all WRT54G's support DD-WRT. Linksys moved from Linux to Vxworks but kept the model number the same (the version did change). The WRT54GL along with various other devices do support it - details are on the DD-WRT website. Scott. From laurent at guerby.net Sat Feb 12 14:44:16 2011 From: laurent at guerby.net (Laurent GUERBY) Date: Sat, 12 Feb 2011 21:44:16 +0100 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> <4D554F29.8070903@ispalliance.net> Message-ID: <1297543456.11476.1920.camel@pc2.unassigned-domain> On Sat, 2011-02-12 at 09:37 -0800, Cameron Byrne wrote: > Mikael and I both have 3G networks with demonstrated IPv6 > capabilities, perhaps people should request Google drive Android IPv6 > support. Please point your IPv6 interest here > http://code.google.com/p/android/issues/detail?id=3389 and comment and > try and drive the IPv6 support for mobile into Android. Looks like cyanogenmod supports ipv6: http://forum.cyanogenmod.com/topic/1286-ipv6-on-cm-508-ds/ Laurent From dr at cluenet.de Sat Feb 12 14:46:36 2011 From: dr at cluenet.de (Daniel Roesen) Date: Sat, 12 Feb 2011 21:46:36 +0100 Subject: SmartNet Alternatives In-Reply-To: References: <060EDFC2221B014B9504AC06B747F58A499BCC3B57@ex01.alentus.lan> Message-ID: <20110212204636.GA27845@srv03.cluenet.de> On Fri, Feb 11, 2011 at 04:49:55PM -0500, Andrey Khomyakov wrote: > If only Cisco would sell "software only" support. They do. You might have to make your sales droid know that YOU know about it thought. :-) Order items were CON-SW-... in the past, not sure about today. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From denys at visp.net.lb Sat Feb 12 15:05:41 2011 From: denys at visp.net.lb (denys at visp.net.lb) Date: Sat, 12 Feb 2011 23:05:41 +0200 Subject: US Warships jamming Lebanon Internet In-Reply-To: <4D51911A.2060008@brightok.net> References: "\"<201102081359.39100.denys@visp.net.lb>" <201102081434.38609.denys@visp.net.lb>" <052C3BF4-13C9-4AE1-BF5E-DC5AF16179C7@oitc.com> <201102081541.23651.denys@visp.net.lb> <4D51911A.2060008@brightok.net> Message-ID: <73b1fdd4629c62e4cc48070f2825596f@visp.net.lb> On Tue, 08 Feb 2011 12:53:14 -0600, Jack Bates wrote: > On 2/8/2011 7:41 AM, Denys Fedoryshchenko wrote: >> It is PLL LNB, one carrier, we are using full transponder 36 Mhz. >> There is >> almost no other users on this satellite (inclined more than 1.5 >> degree), and >> other carriers center frequency 100Mhz away. >> > > Since no one else will, "I blame solar flares!" > > > Jack I am monitoring solar activity, getting info from NOAA. No correlation. From ryan.finnesey at HarrierInvestments.com Sat Feb 12 15:33:32 2011 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Sat, 12 Feb 2011 13:33:32 -0800 Subject: SmartNet Alternatives In-Reply-To: References: <060EDFC2221B014B9504AC06B747F58A499BCC3B57@ex01.alentus.lan> Message-ID: <6EFFEFBAC68377459A2E972105C759EC036456FC@EXVBE005-2.exch005intermedia.net> This is one of the reasons we are starting to look at Juniper for a new network build. It is my understanding we set software updates for life for free. Cheers Ryan -----Original Message----- From: Michael Loftis [mailto:mloftis at wgops.com] Sent: Friday, February 11, 2011 4:27 PM To: John Macleod Cc: nanog at nanog.org Subject: Re: SmartNet Alternatives Cisco is making noises that they'll eventually be restricting software access to ONLY those devices which have an active SmartNet contract associated to your CCO account. I don't know where this currently stands, and it sure will be a huge pain in my rear if/when it happens. On Fri, Feb 11, 2011 at 1:41 PM, John Macleod wrote: > Just interested in other peoples experience to companies offering alternatives to SmartNet? > > Pros/Cons/Tradeoffs? > > We currently have a mix of SmartNet and internal parts supply. > > John > > > __ > John Macleod > Alentus UK Limited > Seymour House > South Street > Bromley > BR1 1RH > ?+44 (0)208 315 5800 > ?+44 (0)208 315 5801 fax > alentus.co.uk ?| ?alentus.com > > "Please consider the environment before printing this e-mail > > This e-mail (and/or any attachment) contains information, which is confidential and intended solely for the attention and use of the named addressee(s). If you are not the intended recipient you must not copy, distribute or use it for any purpose or disclose the contents to any person. If you have received this e-mail in error, please immediately notify the sender. The information contained in this e-mail (and any attachments) is supplied in good faith, but the sender shall not be under any liability in damages or otherwise for any reliance that may be placed upon it by the recipient, nor does it constitute a contract in any way. Any comments or opinions expressed are those of the originator not of Alentus Corporation unless otherwise expressly stated." > > From tagno25 at gmail.com Sat Feb 12 15:37:42 2011 From: tagno25 at gmail.com (Philip Dorr) Date: Sat, 12 Feb 2011 15:37:42 -0600 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <1297543456.11476.1920.camel@pc2.unassigned-domain> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> <4D554F29.8070903@ispalliance.net> <1297543456.11476.1920.camel@pc2.unassigned-domain> Message-ID: That is on WiFi, NOT cellular. On Sat, Feb 12, 2011 at 2:44 PM, Laurent GUERBY wrote: > On Sat, 2011-02-12 at 09:37 -0800, Cameron Byrne wrote: >> Mikael and I both have 3G networks with demonstrated IPv6 >> capabilities, perhaps people should request Google drive Android IPv6 >> support. ?Please point your IPv6 interest here >> http://code.google.com/p/android/issues/detail?id=3389 and comment and >> try and drive the IPv6 support for mobile into Android. > > Looks like cyanogenmod supports ipv6: > > http://forum.cyanogenmod.com/topic/1286-ipv6-on-cm-508-ds/ > > Laurent > > > > > From tvhawaii at shaka.com Sat Feb 12 15:39:59 2011 From: tvhawaii at shaka.com (Michael Painter) Date: Sat, 12 Feb 2011 11:39:59 -1000 Subject: US Warships jamming Lebanon Internet References: "\"<201102081359.39100.denys@visp.net.lb>"<201102081434.38609.denys@visp.net.lb>"<052C3BF4-13C9-4AE1-BF5E-DC5AF16179C7@oitc.com><201102081541.23651.denys@visp.net.lb> <4D51911A.2060008@brightok.net> <73b1fdd4629c62e4cc48070f2825596f@visp.net.lb> Message-ID: denys at visp.net.lb wrote: > On Tue, 08 Feb 2011 12:53:14 -0600, Jack Bates wrote: >> On 2/8/2011 7:41 AM, Denys Fedoryshchenko wrote: >>> It is PLL LNB, one carrier, we are using full transponder 36 Mhz. >>> There is >>> almost no other users on this satellite (inclined more than 1.5 >>> degree), and >>> other carriers center frequency 100Mhz away. >>> >> >> Since no one else will, "I blame solar flares!" >> >> >> Jack > > I am monitoring solar activity, getting info from NOAA. No correlation. Have you been able to get any assistance from the uplink/teleport noc or the satellite operator? From joly at punkcast.com Sat Feb 12 16:01:12 2011 From: joly at punkcast.com (Joly MacFie) Date: Sat, 12 Feb 2011 17:01:12 -0500 Subject: Internet blocked in Algeria? Message-ID: Any confirmation of internet blocking? http://bikyamasr.com/wordpress/?p=26849 As massive street demonstrations are met with widespread violence in Algeria, the country is reporting that many Facebook accounts have been deleted or blocked by the government, in an effort to stifle protests against President Abdelaziz Boutifleka, activists on Twitter reported around midday in the country. They also said that the government is working fast to cut off all Internet providers in the country. -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org --------------------------------------------------------------- From smb at cs.columbia.edu Sat Feb 12 16:44:03 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Sat, 12 Feb 2011 17:44:03 -0500 Subject: US Warships jamming Lebanon Internet In-Reply-To: <73b1fdd4629c62e4cc48070f2825596f@visp.net.lb> References: "\"<201102081359.39100.denys@visp.net.lb>" <201102081434.38609.denys@visp.net.lb>" <052C3BF4-13C9-4AE1-BF5E-DC5AF16179C7@oitc.com> <201102081541.23651.denys@visp.net.lb> <4D51911A.2060008@brightok.net> <73b1fdd4629c62e4cc48070f2825596f@visp.net.lb> Message-ID: On Feb 12, 2011, at 4:05 41PM, denys at visp.net.lb wrote: > On Tue, 08 Feb 2011 12:53:14 -0600, Jack Bates wrote: >> On 2/8/2011 7:41 AM, Denys Fedoryshchenko wrote: >>> It is PLL LNB, one carrier, we are using full transponder 36 Mhz. There is >>> almost no other users on this satellite (inclined more than 1.5 degree), and >>> other carriers center frequency 100Mhz away. >>> >> >> Since no one else will, "I blame solar flares!" >> >> >> Jack > > I am monitoring solar activity, getting info from NOAA. No correlation. > Your suspicion may be accurate and accidental. I rented a car in San Diego the other day -- there was a sign warning that the key fob might not work within 5 miles of the port -- San Diego has a major Navy base -- because of interference from shipboard electronics. --Steve Bellovin, http://www.cs.columbia.edu/~smb From jg at freedesktop.org Sat Feb 12 16:51:00 2011 From: jg at freedesktop.org (Jim Gettys) Date: Sat, 12 Feb 2011 17:51:00 -0500 Subject: [v6z] Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <5A6D953473350C4B9995546AFE9939EE0BC13A5A@RWC-EX1.corp.seven.com> <76284.1297463617@localhost> <201102121226.32079.lowen@pari.edu> Message-ID: <4D570ED4.6010201@freedesktop.org> On 02/12/2011 02:32 PM, Scott Howard wrote: > On Sat, Feb 12, 2011 at 9:26 AM, Lamar Owen wrote: > >> While I have a few WRT54G's lying around, I've never tried IPv6 on them, >> and would find it interesting if anyone has. >> > > I used a WRT54G running DD-WRT for some time with a HE IPv6 tunnel (now > replaced with a Cisco 877, but not due to any failing of the Linksys/DD-WRT) > > IPv6 support is actually broken in the latest version of DD-WRT, and it's > been that way for some time (measured in years), however with some hacking > you can get it to work. It's not at all user friendly, and definitely not > consumer ready, but once it's working it's pretty much rock solid. > > All up I'd say I probably spent less time getting IPv6 working on DD-WRT > than on my Cisco 877W (Hint: IOS 12.x doesn't support IPv6 on the bridge > interface, the IOS 15.x Advanced Security feature set doesn't support IPv6 > at all, and the flash requirements listed for 15.1 Advanced IP are wrong. Go > Cisco!) > > Keep in mind that not all WRT54G's support DD-WRT. Linksys moved from Linux > to Vxworks but kept the model number the same (the version did change). The > WRT54GL along with various other devices do support it - details are on the > DD-WRT website. > OpenWRT will run IPv6 fine; Comcast posted patches some months back to enable some 6rd configuration mods needed for Comcast's IPv6 trial. From the Comcast beta forum, it's clear that some people have succeeded at merging those 6rd patches into OpenWRT, though there may be some rough edges. I haven't had time to take them for a spin. - Jim From denys at visp.net.lb Sat Feb 12 16:55:42 2011 From: denys at visp.net.lb (denys at visp.net.lb) Date: Sun, 13 Feb 2011 00:55:42 +0200 Subject: US Warships jamming Lebanon Internet In-Reply-To: References: "\"\\\"\\\\\\\"<201102081359.39100.denys@visp.net.lb>\\\"<201102081434.38609.denys@visp.net.lb>\\\"<052C3BF4-13C9-4AE1-BF5E-DC5AF16179C7@oitc.com><201102081541.23651.denys@visp.net.lb> <4D51911A.2060008@brightok.net>" <73b1fdd4629c62e4cc48070f2825596f@visp.net.lb>" Message-ID: On Sat, 12 Feb 2011 11:39:59 -1000, Michael Painter wrote: > denys at visp.net.lb wrote: >> On Tue, 08 Feb 2011 12:53:14 -0600, Jack Bates wrote: >>> On 2/8/2011 7:41 AM, Denys Fedoryshchenko wrote: >>>> It is PLL LNB, one carrier, we are using full transponder 36 Mhz. >>>> There is >>>> almost no other users on this satellite (inclined more than 1.5 >>>> degree), and >>>> other carriers center frequency 100Mhz away. >>>> >>> Since no one else will, "I blame solar flares!" >>> >>> Jack >> I am monitoring solar activity, getting info from NOAA. No >> correlation. > > Have you been able to get any assistance from the uplink/teleport noc > or the satellite operator? Yes, for sure. Satellite operator doesn't provide much help, but uplink proposed for us some plan to solve all this issues. Already we implement temporary solution, and things at least stable now, plus it seems interference is lower somehow few last days. From mikea at mikea.ath.cx Sat Feb 12 17:05:35 2011 From: mikea at mikea.ath.cx (mikea) Date: Sat, 12 Feb 2011 17:05:35 -0600 Subject: Internet blocked in Algeria? In-Reply-To: References: Message-ID: <20110212230535.GA98070@mikea.ath.cx> On Sat, Feb 12, 2011 at 05:01:12PM -0500, Joly MacFie wrote: > Any confirmation of internet blocking? > > http://bikyamasr.com/wordpress/?p=26849 > > As massive street demonstrations are met with widespread violence in > Algeria, the country is reporting that many Facebook accounts have been > deleted or blocked by the government, in an effort to stifle protests > against President Abdelaziz Boutifleka, activists on Twitter reported around > midday in the country. > They also said that the government is working fast to cut off all Internet > providers in the country. At least some websites, though not all of them, that are linked off seem to be working OK. I grant they're all government, but they're up and serving requests. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From cowie at renesys.com Sat Feb 12 17:20:39 2011 From: cowie at renesys.com (Jim Cowie) Date: Sat, 12 Feb 2011 18:20:39 -0500 Subject: Internet blocked in Algeria? In-Reply-To: <20110212230535.GA98070@mikea.ath.cx> References: <20110212230535.GA98070@mikea.ath.cx> Message-ID: On Sat, Feb 12, 2011 at 6:05 PM, mikea wrote: > On Sat, Feb 12, 2011 at 05:01:12PM -0500, Joly MacFie wrote: >> Any confirmation of internet blocking? >> >> http://bikyamasr.com/wordpress/?p=26849 >> >> As massive street demonstrations are met with widespread violence in >> Algeria, the country is reporting that many Facebook accounts have been >> deleted or blocked by the government, in an effort to stifle protests >> against President Abdelaziz Boutifleka, activists on Twitter reported around >> midday in the country. >> They also said that the government is working fast to cut off all Internet >> providers in the country. > > At least some websites, though not all of them, that are linked off > > seem to be working OK. I grant they're all government, but they're up > and serving requests. > Looks up to us, with the exception of a few websites. Routes stable, inbound traceroutes unremarkable, lots and lots of DZ-hosted content available. http://www.renesys.com/blog/2011/02/watching-algeria.shtml best, --jim From brandon.kim at brandontek.com Sat Feb 12 17:42:20 2011 From: brandon.kim at brandontek.com (Brandon Kim) Date: Sat, 12 Feb 2011 18:42:20 -0500 Subject: SmartNet Alternatives In-Reply-To: <6EFFEFBAC68377459A2E972105C759EC036456FC@EXVBE005-2.exch005intermedia.net> References: <060EDFC2221B014B9504AC06B747F58A499BCC3B57@ex01.alentus.lan>, , <6EFFEFBAC68377459A2E972105C759EC036456FC@EXVBE005-2.exch005intermedia.net> Message-ID: Sometimes you have to pick your battles. I'm sure there's a number cruncher somewhere telling Cisco this is a good idea. Let's see how the real world reacts though.... > Subject: RE: SmartNet Alternatives > Date: Sat, 12 Feb 2011 13:33:32 -0800 > From: ryan.finnesey at HarrierInvestments.com > To: nanog at nanog.org > CC: JMacleod at alentus.com > > This is one of the reasons we are starting to look at Juniper for a new network build. It is my understanding we set software updates for life for free. > Cheers > Ryan > > > -----Original Message----- > From: Michael Loftis [mailto:mloftis at wgops.com] > Sent: Friday, February 11, 2011 4:27 PM > To: John Macleod > Cc: nanog at nanog.org > Subject: Re: SmartNet Alternatives > > Cisco is making noises that they'll eventually be restricting software access to ONLY those devices which have an active SmartNet contract associated to your CCO account. I don't know where this currently stands, and it sure will be a huge pain in my rear if/when it happens. > > On Fri, Feb 11, 2011 at 1:41 PM, John Macleod wrote: > > Just interested in other peoples experience to companies offering alternatives to SmartNet? > > > > Pros/Cons/Tradeoffs? > > > > We currently have a mix of SmartNet and internal parts supply. > > > > John > > > > > > __ > > John Macleod > > Alentus UK Limited > > Seymour House > > South Street > > Bromley > > BR1 1RH > > +44 (0)208 315 5800 > > +44 (0)208 315 5801 fax > > alentus.co.uk | alentus.com > > > > "Please consider the environment before printing this e-mail > > > > This e-mail (and/or any attachment) contains information, which is confidential and intended solely for the attention and use of the named addressee(s). If you are not the intended recipient you must not copy, distribute or use it for any purpose or disclose the contents to any person. If you have received this e-mail in error, please immediately notify the sender. The information contained in this e-mail (and any attachments) is supplied in good faith, but the sender shall not be under any liability in damages or otherwise for any reliance that may be placed upon it by the recipient, nor does it constitute a contract in any way. Any comments or opinions expressed are those of the originator not of Alentus Corporation unless otherwise expressly stated." > > > > > > From joly at punkcast.com Sat Feb 12 18:57:13 2011 From: joly at punkcast.com (Joly MacFie) Date: Sat, 12 Feb 2011 19:57:13 -0500 Subject: Internet blocked in Algeria? In-Reply-To: References: <20110212230535.GA98070@mikea.ath.cx> Message-ID: Thanks, I wonder if the fb messing is filtering or a repeat of the Tunisian password stealing gambit? I guess time will tell. I know fb implemented countrywide https as a workaround in that case. j On Sat, Feb 12, 2011 at 6:20 PM, Jim Cowie wrote: > On Sat, Feb 12, 2011 at 6:05 PM, mikea wrote: > > On Sat, Feb 12, 2011 at 05:01:12PM -0500, Joly MacFie wrote: > >> Any confirmation of internet blocking? > >> > >> http://bikyamasr.com/wordpress/?p=26849 > >> > >> As massive street demonstrations are met with widespread violence in > >> Algeria, the country is reporting that many Facebook accounts have been > >> deleted or blocked by the government, in an effort to stifle protests > >> against President Abdelaziz Boutifleka, activists on Twitter reported > around > >> midday in the country. > >> They also said that the government is working fast to cut off all > Internet > >> providers in the country. > > > > At least some websites, though not all of them, that are linked off > > > > seem to be working OK. I grant they're all government, but they're up > > and serving requests. > > > > Looks up to us, with the exception of a few websites. Routes stable, > inbound traceroutes unremarkable, lots and lots of DZ-hosted content > available. > > http://www.renesys.com/blog/2011/02/watching-algeria.shtml > > best, --jim > > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org --------------------------------------------------------------- From alejandroacostaalamo at gmail.com Sat Feb 12 19:08:56 2011 From: alejandroacostaalamo at gmail.com (Alejandro Acosta) Date: Sun, 13 Feb 2011 01:08:56 +0000 Subject: SmartNet Alternatives Message-ID: <4d572fb6.460ae30a.5c25.293c@mx.google.com> Right, pretty good idea to look for other altermatives, few years ago I wouldn't agree, however my feeling says that Cisco competetitors have grown a lot, AAA-, -----Mensaje original----- De: Ryan Finnesey Enviados: 12/02/2011 17:03:32 Para: nanog at nanog.org Cc: John Macleod Asunto: RE: SmartNet Alternatives This is one of the reasons we are starting to look at Juniper for a new network build. It is my understanding we set software updates for life for free. Cheers Ryan -----Original Message----- From: Michael Loftis [mailto:mloftis at wgops.com] Sent: Friday, February 11, 2011 4:27 PM To: John Macleod Cc: nanog at nanog.org Subject: Re: SmartNet Alternatives Cisco is making noises that they'll eventually be restricting software access to ONLY those devices which have an active SmartNet contract associated to your CCO account. I don't know where this currently stands, and it sure will be a huge pain in my rear if/when it happens. On Fri, Feb 11, 2011 at 1:41 PM, John Macleod wrote: > Just interested in other peoples experience to companies offering alternatives to SmartNet? > > Pros/Cons/Tradeoffs? > > We currently have a mix of SmartNet and internal parts supply. > > John > > > __ > John Macleod > Alentus UK Limited > Seymour House > South Street > Bromley > BR1 1RH > ?+44 (0)208 315 5800 > ?+44 (0)208 315 5801 fax > alentus.co.uk ?| ?alentus.com > > "Please consider the environment before printing this e-mail > > This e-mail (and/or any attachment) contains information, which is confidential and intended solely for the attention and use of the named addressee(s). If you are not the intended recipient you must not copy, distribute or use it for any purpose or disclose the contents to any person. If you have received this e-mail in error, please immediately notify the sender. The information contained in this e-mail (and any attachments) is supplied in good faith, but the sender shall not be under any liability in damages or otherwise for any reliance that may be placed upon it by the recipient, nor does it constitute a contract in any way. Any comments or opinions expressed are those of the originator not of Alentus Corporation unless otherwise expressly stated." > > From sethm at rollernet.us Sat Feb 12 19:49:24 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 12 Feb 2011 17:49:24 -0800 Subject: SmartNet Alternatives In-Reply-To: <6EFFEFBAC68377459A2E972105C759EC036456FC@EXVBE005-2.exch005intermedia.net> References: <060EDFC2221B014B9504AC06B747F58A499BCC3B57@ex01.alentus.lan> <6EFFEFBAC68377459A2E972105C759EC036456FC@EXVBE005-2.exch005intermedia.net> Message-ID: <4D5738A4.3070005@rollernet.us> On 2/12/2011 13:33, Ryan Finnesey wrote: > This is one of the reasons we are starting to look at Juniper for a new network build. It is my understanding we set software updates for life for free. > Cheers > Ryan > How does Juniper feel about used hardware? ~Seth From lee at asgard.org Sat Feb 12 20:03:41 2011 From: lee at asgard.org (Lee Howard) Date: Sat, 12 Feb 2011 21:03:41 -0500 Subject: IPv6 is on the marketers radar In-Reply-To: References: <33020353.1007.1297454809458.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <000901cbcb22$3cf978a0$b6ec69e0$@org> > -----Original Message----- > From: Geert Bosch [mailto:bosch at adacore.com] > > Honestly, I can't quite see the big deal for home users. I'm using > an Apple Airport Extreme, and setting it up with a IPv6 tunnel from $150? That's a high-powered device compared to most home gateways. > HE was quite straightforward. Sure, I don't expect the average user > to go through these steps, but they could easily be automated and > rolled out as part of a firmware update (which is a routine matter Yes, if the ISP provided the gateway. In many markets, they don't. Even if they start now, they would have to convince every customer to swap routers. And find the capital to pay for them. And have a system for updating the firmware and configurations of those devices. Or maybe the customer's going to have to buy a new gateway, when the one they have is still functioning, and might even be brand new. > the foreseeable future, people will have (NATed or not) IPv4 > connectivity, so content providers are fine without IPv6. Depends on the content. Large-scale NAT is bad for you if you depend on IP geo-location, or use anti-DDOS measures to limit number of connections or bits from a single IP address, or use IP address to report abuse, or blacklist IP addresses, or log the user's IP address, or try to enforce copyright by reporting IP addresses of violators, or rate-limit outbound data per address, or record unique visitors by IP address. It might also increase latency, but probably not so much that you'd panic. Except for the most basic, static of websites, content providers are going to prefer IPv6 over IPv4. I don't know whether web hosting companies will ever automatically dual-stack the PTA's website, but at some point it will be easier for them to warn all their customers and just do it, than to track which customers asked for IPv6 explicitly. > So, I think we'll transition to a situation where for some purposes > (Skype, gaming, file-sharing) there will be a benefit for (tunneled) > IPv6 compared to (NATed) IPv4, but for simple content providers > there will still be no incentive to leave IPv4. . . . > Again, it seems it is far easier to deal with the relatively > homogeneous base of users for IPv6, compared to the fragmented and > irregular market of content providers. That sounds heterogenous: web-browsing-only users, and peer-to-peer-application-using users. Lee From tme at americafree.tv Sat Feb 12 20:26:20 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Sat, 12 Feb 2011 21:26:20 -0500 Subject: Internet blocked in Algeria? In-Reply-To: References: <20110212230535.GA98070@mikea.ath.cx> Message-ID: <5D673CBE-363D-4B14-9763-CB69D71B2322@americafree.tv> On Feb 12, 2011, at 6:20 PM, Jim Cowie wrote: > On Sat, Feb 12, 2011 at 6:05 PM, mikea wrote: >> On Sat, Feb 12, 2011 at 05:01:12PM -0500, Joly MacFie wrote: >>> Any confirmation of internet blocking? >>> >>> http://bikyamasr.com/wordpress/?p=26849 >>> >>> As massive street demonstrations are met with widespread violence in >>> Algeria, the country is reporting that many Facebook accounts have been >>> deleted or blocked by the government, in an effort to stifle protests >>> against President Abdelaziz Boutifleka, activists on Twitter reported around >>> midday in the country. >>> They also said that the government is working fast to cut off all Internet >>> providers in the country. >> >> At least some websites, though not all of them, that are linked off >> >> seem to be working OK. I grant they're all government, but they're up >> and serving requests. >> > > Looks up to us, with the exception of a few websites. Routes stable, > inbound traceroutes unremarkable, lots and lots of DZ-hosted content > available. > > http://www.renesys.com/blog/2011/02/watching-algeria.shtml > I have received several reports of Twitter and Facebook outages in Algeria, but not general Internet blockage. The Telegraph has this report or http://bit.ly/f97OmX which talks vaguely of Internet outages. On the other side of both the coin and the world, there is this http://knightcenter.utexas.edu/blog/bloggers-celebrate-cuba-unblocks-their-sites "Bloggers celebrate as Cuba unblocks their site" Maybe this is connected to the new fiber optic cable to Venezuela, it seems to have caught everyone by surprise. Regards Marshall > best, --jim > > From danny at spesh.com Sat Feb 12 20:27:15 2011 From: danny at spesh.com (Danny O'Brien) Date: Sun, 13 Feb 2011 09:27:15 +0700 Subject: Internet blocked in Algeria? In-Reply-To: References: Message-ID: On Sun, Feb 13, 2011 at 5:01 AM, Joly MacFie wrote: > Any confirmation of internet blocking? > > http://bikyamasr.com/wordpress/?p=26849 > > As massive street demonstrations are met with widespread violence in > Algeria, the country is reporting that many Facebook accounts have been > deleted or blocked by the government, in an effort to stifle protests > against President Abdelaziz Boutifleka, activists on Twitter reported > around > midday in the country. > They also said that the government is working fast to cut off all Internet > providers in the country. > I've had no reports, apart from unreliable third-hand sources (and only one in Arabic). Most of them seeming to be just echoing a very vague report in the UK's Daily Telegraph. Also I'm sceptical of the combination of "Internet shut down" and "Facebook pages deleted" in all of these reports. Those are two very different acts and, while if you are worried about such things (Egypt did the former, Tunisia did the latter), they aren't part of the some giant lever that a government pulls. I suspect people are just jittery in Algiers today. d. > > > > -- > --------------------------------------------------------------- > Joly MacFie 218 565 9365 Skype:punkcast > WWWhatsup NYC - http://wwwhatsup.com > http://pinstand.com - http://punkcast.com > VP (Admin) - ISOC-NY - http://isoc-ny.org > --------------------------------------------------------------- > > From jared at puck.nether.net Sat Feb 12 20:32:29 2011 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 12 Feb 2011 21:32:29 -0500 Subject: Internet blocked in Algeria? In-Reply-To: <5D673CBE-363D-4B14-9763-CB69D71B2322@americafree.tv> References: <20110212230535.GA98070@mikea.ath.cx> <5D673CBE-363D-4B14-9763-CB69D71B2322@americafree.tv> Message-ID: <17BF953F-534A-4689-83A0-AAD8D296E8E8@puck.nether.net> On Feb 12, 2011, at 9:26 PM, Marshall Eubanks wrote: > Maybe this is connected to the new fiber optic cable to Venezuela, it seems to have caught everyone by surprise. I believe the cable was landed, but not actually lit yet. That's set for later this year based on what I recall from that cable landing. - Jared (looking forward for the day there are 10Gs lit to Cuba) From tme at americafree.tv Sat Feb 12 20:58:22 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Sat, 12 Feb 2011 21:58:22 -0500 Subject: US Warships jamming Lebanon Internet In-Reply-To: References: "\"\\\"\\\\\\\"<201102081359.39100.denys@visp.net.lb>\\\"<201102081434.38609.denys@visp.net.lb>\\\"<052C3BF4-13C9-4AE1-BF5E-DC5AF16179C7@oitc.com><201102081541.23651.denys@visp.net.lb> <4D51911A.2060008@brightok.net>" <73b1fdd4629c62e4cc48070f2825596f@visp.net.lb>" Message-ID: On Feb 12, 2011, at 5:55 PM, denys at visp.net.lb wrote: > On Sat, 12 Feb 2011 11:39:59 -1000, Michael Painter wrote: >> denys at visp.net.lb wrote: >>> On Tue, 08 Feb 2011 12:53:14 -0600, Jack Bates wrote: >>>> On 2/8/2011 7:41 AM, Denys Fedoryshchenko wrote: >>>>> It is PLL LNB, one carrier, we are using full transponder 36 Mhz. >>>>> There is >>>>> almost no other users on this satellite (inclined more than 1.5 >>>>> degree), and >>>>> other carriers center frequency 100Mhz away. >>>>> >>>> Since no one else will, "I blame solar flares!" >>>> >>>> Jack >>> I am monitoring solar activity, getting info from NOAA. No correlation. >> >> Have you been able to get any assistance from the uplink/teleport noc >> or the satellite operator? > Yes, for sure. > Satellite operator doesn't provide much help, but uplink proposed for us some plan to solve all this issues. > Already we implement temporary solution, and things at least stable now, plus it seems interference is lower somehow few last days. > > Here is a dumb idea that I have actually seen cause problems : Is it possible that the declination of the satellite from your location is the same as the Sun right now ? That will cause up to several hours of interruption every mid-day. The clue is that the shadow of the receiver box is in the center of the dish (for prime focus mounts). You might be surprised how many times this has caught people, so I thought I would mention it. Regards Marshall > From bosch at adacore.com Sat Feb 12 21:34:21 2011 From: bosch at adacore.com (Geert Bosch) Date: Sat, 12 Feb 2011 22:34:21 -0500 Subject: IPv6 is on the marketers radar In-Reply-To: <000901cbcb22$3cf978a0$b6ec69e0$@org> References: <33020353.1007.1297454809458.JavaMail.franck@franck-martins-macbook-pro.local> <000901cbcb22$3cf978a0$b6ec69e0$@org> Message-ID: <8B082D10-A0EA-4012-8656-E60DD7EC76D0@adacore.com> On Feb 12, 2011, at 21:03, Lee Howard wrote: >> Honestly, I can't quite see the big deal for home users. I'm using >> an Apple Airport Extreme, and setting it up with a IPv6 tunnel from > > $150? That's a high-powered device compared to most home gateways. Sure, but the same thing is possible with a cheap 6-year-old sub-$50 popular Linksys wifi router, see http://opensystems.wordpress.com/2006/06/01/linksys-wrt54g-ipv6-howto/ for example. The point is that it can be cheap, relatively easy and painless for users to upgrade. Basically, it should not have to cost anything extra to set up new users for IPv6. The same hardware that handles IPv4 today can be programmed to do IPv6. >> the foreseeable future, people will have (NATed or not) IPv4 >> connectivity, so content providers are fine without IPv6. > > Depends on the content. Large-scale NAT is bad for you if you > depend on IP geo-location, or use anti-DDOS measures to limit > number of connections or bits from a single IP address, or use > IP address to report abuse, or blacklist IP addresses, or log the > user's IP address, or try to enforce copyright by reporting IP > addresses of violators, or rate-limit outbound data per address, > or record unique visitors by IP address. > It might als > o increase latency, but probably not so much that > you'd panic. Users don't care about IP geo-location or anti-DDOS measures, or any of the other reasons you list. These are things content providers care about, but they don't get to choose wether their viewers use IPv4 or IPv6. > Except for the most basic, static of websites, content providers > are going to prefer IPv6 over IPv4. I don't know whether web > hosting companies will ever automatically dual-stack the PTA's > website, but at some point it will be easier for them to warn all > their customers and just do it, than to track which customers > asked for IPv6 explicitly. As long as a majority of users come over IPv4, better anti-DDOS measures or anti-abuse procedures for IPv6 are not going to make any difference. "When you DOS my site, please use IPv6, so we can better find out your location and more effectively block your IP address." Users are going to drive adoption of IPv6, if and when they find a "killer-app" where IPv6 can provide usability that (heavily NATed) IPv4 can't. This could be better file-sharing tools, lower latency online gaming, better long-distance video-calling or whatever, as long as the benefits will be worth the relatively small (<$50) investment of money and time. For content providers, as long as 90+% of the net is IPv4 only and essentially nobody is IPv6 only, providing dual-stack support is just adding cost for little or no gain in viewership. Content providers often depend on dozens if not hundreds of pieces of hardware and software to provider their services, so supporting IPv6 is vastly most expensive than it is for users to take advantage of it. In my case, the upgrade to IPv6 was free. There must be many more using an Apple router (any model, Express, Extreme or otherwise) that can upgrade to IPv6 for free. However, I can't list any benefit from doing so, except from going to test-ipv6.com and seeing a 10/10 score. Basically, you have to be a geek to be interested in IPv6. That's got to change, before there will be any meaningful shifts. -Geert From bfeeny at mac.com Sat Feb 12 22:00:46 2011 From: bfeeny at mac.com (Brian Feeny) Date: Sat, 12 Feb 2011 23:00:46 -0500 Subject: Old Annex question Message-ID: <8FCED5CE-7FB8-459C-AE55-BBF2B57CDD7F@mac.com> Sad but true, I still have a few of these in operation as terminal servers. In reading the documentation I could find it wasn't clear to me how to solve my issue. I use these to manage Cisco routers. How can I connect to a server, and then drop back to the CLI, so I can then connect to another server, and keep switching back and forth? I thought I could just set the attn_string to say "^A" and then I could just hit that and it would work, but it doesn't seem to. I basically want to emulate the same functionality you can get when you do ^^x on a Cisco terminal server (2509/2511/etc). here is how its configured right now: %rotary host1: 1 at 172.16.1.10 host2: 2 at 172.16.1.10 host3: 3 at 172.16.1.10 %gateway annex 172.16.1.10 net default gateway 172.16.1.1 metric 1 hardwired end So I connect to my annex by telnetting to 172.16.1.10, then I type say host1, but I want to drop back to the CLI, any ideas how to escape to CLI once connected? I figured that since many of you are from my same era and these were popular with ISP's of the day, someone here may know...... Brian From randy at psg.com Sat Feb 12 22:11:42 2011 From: randy at psg.com (Randy Bush) Date: Sat, 12 Feb 2011 20:11:42 -0800 Subject: US Warships jamming Lebanon Internet In-Reply-To: References: <201102081434.38609.denys@visp.net.lb> Message-ID: > Your suspicion may be accurate and accidental. I rented a car in San > Diego the other day -- there was a sign warning that the key fob might > not work within 5 miles of the port -- San Diego has a major Navy base > -- because of interference from shipboard electronics. same time, my phone's gps claimed accuracy to 700m in the 10 miles from san diego airport. that is not a lot of good for nav. luckily i used to hang down there in the late '70s and early '80s so kinda knew my way around. randy From jna at retina.net Sat Feb 12 22:17:10 2011 From: jna at retina.net (John Adams) Date: Sat, 12 Feb 2011 20:17:10 -0800 Subject: Old Annex question In-Reply-To: <8FCED5CE-7FB8-459C-AE55-BBF2B57CDD7F@mac.com> References: <8FCED5CE-7FB8-459C-AE55-BBF2B57CDD7F@mac.com> Message-ID: I remember maintaining a fleet of these back in the day. I believe it's just the standard escape character Ctrl-] ? Maybe this document helps? http://www.marine.csiro.au/~dpg/sysManDocs/annex_man.pdf -j On Sat, Feb 12, 2011 at 8:00 PM, Brian Feeny wrote: > > Sad but true, I still have a few of these in operation as terminal servers. ?In reading the documentation I could find it wasn't clear to me how to solve my issue. ?I use these to manage Cisco routers. > > How can I connect to a server, and then drop back to the CLI, so I can then connect to another server, and keep switching back and forth? ?I thought I could just set the attn_string to say "^A" and then I could just hit that and it would work, but it doesn't seem to. ?I basically want to emulate the same functionality you can get when you do ^^x on a Cisco terminal server (2509/2511/etc). > > here is how its configured right now: > > %rotary > host1: ? ? ? ? ? ? ? ? ? ? ? ? ?1 at 172.16.1.10 > host2: ? ? ? ? ? ? ? ? ? ? ? ? ?2 at 172.16.1.10 > host3: ? ? ? ? ? ? ? ? ? ? ? ? ?3 at 172.16.1.10 > %gateway > annex 172.16.1.10 > net default gateway 172.16.1.1 metric 1 hardwired > end > > So I connect to my annex by telnetting to 172.16.1.10, then I type say host1, but I want to drop back to the CLI, any ideas how to escape to CLI once connected? > > I figured that since many of you are from my same era and these were popular with ISP's of the day, someone here may know...... > > Brian > > > From smb at cs.columbia.edu Sat Feb 12 22:24:59 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Sat, 12 Feb 2011 23:24:59 -0500 Subject: US Warships jamming Lebanon Internet In-Reply-To: References: <201102081434.38609.denys@visp.net.lb> Message-ID: <06733F9A-633D-420A-B2D8-D12D553FB5C0@cs.columbia.edu> On Feb 12, 2011, at 11:11 42PM, Randy Bush wrote: >> Your suspicion may be accurate and accidental. I rented a car in San >> Diego the other day -- there was a sign warning that the key fob might >> not work within 5 miles of the port -- San Diego has a major Navy base >> -- because of interference from shipboard electronics. > > same time, my phone's gps claimed accuracy to 700m in the 10 miles from > san diego airport. that is not a lot of good for nav. luckily i used > to hang down there in the late '70s and early '80s so kinda knew my way > around. > That sounds like it didn't have a GPS fix at all, and was instead using cell site proximity location. (I didn't check my phone's GPS; my Garmin unit had no trouble.) --Steve Bellovin, http://www.cs.columbia.edu/~smb From mloftis at wgops.com Sat Feb 12 22:50:24 2011 From: mloftis at wgops.com (Michael Loftis) Date: Sat, 12 Feb 2011 21:50:24 -0700 Subject: Old Annex question In-Reply-To: <8FCED5CE-7FB8-459C-AE55-BBF2B57CDD7F@mac.com> References: <8FCED5CE-7FB8-459C-AE55-BBF2B57CDD7F@mac.com> Message-ID: Never used those but on some gear from that era it had to.be repeated 3x like the Hayes +++ attention sequence. On Feb 12, 2011 9:02 PM, "Brian Feeny" wrote: > > Sad but true, I still have a few of these in operation as terminal servers. In reading the documentation I could find it wasn't clear to me how to solve my issue. I use these to manage Cisco routers. > > How can I connect to a server, and then drop back to the CLI, so I can then connect to another server, and keep switching back and forth? I thought I could just set the attn_string to say "^A" and then I could just hit that and it would work, but it doesn't seem to. I basically want to emulate the same functionality you can get when you do ^^x on a Cisco terminal server (2509/2511/etc). > > here is how its configured right now: > > %rotary > host1: 1 at 172.16.1.10 > host2: 2 at 172.16.1.10 > host3: 3 at 172.16.1.10 > %gateway > annex 172.16.1.10 > net default gateway 172.16.1.1 metric 1 hardwired > end > > So I connect to my annex by telnetting to 172.16.1.10, then I type say host1, but I want to drop back to the CLI, any ideas how to escape to CLI once connected? > > I figured that since many of you are from my same era and these were popular with ISP's of the day, someone here may know...... > > Brian > > From perkonis2000 at gmail.com Sun Feb 13 01:44:19 2011 From: perkonis2000 at gmail.com (Mike Perkins) Date: Sun, 13 Feb 2011 02:44:19 -0500 Subject: No subject Message-ID: <839CC12C-9ED7-46B9-BF4D-E0D3B74F203D@gmail.com> Sent from my iPhone. I blame all misspellings on the autocorrect. From Skeeve at eintellego.net Sun Feb 13 01:53:43 2011 From: Skeeve at eintellego.net (Skeeve Stevens) Date: Sun, 13 Feb 2011 18:53:43 +1100 Subject: SmartNet Alternatives In-Reply-To: <4D5738A4.3070005@rollernet.us> Message-ID: Interesting Question... And do they consider the JUNOS included a separate item? Or can it happily be sold with the hardware. Juniper will have a couple of years before it has to worry about a refurb market like Cisco has - especially in volume. ...Skeeve -- Skeeve Stevens, CEO eintellego Pty Ltd - The Networking Specialists skeeve at eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- eintellego - The Experts that the Experts call - Juniper - HP Networking - Cisco - Brocade - Arista - Allied Telesis -----Original Message----- From: Seth Mattinen Date: Sun, 13 Feb 2011 12:49:24 +1100 To: "nanog at nanog.org" Subject: Re: SmartNet Alternatives >On 2/12/2011 13:33, Ryan Finnesey wrote: >> This is one of the reasons we are starting to look at Juniper for a new >>network build. It is my understanding we set software updates for life >>for free. >> Cheers >> Ryan >> > > >How does Juniper feel about used hardware? > >~Seth > From Skeeve at eintellego.net Sun Feb 13 01:57:03 2011 From: Skeeve at eintellego.net (Skeeve Stevens) Date: Sun, 13 Feb 2011 18:57:03 +1100 Subject: SmartNet Alternatives In-Reply-To: <20110212204636.GA27845@srv03.cluenet.de> Message-ID: Different rules for different countries. Can't buy CON-SW from Australian distributors (I've tried 3), but I can buy it from the UK with support for Australia. ...Skeeve -- Skeeve Stevens, CEO eintellego Pty Ltd - The Networking Specialists skeeve at eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- eintellego - The Experts that the Experts call - Juniper - HP Networking - Cisco - Brocade - Arista - Allied Telesis -----Original Message----- From: Daniel Roesen Date: Sun, 13 Feb 2011 07:46:36 +1100 To: "nanog at nanog.org" Subject: Re: SmartNet Alternatives >On Fri, Feb 11, 2011 at 04:49:55PM -0500, Andrey Khomyakov wrote: >> If only Cisco would sell "software only" support. > >They do. You might have to make your sales droid know that YOU know >about it thought. :-) > >Order items were CON-SW-... in the past, not sure about today. > > >Best regards, >Daniel > >-- >CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 > From Skeeve at eintellego.net Sun Feb 13 01:59:11 2011 From: Skeeve at eintellego.net (Skeeve Stevens) Date: Sun, 13 Feb 2011 18:59:11 +1100 Subject: SmartNet Alternatives In-Reply-To: Message-ID: Started a few weeks ago for us. ...Skeeve -- Skeeve Stevens, CEO eintellego Pty Ltd - The Networking Specialists skeeve at eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- eintellego - The Experts that the Experts call - Juniper - HP Networking - Cisco - Brocade - Arista - Allied Telesis -----Original Message----- From: Michael Loftis Date: Sat, 12 Feb 2011 08:26:56 +1100 To: John Macleod Cc: "nanog at nanog.org" Subject: Re: SmartNet Alternatives >Cisco is making noises that they'll eventually be restricting software >access to ONLY those devices which have an active SmartNet contract >associated to your CCO account. I don't know where this currently >stands, and it sure will be a huge pain in my rear if/when it happens. > >On Fri, Feb 11, 2011 at 1:41 PM, John Macleod >wrote: >> Just interested in other peoples experience to companies offering >>alternatives to SmartNet? >> >> Pros/Cons/Tradeoffs? >> >> We currently have a mix of SmartNet and internal parts supply. >> >> John >> >> >> __ >> John Macleod >> Alentus UK Limited >> Seymour House >> South Street >> Bromley >> BR1 1RH >> +44 (0)208 315 5800 >> +44 (0)208 315 5801 fax >> alentus.co.uk | alentus.com >> >> "Please consider the environment before printing this e-mail >> >> This e-mail (and/or any attachment) contains information, which is >>confidential and intended solely for the attention and use of the named >>addressee(s). If you are not the intended recipient you must not copy, >>distribute or use it for any purpose or disclose the contents to any >>person. If you have received this e-mail in error, please immediately >>notify the sender. The information contained in this e-mail (and any >>attachments) is supplied in good faith, but the sender shall not be >>under any liability in damages or otherwise for any reliance that may be >>placed upon it by the recipient, nor does it constitute a contract in >>any way. Any comments or opinions expressed are those of the originator >>not of Alentus Corporation unless otherwise expressly stated." >> >> > From lee at asgard.org Sun Feb 13 09:22:47 2011 From: lee at asgard.org (Lee Howard) Date: Sun, 13 Feb 2011 10:22:47 -0500 Subject: IPv6 is on the marketers radar In-Reply-To: <8B082D10-A0EA-4012-8656-E60DD7EC76D0@adacore.com> References: <33020353.1007.1297454809458.JavaMail.franck@franck-martins-macbook-pro.local> <000901cbcb22$3cf978a0$b6ec69e0$@org> <8B082D10-A0EA-4012-8656-E60DD7EC76D0@adacore.com> Message-ID: <001001cbcb91$deb34c60$9c19e520$@org> > From: Geert Bosch [mailto:bosch at adacore.com] > Basically, it should not have to cost anything extra to set up > new users for IPv6. The same hardware that handles IPv4 today > can be programmed to do IPv6. That is not the case for a significant number of home gateways and other consumer electronics. This is a market where a few dollars saved in flash or RAM means market share or profitability. Only in high-end gateways is there capacity for IPv6 (see the plans from Linksys, Netgear). You can argue about whether this "should" be true, but the manufacturers say they can't add IPv6 to the current low-end gateways. > >> the foreseeable future, people will have (NATed or not) IPv4 > >> connectivity, so content providers are fine without IPv6. > > [why content providers hate NAT and will dual-stack] > Users don't care about IP geo-location or anti-DDOS measures, or > any of the other reasons you list. These are things content providers > care about, but they don't get to choose wether their viewers use > IPv4 or IPv6. You were arguing, I thought, that content providers would stay on IPv4-only for a long time, and that web users would never move until content was IPv6-only. I disagree with the first part: most web content will be dual-stack, so that as much traffic as possible will be over IPv6. > > Except for the most basic, static of websites, content providers > > are going to prefer IPv6 over IPv4. I don't know whether web > > hosting companies will ever automatically dual-stack the PTA's > > website, but at some point it will be easier for them to warn all > > their customers and just do it, than to track which customers > > asked for IPv6 explicitly. > As long as a majority of users come over IPv4, better anti-DDOS > measures or anti-abuse procedures for IPv6 are not going to make > any difference. "When you DOS my site, please use IPv6, so we > can better find out your location and more effectively block > your IP address." That's not what I was saying. Since anti-DDOS in IPv4 will inflict collateral damage, interfering with innocent users' experience of the site, web content providers should have a strong preference for IPv6. Meaning they will make it available, and possibly promote it as much as possible. > Users are going to drive adoption of IPv6, if and when they > find a "killer-app" where IPv6 can provide usability that (heavily > NATed) IPv4 can't. This could be better file-sharing tools, lower > latency online gaming, better long-distance video-calling or whatever, > as long as the benefits will be worth the relatively small > (<$50) investment of money and time. The killer app is the avoidance of CGN: head-to-head gaming, p2p, SIP, remote access, etc. ISPs are deploying IPv6 (http://www.cablelabs.com/news/pr/2011/11_pr_ipv6_transition_020111.html) Web content providers are deploying IPv6 (http://isoc.org/wp/worldipv6day/) It's bad that home gateways need replacing (http://www.computerworld.com/s/article/9208718/Cisco_Linksys_routers_still_ don_t_support_IPv6?taxonomyId=16) And consumer electronics are dangerously far behind. > > For content providers, as long as 90+% of the net is IPv4 only and Less than a year before > 10% of the net has IPv6. You read it here first. > essentially nobody is IPv6 only, providing dual-stack support is just > adding cost for little or no gain in viewership. Content providers > often depend on dozens if not hundreds of pieces of hardware and > software to provider their services, so supporting IPv6 is vastly > most expensive than it is for users to take advantage of it. Cisco and Netgear (see article above) say that essentially every user needs a new gateway in the $150 range. You already have one-- excellent, but the high end does not dominate the market. You're arguing that web content provider costs are greater than $100 per user? I don't mean to trivialize the effort content providers must make. But to suggest that it's enormously higher than any other segment's investment, and has no benefit, is misguided. Lee From joe at nethead.com Sun Feb 13 09:30:08 2011 From: joe at nethead.com (Joe Hamelin) Date: Sun, 13 Feb 2011 07:30:08 -0800 Subject: Old Annex question In-Reply-To: References: <8FCED5CE-7FB8-459C-AE55-BBF2B57CDD7F@mac.com> Message-ID: Michael Loftis wrote: > I could just set the attn_string to say "^A" and then I could just hit that > and it would work, but it doesn't seem to. Remember if you're using minicom it will escape ^A for it's own menu use. Wolfe.net had a score of those with Multi-tech modems way back in the day. I remember days spent hunting down ring-no-answers in a 400 POTS line hunt group. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From nick at foobar.org Sun Feb 13 10:36:47 2011 From: nick at foobar.org (Nick Hilliard) Date: Sun, 13 Feb 2011 16:36:47 +0000 Subject: Old Annex question In-Reply-To: References: <8FCED5CE-7FB8-459C-AE55-BBF2B57CDD7F@mac.com> Message-ID: <4D58089F.2040604@foobar.org> On 13/02/2011 15:30, Joe Hamelin wrote: > day. I remember days spent hunting down ring-no-answers in a 400 POTS > line hunt group. It was much easier to detect those by looking for strange port connectivity patterns in the logs. re: annexes, it was a happy day when we upgraded from annex 3 to portmaster. No idea what the escape key was. Nick From meekjt at gmail.com Sun Feb 13 11:18:47 2011 From: meekjt at gmail.com (Jon Meek) Date: Sun, 13 Feb 2011 12:18:47 -0500 Subject: Old Annex question In-Reply-To: <4D58089F.2040604@foobar.org> References: <8FCED5CE-7FB8-459C-AE55-BBF2B57CDD7F@mac.com> <4D58089F.2040604@foobar.org> Message-ID: On Sun, Feb 13, 2011 at 11:36 AM, Nick Hilliard wrote: > On 13/02/2011 15:30, Joe Hamelin wrote: > >> day. I remember days spent hunting down ring-no-answers in a 400 POTS >> line hunt group. >> > > It was much easier to detect those by looking for strange port connectivity > patterns in the logs. > > re: annexes, it was a happy day when we upgraded from annex 3 to > portmaster. No idea what the escape key was. > > Nick > > I have a couple of Micro Annex's in the recycle pile in my basement and, after a bit of rummaging, found that I have the paper documentation as well. In the User's Guide it says: "While in a session with a host, pressing an attention key returns you to the CLI prompt." Somewhere else it indicates that BREAK is the attention key however that may be configurable. If anything further is needed contact me, probably off-list, and I can look in the docs including the full CLI manual. Jon From joelja at bogus.com Sun Feb 13 11:56:50 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 13 Feb 2011 09:56:50 -0800 Subject: quietly.... In-Reply-To: References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <4D4979D1.4000104@phaze.org> <70C15FD9-CF85-4664-B913-3EBE4271C7F5@muada.com> <4D499910.4020001@foobar.org> <4D4AB894.6050107@brightok.net> <4D4AB9B4.4060201@foobar.org> <4D4ACB3B.4080200@brightok.net > Message-ID: <4D581B62.7080101@bogus.com> On 2/3/11 12:59 PM, David Conrad wrote: > On Feb 3, 2011, at 5:35 AM, Jack Bates wrote: >> You missed my pointed. Root servers are hard coded, but they aren't >> using a well known anycast address. > > Actually, most of the IP addresses used for root servers are anycast > addresses and given they're in every resolver on the Internet, > they're pretty well known... > > Of course, one might ask why those well known anycast addresses are > "owned" by 12 different organizations instead of being "golden" > addresses specified in an RFC or somesuch, but that gets into root > server operator politics... there are perfectly valid reasons why you might want to renumber one, the current institutional heterogeneity has pretty good prospects for survivability. > Regards, -drc > > > From drc at virtualized.org Sun Feb 13 12:31:30 2011 From: drc at virtualized.org (David Conrad) Date: Sun, 13 Feb 2011 08:31:30 -1000 Subject: quietly.... In-Reply-To: <4D581B62.7080101@bogus.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <4D4979D1.4000104@phaze.org> <70C15FD9-CF85-4664-B913-3EBE4271C7F5@muada.com> <4D499910.4020001@foobar.org> <4D4AB894.6050107@brightok.net> <4D4AB9B4.4060201@foobar.org> <4D4ACB3B.4080200@brightok.net > <4D581B62.7080101@bogus.com> Message-ID: <175BA50F-0AF0-43F3-9F96-3B4755DF8028@virtualized.org> On Feb 13, 2011, at 7:56 AM, Joel Jaeggli wrote: >> Of course, one might ask why those well known anycast addresses are >> "owned" by 12 different organizations instead of being "golden" >> addresses specified in an RFC or somesuch, but that gets into root >> server operator politics... > > there are perfectly valid reasons why you might want to renumber one, Ignoring historical mistakes, what would they be? > the current institutional heterogeneity has pretty good prospects for > survivability. "Golden" addresses dedicated to root service (as opposed to 'owned' by the root serving organization) means nothing regarding who is operating servers behind those addresses. It does make it easier to change who performs root service operation (hence the politics). Regards, -drc From jra at baylink.com Sun Feb 13 12:41:38 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 13 Feb 2011 13:41:38 -0500 (EST) Subject: quietly.... In-Reply-To: <31439225.7253.1297622486079.JavaMail.root@benjamin.baylink.com> Message-ID: <8594830.7255.1297622498214.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "David Conrad" > On Feb 13, 2011, at 7:56 AM, Joel Jaeggli wrote: > >> Of course, one might ask why those well known anycast addresses are > >> "owned" by 12 different organizations instead of being "golden" > >> addresses specified in an RFC or somesuch, but that gets into root > >> server operator politics... > > > > there are perfectly valid reasons why you might want to renumber > > one, > > Ignoring historical mistakes, what would they be? > > > the current institutional heterogeneity has pretty good prospects > > for > > survivability. > > "Golden" addresses dedicated to root service (as opposed to 'owned' by > the root serving organization) means nothing regarding who is > operating servers behind those addresses. It does make it easier to > change who performs root service operation (hence the politics). Exactly: it *centralizes control* over what the roots are. The second- and third-order resultants of that observation will be left as an exercise for the student; politics are off-topic for NANOG :-) Cheers, -- jra From eric at roxanne.org Sun Feb 13 14:11:08 2011 From: eric at roxanne.org (Eric Gauthier) Date: Sun, 13 Feb 2011 15:11:08 -0500 Subject: Combining 10g tap ports Message-ID: <20110213201108.GA30293@roxanne.org> Hello, I'm wondering what are people's experience is with boxes, like those from Gigamon, to aggregate 10g span ports? Any recommendations? As background, we currently have a sensor network where we provide our InfoSec team with taps from various points in our network. In cases where we have redundant routers, we've taken a tap from each one, fed it into a switch, then span'ed the two ports into a third so that we can present them with a single feed for each location because, according to them, they can not re-assemble data from different interfaces on their sensors. We have an "opportunity" to revisit this design now that we're moving to 10g router interlinks. Eric :) From fw at deneb.enyo.de Sun Feb 13 14:23:32 2011 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 13 Feb 2011 21:23:32 +0100 Subject: SmartNet Alternatives In-Reply-To: <6EFFEFBAC68377459A2E972105C759EC036456FC@EXVBE005-2.exch005intermedia.net> (Ryan Finnesey's message of "Sat, 12 Feb 2011 13:33:32 -0800") References: <060EDFC2221B014B9504AC06B747F58A499BCC3B57@ex01.alentus.lan> <6EFFEFBAC68377459A2E972105C759EC036456FC@EXVBE005-2.exch005intermedia.net> Message-ID: <87pqqvfzuj.fsf@mid.deneb.enyo.de> * Ryan Finnesey: > This is one of the reasons we are starting to look at Juniper for a > new network build. It is my understanding we set software updates > for life for free. My understanding is that it's free for customers who have a service contract in place. Most downloads are not self-service, and I haven't tested if you can get JTAC to provide images for devices you don't own. From ios.run at gmail.com Sun Feb 13 14:53:16 2011 From: ios.run at gmail.com (Raul Rodriguez) Date: Sun, 13 Feb 2011 12:53:16 -0800 Subject: Little to No Connectivity on LLNW Delivered Content // AS22822 ... AS7132 Message-ID: Will an ATT op comment on what looks like an outage (or the beginning of a connectivity tiff) regarding LLNW content (Netflix among others) delivered via GBLX and TiNet to AS7132 customers in Southern California? Here's the full path: AS22822 AS3257 AS7018 AS7132 Thanks. -RR From rcarpen at network1.net Sun Feb 13 14:54:11 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Sun, 13 Feb 2011 15:54:11 -0500 (EST) Subject: SmartNet Alternatives In-Reply-To: <4D5738A4.3070005@rollernet.us> Message-ID: <7083ccea-25ae-434e-9b05-234a9e8fe4a4@zimbra.network1.net> > How does Juniper feel about used hardware? > > ~Seth I love Juniper's hardware and software, and support. However, the way they deal with used or second hand hardware is terrible. It is not possible to transfer ownership at all. You can not resell anything, and hope to get any software updates or support. The challenge is that Cisco refurb with SmartNet is generally considerably cheaper than new Juniper. It makes it tough to sell Juniper in many situations. We have the same problem with NetApp. It seems that these companies would rather see their equipment end up in a landfill, and have the secondary market turn to a different vendor, rather than being responsible, and making it possible for equipment to be reused instead of trashed. It really annoys me. Disclaimer: I am a Juniper and NetApp partner/reseller, and love their stuff. I just hate their policies. -Randy From gbonser at seven.com Sun Feb 13 14:58:49 2011 From: gbonser at seven.com (George Bonser) Date: Sun, 13 Feb 2011 12:58:49 -0800 Subject: SmartNet Alternatives In-Reply-To: <87pqqvfzuj.fsf@mid.deneb.enyo.de> References: <060EDFC2221B014B9504AC06B747F58A499BCC3B57@ex01.alentus.lan><6EFFEFBAC68377459A2E972105C759EC036456FC@EXVBE005-2.exch005intermedia.net> <87pqqvfzuj.fsf@mid.deneb.enyo.de> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13A7C@RWC-EX1.corp.seven.com> > * Ryan Finnesey: > > > This is one of the reasons we are starting to look at Juniper for a > > new network build. It is my understanding we set software updates > > for life for free. > > My understanding is that it's free for customers who have a service > contract in place. Most downloads are not self-service, and I haven't > tested if you can get JTAC to provide images for devices you don't > own. Brocade is now offering 5 years (what they consider lifetime) support to the original purchaser of the equipment on some product lines: FastIron SX800, SX1600, CX, WS, and TurboIron that includes software updates. We use a lot of the FCX units. From marka at isc.org Sun Feb 13 15:33:14 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 14 Feb 2011 08:33:14 +1100 Subject: IPv6 is on the marketers radar In-Reply-To: Your message of "Sat, 12 Feb 2011 21:03:41 CDT." <000901cbcb22$3cf978a0$b6ec69e0$@org> References: <33020353.1007.1297454809458.JavaMail.franck@franck-martins-macbook-pro.local> <000901cbcb22$3cf978a0$b6ec69e0$@org> Message-ID: <20110213213314.83EBA9EF639@drugs.dv.isc.org> In message <000901cbcb22$3cf978a0$b6ec69e0$@org>, "Lee Howard" writes: > > > > -----Original Message----- > > From: Geert Bosch [mailto:bosch at adacore.com] > > > > Honestly, I can't quite see the big deal for home users. I'm using > > an Apple Airport Extreme, and setting it up with a IPv6 tunnel from > > $150? That's a high-powered device compared to most home gateways. > > > HE was quite straightforward. Sure, I don't expect the average user > > to go through these steps, but they could easily be automated and > > rolled out as part of a firmware update (which is a routine matter > > Yes, if the ISP provided the gateway. In many markets, they don't. > Even if they start now, they would have to convince every customer > to swap routers. And find the capital to pay for them. And have a > system for updating the firmware and configurations of those > devices. Or maybe the customer's going to have to buy a new > gateway, when the one they have is still functioning, and might > even be brand new. > > > the foreseeable future, people will have (NATed or not) IPv4 > > connectivity, so content providers are fine without IPv6. > > Depends on the content. Large-scale NAT is bad for you if you > depend on IP geo-location, or use anti-DDOS measures to limit > number of connections or bits from a single IP address, or use > IP address to report abuse, or blacklist IP addresses, or log the > user's IP address, or try to enforce copyright by reporting IP > addresses of violators, or rate-limit outbound data per address, > or record unique visitors by IP address. > It might also increase latency, but probably not so much that > you'd panic. And a lot of that depends upon how you implement LSN. * LSN per pop or a uber mega LSN? * How many customers per address? 2 or 200? -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From wavetossed at googlemail.com Sun Feb 13 15:37:51 2011 From: wavetossed at googlemail.com (Michael Dillon) Date: Sun, 13 Feb 2011 13:37:51 -0800 Subject: IPv6 is on the marketers radar In-Reply-To: <001001cbcb91$deb34c60$9c19e520$@org> References: <33020353.1007.1297454809458.JavaMail.franck@franck-martins-macbook-pro.local> <000901cbcb22$3cf978a0$b6ec69e0$@org> <8B082D10-A0EA-4012-8656-E60DD7EC76D0@adacore.com> <001001cbcb91$deb34c60$9c19e520$@org> Message-ID: > It's bad that home gateways need replacing It's not neccessarily bad. There are a lot of older devices out there and technology has progressed a couple of generations since then. That spells market opportunity for manufacturers of IPv6 gateways, particularly at the higher end of the market where the impact of the recession has not hit as hard. And given that a gateway is a box running Linux with some network interfaces, there is an opportunity for added features, maybe even so far as an Android style apps market. The general public is now learning that the Internet is going through a transition and that IPv6 is future proof. The smart money would now be putting gateways on the market to sell to early adopters. And the creative money would be looking for a way to link the IPv6 gateways with an IPv6 home server that runs apps from an apps market. Those apps could be anything from a backup of your blog to a SIP PABX. --Michael Dillon P.S. if anyone has money to invest, contact me and let's talk. From marka at isc.org Sun Feb 13 16:07:31 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 14 Feb 2011 09:07:31 +1100 Subject: IPv6 is on the marketers radar In-Reply-To: Your message of "Sat, 12 Feb 2011 22:34:21 CDT." <8B082D10-A0EA-4012-8656-E60DD7EC76D0@adacore.com> References: <33020353.1007.1297454809458.JavaMail.franck@franck-martins-macbook-pro.local> <000901cbcb22$3cf978a0$b6ec69e0$@org><8B082D10-A0EA-4012-8656-E60DD7EC76D0@adacore.com> Message-ID: <20110213220731.DD7809EF7EF@drugs.dv.isc.org> In message <8B082D10-A0EA-4012-8656-E60DD7EC76D0 at adacore.com>, Geert Bosch write s: > > On Feb 12, 2011, at 21:03, Lee Howard wrote: > >> Honestly, I can't quite see the big deal for home users. I'm using > >> an Apple Airport Extreme, and setting it up with a IPv6 tunnel from > >=20 > > $150? That's a high-powered device compared to most home gateways. > Sure, but the same thing is possible with a cheap 6-year-old sub-$50=20 > popular Linksys wifi router, see = > http://opensystems.wordpress.com/2006/06/01/linksys-wrt54g-ipv6-howto/ > for example. The point is that it can be cheap, relatively easy=20 > and painless for users to upgrade. > > Basically, it should not have to cost anything extra to set up=20 > new users for IPv6. The same hardware that handles IPv4 today > can be programmed to do IPv6. > > >> the foreseeable future, people will have (NATed or not) IPv4 > >> connectivity, so content providers are fine without IPv6.=20 > >=20 > > Depends on the content. Large-scale NAT is bad for you if you > > depend on IP geo-location, or use anti-DDOS measures to limit > > number of connections or bits from a single IP address, or use > > IP address to report abuse, or blacklist IP addresses, or log the > > user's IP address, or try to enforce copyright by reporting IP > > addresses of violators, or rate-limit outbound data per address, > > or record unique visitors by IP address. > > It might als > > > o increase latency, but probably not so much that > > you'd panic. > Users don't care about IP geo-location or anti-DDOS measures, or > any of the other reasons you list. These are things content providers > care about, but they don't get to choose wether their viewers use > IPv4 or IPv6. > > > Except for the most basic, static of websites, content providers > > are going to prefer IPv6 over IPv4. I don't know whether web > > hosting companies will ever automatically dual-stack the PTA's > > website, but at some point it will be easier for them to warn all > > their customers and just do it, than to track which customers > > asked for IPv6 explicitly. > As long as a majority of users come over IPv4, better anti-DDOS > measures or anti-abuse procedures for IPv6 are not going to make > any difference. "When you DOS my site, please use IPv6, so we > can better find out your location and more effectively block=20 > your IP address." > > Users are going to drive adoption of IPv6, if and when they > find a "killer-app" where IPv6 can provide usability that (heavily > NATed) IPv4 can't. This could be better file-sharing tools, lower > latency online gaming, better long-distance video-calling or whatever,=20= > as long as the benefits will be worth the relatively small=20 > (<$50) investment of money and time. Or ISP's will drive it because they don't want the long term costs of LSN and pay the handful of CPE vendors to develop and ship products with IPv6 enabled and not ship IPv4 only products. $1 per IPv6 enabled product sold for N years. Just have a check box for the ISPs participating in the scheme + other when doing the warranty registation. > For content providers, as long as 90+% of the net is IPv4 only and > essentially nobody is IPv6 only, providing dual-stack support is just > adding cost for little or no gain in viewership. Content providers > often depend on dozens if not hundreds of pieces of hardware and > software to provider their services, so supporting IPv6 is vastly > most expensive than it is for users to take advantage of it. And how much of that is already IPv6 capable? > In my case, the upgrade to IPv6 was free. There must be many more > using an Apple router (any model, Express, Extreme or otherwise) > that can upgrade to IPv6 for free. However, I can't list any benefit > from doing so, except from going to test-ipv6.com and seeing a 10/10 > score. Basically, you have to be a geek to be interested in IPv6. > That's got to change, before there will be any meaningful shifts. > > -Geert= > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From frnkblk at iname.com Sun Feb 13 16:44:40 2011 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 13 Feb 2011 16:44:40 -0600 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <4D55B191.9030702@brightok.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> <4D554F29.8070903@ispalliance.net> <5A6D953473350C4B9995546AFE9939EE0BC13A3E@RWC-EX1.corp.seven.com> <4D55B191.9030702@brightok.net> Message-ID: <001a01cbcbcf$9994b680$ccbe2380$@iname.com> Fine approach as long as the DSLAMs and CPE allow ether type 0x86DD to pass. Frank -----Original Message----- From: Jack Bates [mailto:jbates at brightok.net] Sent: Friday, February 11, 2011 4:01 PM To: Ricky Beam Cc: nanog at nanog.org Subject: Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... On 2/11/2011 3:41 PM, Ricky Beam wrote: > In bridge mode, any modem will do. It's when the modem is also the > router (which is most cases today) that it will need attention to > support IPv6. (in bridge mode, you'll have to fix whatever it's plugged > into, but that's the customer's problem... off to Best Buy for an IPv6 > capable D-Link.) I just finished discussing with the one telco in my network that deployed PPPoE. All customers will bring their modem into the office, where the front desk ladies will flash the config to bridge mode. It was that or replace thousands of CPE that never will support IPv6 in routed mode. Have a nice day. Jack From marka at isc.org Sun Feb 13 16:59:33 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 14 Feb 2011 09:59:33 +1100 Subject: mailing list bounces Message-ID: <20110213225933.95C649F05C2@drugs.dv.isc.org> It looks like one of nanog's outbound servers doesn't have a PTR record. Mark Received:from s0.nanog.org (207.75.116.162) by edge.atlasbiz.com (192.168.198.21 ) with Microsoft SMTP Server id 8.2.255.0; Sun, 13 Feb 2011 21:34:17 +0000 ; <<>> DiG 9.6.0-APPLE-P2 <<>> -x 207.75.116.162 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 29686 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;162.116.75.207.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: 116.75.207.in-addr.arpa. 10764 IN SOA dns.merit.net. ejd.merit.edu. 2011021202 28800 14400 2419200 14400 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Feb 14 09:54:42 2011 ;; MSG SIZE rcvd: 107 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jason at lixfeld.ca Sun Feb 13 18:29:16 2011 From: jason at lixfeld.ca (Jason Lixfeld) Date: Sun, 13 Feb 2011 19:29:16 -0500 Subject: Packet over SONET failback Message-ID: <301B4391-D67C-4106-8DF8-FC4021DCCB3F@lixfeld.ca> PoS failure detection happens in under 50ms, but what about the failback? Same deal? I ask because I've got two routers connected to opposite ends of a spare PoS link that I've been playing with and I'm noticing that the failback on the far side seems to be about 15 seconds (assuming the near side failover was initiated with an interface shutdown command and thusly no shut'd to re-enable the link). Just wanted to know if a higher failback time is a relatively normal occurrence and maybe I'm seeing some sort of built-in hold down feature working away? From ljb at merit.edu Sun Feb 13 18:48:03 2011 From: ljb at merit.edu (Larry J. Blunk) Date: Sun, 13 Feb 2011 19:48:03 -0500 (EST) Subject: mailing list bounces In-Reply-To: <20110213225933.95C649F05C2@drugs.dv.isc.org> Message-ID: <121334192.111427.1297644483313.JavaMail.root@int-mailstore01> ----- Original Message ----- > It looks like one of nanog's outbound servers doesn't have a PTR > record. > > Mark > > Received:from s0.nanog.org (207.75.116.162) by edge.atlasbiz.com > (192.168.198.21 > ) with Microsoft SMTP Server id 8.2.255.0; Sun, 13 Feb 2011 21:34:17 > +0000 > > > ; <<>> DiG 9.6.0-APPLE-P2 <<>> -x 207.75.116.162 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 29686 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;162.116.75.207.in-addr.arpa. IN PTR > > ;; AUTHORITY SECTION: > 116.75.207.in-addr.arpa. 10764 IN SOA dns.merit.net. ejd.merit.edu. > 2011021202 28800 14400 2419200 14400 > > ;; Query time: 0 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Mon Feb 14 09:54:42 2011 > ;; MSG SIZE rcvd: 107 > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org Oops, fixed. The machines were moved to a new a subnet this morning and I was so preoccupied with remembering to create the ip6.arpa PTR records that I completely forgot the in-addr.arpa's. Bet that's a first. I suppose it's progress to be thinking about v6 first and v4 second. -Larry Blunk Merit From joelja at bogus.com Sun Feb 13 18:49:57 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 13 Feb 2011 16:49:57 -0800 Subject: quietly.... In-Reply-To: <175BA50F-0AF0-43F3-9F96-3B4755DF8028@virtualized.org> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <4D4979D1.4000104@phaze.org> <70C15FD9-CF85-4664-B913-3EBE4271C7F5@muada.com> <4D499910.4020001@foobar.org> <4D4AB894.6050107@brightok.net> <4D4AB9B4.4060201@foobar.org> <4D4ACB3B.4080200@brightok.net > <4D581B62.7080101@bogus.com> <175BA50F-0AF0-43F3-9F96-3B4755DF8028@virtualized.org> Message-ID: <4D587C35.10101@bogus.com> On 2/13/11 10:31 AM, David Conrad wrote: > On Feb 13, 2011, at 7:56 AM, Joel Jaeggli wrote: >>> Of course, one might ask why those well known anycast addresses >>> are "owned" by 12 different organizations instead of being >>> "golden" addresses specified in an RFC or somesuch, but that gets >>> into root server operator politics... >> >> there are perfectly valid reasons why you might want to renumber >> one, > > Ignoring historical mistakes, what would they be? gosh, I can't imagine why anyone would want to renumber of out 198.32.64.0/24... making them immutable pretty much insures that you'll then find a reason to do so. >> the current institutional heterogeneity has pretty good prospects >> for survivability. > > "Golden" addresses dedicated to root service (as opposed to 'owned' > by the root serving organization) means nothing regarding who is > operating servers behind those addresses. It does make it easier to > change who performs root service operation (hence the politics). There are plenty of cautionary tales to be told about well-known addresses. assuming that for the sake of the present that we forsake future flexibility then sure golden addresses are great. > Regards, -drc > > From marka at isc.org Sun Feb 13 19:12:06 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 14 Feb 2011 12:12:06 +1100 Subject: mailing list bounces In-Reply-To: Your message of "Sun, 13 Feb 2011 19:48:03 CDT." <121334192.111427.1297644483313.JavaMail.root@int-mailstore01> References: <121334192.111427.1297644483313.JavaMail.root@int-mailstore01> Message-ID: <20110214011206.AC2B09F0EFA@drugs.dv.isc.org> In message <121334192.111427.1297644483313.JavaMail.root at int-mailstore01>, "Larr y J. Blunk" writes: > > > ----- Original Message ----- > > It looks like one of nanog's outbound servers doesn't have a PTR > > record. > > > > Mark > > > > Received:from s0.nanog.org (207.75.116.162) by edge.atlasbiz.com > > (192.168.198.21 > > ) with Microsoft SMTP Server id 8.2.255.0; Sun, 13 Feb 2011 21:34:17 > > +0000 > > > > > > ; <<>> DiG 9.6.0-APPLE-P2 <<>> -x 207.75.116.162 > > ;; global options: +cmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 29686 > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > > > > ;; QUESTION SECTION: > > ;162.116.75.207.in-addr.arpa. IN PTR > > > > ;; AUTHORITY SECTION: > > 116.75.207.in-addr.arpa. 10764 IN SOA dns.merit.net. ejd.merit.edu. > > 2011021202 28800 14400 2419200 14400 > > > > ;; Query time: 0 msec > > ;; SERVER: 127.0.0.1#53(127.0.0.1) > > ;; WHEN: Mon Feb 14 09:54:42 2011 > > ;; MSG SIZE rcvd: 107 > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > > > > Oops, fixed. The machines were moved to a new a > subnet this morning and I was so preoccupied with remembering > to create the ip6.arpa PTR records that I completely forgot > the in-addr.arpa's. Bet that's a first. I suppose it's > progress to be thinking about v6 first and v4 second. > > > -Larry Blunk > Merit It will be much better when the OS's just register themselves in the DNS. Humans shouldn't have to do this when a machine renumbers. Named can already authenticate PTR updates based on using TCP and the source address of the update. For A/AAAA records you setup a cryptographically strong authentication first. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From joelja at bogus.com Sun Feb 13 20:18:10 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 13 Feb 2011 18:18:10 -0800 Subject: My upstream ISP does not support IPv6 In-Reply-To: <4D4C15BE.8090801@ispalliance.net> References: <18699589.266.1296788654238.JavaMail.franck@franck-martins-macbook-pro.local> <4D4C15BE.8090801@ispalliance.net> Message-ID: <4D5890E2.3010109@bogus.com> fwiw we have v6 transit from internap in metro atlanta. setup was drama-free. up until about 6 months ago it was offered on a non-production basis and only as a tunnel, now it's dual stacked to our customer edge. joel On 2/4/11 7:05 AM, Scott Helms wrote: > We have been working diligently for more than 6 months to try and get a > /56 routed to one of our offices in metro Atlanta. The carrier in > question is a Tier 1 as well as being one of the old telecom names. I > have the entire chain of emails documenting the carrier's struggles with > internal process and technical issues. We are currently waiting for a > new edge router to be ready to transfer our existing circuits to. Not > that it matters but we were also told that we would be moved from a > Cisco to a Juniper. Once I realized how much of a struggle that was > turning into I contacted some of our other providers (a mix of Tier 1 & > 2 ISPs and collocation providers) as of this moment none of them (though > some seem close) are actually prepared to deliver IPv6 connectivity > where we need it despite some of them already touting preparedness. > > What I think is worth remembering is that there are a _lot_ of moving > parts to get right to actually route an IPv6 block down a connection. > Some of those parts are technical like making sure an edge router that > may have been in place for years can handle IPv6 traffic _and_ that > addition won't cause a CPU or other issue on the specific platform > you're looking at. Some of the others are simply business process > pieces like making sure contracts, internal and external documentation, > and work flow that need to be updated. > > TLDR version, marketing often fails to reflect reality :) > > On 2/3/2011 10:04 PM, Franck Martin wrote: >> The biggest complaint that I hear from ISPs, is that their upstream >> ISP does not support IPv6 or will not provide them with a native IPv6 >> circuit. >> >> Is that bull? >> >> I thought the whole backbone is IPv6 now, and it is only the >> residential ISPs that are still figuring it out because CPE are still >> not there yet. >> >> Where can I get more information? Any list of peering ISPs that have >> IPv6 as part of their products? >> >> It seems to me the typical answer sales people say when asked about >> IPv6: "Gosh, this is the first time I'm asked this one". >> > > From owen at delong.com Sun Feb 13 20:16:38 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 13 Feb 2011 18:16:38 -0800 Subject: IPv6 is on the marketers radar In-Reply-To: <20110213213314.83EBA9EF639@drugs.dv.isc.org> References: <33020353.1007.1297454809458.JavaMail.franck@franck-martins-macbook-pro.local> <000901cbcb22$3cf978a0$b6ec69e0$@org> <20110213213314.83EBA9EF639@drugs.dv.isc.org> Message-ID: <97A71056-759E-4749-97FE-15458CCC4396@delong.com> On Feb 13, 2011, at 1:33 PM, Mark Andrews wrote: > > In message <000901cbcb22$3cf978a0$b6ec69e0$@org>, "Lee Howard" writes: >> >> >>> -----Original Message----- >>> From: Geert Bosch [mailto:bosch at adacore.com] >>> >>> Honestly, I can't quite see the big deal for home users. I'm using >>> an Apple Airport Extreme, and setting it up with a IPv6 tunnel from >> >> $150? That's a high-powered device compared to most home gateways. >> >>> HE was quite straightforward. Sure, I don't expect the average user >>> to go through these steps, but they could easily be automated and >>> rolled out as part of a firmware update (which is a routine matter >> >> Yes, if the ISP provided the gateway. In many markets, they don't. >> Even if they start now, they would have to convince every customer >> to swap routers. And find the capital to pay for them. And have a >> system for updating the firmware and configurations of those >> devices. Or maybe the customer's going to have to buy a new >> gateway, when the one they have is still functioning, and might >> even be brand new. >> >>> the foreseeable future, people will have (NATed or not) IPv4 >>> connectivity, so content providers are fine without IPv6. >> >> Depends on the content. Large-scale NAT is bad for you if you >> depend on IP geo-location, or use anti-DDOS measures to limit >> number of connections or bits from a single IP address, or use >> IP address to report abuse, or blacklist IP addresses, or log the >> user's IP address, or try to enforce copyright by reporting IP >> addresses of violators, or rate-limit outbound data per address, >> or record unique visitors by IP address. >> It might also increase latency, but probably not so much that >> you'd panic. > > And a lot of that depends upon how you implement LSN. > * LSN per pop or a uber mega LSN? > * How many customers per address? 2 or 200? > Most LSNs will probably be regional collections of LSN boxes that are (somewhat randomly) load balanced. Owen From bmanning at vacation.karoshi.com Sun Feb 13 21:51:48 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 14 Feb 2011 03:51:48 +0000 Subject: quietly.... In-Reply-To: <4D587C35.10101@bogus.com> References: <4D499910.4020001@foobar.org> <4D4AB894.6050107@brightok.net> <4D4AB9B4.4060201@foobar.org> <4D4ACB3B.4080200@brightok.net> <4D581B62.7080101@bogus.com> <175BA50F-0AF0-43F3-9F96-3B4755DF8028@virtualized.org> <4D587C35.10101@bogus.com> Message-ID: <20110214035148.GA1929@vacation.karoshi.com.> On Sun, Feb 13, 2011 at 04:49:57PM -0800, Joel Jaeggli wrote: > On 2/13/11 10:31 AM, David Conrad wrote: > > On Feb 13, 2011, at 7:56 AM, Joel Jaeggli wrote: > >>> Of course, one might ask why those well known anycast addresses > >>> are "owned" by 12 different organizations instead of being > >>> "golden" addresses specified in an RFC or somesuch, but that gets > >>> into root server operator politics... > >> > >> there are perfectly valid reasons why you might want to renumber > >> one, > > > > Ignoring historical mistakes, what would they be? > > gosh, I can't imagine why anyone would want to renumber of out > > 198.32.64.0/24... or 198.32.65.0/24 or 10.0.0.0/8 or 128.0.0.0/16 (speaking of the other blocks I've had the fortune to have to renumber out of) > > making them immutable pretty much insures that you'll then find a reason > to do so. > > >> the current institutional heterogeneity has pretty good prospects > >> for survivability. > > > > "Golden" addresses dedicated to root service (as opposed to 'owned' > > by the root serving organization) means nothing regarding who is > > operating servers behind those addresses. It does make it easier to > > change who performs root service operation (hence the politics). > > There are plenty of cautionary tales to be told about well-known > addresses. assuming that for the sake of the present that we forsake > future flexibility then sure golden addresses are great. > > > Regards, -drc well - there is an interesting take on hosting root name service on 127.0.0.1 and ::1 then you have to do other tricks, like multicast and new op-codes and rip out the link-local restrictions that Apple's multicastDNS or the ilnp proposals do... end of the day, you end up with a -much- more robust DNS w/o the whole P2P/DNS (chord) like framework. but ... this thread has migrated far from its origins... and the mutations are less than operational. YMMV of course. --bill From frnkblk at iname.com Sun Feb 13 22:46:39 2011 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 13 Feb 2011 22:46:39 -0600 Subject: Looking for an IPv6 naysayer... In-Reply-To: <4D5306EB.3030203@ispalliance.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><4D52E942.5000607@ispalliance.net><87sjvxhu1v.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com> <8762stc5a7.fsf@oban.berlin.quux.de><5A6D953473350C4B9995546AFE9939EE0BC1397F@RWC-EX1.corp.seven.com> <4D52FF60.1090102@ispalliance.net> <5A6D953473350C4B9995546AFE9939EE0BC13980@RWC-EX1.corp.seven.com> <4D5306EB.3030203@ispalliance.net> Message-ID: <005201cbcc02$2b56f0b0$8204d210$@iname.com> I believe all the CM vendors make at least one cable modem that has an embedded router that does NAT (Motorola SBG901, 901, 940, 941; Arris WTM552, etc). Some MSOs may deploy more or less of those. Frank -----Original Message----- From: Scott Helms [mailto:khelms at ispalliance.net] Sent: Wednesday, February 09, 2011 3:28 PM To: George Bonser Cc: nanog at nanog.org Subject: Re: Looking for an IPv6 naysayer... George, Comcast, like all(?) DOCSIS systems uses 10/8 or one of the other defined non-routable blocks for cable modems, which (if its a DOCSIS certified device) will be a bridge only and will not do NAT. If you we're NAT'ed on a cable modem system it must have been a proprietary system, of which there once was a ton before DOCSIS caught on, that Comcast hadn't phased out. I don't believe that any of the large MSO's (and none of the small ones I know) are doing NAT on edge devices or the core at this point, however your point is still valid since virtually all of the ADSL lines deployed are being NAT'ed at the modem level and that means that millions of people are being NAT'ed without a choice. That also means that a lot of people are already going through two NAT translations since they have plugged in a small router behind their DSL modem and both are NAT'ing their buggy little hearts out. We also have to think about the tremendous number of people on all kinds of networks that are voluntarily, like me, NAT'ing through one device of their own (usually not educated) choice. > How many instances of 10/8 did they say they were running? I was behind > a NAT when I had Comcast service. I am behind a NAT currently with my > AT&T service. > > Note that the NAT was done on the "cable modem" in both cases and not > further in to their network. That said, from my reading of some > industry large scale NAT devices (the A10 AX series is one which I am > familiar with), they do things such as full cone NAT so it will still > work with many applications that might break with conventional overload > dynamic NAT. > > > -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From drc at virtualized.org Sun Feb 13 22:57:12 2011 From: drc at virtualized.org (David Conrad) Date: Sun, 13 Feb 2011 18:57:12 -1000 Subject: quietly.... In-Reply-To: <4D587C35.10101@bogus.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <4D4979D1.4000104@phaze.org> <70C15FD9-CF85-4664-B913-3EBE4271C7F5@muada.com> <4D499910.4020001@foobar.org> <4D4AB894.6050107@brightok.net> <4D4AB9B4.4060201@foobar.org> <4D4ACB3B.4080200@brightok.net > <4D581B62.7080101@bogus.com> <175BA50F-0AF0-43F3-9F96-3B4755DF8028@virtualized.org> <4D587C35.10101@bogus.c om> Message-ID: <7C6F6BD2-F128-426B-9AEA-F7FBBB1226D9@virtualized.org> On Feb 13, 2011, at 2:49 PM, Joel Jaeggli wrote: >> Ignoring historical mistakes, what would they be? > gosh, I can't imagine why anyone would want to renumber of out 198.32.64.0/24... I guess you missed the part where I said "Ignoring historical mistakes". > making them immutable pretty much insures that you'll then find a reason to do so. The fact that ICANN felt it necessary to renumber into a new prefix is a perfect example of why having golden addresses for the DNS makes sense. If the root server addresses had been specified in an RFC or somesuch, there would be no question about address "ownership". > There are plenty of cautionary tales to be told about well-known addresses. As I'm sure you're aware, the DNS is a bit unique in that can't use the DNS to bootstrap. It requires a set of pre-configured addresses to function. Changing one of those pre-configured addresses requires changing the hints file in every resolver on the Internet which takes a very long time (I'm told that a root server address changed over a decade ago still receives more than 10 priming queries per second). It also means the former root server address is forever poisoned -- you don't want to give that address to someone who might use it to set up a bogus root server. It was hard enough when there were just a couple of DNS resolver vendors, now there are more than a few. > assuming that for the sake of the present that we forsake future flexibility then sure golden addresses are great. It isn't clear to me what flexibility would be sacrificed, but it is academic. Unfortunately, it'll likely take some traumatic event for the status quo to change. Regards, -drc From frnkblk at iname.com Sun Feb 13 23:14:05 2011 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 13 Feb 2011 23:14:05 -0600 Subject: quietly.... In-Reply-To: <4D48E558.7070805@brightok.net> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <4D48E558.7070805@brightok.net> Message-ID: <006401cbcc06$0044a580$00cdf080$@iname.com> Ditto. -----Original Message----- From: Jack Bates [mailto:jbates at brightok.net] Sent: Tuesday, February 01, 2011 11:02 PM To: NANOG list Subject: Re: quietly.... I have also now seen 2 different vendor DSL modems which when not using PPPoE require a manually entered default router (ie, no RA support). Jack From frnkblk at iname.com Sun Feb 13 23:46:39 2011 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 13 Feb 2011 23:46:39 -0600 Subject: quietly.... In-Reply-To: References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> Message-ID: <007301cbcc0a$8cd54f00$a67fed00$@iname.com> Sounds like PI space is a solution for those 5000 desktops. Frank -----Original Message----- From: david raistrick [mailto:drais at icantclick.org] Sent: Wednesday, February 02, 2011 11:05 AM To: Cameron Byrne; Owen DeLong Cc: nanog at nanog.org Subject: Re: quietly.... On Tue, 1 Feb 2011, Cameron Byrne wrote: >> Telling people "I'm right, you're wrong" over and over again leads to >> them going away and ignoring IPv6. >> > > +1 > > Somebody should probably get a blog instead of sending, *39 and > counting*, emails to this list in one day. It's a discussion list. We're having a discussion. Admittedly, Owen hasn't presented any solutions to my actual problems, but.. ;) Owen said: > The solution to number 2 depends again on the circumstance. IPv6 > offers a variety of tools for this problem, but, I have yet to see an > environment where the other tools can't offer a better solution than > NAT. Which is a complete non-answer. NAT provides a nice "solution" - even with it's problems - for small consumers and large enterprises, who have much higher percentages of devices that need (or even -require-) no inbound connectivity. Why should I (or my IT department) have to renumber the 5,000 desktop PCs in this office (a large percentage of which have static IP addresses due to the failings of dynamic DNS and software that won't support DNS (I'm looking at you, Unity.) just because we've changed providers? Why should we have to renumber devices at my mom's house just because she switched from cable to dsl? -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From frnkblk at iname.com Sun Feb 13 23:46:55 2011 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 13 Feb 2011 23:46:55 -0600 Subject: quietly.... In-Reply-To: <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> Message-ID: <007401cbcc0a$96ca9830$c45fc890$@iname.com> Requiring them to be on certain well known addresses is restrictive and creates an unnecessary digression from IPv4 practice. It's comments like this that raise the hair on admins' necks. At least mine. Frank -----Original Message----- From: Iljitsch van Beijnum [mailto:iljitsch at muada.com] Sent: Wednesday, February 02, 2011 9:23 AM To: Owen DeLong Cc: NANOG list Subject: Re: quietly.... On 2 feb 2011, at 16:00, Owen DeLong wrote: > SLAAC fails because you can't get information about DNS, NTP, or anything other than a list of prefixes and a router that MIGHT actually be able to default-route your packets. Who ever puts NTP addresses in DHCP? That doesn't make any sense. I'd rather use a known NTP server that keeps correct time. For DNS in RA, see RFC 6106. But all of this could easily have been avoided: why are we _discovering_ DNS addresses in the first place? Simply host them on well known addresses and you can hardcode those addresses, similar to the 6to4 gateway address. But no, no rough consensus on something so simple. > DHCP fails because you can't get a default router out of it. If you consider that wrong, I don't want to be right. From franck at genius.com Mon Feb 14 03:57:01 2011 From: franck at genius.com (Franck Martin) Date: Mon, 14 Feb 2011 22:57:01 +1300 (FJST) Subject: IPv6 is on the marketers radar In-Reply-To: Message-ID: <22074840.663.1297677419591.JavaMail.franck@franck-martins-macbook-pro.local> ----- Original Message ----- > From: "Michael Dillon" > To: nanog at nanog.org > Sent: Monday, 14 February, 2011 10:37:51 AM > Subject: Re: IPv6 is on the marketers radar > > It's bad that home gateways need replacing > > It's not neccessarily bad. There are a lot of older devices out there > and technology has progressed a couple of generations since then. That > spells market opportunity for manufacturers of IPv6 gateways, > particularly at the higher end of the market where the impact of the > recession has not hit as hard. And given that a gateway is a box > running Linux with some network interfaces, there is an opportunity > for added features, maybe even so far as an Android style apps market. > > The general public is now learning that the Internet is going through > a transition and that IPv6 is future proof. The smart money would now > be putting gateways on the market to sell to early adopters. And the > creative money would be looking for a way to link the IPv6 gateways > with an IPv6 home server that runs apps from an apps market. Those > apps could be anything from a backup of your blog to a SIP PABX. > > --Michael Dillon > > P.S. if anyone has money to invest, contact me and let's talk. one new box nearly every year: http://fr.wikipedia.org/wiki/Freebox IPv6 available since 2007: http://www.zdnet.fr/actualites/la-freebox-adopte-l-ipv6-et-se-mue-en-serveur-d-impression-39376502.htm From denys at visp.net.lb Mon Feb 14 05:15:39 2011 From: denys at visp.net.lb (denys at visp.net.lb) Date: Mon, 14 Feb 2011 13:15:39 +0200 Subject: US Warships jamming Lebanon Internet In-Reply-To: References: "\"\\\"\\\\\\\"\\\\\\\\\\\\\\\"<201102081359.39100.denys@visp.net.lb>\\\\\\\"<201102081434.38609.denys@visp.net.lb>\\\\\\\"<052C3BF4-13C9-4AE1-BF5E-DC5AF16179C7@oitc.com><201102081541.23651.denys@visp.net.lb>" "<4D51911A.2060008@brightok.net>\"" "<73b1fdd4629c62e4cc48070f2825596f@visp.net.lb>\" "\"" Message-ID: <1f61ea135891eff35ea11fe79ca77191@visp.net.lb> On Sat, 12 Feb 2011 21:58:22 -0500, Marshall Eubanks wrote: > On Feb 12, 2011, at 5:55 PM, denys at visp.net.lb wrote: > >> On Sat, 12 Feb 2011 11:39:59 -1000, Michael Painter wrote: >>> denys at visp.net.lb wrote: >>>> On Tue, 08 Feb 2011 12:53:14 -0600, Jack Bates wrote: >>>>> On 2/8/2011 7:41 AM, Denys Fedoryshchenko wrote: >>>>>> It is PLL LNB, one carrier, we are using full transponder 36 >>>>>> Mhz. >>>>>> There is >>>>>> almost no other users on this satellite (inclined more than 1.5 >>>>>> degree), and >>>>>> other carriers center frequency 100Mhz away. >>>>>> >>>>> Since no one else will, "I blame solar flares!" >>>>> >>>>> Jack >>>> I am monitoring solar activity, getting info from NOAA. No >>>> correlation. >>> >>> Have you been able to get any assistance from the uplink/teleport >>> noc >>> or the satellite operator? >> Yes, for sure. >> Satellite operator doesn't provide much help, but uplink proposed >> for us some plan to solve all this issues. >> Already we implement temporary solution, and things at least stable >> now, plus it seems interference is lower somehow few last days. >> >> > > Here is a dumb idea that I have actually seen cause problems : > > Is it possible that the declination of the satellite from your > location is the same as the Sun right now ? That will cause up to > several hours of interruption every mid-day. The clue is that the > shadow of the receiver box is in the center of the dish (for prime > focus mounts). > > You might be surprised how many times this has caught people, so I > thought I would mention it. > Usually we are preparing for solar interference before 1-2 month, and we know exactly when it will stop :-) Plus it is happening max 10-15 minutes per day, and i had complete outage for few days. From internetplumber at gmail.com Mon Feb 14 05:47:29 2011 From: internetplumber at gmail.com (Rob Evans) Date: Mon, 14 Feb 2011 11:47:29 +0000 Subject: Packet over SONET failback In-Reply-To: <301B4391-D67C-4106-8DF8-FC4021DCCB3F@lixfeld.ca> References: <301B4391-D67C-4106-8DF8-FC4021DCCB3F@lixfeld.ca> Message-ID: > PoS failure detection happens in under 50ms, but what about the failback? ?Same deal? ?I ask because I've got two routers connected to opposite ends of a spare PoS link that I've been playing with and I'm noticing that the failback on the far side seems to be about 15 seconds (assuming the near side failover was initiated with an interface shutdown command and thusly no shut'd to re-enable the link). I think there are a couple of issues at play here. First of all, SONET/SDH restoration happens at layer 1, whereas it looks like you're waiting for a router to reroute. Your reroute times will be tied to recalculation of IGPs. Secondly, is this with a Cisco? Try setting "pos ais-shut" on both sides. Unless you do that, the router won't generate and AIS, and it will take the encapsulation timeout (HDLC, PPP) for the interface on the other side to go down and signal that to the routing protocols on top. Rob From jason at lixfeld.ca Mon Feb 14 06:53:38 2011 From: jason at lixfeld.ca (Jason Lixfeld) Date: Mon, 14 Feb 2011 07:53:38 -0500 Subject: Packet over SONET failback In-Reply-To: References: <301B4391-D67C-4106-8DF8-FC4021DCCB3F@lixfeld.ca> Message-ID: On 2011-02-14, at 6:47 AM, Rob Evans wrote: >> PoS failure detection happens in under 50ms, but what about the failback? Same deal? I ask because I've got two routers connected to opposite ends of a spare PoS link that I've been playing with and I'm noticing that the failback on the far side seems to be about 15 seconds (assuming the near side failover was initiated with an interface shutdown command and thusly no shut'd to re-enable the link). > > I think there are a couple of issues at play here. First of all, > SONET/SDH restoration happens at layer 1, whereas it looks like you're > waiting for a router to reroute. Your reroute times will be tied to > recalculation of IGPs. > > Secondly, is this with a Cisco? Try setting "pos ais-shut" on both > sides. Unless you do that, the router won't generate and AIS, and it > will take the encapsulation timeout (HDLC, PPP) for the interface on > the other side to go down and signal that to the routing protocols on > top. It's becoming clear from the responses that my initial post was lacking a bit of info. It's not actually SONET all the way through. It's GigE from the router to the SONET node, an unprotected OC192 wave to another node, out GigE to the far end router. I didn't mention that because I didn't think it mattered; I assumed the speed in which the GigE on the other side came up was protocol agnostic. I assumed that as soon as the far end of the SONET node saw the near end go back up, it would turn the laser back on on the far side bringing the interface back up. I assumed also that since it took a whole 15 seconds that it had something to do with the SONET side of things. I'm not necessarily talking about forwarding of packets here, I'm talking simply about the time it takes the far side interface to come back up over a SONET node; layer 1. Maybe this has nothing at all to do with SONET, I dunno :) It was gleaned that the next step might be to look at the SONET node and see if it's waiting 15 seconds to turn the laser back on or something. From pelle at hemmop.com Mon Feb 14 07:12:16 2011 From: pelle at hemmop.com (Per Carlson) Date: Mon, 14 Feb 2011 14:12:16 +0100 Subject: Packet over SONET failback In-Reply-To: References: <301B4391-D67C-4106-8DF8-FC4021DCCB3F@lixfeld.ca> Message-ID: Hi Jason. >>> PoS failure detection happens in under 50ms IMHO this is the most important part, fast *down* detection. > It's not actually SONET all the way through. It's GigE from the router to the SONET node, an unprotected OC192 wave to another node, out GigE to the far end router. If the gear manages to shut down the GE lasers within the 50ms, you have no rights at all to complain :-) > I'm not necessarily talking about forwarding of packets here, I'm talking simply about the time it takes the far side interface to come back up over a SONET node; layer 1. ?Maybe this has nothing at all to do with SONET, I dunno :) ? It was gleaned that the next step might be to look at the SONET node and see if it's waiting 15 seconds to turn the laser back on or something. A 15 second wait before enabling the path is a good thing. Nothing worse than switch back to a path and experience a second down event (and thrid, forth etc.). If it's been up 15 secs, it probably is safe to use. -- Pelle RFC1925, truth 11: ?Every old idea will be proposed again with a different name and ?a different presentation, regardless of whether it works. From david.freedman at uk.clara.net Mon Feb 14 08:16:35 2011 From: david.freedman at uk.clara.net (David Freedman) Date: Mon, 14 Feb 2011 14:16:35 +0000 Subject: ANNOUNCE: NANOG List and Website Downtime In-Reply-To: References: Message-ID: Has this move completed yet? I'm getting redirect loop: $ curl -I www.nanog.org HTTP/1.1 302 Found Date: Mon, 14 Feb 2011 14:15:04 GMT Server: Apache/2.2.6 (FreeBSD) mod_ssl/2.2.6 OpenSSL/0.9.8e DAV/2 PHP/5.2.4 with Suhosin-Patch Location: http://www.nanog.org Michael K. Smith - Adhost wrote: > Hello All: > > The NANOG website and NANOG mailing list will be unavailable during the times listed below. There is an issue with the present location within the University of Michigan environment that requires a physical move of the NANOG servers to a discrete location. We apologize for the short notice and will do our best to minimize the associated downtime. > > If you have any questions, feel free to let me know or you can address it on nanog-futures as well. > > Date of Outage: Sunday, February 13th, 2011 > Start of Outage: 0500 EST (GMT -5) > End of Outage: 0900 EST (GMT -5) > Impact: www.nanog.org will be unavailable and the NANOG mailing list will not accept mail. > > Regards, > Mike > On behalf of the NANOG Communications Committee > > -- > Michael K. Smith - CISSP, GSEC, GISP > Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com > w: +1 (206) 404-9500 f: +1 (206) 404-9050 > PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) > > > > -- David Freedman Group Network Engineering Claranet Group From david.freedman at uk.clara.net Mon Feb 14 08:43:38 2011 From: david.freedman at uk.clara.net (David Freedman) Date: Mon, 14 Feb 2011 14:43:38 +0000 Subject: ANNOUNCE: NANOG List and Website Downtime In-Reply-To: References: Message-ID: Somebody has helpfully pointed out that this is only broken over v6, v4 is fine $ curl -I -4 nanog.org HTTP/1.1 200 OK Date: Mon, 14 Feb 2011 14:43:10 GMT Server: Apache/2.2.6 (FreeBSD) mod_ssl/2.2.6 OpenSSL/0.9.8e DAV/2 PHP/5.2.4 with Suhosin-Patch X-Powered-By: PHP/5.2.4 Content-Type: text/html Dave. David Freedman wrote: > Has this move completed yet? I'm getting redirect loop: > > $ curl -I www.nanog.org > HTTP/1.1 302 Found > Date: Mon, 14 Feb 2011 14:15:04 GMT > Server: Apache/2.2.6 (FreeBSD) mod_ssl/2.2.6 OpenSSL/0.9.8e DAV/2 > PHP/5.2.4 with Suhosin-Patch > Location: http://www.nanog.org > > > > Michael K. Smith - Adhost wrote: >> Hello All: >> >> The NANOG website and NANOG mailing list will be unavailable during the times listed below. There is an issue with the present location within the University of Michigan environment that requires a physical move of the NANOG servers to a discrete location. We apologize for the short notice and will do our best to minimize the associated downtime. >> >> If you have any questions, feel free to let me know or you can address it on nanog-futures as well. >> >> Date of Outage: Sunday, February 13th, 2011 >> Start of Outage: 0500 EST (GMT -5) >> End of Outage: 0900 EST (GMT -5) >> Impact: www.nanog.org will be unavailable and the NANOG mailing list will not accept mail. >> >> Regards, >> Mike >> On behalf of the NANOG Communications Committee >> >> -- >> Michael K. Smith - CISSP, GSEC, GISP >> Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com >> w: +1 (206) 404-9500 f: +1 (206) 404-9050 >> PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) >> >> >> >> > > -- David Freedman Group Network Engineering Claranet Group From brunner at nic-naa.net Mon Feb 14 09:12:42 2011 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Mon, 14 Feb 2011 10:12:42 -0500 Subject: Looking for an IPv6 naysayer... In-Reply-To: <7D5EC021-DD50-4E3A-9916-8CE32C840645@delong.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E59B.4070904@nic-naa.net> <6E2D8385-77A1-4408-B12B-A7F61FDCC3EF@delong.com> <4D531E85.3000005@nic-naa.net> <0CA94927-95DB-4C36-9B55-C891151729FB@delong.com> <4D53FDA2.8050304@nic-naa.net> <7D5EC021-DD50-4E3A-9916-8CE32C840645@delong.com> Message-ID: <4D59466A.6070603@nic-naa.net> owen, at several points you assert that gtlds are "global", which i suggest is an error on your part. gtlds are whatever the controlling contract (icann) requires, and that currently lacks an external to the point of service performance measurement, and whatever the registrants require, with some filtering through the marginal interests of registrars. the icann contract for the .cat registry is "sponsored", and the interest of the registry, and its registrants, is marginal outside of catalonia. the icann contract for some municipality or region, assuming the new gtld program results in new contracts, may be "standard" or "community-based", but the intersts of the registry, and its registrants, may also be marginal outside of that municipality or region. you can decide for yourself if your preference for the policy and profit margins for .nyc are controlling, or if the preferences of the city administration, the registry operator, and, using either the .cat or the .nl rates of adoption, a quarter of a million or four million new yorkers are controlling. if there is a registry the operations for which you are familiar enough to discuss, we can discuss the necessity and utility of a v6 reachibility requirement, though the prior to delegation requirement is unique to the proposed contract for new registries. -e From mksmith at adhost.com Mon Feb 14 09:30:25 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Mon, 14 Feb 2011 15:30:25 +0000 Subject: ANNOUNCE: NANOG List and Website Downtime In-Reply-To: Message-ID: Hello All: It appears that Merit has corrected the v6 redirect loop so all services should be operational at this point. If anyone is having any ongoing issues please let me know. Regards, Mike On behalf of the NANOG Communications Committee -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) On 2/14/11 6:43 AM, "David Freedman" wrote: >Somebody has helpfully pointed out that this is only broken over v6, v4 >is fine > >$ curl -I -4 nanog.org >HTTP/1.1 200 OK >Date: Mon, 14 Feb 2011 14:43:10 GMT >Server: Apache/2.2.6 (FreeBSD) mod_ssl/2.2.6 OpenSSL/0.9.8e DAV/2 >PHP/5.2.4 with Suhosin-Patch >X-Powered-By: PHP/5.2.4 >Content-Type: text/html > >Dave. > > >David Freedman wrote: >> Has this move completed yet? I'm getting redirect loop: >> >> $ curl -I www.nanog.org >> HTTP/1.1 302 Found >> Date: Mon, 14 Feb 2011 14:15:04 GMT >> Server: Apache/2.2.6 (FreeBSD) mod_ssl/2.2.6 OpenSSL/0.9.8e DAV/2 >> PHP/5.2.4 with Suhosin-Patch >> Location: http://www.nanog.org >> >> >> >> Michael K. Smith - Adhost wrote: >>> Hello All: >>> >>> The NANOG website and NANOG mailing list will be unavailable during >>>the times listed below. There is an issue with the present location >>>within the University of Michigan environment that requires a physical >>>move of the NANOG servers to a discrete location. We apologize for the >>>short notice and will do our best to minimize the associated downtime. >>> >>> If you have any questions, feel free to let me know or you can address >>>it on nanog-futures as well. >>> >>> Date of Outage: Sunday, February 13th, 2011 >>> Start of Outage: 0500 EST (GMT -5) >>> End of Outage: 0900 EST (GMT -5) >>> Impact: www.nanog.org will be unavailable and the NANOG mailing list >>>will not accept mail. >>> >>> Regards, >>> Mike >>> On behalf of the NANOG Communications Committee >>> >>> -- >>> Michael K. Smith - CISSP, GSEC, GISP >>> Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com >>> w: +1 (206) 404-9500 f: +1 (206) 404-9050 >>> PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) >>> >>> >>> >>> >> >> > > >-- > > >David Freedman >Group Network Engineering >Claranet Group > > From jbates at brightok.net Mon Feb 14 09:49:25 2011 From: jbates at brightok.net (Jack Bates) Date: Mon, 14 Feb 2011 09:49:25 -0600 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <001a01cbcbcf$9994b680$ccbe2380$@iname.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> <4D554F29.8070903@ispalliance.net> <5A6D953473350C4B9995546AFE9939EE0BC13A3E@RWC-EX1.corp.seven.com> <4D55B191.9030702@brightok.net> <001a01cbcbcf$9994b680$ccbe2380$@iname.com> Message-ID: <4D594F05.40603@brightok.net> Luckily, they do. Only the smart DSLAMs had issues, and they even blocked IP protocol 41. haha On 2/13/2011 4:44 PM, Frank Bulk wrote: > Fine approach as long as the DSLAMs and CPE allow ether type 0x86DD to pass. From intensifysecurity at gmail.com Mon Feb 14 09:59:35 2011 From: intensifysecurity at gmail.com (Jeff Hartley) Date: Mon, 14 Feb 2011 10:59:35 -0500 Subject: IPv6 is on the marketers radar In-Reply-To: References: <33020353.1007.1297454809458.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On Fri, Feb 11, 2011 at 3:43 PM, Fred Baker wrote: > > On Feb 11, 2011, at 12:21 PM, Franck Martin wrote: > >> http://www.marketingvox.com/under-the-microscope-what-the-end-of-ipv4-means-for-marketers-048657/ >> >> I can hear people, say oh no.... >> >> Interesting to see that marketers do not like CGNAT. > > They missed an important point. > >> Who Will Be Impacted: For more consumers, there will be negligible impact. "The ISPs will be handling much of this,? said Leo Vegoda, a researcher with ICANN. (via TechNewsWorld). Some technology users may experience some glitches, such as people using VPN software to connect with their offices or users of point-to-point software such as Skype, he adds. > > Anyone that uses a residential router (Linksys, D-Link, Netgear, etc) is likely to need to upgrade that, most likely by buying a new one. Set-top boxes are generally IPv4; anyone with a TV is likely to need to upgrade at least the software. Skype is not yet IPv6-capable, and will need one an update. "The ISPs will take care of this" is a really empty hope. The ISPs will take care of their part, but users should expect that there will be things jiggling over the coming couple of years. > NetGear is apparently stepping up to the plate on the IPv6 CPE support -- their WNDRxxxx series have stubs for IPv6 config in place now. Granted, time and testing will reveal exactly how well (or poorly) implemented the support is... I was pleasantly surprised to discover this while providing "Family Tech Support" last weekend: (See second list, #1) # A New Firmware Version is Found. Do You Want to Upgrade to the New Version Now? # Current Firmware Version: V1.0.4.68NA # New Firmware Version: V1.0.7.98NA # Current GUI Language Version: V1.0.0.41 # New GUI Language Version: V1.0.0.64 # # 1.Fixed "can't get IP from 3700 DHCP server". # 2.Fixed "Some applications have disconnection issue in every 5~10 minutes like Google talk, Battlefield, Starcraft, mIRC, AIM, ooVoo, etc." # 3.Fixed "Web page loading slow". # 4.Fixed "DHCP reservation issue, change IP address of one device in the reservation table and the device is changed to new IP, but the attached device list still displays old IP". # # 1.IPv6 certified. # 2.DLNA certified. # 3.Remove WEP and TKIP from "Up to 135Mbps" and "Up to 300M It will certainly be entertaining to see what behaviors the various CPEs default to on the public-facing side. In the NetGear WNDR3700's case after upgrading its firmware, options were included for: Disabled (default) Auto-detect 6to4 Tunnel Pass Through Fixed DHCP PPPoE At least that gives the various broadband providers flexibility in tailoring their tech.support processes. (You know -- "click here, click there," etc.) FYI, -Jeff From andre.edwards at gmail.com Mon Feb 14 10:00:48 2011 From: andre.edwards at gmail.com (=?ISO-8859-1?Q?Andr=E9_Edwards?=) Date: Mon, 14 Feb 2011 12:00:48 -0400 Subject: CaribNOG Puerto Rico April 13th - 15th 2011 Message-ID: *Dear Colleagues, members of the Nanog Community and CaribNOG* Supporters, The Caribbean Network Operators Group (CARIBNOG) has the pleasure of announcing and inviting you to participate in the Regional CaribNOG meeting, CARIBNOG Puerto Rico, from 13th to 15th April. The 3 day event is being jointly supported by the American Registry for Internet Numbers (ARIN) , the Caribbean Telecommunications Union , Gauss Laboratories and the Internet Society (ISOC) . CaribNOG meetings place heavy emphasis on building Caribbean technical capacity by providing targeted training facilitated by industry experts. At the same time these gatherings afford participants a unique forum for exchanging ideas, sharing experiences and building the relationships so essential to creating a truly regional technical community. CaribNOG Puerto Rico will build on the content of the inaugural meeting and offer a more in-depth treatment of Routing Techniques and the technical considerations for the establishment of IXPs. The meeting will also continue to promote regional awareness of and participation in groups such as ISOC, ARIN, LACNIC and ICANN. Admission to the meeting will be free of charge and open Internet Service Providers, Network Administrators, Computer Engineers, Technology Researchers and ICT Consultants and other interested stakeholders. This allows regional ICT practitioners a unique opportunity to benefit from the expertise of some of the top minds in the industry. Location: The Caribe Hilton http://www.caribehilton.com/ Register Now for CaribNOG Puerto Rico: Registration More information on CaribNOG Puerto Rico: http://www.caribnog.org/events/puertorico2011/ Information on ARIN XXVII available here: https://www.arin.net/announcements/2011/20110125_arinxxvii.html Regards, __________________________ Andr? Edwards CARIBNOG Communications Team Email: andre.edwards at gmail.com Web: http://www.caribnog.org IPv6: http://www.caribnog.org/ipv6/ Mailing lists: http://www.caribnog.org/mailing-lists/ Facebook: http://www.facebook.com/pages/Caribnog/143643545668920?ref=ts Twitter: http://twitter.com/caribnog From dr at cluenet.de Mon Feb 14 10:19:40 2011 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 14 Feb 2011 17:19:40 +0100 Subject: IPv6 is on the marketers radar In-Reply-To: References: <33020353.1007.1297454809458.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <20110214161940.GA7289@srv03.cluenet.de> On Mon, Feb 14, 2011 at 10:59:35AM -0500, Jeff Hartley wrote: > It will certainly be entertaining to see what behaviors the various > CPEs default to on the public-facing side. In the NetGear WNDR3700's > case after upgrading its firmware, options were included for: > Disabled (default) > Auto-detect > 6to4 Tunnel > Pass Through > Fixed > DHCP > PPPoE missing: DS-Lite 6RD :-) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From joly at punkcast.com Mon Feb 14 12:05:32 2011 From: joly at punkcast.com (Joly MacFie) Date: Mon, 14 Feb 2011 13:05:32 -0500 Subject: NY Times on IPv4 depletion Message-ID: http://www.nytimes.com/2011/02/15/technology/15internet.html ?The problem was, the experiment never ended,? added Mr. Cerf, who is the > chairman of the Internet Corporation for Assigned Names and Numbers, > or Icann , a nonprofit corporation that coordinates > the Internet naming system. Surprising that that got past the NYT fact-checkers.. can see where they got it http://www.icann.org/en/biog/cerf.htm while they should have looked at http://www.icann.org/en/general/board.html or even http://en.wikipedia.org/wiki/Vint_Cerf let's see how long it takes to fix it. j -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org --------------------------------------------------------------- From joly at punkcast.com Mon Feb 14 12:05:52 2011 From: joly at punkcast.com (Joly MacFie) Date: Mon, 14 Feb 2011 13:05:52 -0500 Subject: NY Times on IPv4 depletion Message-ID: http://www.nytimes.com/2011/02/15/technology/15internet.html ?The problem was, the experiment never ended,? added Mr. Cerf, who is the > chairman of the Internet Corporation for Assigned Names and Numbers, > or Icann , a nonprofit corporation that coordinates > the Internet naming system. Surprising that that got past the NYT fact-checkers.. can see where they got it http://www.icann.org/en/biog/cerf.htm while they should have looked at http://www.icann.org/en/general/board.html or even http://en.wikipedia.org/wiki/Vint_Cerf let's see how long it takes to fix it. j -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org --------------------------------------------------------------- From cb.list6 at gmail.com Mon Feb 14 12:12:21 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Mon, 14 Feb 2011 10:12:21 -0800 Subject: NY Times on IPv4 depletion In-Reply-To: References: Message-ID: Too bad the article pushes my mobile device to their mobile site mobile.nytimes.com and that references an ipv4 literal for the picture to load .... so not only is nytimes not ipv6 it is also broken for ipv6 only users behind nat64 .... From jbates at brightok.net Mon Feb 14 12:19:02 2011 From: jbates at brightok.net (Jack Bates) Date: Mon, 14 Feb 2011 12:19:02 -0600 Subject: NY Times on IPv4 depletion In-Reply-To: References: Message-ID: <4D597216.1030400@brightok.net> On 2/14/2011 12:12 PM, Cameron Byrne wrote: > Too bad the article pushes my mobile device to their mobile site > mobile.nytimes.com and that references an ipv4 literal for the picture to > load .... so not only is nytimes not ipv6 it is also broken for ipv6 only > users behind nat64 .... That's almost as bad as the hundreds of subdomains used in webpages which sometimes hit broken load balancers (reporting nxdomain for AAAA). So you have to check each and every domain in the source to find which ones are broken. Jack From owen at delong.com Mon Feb 14 14:30:31 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 14 Feb 2011 12:30:31 -0800 Subject: Looking for an IPv6 naysayer... In-Reply-To: <4D59466A.6070603@nic-naa.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E59B.4070904@nic-naa.net> <6E2D8385-77A1-4408-B12B-A7F61FDCC3EF@delong.com> <4D531E85.3000005@nic-naa.net> <0CA94927-95DB-4C36-9B55-C891151729FB@delong.com> <4D53FDA2.8050304@nic-naa.net> <7D5EC021-DD50-4E3A-9916-8CE32C840645@delong.com> <4D59466A.6070603@nic-naa.net> Message-ID: <976D33C1-A3C6-462B-A0CA-5FC0BE31D9AE@delong.com> On Feb 14, 2011, at 7:12 AM, Eric Brunner-Williams wrote: > owen, > > at several points you assert that gtlds are "global", which i suggest is an error on your part. > TLDs come in two flavors. GTLD -- Global Top Level Domain -- A domain which contains records for entities not restricted to a particular geographical area. CCTLD -- Country Code Top Level Domain -- A domain which is under the control of a particular national government represented by the corresponding 2-letter ISO country code. The G in GTLD is Global... I'm not asserting anything, it's flat out in the term. > gtlds are whatever the controlling contract (icann) requires, and that currently lacks an external to the point of service performance measurement, and whatever the registrants require, with some filtering through the marginal interests of registrars. > Your point being? > the icann contract for the .cat registry is "sponsored", and the interest of the registry, and its registrants, is marginal outside of catalonia. > Interest in .cat may or may not be marginal. Doesn't matter. The nature of any policy regarding GTLDs is that it relates to more GTLDs than just ".cat". GTLDs are, by definition, global in scope on the internet and any policy about them should be viewed in that light. > the icann contract for some municipality or region, assuming the new gtld program results in new contracts, may be "standard" or "community-based", but the intersts of the registry, and its registrants, may also be marginal outside of that municipality or region. > Your point being? > you can decide for yourself if your preference for the policy and profit margins for .nyc are controlling, or if the preferences of the city administration, the registry operator, and, using either the .cat or the .nl rates of adoption, a quarter of a million or four million new yorkers are controlling. > First, I think giving all of these random things a GTLD to begin with is an absurd process fraught with peril to satisfy ICANN's greed. However, that's not my decision. If ICANN is going to move forward with this mess, the least we can do is try to have consistent policy for all GTLDs. While I recognize that ICANN lacked the foresight to make it possible to apply updated technical requirements to existing GTLD operators until their contract comes up for renewal, that is no reason we should not have reasonable and current requirements for new GTLDs. > if there is a registry the operations for which you are familiar enough to discuss, we can discuss the necessity and utility of a v6 reachibility requirement, though the prior to delegation requirement is unique to the proposed contract for new registries. > All operators should be required to support IPv6. If ICANN had done their job properly, this requirement would be applied to existing operators too. Unfortunately, ICANN dropped the ball and the contracts don't allow that. The fact that ICANN dropped the ball on existing registries isn't a reason to drop the ball on new ones. Owen From ikiris at gmail.com Mon Feb 14 14:34:48 2011 From: ikiris at gmail.com (Blake Dunlap) Date: Mon, 14 Feb 2011 13:34:48 -0700 Subject: IPv6 is on the marketers radar In-Reply-To: References: <33020353.1007.1297454809458.JavaMail.franck@franck-martins-macbook-pro.local> <4C98E9AF-6611-4F7D-885C-E259DC90B425@cybernothing.org> <4D55B4AC.3000907@paulgraydon.co.uk> Message-ID: On Fri, Feb 11, 2011 at 15:52, Dorn Hetzel wrote: > > > > > > p.s. with apologies to any honest marketers. All 2 of you.. > > > > > What's the difference between a used car salesman and a network equipment > salesman? > > The used care salesman knows when he's lying to you :) > The required software on the fuel injection doesn't require a separate non transferable license? -Blake From marka at isc.org Mon Feb 14 15:00:15 2011 From: marka at isc.org (Mark Andrews) Date: Tue, 15 Feb 2011 08:00:15 +1100 Subject: IPv6 is on the marketers radar In-Reply-To: Your message of "Mon, 14 Feb 2011 10:59:35 CDT." References: <33020353.1007.1297454809458.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <20110214210015.1905FA0994A@drugs.dv.isc.org> In message , Jeff Hartley writes: > On Fri, Feb 11, 2011 at 3:43 PM, Fred Baker wrote: > > > > On Feb 11, 2011, at 12:21 PM, Franck Martin wrote: > > > >> http://www.marketingvox.com/under-the-microscope-what-the-end-of-ipv4-me= > ans-for-marketers-048657/ > >> > >> I can hear people, say oh no.... > >> > >> Interesting to see that marketers do not like CGNAT. > > > > They missed an important point. > > > >> Who Will Be Impacted: For more consumers, there will be negligible impac= > t. "The ISPs will be handling much of this,=94 said Leo Vegoda, a researche= > r with ICANN. (via TechNewsWorld). Some technology users may experience som= > e glitches, such as people using VPN software to connect with their offices= > or users of point-to-point software such as Skype, he adds. > > > > Anyone that uses a residential router (Linksys, D-Link, Netgear, etc) is = > likely to need to upgrade that, most likely by buying a new one. Set-top bo= > xes are generally IPv4; anyone with a TV is likely to need to upgrade at le= > ast the software. Skype is not yet IPv6-capable, and will need one an updat= > e. "The ISPs will take care of this" is a really empty hope. The ISPs will = > take care of their part, but users should expect that there will be things = > jiggling over the coming couple of years. > > > > > > NetGear is apparently stepping up to the plate on the IPv6 CPE support > -- their WNDRxxxx series have stubs for IPv6 config in place now. > Granted, time and testing will reveal exactly how well (or poorly) > implemented the support is... > > I was pleasantly surprised to discover this while providing "Family > Tech Support" last weekend: > (See second list, #1) > # A New Firmware Version is Found. Do You Want to Upgrade to the New > Version Now? > # Current Firmware Version: V1.0.4.68NA > # New Firmware Version: V1.0.7.98NA > # Current GUI Language Version: V1.0.0.41 > # New GUI Language Version: V1.0.0.64 > # > # 1.Fixed "can't get IP from 3700 DHCP server". > # 2.Fixed "Some applications have disconnection issue in every 5~10 > minutes like Google talk, Battlefield, Starcraft, mIRC, AIM, ooVoo, > etc." > # 3.Fixed "Web page loading slow". > # 4.Fixed "DHCP reservation issue, change IP address of one device in > the reservation table and the device is changed to new IP, but the > attached device list still displays old IP". > # > # 1.IPv6 certified. > # 2.DLNA certified. > # 3.Remove WEP and TKIP from "Up to 135Mbps" and "Up to 300M > > > It will certainly be entertaining to see what behaviors the various > CPEs default to on the public-facing side. In the NetGear WNDR3700's > case after upgrading its firmware, options were included for: > Disabled (default) > Auto-detect > 6to4 Tunnel > Pass Through > Fixed > DHCP > PPPoE Where is SLAAC? > At least that gives the various broadband providers flexibility in > tailoring their tech.support processes. (You know -- "click here, > click there," etc.) It's not always a broadband vendor on the upstream side. > FYI, > -Jeff > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From dr at cluenet.de Mon Feb 14 15:21:29 2011 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 14 Feb 2011 22:21:29 +0100 Subject: Looking for an IPv6 naysayer... In-Reply-To: <976D33C1-A3C6-462B-A0CA-5FC0BE31D9AE@delong.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E59B.4070904@nic-naa.net> <6E2D8385-77A1-4408-B12B-A7F61FDCC3EF@delong.com> <4D531E85.3000005@nic-naa.net> <0CA94927-95DB-4C36-9B55-C891151729FB@delong.com> <4D53FDA2.8050304@nic-naa.net> <7D5EC021-DD50-4E3A-9916-8CE32C840645@delong.com> <4D59466A.6070603@nic-naa.net> <976D33C1-A3C6-462B-A0CA-5FC0BE31D9AE@delong.com> Message-ID: <20110214212129.GA28015@srv03.cluenet.de> On Mon, Feb 14, 2011 at 12:30:31PM -0800, Owen DeLong wrote: > GTLD -- Global Top Level Domain -- A domain which contains records for entities not restricted > to a particular geographical area. s/Global/Generic/ > The G in GTLD is Global... I'm not asserting anything, it's flat out in the term. No, it isn't. > All operators should be required to support IPv6. If ICANN had done > their job properly, this requirement would be applied to existing > operators too. That I agree to. :-) Domain stuff is all about making money with labels, not "doing it the right way" though. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From brunner at nic-naa.net Mon Feb 14 15:44:41 2011 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Mon, 14 Feb 2011 16:44:41 -0500 Subject: Looking for an IPv6 naysayer... In-Reply-To: <976D33C1-A3C6-462B-A0CA-5FC0BE31D9AE@delong.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E59B.4070904@nic-naa.net> <6E2D8385-77A1-4408-B12B-A7F61FDCC3EF@delong.com> <4D531E85.3000005@nic-naa.net> <0CA94927-95DB-4C36-9B55-C891151729FB@delong.com> <4D53FDA2.8050304@nic-naa.net> <7D5EC021-DD50-4E3A-9916-8CE32C840645@delong.com> <4D59466A.6070603@nic-naa.net> <976D33C1-A3C6-462B-A0CA-5FC0BE31D9AE@delong.com> Message-ID: <4D59A249.9070006@nic-naa.net> On 2/14/11 3:30 PM, Owen DeLong wrote: > > On Feb 14, 2011, at 7:12 AM, Eric Brunner-Williams wrote: > >> owen, >> >> at several points you assert that gtlds are "global", which i suggest is an error on your part. >> > TLDs come in two flavors. > > GTLD -- Global Top Level Domain -- A domain which contains records for entities not restricted > to a particular geographical area. > > CCTLD -- Country Code Top Level Domain -- A domain which is under the control of a particular > national government represented by the corresponding 2-letter ISO country code. > > The G in GTLD is Global... I'm not asserting anything, it's flat out in the term. ok. we've reached the point where your subject matter expertise is obviously greater than mine. i've been working in icann policy and registry technology since ... well, since the nic contract was one floor below my office in sri's e-building. and you _know_ that "g" means "global". -e From jeffrey.lyon at blacklotus.net Mon Feb 14 15:51:49 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 14 Feb 2011 16:51:49 -0500 Subject: Looking for an IPv6 naysayer... In-Reply-To: <4D59A249.9070006@nic-naa.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E59B.4070904@nic-naa.net> <6E2D8385-77A1-4408-B12B-A7F61FDCC3EF@delong.com> <4D531E85.3000005@nic-naa.net> <0CA94927-95DB-4C36-9B55-C891151729FB@delong.com> <4D53FDA2.8050304@nic-naa.net> <7D5EC021-DD50-4E3A-9916-8CE32C840645@delong.com> <4D59466A.6070603@nic-naa.net> <976D33C1-A3C6-462B-A0CA-5FC0BE31D9AE@delong.com> <4D59A249.9070006@nic-naa.net> Message-ID: >> The G in GTLD is Global... I'm not asserting anything, it's flat out in >> the term. I believe the "g" is for "generic." -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From marka at isc.org Mon Feb 14 15:52:39 2011 From: marka at isc.org (Mark Andrews) Date: Tue, 15 Feb 2011 08:52:39 +1100 Subject: NY Times on IPv4 depletion In-Reply-To: Your message of "Mon, 14 Feb 2011 12:19:02 MDT." <4D597216.1030400@brightok.net> References: <4D597216.1030400@brightok.net> Message-ID: <20110214215239.E0671A09F98@drugs.dv.isc.org> In message <4D597216.1030400 at brightok.net>, Jack Bates writes: > > > On 2/14/2011 12:12 PM, Cameron Byrne wrote: > > Too bad the article pushes my mobile device to their mobile site > > mobile.nytimes.com and that references an ipv4 literal for the picture to > > load .... so not only is nytimes not ipv6 it is also broken for ipv6 only > > users behind nat64 .... > > That's almost as bad as the hundreds of subdomains used in webpages > which sometimes hit broken load balancers (reporting nxdomain for AAAA). Very few do that anymore. What they do however is return the wrong SOA record. > So you have to check each and every domain in the source to find which > ones are broken. Which one really shouldn't have to do. Add DS-Lite support to the phone and have the carriers advertise that they support DS-Lite and the IPv4 literal problem goes away. This has been done in a phone already so it is possible to do. > Jack -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From cb.list6 at gmail.com Mon Feb 14 16:09:35 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Mon, 14 Feb 2011 14:09:35 -0800 Subject: NY Times on IPv4 depletion In-Reply-To: <20110214215239.E0671A09F98@drugs.dv.isc.org> References: <4D597216.1030400@brightok.net> <20110214215239.E0671A09F98@drugs.dv.isc.org> Message-ID: On Feb 14, 2011 1:52 PM, "Mark Andrews" wrote: > > > In message <4D597216.1030400 at brightok.net>, Jack Bates writes: > > > > > > On 2/14/2011 12:12 PM, Cameron Byrne wrote: > > > Too bad the article pushes my mobile device to their mobile site > > > mobile.nytimes.com and that references an ipv4 literal for the picture to > > > load .... so not only is nytimes not ipv6 it is also broken for ipv6 only > > > users behind nat64 .... > > > > That's almost as bad as the hundreds of subdomains used in webpages > > which sometimes hit broken load balancers (reporting nxdomain for AAAA). > > Very few do that anymore. What they do however is return the wrong SOA > record. > > > So you have to check each and every domain in the source to find which > > ones are broken. > > Which one really shouldn't have to do. Add DS-Lite support to the > phone and have the carriers advertise that they support DS-Lite and > the IPv4 literal problem goes away. > > This has been done in a phone already so it is possible to do. > Ds-lite has been dismissed by 3gpp. Nytimes needs to start using fqdns and ideally ipv6. Until then, it's their content that's being mangled. It is not reasonable for network operators to engineer for amateur web programming mistakes Cb > > Jack > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From intensifysecurity at gmail.com Mon Feb 14 16:13:29 2011 From: intensifysecurity at gmail.com (Jeff Hartley) Date: Mon, 14 Feb 2011 17:13:29 -0500 Subject: IPv6 is on the marketers radar In-Reply-To: <20110214210015.1905FA0994A@drugs.dv.isc.org> References: <33020353.1007.1297454809458.JavaMail.franck@franck-martins-macbook-pro.local> <20110214210015.1905FA0994A@drugs.dv.isc.org> Message-ID: On Mon, Feb 14, 2011 at 4:00 PM, Mark Andrews wrote: > >> It will certainly be entertaining to see what behaviors the various >> CPEs default to on the public-facing side. ?In the NetGear WNDR3700's >> case after upgrading its firmware, options were included for: >> ? Disabled (default) >> ? Auto-detect >> ? 6to4 Tunnel >> ? Pass Through >> ? Fixed >> ? DHCP >> ? PPPoE > > Where is SLAAC? > > Mark Andrews, ISC > Based on their tiny bit of surrounding text, apparently that's "Pass Through", although that naming choice seems odd to me. I'd call it "native", but we're back to marketing at that point... I agree with Daniel (above) on the noticeable lack of DS-Lite and/or 6rd. Chicken-and-egg situation regarding the most profitable to implement? Lack of development resources? Coming RSN? ...I was surprised to see anything at all, hence the share. -Jeff From marka at isc.org Mon Feb 14 16:52:59 2011 From: marka at isc.org (Mark Andrews) Date: Tue, 15 Feb 2011 09:52:59 +1100 Subject: NY Times on IPv4 depletion In-Reply-To: Your message of "Mon, 14 Feb 2011 14:09:35 -0800." References: <4D597216.1030400@brightok.net> <20110214215239.E0671A09F98@drugs.dv.isc.org> Message-ID: <20110214225259.B93DCA0C166@drugs.dv.isc.org> In message , Came ron Byrne writes: > --00163630f77d957e25049c454dc0 > Content-Type: text/plain; charset=ISO-8859-1 > > On Feb 14, 2011 1:52 PM, "Mark Andrews" wrote: > > > > > > In message <4D597216.1030400 at brightok.net>, Jack Bates writes: > > > > > > > > > On 2/14/2011 12:12 PM, Cameron Byrne wrote: > > > > Too bad the article pushes my mobile device to their mobile site > > > > mobile.nytimes.com and that references an ipv4 literal for the picture > to > > > > load .... so not only is nytimes not ipv6 it is also broken for ipv6 > only > > > > users behind nat64 .... > > > > > > That's almost as bad as the hundreds of subdomains used in webpages > > > which sometimes hit broken load balancers (reporting nxdomain for AAAA). > > > > Very few do that anymore. What they do however is return the wrong SOA > > record. > > > > > So you have to check each and every domain in the source to find which > > > ones are broken. > > > > Which one really shouldn't have to do. Add DS-Lite support to the > > phone and have the carriers advertise that they support DS-Lite and > > the IPv4 literal problem goes away. > > > > This has been done in a phone already so it is possible to do. > > > > Ds-lite has been dismissed by 3gpp. Nytimes needs to start using fqdns and > ideally ipv6. Until then, it's their content that's being mangled. It is > not reasonable for network operators to engineer for amateur web programming > mistakes It still doesn't stop handest manufatures adding DS-Lite support and operators responding to the DHCP option so the handsets can find the AFTR box. NAT64/DNS64 may be the only operator side only solution but it has lots of limitation to it and it can't be made to work as well has DS-Lite even once the handset know the DNS64 prefix and BIH is added to translate IPv4 to IPv6 inside the handset using the DNS64 prefix. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Mon Feb 14 16:59:34 2011 From: marka at isc.org (Mark Andrews) Date: Tue, 15 Feb 2011 09:59:34 +1100 Subject: IPv6 is on the marketers radar In-Reply-To: Your message of "Mon, 14 Feb 2011 17:13:29 CDT." References: <33020353.1007.1297454809458.JavaMail.franck@franck-martins-macbook-pro.local> <20110214210015.1905FA0994A@drugs.dv.isc.org> Message-ID: <20110214225934.5FA09A0C1E9@drugs.dv.isc.org> In message , Jeff Hartley writes: > On Mon, Feb 14, 2011 at 4:00 PM, Mark Andrews wrote: > > > >> It will certainly be entertaining to see what behaviors the various > >> CPEs default to on the public-facing side. =A0In the NetGear WNDR3700's > >> case after upgrading its firmware, options were included for: > >> =A0 Disabled (default) > >> =A0 Auto-detect > >> =A0 6to4 Tunnel > >> =A0 Pass Through > >> =A0 Fixed > >> =A0 DHCP > >> =A0 PPPoE > > > > Where is SLAAC? > > > > Mark Andrews, ISC > > > > Based on their tiny bit of surrounding text, apparently that's "Pass > Through", although that naming choice seems odd to me. I'd call it > "native", but we're back to marketing at that point... SLAAC/PPPoE/DHCP/Fixed are all native. 6to4/6rd/6in4 are all tunnels of one form or another. I was seeing Pass Through as bridge mode. DS-lite is also a tunnel. DNS64 also needs to be added once they workout how to send it to the the box. Along with a NAT46. > I agree with Daniel (above) on the noticeable lack of DS-Lite and/or 6rd. > Chicken-and-egg situation regarding the most profitable to implement? > Lack of development resources? > Coming RSN? > ...I was surprised to see anything at all, hence the share. > > -Jeff > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From adrian at creative.net.au Mon Feb 14 17:08:03 2011 From: adrian at creative.net.au (Adrian Chadd) Date: Tue, 15 Feb 2011 07:08:03 +0800 Subject: AS7007 incident - would someone please "fix" the article? Message-ID: <20110214230803.GE30809@skywalker.creative.net.au> There's a wikipedia article: http://en.wikipedia.org/wiki/AS_7007_incident .. that a post I wrote up for a local computer club magazine somehow suffices as primary reference material for. Even though I think this is partially hilarious, would someone mind making it a little more authoritive and well-referenced? My article was definitely not written to be used as any form of source, primary or otherwise. :-) Thanks! Adrian From george.herbert at gmail.com Mon Feb 14 18:05:05 2011 From: george.herbert at gmail.com (George Herbert) Date: Mon, 14 Feb 2011 16:05:05 -0800 Subject: AS7007 incident - would someone please "fix" the article? In-Reply-To: <20110214230803.GE30809@skywalker.creative.net.au> References: <20110214230803.GE30809@skywalker.creative.net.au> Message-ID: On Mon, Feb 14, 2011 at 3:08 PM, Adrian Chadd wrote: > There's a wikipedia article: > > http://en.wikipedia.org/wiki/AS_7007_incident > > .. that a post I wrote up for a local computer club magazine somehow suffices > as primary reference material for. > > Even though I think this is partially hilarious, would someone mind making > it a little more authoritive and well-referenced? My article was definitely > not written to be used as any form of source, primary or otherwise. :-) > > Thanks! > > Adrian Improving it wouldn't hurt, but though your note is the only listed "reference" it also includes external links to the cnet news article about it, two NANOG list messages, "Origin Authentication in Interdomain Routing" by Aiello, Ioannis, and McDaniel, and a Penn State routing seminar slide deck. It's not badly sourced all things considered; the other sources could be more prominently referred to, though. -- -george william herbert george.herbert at gmail.com From tshaw at oitc.com Mon Feb 14 18:24:40 2011 From: tshaw at oitc.com (TR Shaw) Date: Mon, 14 Feb 2011 19:24:40 -0500 Subject: NIST and SP800-119 Message-ID: Just wondering what this community thinks of NIST in general and their SP800-119 ( http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf ) writeup about IPv6 in particular. From John_Brzozowski at Cable.Comcast.com Mon Feb 14 19:09:17 2011 From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John) Date: Tue, 15 Feb 2011 01:09:17 +0000 Subject: NY Times on IPv4 depletion In-Reply-To: Message-ID: +1 ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= On 2/14/11 5:09 PM, "Cameron Byrne" wrote: >On Feb 14, 2011 1:52 PM, "Mark Andrews" wrote: >> >> >> In message <4D597216.1030400 at brightok.net>, Jack Bates writes: >> > >> > >> > On 2/14/2011 12:12 PM, Cameron Byrne wrote: >> > > Too bad the article pushes my mobile device to their mobile site >> > > mobile.nytimes.com and that references an ipv4 literal for the >>picture >to >> > > load .... so not only is nytimes not ipv6 it is also broken for ipv6 >only >> > > users behind nat64 .... >> > >> > That's almost as bad as the hundreds of subdomains used in webpages >> > which sometimes hit broken load balancers (reporting nxdomain for >>AAAA). >> >> Very few do that anymore. What they do however is return the wrong SOA >> record. >> >> > So you have to check each and every domain in the source to find which >> > ones are broken. >> >> Which one really shouldn't have to do. Add DS-Lite support to the >> phone and have the carriers advertise that they support DS-Lite and >> the IPv4 literal problem goes away. >> >> This has been done in a phone already so it is possible to do. >> > >Ds-lite has been dismissed by 3gpp. Nytimes needs to start using fqdns and >ideally ipv6. Until then, it's their content that's being mangled. It is >not reasonable for network operators to engineer for amateur web >programming >mistakes > >Cb >> > Jack >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bill at herrin.us Mon Feb 14 20:41:17 2011 From: bill at herrin.us (William Herrin) Date: Mon, 14 Feb 2011 21:41:17 -0500 Subject: NIST and SP800-119 In-Reply-To: References: Message-ID: On Mon, Feb 14, 2011 at 7:24 PM, TR Shaw wrote: > Just wondering what this community thinks of NIST in > general and their SP800-119 ( > http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf ) > writeup about IPv6 in particular. Well, according to this document IPv4 path MTU discovery is, "optional, not widely used." -Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From david.binet at orange-ftgroup.com Tue Feb 15 03:48:50 2011 From: david.binet at orange-ftgroup.com (david.binet at orange-ftgroup.com) Date: Tue, 15 Feb 2011 10:48:50 +0100 Subject: NY Times on IPv4 depletion In-Reply-To: <20110214225259.B93DCA0C166@drugs.dv.isc.org> References: <4D597216.1030400@brightok.net> <20110214215239.E0671A09F98@drugs.dv.isc.org> <20110214225259.B93DCA0C166@drugs.dv.isc.org> Message-ID: <18493_1297763331_4D5A4C03_18493_67138_1_1B2E7539FECD9048B261B791B1B24A7C2994CE60F1@PUEXCB1A.nanterre.francetelecom.fr> Dear all, Actually I fully agree with Cameron. >From an operator point of view, it is quite difficult to rely on some specific functions in mobile, besides an IPv6 stack - that is already difficult to get if we have a look on IPv6-ready devices available on market. I do not know how we can mandate some DS-lite functions in devices, for example, as far as there is no document where 3GPP devices are "specified". So, it is not possible to set up some IPv6 introduction strategy based on some solutions integrated in devices. In mobile context, I think it is more adapted to encourage IPv6 native communications and to rely on NAT64 for IPv4-only appls access even if we all know that such translation solution has some drawbacks. David > -----Message d'origine----- > De : Mark Andrews [mailto:marka at isc.org] > Envoy? : lundi 14 f?vrier 2011 23:53 > ? : Cameron Byrne > Cc : North American Network Operators Group > Objet : Re: NY Times on IPv4 depletion > > > In message > > , Came ron Byrne writes: > > --00163630f77d957e25049c454dc0 > > Content-Type: text/plain; charset=ISO-8859-1 > > > > On Feb 14, 2011 1:52 PM, "Mark Andrews" wrote: > > > > > > > > > In message <4D597216.1030400 at brightok.net>, Jack Bates writes: > > > > > > > > > > > > On 2/14/2011 12:12 PM, Cameron Byrne wrote: > > > > > Too bad the article pushes my mobile device to their > mobile site > > > > > mobile.nytimes.com and that references an ipv4 > literal for the > > > > > picture > > to > > > > > load .... so not only is nytimes not ipv6 it is also > broken for > > > > > ipv6 > > only > > > > > users behind nat64 .... > > > > > > > > That's almost as bad as the hundreds of subdomains used in > > > > webpages which sometimes hit broken load balancers > (reporting nxdomain for AAAA). > > > > > > Very few do that anymore. What they do however is return > the wrong > > > SOA record. > > > > > > > So you have to check each and every domain in the > source to find > > > > which ones are broken. > > > > > > Which one really shouldn't have to do. Add DS-Lite > support to the > > > phone and have the carriers advertise that they support > DS-Lite and > > > the IPv4 literal problem goes away. > > > > > > This has been done in a phone already so it is possible to do. > > > > > > > Ds-lite has been dismissed by 3gpp. Nytimes needs to start > using fqdns > > and ideally ipv6. Until then, it's their content that's being > > mangled. It is not reasonable for network operators to engineer for > > amateur web programming mistakes > > It still doesn't stop handest manufatures adding DS-Lite > support and operators responding to the DHCP option so the > handsets can find the AFTR box. > > NAT64/DNS64 may be the only operator side only solution but > it has lots of limitation to it and it can't be made to work > as well has DS-Lite even once the handset know the DNS64 > prefix and BIH is added to translate IPv4 to IPv6 inside the > handset using the DNS64 prefix. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > ********************************* This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ******************************** From iljitsch at muada.com Tue Feb 15 04:08:01 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 15 Feb 2011 11:08:01 +0100 Subject: quietly.... In-Reply-To: <007401cbcc0a$96ca9830$c45fc890$@iname.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <007401cbcc0a$96ca9830$c45fc890$@iname.com> Message-ID: <97EF8D2D-B47C-44FB-94B0-816C998F9A1C@muada.com> On 14 feb 2011, at 6:46, Frank Bulk wrote: > Requiring them to be on certain well known addresses is restrictive and > creates an unnecessary digression from IPv4 practice. It's comments like > this that raise the hair on admins' necks. At least mine. I don't get this. Why spend cycles discovering a value that doesn't need to change? But I lost this argument in the IETF years ago, so I guess I'm relatively alone here. From Mauricio.Rodriguez at fpl.com Tue Feb 15 09:02:02 2011 From: Mauricio.Rodriguez at fpl.com (Rodriguez, Mauricio) Date: Tue, 15 Feb 2011 10:02:02 -0500 Subject: Recommendations for Outsourced Support for Cacti? Message-ID: <611085D375448C4D99BAF870659DEAC421B028FB2F@GOXEXVS03.fplu.fpl.com> Couldn't help but notice all the Cacti screens open during NANOG51. We have also implemented Cacti for our data collection and trend analysis needs. Recently, support of our Cacti implementation, both server/OS and app, was handed off to another group within my company. This sparked an interest in finding a firm that could help us going forward with support, customization, maintenance/upgrades, etc. Does anyone out there use such a firm for support that they would be willing to recommend? Kind Regards, Mauricio Rodriguez, NRS1 | Data Network Architect, Peering Coordinator 9250 W Flagler St, Miami, FL 33174 | www.FPLFiberNet.com From jabley at hopcount.ca Tue Feb 15 09:09:37 2011 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 15 Feb 2011 10:09:37 -0500 Subject: NIST and SP800-119 In-Reply-To: References: Message-ID: <0DCE3E24-A879-41DC-958D-99BC5DD57784@hopcount.ca> On 2011-02-14, at 21:41, William Herrin wrote: > On Mon, Feb 14, 2011 at 7:24 PM, TR Shaw wrote: >> Just wondering what this community thinks of NIST in >> general and their SP800-119 ( >> http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf ) >> writeup about IPv6 in particular. > > Well, according to this document IPv4 path MTU discovery is, > "optional, not widely used." Optional seems right. Have there been any recent studies on how widely pMTUd is actually used in v4? More contentious is that Path MTU discovery is "strongly recommended" in IPv6. Surely it's mandatory whenever you're exchanging datagrams larger than 1280 octets? Otherwise the sender can't fragment. Joe From bill at herrin.us Tue Feb 15 09:36:54 2011 From: bill at herrin.us (William Herrin) Date: Tue, 15 Feb 2011 10:36:54 -0500 Subject: NIST and SP800-119 In-Reply-To: <0DCE3E24-A879-41DC-958D-99BC5DD57784@hopcount.ca> References: <0DCE3E24-A879-41DC-958D-99BC5DD57784@hopcount.ca> Message-ID: On Tue, Feb 15, 2011 at 10:09 AM, Joe Abley wrote: > On 2011-02-14, at 21:41, William Herrin wrote: >> On Mon, Feb 14, 2011 at 7:24 PM, TR Shaw wrote: >>> Just wondering what this community thinks of NIST in >>> general and their SP800-119 ( >>> http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf ) >>> writeup about IPv6 in particular. >> >> Well, according to this document IPv4 path MTU discovery is, >> "optional, not widely used." > > Optional seems right. Have there been any recent studies on how widely pMTUd is actually used in v4? Hi Joe, Are you aware of a TCP implementation in an OS that shipped within the last decade but doesn't enable IPv4 pMTUd by default? Each version of Windows and all the major unixes use it on every TCP connection unless you explicitly turn it off. Regards, Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jabley at hopcount.ca Tue Feb 15 10:06:09 2011 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 15 Feb 2011 11:06:09 -0500 Subject: NIST and SP800-119 In-Reply-To: References: <0DCE3E24-A879-41DC-958D-99BC5DD57784@hopcount.ca> Message-ID: On 2011-02-15, at 10:36, William Herrin wrote: > Are you aware of a TCP implementation in an OS that shipped within the > last decade but doesn't enable IPv4 pMTUd by default? I am not, but I'd still be vaguely interested in an actual study :-) The last time I tangled with v4 pMTUd it actually was a decade or more ago. At that time wholesale ICMP blocking caused all kinds of problems for clients with a sub-ethernet MTU in their path. If the world has moved on, that seems good :-) Joe From smb at cs.columbia.edu Tue Feb 15 10:22:20 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Tue, 15 Feb 2011 11:22:20 -0500 Subject: NIST and SP800-119 In-Reply-To: References: <0DCE3E24-A879-41DC-958D-99BC5DD57784@hopcount.ca> Message-ID: <4969A10C-621E-4F28-85A3-B1FA3F974D60@cs.columbia.edu> On Feb 15, 2011, at 10:36 54AM, William Herrin wrote: > On Tue, Feb 15, 2011 at 10:09 AM, Joe Abley wrote: >> On 2011-02-14, at 21:41, William Herrin wrote: >>> On Mon, Feb 14, 2011 at 7:24 PM, TR Shaw wrote: >>>> Just wondering what this community thinks of NIST in >>>> general and their SP800-119 ( >>>> http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf ) >>>> writeup about IPv6 in particular. >>> >>> Well, according to this document IPv4 path MTU discovery is, >>> "optional, not widely used." >> >> Optional seems right. Have there been any recent studies on how widely pMTUd is actually used in v4? > > Hi Joe, > > Are you aware of a TCP implementation in an OS that shipped within the > last decade but doesn't enable IPv4 pMTUd by default? Each version of > Windows and all the major unixes use it on every TCP connection unless > you explicitly turn it off. > All modern TCPs support it; many firewalls are configured to block the necessary ICMPs. --Steve Bellovin, http://www.cs.columbia.edu/~smb From mohacsi at niif.hu Tue Feb 15 10:46:01 2011 From: mohacsi at niif.hu (Mohacsi Janos) Date: Tue, 15 Feb 2011 17:46:01 +0100 (CET) Subject: NIST and SP800-119 In-Reply-To: <4969A10C-621E-4F28-85A3-B1FA3F974D60@cs.columbia.edu> References: <0DCE3E24-A879-41DC-958D-99BC5DD57784@hopcount.ca> <4969A10C-621E-4F28-85A3-B1FA3F974D60@cs.columbia.edu> Message-ID: On Tue, 15 Feb 2011, Steven Bellovin wrote: > > On Feb 15, 2011, at 10:36 54AM, William Herrin wrote: > >> On Tue, Feb 15, 2011 at 10:09 AM, Joe Abley wrote: >>> On 2011-02-14, at 21:41, William Herrin wrote: >>>> On Mon, Feb 14, 2011 at 7:24 PM, TR Shaw wrote: >>>>> Just wondering what this community thinks of NIST in >>>>> general and their SP800-119 ( >>>>> http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf ) >>>>> writeup about IPv6 in particular. >>>> >>>> Well, according to this document IPv4 path MTU discovery is, >>>> "optional, not widely used." >>> >>> Optional seems right. Have there been any recent studies on how widely pMTUd is actually used in v4? >> >> Hi Joe, >> >> Are you aware of a TCP implementation in an OS that shipped within the >> last decade but doesn't enable IPv4 pMTUd by default? Each version of >> Windows and all the major unixes use it on every TCP connection unless >> you explicitly turn it off. >> > All modern TCPs support it; many firewalls are configured to block the necessary ICMPs. Then probably blackholing themselves the firewall operators.... Best Regards, Janos Mohacsi From davei at otd.com Tue Feb 15 11:28:13 2011 From: davei at otd.com (David Israel) Date: Tue, 15 Feb 2011 12:28:13 -0500 Subject: quietly.... In-Reply-To: <97EF8D2D-B47C-44FB-94B0-816C998F9A1C@muada.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <007401cbcc0a$96ca9830$c45fc890$@iname.com> <97EF8D2D-B47C-44FB-94B0-816C998F9A1C@muada.com> Message-ID: <4D5AB7AD.9010604@otd.com> On 2/15/2011 5:08 AM, Iljitsch van Beijnum wrote: > On 14 feb 2011, at 6:46, Frank Bulk wrote: > >> Requiring them to be on certain well known addresses is restrictive and >> creates an unnecessary digression from IPv4 practice. It's comments like >> this that raise the hair on admins' necks. At least mine. > I don't get this. Why spend cycles discovering a value that doesn't need to change? Because it will change. At some point, this paradigm will shift. The service hierarchy will change, the protocol methodology will change, the network topology will change... *something* will happen that will make a well-known address, hard-coded in a million places, change from a boon to a massive headache. One of the biggest problem v6 seems to have had is that its designers seemed to think the problem with v4 was that it didn't have enough features. They then took features from protocols that ipv4 had killed over the years, and added them to v6, and said, "Look, I made your new IP better." And then, when the operators groaned and complained and shook their heads, the ipv6 folks called them "backward" and "stuck in ipv4-think." But the fact of the matter is, operators want a protocol to be as simple, efficient, flexible, and stupid as possible. They don't want the protocol tied to how things work today; it needs to be open to innovation and variety. And part of that is that an address needs to be just an address, with no other significance other than being unique and routable. The moment an address has any significance beyond the network layer, it's a liability waiting to happen. From jbates at brightok.net Tue Feb 15 11:38:43 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 15 Feb 2011 11:38:43 -0600 Subject: quietly.... In-Reply-To: <4D5AB7AD.9010604@otd.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <007401cbcc0a$96ca9830$c45fc890$@iname.com> <97EF8D2D-B47C-44FB-94B0-816C998F9A1C@muada.com> <4D5AB7AD.9010604@otd.com> Message-ID: <4D5ABA23.2010506@brightok.net> On 2/15/2011 11:28 AM, David Israel wrote: > They don't want the protocol tied to how things work today; it needs to > be open to innovation and variety. And part of that is that an address > needs to be just an address, with no other significance other than being > unique and routable. The moment an address has any significance beyond > the network layer, it's a liability waiting to happen. +1 The rare exception being multicast. :) Jack From Valdis.Kletnieks at vt.edu Tue Feb 15 11:41:26 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 15 Feb 2011 12:41:26 -0500 Subject: quietly.... In-Reply-To: Your message of "Tue, 15 Feb 2011 11:08:01 +0100." <97EF8D2D-B47C-44FB-94B0-816C998F9A1C@muada.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <007401cbcc0a$96ca9830$c45fc890$@iname.com> <97EF8D2D-B47C-44FB-94B0-816C998F9A1C@muada.com> Message-ID: <17205.1297791686@localhost> On Tue, 15 Feb 2011 11:08:01 +0100, Iljitsch van Beijnum said: > On 14 feb 2011, at 6:46, Frank Bulk wrote: > > Requiring them to be on certain well known addresses is restrictive and > > creates an unnecessary digression from IPv4 practice. It's comments like > > this that raise the hair on admins' necks. At least mine. > I don't get this. Why spend cycles discovering a value that doesn't need > to change? You've obviously never had to change a number in a /etc/resolv.conf because the number you've listed has gone bat-guano insane. If the root DNS address becomes a magic IP address (presumably some variety of anycast), it becomes a lot harder to change to another address if the closest anycast address goes insane. If root nameserver F (or merely the anycast instance I can see) goes bonkers(*), I can say "screw this, ask G and K instead". You can't do that if G and K are the same magic address as F. (*) "bonkers" for whatever operational definition you want - wedged hardware, corrupted database, coercion by men with legal documents and firearms, whatever. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jbates at brightok.net Tue Feb 15 11:50:21 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 15 Feb 2011 11:50:21 -0600 Subject: quietly.... In-Reply-To: <17205.1297791686@localhost> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <007401cbcc0a$96ca9830$c45fc890$@iname.com> <97EF8D2D-B47C-44FB-94B0-816C998F9A1C@muada.com> <17205.1297791686@localhost> Message-ID: <4D5ABCDD.2090706@brightok.net> On 2/15/2011 11:41 AM, Valdis.Kletnieks at vt.edu wrote: > (*) "bonkers" for whatever operational definition you want - wedged hardware, > corrupted database, coercion by men with legal documents and firearms, whatever. Route injected by foreign parties into BGP. Also a reason not to have them even close together. Jack From packetjockey at gmail.com Tue Feb 15 14:43:52 2011 From: packetjockey at gmail.com (Rafael Rodriguez) Date: Tue, 15 Feb 2011 15:43:52 -0500 Subject: NIST and SP800-119 In-Reply-To: References: Message-ID: I've spent some time reading through it over the past couple of days and it seems to be very good so far (have read up to end of section 3). On Mon, Feb 14, 2011 at 7:24 PM, TR Shaw wrote: > Just wondering what this community thinks of NIST in general and their > SP800-119 ( > http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf ) writeup > about IPv6 in particular. > > > > From jared at puck.nether.net Tue Feb 15 15:31:07 2011 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 15 Feb 2011 16:31:07 -0500 Subject: NIST and SP800-119 In-Reply-To: References: <0DCE3E24-A879-41DC-958D-99BC5DD57784@hopcount.ca> Message-ID: <5871B737-B4F2-4512-B450-8EF3EF364FDD@puck.nether.net> On Feb 15, 2011, at 10:36 AM, William Herrin wrote: > On Tue, Feb 15, 2011 at 10:09 AM, Joe Abley wrote: >> On 2011-02-14, at 21:41, William Herrin wrote: >>> On Mon, Feb 14, 2011 at 7:24 PM, TR Shaw wrote: >>>> Just wondering what this community thinks of NIST in >>>> general and their SP800-119 ( >>>> http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf ) >>>> writeup about IPv6 in particular. >>> >>> Well, according to this document IPv4 path MTU discovery is, >>> "optional, not widely used." >> >> Optional seems right. Have there been any recent studies on how widely pMTUd is actually used in v4? > > Hi Joe, > > Are you aware of a TCP implementation in an OS that shipped within the > last decade but doesn't enable IPv4 pMTUd by default? Each version of > Windows and all the major unixes use it on every TCP connection unless > you explicitly turn it off. IOS does not support it unless explicitly turned on. It will result in decreased network performance for some things (eg: BGP Updates) as the negotiated mss will be really small. They likely don't want to change some sacred default either as it would break other things. If you run larger than ~500 mtus internally, you may want to enable 'ip tcp path-mtu-discovery' and watch your BGP convergence improve significantly. Router#sh ip bgp neighbors | inc max data segment Broken setups will show something like this: Datagrams (max data segment is 1240 bytes): Datagrams (max data segment is 516 bytes): Datagrams (max data segment is 536 bytes): Others may show something much larger depending on your infrastructure. IMHO, path-mtu-discovery is REQUIRED, not optional. Anyone saying otherwise has a broken network and you should not give them your money. - Jared From tbraning at gmail.com Tue Feb 15 17:04:32 2011 From: tbraning at gmail.com (Todd Braning) Date: Tue, 15 Feb 2011 16:04:32 -0700 Subject: SmartNet Alternatives In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13A7C@RWC-EX1.corp.seven.com> References: <060EDFC2221B014B9504AC06B747F58A499BCC3B57@ex01.alentus.lan> <6EFFEFBAC68377459A2E972105C759EC036456FC@EXVBE005-2.exch005intermedia.net> <87pqqvfzuj.fsf@mid.deneb.enyo.de> <5A6D953473350C4B9995546AFE9939EE0BC13A7C@RWC-EX1.corp.seven.com> Message-ID: I know NHR has a alternative that looks to be comparable. http://www.networkhardware.com/Maintenance/ -tb From wavetossed at googlemail.com Tue Feb 15 21:25:09 2011 From: wavetossed at googlemail.com (Michael Dillon) Date: Tue, 15 Feb 2011 19:25:09 -0800 Subject: quietly.... In-Reply-To: <4D5AB7AD.9010604@otd.com> References: <1150298540.1443.1296591043065.JavaMail.root@zimbra.network1.net> <4D486C0F.7050804@otd.com> <0A77875D-59A4-422A-A5D4-116A0C5EE536@delong.com> <1296603710.12449.19.camel@karl> <20110202022456.GA3142@hiwaay.net> <4D48D4BA.5010005@otd.com> <83A5D662-4055-4A0D-A62A-5F6552E46F20@muada.com> <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com> <5CF16AD6-DDCC-4A72-AD30-9DFC653A0B6D@muada.com> <007401cbcc0a$96ca9830$c45fc890$@iname.com> <97EF8D2D-B47C-44FB-94B0-816C998F9A1C@muada.com> <4D5AB7AD.9010604@otd.com> Message-ID: > One of the biggest problem v6 seems to have had is that its designers seemed > to think the problem with v4 was that it didn't have enough features. ?They > then took features from protocols that ipv4 had killed over the years, and > added them to v6, and said, "Look, I made your new IP better." ?And then, > when the operators groaned and complained and shook their heads, the ipv6 > folks called them "backward" and "stuck in ipv4-think." ?But the fact of the > matter is, operators want a protocol to be as simple, efficient, flexible, > and stupid as possible. ?They don't want the protocol tied to how things > work today; it needs to be open to innovation and variety. This sounds a lot like bellhead speak. The fact is that IP of any version was made for the users of network, not just for the privileged few who operate them. Compromises had to be made so, in the end, IPv6 is not perfect. But why should it be? There is a process for changing and updating IPv6. Use it! But implement what we have now as best you can. From jra at baylink.com Tue Feb 15 22:57:46 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 15 Feb 2011 23:57:46 -0500 (EST) Subject: quietly.... In-Reply-To: Message-ID: <11445089.286.1297832266043.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Michael Dillon" > > folks called them "backward" and "stuck in ipv4-think." But the fact > > of the matter is, operators want a protocol to be as simple, efficient, > > flexible, and stupid as possible. They don't want the protocol tied to how > > things work today; it needs to be open to innovation and variety. > > This sounds a lot like bellhead speak. As a long time fan of David Isen, I almost fell off my chair laughing at that, Michael: Bell *wanted* things -- specifically the network -- smart and complicated; Isen's POV, which got him... well, I don't know if "laughed out of" AT&T is the right way to phrase it, but it's close enough, was: Stupid network; smart endpoints. That seems entirely compatible with the proposed preference for IPv6 which you dismiss above as Bellhead. Cheers, -- jra From joly at punkcast.com Tue Feb 15 23:15:12 2011 From: joly at punkcast.com (Joly MacFie) Date: Wed, 16 Feb 2011 00:15:12 -0500 Subject: =?windows-1252?Q?NYTimes=3A_Egypt_Leaders_Found_=91Off=92_Switch_for_In?= =?windows-1252?Q?ternet?= Message-ID: http://www.nytimes.com/2011/02/16/technology/16internet.html There has been intense debate both inside and outside Egypt on whether the > cutoff at 26 Ramses Street was accomplished by surgically tampering with the > software mechanism that defines how networks at the core of the Internet > communicate with one another, or by a blunt approach: simply cutting off the > power to the router computers that connect Egypt to the outside world. -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org --------------------------------------------------------------- From frnkblk at iname.com Tue Feb 15 23:40:26 2011 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 15 Feb 2011 23:40:26 -0600 Subject: IPv6 is on the marketers radar In-Reply-To: <22074840.663.1297677419591.JavaMail.franck@franck-martins-macbook-pro.local> References: <22074840.663.1297677419591.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <00a001cbcd9c$0373bce0$0a5b36a0$@iname.com> See my notes on the WNDR3700v2 here: http://www.getipv6.info/index.php/Broadband_CPE#Routers.2FWireless_Access_Points If someone has a suggestion for additional testing, please let me know. Frank -----Original Message----- From: Franck Martin [mailto:franck at genius.com] Sent: Monday, February 14, 2011 3:57 AM To: Michael Dillon Cc: nanog at nanog.org Subject: Re: IPv6 is on the marketers radar ----- Original Message ----- > From: "Michael Dillon" > To: nanog at nanog.org > Sent: Monday, 14 February, 2011 10:37:51 AM > Subject: Re: IPv6 is on the marketers radar > > It's bad that home gateways need replacing > > It's not neccessarily bad. There are a lot of older devices out there > and technology has progressed a couple of generations since then. That > spells market opportunity for manufacturers of IPv6 gateways, > particularly at the higher end of the market where the impact of the > recession has not hit as hard. And given that a gateway is a box > running Linux with some network interfaces, there is an opportunity > for added features, maybe even so far as an Android style apps market. > > The general public is now learning that the Internet is going through > a transition and that IPv6 is future proof. The smart money would now > be putting gateways on the market to sell to early adopters. And the > creative money would be looking for a way to link the IPv6 gateways > with an IPv6 home server that runs apps from an apps market. Those > apps could be anything from a backup of your blog to a SIP PABX. > > --Michael Dillon > > P.S. if anyone has money to invest, contact me and let's talk. one new box nearly every year: http://fr.wikipedia.org/wiki/Freebox IPv6 available since 2007: http://www.zdnet.fr/actualites/la-freebox-adopte-l-ipv6-et-se-mue-en-serveur-d-impression-39376502.htm From mansaxel at besserwisser.org Wed Feb 16 01:21:43 2011 From: mansaxel at besserwisser.org (Mans Nilsson) Date: Wed, 16 Feb 2011 08:21:43 +0100 Subject: NIST and SP800-119 In-Reply-To: References: <0DCE3E24-A879-41DC-958D-99BC5DD57784@hopcount.ca> <4969A10C-621E-4F28-85A3-B1FA3F974D60@cs.columbia.edu> Message-ID: <20110216072143.GH10240@besserwisser.org> Subject: Re: NIST and SP800-119 Date: Tue, Feb 15, 2011 at 05:46:01PM +0100 Quoting Mohacsi Janos (mohacsi at niif.hu): > >All modern TCPs support it; many firewalls are configured to block the necessary ICMPs. > > Then probably blackholing themselves the firewall operators.... And the replies when you try to fix it simmer with contempt for those so unresponsible as to even contemplate allowing any ICMP at all. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Where's the Coke machine? Tell me a joke!! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From dotis at mail-abuse.org Wed Feb 16 01:44:11 2011 From: dotis at mail-abuse.org (Douglas Otis) Date: Wed, 16 Feb 2011 15:44:11 +0800 Subject: NIST and SP800-119 In-Reply-To: <0DCE3E24-A879-41DC-958D-99BC5DD57784@hopcount.ca> References: <0DCE3E24-A879-41DC-958D-99BC5DD57784@hopcount.ca> Message-ID: <4D5B804B.7020408@mail-abuse.org> On 2/15/11 11:09 PM, Joe Abley wrote: > On 2011-02-14, at 21:41, William Herrin wrote: >> On Mon, Feb 14, 2011 at 7:24 PM, TR Shaw wrote: >>> Just wondering what this community thinks of NIST in >>> general and their SP800-119 ( >>> http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf ) >>> writeup about IPv6 in particular. >> Well, according to this document IPv4 path MTU discovery is, >> "optional, not widely used." > Optional seems right. Have there been any recent studies on how widely pMTUd is actually used in v4? > > More contentious is that Path MTU discovery is "strongly recommended" in IPv6. Surely it's mandatory whenever you're exchanging datagrams larger than 1280 octets? Otherwise the sender can't fragment. Routers indicate local MTUs, but minimum MTUs are not assured to have 1280 octets when IPv4 translation is involved. See Section 5 in rfc2460. (1280 minus 40 for the IPv6 header and 8 for the Fragment header.) Bill suggested this could even be smaller. This also ignores likely limited resources to resolve addresses within a /64. Public facing servers might be placed into much smaller ranges to avoid supporting 16M multicast. Also there might be a need to limit ICMPv6 functions as well, depending upon the features found in layer-2 switches. -Doug From cdel at firsthand.net Wed Feb 16 02:43:41 2011 From: cdel at firsthand.net (Christian de Larrinaga) Date: Wed, 16 Feb 2011 09:43:41 +0100 Subject: SmartNet Alternatives In-Reply-To: <7083ccea-25ae-434e-9b05-234a9e8fe4a4@zimbra.network1.net> References: <7083ccea-25ae-434e-9b05-234a9e8fe4a4@zimbra.network1.net> Message-ID: <7A58D590-964F-4D16-97A3-9489CCD1E16A@firsthand.net> Can anybody point to dependable analysis of the performance credentials on "green" (CO2/carbon neutral, recycling, etc) and financial cost recovery of the Internet vendors such Juniper and Cisco et al? The story emerging here is not looking very encouraging. Christian On 13 Feb 2011, at 21:54, Randy Carpenter wrote: >> How does Juniper feel about used hardware? >> >> ~Seth > > I love Juniper's hardware and software, and support. However, the way they deal with used or second hand hardware is terrible. It is not possible to transfer ownership at all. You can not resell anything, and hope to get any software updates or support. The challenge is that Cisco refurb with SmartNet is generally considerably cheaper than new Juniper. It makes it tough to sell Juniper in many situations. We have the same problem with NetApp. It seems that these companies would rather see their equipment end up in a landfill, and have the secondary market turn to a different vendor, rather than being responsible, and making it possible for equipment to be reused instead of trashed. It really annoys me. > > Disclaimer: I am a Juniper and NetApp partner/reseller, and love their stuff. I just hate their policies. > > -Randy > From neil at domino.org Wed Feb 16 03:56:05 2011 From: neil at domino.org (Neil J. McRae) Date: Wed, 16 Feb 2011 03:56:05 -0600 (CST) Subject: SmartNet Alternatives In-Reply-To: References: <060EDFC2221B014B9504AC06B747F58A499BCC3B57@ex01.alentus.lan> <5A6D953473350C4B9995546AFE9939EE0BC13A7C@RWC-EX1.corp.seven.com> <6EFFEFBAC68377459A2E972105C759EC036456FC@EXVBE005-2.exch005intermedia .net> <87pqqvfzuj.fsf@mid.deneb.enyo.de> Message-ID: <1297850165.v2.mailanyonewebmail-761213@fuseweb2d> I've used NHR for a number of deployments over the past couple of years and they are a fantastic organisation to work with. I've used them for maintenance support in the US for replacement of parts - highly recommended. ----- Original Message ----- From: tbraning at gmail.com Sent: Tue, February 15, 2011, 11:04 PM Subject: Re: SmartNet Alternatives I know NHR has a alternative that looks to be comparable. http://www.networkhardware.com/Maintenance/ -tb From tme at americafree.tv Wed Feb 16 08:09:47 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Wed, 16 Feb 2011 09:09:47 -0500 Subject: =?windows-1252?Q?Re:_NYTimes:_Egypt_Leaders_Found_=91Off=92_Swit?= =?windows-1252?Q?ch_for_Internet?= In-Reply-To: References: Message-ID: <7F7401DE-390B-41F9-8B09-F920FBBC637A@americafree.tv> On Feb 16, 2011, at 12:15 AM, Joly MacFie wrote: > http://www.nytimes.com/2011/02/16/technology/16internet.html > > There has been intense debate both inside and outside Egypt on whether the >> cutoff at 26 Ramses Street was accomplished by surgically tampering with the >> software mechanism that defines how networks at the core of the Internet >> communicate with one another, or by a blunt approach: simply cutting off the >> power to the router computers that connect Egypt to the outside world. > > I do remember some intense debate, here and elsewhere, but I somehow don't remember those as being the primary debate parameters. Regards Marshall > -- > --------------------------------------------------------------- > Joly MacFie 218 565 9365 Skype:punkcast > WWWhatsup NYC - http://wwwhatsup.com > http://pinstand.com - http://punkcast.com > VP (Admin) - ISOC-NY - http://isoc-ny.org > --------------------------------------------------------------- > From jabley at hopcount.ca Wed Feb 16 08:57:23 2011 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 16 Feb 2011 09:57:23 -0500 Subject: NIST and SP800-119 In-Reply-To: <4D5B804B.7020408@mail-abuse.org> References: <0DCE3E24-A879-41DC-958D-99BC5DD57784@hopcount.ca> <4D5B804B.7020408@mail-abuse.org> Message-ID: On 2011-02-16, at 02:44, Douglas Otis wrote: > Routers indicate local MTUs, but minimum MTUs are not assured to have 1280 octets when IPv4 translation is involved. > See Section 5 in rfc2460. I've heard that interpretation of 2460 before from Bill Manning, but I still don't see it myself. The text seems fairly clear that 1280 is the minimum MTU for any interface, regardless of the type of interface (tunnel, PPP, whatever). In particular, Links that have a configurable MTU (for example, PPP links [RFC- 1661]) must be configured to have an MTU of at least 1280 octets; it is recommended that they be configured with an MTU of 1500 octets or greater, to accommodate possible encapsulations (i.e., tunneling) without incurring IPv6-layer fragmentation. That same section indicates that pMTUd is strongly recommended in IPv6 rather than mandatory, but in the context of embedded devices that can avoid implementing pMTUd by never sending a packet larger than the minimum MTU. Such devices would break if there was an interface (of any kind) in the path with a sub-1280 MTU. Joe From millnert at gmail.com Wed Feb 16 13:28:22 2011 From: millnert at gmail.com (Martin Millnert) Date: Wed, 16 Feb 2011 14:28:22 -0500 Subject: =?windows-1252?Q?Re=3A_NYTimes=3A_Egypt_Leaders_Found_=91Off=92_Switch_fo?= =?windows-1252?Q?r_Internet?= In-Reply-To: <7F7401DE-390B-41F9-8B09-F920FBBC637A@americafree.tv> References: <7F7401DE-390B-41F9-8B09-F920FBBC637A@americafree.tv> Message-ID: On Wed, Feb 16, 2011 at 9:09 AM, Marshall Eubanks wrote: > > On Feb 16, 2011, at 12:15 AM, Joly MacFie wrote: > >> http://www.nytimes.com/2011/02/16/technology/16internet.html >> >> There has been intense debate both inside and outside Egypt on whether the >>> cutoff at 26 Ramses Street was accomplished by surgically tampering with the >>> software mechanism that defines how networks at the core of the Internet >>> communicate with one another, or by a blunt approach: simply cutting off the >>> power to the router computers that connect Egypt to the outside world. >> > > I do remember some intense debate, here and elsewhere, but I somehow don't remember those as being the primary debate parameters. Interesting article though. There are several good pieces to take-away from that article (not really 'news', but still healthy with the occasional refresher): "Individual Internet service providers were also called on the carpet and ordered to shut down, as they are required to do by their licensing agreements if the government so decrees." "When he, too, noticed that domestic fiber-optic cables were open, he had a moment of exhilaration, remembering that he could link up servers directly and establish messaging using an older system called Internet Relay Chat. But then it dawned on him that he had always assumed he could download the necessary software via the Internet and had saved no copy." Operating local IRC networks is good, as is having local OS mirrors, such as Debian/Ubuntu and let's not forget, having a resilient DNS configuration (root zone copy hint 101: "dig @k.root-servers.net. . axfr"). A securely distributed "network-contingency-plan-autocrat-generic-all.deb" could be useful, as well. Cheers, Martin From franck at genius.com Wed Feb 16 13:50:04 2011 From: franck at genius.com (Franck Martin) Date: Thu, 17 Feb 2011 08:50:04 +1300 (FJST) Subject: =?utf-8?Q?Local_root_zone_(Was_NYTimes:_Egypt_Le?= =?utf-8?Q?aders_Found_=E2=80=98Off=E2=80=99_Switch_for_Internet)?= In-Reply-To: Message-ID: <26249556.338.1297885804108.JavaMail.franck@franck-martins-macbook-pro.local> ----- Original Message ----- > From: "Martin Millnert" > To: "Marshall Eubanks" > Cc: "North American Network Operators Group" > Sent: Thursday, 17 February, 2011 8:28:22 AM > Subject: Re: NYTimes: Egypt Leaders Found ?Off? Switch for Internet > On Wed, Feb 16, 2011 at 9:09 AM, Marshall Eubanks > wrote: > > > > On Feb 16, 2011, at 12:15 AM, Joly MacFie wrote: > > " > > Operating local IRC networks is good, as is having local OS mirrors, > such as Debian/Ubuntu and let's not forget, having a resilient DNS > configuration (root zone copy hint 101: "dig @k.root-servers.net. . > axfr"). A securely distributed Would it make sense for an ISP to "store" the root zone on their DNS servers instead of letting it be refreshed by the DNS cache? A cron job could refresh it from time to time. It would avoid entries from expiring and would always serve to clients entries with max ttl? A root server would be better, but that could be an intermediary step? Just speaking out loud here, so it may be total non-sense... From jcurran at arin.net Wed Feb 16 15:00:27 2011 From: jcurran at arin.net (John Curran) Date: Wed, 16 Feb 2011 21:00:27 +0000 Subject: Fwd: [arin-announce] IN-ADDR.ARPA Zone Transfer Complete References: <4D5C3952.1080602@arin.net> Message-ID: Apologies for cross-posting, but I believe this relevant to the NANOG operator community. FYI, /John Begin forwarded message: From: ARIN > Date: February 16, 2011 3:53:38 PM EST To: > Subject: [arin-announce] IN-ADDR.ARPA Zone Transfer Complete Today ARIN and ICANN are jointly working on the transition of the technical management function for the IN-ADDR.ARPA zone from ARIN to ICANN. ARIN carried out the DNS zone maintenance function for IN-ADDR.ARPA since 1997 and worked closed with ICANN throughout the transition period. Immediately upon transfer to ICANN, the IN-ADDR.ARPA zone will also be signed using DNS Security Extensions (DNSSEC), providing end-users with the ability to validate answers to reverse DNS queries. The IN-ADDR.ARPA zone is also in the process of being moved from twelve root servers to dedicated nameservers operated by the five Regional Internet Registries (RIRs) and one operated by ICANN. For more details on the history of this transition please see . Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From dougb at dougbarton.us Wed Feb 16 15:22:05 2011 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 16 Feb 2011 13:22:05 -0800 Subject: =?windows-1252?Q?Re=3A_Local_root_zone_=28Was_NYTimes=3A?= =?windows-1252?Q?_Egypt_Leaders_Found_=91Off=92_Switch_for_?= =?windows-1252?Q?Internet=29?= In-Reply-To: <26249556.338.1297885804108.JavaMail.franck@franck-martins-macbook-pro.local> References: <26249556.338.1297885804108.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4D5C3FFD.10905@dougbarton.us> On 02/16/2011 11:50, Franck Martin wrote: > > > ----- Original Message ----- >> From: "Martin Millnert" >> To: "Marshall Eubanks" >> Cc: "North American Network Operators Group" >> Sent: Thursday, 17 February, 2011 8:28:22 AM >> Subject: Re: NYTimes: Egypt Leaders Found ?Off? Switch for Internet >> On Wed, Feb 16, 2011 at 9:09 AM, Marshall Eubanks >> wrote: >>> >>> On Feb 16, 2011, at 12:15 AM, Joly MacFie wrote: >>> > " >> >> Operating local IRC networks is good, as is having local OS mirrors, >> such as Debian/Ubuntu and let's not forget, having a resilient DNS >> configuration (root zone copy hint 101: "dig @k.root-servers.net. . >> axfr"). A securely distributed > > Would it make sense for an ISP to "store" the root zone on their DNS servers instead of letting it be refreshed by the DNS cache? A cron job could refresh it from time to time. It would avoid entries from expiring and would always serve to clients entries with max ttl? > > A root server would be better, but that could be an intermediary step? > > Just speaking out loud here, so it may be total non-sense... This is a subject of intense debate amongst the DNS literati: CON: 1. Failure to pay attention to your setup could cause you to have a stale root zone. PRO: 1. Faster local resolution for your users, especially for malformed queries. 2. No spurious traffic will be sent from your network to the roots 3. Greater resilience to any potential root server failure/DDoS Personally I've been doing it for years, never had a problem. On larger sites where I have a lot of resolvers I make the hidden master a slave for the root zone, and also allow the local resolvers to slave it from the hidden master to be more net.friendly. For BIND, make sure you include "notify no;" in your zone{} statement. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From fred at cisco.com Wed Feb 16 15:25:13 2011 From: fred at cisco.com (Fred Baker) Date: Wed, 16 Feb 2011 13:25:13 -0800 Subject: =?windows-1252?Q?Re=3A_Local_root_zone_=28Was_NYTimes=3A_Egypt_L?= =?windows-1252?Q?eaders_Found_=91Off=92_Switch_for_Internet=29?= In-Reply-To: <26249556.338.1297885804108.JavaMail.franck@franck-martins-macbook-pro.local> References: <26249556.338.1297885804108.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <5E883CE1-AE35-41B6-971B-F40A36730771@cisco.com> I don't think that the Egyptian shutdown of domain names had much effect; that's why the bgp prefixes were withdrawn. What was effective was the withdrawal of BGP prefixes. http://www.renesys.com/blog/2011/01/egypt-leaves-the-internet.shtml notes, for example, that routes *through* Egypt were operational, but routes through the same fiber and the same routers *to* Egypt were non-functional. https://labs.ripe.net/Members/akvadrako/live_eqyptian_internet_incident_analysis pretty clearly states that "prefixes associated with Egyptian ISPs were withdrawn". On Feb 16, 2011, at 11:50 AM, Franck Martin wrote: > > > ----- Original Message ----- >> From: "Martin Millnert" >> To: "Marshall Eubanks" >> Cc: "North American Network Operators Group" >> Sent: Thursday, 17 February, 2011 8:28:22 AM >> Subject: Re: NYTimes: Egypt Leaders Found ?Off? Switch for Internet >> On Wed, Feb 16, 2011 at 9:09 AM, Marshall Eubanks >> wrote: >>> >>> On Feb 16, 2011, at 12:15 AM, Joly MacFie wrote: >>> > " >> >> Operating local IRC networks is good, as is having local OS mirrors, >> such as Debian/Ubuntu and let's not forget, having a resilient DNS >> configuration (root zone copy hint 101: "dig @k.root-servers.net. . >> axfr"). A securely distributed > > Would it make sense for an ISP to "store" the root zone on their DNS servers instead of letting it be refreshed by the DNS cache? A cron job could refresh it from time to time. It would avoid entries from expiring and would always serve to clients entries with max ttl? > > A root server would be better, but that could be an intermediary step? > > Just speaking out loud here, so it may be total non-sense... > From dougb at dougbarton.us Wed Feb 16 15:30:52 2011 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 16 Feb 2011 13:30:52 -0800 Subject: Fwd: [arin-announce] IN-ADDR.ARPA Zone Transfer Complete In-Reply-To: References: <4D5C3952.1080602@arin.net> Message-ID: <4D5C420C.6030306@dougbarton.us> John, Congratulations to you and ICANN for this significant step, at all the various layers and meanings of significant. :) Relevant to another post today, I've noticed that neither the *.ip6-servers.arpa nor the *.in-addr-servers.arpa allow axfr. Which leads to the following questions: 1. Was that a conscious decision, and if so why? 2. Is there any hope that axfr could be permitted in the future? Of course, if you're not the right person to ask feel free to redirect me. Best regards, Doug On 02/16/2011 13:00, John Curran wrote: > Apologies for cross-posting, but I believe this relevant to the NANOG operator community. > FYI, > /John > > Begin forwarded message: > > From: ARIN> > Date: February 16, 2011 3:53:38 PM EST > To:> > Subject: [arin-announce] IN-ADDR.ARPA Zone Transfer Complete > > Today ARIN and ICANN are jointly working on the transition of the technical management function for the IN-ADDR.ARPA zone from ARIN to ICANN. ARIN carried out the DNS zone maintenance function for IN-ADDR.ARPA since 1997 and worked closed with ICANN throughout the transition period. > > Immediately upon transfer to ICANN, the IN-ADDR.ARPA zone will also be signed using DNS Security Extensions (DNSSEC), providing end-users with the ability to validate answers to reverse DNS queries. The IN-ADDR.ARPA zone is also in the process of being moved from twelve root servers to dedicated nameservers operated by the five Regional Internet Registries (RIRs) and one operated by ICANN. > > For more details on the history of this transition please see. > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From jcurran at arin.net Wed Feb 16 15:44:31 2011 From: jcurran at arin.net (John Curran) Date: Wed, 16 Feb 2011 21:44:31 +0000 Subject: [arin-announce] IN-ADDR.ARPA Zone Transfer Complete In-Reply-To: <4D5C420C.6030306@dougbarton.us> References: <4D5C3952.1080602@arin.net> <4D5C420C.6030306@dougbarton.us> Message-ID: On Feb 16, 2011, at 4:30 PM, Doug Barton wrote: > John, > > Congratulations to you and ICANN for this significant step, at all the various layers and meanings of significant. :) > > Relevant to another post today, I've noticed that neither the *.ip6-servers.arpa nor the *.in-addr-servers.arpa allow axfr. Which leads to the following questions: > > 1. Was that a conscious decision, and if so why? > 2. Is there any hope that axfr could be permitted in the future? > > Of course, if you're not the right person to ask feel free to redirect me. Doug - Excellent questions (of which I do not know the answer) Allow me some time for research. Thanks! /John John Curran President and CEO ARIN From dougb at dougbarton.us Wed Feb 16 15:47:21 2011 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 16 Feb 2011 13:47:21 -0800 Subject: [arin-announce] IN-ADDR.ARPA Zone Transfer Complete In-Reply-To: References: <4D5C3952.1080602@arin.net> <4D5C420C.6030306@dougbarton.us> Message-ID: <4D5C45E9.6060107@dougbarton.us> On 02/16/2011 13:44, John Curran wrote: > On Feb 16, 2011, at 4:30 PM, Doug Barton wrote: > >> John, >> >> Congratulations to you and ICANN for this significant step, at all the various layers and meanings of significant. :) >> >> Relevant to another post today, I've noticed that neither the *.ip6-servers.arpa nor the *.in-addr-servers.arpa allow axfr. Which leads to the following questions: >> >> 1. Was that a conscious decision, and if so why? >> 2. Is there any hope that axfr could be permitted in the future? >> >> Of course, if you're not the right person to ask feel free to redirect me. > > Doug - > > Excellent questions (of which I do not know the answer) > > Allow me some time for research. > > Thanks! No no, thank YOU. :) Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From jabley at hopcount.ca Wed Feb 16 16:23:30 2011 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 16 Feb 2011 17:23:30 -0500 Subject: [arin-announce] IN-ADDR.ARPA Zone Transfer Complete In-Reply-To: <4D5C420C.6030306@dougbarton.us> References: <4D5C3952.1080602@arin.net> <4D5C420C.6030306@dougbarton.us> Message-ID: Hi Doug, On 2011-02-16, at 16:30, Doug Barton wrote: > Relevant to another post today, I've noticed that neither the *.ip6-servers.arpa nor the *.in-addr-servers.arpa allow axfr. Which leads to the following questions: > > 1. Was that a conscious decision, and if so why? It's a question for the individual operators of the servers. I can only speak for the particular servers that ICANN operates. ICANN operates B.IN-ADDR-SERVERS.ARPA and B.IP6-SERVERS.ARPA. As with L-Root, we don't permit zone transfers from the servers themselves; our goal with the nameservers themselves is to provide them with as much headroom as possible for answering DNS queries, and it has never seemed to us that also responding to AXFR is going to help with that. We do however support open zone transfers for the root zone, ARPA, IN-ADDR.ARPA and IP6.ARPA from two locations for anybody who cares to use them: xfr.lax.dns.icann.org xfr.cjr.dns.icann.org The availability of these servers for AXFR is documented at . Joe From dougb at dougbarton.us Wed Feb 16 16:33:28 2011 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 16 Feb 2011 14:33:28 -0800 Subject: [arin-announce] IN-ADDR.ARPA Zone Transfer Complete In-Reply-To: References: <4D5C3952.1080602@arin.net> <4D5C420C.6030306@dougbarton.us> Message-ID: <4D5C50B8.5070804@dougbarton.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/16/2011 14:23, Joe Abley wrote: | Hi Doug, | | On 2011-02-16, at 16:30, Doug Barton wrote: | |> Relevant to another post today, I've noticed that neither the *.ip6-servers.arpa nor the *.in-addr-servers.arpa allow axfr. Which leads to the following questions: |> |> 1. Was that a conscious decision, and if so why? | | It's a question for the individual operators of the servers. I can only speak for the particular servers that ICANN operates. | | ICANN operates B.IN-ADDR-SERVERS.ARPA and B.IP6-SERVERS.ARPA. As with L-Root, we don't permit zone transfers from the servers themselves; our goal with the nameservers themselves is to provide them with as much headroom as possible for answering DNS queries, and it has never seemed to us that also responding to AXFR is going to help with that. | | We do however support open zone transfers for the root zone, ARPA, IN-ADDR.ARPA and IP6.ARPA from two locations for anybody who cares to use them: | | xfr.lax.dns.icann.org | xfr.cjr.dns.icann.org | | The availability of these servers for AXFR is documented at. Joe, Thanks for clarifying. I almost included "is axfr available from any other source?" as a 3rd question, but figured that would come out in the wash. :) This leads to 2 additional questions: 1. Is the zone available from those 2 locations "the same" as what's available on the authoritative servers, or is there a lag time between updates on the auth and the xfr servers? 2. Is there any objection to having those servers listed in publicly available documentation on how to configure resolvers to slave the root and related zones? Thanks again, Doug - -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBCAAGBQJNXFC4AAoJEFzGhvEaGryEDJsIAMPnaAEjXUJHJieA5YlsLL7U iHaCdNAW4q9pBRao8syG9c6l1ZNTG/qZu2CfJ5sBfXfLuimiCvJ4qsfqBX3koc+/ n8EC7f9tEFYQuTQJOZQs3xoT8dYfFxBRn9OFYLRVnEzWXfNB0LpY1a+Q+wEjwU/M U5/1k2ejDyhSSZGpc3VqrSpnQNu8/KAcJM3Ybt0eZE9oZoS7qE5oKmbJ7KuVPHug mH/4PeNoLTtfL1kg+k663SafGbERtfCarZvSOIWbDKPl2YjJcXT9mhpCuPHV/Tkf SHyvB9vcvhZS2PPvVOd/WpZxowG3PxLQJPdv2j/rB1HHu8/QT8KLxm60AivxYh8= =go0l -----END PGP SIGNATURE----- From brunner at nic-naa.net Wed Feb 16 16:36:03 2011 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Wed, 16 Feb 2011 17:36:03 -0500 Subject: =?UTF-8?B?UmU6IExvY2FsIHJvb3Qgem9uZSAoV2FzIE5ZVGltZXM6IEVneXB0IEw=?= =?UTF-8?B?ZWFkZXJzIEZvdW5kIOKAmE9mZuKAmSBTd2l0Y2ggZm9yIEludGVybmV0KQ==?= In-Reply-To: <5E883CE1-AE35-41B6-971B-F40A36730771@cisco.com> References: <26249556.338.1297885804108.JavaMail.franck@franck-martins-macbook-pro.local> <5E883CE1-AE35-41B6-971B-F40A36730771@cisco.com> Message-ID: <4D5C5153.1000909@nic-naa.net> On 2/16/11 4:25 PM, Fred Baker wrote: > I don't think that the Egyptian shutdown of domain names had much effect ... ditto. i'm not aware of any actions by the .eg registry operator, though i'll ask, coincidental to the prefix withdrawal. i suppose in the interests of completeness i should also ask about the (wicked recent) (???.) IDN ccTLD. these are both wicked small zones, relative to the density of names registered (registries other than .eg) by egyptian residents, and the larger number of network using egyptians. it is possible that as a preliminary step, the recursive resolver operators of each of the subsequently prefix withdrawing providers modified their cached data to provide policy-based resolution. -e From richard.barnes at gmail.com Wed Feb 16 16:38:32 2011 From: richard.barnes at gmail.com (Richard Barnes) Date: Wed, 16 Feb 2011 17:38:32 -0500 Subject: =?windows-1252?Q?Re=3A_NYTimes=3A_Egypt_Leaders_Found_=91Off=92_Switch_fo?= =?windows-1252?Q?r_Internet?= In-Reply-To: <7F7401DE-390B-41F9-8B09-F920FBBC637A@americafree.tv> References: <7F7401DE-390B-41F9-8B09-F920FBBC637A@americafree.tv> Message-ID: It also seems like a question that could be decided empirically. Can anyone on here comment on whether or not the BGP session ended gracefully and the link lights remained lit? --Richard On Wed, Feb 16, 2011 at 9:09 AM, Marshall Eubanks wrote: > > On Feb 16, 2011, at 12:15 AM, Joly MacFie wrote: > >> http://www.nytimes.com/2011/02/16/technology/16internet.html >> >> There has been intense debate both inside and outside Egypt on whether the >>> cutoff at 26 Ramses Street was accomplished by surgically tampering with the >>> software mechanism that defines how networks at the core of the Internet >>> communicate with one another, or by a blunt approach: simply cutting off the >>> power to the router computers that connect Egypt to the outside world. >> >> > > I do remember some intense debate, here and elsewhere, but I somehow don't remember those as being the primary debate parameters. > > Regards > Marshall > > >> -- >> --------------------------------------------------------------- >> Joly MacFie ?218 565 9365 Skype:punkcast >> WWWhatsup NYC - http://wwwhatsup.com >> http://pinstand.com - http://punkcast.com >> ?VP (Admin) - ISOC-NY - http://isoc-ny.org >> --------------------------------------------------------------- >> > > > From richard.barnes at gmail.com Wed Feb 16 16:41:36 2011 From: richard.barnes at gmail.com (Richard Barnes) Date: Wed, 16 Feb 2011 17:41:36 -0500 Subject: =?windows-1252?Q?Re=3A_NYTimes=3A_Egypt_Leaders_Found_=91Off=92_Switch_fo?= =?windows-1252?Q?r_Internet?= In-Reply-To: References: <7F7401DE-390B-41F9-8B09-F920FBBC637A@americafree.tv> Message-ID: Never mind, Messrs. Cowie and Baker answered my question: Couldn't have paths through Egypt if layer 2 were cut off. (Right?) --Richard On Wed, Feb 16, 2011 at 5:38 PM, Richard Barnes wrote: > It also seems like a question that could be decided empirically. ?Can > anyone on here comment on whether or not the BGP session ended > gracefully and the link lights remained lit? > > --Richard > > > > On Wed, Feb 16, 2011 at 9:09 AM, Marshall Eubanks wrote: >> >> On Feb 16, 2011, at 12:15 AM, Joly MacFie wrote: >> >>> http://www.nytimes.com/2011/02/16/technology/16internet.html >>> >>> There has been intense debate both inside and outside Egypt on whether the >>>> cutoff at 26 Ramses Street was accomplished by surgically tampering with the >>>> software mechanism that defines how networks at the core of the Internet >>>> communicate with one another, or by a blunt approach: simply cutting off the >>>> power to the router computers that connect Egypt to the outside world. >>> >>> >> >> I do remember some intense debate, here and elsewhere, but I somehow don't remember those as being the primary debate parameters. >> >> Regards >> Marshall >> >> >>> -- >>> --------------------------------------------------------------- >>> Joly MacFie ?218 565 9365 Skype:punkcast >>> WWWhatsup NYC - http://wwwhatsup.com >>> http://pinstand.com - http://punkcast.com >>> ?VP (Admin) - ISOC-NY - http://isoc-ny.org >>> --------------------------------------------------------------- >>> >> >> >> > From mikeal.clark at gmail.com Wed Feb 16 16:44:51 2011 From: mikeal.clark at gmail.com (Mikeal Clark) Date: Wed, 16 Feb 2011 16:44:51 -0600 Subject: AT&T MPLS / BIB Routers Message-ID: We just put in a AT&T MPLS and are having a pretty negative experience with the "Business in a Box" routers they are using for our smaller sites. We are seeing extremely high latency under load. Anyone have any experience with these devices that could shed some light on this? Are they really this bad? From jabley at hopcount.ca Wed Feb 16 17:05:16 2011 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 16 Feb 2011 18:05:16 -0500 Subject: [arin-announce] IN-ADDR.ARPA Zone Transfer Complete In-Reply-To: <4D5C50B8.5070804@dougbarton.us> References: <4D5C3952.1080602@arin.net> <4D5C420C.6030306@dougbarton.us> <4D5C50B8.5070804@dougbarton.us> Message-ID: <4BF50EC1-786A-4D97-87A9-EBB1BDC83AA2@hopcount.ca> On 2011-02-16, at 17:33, Doug Barton wrote: > This leads to 2 additional questions: > > 1. Is the zone available from those 2 locations "the same" as what's > available on the authoritative servers, or is there a lag time between > updates on the auth and the xfr servers? The two servers mentioned transfer the zone from the same place as the *.in-addr-servers.arpa servers. They're a little closer than some of the other servers. I imagine some propagation lag between them would be visible with the right instrumentation. The speed of light is the speed of light. > 2. Is there any objection to having those servers listed in publicly > available documentation on how to configure resolvers to slave the root > and related zones? My personal opinion is that such advice is misguided, but we place no restrictions on the soundness of the reasons for transferring zones from those places :-) Joe From jg at freedesktop.org Wed Feb 16 17:09:50 2011 From: jg at freedesktop.org (Jim Gettys) Date: Wed, 16 Feb 2011 18:09:50 -0500 Subject: AT&T MPLS / BIB Routers In-Reply-To: References: Message-ID: <4D5C593E.9060808@freedesktop.org> On 02/16/2011 05:44 PM, Mikeal Clark wrote: > We just put in a AT&T MPLS and are having a pretty negative experience with > the "Business in a Box" routers they are using for our smaller sites. We > are seeing extremely high latency under load. Anyone have any experience > with these devices that could shed some light on this? Are they really this > bad? > There is excessive buffering in all sorts of devices all over the Internet. This causes high latency under load (along with higher packet losses, and lots of other problems. It's what I've been blogging about on http://gettys.wordpress.com. These buffers fill; and they are so large they have defeated TCP congestion avoidance to boot, with horrifying consequences. So far, I've found this problem (almost) everywhere I've looked: o ICSI has good data that bufferbloat is endemic in DSL, Cable, and FIOS. Delays are often measured in seconds (rather than milliseconds). o some corporate and ISP networks run without AQM, in circumstances that they should. o Windows, Mac OSX and Linux all have bufferbloat in their network stacks, at a minimum on recent network device drivers, and often elsewhere. o Every home router I've tested is horrifyingly bad. o 3g networks & 802.11 have this in spades. Why should AT&T's MPLS be any different? My next topic will be "transient" bufferbloat, having to do with defeating slowstart. Come start helping fix this: please join us at bufferbloat.net, as we try to get people to fix it. Already there are some experimental patches for the Linux Intel wireless driver. Jim Gettys Bell Labs From smb at cs.columbia.edu Wed Feb 16 17:10:17 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Wed, 16 Feb 2011 18:10:17 -0500 Subject: =?windows-1252?Q?Re=3A_Local_root_zone_=28Was_NYTimes=3A_Egypt_L?= =?windows-1252?Q?eaders_Found_=91Off=92_Switch_for_Internet=29?= In-Reply-To: <5E883CE1-AE35-41B6-971B-F40A36730771@cisco.com> References: <26249556.338.1297885804108.JavaMail.franck@franck-martins-macbook-pro.local> <5E883CE1-AE35-41B6-971B-F40A36730771@cisco.com> Message-ID: <2B8C7D7B-1F83-476E-8D05-6A6E450280AD@cs.columbia.edu> On Feb 16, 2011, at 4:25 13PM, Fred Baker wrote: > I don't think that the Egyptian shutdown of domain names had much effect; that's why the bgp prefixes were withdrawn. What was effective was the withdrawal of BGP prefixes. Per the NYT article, the issue was the Egyptian "Intranet" -- people couldn't contact other sites within Egypt by host name, even though the routes were up, because they couldn't resolve .eg, .com, etc. --Steve Bellovin, http://www.cs.columbia.edu/~smb From franck at genius.com Wed Feb 16 17:13:25 2011 From: franck at genius.com (Franck Martin) Date: Thu, 17 Feb 2011 12:13:25 +1300 (FJST) Subject: [arin-announce] IN-ADDR.ARPA Zone Transfer Complete In-Reply-To: <4BF50EC1-786A-4D97-87A9-EBB1BDC83AA2@hopcount.ca> Message-ID: <12519660.360.1297898000961.JavaMail.franck@franck-martins-macbook-pro.local> ----- Original Message ----- > From: "Joe Abley" > To: "Doug Barton" > Cc: "John Curran" , "NANOG" > Sent: Thursday, 17 February, 2011 12:05:16 PM > Subject: Re: [arin-announce] IN-ADDR.ARPA Zone Transfer Complete > On 2011-02-16, at 17:33, Doug Barton wrote: > > > 2. Is there any objection to having those servers listed in publicly > > available documentation on how to configure resolvers to slave the > > root > > and related zones? > > My personal opinion is that such advice is misguided, but we place no > restrictions on the soundness of the reasons for transferring zones > from those places :-) > Would it break DNSSEC ? From mikeal.clark at gmail.com Wed Feb 16 17:16:09 2011 From: mikeal.clark at gmail.com (Mikeal Clark) Date: Wed, 16 Feb 2011 17:16:09 -0600 Subject: AT&T MPLS / BIB Routers In-Reply-To: <4D5C593E.9060808@freedesktop.org> References: <4D5C593E.9060808@freedesktop.org> Message-ID: I'm building up to 3000-4000ms latency with these BIB routers. We never had this issue on the old point to points using Cisco gear. On Wed, Feb 16, 2011 at 5:09 PM, Jim Gettys wrote: > On 02/16/2011 05:44 PM, Mikeal Clark wrote: > >> We just put in a AT&T MPLS and are having a pretty negative experience >> with >> the "Business in a Box" routers they are using for our smaller sites. We >> are seeing extremely high latency under load. Anyone have any experience >> with these devices that could shed some light on this? Are they really >> this >> bad? >> >> > There is excessive buffering in all sorts of devices all over the Internet. > This causes high latency under load (along with higher packet losses, and > lots of other problems. > > It's what I've been blogging about on http://gettys.wordpress.com. These > buffers fill; and they are so large they have defeated TCP congestion > avoidance to boot, with horrifying consequences. > > So far, I've found this problem (almost) everywhere I've looked: > o ICSI has good data that bufferbloat is endemic in DSL, Cable, and > FIOS. Delays are often measured in seconds (rather than milliseconds). > o some corporate and ISP networks run without AQM, in circumstances > that they should. > o Windows, Mac OSX and Linux all have bufferbloat in their network > stacks, at a minimum on recent network device drivers, and often elsewhere. > o Every home router I've tested is horrifyingly bad. > o 3g networks & 802.11 have this in spades. > > Why should AT&T's MPLS be any different? > > My next topic will be "transient" bufferbloat, having to do with defeating > slowstart. > > Come start helping fix this: please join us at bufferbloat.net, as we > try to get people to fix it. Already there are some experimental patches > for the Linux Intel wireless driver. > Jim Gettys > Bell Labs > > From brunner at nic-naa.net Wed Feb 16 17:34:17 2011 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Wed, 16 Feb 2011 18:34:17 -0500 Subject: =?windows-1252?Q?Re=3A_Local_root_zone_=28Was_NYTimes=3A?= =?windows-1252?Q?_Egypt_Leaders_Found_=91Off=92_Switch_for_?= =?windows-1252?Q?Internet=29?= In-Reply-To: <2B8C7D7B-1F83-476E-8D05-6A6E450280AD@cs.columbia.edu> References: <26249556.338.1297885804108.JavaMail.franck@franck-martins-macbook-pro.local> <5E883CE1-AE35-41B6-971B-F40A36730771@cisco.com> <2B8C7D7B-1F83-476E-8D05-6A6E450280AD@cs.columbia.edu> Message-ID: <4D5C5EF9.5010606@nic-naa.net> On 2/16/11 6:10 PM, Steven Bellovin wrote: > > On Feb 16, 2011, at 4:25 13PM, Fred Baker wrote: > >> I don't think that the Egyptian shutdown of domain names had much effect; that's why the bgp prefixes were withdrawn. What was effective was the withdrawal of BGP prefixes. > > Per the NYT article, the issue was the Egyptian "Intranet" -- people couldn't contact other sites within Egypt by host name, even though the routes were up, because they couldn't resolve .eg, .com, etc. i'll have to check if the .eg servers were ever taken off-line. resolution of .com (beyond local caches) would have been pointless post-prefix withdrawal, but if the claim is that local ix routing remained possible, so non-cached .eg resolution was successful from outside of the eun to any other egyptian provider net, then if there is data to support the claim, it will be interesting. i'll ask. -e From scg at gibbard.org Wed Feb 16 17:38:07 2011 From: scg at gibbard.org (Steve Gibbard) Date: Wed, 16 Feb 2011 15:38:07 -0800 Subject: =?windows-1252?Q?Re=3A_Local_root_zone_=28Was_NYTimes=3A_Egypt_L?= =?windows-1252?Q?eaders_Found_=91Off=92_Switch_for_Internet=29?= In-Reply-To: <2B8C7D7B-1F83-476E-8D05-6A6E450280AD@cs.columbia.edu> References: <26249556.338.1297885804108.JavaMail.franck@franck-martins-macbook-pro.local> <5E883CE1-AE35-41B6-971B-F40A36730771@cisco.com> <2B8C7D7B-1F83-476E-8D05-6A6E450280AD@cs.columbia.edu> Message-ID: <4B4A1B8A-ACB3-43EE-854D-7496D6E0E943@gibbard.org> On Feb 16, 2011, at 3:10 PM, Steven Bellovin wrote: > > On Feb 16, 2011, at 4:25 13PM, Fred Baker wrote: > >> I don't think that the Egyptian shutdown of domain names had much effect; that's why the bgp prefixes were withdrawn. What was effective was the withdrawal of BGP prefixes. > > Per the NYT article, the issue was the Egyptian "Intranet" -- people couldn't contact other sites within Egypt by host name, even though the routes were up, because they couldn't resolve .eg, .com, etc. This is interesting, in that according to http://www.root-servers.org Cairo has two root servers (F and J). The presence of a Verisign-operated J Root leads me to assume there are probably also local .com and .net servers. One of the three name servers for .EG looks like it could plausibly be in Cairo (IP address space registered to an Egyptian postal address, 100 ms response time from London). If DNS look-ups at that level didn't work, it seems likely that there was some disruption of internal connectivity as well. Or, it may be that "the Internet" still mostly means foreign services. Being able to look up the addresses of Facebook's name servers isn't the same as being able to access Facebook. The Times article was a bit short of specifics on that, and I haven't seen other information on what it looked like internally. There's something important to keep in mind in cases like this, though. Having redundancy and local copies of things is very good for protecting against accidental disruptions or disruptions of services in other jurisdictions. Protecting things that local guys with guns want to have go away is a somewhat different story. It seems likely that if "the Internet" had still been working after the things the government did to shut it down, the government would have done more. If somebody had managed to put all the pieces together and provide wide access to content the government wanted gone, they would probably have been told to stop. I'm a bit skeptical that having more local copies of things would have helped much. -Steve From fred at cisco.com Wed Feb 16 17:35:55 2011 From: fred at cisco.com (Fred Baker) Date: Wed, 16 Feb 2011 15:35:55 -0800 Subject: =?windows-1252?Q?Re=3A_Local_root_zone_=28Was_NYTimes=3A_Egypt_L?= =?windows-1252?Q?eaders_Found_=91Off=92_Switch_for_Internet=29?= In-Reply-To: <2B8C7D7B-1F83-476E-8D05-6A6E450280AD@cs.columbia.edu> References: <26249556.338.1297885804108.JavaMail.franck@franck-martins-macbook-pro.local> <5E883CE1-AE35-41B6-971B-F40A36730771@cisco.com> <2B8C7D7B-1F83-476E-8D05-6A6E450280AD@cs.columbia.edu> Message-ID: <7FACF683-9D14-4956-847D-758FE3519BDB@cisco.com> ah On Feb 16, 2011, at 3:10 PM, Steven Bellovin wrote: > > On Feb 16, 2011, at 4:25 13PM, Fred Baker wrote: > >> I don't think that the Egyptian shutdown of domain names had much effect; that's why the bgp prefixes were withdrawn. What was effective was the withdrawal of BGP prefixes. > > Per the NYT article, the issue was the Egyptian "Intranet" -- people couldn't contact other sites within Egypt by host name, even though the routes were up, because they couldn't resolve .eg, .com, etc. > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > > > > > From dotis at mail-abuse.org Wed Feb 16 17:52:12 2011 From: dotis at mail-abuse.org (Douglas Otis) Date: Thu, 17 Feb 2011 07:52:12 +0800 Subject: NIST and SP800-119 In-Reply-To: References: <0DCE3E24-A879-41DC-958D-99BC5DD57784@hopcount.ca> <4D5B804B.7020408@mail-abuse.org> Message-ID: <4D5C632C.1050407@mail-abuse.org> On 2/16/11 10:57 PM, Joe Abley wrote: > On 2011-02-16, at 02:44, Douglas Otis wrote: >> Routers indicate local MTUs, but minimum MTUs are not assured to have 1280 octets when IPv4 translation is involved. >> See Section 5 in rfc2460. > I've heard that interpretation of 2460 before from Bill Manning, but I still don't see it myself. The text seems fairly clear that 1280 is the minimum MTU for any interface, regardless of the type of interface (tunnel, PPP, whatever). In particular, > > Links that have a configurable MTU (for example, PPP links [RFC- > 1661]) must be configured to have an MTU of at least 1280 octets; it > is recommended that they be configured with an MTU of 1500 octets or > greater, to accommodate possible encapsulations (i.e., tunneling) > without incurring IPv6-layer fragmentation. > > That same section indicates that pMTUd is strongly recommended in IPv6 rather than mandatory, but in the context of embedded devices that can avoid implementing pMTUd by never sending a packet larger than the minimum MTU. Such devices would break if there was an interface (of any kind) in the path with a sub-1280 MTU. Bill makes a good point. Ensuring a minimum MTU of 1280 octets over v6 connections carrying protocol 41 will not allow subsequent v4 routers to fragment based upon discovered PMTUs. This could influence maximum UDP packets from a DNS server for example, where path MTU discovery is impractical. To be assured of continued operation for critical infrastructure, minimum MTUs of 1280 for v6 connections that might handle protocol 41 packets, becomes 1280 - 40 - 8 = 1232 or less as indicated in RFC2460. As suggested, there might be another 18 octet header, like L2TP, where the maximum MTU safely assumed becomes 1214. Perhaps IPv6 should have specified a required minimum of 1346 octets, where 1280 octets could be safely assumed available. A SHOULD is not a MUST, but critical operations MUST be based upon the MUSTs. How much longer will native v4 be carried over the Internet anyway? :^) -Doug From mounir.mohamed at gmail.com Wed Feb 16 17:58:00 2011 From: mounir.mohamed at gmail.com (Mounir Mohamed) Date: Thu, 17 Feb 2011 01:58:00 +0200 Subject: =?windows-1252?Q?Re=3A_NYTimes=3A_Egypt_Leaders_Found_=91Off=92_Switch_fo?= =?windows-1252?Q?r_Internet?= In-Reply-To: References: <7F7401DE-390B-41F9-8B09-F920FBBC637A@americafree.tv> Message-ID: No the BGP and the physical links were down. On Thu, Feb 17, 2011 at 12:38 AM, Richard Barnes wrote: > It also seems like a question that could be decided empirically. Can > anyone on here comment on whether or not the BGP session ended > gracefully and the link lights remained lit? > > --Richard > > > > On Wed, Feb 16, 2011 at 9:09 AM, Marshall Eubanks > wrote: > > > > On Feb 16, 2011, at 12:15 AM, Joly MacFie wrote: > > > >> http://www.nytimes.com/2011/02/16/technology/16internet.html > >> > >> There has been intense debate both inside and outside Egypt on whether > the > >>> cutoff at 26 Ramses Street was accomplished by surgically tampering > with the > >>> software mechanism that defines how networks at the core of the > Internet > >>> communicate with one another, or by a blunt approach: simply cutting > off the > >>> power to the router computers that connect Egypt to the outside world. > >> > >> > > > > I do remember some intense debate, here and elsewhere, but I somehow > don't remember those as being the primary debate parameters. > > > > Regards > > Marshall > > > > > >> -- > >> --------------------------------------------------------------- > >> Joly MacFie 218 565 9365 Skype:punkcast > >> WWWhatsup NYC - http://wwwhatsup.com > >> http://pinstand.com - http://punkcast.com > >> VP (Admin) - ISOC-NY - http://isoc-ny.org > >> --------------------------------------------------------------- > >> > > > > > > > > -- Best Regards, Mounir Mohamed, CCIE#19573 (R&S/SP), JNCIS-M. Senior Network Engineer, Core Team. NOOR Data Networks, SAE Mobile# +2-010-2345-956 http://mounirmohamed.wordpress.com http://www.linkedin.com/in/mounirmohamed From millnert at gmail.com Wed Feb 16 18:17:04 2011 From: millnert at gmail.com (Martin Millnert) Date: Wed, 16 Feb 2011 19:17:04 -0500 Subject: =?windows-1252?Q?Re=3A_NYTimes=3A_Egypt_Leaders_Found_=91Off=92_Switch_fo?= =?windows-1252?Q?r_Internet?= In-Reply-To: References: <7F7401DE-390B-41F9-8B09-F920FBBC637A@americafree.tv> Message-ID: Mounir, On Wed, Feb 16, 2011 at 6:58 PM, Mounir Mohamed wrote: > No the BGP and the physical links were down. did you have any domestic BGP sessions up? Regards, Martin From dougb at dougbarton.us Wed Feb 16 18:18:35 2011 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 16 Feb 2011 16:18:35 -0800 Subject: [arin-announce] IN-ADDR.ARPA Zone Transfer Complete In-Reply-To: <12519660.360.1297898000961.JavaMail.franck@franck-martins-macbook-pro.local> References: <12519660.360.1297898000961.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4D5C695B.9010605@dougbarton.us> On 02/16/2011 15:13, Franck Martin wrote: > > > ----- Original Message ----- >> From: "Joe Abley" >> To: "Doug Barton" >> Cc: "John Curran", "NANOG" >> Sent: Thursday, 17 February, 2011 12:05:16 PM >> Subject: Re: [arin-announce] IN-ADDR.ARPA Zone Transfer Complete >> On 2011-02-16, at 17:33, Doug Barton wrote: >> >>> 2. Is there any objection to having those servers listed in publicly >>> available documentation on how to configure resolvers to slave the >>> root >>> and related zones? >> >> My personal opinion is that such advice is misguided, Yes, I know. :) I obviously believe that reasonable minds can differ on this topic, but as we've gone round about this before and I don't want to get too deep in the DNS weeds I'll just say that I respect your perspective on this topic, even though I disagree with it. I should also add that the fact that this configuration can get out of sync and cause problems is not to be taken lightly. When I first started using and recommending this configuration 10 years ago my feeling was that the days of "set it and forget it" DNS were coming to an end since DNSSEC was "just around the corner." I was wrong about that on both counts, but I still believe that for those that are willing and able to take appropriate care with their DNS infrastructure that this configuration is a win. >> but we place no >> restrictions on the soundness of the reasons for transferring zones >> from those places :-) >> > Would it break DNSSEC ? No. In my current configuration I have the root zone trust anchor configured and I just re-configured it to download ip6.arpa and in-addr.arpa from the ICANN servers Joe mentioned. Note the "ad" bit: dig @127.0.0.1 6.0.1.0.0.2.ip6.arpa. ns +dnssec ; <<>> DiG 9.8.0rc1 <<>> @127.0.0.1 6.0.1.0.0.2.ip6.arpa. ns +dnssec ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39677 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;6.0.1.0.0.2.ip6.arpa. IN NS ;; ANSWER SECTION: 6.0.1.0.0.2.ip6.arpa. 172800 IN NS sns-pb.isc.org. 6.0.1.0.0.2.ip6.arpa. 172800 IN NS sec3.apnic.net. 6.0.1.0.0.2.ip6.arpa. 172800 IN NS sunic.sunet.se. 6.0.1.0.0.2.ip6.arpa. 172800 IN NS tinnie.arin.net. 6.0.1.0.0.2.ip6.arpa. 172800 IN NS ns3.nic.fr. 6.0.1.0.0.2.ip6.arpa. 172800 IN NS sec1.apnic.net. 6.0.1.0.0.2.ip6.arpa. 172800 IN NS ns-pri.ripe.net. 6.0.1.0.0.2.ip6.arpa. 172800 IN NS munnari.oz.au. 6.0.1.0.0.2.ip6.arpa. 172800 IN RRSIG NS 5 8 172800 20110318135006 20110216125006 63865 6.0.1.0.0.2.ip6.arpa. fe3wJGI5KHjrR2HasKojm8gpJxpQXcPY5Piy7c58XmSyzKlONxOTwvdC +Cjlw/XCfWCSc6IjNlmJm7kACRtQrOrv2PnvYan+1yslAJyguoTvl56j N+nOTD0VDlNeInKkonn/attHWvV+c05gxdXLEkW11PSdF1xtkDKgPkwV n54= ;; Query time: 376 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Feb 16 16:07:34 2011 ;; MSG SIZE rcvd: 435 -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From mounir.mohamed at gmail.com Wed Feb 16 18:22:54 2011 From: mounir.mohamed at gmail.com (Mounir Mohamed) Date: Thu, 17 Feb 2011 02:22:54 +0200 Subject: =?windows-1252?Q?Re=3A_NYTimes=3A_Egypt_Leaders_Found_=91Off=92_Switch_fo?= =?windows-1252?Q?r_Internet?= In-Reply-To: References: <7F7401DE-390B-41F9-8B09-F920FBBC637A@americafree.tv> Message-ID: Yes all sessions were operational during that period. On Thu, Feb 17, 2011 at 2:17 AM, Martin Millnert wrote: > Mounir, > > On Wed, Feb 16, 2011 at 6:58 PM, Mounir Mohamed > wrote: > > No the BGP and the physical links were down. > > did you have any domestic BGP sessions up? > > Regards, > Martin > -- From randy at psg.com Wed Feb 16 19:37:02 2011 From: randy at psg.com (Randy Bush) Date: Thu, 17 Feb 2011 09:37:02 +0800 Subject: Local root zone (Was NYTimes: Egypt Leaders Found =?UTF-8?B?4oCYT2Zm4oCZ?= Switch for Internet) In-Reply-To: <5E883CE1-AE35-41B6-971B-F40A36730771@cisco.com> References: <26249556.338.1297885804108.JavaMail.franck@franck-martins-macbook-pro.local> <5E883CE1-AE35-41B6-971B-F40A36730771@cisco.com> Message-ID: > I don't think that the Egyptian shutdown of domain names had much > effect what shutdown of egyptian domain names? randy, who has a server which serves them From franck at genius.com Wed Feb 16 20:09:44 2011 From: franck at genius.com (Franck Martin) Date: Thu, 17 Feb 2011 15:09:44 +1300 (FJST) Subject: =?utf-8?Q?Re:_Local_root_zone_(Was_NYTimes:_Egypt_?= =?utf-8?Q?Leaders_Found_=E2=80=98Off=E2=80=99_Switch_for_Internet)?= In-Reply-To: Message-ID: <11440265.398.1297908582647.JavaMail.franck@franck-martins-macbook-pro.local> ----- Original Message ----- > From: "Randy Bush" > To: "Fred Baker" > Cc: "Franck Martin" , "North American Network Operators Group" > Sent: Thursday, 17 February, 2011 2:37:02 PM > Subject: Re: Local root zone (Was NYTimes: Egypt Leaders Found ?Off? Switch for Internet) > > I don't think that the Egyptian shutdown of domain names had much > > effect > > what shutdown of egyptian domain names? > > randy, who has a server which serves them The ASCII one .eg or the UTF8 one .xn--wgbh1c? xn--wgbh1c. 172800 IN NS ns1.dotmasr.eg. xn--wgbh1c. 172800 IN NS ns2.dotmasr.eg. xn--wgbh1c. 172800 IN NS ns3.dotmasr.eg. eg. 172800 IN NS ns5.univie.ac.at. eg. 172800 IN NS rip.psg.com. eg. 172800 IN NS frcu.eun.eg. From regnauld at nsrc.org Wed Feb 16 20:14:48 2011 From: regnauld at nsrc.org (Phil Regnauld) Date: Thu, 17 Feb 2011 10:14:48 +0800 Subject: Slaving the root and other top-level DNS zones In-Reply-To: <4D5C695B.9010605@dougbarton.us> References: <12519660.360.1297898000961.JavaMail.franck@franck-martins-macbook-pro.local> <4D5C695B.9010605@dougbarton.us> Message-ID: <20110217021442.GA25515@macbook.catpipe.net> Sorry, this probably should be moved to dns-ops, but this may interest some of the network operators here. Doug Barton (dougb) writes: > > I should also add that the fact that this configuration can get out > of sync and cause problems is not to be taken lightly. When I first > started using and recommending this configuration 10 years ago my > feeling was that the days of "set it and forget it" DNS were coming > to an end since DNSSEC was "just around the corner." I was wrong > about that on both counts, but I still believe that for those that > are willing and able to take appropriate care with their DNS > infrastructure that this configuration is a win. Not to tread on a landmine, but reading /etc/namedb/named.conf on a (recent) FreeBSD, it states: [...] Slaving the following zones from the root name servers has some significant advantages: 1. Faster local resolution for your users 2. No spurious traffic will be sent from your network to the roots 3. Greater resilience to any potential root server failure/DDoS On the other hand, this method requires more monitoring than the hints file to be sure that an unexpected failure mode has not incapacitated your server. Name servers that are serving a lot of clients will benefit more from this approach than individual hosts. Use with caution. [...] (note that other zones can be configured to be slaved per the above setup, but I'm only mentioning root for the sake of the discussion) In order: Point 1: After the NS has primed itself, and has been running for a few minutes, how much faster are we talking about ? Is this something you have some numbers on ? Is it measurable from a user experience point of view ? Is there a sweet spot/ROI of sorts on scale ranging from "small network" to "large corporation" ? With ~300 TLDs in the forward space (don't know how many subdelegations in-addr.arpa has off the top of my head), is this a real, noticeable win ? Imagining that the new vTLDs are a success, and this grows to potentially thousands of new TLDs, what's the projected improvement value from this setup ? Does it become a handicap ? Point 2: I've heard that 98% of traffic to the root is junk, but since NXDOMAINs get quickly neg cached, how much bandwidth conservation and resource preservation are we talking about ? If one takes AS112 into account, how much improvement is this ? Point 3: Do we have a historical scenario where DDoS has effectively hindered DNS resolution for caching nameservers to the extent that they couldn't look up non-cached TLD records/prime themselves at startup ? Analysis of a big DoS attack in 2006, IIRC, did nothing more that slow down somewhat some of the affected anycast instances. Now, I'm not being skeptical here, but you put the arguments for slaving the top level zones as a win-only situation. So I feel compelled to ask you to back those claims, especially considering the tradeoff in complexity and stability it entails with regards to monitoring requirements. The days of "set if and forget it" for DNS may be gone, but it's no reason to make life unnecessarily complex for system administrators, and while it's a personal choice to enable slaving, your recommending it should be thoroughly justified :) Cheers, Phil From drc at virtualized.org Wed Feb 16 20:15:36 2011 From: drc at virtualized.org (David Conrad) Date: Wed, 16 Feb 2011 18:15:36 -0800 Subject: [arin-announce] IN-ADDR.ARPA Zone Transfer Complete In-Reply-To: References: <4D5C3952.1080602@arin.net> Message-ID: <43EE6734-3F25-4905-BAC0-5BACA532C01B@virtualized.org> Congrats to all on getting this done! It's been a long time in coming. Good to see it finally finished. Regards, -drc On Feb 16, 2011, at 1:00 PM, John Curran wrote: > Apologies for cross-posting, but I believe this relevant to the NANOG operator community. > FYI, > /John > > Begin forwarded message: > > From: ARIN > > Date: February 16, 2011 3:53:38 PM EST > To: > > Subject: [arin-announce] IN-ADDR.ARPA Zone Transfer Complete > > Today ARIN and ICANN are jointly working on the transition of the technical management function for the IN-ADDR.ARPA zone from ARIN to ICANN. ARIN carried out the DNS zone maintenance function for IN-ADDR.ARPA since 1997 and worked closed with ICANN throughout the transition period. > > Immediately upon transfer to ICANN, the IN-ADDR.ARPA zone will also be signed using DNS Security Extensions (DNSSEC), providing end-users with the ability to validate answers to reverse DNS queries. The IN-ADDR.ARPA zone is also in the process of being moved from twelve root servers to dedicated nameservers operated by the five Regional Internet Registries (RIRs) and one operated by ICANN. > > For more details on the history of this transition please see . > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > From Valdis.Kletnieks at vt.edu Wed Feb 16 20:27:32 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 16 Feb 2011 21:27:32 -0500 Subject: Slaving the root and other top-level DNS zones In-Reply-To: Your message of "Thu, 17 Feb 2011 10:14:48 +0800." <20110217021442.GA25515@macbook.catpipe.net> References: <12519660.360.1297898000961.JavaMail.franck@franck-martins-macbook-pro.local> <4D5C695B.9010605@dougbarton.us> <20110217021442.GA25515@macbook.catpipe.net> Message-ID: <9934.1297909652@localhost> On Thu, 17 Feb 2011 10:14:48 +0800, Phil Regnauld said: > Point 2: > > I've heard that 98% of traffic to the root is junk, but since > NXDOMAINs get quickly neg cached, how much bandwidth conservation > and resource preservation are we talking about ? If one takes > AS112 into account, how much improvement is this ? If that's the CAIDA paper I'm thinking of, a lot of the 98% junk was the sort of stuff you'd expect from broken sites who probably won't do neg caching right - and in fact, a significant portion (30%?) was *specifically* sources that failed to negative cache a reply and asking over and over again, often multiple times a second. Of course, those sort of broken sites probably will manage to screw up deploying a local hints file, resulting in *more* traffic at the roots :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dougb at dougbarton.us Wed Feb 16 20:55:56 2011 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 16 Feb 2011 18:55:56 -0800 Subject: Slaving the root and other top-level DNS zones In-Reply-To: <20110217021442.GA25515@macbook.catpipe.net> References: <12519660.360.1297898000961.JavaMail.franck@franck-martins-macbook-pro.local> <4D5C695B.9010605@dougbarton.us> <20110217021442.GA25515@macbook.catpipe.net> Message-ID: <4D5C8E3C.2040408@dougbarton.us> On 02/16/2011 18:14, Phil Regnauld wrote: > Not to tread on a landmine, Actually it seems like you want to jump up and down on it. Given that both the benefits and the potential problems have been extensively debated elsewhere, I'll simply say that you raise interesting questions that I think people interested in this method should answer for themselves. > Now, I'm not being skeptical here, but you put the arguments for > slaving the top level zones as a win-only situation. And for me, and a lot of others it has been. If you have something new to contribute in regards to the negatives I'm happy to listen, although this might not be the best forum. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From wavetossed at googlemail.com Wed Feb 16 21:03:59 2011 From: wavetossed at googlemail.com (Michael Dillon) Date: Wed, 16 Feb 2011 19:03:59 -0800 Subject: To the people who answer tech questions on this list Message-ID: This list serves a number of purposes and one of them is to answer technical networking questions. But this list is also not the only place that these types of questions are asked. For instance, LinkedIn has a Q&A feature where people can ask and answer questions on a wide range of topics. Just today I came across this BGP question: http://www.linkedin.com/answers/technology/information-technology/computer-networking/TCH_ITS_CNW/792993-20766406 I would never suggest that LinkedIn could replace the NANOG mailing list, but it is an interesting complement to it. There is a NANOG group here: http://www.linkedin.com/groups?mostPopular=&gid=40718 and a number of people are using LinkedIn for professional purposes. I know many of you tried out Orkut and then migrated to Multiply.com and found them lacking. But I would suggest that LinkedIn might be more useful, in particular, to provide an entry level tier for questions. A lot of NANOG members are rather intimidated to ask questions which might seem too beginner and I think that the NANOG group on LinkedIn might be a good place to encourage such questions in order to draw out more discussion among NANOG members without boosting the mailing list traffic. What do you think? (Probably best to answer this on the NANOG group over at... --Michael Dillon http://www.linkedin.com/profile/view?id=13566587 From jg at freedesktop.org Wed Feb 16 21:06:37 2011 From: jg at freedesktop.org (Jim Gettys) Date: Wed, 16 Feb 2011 22:06:37 -0500 Subject: AT&T MPLS / BIB Routers In-Reply-To: References: <4D5C593E.9060808@freedesktop.org> Message-ID: <4D5C90BD.4040902@freedesktop.org> On 02/16/2011 06:16 PM, Mikeal Clark wrote: > I'm building up to 3000-4000ms latency with these BIB routers. We never > had this issue on the old point to points using Cisco gear. Bufferbloat is getting more and more common, as memory has gotten cheaper, and braindead people claim that 0 packet loss is a good idea and only test for bandwidth. So push back on AT&T, and start routinely testing latency under saturating load on each and every piece of hardware you bring in the door. You don't see the queues build unless the gear is the bottleneck of a path, so it's easy to have the problem move on you: ergo test everything independently. For example, as soon as your broadband bandwidth exceeds that of your wireless link in your house, your suffering will move from the broadband link to your 802.11 hop. There your home router (and your laptop both) will have even more bufferbloat than most broadband connections, and you suffer even worse. Ironically, the cleaner your 802.11 environment is, the worse you'll suffer, as some packet loss will keep the insanely huge buffers from filling. Most current OS hardware seems to put queues of around 256 packets in the driver, and there may be additional buffering above that. - Jim > > On Wed, Feb 16, 2011 at 5:09 PM, Jim Gettys > wrote: > > On 02/16/2011 05:44 PM, Mikeal Clark wrote: > > We just put in a AT&T MPLS and are having a pretty negative > experience with > the "Business in a Box" routers they are using for our smaller > sites. We > are seeing extremely high latency under load. Anyone have any > experience > with these devices that could shed some light on this? Are they > really this > bad? > > > There is excessive buffering in all sorts of devices all over the > Internet. This causes high latency under load (along with higher > packet losses, and lots of other problems. > > It's what I've been blogging about on http://gettys.wordpress.com. > These buffers fill; and they are so large they have defeated TCP > congestion avoidance to boot, with horrifying consequences. > > So far, I've found this problem (almost) everywhere I've looked: > o ICSI has good data that bufferbloat is endemic in DSL, > Cable, and FIOS. Delays are often measured in seconds (rather than > milliseconds). > o some corporate and ISP networks run without AQM, in > circumstances that they should. > o Windows, Mac OSX and Linux all have bufferbloat in their > network stacks, at a minimum on recent network device drivers, and > often elsewhere. > o Every home router I've tested is horrifyingly bad. > o 3g networks & 802.11 have this in spades. > > Why should AT&T's MPLS be any different? > > My next topic will be "transient" bufferbloat, having to do with > defeating slowstart. > > Come start helping fix this: please join us at bufferbloat.net > , as we > try to get people to fix it. Already there are some experimental > patches for the Linux Intel wireless driver. > Jim Gettys > Bell Labs > > From wavetossed at googlemail.com Wed Feb 16 21:10:43 2011 From: wavetossed at googlemail.com (Michael Dillon) Date: Wed, 16 Feb 2011 19:10:43 -0800 Subject: =?windows-1252?Q?Re=3A_NYTimes=3A_Egypt_Leaders_Found_=91Off=92_Switch_fo?= =?windows-1252?Q?r_Internet?= In-Reply-To: References: <7F7401DE-390B-41F9-8B09-F920FBBC637A@americafree.tv> Message-ID: > No the BGP and the physical links were down. What about non-Internet layer 2 links? A number of companies have private IP networks extending into Egypt providing MPLS or other VPN services. In addition, there are often longlines into the Gulf states to provide the Egyptian sites with redundancy. Were these communications also cut? One way to find out would be to talk to the networking folks at any major international consumer brand that is in Egypt. I would expect that nowadays if a Coke or a Pepsi is in a country, they will have some kind of IP VPN crossing that country's borders. --Michael Dillon http://www.linkedin.com/profile/view?id=13566587 From brandon.kim at brandontek.com Wed Feb 16 21:18:33 2011 From: brandon.kim at brandontek.com (Brandon Kim) Date: Wed, 16 Feb 2011 22:18:33 -0500 Subject: To the people who answer tech questions on this list In-Reply-To: References: Message-ID: I'm never afraid to ask a question, just as long as I've done my homework (due diligence) and not using this group to do work for me. Believe me, this group has helped me tremendously. As for LinkedIN, I have nothing against, it, but I don't use it. I don't have an account on it and not sure I ever want to. I'm already slightly on facebook, and very active on twitter, so nothing against linkedin, but there's just too many social media websites to keep track of.... Perhaps one day I will give it a try..... =) Brandon > Date: Wed, 16 Feb 2011 19:03:59 -0800 > Subject: To the people who answer tech questions on this list > From: wavetossed at googlemail.com > To: nanog at nanog.org > > This list serves a number of purposes and one of them is to answer > technical networking questions. But this list is also not the only > place that these types of questions are asked. For instance, LinkedIn > has a Q&A feature where people can ask and answer questions on a wide > range of topics. Just today I came across this BGP question: > http://www.linkedin.com/answers/technology/information-technology/computer-networking/TCH_ITS_CNW/792993-20766406 > > I would never suggest that LinkedIn could replace the NANOG mailing > list, but it is an interesting complement to it. There is a NANOG > group here: http://www.linkedin.com/groups?mostPopular=&gid=40718 and > a number of people are using LinkedIn for professional purposes. I > know many of you tried out Orkut and then migrated to Multiply.com and > found them lacking. But I would suggest that LinkedIn might be more > useful, in particular, to provide an entry level tier for questions. > > A lot of NANOG members are rather intimidated to ask questions which > might seem too beginner and I think that the NANOG group on LinkedIn > might be a good place to encourage such questions in order to draw out > more discussion among NANOG members without boosting the mailing list > traffic. > > What do you think? (Probably best to answer this on the NANOG group over at... > > --Michael Dillon > http://www.linkedin.com/profile/view?id=13566587 > From regnauld at nsrc.org Wed Feb 16 21:23:28 2011 From: regnauld at nsrc.org (Phil Regnauld) Date: Thu, 17 Feb 2011 11:23:28 +0800 Subject: To the people who answer tech questions on this list In-Reply-To: References: Message-ID: <20110217032322.GC25515@macbook.catpipe.net> Michael Dillon (wavetossed) writes: > > What do you think? (Probably best to answer this on the NANOG group over at... Hmm, wouldn't http://serverfault.com/ or http://www.quora.com/ be a more appropriate / efficient forum for technical questions ? Or does it have to be NANOG specific ? http://www.quora.com/Border-Gateway-Protocol-1/How-does-BGP-work?q=how+does+as+prepend+work+in+bgp http://serverfault.com/search?q=how+does+bgp+work Cheers, Phil From gbonser at seven.com Thu Feb 17 00:02:40 2011 From: gbonser at seven.com (George Bonser) Date: Wed, 16 Feb 2011 22:02:40 -0800 Subject: AT&T MPLS / BIB Routers In-Reply-To: References: <4D5C593E.9060808@freedesktop.org> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13B9E@RWC-EX1.corp.seven.com> > From: Mikeal Clark > Sent: Wednesday, February 16, 2011 3:16 PM > To: Jim Gettys > Cc: nanog at nanog.org > Subject: Re: AT&T MPLS / BIB Routers > > I'm building up to 3000-4000ms latency with these BIB routers. We > never had > this issue on the old point to points using Cisco gear. > Something I might try, assuming that the BIB unit plugs into a switch port, is to try bandwidth limiting that port to whatever the CIR is of the MPLS link. If buffering in that path is the problem, limiting the input bandwidth to the box to the maximum of the output bandwidth should eliminate any buffering in the path or the BIB box. Assuming your old Cisco gear was using the same network infrastructure, that might rule out excessive buffering in the MPLS path as the cause, unless AT&T can't actually deliver the advertized bandwidth across the path they are selling. What is the CIR? If you have a 10Meg path and have a GigE jacked into the box, yeah, it's going to get into buffers pretty quick. Maybe even taking the ethernet port down to 10Meg might help, depending on what you are expecting the bandwidth of the path to be. From regnauld at nsrc.org Thu Feb 17 00:16:13 2011 From: regnauld at nsrc.org (Phil Regnauld) Date: Thu, 17 Feb 2011 14:16:13 +0800 Subject: Slaving the root and other top-level DNS zones In-Reply-To: <4D5C8E3C.2040408@dougbarton.us> References: <12519660.360.1297898000961.JavaMail.franck@franck-martins-macbook-pro.local> <4D5C695B.9010605@dougbarton.us> <20110217021442.GA25515@macbook.catpipe.net> <4D5C8E3C.2040408@dougbarton.us> Message-ID: <20110217061607.GG25515@macbook.catpipe.net> Doug Barton (dougb) writes: > Actually it seems like you want to jump up and down on it. Given > that both the benefits and the potential problems have been > extensively debated elsewhere, I'll simply say that you raise > interesting questions that I think people interested in this method > should answer for themselves. So, you're advocating a method that potentially fragilizes one's DNS infrastructure, but you're not providing factual data backing up the purported advantages, and actually leave it up to the users to find out for themselves ? Gee, that's a seller :) > > Now, I'm not being skeptical here, but you put the arguments for > > slaving the top level zones as a win-only situation. > > And for me, and a lot of others it has been. If you have something > new to contribute in regards to the negatives I'm happy to listen, > although this might not be the best forum. Well, I was trying to raise constructive criticism - and hoped you would reply by providing links to resources/references summarizing the advantages, with more than empirical claims. But agreed, this is best discussed elsewhere :) Cheers, Phil From dougb at dougbarton.us Thu Feb 17 00:54:14 2011 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 16 Feb 2011 22:54:14 -0800 Subject: Slaving the root and other top-level DNS zones In-Reply-To: <20110217061607.GG25515@macbook.catpipe.net> References: <12519660.360.1297898000961.JavaMail.franck@franck-martins-macbook-pro.local> <4D5C695B.9010605@dougbarton.us> <20110217021442.GA25515@macbook.catpipe.net> <4D5C8E3C.2040408@dougbarton.us> <20110217061607.GG25515@macbook.catpipe.net> Message-ID: <4D5CC616.7080301@dougbarton.us> On 02/16/2011 22:16, Phil Regnauld wrote: > Doug Barton (dougb) writes: >> Actually it seems like you want to jump up and down on it. Given >> that both the benefits and the potential problems have been >> extensively debated elsewhere, I'll simply say that you raise >> interesting questions that I think people interested in this method >> should answer for themselves. > > So, you're advocating This is the second time you've made this claim, I ignored it the first time, but let me be clear. I'm not advocating anything. Someone else asked if it made sense to do so, and I responded. Yes, the FreeBSD named.conf states that there are advantages to this method, it also states that there are things to be careful about. > a method that potentially fragilizes one's > DNS infrastructure, but you're not providing factual data backing > up the purported advantages, Nope, I'm saying that it's all been discussed before, and this isn't the forum to discuss it in more detail. > and actually leave it up to the users to > find out for themselves ? Gee, that's a seller :) I think you'd be pretty foolish to not carefully weigh the pros and cons for yourself before making any change of this nature to something as critical as DNS, and I include things that I _do_ advocate in that category like DNSSEC and IPv6. >>> Now, I'm not being skeptical here, but you put the arguments for >>> slaving the top level zones as a win-only situation. >> >> And for me, and a lot of others it has been. If you have something >> new to contribute in regards to the negatives I'm happy to listen, >> although this might not be the best forum. > > Well, I was trying to raise constructive criticism - and hoped you > would reply by providing links to resources/references summarizing the > advantages, with more than empirical claims. > > But agreed, this is best discussed elsewhere :) Funny how you keep saying that .... Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From hank at efes.iucc.ac.il Thu Feb 17 00:46:49 2011 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 17 Feb 2011 08:46:49 +0200 Subject: To the people who answer tech questions on this list In-Reply-To: Message-ID: <5.1.0.14.2.20110217084509.036199a8@efes.iucc.ac.il> At 19:03 16/02/2011 -0800, Michael Dillon wrote: >This list serves a number of purposes and one of them is to answer >technical networking questions. But this list is also not the only >place that these types of questions are asked. For instance, LinkedIn >has a Q&A feature where people can ask and answer questions on a wide >range of topics. Just today I came across this BGP question: >http://www.linkedin.com/answers/technology/information-technology/computer-networking/TCH_ITS_CNW/792993-20766406 > >I would never suggest that LinkedIn could replace the NANOG mailing >list, but it is an interesting complement to it. There is a NANOG >group here: http://www.linkedin.com/groups?mostPopular=&gid=40718 and >a number of people are using LinkedIn for professional purposes. That would work if someone handled the join requests there. My request to join that group after about 10 days is still "pending". -Hank From trejrco at gmail.com Thu Feb 17 01:56:09 2011 From: trejrco at gmail.com (TJ) Date: Thu, 17 Feb 2011 02:56:09 -0500 Subject: To the people who answer tech questions on this list In-Reply-To: <20110217032322.GC25515@macbook.catpipe.net> References: <20110217032322.GC25515@macbook.catpipe.net> Message-ID: On Wed, Feb 16, 2011 at 22:23, Phil Regnauld wrote: > Michael Dillon (wavetossed) writes: > > > > What do you think? (Probably best to answer this on the NANOG group over > at... > > >> Hmm, wouldn't http://serverfault.com/ or http://www.quora.com/ be > a more > >> appropriate / efficient forum for technical questions ? Or does > it have > >> to be NANOG specific ? > > Nothing against mailing lists, or LinkedIn, but Quora is rather interesting > (& useful!) - the interface takes a minute or three to get used to, but > there seems to be a fair level of expertise there (and not just networking > related nor confined to "your normal social-networking circle"). > > /TJ > From wavetossed at googlemail.com Thu Feb 17 02:30:46 2011 From: wavetossed at googlemail.com (Michael Dillon) Date: Thu, 17 Feb 2011 00:30:46 -0800 Subject: To the people who answer tech questions on this list In-Reply-To: <20110217032322.GC25515@macbook.catpipe.net> References: <20110217032322.GC25515@macbook.catpipe.net> Message-ID: > As for LinkedIN, I have nothing against, it, but I don't use it. I don't > have an account on it > and not sure I ever want to. I'm already slightly on facebook, and very > active on twitter, > so nothing against linkedin, but there's just too many social media websites > to keep track of.... There are no perfect solutions. It seems to me that Twitter is not conducive to technical Q&A and given the choice between Facebook and LinkedIn, it seems that the professional social network is more likely to gain traction. Nobody has to participate if they don't want to; it's just about adding a choice and seeing whether or not people really want this kind of thing. > ? ? ? ?Hmm, wouldn't http://serverfault.com/ or http://www.quora.com/ be a more > ? ? ? ?appropriate / efficient forum for technical questions ? ?Or does it have > ? ? ? ?to be NANOG specific ? Never heard of Quora and that seems to be tied to Facebook, so not ideal. As for serverfault, that is a good idea but serverfault is not really for general IP networking questions related to routing and switching or ISP networking. Therefore, I have proposed that the operators of ServerFault and StackOverflow create a new site called NANOG (maybe it shouldn't be exactly that name). http://area51.stackexchange.com/proposals/29470/nanog If you have questions, comments, or want to commit to using the site for Q&A, please visit it and join in. It accepts Google, Yahoo, MyOpenID, AOL and Facebook credentials. --Michael Dillon http://www.linkedin.com/profile/view?id=13566587 From carlosm3011 at gmail.com Thu Feb 17 06:34:35 2011 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Thu, 17 Feb 2011 12:34:35 +0000 Subject: Open Source Tunnel Broker software implementations ? Message-ID: Hello! I am looking for open source tunnel broker implementations. There are some mentions in Google but nothing very specific. Also I would like to get in touch with folks who might be working or interested on implementing something like that. Warm regards, Carlos -- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net ========================= From iljitsch at muada.com Thu Feb 17 06:39:27 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 17 Feb 2011 13:39:27 +0100 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> Message-ID: <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> On 11 feb 2011, at 17:51, William Herrin wrote: > We can't backport ULA into IPv4 private > addressing; there aren't enough addresses for the math to work. So we > either make such folks jump through all kinds of hoops to get their > networks to function, or we assign addresses that could otherwise be > used on the big-I Internet. Not that it matters because it's too late now and it would only give us a few more months, but: Does the US government really need more than 150 million addresses, of which about half are not publically routed? Non-publically routed addresses can be reused by others as long as the stuff both users connect to doesn't overlap. From jcurran at istaff.org Thu Feb 17 07:08:50 2011 From: jcurran at istaff.org (John Curran) Date: Thu, 17 Feb 2011 08:08:50 -0500 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> Message-ID: <54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> On Feb 17, 2011, at 7:39 AM, Iljitsch van Beijnum wrote: > Not that it matters because it's too late now and it would only give us a few more months, but: > > Does the US government really need more than 150 million addresses, of which about half are not publically routed? Non-publically routed addresses can be reused by others as long as the stuff both users connect to doesn't overlap. Again, I note that we've collectively allocated the 95%+ of the address space which was made available outside of DoD's original blocks, and then considering that US DoD additionally returned 2 more /8's for the community (noted here: ), I believe they've shown significant consideration to the Internet community. The fact that any particular prefix today isn't in your particular routing table does not imply that global uniqueness isn't desired. Rather than saying 240/4 is unusable for another three years, perhaps the service provider community could make plain that this space needs to be made usable (ala http://tools.ietf.org/html/draft-fuller-240space-02 or http://tools.ietf.org/html/draft-wilson-class-e-00, etc.) on a priority basis and work with the operating system and vendor community actually to make this happen? There's a chance that it could be made usable with sufficient focus to make that happen, but it is assured not to be usable if eternally delayed because it is "too hard" to accomplish. /John (my views alone; 100% recycled electrons used in this message) From jg at freedesktop.org Thu Feb 17 07:13:24 2011 From: jg at freedesktop.org (Jim Gettys) Date: Thu, 17 Feb 2011 08:13:24 -0500 Subject: AT&T MPLS / BIB Routers In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13B9E@RWC-EX1.corp.seven.com> References: <4D5C593E.9060808@freedesktop.org> <5A6D953473350C4B9995546AFE9939EE0BC13B9E@RWC-EX1.corp.seven.com> Message-ID: <4D5D1EF4.7080704@freedesktop.org> On 02/17/2011 01:02 AM, George Bonser wrote: > > >> From: Mikeal Clark >> Sent: Wednesday, February 16, 2011 3:16 PM >> To: Jim Gettys >> Cc: nanog at nanog.org >> Subject: Re: AT&T MPLS / BIB Routers >> >> I'm building up to 3000-4000ms latency with these BIB routers. We >> never had >> this issue on the old point to points using Cisco gear. >> > > Something I might try, assuming that the BIB unit plugs into a switch > port, is to try bandwidth limiting that port to whatever the CIR is of > the MPLS link. If buffering in that path is the problem, limiting the > input bandwidth to the box to the maximum of the output bandwidth should > eliminate any buffering in the path or the BIB box. Assuming your old > Cisco gear was using the same network infrastructure, that might rule > out excessive buffering in the MPLS path as the cause, unless AT&T can't > actually deliver the advertized bandwidth across the path they are > selling. > > What is the CIR? If you have a 10Meg path and have a GigE jacked into > the box, yeah, it's going to get into buffers pretty quick. Maybe even > taking the ethernet port down to 10Meg might help, depending on what you > are expecting the bandwidth of the path to be. Yes, bandwidth limiting is something to try. It's how you can deal with your home broadband connection to inject sanity. Note that you can have bufferbloat just upstream as well. For example, if you plug a GigE ethernet into a 100Mbps switch, if there is buffering upstream, it will fill. http://gettys.wordpress.com/2010/11/29/home-router-puzzle-piece-one-fun-with-your-switch/ In the test case in that post, the bloating is in the laptop plugged into the 100Mbps switch (in the device driver ring, and possibly transmit queue). - Jim From marka at isc.org Thu Feb 17 07:31:36 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 18 Feb 2011 00:31:36 +1100 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: Your message of "Thu, 17 Feb 2011 08:08:50 CDT." <54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> Message-ID: <20110217133136.85B40A47F14@drugs.dv.isc.org> In message <54CC2B0D-EAE0-4B79-AF19-20BBD233A581 at istaff.org>, John Curran writes: > On Feb 17, 2011, at 7:39 AM, Iljitsch van Beijnum wrote: > > > Not that it matters because it's too late now and it would only give = > us a few more months, but: > >=20 > > Does the US government really need more than 150 million addresses, of = > which about half are not publically routed? Non-publically routed = > addresses can be reused by others as long as the stuff both users = > connect to doesn't overlap. > > Again, I note that we've collectively allocated the 95%+ of the address=20= > > space which was made available outside of DoD's original blocks, and = > then > considering that US DoD additionally returned 2 more /8's for the = > community=20 > (noted here: = > ),=20 > I believe they've shown significant consideration to the Internet = > community. > The fact that any particular prefix today isn't in your particular = > routing=20 > table does not imply that global uniqueness isn't desired. > > Rather than saying 240/4 is unusable for another three years, perhaps = > the > service provider community could make plain that this space needs to be=20= > > made usable (ala http://tools.ietf.org/html/draft-fuller-240space-02 or=20= > > http://tools.ietf.org/html/draft-wilson-class-e-00, etc.) on a priority=20= > > basis and work with the operating system and vendor community actually > to make this happen? There's a chance that it could be made usable with=20= > > sufficient focus to make that happen, but it is assured not to be usable > if eternally delayed because it is "too hard" to accomplish. > > /John > > (my views alone; 100% recycled electrons used in this message) It's not usable as general purpose unicast. Both those drafts attempt to do that. It would be possible to use it as restricted purpose unicast, i.e. to connect from a cpe border router to a 6rd and/or LSN with the cpe border router signaling that it support the use of class E addresses when it requests a address from upstream. The upsteam only returns a class E address when it is sure that the network between the LSN/6rd supports class E traffic. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From ryan.finnesey at HarrierInvestments.com Thu Feb 17 08:19:57 2011 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Thu, 17 Feb 2011 06:19:57 -0800 Subject: AT&T MPLS / BIB Routers In-Reply-To: References: <4D5C593E.9060808@freedesktop.org> Message-ID: <6EFFEFBAC68377459A2E972105C759EC03645A08@EXVBE005-2.exch005intermedia.net> What type of hardware are they using for this BIB router? Cheers Ryan -----Original Message----- From: Mikeal Clark [mailto:mikeal.clark at gmail.com] Sent: Wednesday, February 16, 2011 6:16 PM To: Jim Gettys Cc: nanog at nanog.org Subject: Re: AT&T MPLS / BIB Routers I'm building up to 3000-4000ms latency with these BIB routers. We never had this issue on the old point to points using Cisco gear. On Wed, Feb 16, 2011 at 5:09 PM, Jim Gettys wrote: > On 02/16/2011 05:44 PM, Mikeal Clark wrote: > >> We just put in a AT&T MPLS and are having a pretty negative >> experience with the "Business in a Box" routers they are using for >> our smaller sites. We are seeing extremely high latency under load. >> Anyone have any experience with these devices that could shed some >> light on this? Are they really this bad? >> >> > There is excessive buffering in all sorts of devices all over the Internet. > This causes high latency under load (along with higher packet losses, > and lots of other problems. > > It's what I've been blogging about on http://gettys.wordpress.com. > These buffers fill; and they are so large they have defeated TCP > congestion avoidance to boot, with horrifying consequences. > > So far, I've found this problem (almost) everywhere I've looked: > o ICSI has good data that bufferbloat is endemic in DSL, Cable, > and FIOS. Delays are often measured in seconds (rather than milliseconds). > o some corporate and ISP networks run without AQM, in > circumstances that they should. > o Windows, Mac OSX and Linux all have bufferbloat in their > network stacks, at a minimum on recent network device drivers, and often elsewhere. > o Every home router I've tested is horrifyingly bad. > o 3g networks & 802.11 have this in spades. > > Why should AT&T's MPLS be any different? > > My next topic will be "transient" bufferbloat, having to do with > defeating slowstart. > > Come start helping fix this: please join us at bufferbloat.net, as we > try to get people to fix it. Already there are some experimental > patches for the Linux Intel wireless driver. > Jim Gettys > Bell Labs > > From owen at delong.com Thu Feb 17 08:20:30 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 17 Feb 2011 06:20:30 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> Message-ID: <8B0FDF52-A36D-46E8-9408-3C1A4C5D30CD@delong.com> On Feb 17, 2011, at 4:39 AM, Iljitsch van Beijnum wrote: > On 11 feb 2011, at 17:51, William Herrin wrote: > >> We can't backport ULA into IPv4 private >> addressing; there aren't enough addresses for the math to work. So we >> either make such folks jump through all kinds of hoops to get their >> networks to function, or we assign addresses that could otherwise be >> used on the big-I Internet. > > Not that it matters because it's too late now and it would only give us a few more months, but: > > Does the US government really need more than 150 million addresses, of which about half are not publically routed? Non-publically routed addresses can be reused by others as long as the stuff both users connect to doesn't overlap. The DoD does not seem particularly anxious to announce or explain their usage of those blocks to the rest of the community. They have much larger quantities of significantly more sophisticated armaments than ARIN. I agree it would be nice if they would voluntarily return whatever is appropriate to the community, but, as you say, there is little upside to them doing so anyway. Certainly not enough to make the risks of attempting to obtain it through any means other than voluntary return feasible or even worthy of consideration. Owen From Valdis.Kletnieks at vt.edu Thu Feb 17 08:32:57 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 17 Feb 2011 09:32:57 -0500 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: Your message of "Thu, 17 Feb 2011 08:08:50 EST." <54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> Message-ID: <38565.1297953177@localhost> On Thu, 17 Feb 2011 08:08:50 EST, John Curran said: > Rather than saying 240/4 is unusable for another three years, perhaps the > service provider community could make plain that this space needs to be > made usable In other words, you're going to tell Granny she needs to upgrade to Windows 8 and/or replace her CPE because you couldn't get your act together and deploy IPv6 - even though her friends at the bridge club who are customers of your clued competitor didn't have to do a thing. And then she has to do something *else* 9 months later when you need to deploy IPv6 *anyhow*. I encourage my competitors to design their business plans that way. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jcurran at istaff.org Thu Feb 17 08:44:04 2011 From: jcurran at istaff.org (John Curran) Date: Thu, 17 Feb 2011 09:44:04 -0500 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <38565.1297953177@localhost> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> <38565.1297953177@localhost> Message-ID: <98FCFBF5-3E2F-4AC5-BFD3-1F61C7DBA025@istaff.org> On Feb 17, 2011, at 9:32 AM, Valdis.Kletnieks at vt.edu wrote: > On Thu, 17 Feb 2011 08:08:50 EST, John Curran said: > >> Rather than saying 240/4 is unusable for another three years, perhaps the >> service provider community could make plain that this space needs to be >> made usable > > In other words, you're going to tell Granny she needs to upgrade to Windows 8 > and/or replace her CPE because you couldn't get your act together and deploy > IPv6 - even though her friends at the bridge club who are customers of > your clued competitor didn't have to do a thing. Not, what I'm saying is that we've been considering this matter for more than 10 years, and as old as her machine is, it would have been patched once since then if we had bothered to note that "Reserved for Future Use" should be treated as unicast space. The same argument applies now: unless there is a reason to save 240/8, it should at least be redefined to be usable in some manner so that we don't repeat the same argument 5 years from now. /John From jra at baylink.com Thu Feb 17 08:59:45 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 17 Feb 2011 09:59:45 -0500 (EST) Subject: To the people who answer tech questions on this list In-Reply-To: Message-ID: <17895217.14.1297954785315.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Michael Dillon" > There are no perfect solutions. It seems to me that Twitter is not > conducive to technical Q&A and given the choice between Facebook and > LinkedIn, it seems that the professional social network is more likely > to gain traction. Nobody has to participate if they don't want to; > it's just about adding a choice and seeing whether or not people > really want this kind of thing. They don't. The issue is *really* knowledge capture -- not the getting to the solutions, but the keeping of them for later. I set up a wikia for this, 3 and more years ago. Crickets. Cheers, -- jra From mikeal.clark at gmail.com Thu Feb 17 09:04:51 2011 From: mikeal.clark at gmail.com (Mikeal Clark) Date: Thu, 17 Feb 2011 09:04:51 -0600 Subject: AT&T MPLS / BIB Routers In-Reply-To: <6EFFEFBAC68377459A2E972105C759EC03645A08@EXVBE005-2.exch005intermedia.net> References: <4D5C593E.9060808@freedesktop.org> <6EFFEFBAC68377459A2E972105C759EC03645A08@EXVBE005-2.exch005intermedia.net> Message-ID: The routers are Edgemarc. P/N EM-4608T4 http://www.edgewaternetworks.com/edgemarc_overview_page.htm On Thu, Feb 17, 2011 at 8:19 AM, Ryan Finnesey < ryan.finnesey at harrierinvestments.com> wrote: > What type of hardware are they using for this BIB router? > > Cheers > Ryan > > > -----Original Message----- > From: Mikeal Clark [mailto:mikeal.clark at gmail.com] > Sent: Wednesday, February 16, 2011 6:16 PM > To: Jim Gettys > Cc: nanog at nanog.org > Subject: Re: AT&T MPLS / BIB Routers > > I'm building up to 3000-4000ms latency with these BIB routers. We never > had this issue on the old point to points using Cisco gear. > > On Wed, Feb 16, 2011 at 5:09 PM, Jim Gettys wrote: > > > On 02/16/2011 05:44 PM, Mikeal Clark wrote: > > > >> We just put in a AT&T MPLS and are having a pretty negative > >> experience with the "Business in a Box" routers they are using for > >> our smaller sites. We are seeing extremely high latency under load. > > >> Anyone have any experience with these devices that could shed some > >> light on this? Are they really this bad? > >> > >> > > There is excessive buffering in all sorts of devices all over the > Internet. > > This causes high latency under load (along with higher packet losses, > > and lots of other problems. > > > > It's what I've been blogging about on http://gettys.wordpress.com. > > These buffers fill; and they are so large they have defeated TCP > > congestion avoidance to boot, with horrifying consequences. > > > > So far, I've found this problem (almost) everywhere I've looked: > > o ICSI has good data that bufferbloat is endemic in DSL, Cable, > > > and FIOS. Delays are often measured in seconds (rather than > milliseconds). > > o some corporate and ISP networks run without AQM, in > > circumstances that they should. > > o Windows, Mac OSX and Linux all have bufferbloat in their > > network stacks, at a minimum on recent network device drivers, and > often elsewhere. > > o Every home router I've tested is horrifyingly bad. > > o 3g networks & 802.11 have this in spades. > > > > Why should AT&T's MPLS be any different? > > > > My next topic will be "transient" bufferbloat, having to do with > > defeating slowstart. > > > > Come start helping fix this: please join us at bufferbloat.net, as we > > try to get people to fix it. Already there are some experimental > > patches for the Linux Intel wireless driver. > > Jim Gettys > > Bell Labs > > > > > From wnagele at ripe.net Thu Feb 17 09:11:51 2011 From: wnagele at ripe.net (Wolfgang Nagele) Date: Thu, 17 Feb 2011 16:11:51 +0100 Subject: Fwd: [arin-announce] IN-ADDR.ARPA Zone Transfer Complete In-Reply-To: <4D5C420C.6030306@dougbarton.us> References: <4D5C3952.1080602@arin.net> <4D5C420C.6030306@dougbarton.us> Message-ID: <4D5D3AB7.8080909@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, > Relevant to another post today, I've noticed that neither the *.ip6-servers.arpa > nor the *.in-addr-servers.arpa allow axfr. Which leads to the following questions: > > 1. Was that a conscious decision, and if so why? Speaking for the operator of f.in-addr-servers.arpa and f.ip6-servers.arpa this was simply not on our radar. > 2. Is there any hope that axfr could be permitted in the future? Since we are also operating k.root-servers.net and have provided XFR from it for all this time we will do so for these servers as well. This has now been enabled on our systems. Regards, Wolfgang Nagele RIPE NCC DNS Group Manager -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1dOrcACgkQjO7G63Byy8f5hACgmRBBPCYlPI4vVumvAwyWZAgJ t8MAoJs4BOwzKiKYwNjYY9oOIADlhTzs =aFMj -----END PGP SIGNATURE----- From santino.codispoti at gmail.com Thu Feb 17 09:21:18 2011 From: santino.codispoti at gmail.com (Santino Codispoti) Date: Thu, 17 Feb 2011 10:21:18 -0500 Subject: ISDN BRI Message-ID: Is it possible to order a ISDN BRI line from the LEC and have them look at the design of a DS1 and have them if possible design the ISDN BRI lineon a devurse path or at lest different equipment within the CO? From jra at baylink.com Thu Feb 17 09:30:12 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 17 Feb 2011 10:30:12 -0500 (EST) Subject: ISDN BRI In-Reply-To: Message-ID: <8220928.34.1297956612558.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Santino Codispoti" > Is it possible to order a ISDN BRI line from the LEC and have them > look at the design of a DS1 and have them if possible design the ISDN > BRI line on a diverse path or at lest different equipment within the > CO? Off hand, I wouldn't expect a carrier to do any special engineering on a BRI -- can you even *order* a BRI these days? :-) As old NANOG hands know, though, it doesn't matter *what* you ask for, few-to-no carriers properly manage physical diversity requests properly over the long haul, anyway, and the only way to do it yourself often requires that you ask the carrier for records they won't give you. Regularly. Like, monthly. Even if you're paying them extra for the diversity. Cheers, -- jra From jgreco at ns.sol.net Thu Feb 17 09:37:06 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 17 Feb 2011 09:37:06 -0600 (CST) Subject: ISDN BRI In-Reply-To: Message-ID: <201102171537.p1HFb6SR077062@aurora.sol.net> > Is it possible to order a ISDN BRI line from the LEC and have them > look at the design of a DS1 and have them if possible design the ISDN > BRI lineon a devurse path or at lest different equipment within the > CO? Effectively: No. You might find a salescritter willing to *sell* you such a thing, but it's not likely to have any basis in reality, at least long-term. In the general case, telcos try *not* to have diverse paths for end- user lines; for them, it's simpler to have one big mondo cable hauling lots of connections into an area than it is to have three or four that are running in separate directions. You can certainly find counterexamples where some level of diversity might be available (such as a different cable hanging on the same poles), but actual diversity from start to finish is tough. You would be slightly better off with a DS1 and a connection from the cable company; they may share a bunch of poles, but at some point it will diverge and you're largely guaranteed to be on somewhat different equipment in the CO/headend, heh. ... 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. From streiner at cluebyfour.org Thu Feb 17 05:46:16 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 17 Feb 2011 06:46:16 -0500 (EST) Subject: ISDN BRI In-Reply-To: References: Message-ID: On Thu, 17 Feb 2011, Santino Codispoti wrote: > Is it possible to order a ISDN BRI line from the LEC and have them > look at the design of a DS1 and have them if possible design the ISDN > BRI lineon a devurse path or at lest different equipment within the > CO? I suspect that, particularly for something as small (in terms of revenue to the LEC) as a BRI circuit, you won't have much leverage to ask for anything 'off the menu', like diverse physical routing through the CO. When you get to the point of dealing with the copper in the ground/on the pole, your options for route diversity are usually extremely limited (read: nonexistent). Telco copper plant is usually based on large multipair cables from the CO on a specific route, so even if you managed to get them to commit to diverse routeing in the CO, the copper pairs will still be in the same cable bundle, entering your building and the CO at the same points. jms From jared at puck.nether.net Thu Feb 17 09:50:48 2011 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 17 Feb 2011 10:50:48 -0500 Subject: ISDN BRI In-Reply-To: References: Message-ID: <4A8C7BE7-6A2F-4C7F-9092-555DD7E52C37@puck.nether.net> What you can do is (if you are important enough) apply for TSP (tsp.ncs.gov) in conjunction with provisioning of a circuit to actually have this type of engineering happen and persist, including emergency restoration. If your local carrier doesn't offer the redundancy you want, your only other choice is to build it yourself. Considering the cost of lighting a 10G or 1G strand of fiber for 10km or 20km, working with a BRI isn't that important anymore. - Jared (who has a BRI line for his "POTS" at home to get clean dial tone at his distance from the CO) On Feb 17, 2011, at 6:46 AM, Justin M. Streiner wrote: > On Thu, 17 Feb 2011, Santino Codispoti wrote: > >> Is it possible to order a ISDN BRI line from the LEC and have them >> look at the design of a DS1 and have them if possible design the ISDN >> BRI lineon a devurse path or at lest different equipment within the >> CO? > > I suspect that, particularly for something as small (in terms of revenue to the LEC) as a BRI circuit, you won't have much leverage to ask for anything 'off the menu', like diverse physical routing through the CO. > > When you get to the point of dealing with the copper in the ground/on the pole, your options for route diversity are usually extremely limited (read: nonexistent). Telco copper plant is usually based on large multipair cables from the CO on a specific route, so even if you managed to get them to commit to diverse routeing in the CO, the copper pairs will still be in the same cable bundle, entering your building and the CO at the same points. > > jms From paul at paulstewart.org Thu Feb 17 09:56:06 2011 From: paul at paulstewart.org (Paul Stewart) Date: Thu, 17 Feb 2011 10:56:06 -0500 Subject: ISDN BRI In-Reply-To: <8220928.34.1297956612558.JavaMail.root@benjamin.baylink.com> References: <8220928.34.1297956612558.JavaMail.root@benjamin.baylink.com> Message-ID: <07b101cbcebb$307ebe90$917c3bb0$@org> Unfortunate but very true.... seen that many of times where a "special engineering" fee has been charged specifically to carry a circuit in a diverse manner (or even reasonably diverse). Then it breaks and the excuses start as to why it was never done as promised - then a couple of years later it breaks and nobody has paperwork that shows it was *ever* supposed to be diverse in the first place.... ;) Paul -----Original Message----- From: Jay Ashworth [mailto:jra at baylink.com] Sent: Thursday, February 17, 2011 10:30 AM To: NANOG Subject: Re: ISDN BRI ----- Original Message ----- > From: "Santino Codispoti" > Is it possible to order a ISDN BRI line from the LEC and have them > look at the design of a DS1 and have them if possible design the ISDN > BRI line on a diverse path or at lest different equipment within the > CO? Off hand, I wouldn't expect a carrier to do any special engineering on a BRI -- can you even *order* a BRI these days? :-) As old NANOG hands know, though, it doesn't matter *what* you ask for, few-to-no carriers properly manage physical diversity requests properly over the long haul, anyway, and the only way to do it yourself often requires that you ask the carrier for records they won't give you. Regularly. Like, monthly. Even if you're paying them extra for the diversity. Cheers, -- jra From andrew.wallace at rocketmail.com Thu Feb 17 09:56:19 2011 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Thu, 17 Feb 2011 07:56:19 -0800 (PST) Subject: Solar flare to reach earth Message-ID: <624439.94303.qm@web59602.mail.ac4.yahoo.com> These "coronal mass ejections" will slam into the Earth's magnetic shield. The biggest flares can disrupt technology, including power grids, communications systems and satellites. "Our current view is that the effect of the solar flare is likely to reach Earth later today (Thursday GMT), possibly tomorrow morning," said Alan Thomson, head of geomagnetism at the British Geological Survey (BGS). http://www.bbc.co.uk/news/science-environment-12493980 Andrew From jabley at hopcount.ca Thu Feb 17 10:03:07 2011 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 17 Feb 2011 11:03:07 -0500 Subject: [arin-announce] IN-ADDR.ARPA Zone Transfer Complete In-Reply-To: <43EE6734-3F25-4905-BAC0-5BACA532C01B@virtualized.org> References: <4D5C3952.1080602@arin.net> <43EE6734-3F25-4905-BAC0-5BACA532C01B@virtualized.org> Message-ID: On 2011-02-16, at 21:15, David Conrad wrote: > Congrats to all on getting this done! It's been a long time in coming. Good to see it finally finished. You're very welcome :-) however, the work is not quiet yet done. Next steps are: week of 2011-02-21: IN-ADDR.ARPA zone dropped from B, C, E, G, I, M root servers week of 2011-02-28: IN-ADDR.ARPA zone dropped from A, D, F, H, K, L root servers week of 2011-03-06: DS record for IN-ADDR.ARPA inserted into ARPA zone At the end of this process every subdomain of ARPA will be fully DNSSEC-signed. Query rates on the new servers (those operated by the RIRs and ICANN) are currently low, but are expected to increase as the IN-ADDR.ARPA zone is dropped from root servers. Some stats on the ICANN-operated servers can be found here: http://dns.icann.org/services/inaddr-arpa/ http://dns.icann.org/services/ip6-arpa/ (click through on the graphs for more detail) Joe From santino.codispoti at gmail.com Thu Feb 17 10:13:05 2011 From: santino.codispoti at gmail.com (Santino Codispoti) Date: Thu, 17 Feb 2011 11:13:05 -0500 Subject: ISDN BRI In-Reply-To: <4A8C7BE7-6A2F-4C7F-9092-555DD7E52C37@puck.nether.net> References: <4A8C7BE7-6A2F-4C7F-9092-555DD7E52C37@puck.nether.net> Message-ID: This may be a great options because the network will be going into air ports. On Thu, Feb 17, 2011 at 10:50 AM, Jared Mauch wrote: > What you can do is (if you are important enough) apply for TSP (tsp.ncs.gov) in conjunction with provisioning of a circuit to actually have this type of engineering happen and persist, including emergency restoration. ?If your local carrier doesn't offer the redundancy you want, your only other choice is to build it yourself. ?Considering the cost of lighting a 10G or 1G strand of fiber for 10km or 20km, working with a BRI isn't that important anymore. > > - Jared > (who has a BRI line for his "POTS" at home to get clean dial tone at his distance from the CO) > > On Feb 17, 2011, at 6:46 AM, Justin M. Streiner wrote: > >> On Thu, 17 Feb 2011, Santino Codispoti wrote: >> >>> Is it possible to order a ISDN BRI line from the LEC and have them >>> look at the design of a DS1 and have them if possible design the ISDN >>> BRI lineon a devurse path or at lest different equipment within the >>> CO? >> >> I suspect that, particularly for something as small (in terms of revenue to the LEC) as a BRI circuit, you won't have much leverage to ask for anything 'off the menu', like diverse physical routing through the CO. >> >> When you get to the point of dealing with the copper in the ground/on the pole, your options for route diversity are usually extremely limited (read: nonexistent). ?Telco copper plant is usually based on large multipair cables from the CO on a specific route, so even if you managed to get them to commit to diverse routeing in the CO, the copper pairs will still be in the same cable bundle, entering your building and the CO at the same points. >> >> jms > > From jbates at brightok.net Thu Feb 17 10:13:37 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 17 Feb 2011 10:13:37 -0600 Subject: To the people who answer tech questions on this list In-Reply-To: References: <20110217032322.GC25515@macbook.catpipe.net> Message-ID: <4D5D4931.2070908@brightok.net> On 2/17/2011 2:30 AM, Michael Dillon wrote: > Never heard of Quora and that seems to be tied to Facebook, so not > ideal. Did you just dis Facebook while plugging linked-in? Jack (continuing to ask stupid and redundant questions on NANOG) From jbates at brightok.net Thu Feb 17 10:20:11 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 17 Feb 2011 10:20:11 -0600 Subject: Solar flare to reach earth In-Reply-To: <624439.94303.qm@web59602.mail.ac4.yahoo.com> References: <624439.94303.qm@web59602.mail.ac4.yahoo.com> Message-ID: <4D5D4ABB.9040305@brightok.net> On 2/17/2011 9:56 AM, andrew.wallace wrote: > These "coronal mass ejections" will slam into the Earth's magnetic shield. > > The biggest flares can disrupt technology, including power grids, communications systems and satellites. > > "Our current view is that the effect of the solar flare is likely to > reach Earth later today (Thursday GMT), possibly tomorrow morning," said Alan Thomson, head of geomagnetism at the British Geological Survey > (BGS). > > http://www.bbc.co.uk/news/science-environment-12493980 > The sky is falling! The Sky is falling! We have been saved from dealing with IPv6 by solar flares! Everyone power off their computers and routers now. :) Jack (my bridge troll is very fat) From smb at cs.columbia.edu Thu Feb 17 10:24:54 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Thu, 17 Feb 2011 11:24:54 -0500 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <98FCFBF5-3E2F-4AC5-BFD3-1F61C7DBA025@istaff.org> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> <38565.1297953177@localhost> <98FCFBF5-3E2F-4AC5-BFD3-1F61C7DBA025@istaff.org> Message-ID: On Feb 17, 2011, at 9:44 04AM, John Curran wrote: > On Feb 17, 2011, at 9:32 AM, Valdis.Kletnieks at vt.edu wrote: > >> On Thu, 17 Feb 2011 08:08:50 EST, John Curran said: >> >>> Rather than saying 240/4 is unusable for another three years, perhaps the >>> service provider community could make plain that this space needs to be >>> made usable >> >> In other words, you're going to tell Granny she needs to upgrade to Windows 8 >> and/or replace her CPE because you couldn't get your act together and deploy >> IPv6 - even though her friends at the bridge club who are customers of >> your clued competitor didn't have to do a thing. > > Not, what I'm saying is that we've been considering this matter for more than > 10 years, and as old as her machine is, it would have been patched once since > then if we had bothered to note that "Reserved for Future Use" should be treated > as unicast space. > > The same argument applies now: unless there is a reason to save 240/8, it should > at least be redefined to be usable in some manner so that we don't repeat the > same argument 5 years from now. > John, my usual rule of thumb for something like this is 8-10 years -- 3-5 years for the next major version of Windows, plus (at least) 5 for enough old machines to die off. There are just too many machines that don't listen to Windows Upgrade; you can't roll out a major change that way. We won't even talk about things like home NATs and cable/DSL/fiber modems, which tend to be longer-lived. If we'd started this 10 years ago, as you suggest in a later note, maybe it would be present in Windows 7, possibly even Vista. So we'd be set -- Windows XP is gone by now, right? Oh, yeah, it isn't... And as Valdis points out, it just doesn't buy us that much time. It might be worth doing for ISP backbones, and for things like tunnel endpoints. For anything else, it's not worth the effort -- and I suspect never was. --Steve Bellovin, http://www.cs.columbia.edu/~smb From jbates at brightok.net Thu Feb 17 10:28:19 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 17 Feb 2011 10:28:19 -0600 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> <38565.1297953177@localhost> <98FCFBF5-3E2F-4AC5-BFD3-1F61C7DBA025@istaff.org> Message-ID: <4D5D4CA3.50000@brightok.net> On 2/17/2011 10:24 AM, Steven Bellovin wrote: > It might be worth doing for ISP backbones, and for things like tunnel endpoints. > For anything else, it's not worth the effort -- and I suspect never was. I think several people's point is that it may be useful for the CGN/LSN numbering and other special case scenarios where a CPE might be compliant and the windows box would be ignorant. Jack From literalka at gmail.com Thu Feb 17 10:31:16 2011 From: literalka at gmail.com (Leon Kaiser) Date: Thu, 17 Feb 2011 11:31:16 -0500 Subject: Solar flare to reach earth In-Reply-To: <4D5D4ABB.9040305@brightok.net> References: <624439.94303.qm@web59602.mail.ac4.yahoo.com> <4D5D4ABB.9040305@brightok.net> Message-ID: <1297960276.2038.0.camel@kafir> Huh, interesting how the media didn't panic. ======================================================== Leon Kaiser - Head of GNAA Public Relations - literalka at gnaa.eu || literalka at goatse.fr http://gnaa.eu || http://security.goatse.fr 7BEECD8D FCBED526 F7960173 459111CE F01F9923 "The mask of anonymity is not intensely constructive." -- Andrew "weev" Auernheimer ======================================================== On Thu, 2011-02-17 at 10:20 -0600, Jack Bates wrote: > > On 2/17/2011 9:56 AM, andrew.wallace wrote: > > These "coronal mass ejections" will slam into the Earth's magnetic shield. > > > > The biggest flares can disrupt technology, including power grids, communications systems and satellites. > > > > "Our current view is that the effect of the solar flare is likely to > > reach Earth later today (Thursday GMT), possibly tomorrow morning," said Alan Thomson, head of geomagnetism at the British Geological Survey > > (BGS). > > > > http://www.bbc.co.uk/news/science-environment-12493980 > > > > > The sky is falling! The Sky is falling! > > > We have been saved from dealing with IPv6 by solar flares! Everyone > power off their computers and routers now. :) > > > Jack (my bridge troll is very fat) > From Valdis.Kletnieks at vt.edu Thu Feb 17 10:33:22 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 17 Feb 2011 11:33:22 -0500 Subject: Solar flare to reach earth In-Reply-To: Your message of "Thu, 17 Feb 2011 07:56:19 PST." <624439.94303.qm@web59602.mail.ac4.yahoo.com> References: <624439.94303.qm@web59602.mail.ac4.yahoo.com> Message-ID: <11752.1297960402@localhost> On Thu, 17 Feb 2011 07:56:19 PST, "andrew.wallace" said: > The biggest flares can disrupt technology, including power grids, > communications systems and satellites. > http://www.bbc.co.uk/news/science-environment-12493980 Better references: http://www.spaceweather.com/ and http://www.swpc.noaa.gov/: 3-day Solar-Geophysical Forecast issued Feb 16 22:00 UTC Solar Activity Forecast: Solar activity is expected to be moderate with a chance for an isolated major flare for the next three days (17-19 February). Region 1158 is expected to produce more M-class flares and still has the potential for producing an M5 or greater x-ray event. There is a chance for isolated M-class activity from Region 1161. Geophysical Activity Forecast: The geomagnetic field is expected to be predominately quiet on day one (February 17). An increase to unsettled to active conditions, with a chance for minor storm periods is expected late on day one into day two (18 February). The increased activity is forecast due to the expected arrival of the CME associated with the X2 flare that occurred on 15/0156Z. Day three (19 February) is expected to be quiet to active as the disturbance subsides. *yawn*. "active" to "minor storm". Move along, nothing much to see except some aurora. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From gbonser at seven.com Thu Feb 17 10:35:08 2011 From: gbonser at seven.com (George Bonser) Date: Thu, 17 Feb 2011 08:35:08 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <38565.1297953177@localhost> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com><245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com><8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at><09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com><54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> <38565.1297953177@localhost> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13BB8@RWC-EX1.corp.seven.com> > > In other words, you're going to tell Granny she needs to upgrade to > Windows 8 and/or replace her CPE because you couldn't get your act > together and deploy > IPv6 - even though her friends at the bridge club who are customers of > your clued competitor didn't have to do a thing. Or tell her to run "Windows Update" and get the latest update for her existing OS which has the patch. > And then she has to do something *else* 9 months later when you need to > deploy IPv6 *anyhow*. Maybe, maybe not. It depends on how it is deployed. That "something else" might be as simple as "reboot the computer". > > I encourage my competitors to design their business plans that way. :) Considering v4 is likely to be around for another decade or two, getting Class E into general use seems easy enough to do. From drc at virtualized.org Thu Feb 17 10:39:08 2011 From: drc at virtualized.org (David Conrad) Date: Thu, 17 Feb 2011 08:39:08 -0800 Subject: [arin-announce] IN-ADDR.ARPA Zone Transfer Complete In-Reply-To: References: <4D5C3952.1080602@arin.net> <43EE6734-3F25-4905-BAC0-5BACA532C01B@virtualized.org> Message-ID: <084AE830-F552-4BD1-BB6D-7EB6BCF20FE6@virtualized.org> On Feb 17, 2011, at 8:03 AM, Joe Abley wrote: > At the end of this process every subdomain of ARPA will be fully DNSSEC-signed. Cool. > Query rates on the new servers (those operated by the RIRs and ICANN) are currently low, but are expected to increase as the IN-ADDR.ARPA zone is dropped from root servers. It'll be interesting to see what the corresponding drop in traffic in the root servers will be... Regards, -drc From jcurran at istaff.org Thu Feb 17 10:44:14 2011 From: jcurran at istaff.org (John Curran) Date: Thu, 17 Feb 2011 11:44:14 -0500 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <4D5D4CA3.50000@brightok.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> <38565.1297953177@localhost> <98FCFBF5-3E2F-4AC5-BFD3-1F61C7DBA025@istaff.org> <4D5D4CA3.50000@brightok.net> Message-ID: On Feb 17, 2011, at 11:28 AM, Jack Bates wrote: > On 2/17/2011 10:24 AM, Steven Bellovin wrote: >> It might be worth doing for ISP backbones, and for things like tunnel endpoints. >> For anything else, it's not worth the effort -- and I suspect never was. > > I think several people's point is that it may be useful for the CGN/LSN numbering and other special case scenarios where a CPE might be compliant and the windows box would be ignorant. Jack - There's numerous applications, including expanding internal applications such as virtualized servers for which the address space might be useful, if it was actually defined as usable as unicast. Apparently, it is also the case that the operator community wouldn't recognize the usage restrictions that might apply due to the recent reclassification, and would badly hurt themselves by making use of the space inappropriately. Thus, it is deemed better that nobody have use of the 1/16 of the IPv4 space (even if your internal use is perfectly compatible) because some who won't understand might get hurt... ;-) /John From gbonser at seven.com Thu Feb 17 10:48:16 2011 From: gbonser at seven.com (George Bonser) Date: Thu, 17 Feb 2011 08:48:16 -0800 Subject: Solar flare to reach earth In-Reply-To: <11752.1297960402@localhost> References: <624439.94303.qm@web59602.mail.ac4.yahoo.com> <11752.1297960402@localhost> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13BBA@RWC-EX1.corp.seven.com> > > Solar Activity Forecast: Solar activity is expected to be moderate with > a chance for an isolated major flare for the next three days (17-19 > February). > Region 1158 is expected to produce more M-class flares and still has > the potential for producing an M5 or greater x-ray event. There is a > chance for isolated M-class activity from Region 1161. 1158 is rotating away from facing directly to us so any flares at this point will not be aimed directly at Earth as the earlier M and X class flares were. Actually, I would be more worried if I earned my living in orbit or at high altitude. 1161 is rotating into an Earth-facing position but doesn't seem as active as 1158 was though that can change tomorrow. http://spaceweather.com/ From cb.list6 at gmail.com Thu Feb 17 11:01:34 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Thu, 17 Feb 2011 09:01:34 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> Message-ID: On Thu, Feb 17, 2011 at 5:08 AM, John Curran wrote: > On Feb 17, 2011, at 7:39 AM, Iljitsch van Beijnum wrote: > >> Not that it matters because it's too late now and it would only give us a few more months, but: >> >> Does the US government really need more than 150 million addresses, of which about half are not publically routed? Non-publically routed addresses can be reused by others as long as the stuff both users connect to doesn't overlap. > > Again, I note that we've collectively allocated the 95%+ of the address > space which was made available outside of DoD's original blocks, and then > considering that US DoD additionally returned 2 more /8's for the community > (noted here: ), > I believe they've shown significant consideration to the Internet community. > The fact that any particular prefix today isn't in your particular routing > table does not imply that global uniqueness isn't desired. > > Rather than saying 240/4 is unusable for another three years, perhaps the > service provider community could make plain that this space needs to be > made usable (ala http://tools.ietf.org/html/draft-fuller-240space-02 or > http://tools.ietf.org/html/draft-wilson-class-e-00, etc.) on a priority > basis and work with the operating system and vendor community actually > to make this happen? ?There's a chance that it could be made usable with > sufficient focus to make that happen, but it is assured not to be usable > if eternally delayed because it is "too hard" to accomplish. > +1 If you want to go on a wild goose chase, start chasing down 240/4 and you might make some progress. As i have mentioned before, it was only after i gave up on 240/4 for private network numbering that i really earnestly took on IPv6-only as a strategy. Seeing 240/4 actually work would be nice, but i have already concluded it does not fit my exhaustion timeline given how many edge devices will never support it. If i have to fork lift, it should be for ipv6. Cameron ======= http://groups.google.com/group/tmoipv6beta ======= > /John > > (my views alone; 100% recycled electrons used in this message) > > > From wnagele at ripe.net Thu Feb 17 11:15:19 2011 From: wnagele at ripe.net (Wolfgang Nagele) Date: Thu, 17 Feb 2011 18:15:19 +0100 Subject: [arin-announce] IN-ADDR.ARPA Zone Transfer Complete In-Reply-To: <084AE830-F552-4BD1-BB6D-7EB6BCF20FE6@virtualized.org> References: <4D5C3952.1080602@arin.net> <43EE6734-3F25-4905-BAC0-5BACA532C01B@virtualized.org> <084AE830-F552-4BD1-BB6D-7EB6BCF20FE6@virtualized.org> Message-ID: <4D5D57A7.7090106@ripe.net> Hi, > It'll be interesting to see what the corresponding drop in traffic in the root servers will be... We expect it to be around 2000qps (or ~8% of the total traffic) for k.root-servers.net. PTR query rates are very steady and do not follow the general diurnal cycle. Regards, Wolfgang From rs at seastrom.com Thu Feb 17 11:26:05 2011 From: rs at seastrom.com (Robert E. Seastrom) Date: Thu, 17 Feb 2011 12:26:05 -0500 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <20110217133136.85B40A47F14@drugs.dv.isc.org> (Mark Andrews's message of "Fri, 18 Feb 2011 00:31:36 +1100") References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> <20110217133136.85B40A47F14@drugs.dv.isc.org> Message-ID: <86d3mqpo7m.fsf@seastrom.com> Mark Andrews writes: > It's not usable as general purpose unicast. Both those drafts > attempt to do that. http://tools.ietf.org/html/draft-wilson-class-e-00 does not. Recommend you re-read. > It would be possible to use it as restricted purpose unicast, i.e. > to connect from a cpe border router to a 6rd and/or LSN with the > cpe border router signaling that it support the use of class E > addresses when it requests a address from upstream. > > The upsteam only returns a class E address when it is sure that the > network between the LSN/6rd supports class E traffic. The contemporary discussions we had on this subject centered around management infrastructure for MSOs, not 6rd (which was still a twinkle in the Bad Idea Fairy's eye at the time). Not speaking for Paul here, but it was not our intention to box in possible use of this space, only to mark it as sufficiently toxic that end users and normal enterprises would stay away. Would be great for 6rd if that's what folks wanted to use it for and could get the CPE vendors to cooperate. -r From gbonser at seven.com Thu Feb 17 11:46:46 2011 From: gbonser at seven.com (George Bonser) Date: Thu, 17 Feb 2011 09:46:46 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com><245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com><8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at><09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com><54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13BC1@RWC-EX1.corp.seven.com> > If you want to go on a wild goose chase, start chasing down 240/4 and > you might make some progress. > > As i have mentioned before, it was only after i gave up on 240/4 for > private network numbering that i really earnestly took on IPv6-only as > a strategy. Seeing 240/4 actually work would be nice, but i have > already concluded it does not fit my exhaustion timeline given how > many edge devices will never support it. > > If i have to fork lift, it should be for ipv6. 240/4 has been enabled in Linux since 2.6.25 (applied on January 21, 2008 by David Miller) so that's like three years already. From rs at seastrom.com Thu Feb 17 11:46:02 2011 From: rs at seastrom.com (Robert E. Seastrom) Date: Thu, 17 Feb 2011 12:46:02 -0500 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <8B0FDF52-A36D-46E8-9408-3C1A4C5D30CD@delong.com> (Owen DeLong's message of "Thu, 17 Feb 2011 06:20:30 -0800") References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <8B0FDF52-A36D-46E8-9408-3C1A4C5D30CD@delong.com> Message-ID: <868vxepnad.fsf@seastrom.com> Owen DeLong writes: > The DoD does not seem particularly anxious to announce or explain > their usage of those blocks to the rest of the community. > > They have much larger quantities of significantly more sophisticated > armaments than ARIN. > > I agree it would be nice if they would voluntarily return whatever > is appropriate to the community, but, You mean like they already did with 49/8, 50/8 (both formerly Joint Technical Command), 10/8 (formerly ARPAnet), and 7/8 (DNIC)? As the biggest returner of IPv4 space by a fair margin, notwithstanding their current holdings I think the DoD is quite justified in saying "I gave at the office" and hanging up. -r From cb.list6 at gmail.com Thu Feb 17 11:48:35 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Thu, 17 Feb 2011 09:48:35 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13BC1@RWC-EX1.corp.seven.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> <5A6D953473350C4B9995546AFE9939EE0BC13BC1@RWC-EX1.corp.seven.com> Message-ID: On Thu, Feb 17, 2011 at 9:46 AM, George Bonser wrote: >> If you want to go on a wild goose chase, start chasing down 240/4 and >> you might make some progress. >> >> As i have mentioned before, it was only after i gave up on 240/4 for >> private network numbering that i really earnestly took on IPv6-only as >> a strategy. ?Seeing 240/4 actually work would be nice, but i have >> already concluded it does not fit my exhaustion timeline given how >> many edge devices will never support it. >> >> If i have to fork lift, it should be for ipv6. > > 240/4 has been enabled in Linux since 2.6.25 (applied on January 21, > 2008 by David Miller) so that's like three years already. > Yep, and that's great. Let me know when a Cisco 7600 will route a packet like this. Cameron From jcurran at istaff.org Thu Feb 17 11:51:28 2011 From: jcurran at istaff.org (John Curran) Date: Thu, 17 Feb 2011 12:51:28 -0500 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> <5A6D953473350C4B9995546AFE9939EE0BC13BC1@RWC-EX1.corp.seven.com> Message-ID: <32ECC9CD-D927-4407-914C-751316C59966@istaff.org> On Feb 17, 2011, at 12:48 PM, Cameron Byrne wrote: >> 240/4 has been enabled in Linux since 2.6.25 (applied on January 21, >> 2008 by David Miller) so that's like three years already. > > Yep, and that's great. Let me know when a Cisco 7600 will route a > packet like this. So, it won't work for you. Is there any reason that it shouldn't be defined as unicast or private use (with warnings) rather than "Future Use", so that those who might have a use for it can do so? /John From gbonser at seven.com Thu Feb 17 11:52:32 2011 From: gbonser at seven.com (George Bonser) Date: Thu, 17 Feb 2011 09:52:32 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com><245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com><8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us><4D5415C6.80700@matthew.at><09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com><54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org><5A6D953473350C4B9995546AFE9939EE0BC13BC1@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13BC3@RWC-EX1.corp.seven.com> > > > > 240/4 has been enabled in Linux since 2.6.25 (applied on January 21, > > 2008 by David Miller) so that's like three years already. > > > > Yep, and that's great. Let me know when a Cisco 7600 will route a > packet like this. > > Cameron Considering how small of a change it is, simply removing that net from the "black list", they could do it at any time with a code update to any version of IOS, provided that black list isn't burned into hardware. George From cb.list6 at gmail.com Thu Feb 17 11:54:49 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Thu, 17 Feb 2011 09:54:49 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <32ECC9CD-D927-4407-914C-751316C59966@istaff.org> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> <5A6D953473350C4B9995546AFE9939EE0BC13BC1@RWC-EX1.corp.seven.com> <32ECC9CD-D927-4407-914C-751316C59966@istaff.org> Message-ID: On Thu, Feb 17, 2011 at 9:51 AM, John Curran wrote: > On Feb 17, 2011, at 12:48 PM, Cameron Byrne wrote: > >>> 240/4 has been enabled in Linux since 2.6.25 (applied on January 21, >>> 2008 by David Miller) so that's like three years already. >> >> Yep, and that's great. ?Let me know when a Cisco 7600 will route a >> packet like this. > > So, it won't work for you. ?Is there any reason that it shouldn't > be defined as unicast or private use (with warnings) rather than > "Future Use", so that those who might have a use for it can do so? > I am 100% pro making Class E defined as private unicast space. My only point is that people need to be realistic about the near term benefit. Yes, some linux may work. But, Microsoft and Cisco don't work today. Let's move it to not-reserved, but don't bet the farm on 240/4 solving any of your problems or in any way changing the need to for IPv6 migration. This is where the slipperly slope and expectation settings start. Cameron From jcurran at arin.net Thu Feb 17 11:57:32 2011 From: jcurran at arin.net (John Curran) Date: Thu, 17 Feb 2011 17:57:32 +0000 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <868vxepnad.fsf@seastrom.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <8B0FDF52-A36D-46E8-9408-3C1A4C5D30CD@delong.com> <868vxepnad.fsf@seastrom.com> Message-ID: On Feb 17, 2011, at 12:46 PM, Robert E. Seastrom wrote: > Owen DeLong writes: >> ... >> I agree it would be nice if they would voluntarily return whatever >> is appropriate to the community, but, > > You mean like they already did with 49/8, 50/8 (both formerly Joint > Technical Command), 10/8 (formerly ARPAnet), and 7/8 (DNIC)? > > As the biggest returner of IPv4 space by a fair margin, > notwithstanding their current holdings I think the DoD is quite > justified in saying "I gave at the office" and hanging up. Actually, as I have noted before, the US DoD has contractually agreed to return to ARIN unneeded IPv4 address space if/when such becomes available, so that it may be used by the Internet community. /John John Curran President and CEO ARIN From gbonser at seven.com Thu Feb 17 12:00:26 2011 From: gbonser at seven.com (George Bonser) Date: Thu, 17 Feb 2011 10:00:26 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com><245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com><8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us><4D5415C6.80700@matthew.at><09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com><54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org><5A6D953473350C4B9995546AFE9939EE0BC13BC1@RWC-EX1.corp.seven.com><32ECC9CD-D927-4407-914C-751316C59966@istaff.org> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13BC4@RWC-EX1.corp.seven.com> > > > > I am 100% pro making Class E defined as private unicast space. > > My only point is that people need to be realistic about the near term > benefit. Yes, some linux may work. But, Microsoft and Cisco don't > work today. Let's move it to not-reserved, but don't bet the farm on > 240/4 solving any of your problems or in any way changing the need to > for IPv6 migration. This is where the slipperly slope and expectation > settings start. > > Cameron Considering the amount of linux-based CPE and other network hardware out there (including some Cisco gear), the extent to which it might be usable today could be surprising. From cb.list6 at gmail.com Thu Feb 17 12:05:53 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Thu, 17 Feb 2011 10:05:53 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13BC3@RWC-EX1.corp.seven.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> <5A6D953473350C4B9995546AFE9939EE0BC13BC1@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC13BC3@RWC-EX1.corp.seven.com> Message-ID: On Thu, Feb 17, 2011 at 9:52 AM, George Bonser wrote: >> > >> > 240/4 has been enabled in Linux since 2.6.25 (applied on January 21, >> > 2008 by David Miller) so that's like three years already. >> > >> >> Yep, and that's great. ?Let me know when a Cisco 7600 will route a >> packet like this. >> >> Cameron > > Considering how small of a change it is, simply removing that net from > the "black list", they could do it at any time with a code update to any > version of IOS, provided that black list isn't burned into hardware. > I asked 2 years ago, and i was told it was not feasible. I escalated, still no-go, it was a "deep" problem. And they pointed to the IETF saying no on the above drafts as reason to not dig into the microcode or whatever to fix it. This is where i turned to the IPv6-only reality of the future near-term internet. I suggest you do the same. Cisco is just one example. The fact is it will likely not work in cell phones, home gateways, windows PCs, Mac's, .... I understand some progress has been made... but choose your scope wisely and pick your battles and know that the weight of the world is against you (cisco and msft) Let me remind you, i believe opening 240/4 for private unicast was a good ideas years ago. It is still not a bad idea, what's the harm? But ... the answer you will hear is that IPv6 has momentum, go with the flow. Using 240/4 is much better than providing a public allocation to private networks. It properly makes folks consider the reality of staying with broken ipv4 or making the much better long term investment in IPv6. @George Please don't speculating on when Cisco or Microsoft will support 240/4 on this list. Ask your account rep, then report back with facts. Arm-chair engineering accounts for too many emails on this list. Cameron ===== http://groups.google.com/group/tmoipv6beta ===== From jeffrey.lyon at blacklotus.net Thu Feb 17 12:31:31 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 17 Feb 2011 13:31:31 -0500 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> <5A6D953473350C4B9995546AFE9939EE0BC13BC1@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC13BC3@RWC-EX1.corp.seven.com> Message-ID: On Thu, Feb 17, 2011 at 1:05 PM, Cameron Byrne wrote: > On Thu, Feb 17, 2011 at 9:52 AM, George Bonser wrote: >>> > >>> > 240/4 has been enabled in Linux since 2.6.25 (applied on January 21, >>> > 2008 by David Miller) so that's like three years already. >>> > >>> >>> Yep, and that's great. ?Let me know when a Cisco 7600 will route a >>> packet like this. >>> >>> Cameron >> >> Considering how small of a change it is, simply removing that net from >> the "black list", they could do it at any time with a code update to any >> version of IOS, provided that black list isn't burned into hardware. >> > > I asked 2 years ago, and i was told it was not feasible. ?I escalated, > still no-go, it was a "deep" problem. ?And they pointed to the IETF > saying no on the above drafts as reason to not dig into the microcode > or whatever to fix it. > > This is where i turned to the IPv6-only reality of the future > near-term internet. ?I suggest you do the same. > > Cisco is just one example. ?The fact is it will likely not work in > cell phones, home gateways, windows PCs, Mac's, .... ?I understand > some progress has been made... but choose your scope wisely and pick > your battles and know that the weight of the world is against you > (cisco and msft) > > Let me remind you, i believe opening 240/4 for private unicast was a > good ideas years ago. ?It is still not a bad idea, what's the harm? > But ... the answer you will hear is that IPv6 has momentum, go with > the flow. > > Using 240/4 is much better than providing a public allocation to > private networks. ?It properly makes folks consider the reality of > staying with broken ipv4 or making the much better long term > investment in IPv6. > > @George > > Please don't speculating on when Cisco or Microsoft will support 240/4 > on this list. ?Ask your account rep, then report back with facts. > Arm-chair engineering accounts for too many emails on this list. > > Cameron > ===== > http://groups.google.com/group/tmoipv6beta > ===== > > IPv6's momentum is a lot like a beach landing at Normandy. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From gbonser at seven.com Thu Feb 17 12:35:33 2011 From: gbonser at seven.com (George Bonser) Date: Thu, 17 Feb 2011 10:35:33 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com><245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com><8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us><4D5415C6.80700@matthew.at><09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com><54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org><5A6D953473350C4B9995546AFE9939EE0BC13BC1@RWC-EX1.corp.seven.com><5A6D953473350C4B9995546AFE9939EE0BC13BC3@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13BC9@RWC-EX1.corp.seven.com> > I asked 2 years ago, and i was told it was not feasible. I escalated, > still no-go, it was a "deep" problem. And they pointed to the IETF > saying no on the above drafts as reason to not dig into the microcode > or whatever to fix it. Ok, so that implies that it is burned into hardware and as it is ASIC-based hardware and not FPGA, they can't reprogram the hardware with a code update (one of the advantages of FPGA-based hardware). > Cisco is just one example. The fact is it will likely not work in > cell phones, home gateways, windows PCs, Mac's, .... I understand > some progress has been made... but choose your scope wisely and pick > your battles and know that the weight of the world is against you > (cisco and msft) > I don't think I had general usage in mind, more along the lines of the "middle 4" in NAT444 that will be rolled out in many networks to conserve IP space. > @George > > Please don't speculating on when Cisco or Microsoft will support 240/4 > on this list. Ask your account rep, then report back with facts. > Arm-chair engineering accounts for too many emails on this list. The usage I have in mind would be transparent to the end stations and, frankly, someone who produces provider gear and CPE that can take advantage of that space is going to have a great selling point. There is some gold under there for someone. 240/4 is a great big "dig here" sign if they want some of it. From davei at otd.com Thu Feb 17 12:36:49 2011 From: davei at otd.com (David Israel) Date: Thu, 17 Feb 2011 13:36:49 -0500 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> <5A6D953473350C4B9995546AFE9939EE0BC13BC1@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC13BC3@RWC-EX1.corp.seven.com> Message-ID: <4D5D6AC1.50203@otd.com> On 2/17/2011 1:31 PM, Jeffrey Lyon wrote: > IPv6's momentum is a lot like a beach landing at Normandy. > As in, "large, dedicated, and nigh unstoppable, but fraught with peril and with a lot of mess and destruction to get through before it is done," or as in "mainly opposed by aging crazy Nazis who should have seen it coming but kept their attention in the wrong place?" From owen at delong.com Thu Feb 17 12:44:54 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 17 Feb 2011 10:44:54 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13BB8@RWC-EX1.corp.seven.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com><245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com><8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at><09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com><54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> <38565.1297953177@localhost> <5A6D953473350C4B9995546AFE9939EE0BC13BB8@RWC-EX1.corp.seven.com> Message-ID: <89DE695D-BB64-4EE5-94AB-D7EBEF733412@delong.com> On Feb 17, 2011, at 8:35 AM, George Bonser wrote: >> >> In other words, you're going to tell Granny she needs to upgrade to >> Windows 8 and/or replace her CPE because you couldn't get your act >> together and deploy >> IPv6 - even though her friends at the bridge club who are customers of >> your clued competitor didn't have to do a thing. > > Or tell her to run "Windows Update" and get the latest update for her > existing OS which has the patch. > Because that certainly solved the DNS resolver over IPv6 problems for all the WinXP users out there. > >> And then she has to do something *else* 9 months later when you need > to >> deploy IPv6 *anyhow*. > > Maybe, maybe not. It depends on how it is deployed. That "something > else" might be as simple as "reboot the computer". > Unlikely unless she has IPv6 compliant CPE. >> >> I encourage my competitors to design their business plans that way. :) > > Considering v4 is likely to be around for another decade or two, getting > Class E into general use seems easy enough to do. > > I'd much rather see the resources required go into improving IPv6 support and deployment. Owen From owen at delong.com Thu Feb 17 13:05:54 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 17 Feb 2011 11:05:54 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <8B0FDF52-A36D-46E8-9408-3C1A4C5D30CD@delong.com> <868vxepnad.fsf@seastrom.com> Message-ID: On Feb 17, 2011, at 9:57 AM, John Curran wrote: > On Feb 17, 2011, at 12:46 PM, Robert E. Seastrom wrote: > >> Owen DeLong writes: >>> ... >>> I agree it would be nice if they would voluntarily return whatever >>> is appropriate to the community, but, >> >> You mean like they already did with 49/8, 50/8 (both formerly Joint >> Technical Command), 10/8 (formerly ARPAnet), and 7/8 (DNIC)? >> >> As the biggest returner of IPv4 space by a fair margin, >> notwithstanding their current holdings I think the DoD is quite >> justified in saying "I gave at the office" and hanging up. > As they are also the biggest consumer of IPv4 space by a fair margin, that statement rings a bit hollow. > Actually, as I have noted before, the US DoD has contractually > agreed to return to ARIN unneeded IPv4 address space if/when > such becomes available, so that it may be used by the Internet > community. > This statement, on the other hand, is a good thing. Owen From owen at delong.com Thu Feb 17 13:14:43 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 17 Feb 2011 11:14:43 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> <5A6D953473350C4B9995546AFE9939EE0BC13BC1@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC13BC3@RWC-EX1.corp.seven.com> Message-ID: <9F437DBF-7974-4294-9306-2CFAF37729D8@delong.com> > > IPv6's momentum is a lot like a beach landing at Normandy. ?? Inevitably going to succeed, but, not without heavy losses in the process? Owen From owen at delong.com Thu Feb 17 13:16:40 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 17 Feb 2011 11:16:40 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13BC9@RWC-EX1.corp.seven.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com><245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com><8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us><4D5415C6.80700@matthew.at><09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com><54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org><5A6D953473350C4B9995546AFE9939EE0BC13BC1@RWC-EX1.corp.seven.com><5A6D953473350C4B9995546AFE9939EE0BC13BC3@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE! 0BC13BC9@RWC-EX1.corp.seven.com> Message-ID: <5F90644C-5457-460F-9BC3-70802B13A270@delong.com> > >> Cisco is just one example. The fact is it will likely not work in >> cell phones, home gateways, windows PCs, Mac's, .... I understand >> some progress has been made... but choose your scope wisely and pick >> your battles and know that the weight of the world is against you >> (cisco and msft) >> > > I don't think I had general usage in mind, more along the lines of the > "middle 4" in NAT444 that will be rolled out in many networks to > conserve IP space. > Infeasible. NAT444 is primarily needed to avoid doing a CPE forklift for nearly every subscriber. To deploy these addresses in that space would require a CPE forklift for nearly every subscriber. >> @George >> >> Please don't speculating on when Cisco or Microsoft will support 240/4 >> on this list. Ask your account rep, then report back with facts. >> Arm-chair engineering accounts for too many emails on this list. > > The usage I have in mind would be transparent to the end stations and, > frankly, someone who produces provider gear and CPE that can take > advantage of that space is going to have a great selling point. There > is some gold under there for someone. 240/4 is a great big "dig here" > sign if they want some of it. > > Maybe, but, CPE is rarely a unified solution, even within the same carrier. Owen From jeffrey.lyon at blacklotus.net Thu Feb 17 13:25:18 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 17 Feb 2011 14:25:18 -0500 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <9F437DBF-7974-4294-9306-2CFAF37729D8@delong.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> <5A6D953473350C4B9995546AFE9939EE0BC13BC1@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC13BC3@RWC-EX1.corp.seven.com> <9F437DBF-7974-4294-9306-2CFAF37729D8@delong.com> Message-ID: On Thu, Feb 17, 2011 at 2:14 PM, Owen DeLong wrote: >> >> IPv6's momentum is a lot like a beach landing at Normandy. > > ?? > Inevitably going to succeed, but, not without heavy losses in the process? > > Owen > > Yes, and also with mass fear and confusion at the beginning. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From jbates at brightok.net Thu Feb 17 13:48:49 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 17 Feb 2011 13:48:49 -0600 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> <5A6D953473350C4B9995546AFE9939EE0BC13BC1@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC13BC3@RWC-EX1.corp.seven.com> <9F437DBF-7974-4294-9306-2CFAF37729D8@delong.com> Message-ID: <4D5D7BA1.9090908@brightok.net> On 2/17/2011 1:25 PM, Jeffrey Lyon wrote: > On Thu, Feb 17, 2011 at 2:14 PM, Owen DeLong wrote: >>> >>> IPv6's momentum is a lot like a beach landing at Normandy. >> >> ?? >> Inevitably going to succeed, but, not without heavy losses in the process? >> >> Owen >> >> > > Yes, and also with mass fear and confusion at the beginning. > Given the heavy losses and chaotic nature of the event, wasn't mass fear and confusion to be expected? Jack From jeffrey.lyon at blacklotus.net Thu Feb 17 14:08:17 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 17 Feb 2011 15:08:17 -0500 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <4D5D7BA1.9090908@brightok.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> <5A6D953473350C4B9995546AFE9939EE0BC13BC1@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC13BC3@RWC-EX1.corp.seven.com> <9F437DBF-7974-4294-9306-2CFAF37729D8@delong.com> <4D5D7BA1.9090908@brightok.net> Message-ID: On Thu, Feb 17, 2011 at 2:48 PM, Jack Bates wrote: > > > On 2/17/2011 1:25 PM, Jeffrey Lyon wrote: >> >> On Thu, Feb 17, 2011 at 2:14 PM, Owen DeLong ?wrote: >>>> >>>> IPv6's momentum is a lot like a beach landing at Normandy. >>> >>> ?? >>> Inevitably going to succeed, but, not without heavy losses in the >>> process? >>> >>> Owen >>> >>> >> >> Yes, and also with mass fear and confusion at the beginning. >> > > Given the heavy losses and chaotic nature of the event, wasn't mass fear and > confusion to be expected? > > > Jack > At Normandy or on 2/3/11? -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From marka at isc.org Thu Feb 17 14:30:20 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 18 Feb 2011 07:30:20 +1100 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: Your message of "Thu, 17 Feb 2011 09:01:34 -0800." References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> Message-ID: <20110217203020.7E40EA488B2@drugs.dv.isc.org> In message , Came ron Byrne writes: > On Thu, Feb 17, 2011 at 5:08 AM, John Curran wrote: > > On Feb 17, 2011, at 7:39 AM, Iljitsch van Beijnum wrote: > > > >> Not that it matters because it's too late now and it would only give us = > a few more months, but: > >> > >> Does the US government really need more than 150 million addresses, of w= > hich about half are not publically routed? Non-publically routed addresses = > can be reused by others as long as the stuff both users connect to doesn't = > overlap. > > > > Again, I note that we've collectively allocated the 95%+ of the address > > space which was made available outside of DoD's original blocks, and then > > considering that US DoD additionally returned 2 more /8's for the communi= > ty > > (noted here: />), > > I believe they've shown significant consideration to the Internet communi= > ty. > > The fact that any particular prefix today isn't in your particular routin= > g > > table does not imply that global uniqueness isn't desired. > > > > Rather than saying 240/4 is unusable for another three years, perhaps the > > service provider community could make plain that this space needs to be > > made usable (ala http://tools.ietf.org/html/draft-fuller-240space-02 or > > http://tools.ietf.org/html/draft-wilson-class-e-00, etc.) on a priority > > basis and work with the operating system and vendor community actually > > to make this happen? =A0There's a chance that it could be made usable wit= > h > > sufficient focus to make that happen, but it is assured not to be usable > > if eternally delayed because it is "too hard" to accomplish. > > > > +1 > > If you want to go on a wild goose chase, start chasing down 240/4 and > you might make some progress. > > As i have mentioned before, it was only after i gave up on 240/4 for > private network numbering that i really earnestly took on IPv6-only as > a strategy. Seeing 240/4 actually work would be nice, but i have > already concluded it does not fit my exhaustion timeline given how > many edge devices will never support it. > > If i have to fork lift, it should be for ipv6. You can reflash CPE devices to support this that you can't reflash to support IPv6 as there is no space in the flash for the extra code. This should be minimal. A extra PPP/DHCP option and a check box to enable (default) / disable setting it. It can be deployed incrementally. It enables IPv6 to be deployed over intermediate hardware that doesn't support IPv4. You still need lots of IPv4 to do that. It doesn't however have to be globally unique and it shouldn't be RFC 1918. Leave RFC 1918 for customers. You add IPv6 support to CPE devices where you can. It doesn't require the world to upgrade. It gives a well defined range that you don't use with 6to4. We also don't need all of class E. The first half would be more than enough for even the biggest ISP. It's big enough to give customers stable IPv6 addresses via 6rd. Mark > Cameron > =3D=3D=3D=3D=3D=3D=3D > http://groups.google.com/group/tmoipv6beta > =3D=3D=3D=3D=3D=3D=3D > > > /John > > > > (my views alone; 100% recycled electrons used in this message) > > > > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Thu Feb 17 14:34:23 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 18 Feb 2011 07:34:23 +1100 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: Your message of "Thu, 17 Feb 2011 12:51:28 CDT." <32ECC9CD-D927-4407-914C-751316C59966@istaff.org> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> <5A6D953473350C4B9995546AFE9939EE0BC13BC1@RWC-EX1.corp.seven.com> <32ECC9CD-D927-4407-914C-751316C59966@istaff.org> Message-ID: <20110217203423.11DB5A4898E@drugs.dv.isc.org> In message <32ECC9CD-D927-4407-914C-751316C59966 at istaff.org>, John Curran write s: > On Feb 17, 2011, at 12:48 PM, Cameron Byrne wrote: > > >> 240/4 has been enabled in Linux since 2.6.25 (applied on January 21, > >> 2008 by David Miller) so that's like three years already. > > > > Yep, and that's great. Let me know when a Cisco 7600 will route a > > packet like this. > > So, it won't work for you. Is there any reason that it shouldn't > be defined as unicast or private use (with warnings) rather than > "Future Use", so that those who might have a use for it can do so? > > /John Or to ask CISCO to fix the box so it can route it? In many cases it is a minimal change. I don't know whether it is in Cisco 7600 but it can't hurt to ask the vendors if it is technically possible. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From smeuse at mara.org Thu Feb 17 14:36:39 2011 From: smeuse at mara.org (Steve Meuse) Date: Thu, 17 Feb 2011 15:36:39 -0500 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13BC4@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13BC4@RWC-EX1.corp.seven.com> Message-ID: <20110217203639.GA3702@mara.org> George Bonser expunged (gbonser at seven.com): > Considering the amount of linux-based CPE and other network hardware out > there (including some Cisco gear), the extent to which it might be > usable today could be surprising. An how many of those embedded linux devices are running a 2.4 kernel? Just look at xx-wrt as an example. If you have a certain chipset, 2.4 is your only option. -Steve From smeuse at mara.org Thu Feb 17 14:39:22 2011 From: smeuse at mara.org (Steve Meuse) Date: Thu, 17 Feb 2011 15:39:22 -0500 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <20110217203423.11DB5A4898E@drugs.dv.isc.org> References: <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> <5A6D953473350C4B9995546AFE9939EE0BC13BC1@RWC-EX1.corp.seven.com> <32ECC9CD-D927-4407-914C-751316C59966@istaff.org> <20110217203423.11DB5A4898E@drugs.dv.isc.org> Message-ID: <20110217203922.GB3702@mara.org> Mark Andrews expunged (marka at isc.org): > Or to ask CISCO to fix the box so it can route it? In many cases > it is a minimal change. I don't know whether it is in Cisco 7600 They are in the business of selling new gear, not enabling features on EOL equipment :) -Steve From owen at delong.com Thu Feb 17 14:59:54 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 17 Feb 2011 12:59:54 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <20110217203020.7E40EA488B2@drugs.dv.isc.org> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> <20110217203020.7E40EA488B2@drugs.dv.isc.org> Message-ID: <1DBDCA5F-16EC-428D-BC46-3BD59A6F4CDB@delong.com> > > You can reflash CPE devices to support this that you can't reflash > to support IPv6 as there is no space in the flash for the extra > code. This should be minimal. A extra PPP/DHCP option and a check > box to enable (default) / disable setting it. > Reflashing most CPE amounts to forklifting. The difference between having them bring their CPE in to be reflashed or rolling a truck to do same vs. replacing the CPE will, in most cases, actually render replacing the CPE cheaper. > It can be deployed incrementally. > So can replacing the CPE, but, neither is a particularly attractive alternative for many providers. Owen From lowen at pari.edu Thu Feb 17 15:15:40 2011 From: lowen at pari.edu (Lamar Owen) Date: Thu, 17 Feb 2011 16:15:40 -0500 Subject: ISDN BRI In-Reply-To: <8220928.34.1297956612558.JavaMail.root@benjamin.baylink.com> References: <8220928.34.1297956612558.JavaMail.root@benjamin.baylink.com> Message-ID: <201102171615.40878.lowen@pari.edu> On Thursday, February 17, 2011 10:30:12 am Jay Ashworth wrote: > Off hand, I wouldn't expect a carrier to do any special engineering on > a BRI -- can you even *order* a BRI these days? :-) Seems to still be in NECA Tariff5, at least the last copy I looked at. So the rurals still are tariffed for it. From lowen at pari.edu Thu Feb 17 15:20:42 2011 From: lowen at pari.edu (Lamar Owen) Date: Thu, 17 Feb 2011 16:20:42 -0500 Subject: ISDN BRI In-Reply-To: References: Message-ID: <201102171620.43159.lowen@pari.edu> On Thursday, February 17, 2011 10:21:18 am Santino Codispoti wrote: > Is it possible to order a ISDN BRI line from the LEC and have them > look at the design of a DS1 and have them if possible design the ISDN > BRI lineon a devurse path or at lest different equipment within the > CO? As I understand the question, you want the BRI to be path diverse to the DS1's path, correct? It would depend upon how well you know the tech folk at the telco, and whether there is existing or planned transport in multiple directions from your site. Even if you order bona fide protected circuits, you're not likely to be guaranteed physical path diversity. Having said that, lots of telcos will work with you if you know the people to work with, and some will quote you a term agreement for the physical plant provisioning as an additional cost, and probably for three to five years terms. From andyr at merit.edu Thu Feb 17 15:35:38 2011 From: andyr at merit.edu (Andy Rosenzweig) Date: Thu, 17 Feb 2011 16:35:38 -0500 Subject: Information about upcoming transition of mailing list ownership Message-ID: <4D5D94AA.3060003@merit.edu> Dear nanog at nanog.org subscriber: This message is to let you know about an upcoming change in the ownership of this mailing list. As you may know, the ownership and management of NANOG has been been transferred from Merit Network to NewNOG, Inc., a non-profit led by members of the NANOG community (http://www.newnog.org). You can read more details of this change at http://nanog.org/governance/transition. As of Friday, February 25, this mailing list will be transferred to NewNOG's management. Because you are a current member of this list, your email address will be transferred from Merit to NewNOG. If you prefer that your address not be transferred, you may unsubscribe from the list before Friday, February 25, 2011. Instructions are available at: http://mailman.nanog.org/mailman/listinfo/nanog It has been a privilege for Merit to serve the NANOG community since the formation of the group in 1994. We hope that you will choose to continue as a subscriber to this list under NewNOG's stewardship. Sincerely, Andy Rosenzweig Merit Network, Inc. From mikeal.clark at gmail.com Thu Feb 17 15:37:55 2011 From: mikeal.clark at gmail.com (Mikeal Clark) Date: Thu, 17 Feb 2011 15:37:55 -0600 Subject: AT&T MPLS / BIB Routers In-Reply-To: References: <4D5C593E.9060808@freedesktop.org> <6EFFEFBAC68377459A2E972105C759EC03645A08@EXVBE005-2.exch005intermedia.net> Message-ID: AT&T and Edgemarc now believe they might have shipped routers with firmware that is causing the issues. We will upgrade the firmware on Tuesday and see if that is the case. Thanks everyone for the input. On Thu, Feb 17, 2011 at 9:04 AM, Mikeal Clark wrote: > The routers are Edgemarc. P/N EM-4608T4 > > http://www.edgewaternetworks.com/edgemarc_overview_page.htm > > > On Thu, Feb 17, 2011 at 8:19 AM, Ryan Finnesey < > ryan.finnesey at harrierinvestments.com> wrote: > >> What type of hardware are they using for this BIB router? >> >> Cheers >> Ryan >> >> >> -----Original Message----- >> From: Mikeal Clark [mailto:mikeal.clark at gmail.com] >> Sent: Wednesday, February 16, 2011 6:16 PM >> To: Jim Gettys >> Cc: nanog at nanog.org >> Subject: Re: AT&T MPLS / BIB Routers >> >> I'm building up to 3000-4000ms latency with these BIB routers. We never >> had this issue on the old point to points using Cisco gear. >> >> On Wed, Feb 16, 2011 at 5:09 PM, Jim Gettys wrote: >> >> > On 02/16/2011 05:44 PM, Mikeal Clark wrote: >> > >> >> We just put in a AT&T MPLS and are having a pretty negative >> >> experience with the "Business in a Box" routers they are using for >> >> our smaller sites. We are seeing extremely high latency under load. >> >> >> Anyone have any experience with these devices that could shed some >> >> light on this? Are they really this bad? >> >> >> >> >> > There is excessive buffering in all sorts of devices all over the >> Internet. >> > This causes high latency under load (along with higher packet losses, >> > and lots of other problems. >> > >> > It's what I've been blogging about on http://gettys.wordpress.com. >> > These buffers fill; and they are so large they have defeated TCP >> > congestion avoidance to boot, with horrifying consequences. >> > >> > So far, I've found this problem (almost) everywhere I've looked: >> > o ICSI has good data that bufferbloat is endemic in DSL, Cable, >> >> > and FIOS. Delays are often measured in seconds (rather than >> milliseconds). >> > o some corporate and ISP networks run without AQM, in >> > circumstances that they should. >> > o Windows, Mac OSX and Linux all have bufferbloat in their >> > network stacks, at a minimum on recent network device drivers, and >> often elsewhere. >> > o Every home router I've tested is horrifyingly bad. >> > o 3g networks & 802.11 have this in spades. >> > >> > Why should AT&T's MPLS be any different? >> > >> > My next topic will be "transient" bufferbloat, having to do with >> > defeating slowstart. >> > >> > Come start helping fix this: please join us at bufferbloat.net, as we >> > try to get people to fix it. Already there are some experimental >> > patches for the Linux Intel wireless driver. >> > Jim Gettys >> > Bell Labs >> > >> > >> > > From andyr at merit.edu Thu Feb 17 15:41:03 2011 From: andyr at merit.edu (Andy Rosenzweig) Date: Thu, 17 Feb 2011 16:41:03 -0500 Subject: [NANOG-announce] Information about upcoming transition of NANOG-Announce list ownership Message-ID: <4D5D95EF.3070708@merit.edu> Dear nanog-announce at nanog.org subscriber: This message is to let you know about an upcoming change in the ownership of this mailing list. As you may know, the ownership and management of NANOG has been been transferred from Merit Network to NewNOG, Inc., a non-profit led by members of the NANOG community (http://www.newnog.org). You can read more details of this change at http://nanog.org/governance/transition. As of Friday, February 25, this mailing list will be transferred to NewNOG's management. Because you are a current member of this list, your email address will be transferred from Merit to NewNOG. If you prefer that your address not be transferred, you may unsubscribe from the list before Friday, February 25, 2011. Instructions are available at: http://mailman.nanog.org/mailman/listinfo/nanog-announce It has been a privilege for Merit to serve the NANOG community since the formation of the group in 1994. We hope that you will choose to continue as a subscriber to this list under NewNOG's stewardship. Sincerely, Andy Rosenzweig Merit Network, Inc. _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From jason at lixfeld.ca Thu Feb 17 17:00:21 2011 From: jason at lixfeld.ca (Jason Lixfeld) Date: Thu, 17 Feb 2011 18:00:21 -0500 Subject: SFP vs. SFP+ Message-ID: <36F57F0C-B78A-46AC-AAC4-E5FF902DD032@lixfeld.ca> I was asked today what the difference between SFP and SFP+ is. I did really know, so I looked it up and it seems that the SFP spec provides capabilities for data rates up to 4.25Gb/s, whereas SFP+ supports up to 10Gb/s. Naturally, this made me wonder whether or not an optic that supported 10GbE always conformed to the SFP+ standard inherently, or if there are cases where a 10GbE optic might only support the SFP standard, thus having a 4.25Gb/s bottleneck. From Sam at networkhardware.com Thu Feb 17 17:25:13 2011 From: Sam at networkhardware.com (Sam Chesluk) Date: Thu, 17 Feb 2011 15:25:13 -0800 Subject: SFP vs. SFP+ In-Reply-To: <36F57F0C-B78A-46AC-AAC4-E5FF902DD032@lixfeld.ca> References: <36F57F0C-B78A-46AC-AAC4-E5FF902DD032@lixfeld.ca> Message-ID: <5D2B264604643843B933666791F5D52F0A8EC6FF@nhrglma1.networkhardware.local> Jason - there are no SFP-10G parts based off of the original SFP; they all are based on the SFP+ standard, so there will be no issues with the optic not being able to work at the full 10Gbps it's rated for. Sam Chesluk Network Hardware Resale -----Original Message----- From: Jason Lixfeld [mailto:jason at lixfeld.ca] Sent: Thursday, February 17, 2011 3:00 PM To: nanog at nanog.org Subject: SFP vs. SFP+ I was asked today what the difference between SFP and SFP+ is. I did really know, so I looked it up and it seems that the SFP spec provides capabilities for data rates up to 4.25Gb/s, whereas SFP+ supports up to 10Gb/s. Naturally, this made me wonder whether or not an optic that supported 10GbE always conformed to the SFP+ standard inherently, or if there are cases where a 10GbE optic might only support the SFP standard, thus having a 4.25Gb/s bottleneck. From jimmy.changa007 at gmail.com Thu Feb 17 17:38:39 2011 From: jimmy.changa007 at gmail.com (Jimmy Changa) Date: Thu, 17 Feb 2011 18:38:39 -0500 Subject: SFP vs. SFP+ In-Reply-To: <5D2B264604643843B933666791F5D52F0A8EC6FF@nhrglma1.networkhardware.local> References: <36F57F0C-B78A-46AC-AAC4-E5FF902DD032@lixfeld.ca> <5D2B264604643843B933666791F5D52F0A8EC6FF@nhrglma1.networkhardware.local> Message-ID: I'm curious also. Could you use a SFP in a ten gig port if you only need 4gb of throughput? Sent from my iPhone On Feb 17, 2011, at 6:25 PM, "Sam Chesluk" wrote: > Jason - there are no SFP-10G parts based off of the original SFP; they > all are based on the SFP+ standard, so there will be no issues with the > optic not being able to work at the full 10Gbps it's rated for. > > Sam Chesluk > Network Hardware Resale > > > -----Original Message----- > From: Jason Lixfeld [mailto:jason at lixfeld.ca] > Sent: Thursday, February 17, 2011 3:00 PM > To: nanog at nanog.org > Subject: SFP vs. SFP+ > > I was asked today what the difference between SFP and SFP+ is. I did > really know, so I looked it up and it seems that the SFP spec provides > capabilities for data rates up to 4.25Gb/s, whereas SFP+ supports up to > 10Gb/s. Naturally, this made me wonder whether or not an optic that > supported 10GbE always conformed to the SFP+ standard inherently, or if > there are cases where a 10GbE optic might only support the SFP standard, > thus having a 4.25Gb/s bottleneck. > From Sam at networkhardware.com Thu Feb 17 17:41:28 2011 From: Sam at networkhardware.com (Sam Chesluk) Date: Thu, 17 Feb 2011 15:41:28 -0800 Subject: SFP vs. SFP+ In-Reply-To: References: <36F57F0C-B78A-46AC-AAC4-E5FF902DD032@lixfeld.ca> <5D2B264604643843B933666791F5D52F0A8EC6FF@nhrglma1.networkhardware.local> Message-ID: <5D2B264604643843B933666791F5D52F0A8EC74F@nhrglma1.networkhardware.local> Depends on the switch. Some, like the 2960S and 4948E, have 1G/10G ports. They will, however, not operate at 4Gbps (that particular speed was chosen to allow the core components to work for gigabit Ethernet, OC48, 2G FC, and 4G FC). Sam Chesluk Network Hardware Resale -----Original Message----- From: Jimmy Changa [mailto:jimmy.changa007 at gmail.com] Sent: Thursday, February 17, 2011 3:39 PM To: Sam Chesluk Cc: Jason Lixfeld; Subject: Re: SFP vs. SFP+ I'm curious also. Could you use a SFP in a ten gig port if you only need 4gb of throughput? Sent from my iPhone On Feb 17, 2011, at 6:25 PM, "Sam Chesluk" wrote: > Jason - there are no SFP-10G parts based off of the original SFP; they > all are based on the SFP+ standard, so there will be no issues with the > optic not being able to work at the full 10Gbps it's rated for. > > Sam Chesluk > Network Hardware Resale > > > -----Original Message----- > From: Jason Lixfeld [mailto:jason at lixfeld.ca] > Sent: Thursday, February 17, 2011 3:00 PM > To: nanog at nanog.org > Subject: SFP vs. SFP+ > > I was asked today what the difference between SFP and SFP+ is. I did > really know, so I looked it up and it seems that the SFP spec provides > capabilities for data rates up to 4.25Gb/s, whereas SFP+ supports up to > 10Gb/s. Naturally, this made me wonder whether or not an optic that > supported 10GbE always conformed to the SFP+ standard inherently, or if > there are cases where a 10GbE optic might only support the SFP standard, > thus having a 4.25Gb/s bottleneck. > From dougb at dougbarton.us Thu Feb 17 18:04:05 2011 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 17 Feb 2011 16:04:05 -0800 Subject: Fwd: [arin-announce] IN-ADDR.ARPA Zone Transfer Complete In-Reply-To: <4D5D3AB7.8080909@ripe.net> References: <4D5C3952.1080602@arin.net> <4D5C420C.6030306@dougbarton.us> <4D5D3AB7.8080909@ripe.net> Message-ID: <4D5DB775.1080801@dougbarton.us> On 02/17/2011 07:11, Wolfgang Nagele wrote: > Hi, > >> Relevant to another post today, I've noticed that neither the *.ip6-servers.arpa >> nor the *.in-addr-servers.arpa allow axfr. Which leads to the following questions: > >> 1. Was that a conscious decision, and if so why? > Speaking for the operator of f.in-addr-servers.arpa and f.ip6-servers.arpa this > was simply not on our radar. > >> 2. Is there any hope that axfr could be permitted in the future? > Since we are also operating k.root-servers.net and have provided XFR from it for > all this time we will do so for these servers as well. This has now been enabled > on our systems. Thanks! I sort of suspected that this was the case at least for the servers operated by RIPE NCC because of the history with K as you pointed out above. I appreciate your quick attention to this issue, and my (admittedly non-comprehensive) tests indicate that f.ip6-servers.arpa and f.in-addr-servers.arpa are indeed now allowing transfers. Best Regards, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From marka at isc.org Thu Feb 17 18:52:55 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 18 Feb 2011 11:52:55 +1100 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: Your message of "Thu, 17 Feb 2011 11:16:40 -0800." <5F90644C-5457-460F-9BC3-70802B13A270@delong.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com><245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com><8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us><4D5415C6.80700@matthew.at><09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com><54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org><5A6D953473350C4B9995546AFE9939EE0BC13BC1@RWC-EX1.corp.seven.com><5A6D953473350C4B9995546AFE9939EE0BC13BC3@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE! 0BC13BC9@RWC-EX1.corp.seven.com> <5F90644C-5457-460F-9BC3-70802B13A270@delong.com> Message-ID: <20110218005255.96B37A4A7B9@drugs.dv.isc.org> In message <5F90644C-5457-460F-9BC3-70802B13A270 at delong.com>, Owen DeLong write s: > > > >> Cisco is just one example. The fact is it will likely not work in > >> cell phones, home gateways, windows PCs, Mac's, .... I understand > >> some progress has been made... but choose your scope wisely and pick > >> your battles and know that the weight of the world is against you > >> (cisco and msft) > >> > > > > I don't think I had general usage in mind, more along the lines of the > > "middle 4" in NAT444 that will be rolled out in many networks to > > conserve IP space. > > > Infeasible. NAT444 is primarily needed to avoid doing a CPE forklift > for nearly every subscriber. To deploy these addresses in that space would > require a CPE forklift for nearly every subscriber. Firstly it is entirely possible to do this incrementally. Secondly it doesn't require a fork lift upgrade. A minimal upgrade is all that is required. For modern Linux boxes just setting a DHCP option would be enough. A two line fix in a config file. > >> @George > >> > >> Please don't speculating on when Cisco or Microsoft will support 240/4 > >> on this list. Ask your account rep, then report back with facts. > >> Arm-chair engineering accounts for too many emails on this list. > > > > The usage I have in mind would be transparent to the end stations and, > > frankly, someone who produces provider gear and CPE that can take > > advantage of that space is going to have a great selling point. There > > is some gold under there for someone. 240/4 is a great big "dig here" > > sign if they want some of it. > > > > > Maybe, but, CPE is rarely a unified solution, even within the same carrier. > > Owen -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Thu Feb 17 18:57:39 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 18 Feb 2011 11:57:39 +1100 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: Your message of "Thu, 17 Feb 2011 15:36:39 CDT." <20110217203639.GA3702@mara.org> References: <5A6D953473350C4B9995546AFE9939EE0BC13BC4@RWC-EX1.corp.seven.com><20110217203639.GA3702@mara.org> Message-ID: <20110218005739.B2CEDA4A8E8@drugs.dv.isc.org> In message <20110217203639.GA3702 at mara.org>, Steve Meuse writes: > George Bonser expunged (gbonser at seven.com): > > > Considering the amount of linux-based CPE and other network hardware out > > there (including some Cisco gear), the extent to which it might be > > usable today could be surprising. > > An how many of those embedded linux devices are running a 2.4 kernel? Just lo > ok at xx-wrt as an example. If you have a certain chipset, 2.4 is your only o > ption. And the work to patch that kernel is minimal if it doesn't already support it. It would take less time to fix the kernel than to argue over whether to fix it. > -Steve -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From ras at e-gerbil.net Thu Feb 17 18:59:30 2011 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Thu, 17 Feb 2011 18:59:30 -0600 Subject: SFP vs. SFP+ In-Reply-To: <5D2B264604643843B933666791F5D52F0A8EC74F@nhrglma1.networkhardware.local> References: <36F57F0C-B78A-46AC-AAC4-E5FF902DD032@lixfeld.ca> <5D2B264604643843B933666791F5D52F0A8EC6FF@nhrglma1.networkhardware.local> <5D2B264604643843B933666791F5D52F0A8EC74F@nhrglma1.networkhardware.local> Message-ID: <20110218005930.GA38726@gerbil.cluepon.net> On Thu, Feb 17, 2011 at 03:41:28PM -0800, Sam Chesluk wrote: > Depends on the switch. Some, like the 2960S and 4948E, have 1G/10G > ports. They will, however, not operate at 4Gbps (that particular speed > was chosen to allow the core components to work for gigabit Ethernet, > OC48, 2G FC, and 4G FC). 4G SFPs are relatively rare, and only for fibre channel. Multi-rate SFPs that do up to 2.5G (for OC48) are a lot more common, but they cost more than just a simple 1GE SFP. Since all you can do with Ethernet is 1G or 10G anyways, "most" SFPs you'll encounter in the field will be the cheaper non-multirate kind. For more information about SFP+, as well as some comparisons between different 10G optic types, take a look at: http://www.nanog.org/meetings/nanog42/presentations/pluggables.pdf As an update (since this presentation is from Feb 2008), SFP+ is just now finally starting to get into 40km/ER reach territory. Supplies are limited, as they just very recently started shipping, but they do exist. Of course since they moved the electronic dispersion compensation (EDC) off the optic and onto the host board, the exact distances you'll be able to achieve are still based on the quality of the device you're plugging them into. SFP+ is still mostly an enterprise box or high density / short reach offering, and XFP is still required for full functionality. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From marka at isc.org Thu Feb 17 19:13:34 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 18 Feb 2011 12:13:34 +1100 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: Your message of "Thu, 17 Feb 2011 15:39:22 CDT." <20110217203922.GB3702@mara.org> References: <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> <5A6D953473350C4B9995546AFE9939EE0BC13BC1@RWC-EX1.corp.seven.com> <32ECC9CD-D927-4407-914C-751316C59966@istaff.org> <20110217203423.11DB5A4898E@drugs.dv.isc.org> <20110217203922.GB3702@mara.org> Message-ID: <20110218011334.A55EAA4AF39@drugs.dv.isc.org> In message <20110217203922.GB3702 at mara.org>, Steve Meuse writes: > Mark Andrews expunged (marka at isc.org): > > > Or to ask CISCO to fix the box so it can route it? In many cases > > it is a minimal change. I don't know whether it is in Cisco 7600 > > They are in the business of selling new gear, not enabling features on EOL eq > uipment :) > > -Steve Sometime the good will generated is worth the minor expense. Remember a lot of this problem is the direct result of vendors not acting soon enough and that includes CISCO. Asking those vendors to do a bit of work to fixup the results of their bad decisions is not unreasonable. They can't fix hardware limitations but they can definitely fix software limitations. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From owen at delong.com Thu Feb 17 19:09:23 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 17 Feb 2011 17:09:23 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <20110218005739.B2CEDA4A8E8@drugs.dv.isc.org> References: <5A6D953473350C4B9995546AFE9939EE0BC13BC4@RWC-EX1.corp.seven.com><20110217203639.GA3702@mara.org> <20110218005739.B2CEDA4A8E8@drugs.dv.isc.org> Message-ID: <4A0543F0-0B14-4A90-8B1B-ABEEB19F6EF5@delong.com> On Feb 17, 2011, at 4:57 PM, Mark Andrews wrote: > > In message <20110217203639.GA3702 at mara.org>, Steve Meuse writes: >> George Bonser expunged (gbonser at seven.com): >> >>> Considering the amount of linux-based CPE and other network hardware out >>> there (including some Cisco gear), the extent to which it might be >>> usable today could be surprising. >> >> An how many of those embedded linux devices are running a 2.4 kernel? Just lo >> ok at xx-wrt as an example. If you have a certain chipset, 2.4 is your only o >> ption. > > And the work to patch that kernel is minimal if it doesn't already > support it. It would take less time to fix the kernel than to argue > over whether to fix it. > >> -Steve > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org But way way way more time to deploy the patched kernel than to forklift the devices with IPv6 capable ones which don't require patching the kernel, either. The kernel patch is, at best, an expensive stop gap. At worst, it is a counter productive waste of time. At best it's slightly short of break-even. At worst, it's a huge $negative. Owen From marka at isc.org Thu Feb 17 19:18:41 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 18 Feb 2011 12:18:41 +1100 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: Your message of "Thu, 17 Feb 2011 12:59:54 -0800." <1DBDCA5F-16EC-428D-BC46-3BD59A6F4CDB@delong.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> <20110217203020.7E40EA488B2@drugs.dv.isc.org> <1DBDCA5F-16EC-428D-BC46-3BD59A6F4CDB@delong.com> Message-ID: <20110218011841.4F865A4AFF0@drugs.dv.isc.org> In message <1DBDCA5F-16EC-428D-BC46-3BD59A6F4CDB at delong.com>, Owen DeLong write s: > > > > You can reflash CPE devices to support this that you can't reflash > > to support IPv6 as there is no space in the flash for the extra > > code. This should be minimal. A extra PPP/DHCP option and a check > > box to enable (default) / disable setting it. > > Reflashing most CPE amounts to forklifting. The difference between > having them bring their CPE in to be reflashed or rolling a truck > to do same vs. replacing the CPE will, in most cases, actually render > replacing the CPE cheaper. It depends on the CPE device. Lots of CPE devices can be re-flashed in place. It just requires the will to make the images available. > > It can be deployed incrementally. > > > So can replacing the CPE, but, neither is a particularly attractive > alternative for many providers. And further indecision is going to make this worse not better. > Owen > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From owen at delong.com Thu Feb 17 19:35:03 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 17 Feb 2011 17:35:03 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <20110218011841.4F865A4AFF0@drugs.dv.isc.org> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> <20110217203020.7E40EA488B2@drugs.dv.isc.org> <1DBDCA5F-16EC-428D-BC46-3BD59A6F4CDB@delong.com> <20110218011841.4F865A4AFF0@drugs.dv.isc.org> Message-ID: On Feb 17, 2011, at 5:18 PM, Mark Andrews wrote: > > In message <1DBDCA5F-16EC-428D-BC46-3BD59A6F4CDB at delong.com>, Owen DeLong write > s: >>> >>> You can reflash CPE devices to support this that you can't reflash >>> to support IPv6 as there is no space in the flash for the extra >>> code. This should be minimal. A extra PPP/DHCP option and a check >>> box to enable (default) / disable setting it. >> >> Reflashing most CPE amounts to forklifting. The difference between >> having them bring their CPE in to be reflashed or rolling a truck >> to do same vs. replacing the CPE will, in most cases, actually render >> replacing the CPE cheaper. > > It depends on the CPE device. Lots of CPE devices can be re-flashed > in place. It just requires the will to make the images available. > Who do you think is going to do this reflashing? If you think that Grandma is going to download an image and reflash her linksys, you're at least slightly divorced from reality. If you think she's going to do it and not have about a 10% brick rate (10% of devices going from router to brick) as a result, then, you're optimistic to say the least. >>> It can be deployed incrementally. >>> >> So can replacing the CPE, but, neither is a particularly attractive >> alternative for many providers. > > And further indecision is going to make this worse not better. > On this we agree... Which is why we should decide to move to IPv6 and get on with it instead of continuing to pursue rat-holes like 240/4. Owen From owen at delong.com Thu Feb 17 19:39:32 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 17 Feb 2011 17:39:32 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <20110218005255.96B37A4A7B9@drugs.dv.isc.org> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com><245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com><8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us><4D5415C6.80700@matthew.at><09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com><54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org><5A6D953473350C4B9995546AFE9939EE0BC13BC1@RWC-EX1.corp.seven.com><5A6D953473350C4B9995546AFE9939EE0BC13BC3@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE! ! 0BC13BC9@RWC-EX1.corp.seven.com> <5F90644C-5457-460F-9BC3-70802B13A270@delong.com> <20110218005255.96B37A4A7B9@drugs.dv.isc.org> Message-ID: <7B275DE0-464D-4F26-AC5C-2AD30EEB7579@delong.com> On Feb 17, 2011, at 4:52 PM, Mark Andrews wrote: > > In message <5F90644C-5457-460F-9BC3-70802B13A270 at delong.com>, Owen DeLong write > s: >>> >>>> Cisco is just one example. The fact is it will likely not work in >>>> cell phones, home gateways, windows PCs, Mac's, .... I understand >>>> some progress has been made... but choose your scope wisely and pick >>>> your battles and know that the weight of the world is against you >>>> (cisco and msft) >>>> >>> >>> I don't think I had general usage in mind, more along the lines of the >>> "middle 4" in NAT444 that will be rolled out in many networks to >>> conserve IP space. >>> >> Infeasible. NAT444 is primarily needed to avoid doing a CPE forklift >> for nearly every subscriber. To deploy these addresses in that space would >> require a CPE forklift for nearly every subscriber. > > Firstly it is entirely possible to do this incrementally. Secondly > it doesn't require a fork lift upgrade. A minimal upgrade is all > that is required. For modern Linux boxes just setting a DHCP option > would be enough. A two line fix in a config file. > Whether you do it incrementally or not, you have to upgrade every affected device eventually. You can roll out IPv6 incrementally, too. Most CPE is _NOT_ within the description of "modern linux boxes" so does not apply to the discussion of the middle 4 in NAT444. It may not require an actual forklift upgrade, but, in the real world, it will require ISP efforts that are equivalent to a forklift upgrade, so, if you're going to that much trouble, it's cheaper (and in many cases easier) to go ahead and forklift your way to IPv6. Ideally in the next round of CPE, the need for NAT444 is a non-issue. It should support at least DS-Lite or 6rd. Anything earlier than the next round of equipment will need to be at least re-flashed. Owen From gbonser at seven.com Thu Feb 17 19:47:09 2011 From: gbonser at seven.com (George Bonser) Date: Thu, 17 Feb 2011 17:47:09 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <4A0543F0-0B14-4A90-8B1B-ABEEB19F6EF5@delong.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13BC4@RWC-EX1.corp.seven.com><20110217203639.GA3702@mara.org><20110218005739.B2CEDA4A8E8@drugs.dv.isc.org> <4A0543F0-0B14-4A90-8B1B-ABEEB19F6EF5@delong.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13C0D@RWC-EX1.corp.seven.com> > > But way way way more time to deploy the patched kernel than to forklift > the > devices with IPv6 capable ones which don't require patching the kernel, > either. > > The kernel patch is, at best, an expensive stop gap. At worst, it is a > counter > productive waste of time. At best it's slightly short of break-even. At > worst, > it's a huge $negative. > > Owen > I don't think anyone was proposing it as an alternative to v6. It is more along the lines of keeping the existing v4 net working as people migrate over. Freeing up WAN IPs can make them available for v6 migration purposes. The ironic thing about v6 is that it will require some additional v4 addresses during the migration period. From cgrundemann at gmail.com Thu Feb 17 19:54:30 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 17 Feb 2011 18:54:30 -0700 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <4C060A07-4FA7-467B-8BA8-8D4D04A0BA9A@queuefull.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> <4C060A07-4FA7-467B-8BA8-8D4D04A0BA9A@queuefull.net> Message-ID: On Thu, Feb 10, 2011 at 14:17, Benson Schliesser wrote: > If you have more experience (not including rumors) that suggests otherwise, I'd very much like to hear about it. ?I'm open to the possibility that NAT444 breaks stuff - that feels right in my gut - but I haven't found any valid evidence of this. In case you have not already found this: http://tools.ietf.org/html/draft-donley-nat444-impacts-01 Cheers, ~Chris > > Regardless, I think we can agree that IPv6 is the way to avoid NAT-related growing pains. ?We've known this for a long time. > > Cheers, > -Benson > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From marka at isc.org Thu Feb 17 19:55:58 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 18 Feb 2011 12:55:58 +1100 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: Your message of "Thu, 17 Feb 2011 17:35:03 -0800." References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> <20110217203020.7E40EA488B2@drugs.dv.isc.org> <1DBDCA5F-16EC-428D-BC46-3BD59A6F4CDB@delong.com> <20110218011841.4F865A4AFF0@drugs.dv.isc.org> Message-ID: <20110218015558.395F3A4BBA0@drugs.dv.isc.org> In message , Owen DeLong write s: > > On Feb 17, 2011, at 5:18 PM, Mark Andrews wrote: > > >=20 > > In message <1DBDCA5F-16EC-428D-BC46-3BD59A6F4CDB at delong.com>, Owen = > DeLong write > > s: > >>>=20 > >>> You can reflash CPE devices to support this that you can't reflash > >>> to support IPv6 as there is no space in the flash for the extra > >>> code. This should be minimal. A extra PPP/DHCP option and a check > >>> box to enable (default) / disable setting it. > >>=20 > >> Reflashing most CPE amounts to forklifting. The difference between > >> having them bring their CPE in to be reflashed or rolling a truck > >> to do same vs. replacing the CPE will, in most cases, actually render > >> replacing the CPE cheaper. > >=20 > > It depends on the CPE device. Lots of CPE devices can be re-flashed > > in place. It just requires the will to make the images available. > >=20 > Who do you think is going to do this reflashing? If you think that = > Grandma > is going to download an image and reflash her linksys, you're at least > slightly divorced from reality. I think grandma is quite capable of doing it. She just needs to be informed that it needs to be done. Most people that are scared of doing it themselves have someone that they can call on to do it for them. It also doesn't have to be 100%. > If you think she's going to do it and not have about a 10% brick rate > (10% of devices going from router to brick) as a result, then, you're > optimistic to say the least. Reflashing with manufacture supplied images doesn't have a 10% brick rate. > >>> It can be deployed incrementally. > >>>=20 > >> So can replacing the CPE, but, neither is a particularly attractive > >> alternative for many providers. > >=20 > > And further indecision is going to make this worse not better. > >=20 > > > On this we agree... > > Which is why we should decide to move to IPv6 and get on with it instead > of continuing to pursue rat-holes like 240/4. 240/4 is actually an enabler for IPv6. It allows the operator to give the customer a stable IPv4 address which can be used for stable IPv6 addresses via 6rd. Different parts upgrade at different times and we need to de-couple all those upgrades if we can. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From randy at psg.com Thu Feb 17 19:57:01 2011 From: randy at psg.com (Randy Bush) Date: Fri, 18 Feb 2011 09:57:01 +0800 Subject: Information about upcoming transition of mailing list ownership In-Reply-To: <4D5D94AA.3060003@merit.edu> References: <4D5D94AA.3060003@merit.edu> Message-ID: > It has been a privilege for Merit to serve the NANOG community since > the formation of the group in 1994. the merit folk have done a great job since nanog happened out of techs. you held the community together and helped move the internet forward. deep thanks. and you're still family. randy From joey.liuyq at gmail.com Thu Feb 17 20:03:12 2011 From: joey.liuyq at gmail.com (Yaoqing(Joey) Liu) Date: Thu, 17 Feb 2011 20:03:12 -0600 Subject: Internet Exchange Point(IXP) questions Message-ID: I'm doing some research on multiple origin AS problems of IXPs. As I know, generally there are two types of IXPs type 1: use exchange routers, which works in layer 3 type 2: use switches and Ethernet topology, which works in layer 2. So I have a couple of qustions: 1. For type 1, the exchange routers may use several IP prefixes for routing, how often does the IP prefixes have their own AS? 2. For type 2, all peers connected to the IXP must work in the same subnet required by Ethernet rules. Is possible that the subnet IP prefixes belong to some private IP address space, such as 192.168.x.x? How often does this happen? If the subnet only contains public IP addresses, how are the addresses announced? Thanks, Yaoqing From smeuse at mara.org Thu Feb 17 20:06:22 2011 From: smeuse at mara.org (Steve Meuse) Date: Thu, 17 Feb 2011 21:06:22 -0500 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <20110218005739.B2CEDA4A8E8@drugs.dv.isc.org> References: <20110218005739.B2CEDA4A8E8@drugs.dv.isc.org> Message-ID: <20110218020622.GA10995@mara.org> Mark Andrews expunged (marka at isc.org): > > An how many of those embedded linux devices are running a 2.4 kernel? Just lo > > ok at xx-wrt as an example. If you have a certain chipset, 2.4 is your only o > > ption. > > And the work to patch that kernel is minimal if it doesn't already > support it. It would take less time to fix the kernel than to argue > over whether to fix it. The point is just because it's "running linux" doesn't make it any more likely to get upgraded than joe six pack is going to update/patch his windows XP. -Steve From smeuse at mara.org Thu Feb 17 20:11:34 2011 From: smeuse at mara.org (Steve Meuse) Date: Thu, 17 Feb 2011 21:11:34 -0500 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <20110218011334.A55EAA4AF39@drugs.dv.isc.org> References: <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> <5A6D953473350C4B9995546AFE9939EE0BC13BC1@RWC-EX1.corp.seven.com> <32ECC9CD-D927-4407-914C-751316C59966@istaff.org> <20110217203423.11DB5A4898E@drugs.dv.isc.org> <20110217203922.GB3702@mara.org> <20110218011334.A55EAA4AF39@drugs.dv.isc.org> Message-ID: <20110218021134.GB10995@mara.org> Mark Andrews expunged (marka at isc.org): > Remember a lot of this problem is the direct result of vendors not > acting soon enough and that includes CISCO. Asking those vendors > to do a bit of work to fixup the results of their bad decisions is > not unreasonable. They can't fix hardware limitations but they can > definitely fix software limitations. Vendors have finite resources. I'm not going to ask them to waste time fixing something that buys us a short amount of time vs. asking them to work on a feature that has immediate impact to my ability to generate revenue. Yah, I'm one of those dirty capitalists. What's Randy's quote? "I highly recommend my competitors do this..." -Steve From mksmith at adhost.com Thu Feb 17 20:17:48 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Fri, 18 Feb 2011 02:17:48 +0000 Subject: Internet Exchange Point(IXP) questions In-Reply-To: References: Message-ID: > -----Original Message----- > From: Yaoqing(Joey) Liu [mailto:joey.liuyq at gmail.com] > Sent: Thursday, February 17, 2011 6:03 PM > To: nanog at nanog.org > Subject: Internet Exchange Point(IXP) questions > > I'm doing some research on multiple origin AS problems of IXPs. As I know, > generally there are two types of IXPs > type 1: use exchange routers, which works in layer 3 > type 2: use switches and Ethernet topology, which works in layer 2. > So I have a couple of qustions: > 1. For type 1, the exchange routers may use several IP prefixes for routing, > how often does the IP prefixes have their own AS? > 2. For type 2, all peers connected to the IXP must work in the same subnet > required by Ethernet rules. Is possible that the subnet IP prefixes belong > to some private IP address space, such as 192.168.x.x? How often does this > happen? If the subnet only contains public IP addresses, how are the > addresses announced? > > Thanks, > Yaoqing Hello: On the Seattle Internet Exchange (SIX) we have ARIN-assigned addresses that we use on the Layer 2 fabric (your type 2 above). Hopefully the addresses aren't being announced at all, although we sometimes have to chase down people that announce it. Those addresses aren't the destination for any traffic, they are merely part of the transport to a destination, so there is no need for them to be in the DFZ. Regards, Mike -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) From marka at isc.org Thu Feb 17 20:19:11 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 18 Feb 2011 13:19:11 +1100 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: Your message of "Thu, 17 Feb 2011 21:06:22 CDT." <20110218020622.GA10995@mara.org> References: <20110218005739.B2CEDA4A8E8@drugs.dv.isc.org><20110218020622.GA10995@mara.org> Message-ID: <20110218021911.8BD2BA4BED7@drugs.dv.isc.org> In message <20110218020622.GA10995 at mara.org>, Steve Meuse writes: > Mark Andrews expunged (marka at isc.org): > > > > An how many of those embedded linux devices are running a 2.4 kernel? Jus > t lo > > > ok at xx-wrt as an example. If you have a certain chipset, 2.4 is your on > ly o > > > ption. > > > > And the work to patch that kernel is minimal if it doesn't already > > support it. It would take less time to fix the kernel than to argue > > over whether to fix it. > > The point is just because it's "running linux" doesn't make it any more likel > y to get upgraded than joe six pack is going to update/patch his windows XP. Joe 6 pack does upgrade his XP box. It companies that don't. There too worried about things breaking. > -Steve > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From smeuse at mara.org Thu Feb 17 20:19:32 2011 From: smeuse at mara.org (Steve Meuse) Date: Thu, 17 Feb 2011 21:19:32 -0500 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <20110218015558.395F3A4BBA0@drugs.dv.isc.org> References: <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> <20110217203020.7E40EA488B2@drugs.dv.isc.org> <1DBDCA5F-16EC-428D-BC46-3BD59A6F4CDB@delong.com> <20110218011841.4F865A4AFF0@drugs.dv.isc.org> <20110218015558.395F3A4BBA0@drugs.dv.isc.org> Message-ID: <20110218021932.GC10995@mara.org> Mark Andrews expunged (marka at isc.org): > I think grandma is quite capable of doing it. She just needs to > be informed that it needs to be done. On my planet (Earth), this isn't likely ever happen. -Steve From bicknell at ufp.org Thu Feb 17 20:31:22 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 17 Feb 2011 18:31:22 -0800 Subject: Internet Exchange Point(IXP) questions In-Reply-To: References: Message-ID: <20110218023122.GA92772@ussenterprise.ufp.org> In a message written on Fri, Feb 18, 2011 at 02:17:48AM +0000, Michael K. Smith - Adhost wrote: > On the Seattle Internet Exchange (SIX) we have ARIN-assigned addresses that we use on the Layer 2 fabric (your type 2 above). Hopefully the addresses aren't being announced at all, although we sometimes have to chase down people that announce it. Those addresses aren't the destination for any traffic, they are merely part of the transport to a destination, so there is no need for them to be in the DFZ. I've had to deal with exchanges like this in the past, and frankly they have always been a pain for the support organization. You see, customers use tools like mtr or Visual Traceroute that do a traceroute and then continuously ping each hop. Many of these customers don't have a default route, or default to their _other_ provider. These tools end up showing 100% loss at the exchange, as they get the traceroute response and then can't ping it. They then open a ticket, and your support organization has to explain to them how all of this works and why it isn't the real cause of their problem. My preference is that the exchange get an ASN, peer with everyone (e.g. from the route server) and announce the exchange prefix. That way it's consistently announced. For exchange that don't do this, I've always put the prefix into BGP in such a way that I will announce it but only to my customers to work around this problem. Please get your own ASN and announce the route, for the sake of all of your members. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From randy at psg.com Thu Feb 17 20:40:04 2011 From: randy at psg.com (Randy Bush) Date: Fri, 18 Feb 2011 10:40:04 +0800 Subject: Internet Exchange Point(IXP) questions In-Reply-To: <20110218023122.GA92772@ussenterprise.ufp.org> References: <20110218023122.GA92772@ussenterprise.ufp.org> Message-ID: >> On the Seattle Internet Exchange (SIX) we have ARIN-assigned >> addresses that we use on the Layer 2 fabric (your type 2 above). >> Hopefully the addresses aren't being announced at all, although we >> sometimes have to chase down people that announce it. > > I've had to deal with exchanges like this in the past, and frankly > they have always been a pain for the support organization. > > You see, customers use tools like mtr or Visual Traceroute that do > a traceroute and then continuously ping each hop. Many of these > customers don't have a default route, or default to their _other_ > provider. These tools end up showing 100% loss at the exchange, > as they get the traceroute response and then can't ping it. > > They then open a ticket, and your support organization has to explain > to them how all of this works and why it isn't the real cause of > their problem. > My preference is that the exchange get an ASN, peer with everyone > (e.g. from the route server) and announce the exchange prefix. i do not like route servers or peering with strange things. treat the exchange as an internal route and announce it within your net and to your customer cone. randy From jack at crepinc.com Thu Feb 17 21:01:10 2011 From: jack at crepinc.com (Jack Carrozzo) Date: Thu, 17 Feb 2011 22:01:10 -0500 Subject: ipv6 transit over tunneled connection In-Reply-To: <2C05E949E19A9146AF7BDF9D44085B863C2BEC427F@exchange.aoihq.local> References: <33361326.494.1273861611194.JavaMail.franck@dport-d820.genius.local> <18959438.496.1273861781840.JavaMail.franck@dport-d820.genius.local> <56516858-8108-41E8-BAB8-0139D1C93B2B@puck.nether.net> <2C05E949E19A9146AF7BDF9D44085B863C2BEC427F@exchange.aoihq.local> Message-ID: We pick up v6 from HE currently (like the rest of the world). L3 offered us dual stack also, but they wanted money to set it up plus MRC. None of our Bits That Matter (tm) go over v6 anyhow. (I guess the right phrase would be "revenue producing bits"). -Jack Carrozzo On Mon, May 17, 2010 at 9:51 AM, Eric Van Tol wrote: > > -----Original Message----- > > From: Jared Mauch [mailto:jared at puck.nether.net] > > Sent: Friday, May 14, 2010 2:49 PM > > To: Jack Carrozzo > > Cc: nanog at nanog.org > > Subject: Re: ipv6 transit over tunneled connection > > > > I'm curious what providers have not gotten their IPv6 > > plans/networks/customer ports enabled. > > > > I know that Comcast is doing their trials now (Thanks John!) and will be > > presenting at the upcoming NANOG about their experiences. > > > > What parts of the big "I" Internet are not enabled or ready? > > > > We don't see Savvis, Level3, or AboveNet with IPv6 capabilities in our > region (DC). Two years ago, neither Verizon or AT&T had IPv6, either. Not > sure about them now, as we no longer use them for transit. One would think > everyone would have v6 capabilities in the heart of government territory, > but okay. > > For whatever reason, Verio actually charges (or used to) for their IPv6 > separately from IPv4 and to top it all off, it wasn't significantly > discounted. > > -evt > > > From joey.liuyq at gmail.com Thu Feb 17 21:04:24 2011 From: joey.liuyq at gmail.com (Yaoqing(Joey) Liu) Date: Thu, 17 Feb 2011 21:04:24 -0600 Subject: Internet Exchange Point(IXP) questions In-Reply-To: References: Message-ID: On Thu, Feb 17, 2011 at 8:17 PM, Michael K. Smith - Adhost < mksmith at adhost.com> wrote: > > -----Original Message----- > > From: Yaoqing(Joey) Liu [mailto:joey.liuyq at gmail.com] > > Sent: Thursday, February 17, 2011 6:03 PM > > To: nanog at nanog.org > > Subject: Internet Exchange Point(IXP) questions > > > > I'm doing some research on multiple origin AS problems of IXPs. As I > know, > > generally there are two types of IXPs > > type 1: use exchange routers, which works in layer 3 > > type 2: use switches and Ethernet topology, which works in layer 2. > > So I have a couple of qustions: > > 1. For type 1, the exchange routers may use several IP prefixes for > routing, > > how often does the IP prefixes have their own AS? > > 2. For type 2, all peers connected to the IXP must work in the same > subnet > > required by Ethernet rules. Is possible that the subnet IP prefixes > belong > > to some private IP address space, such as 192.168.x.x? How often does > this > > happen? If the subnet only contains public IP addresses, how are the > > addresses announced? > > > > Thanks, > > Yaoqing > > Hello: > > On the Seattle Internet Exchange (SIX) we have ARIN-assigned addresses that > we use on the Layer 2 fabric (your type 2 above). Hopefully the addresses > aren't being announced at all, although we sometimes have to chase down > people that announce it. Those addresses aren't the destination for any > traffic, they are merely part of the transport to a destination, so there is > no need for them to be in the DFZ. > But I just checked the IXP prefix list, and found SIX owns prefix 206.81.80.0/23. And it has been announced by three ASNs, AS11537(Internet 2), AS3130(RGnet, LLC) and AS25973(Mzima Networks, Inc). I'm not sure if my info is correct. Does SIX own its own ASN other than the three above? Yaoqing > Regards, > > Mike > -- > Michael K. Smith - CISSP, GSEC, GISP > Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com > w: +1 (206) 404-9500 f: +1 (206) 404-9050 > PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) > > > From frnkblk at iname.com Thu Feb 17 21:04:29 2011 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 17 Feb 2011 21:04:29 -0600 Subject: SFP vs. SFP+ In-Reply-To: <20110218005930.GA38726@gerbil.cluepon.net> References: <36F57F0C-B78A-46AC-AAC4-E5FF902DD032@lixfeld.ca> <5D2B264604643843B933666791F5D52F0A8EC6FF@nhrglma1.networkhardware.local> <5D2B264604643843B933666791F5D52F0A8EC74F@nhrglma1.networkhardware.local> <20110218005930.GA38726@gerbil.cluepon.net> Message-ID: <00bb01cbcf18$8ee491a0$acadb4e0$@iname.com> Are there are any optics that plug into 10G ports but have a copper or optical 1G interface? There's some equipment that I'm specing where it is $10K for a multi-port 1G card, even while I really may only *occasionally* need a single 1G port and there's a free 10G port for me to use. Frank -----Original Message----- From: Richard A Steenbergen [mailto:ras at e-gerbil.net] Sent: Thursday, February 17, 2011 7:00 PM To: Jason Lixfeld Cc: nanog at nanog.org Subject: Re: SFP vs. SFP+ On Thu, Feb 17, 2011 at 03:41:28PM -0800, Sam Chesluk wrote: > Depends on the switch. Some, like the 2960S and 4948E, have 1G/10G > ports. They will, however, not operate at 4Gbps (that particular speed > was chosen to allow the core components to work for gigabit Ethernet, > OC48, 2G FC, and 4G FC). 4G SFPs are relatively rare, and only for fibre channel. Multi-rate SFPs that do up to 2.5G (for OC48) are a lot more common, but they cost more than just a simple 1GE SFP. Since all you can do with Ethernet is 1G or 10G anyways, "most" SFPs you'll encounter in the field will be the cheaper non-multirate kind. For more information about SFP+, as well as some comparisons between different 10G optic types, take a look at: http://www.nanog.org/meetings/nanog42/presentations/pluggables.pdf As an update (since this presentation is from Feb 2008), SFP+ is just now finally starting to get into 40km/ER reach territory. Supplies are limited, as they just very recently started shipping, but they do exist. Of course since they moved the electronic dispersion compensation (EDC) off the optic and onto the host board, the exact distances you'll be able to achieve are still based on the quality of the device you're plugging them into. SFP+ is still mostly an enterprise box or high density / short reach offering, and XFP is still required for full functionality. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From bhmccie at gmail.com Thu Feb 17 21:06:49 2011 From: bhmccie at gmail.com (-Hammer-) Date: Thu, 17 Feb 2011 21:06:49 -0600 Subject: ipv6 transit over tunneled connection In-Reply-To: References: <33361326.494.1273861611194.JavaMail.franck@dport-d820.genius.local> <18959438.496.1273861781840.JavaMail.franck@dport-d820.genius.local> <56516858-8108-41E8-BAB8-0139D1C93B2B@puck.nether.net> <2C05E949E19A9146AF7BDF9D44085B863C2BEC427F@exchange.aoihq.local> Message-ID: <000c01cbcf18$e34e37f0$a9eaa7d0$@com> AT&T has told us that they will have IPv6 on their MIS circuits Q2 2011. Deltacom has told us the same. We will be testing native IPv6 with both these carriers on GE Internet circuits sometime around Q3. ? -Hammer- ? "I was a normal American nerd." -Jack Herer ? ? -----Original Message----- From: Jack Carrozzo [mailto:jack at crepinc.com] Sent: Thursday, February 17, 2011 9:01 PM To: Eric Van Tol Cc: nanog at nanog.org Subject: Re: ipv6 transit over tunneled connection We pick up v6 from HE currently (like the rest of the world). L3 offered us dual stack also, but they wanted money to set it up plus MRC. None of our Bits That Matter (tm) go over v6 anyhow. (I guess the right phrase would be "revenue producing bits"). -Jack Carrozzo On Mon, May 17, 2010 at 9:51 AM, Eric Van Tol wrote: > > -----Original Message----- > > From: Jared Mauch [mailto:jared at puck.nether.net] > > Sent: Friday, May 14, 2010 2:49 PM > > To: Jack Carrozzo > > Cc: nanog at nanog.org > > Subject: Re: ipv6 transit over tunneled connection > > > > I'm curious what providers have not gotten their IPv6 > > plans/networks/customer ports enabled. > > > > I know that Comcast is doing their trials now (Thanks John!) and will be > > presenting at the upcoming NANOG about their experiences. > > > > What parts of the big "I" Internet are not enabled or ready? > > > > We don't see Savvis, Level3, or AboveNet with IPv6 capabilities in our > region (DC). Two years ago, neither Verizon or AT&T had IPv6, either. Not > sure about them now, as we no longer use them for transit. One would think > everyone would have v6 capabilities in the heart of government territory, > but okay. > > For whatever reason, Verio actually charges (or used to) for their IPv6 > separately from IPv4 and to top it all off, it wasn't significantly > discounted. > > -evt > > > From frnkblk at iname.com Thu Feb 17 21:11:32 2011 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 17 Feb 2011 21:11:32 -0600 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <20110218015558.395F3A4BBA0@drugs.dv.isc.org> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> <20110217203020.7E40EA488B2@drugs.dv.isc.org> <1DBDCA5F-16EC-428D-BC46-3BD59A6F4CDB@delong.com> <20110218011841.4F865A4AFF0@drugs.dv.isc.org> <20110218015558.395F3A4BBA0@drugs.dv.isc.org> Message-ID: <00bc01cbcf19$8b3f13d0$a1bd3b70$@iname.com> You're invited to work my helpdesk for a week. I'd even pay you. It's not just flashing, it's reconfiguring every wireless device in the home (printer, Wii, Kindle, laptop (that's not home right, will be when Sally visits for the weekend), etc). If you can come up with an online tool that downloads the correct firmware image, backs up the settings, upgrades the firmware, and restores the configuration, with 99% success, I'd consider buying it to the tune $10/upgraded device. Frank -----Original Message----- From: Mark Andrews [mailto:marka at isc.org] Sent: Thursday, February 17, 2011 7:56 PM To: Owen DeLong Cc: NANOG list; John Curran Subject: Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... I think grandma is quite capable of doing it. She just needs to be informed that it needs to be done. Most people that are scared of doing it themselves have someone that they can call on to do it for them. It also doesn't have to be 100%. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From woody at pch.net Thu Feb 17 21:16:31 2011 From: woody at pch.net (Bill Woodcock) Date: Thu, 17 Feb 2011 19:16:31 -0800 Subject: Internet Exchange Point(IXP) questions In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 17, 2011, at 6:03 PM, Yaoqing(Joey) Liu wrote: > As I know, generally there are two types of IXPs This is incorrect. > type 1: use exchange routers, which works in layer 3 This is not an IXP. This is a router. That router would be owned by someone, who would have some sort of policy in the router, which would make it an Internet service provider, not an Internet exchange point. > type 2: use switches and Ethernet topology, which works in layer 2. This is an IXP. Routers belonging to Internet service providers, communicating with each other across a switch fabric, which is an Internet exchange point. > 1. For type 1, the exchange routers may use several IP prefixes for routing, > how often does the IP prefixes have their own AS? Since this is not an IXP, I think the question is irrelevant to your research. If an ISP wants to participate in BGP routing, and originate an IP prefix, that ISP must have an AS. > 2. For type 2, all peers connected to the IXP must work in the same subnet > required by Ethernet rules. Generally, yes, though some IXPs are not that prescriptive, and would allow a subset of the ISPs to peer on a different subnet if they wished. > Is possible that the subnet IP prefixes belong to some private IP address space, such as 192.168.x.x? It is possible, but it does not follow best-practices, because it breaks traceroute and other diagnostic tools. > How often does this happen? Very very rarely. Only two IXPs out of more than three hundred are using FRC1918 space at this point: Maputo and Santiago de Compostela. This used to be a more common mistake, but as communications with the operators of new IXPs has improved over time, it's become very rare. > If the subnet only contains public IP addresses, how are the addresses announced? They are generally not announced. Occasionally they're announced by one or more participating ISPs at the IXP. Sometimes that's purposeful, other times it's accidental. Some IXPs have rules prohibiting the announcement of the exchange subnet, others actively seek out sources of transit for the exchange subnet. -Bill Woodcock Research Director Packet Clearing House -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk1d5I8ACgkQGvQy4xTRsBFXOwCfbsutsSyYHHwQu5W06BgasXQm QNgAoMScxNcjOLQNdJC5mz4enD1/839f =6iFI -----END PGP SIGNATURE----- From ras at e-gerbil.net Thu Feb 17 21:17:55 2011 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Thu, 17 Feb 2011 21:17:55 -0600 Subject: SFP vs. SFP+ In-Reply-To: <00bb01cbcf18$8ee491a0$acadb4e0$@iname.com> References: <36F57F0C-B78A-46AC-AAC4-E5FF902DD032@lixfeld.ca> <5D2B264604643843B933666791F5D52F0A8EC6FF@nhrglma1.networkhardware.local> <5D2B264604643843B933666791F5D52F0A8EC74F@nhrglma1.networkhardware.local> <20110218005930.GA38726@gerbil.cluepon.net> <00bb01cbcf18$8ee491a0$acadb4e0$@iname.com> Message-ID: <20110218031755.GB38726@gerbil.cluepon.net> On Thu, Feb 17, 2011 at 09:04:29PM -0600, Frank Bulk wrote: > Are there are any optics that plug into 10G ports but have a copper or > optical 1G interface? There's some equipment that I'm specing where > it is $10K for a multi-port 1G card, even while I really may only > *occasionally* need a single 1G port and there's a free 10G port for > me to use. It doesn't work that way. The closest you can get is that the device can support either 1G or 10G in the same port (since SFP and SFP+ are physically and electrically the same), but it requires support from the device (since both PHYs have to be implemented). -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From randy at psg.com Thu Feb 17 21:24:57 2011 From: randy at psg.com (Randy Bush) Date: Fri, 18 Feb 2011 11:24:57 +0800 Subject: Internet Exchange Point(IXP) questions In-Reply-To: References: Message-ID: >> type 1: use exchange routers, which works in layer 3 > This is not an IXP. This is a router. That router would be owned by > someone, who would have some sort of policy in the router, which would > make it an Internet service provider, not an Internet exchange point. this from the guy who pushed "layer three exchange points" for years? rofl! From marka at isc.org Thu Feb 17 21:25:29 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 18 Feb 2011 14:25:29 +1100 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: Your message of "Thu, 17 Feb 2011 21:11:32 MDT." <00bc01cbcf19$8b3f13d0$a1bd3b70$@iname.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> <20110217203020.7E40EA488B2@drugs.dv.isc.org> <1DBDCA5F-16EC-428D-BC46-3BD59A6F4CDB@delong.com> <20110218011841.4F865A4AFF0@drugs.dv.isc.org> <20110218015558.395F3A4BBA0@drugs.dv.isc.org> <00bc01cbcf19$8b3f13d0$a1bd3b70$@iname. com> Message-ID: <20110218032529.C8152A4CF39@drugs.dv.isc.org> In message <00bc01cbcf19$8b3f13d0$a1bd3b70$@iname.com>, "Frank Bulk" writes: > You're invited to work my helpdesk for a week. I'd even pay you. > > It's not just flashing, it's reconfiguring every wireless device in the home > (printer, Wii, Kindle, laptop (that's not home right, will be when Sally > visits for the weekend), etc). Every device doesn't need to know the address. The CPE device still uses RFC 1918 internally. This is for the external address. > If you can come up with an online tool that downloads the correct firmware > image, backs up the settings, upgrades the firmware, and restores the > configuration, with 99% success, I'd consider buying it to the tune > $10/upgraded device. > > Frank -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From randy at psg.com Thu Feb 17 21:25:50 2011 From: randy at psg.com (Randy Bush) Date: Fri, 18 Feb 2011 11:25:50 +0800 Subject: history repeats Message-ID: i am getting nanog list mail repeats from last may randy From llynch at civil-tongue.net Thu Feb 17 21:39:15 2011 From: llynch at civil-tongue.net (Lucy Lynch) Date: Thu, 17 Feb 2011 19:39:15 -0800 (PST) Subject: history repeats In-Reply-To: References: Message-ID: On Fri, 18 Feb 2011, Randy Bush wrote: > i am getting nanog list mail repeats from last may I'm down with Shirley Bassey http://www.youtube.com/watch?v=bE_1tCasi_Q > randy > From jmamodio at gmail.com Thu Feb 17 21:41:35 2011 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 17 Feb 2011 21:41:35 -0600 Subject: history repeats In-Reply-To: References: Message-ID: On Thu, Feb 17, 2011 at 9:25 PM, Randy Bush wrote: > i am getting nanog list mail repeats from last may ME2 -J From santino.codispoti at gmail.com Thu Feb 17 22:30:43 2011 From: santino.codispoti at gmail.com (Santino Codispoti) Date: Thu, 17 Feb 2011 23:30:43 -0500 Subject: ISDN BRI In-Reply-To: <201102171620.43159.lowen@pari.edu> References: <201102171620.43159.lowen@pari.edu> Message-ID: Yes that is my goal. I guess I will be dealing with Verizon and AT&T mostly as the LEC On Thu, Feb 17, 2011 at 4:20 PM, Lamar Owen wrote: > On Thursday, February 17, 2011 10:21:18 am Santino Codispoti wrote: >> Is it possible to order a ISDN BRI line from the LEC and have them >> look at the design of a DS1 and have them if possible design the ISDN >> BRI lineon a devurse path or at lest different equipment within the >> CO? > > As I understand the question, you want the BRI to be path diverse to the DS1's path, correct? > > It would depend upon how well you know the tech folk at the telco, and whether there is existing or planned transport in multiple directions from your site. > > Even if you order bona fide protected circuits, you're not likely to be guaranteed physical path diversity. > > Having said that, lots of telcos will work with you if you know the people to work with, and some will quote you a term agreement for the physical plant provisioning as an additional cost, and probably for three to five years terms. > > From woody at pch.net Thu Feb 17 23:17:36 2011 From: woody at pch.net (Bill Woodcock) Date: Thu, 17 Feb 2011 21:17:36 -0800 Subject: Internet Exchange Point(IXP) questions In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 17, 2011, at 7:24 PM, Randy Bush wrote: > this from the guy who pushed "layer three exchange points" for years? > rofl! I was one of the people who built one in 1994, and used it quite happily for a few years, until it had outlasted its need. Do you have something else in mind? Or are you just trying to keep your blood pressure up? -Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk1eAPEACgkQGvQy4xTRsBFWSwCfcmER1ApNJDCYxUh34tTTBd/e e8sAoLxQ4Q3U1//nOuBF6KLSsQS2K0MD =Rgi7 -----END PGP SIGNATURE----- From jmamodio at gmail.com Thu Feb 17 23:32:18 2011 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 17 Feb 2011 23:32:18 -0600 Subject: Information about upcoming transition of mailing list ownership In-Reply-To: <4D5D94AA.3060003@merit.edu> References: <4D5D94AA.3060003@merit.edu> Message-ID: Most sincere thanks to Merit for their long time support to the network community, Cheers Jorge From pnowak at batblue.com Thu Feb 17 23:55:45 2011 From: pnowak at batblue.com (Peter Nowak) Date: Fri, 18 Feb 2011 00:55:45 -0500 Subject: SFP vs. SFP+ In-Reply-To: <00bb01cbcf18$8ee491a0$acadb4e0$@iname.com> Message-ID: <20110218055545.2aabdb16@concur.batblue.com> You can plug SFP module (copper or fiber) into any SFP+ port. So, on 10G port you can run either 1GE or 10GE. Peter Nowak _____ From: Frank Bulk [mailto:frnkblk at iname.com] To: 'Richard A Steenbergen' [mailto:ras at e-gerbil.net] Cc: nanog at nanog.org Sent: Thu, 17 Feb 2011 22:04:29 -0500 Subject: RE: SFP vs. SFP+ Are there are any optics that plug into 10G ports but have a copper or optical 1G interface? There's some equipment that I'm specing where it is $10K for a multi-port 1G card, even while I really may only *occasionally* need a single 1G port and there's a free 10G port for me to use. Frank -----Original Message----- From: Richard A Steenbergen [mailto:ras at e-gerbil.net] Sent: Thursday, February 17, 2011 7:00 PM To: Jason Lixfeld Cc: nanog at nanog.org Subject: Re: SFP vs. SFP+ On Thu, Feb 17, 2011 at 03:41:28PM -0800, Sam Chesluk wrote: > Depends on the switch. Some, like the 2960S and 4948E, have 1G/10G > ports. They will, however, not operate at 4Gbps (that particular speed > was chosen to allow the core components to work for gigabit Ethernet, > OC48, 2G FC, and 4G FC). 4G SFPs are relatively rare, and only for fibre channel. Multi-rate SFPs that do up to 2.5G (for OC48) are a lot more common, but they cost more than just a simple 1GE SFP. Since all you can do with Ethernet is 1G or 10G anyways, "most" SFPs you'll encounter in the field will be the cheaper non-multirate kind. For more information about SFP+, as well as some comparisons between different 10G optic types, take a look at: http://www.nanog.org/meetings/nanog42/presentations/pluggables.pdf As an update (since this presentation is from Feb 2008), SFP+ is just now finally starting to get into 40km/ER reach territory. Supplies are limited, as they just very recently started shipping, but they do exist. Of course since they moved the electronic dispersion compensation (EDC) off the optic and onto the host board, the exact distances you'll be able to achieve are still based on the quality of the device you're plugging them into. SFP+ is still mostly an enterprise box or high density / short reach offering, and XFP is still required for full functionality. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From ras at e-gerbil.net Fri Feb 18 00:06:55 2011 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Fri, 18 Feb 2011 00:06:55 -0600 Subject: SFP vs. SFP+ In-Reply-To: <20110218055545.2aabdb16@concur.batblue.com> References: <00bb01cbcf18$8ee491a0$acadb4e0$@iname.com> <20110218055545.2aabdb16@concur.batblue.com> Message-ID: <20110218060655.GC38726@gerbil.cluepon.net> On Fri, Feb 18, 2011 at 12:55:45AM -0500, Peter Nowak wrote: > > You can plug SFP module (copper or fiber) into any SFP+ port. > So, on 10G port you can run either 1GE or 10GE. Not true. Some devices support this, since SFP and SFP+ are physically and electrically compatible, but not all. The device must be specifically designed to support both PHYs, which is NOT a given. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From zzuser at yahoo.com Fri Feb 18 02:24:53 2011 From: zzuser at yahoo.com (Zed Usser) Date: Fri, 18 Feb 2011 00:24:53 -0800 (PST) Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <9F8063EB-C9A3-444D-B9CB-7CA12BEE335E@puck.nether.net> Message-ID: <921881.85954.qm@web114701.mail.gq1.yahoo.com> On Thu, Feb 10, 2011 at 14:17, Chris Grundemann wrote: > In case you have not already found this: > http://tools.ietf.org/html/draft-donley-nat444-impacts-01 There's a bit of critique on the NAT444 document on the BEHAVE IETF WG list. "draft-donley-nat444-impacts-01 is somewhat misleading. It claims to analyze NAT444, but it really analyzes what fails when two problems occur: (a) port forwarding isn't configured and (b) UPnP is unavailable or is broken. Several architectures share those two problems: * NAT444 (NAPT44 in the home + NAPT44 in the carrier's network) * LSN (NAPT44 in the carrier's network, without a NAPT44 in the home) * DS-Lite (which is an LSN / NAPT44 in the carrier's network) * stateful NAT64" http://www.ietf.org/mail-archive/web/behave/current/msg09027.html Be that as it may and putting my devil's advocate hat on, aren't the unintended consequences of NAT444 a net win for ISPs? :) Basic Internet services will work (web browsing, email, Facebook, Youtube,...), but: - Less torrenting - Less Netflix watching - Less FTP downloads - Less video streaming in general (webcams, etc.) You might take a hit on online gaming, but what else is there not to love? :) Your sales department / helpdesk might have a bit of hassle of trying to undestand / explain this new Intertubes to the suck^H^H^H^Hcustomers, but most of them won't care either way. Now correct me if I'm wrong, but isn't some kind of NAT/PAT going to be required to join the IPv4 and IPv6 domains in all foreseeable futures? If so, aren't we going to have to deal with these issues in any case? - Zed From nick at foobar.org Fri Feb 18 04:11:37 2011 From: nick at foobar.org (Nick Hilliard) Date: Fri, 18 Feb 2011 10:11:37 +0000 Subject: SFP vs. SFP+ In-Reply-To: <20110218055545.2aabdb16@concur.batblue.com> References: <20110218055545.2aabdb16@concur.batblue.com> Message-ID: <4D5E45D9.3040200@foobar.org> On 18/02/2011 05:55, Peter Nowak wrote: > You can plug SFP module (copper or fiber) into any SFP+ port. > So, on 10G port you can run either 1GE or 10GE. A well known counterexample of this is the Cisco Nexus5k, where only some of the SFP+ ports are 1G capable (first 8 on the 20 port box, and the first 16 on the 40 port box). Nick From jhary at unsane.co.uk Fri Feb 18 04:21:49 2011 From: jhary at unsane.co.uk (Vincent Hoffman) Date: Fri, 18 Feb 2011 10:21:49 +0000 Subject: SFP vs. SFP+ In-Reply-To: <00bb01cbcf18$8ee491a0$acadb4e0$@iname.com> References: <36F57F0C-B78A-46AC-AAC4-E5FF902DD032@lixfeld.ca> <5D2B264604643843B933666791F5D52F0A8EC6FF@nhrglma1.networkhardware.local> <5D2B264604643843B933666791F5D52F0A8EC74F@nhrglma1.networkhardware.local> <20110218005930.GA38726@gerbil.cluepon.net> <00bb01cbcf18$8ee491a0$acadb4e0$@iname.com> Message-ID: <4D5E483D.6050504@unsane.co.uk> On 18/02/2011 03:04, Frank Bulk wrote: > Are there are any optics that plug into 10G ports but have a copper or > optical 1G interface? There's some equipment that I'm specing where it is > $10K for a multi-port 1G card, even while I really may only *occasionally* > need a single 1G port and there's a free 10G port for me to use. Some of the cisco stuff supports a twingig converter module, One tengig to 2 one gig (and from there a copper or optical SFP) http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps7077/product_data_sheet0900aecd805bbee3.html Vince > Frank > > -----Original Message----- > From: Richard A Steenbergen [mailto:ras at e-gerbil.net] > Sent: Thursday, February 17, 2011 7:00 PM > To: Jason Lixfeld > Cc: nanog at nanog.org > Subject: Re: SFP vs. SFP+ > > On Thu, Feb 17, 2011 at 03:41:28PM -0800, Sam Chesluk wrote: >> Depends on the switch. Some, like the 2960S and 4948E, have 1G/10G >> ports. They will, however, not operate at 4Gbps (that particular speed >> was chosen to allow the core components to work for gigabit Ethernet, >> OC48, 2G FC, and 4G FC). > 4G SFPs are relatively rare, and only for fibre channel. Multi-rate SFPs > that do up to 2.5G (for OC48) are a lot more common, but they cost more > than just a simple 1GE SFP. Since all you can do with Ethernet is 1G or > 10G anyways, "most" SFPs you'll encounter in the field will be the > cheaper non-multirate kind. > > For more information about SFP+, as well as some comparisons between > different 10G optic types, take a look at: > > http://www.nanog.org/meetings/nanog42/presentations/pluggables.pdf > > As an update (since this presentation is from Feb 2008), SFP+ is just > now finally starting to get into 40km/ER reach territory. Supplies are > limited, as they just very recently started shipping, but they do exist. > Of course since they moved the electronic dispersion compensation (EDC) > off the optic and onto the host board, the exact distances you'll be > able to achieve are still based on the quality of the device you're > plugging them into. SFP+ is still mostly an enterprise box or high > density / short reach offering, and XFP is still required for full > functionality. > From jhary at unsane.co.uk Fri Feb 18 04:26:14 2011 From: jhary at unsane.co.uk (Vincent Hoffman) Date: Fri, 18 Feb 2011 10:26:14 +0000 Subject: SFP vs. SFP+ In-Reply-To: <00bb01cbcf18$8ee491a0$acadb4e0$@iname.com> References: <36F57F0C-B78A-46AC-AAC4-E5FF902DD032@lixfeld.ca> <5D2B264604643843B933666791F5D52F0A8EC6FF@nhrglma1.networkhardware.local> <5D2B264604643843B933666791F5D52F0A8EC74F@nhrglma1.networkhardware.local> <20110218005930.GA38726@gerbil.cluepon.net> <00bb01cbcf18$8ee491a0$acadb4e0$@iname.com> Message-ID: <4D5E4946.80901@unsane.co.uk> On 18/02/2011 03:04, Frank Bulk wrote: > Are there are any optics that plug into 10G ports but have a copper or > optical 1G interface? There's some equipment that I'm specing where it is > $10K for a multi-port 1G card, even while I really may only *occasionally* > need a single 1G port and there's a free 10G port for me to use. Some of the cisco stuff supports a twingig converter module, One tengig to 2 one gig (and from there a copper or optical SFP) http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps7077/product_data_sheet0900aecd805bbee3.html Vince > Frank > > -----Original Message----- > From: Richard A Steenbergen [mailto:ras at e-gerbil.net] > Sent: Thursday, February 17, 2011 7:00 PM > To: Jason Lixfeld > Cc: nanog at nanog.org > Subject: Re: SFP vs. SFP+ > > On Thu, Feb 17, 2011 at 03:41:28PM -0800, Sam Chesluk wrote: >> Depends on the switch. Some, like the 2960S and 4948E, have 1G/10G >> ports. They will, however, not operate at 4Gbps (that particular speed >> was chosen to allow the core components to work for gigabit Ethernet, >> OC48, 2G FC, and 4G FC). > 4G SFPs are relatively rare, and only for fibre channel. Multi-rate SFPs > that do up to 2.5G (for OC48) are a lot more common, but they cost more > than just a simple 1GE SFP. Since all you can do with Ethernet is 1G or > 10G anyways, "most" SFPs you'll encounter in the field will be the > cheaper non-multirate kind. > > For more information about SFP+, as well as some comparisons between > different 10G optic types, take a look at: > > http://www.nanog.org/meetings/nanog42/presentations/pluggables.pdf > > As an update (since this presentation is from Feb 2008), SFP+ is just > now finally starting to get into 40km/ER reach territory. Supplies are > limited, as they just very recently started shipping, but they do exist. > Of course since they moved the electronic dispersion compensation (EDC) > off the optic and onto the host board, the exact distances you'll be > able to achieve are still based on the quality of the device you're > plugging them into. SFP+ is still mostly an enterprise box or high > density / short reach offering, and XFP is still required for full > functionality. > From iljitsch at muada.com Fri Feb 18 04:50:42 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 18 Feb 2011 11:50:42 +0100 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13BB8@RWC-EX1.corp.seven.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com><245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com><8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at><09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com><54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> <38565.1297953177@localhost> <5A6D953473350C4B9995546AFE9939EE0BC13BB8@RWC-EX1.corp.seven.com> Message-ID: On 17 feb 2011, at 17:35, George Bonser wrote: > Considering v4 is likely to be around for another decade or two, getting > Class E into general use seems easy enough to do. You really think people will be communicating over the public internet using IPv4 in 2031? It will take a long time before the first people are going to turn off IPv4, but once that starts there will be no stopping it and IPv4 will be gone very, very quickly. (Of course there will be legacy stuff, just like some people are still running IPX or AppleTalk today. I'm talking about the public internet here.) Today people are complaining how annoying it is to have to learn new things to be able to run IPv6, but that doesn't compare to how annoying it is to have to learn OLD things to keep running a protocol that is way past its sell by date. I still need to teach class A/B/C despite the fact that CIDR is old enough to drink in most countries because without knowing that you can't configure a Cisco router. That's annoying now. Think about how insane that will be in the 2020s when the notion of requesting IPv4 addresses from an RIR is ancient history and young people don't know any better than having a /64 on every LAN that is big enough to connect all ethernet NICs ever made. Speaking of class E: this address space could be usable for NAT64 translators. That way, only servers and routers need to be upgraded to work with class E, not CPEs or client OSes. From iljitsch at muada.com Fri Feb 18 04:54:56 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 18 Feb 2011 11:54:56 +0100 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <8B0FDF52-A36D-46E8-9408-3C1A4C5D30CD@delong.com> <868vxepnad.fsf@seastrom.com> Message-ID: <3155646E-CC94-4242-83C6-B16C378D42BA@muada.com> On 17 feb 2011, at 18:57, John Curran wrote: > Actually, as I have noted before, the US DoD has contractually > agreed to return to ARIN unneeded IPv4 address space if/when > such becomes available, so that it may be used by the Internet > community. How can they "return" stuff to ARIN that they got from IANA in the first place? ARIN seems to be getting the very long end of the legacy stick. From patrick at ianai.net Fri Feb 18 05:00:14 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 18 Feb 2011 06:00:14 -0500 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <3155646E-CC94-4242-83C6-B16C378D42BA@muada.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <8B0FDF52-A36D-46E8-9408-3C1A4C5D30CD@delong.com> <868vxepnad.fsf@seastrom.com> <3155646E-CC94-4242-83C6-B16C378D42BA@muada.com> Message-ID: <33743D00-0DA9-4580-BD38-5037FE16CBAF@ianai.net> On Feb 18, 2011, at 5:54 AM, Iljitsch van Beijnum wrote: > On 17 feb 2011, at 18:57, John Curran wrote: > >> Actually, as I have noted before, the US DoD has contractually >> agreed to return to ARIN unneeded IPv4 address space if/when >> such becomes available, so that it may be used by the Internet >> community. > > How can they "return" stuff to ARIN that they got from IANA in the first place? > > ARIN seems to be getting the very long end of the legacy stick. Agreed. But last time I checked, the United States is in the ARIN region. And ARIN did not exist when the US DoD got its space. (In fact, I do believe the reason "IP space" exists is because the DoD paid someone to come up with the idea? :) If the US DoD wants more space, it has to ask ARIN, right? Are you suggesting it should deal with a different organization depending on which direction the IP addresses flow? Supposed it was space ARIN assigned the DoD? -- TTFN, patrick From iljitsch at muada.com Fri Feb 18 05:04:57 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 18 Feb 2011 12:04:57 +0100 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <921881.85954.qm@web114701.mail.gq1.yahoo.com> References: <921881.85954.qm@web114701.mail.gq1.yahoo.com> Message-ID: On 18 feb 2011, at 9:24, Zed Usser wrote: > Basic Internet services will work (web browsing, email, Facebook, Youtube,...), but: > - Less torrenting > - Less Netflix watching > - Less FTP downloads > - Less video streaming in general (webcams, etc.) You forget: - no IPv6 tunnels Deploying NAT444 without IPv6 is a very bad thing. From iljitsch at muada.com Fri Feb 18 05:16:09 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 18 Feb 2011 12:16:09 +0100 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <33743D00-0DA9-4580-BD38-5037FE16CBAF@ianai.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <8B0FDF52-A36D-46E8-9408-3C1A4C5D30CD@delong.com> <868vxepnad.fsf@seastrom.com> <3155646E-CC94-4242-83C6-B16C378D42BA@muada.com> <33743D00-0DA9-4580-BD38-5037FE16CBAF@ianai.net> Message-ID: <4B39A00D-EF5A-41D3-980F-85FDBB32B080@muada.com> On 18 feb 2011, at 12:00, Patrick W. Gilmore wrote: >> How can they "return" stuff to ARIN that they got from IANA in the first place? >> ARIN seems to be getting the very long end of the legacy stick. > But last time I checked, the United States is in the ARIN region. And ARIN did not exist when the US DoD got its space. (In fact, I do believe the reason "IP space" exists is because the DoD paid someone to come up with the idea? :) True, but how is all of that relevant? > If the US DoD wants more space, it has to ask ARIN, right? Are you suggesting it should deal with a different organization depending on which direction the IP addresses flow? > Supposed it was space ARIN assigned the DoD? Policies like giving each RIR one of the final five /8s were carefully created to give each RIR equal access to address space. Automatically giving legacy space to the RIR for the region that the holder of the legacy space is in is incompatible with that, and means that ARIN will get virtually all of it. To me, it seems both natural and fair that legacy space (especially /8s) is returned to IANA and then redistributed over the RIRs. By the way, IANA only deals in /8s. However, a lot of people got legacy /16s or other non-/8 sizes, so some /8s that are marked "legacy" actually contain a lot of unused space. Each of those /8 is "administered" by a RIR, but it's unclear (to me at least) whether that means that RIR gets to give out that space in its region or not. And if not, what is supposed to happen with this space. It's a significant amount, about half the size of the class E space: RIR Administerd by Delegated Free afrinic 33.55 M 8.71 M 24.85 M apnic 100.66 M 77.95 M 22.72 M arin 671.09 M 592.04 M 79.05 M ripencc 67.11 M 63.01 M 4.10 M From ayourtch at gmail.com Fri Feb 18 05:33:18 2011 From: ayourtch at gmail.com (Andrew Yourtchenko) Date: Fri, 18 Feb 2011 12:33:18 +0100 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <921881.85954.qm@web114701.mail.gq1.yahoo.com> References: <9F8063EB-C9A3-444D-B9CB-7CA12BEE335E@puck.nether.net> <921881.85954.qm@web114701.mail.gq1.yahoo.com> Message-ID: On Fri, Feb 18, 2011 at 9:24 AM, Zed Usser wrote: > Now correct me if I'm wrong, but isn't some kind of NAT/PAT going to be required to join the IPv4 and IPv6 > domains in all foreseeable futures? If so, aren't we going to have to deal with these issues in any case? I'd compare it with borrowing some money: When you make NAT64 to reach from IPv6 to IPv4, you are borrowing the money to build a new house. When you make NAT444, you borrow the money to repay the debt you made by borrowing the previous month. Both are borrowing. Depending on the circumstances you may need both. cheers, andrew From tore.anderson at redpill-linpro.com Fri Feb 18 05:36:19 2011 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Fri, 18 Feb 2011 12:36:19 +0100 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <4B39A00D-EF5A-41D3-980F-85FDBB32B080@muada.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <8B0FDF52-A36D-46E8-9408-3C1A4C5D30CD@delong.com> <868vxepnad.fsf@seastrom.com> <3155646E-CC94-4242-83C6-B16C378D42BA@muada.com> <33743D00-0DA9-4580-BD38-5037FE16CBAF@ianai.net> <4B39A00D-EF5A-41D3-980F-85FDBB32B080@muada.com> Message-ID: <4D5E59B3.9020307@redpill-linpro.com> * Iljitsch van Beijnum > By the way, IANA only deals in /8s. However, a lot of people got > legacy /16s or other non-/8 sizes, so some /8s that are marked > "legacy" actually contain a lot of unused space. Each of those /8 is > "administered" by a RIR, but it's unclear (to me at least) whether > that means that RIR gets to give out that space in its region or not. The unused space in the ERX blocks were divided evenly between the RIRs a couple of years ago, see: http://www.icann.org/correspondence/wilson-to-conrad-28jan08-en.pdf http://bgp.potaroo.net/stats/nro/various.html I believe ?administered by? simply means that the RIR is the one providing reverse DNS services for the block in question. Regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27 From iljitsch at muada.com Fri Feb 18 05:54:46 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 18 Feb 2011 12:54:46 +0100 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <4D5E59B3.9020307@redpill-linpro.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <8B0FDF52-A36D-46E8-9408-3C1A4C5D30CD@delong.com> <868vxepnad.fsf@seastrom.com> <3155646E-CC94-4242-83C6-B16C378D42BA@muada.com> <33743D00-0DA9-4580-BD38-5037FE16CBAF@ianai.net> <4B39A00D-EF5A-41D3-980F-85FDBB32B080@muada.com> <4D5E59B3.9020307@redpill-linpro.com> Message-ID: <446C995A-48AB-4D75-B22E-20A00C6C45BB@muada.com> On 18 feb 2011, at 12:36, Tore Anderson wrote: >> Each of those /8 is >> "administered" by a RIR, but it's unclear (to me at least) whether >> that means that RIR gets to give out that space in its region or not. > The unused space in the ERX blocks were divided evenly between the RIRs > a couple of years ago, see: > http://www.icann.org/correspondence/wilson-to-conrad-28jan08-en.pdf "Please find attached a summary spreadsheet (Excel format) providing the agreed distribution of administrative responsibility" This still leaves the question of which RIR gets to give out which parts of the unused legacy space unanswered. From tore.anderson at redpill-linpro.com Fri Feb 18 05:59:30 2011 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Fri, 18 Feb 2011 12:59:30 +0100 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <446C995A-48AB-4D75-B22E-20A00C6C45BB@muada.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <8B0FDF52-A36D-46E8-9408-3C1A4C5D30CD@delong.com> <868vxepnad.fsf@seastrom.com> <3155646E-CC94-4242-83C6-B16C378D42BA@muada.com> <33743D00-0DA9-4580-BD38-5037FE16CBAF@ianai.net> <4B39A00D-EF5A-41D3-980F-85FDBB32B080@muada.com> <4D5E59B3.9020307@redpill-linpro.com> <446C995A-48AB-4D75-B22E-20A00C6C45BB@muada.com> Message-ID: <4D5E5F22.6010703@redpill-linpro.com> * Iljitsch van Beijnum >> http://www.icann.org/correspondence/wilson-to-conrad-28jan08-en.pdf > >> > "Please find attached a summary spreadsheet (Excel format) providing > the agreed distribution of administrative responsibility" Hit your Page Down button a couple of times, it's included right there in the PDF. Regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27 From iljitsch at muada.com Fri Feb 18 06:01:20 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 18 Feb 2011 13:01:20 +0100 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <4D5E5F22.6010703@redpill-linpro.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <8B0FDF52-A36D-46E8-9408-3C1A4C5D30CD@delong.com> <868vxepnad.fsf@seastrom.com> <3155646E-CC94-4242-83C6-B16C378D42BA@muada.com> <33743D00-0DA9-4580-BD38-5037FE16CBAF@ianai.net> <4B39A00D-EF5A-41D3-980F-85FDBB32B080@muada.com> <4D5E59B3.9020307@redpill-linpro.com> <446C995A-48AB-4D75-B22E-20A00C6C45BB@muada.com> <4D5E5F22.6010703@redp! ill-linpro.com> Message-ID: <1A78375F-875A-46F6-A792-120F9A58024F@muada.com> On 18 feb 2011, at 12:59, Tore Anderson wrote: > Hit your Page Down button a couple of times, it's included right there > in the PDF. I don't see anything that clears this up. From eugen at leitl.org Fri Feb 18 06:26:53 2011 From: eugen at leitl.org (Eugen Leitl) Date: Fri, 18 Feb 2011 13:26:53 +0100 Subject: BGP (in)security makes the AP wire In-Reply-To: <4BE6E4FA.6000308@bogus.com> References: <308599F2-201F-4C34-862B-4E4B6BF4C875@cs.columbia.edu> <4BE6DAC6.8080204@cox.net> <20100509163047.GN1964@leitl.org> <4BE6E4FA.6000308@bogus.com> Message-ID: <20110218122652.GG23560@leitl.org> On Sun, May 09, 2010 at 09:38:18AM -0700, Joel Jaeggli wrote: > geographic location doesn't map to topology In LEO satellite constellations and mesh wireless it typically does. When bootstrapping a global mesh, one could use VPN tunnels over Internet to emulate long-distance links initially. Eben Moglen recently proposed a FreedomBox intitiative, using ARM wall warts to build an open source cloud with an anonymizing layer. Many of these come with 802.11x radio built-in. If this project ever happens, it could become a basis for end-user owned infrastructure. Long-range WiFi can compete with LR fiber in principle, though at a tiny fraction of throughput. > > Presumably, one could prototype something simple and cheap at L2 level > > with WGS 84->MAC (about ~m^2 resolution), custom switch firmware and GBIC > > for longish (1-70 km) distances, but without a mesh it won't work. The local 64 bit part of IPv6 has enough space for global ~2 m resolution, including altitide (24, 24, 16 bit). With DAD and fuzzing lowest significant bits address collisions could be prevented reliably. Central authority and decentralism can co-exist. > > > >> I'm sorry, but I am very afraid of "Central Authority". > > > -- Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE From patrick at ianai.net Fri Feb 18 06:59:03 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 18 Feb 2011 07:59:03 -0500 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <4B39A00D-EF5A-41D3-980F-85FDBB32B080@muada.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <8B0FDF52-A36D-46E8-9408-3C1A4C5D30CD@delong.com> <868vxepnad.fsf@seastrom.com> <3155646E-CC94-4242-83C6-B16C378D42BA@muada.com> <33743D00-0DA9-4580-BD38-5037FE16CBAF@ianai.net> <4B39A00D-EF5A-41D3-980F-85FDBB32B080@muada.com> Message-ID: <56E5A977-FB84-4DB1-80E4-3CAF202D525B@ianai.net> On Feb 18, 2011, at 6:16 AM, Iljitsch van Beijnum wrote: > On 18 feb 2011, at 12:00, Patrick W. Gilmore wrote: > >>> How can they "return" stuff to ARIN that they got from IANA in the first place? > >>> ARIN seems to be getting the very long end of the legacy stick. > >> But last time I checked, the United States is in the ARIN region. And ARIN did not exist when the US DoD got its space. (In fact, I do believe the reason "IP space" exists is because the DoD paid someone to come up with the idea? :) > > True, but how is all of that relevant? The first seems relevant because it was not possible for the US DoD to get space from ARIN. It's not like they chose to go around ARIN. The second seems relevant because ARIN is the successor, created by the IANA (Dr. Postel himself) specifically to take over the duties of address management in the geographic region where the DoD exists. When someone comes up with an idea (or pays someone to come up with an idea), they tend to get to use that idea before others. If you honestly cannot fathom why that is relevant, then I am not going to attempt to explain it to you. Now that I've answered your question, mind if I ask why you are asking? Or do you just prefer to troll? >> If the US DoD wants more space, it has to ask ARIN, right? Are you suggesting it should deal with a different organization depending on which direction the IP addresses flow? > >> Supposed it was space ARIN assigned the DoD? > > Policies like giving each RIR one of the final five /8s were carefully created to give each RIR equal access to address space. Automatically giving legacy space to the RIR for the region that the holder of the legacy space is in is incompatible with that, and means that ARIN will get virtually all of it. Then perhaps you should work through the process to change that? > To me, it seems both natural and fair that legacy space (especially /8s) is returned to IANA and then redistributed over the RIRs. It may seem that way to many. Posting it to NANOG is not going to help you achieve what you deem to be fair & natural. -- TTFN, patrick From arturo.servin at gmail.com Fri Feb 18 07:10:22 2011 From: arturo.servin at gmail.com (Arturo Servin) Date: Fri, 18 Feb 2011 11:10:22 -0200 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <4D5E59B3.9020307@redpill-linpro.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <8B0FDF52-A36D-46E8-9408-3C1A4C5D30CD@delong.com> <868vxepnad.fsf@seastrom.com> <3155646E-CC94-4242-83C6-B16C378D42BA@muada.com> <33743D00-0DA9-4580-BD38-5037FE16CBAF@ianai.net> <4B39A00D-EF5A-41D3-980F-85FDBB32B080@muada.com> <4D5E59B3.9020307@redpill-linpro.com> Message-ID: <871A63DD-E52D-4125-BFD5-52A974BE8C71@gmail.com> Iljitsch, In deed there were ERX unused space that were divided among RIRs, I think it is referred as "various ERX" (pointed out by Tore). http://bgp.potaroo.net/stats/nro/various.html There were also ERX space transferred from ARIN DB (used to be in InterNIC's) to RIRs because legacy holders were in the RIR region: http://www.lacnic.net/en/erx.html When you talk about "unused" legacy space are you talking about the "various" space or to the legacy space that is currently assigned but the holders just require part of it? Regards, -as On 18 Feb 2011, at 09:36, Tore Anderson wrote: > * Iljitsch van Beijnum > >> By the way, IANA only deals in /8s. However, a lot of people got >> legacy /16s or other non-/8 sizes, so some /8s that are marked >> "legacy" actually contain a lot of unused space. Each of those /8 is >> "administered" by a RIR, but it's unclear (to me at least) whether >> that means that RIR gets to give out that space in its region or not. > > The unused space in the ERX blocks were divided evenly between the RIRs > a couple of years ago, see: > > http://www.icann.org/correspondence/wilson-to-conrad-28jan08-en.pdf > http://bgp.potaroo.net/stats/nro/various.html > > I believe ?administered by? simply means that the RIR is the one > providing reverse DNS services for the block in question. > > Regards, > -- > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com > Tel: +47 21 54 41 27 From neil at tonal.clara.co.uk Fri Feb 18 07:42:14 2011 From: neil at tonal.clara.co.uk (Neil Harris) Date: Fri, 18 Feb 2011 13:42:14 +0000 Subject: BGP (in)security makes the AP wire In-Reply-To: <20110218122652.GG23560@leitl.org> References: <308599F2-201F-4C34-862B-4E4B6BF4C875@cs.columbia.edu> <4BE6DAC6.8080204@cox.net> <20100509163047.GN1964@leitl.org> <4BE6E4FA.6000308@bogus.com> <20110218122652.GG23560@leitl.org> Message-ID: <4D5E7736.2050508@tonal.clara.co.uk> On 18/02/11 12:26, Eugen Leitl wrote: > On Sun, May 09, 2010 at 09:38:18AM -0700, Joel Jaeggli wrote: > >> geographic location doesn't map to topology > In LEO satellite constellations and mesh wireless it typically does. > When bootstrapping a global mesh, one could use VPN tunnels over > Internet to emulate long-distance links initially. > > Eben Moglen recently proposed a FreedomBox intitiative, using ARM > wall warts to build an open source cloud with an anonymizing layer. > Many of these come with 802.11x radio built-in. If this project > ever happens, it could become a basis for end-user owned > infrastructure. Long-range WiFi can compete with LR fiber > in principle, though at a tiny fraction of throughput. > "Tiny fraction" is putting it mildly. I once considered starting up a low-infrastructure wireless ISP using mesh radio based on wifi radio technology adapted to work in licensed bands. If you work out the numbers, the bandwidth you get in any substantial deployment is pitiful compared to technologies like DSL and cable modems, let alone fiber. New technologies such as distributed space-time multipath coding on the wireless side, and multipath network coding on the bitstream side, look like the way forward on this, but these are brand new, and still the subject of research -- you certainly can't just hot-wire these onto wifi hardware. >>> Presumably, one could prototype something simple and cheap at L2 level >>> with WGS 84->MAC (about ~m^2 resolution), custom switch firmware and GBIC >>> for longish (1-70 km) distances, but without a mesh it won't work. > The local 64 bit part of IPv6 has enough space for global ~2 m resolution, > including altitide (24, 24, 16 bit). With DAD and fuzzing lowest > significant bits address collisions could be prevented reliably. > > Central authority and decentralism can co-exist. Indeed. The fact that the usable bandwidth resulting from ad-hoc mesh wiki would be tiny compared to broadband connections doesn't mean this sort of thing isn't worth trying: a few tens of kilobits a second is plenty for speech, and even a few hundred bits per second useful for basic text messaging. Given that the cost of doing this is almost zero, since only software is required to implement it on any modern wifi/GPS equipped mobile hardware, this seems like a great thing to have in the general portfolio of networking technologies: having something like this available could be invaluable in disaster/crisis situations. -- Neil From iljitsch at muada.com Fri Feb 18 08:07:07 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 18 Feb 2011 15:07:07 +0100 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <871A63DD-E52D-4125-BFD5-52A974BE8C71@gmail.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <8B0FDF52-A36D-46E8-9408-3C1A4C5D30CD@delong.com> <868vxepnad.fsf@seastrom.com> <3155646E-CC94-4242-83C6-B16C378D42BA@muada.com> <33743D00-0DA9-4580-BD38-5037FE16CBAF@ianai.net> <4B39A00D-EF5A-41D3-980F-85FDBB32B080@muada.com> <4D5E59B3.9020307@redpill-linpro.com> <871A63DD-E52D-4125-BFD5-52A974BE8C71@gmail.com> Message-ID: On 18 feb 2011, at 14:10, Arturo Servin wrote: > When you talk about "unused" legacy space are you talking about the "various" space or to the legacy space that is currently assigned but the holders just require part of it? Legacy space (A) = all the /8s marked as "legacy" by IANA. Used legacy space (B): addresses allocated/assigned according to one of the RIRs which falls within A. Unused legacy space (C): A - B. Examples: lots of class B networks, either they were never given out or they were returned. And 45/8 minus 45.0.0.0/15. From owen at delong.com Fri Feb 18 08:27:12 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 18 Feb 2011 06:27:12 -0800 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <921881.85954.qm@web114701.mail.gq1.yahoo.com> References: <921881.85954.qm@web114701.mail.gq1.yahoo.com> Message-ID: On Feb 18, 2011, at 12:24 AM, Zed Usser wrote: > On Thu, Feb 10, 2011 at 14:17, Chris Grundemann wrote: > >> In case you have not already found this: >> http://tools.ietf.org/html/draft-donley-nat444-impacts-01 > > There's a bit of critique on the NAT444 document on the BEHAVE IETF WG list. > > "draft-donley-nat444-impacts-01 is somewhat misleading. It claims to analyze NAT444, but it really analyzes what fails when two problems occur: (a) port forwarding isn't configured and (b) UPnP is unavailable or is broken. Several architectures share those two problems: > > * NAT444 (NAPT44 in the home + NAPT44 in the carrier's network) > * LSN (NAPT44 in the carrier's network, without a NAPT44 in the home) > * DS-Lite (which is an LSN / NAPT44 in the carrier's network) > * stateful NAT64" > I don't think the draft makes any attempt to claim that the problems are unique to NAT444, so, the above, while technically accurate isn't particulrarly meaningful. > http://www.ietf.org/mail-archive/web/behave/current/msg09027.html > > Be that as it may and putting my devil's advocate hat on, aren't the unintended consequences of NAT444 a net win for ISPs? :) > I guess that depends on whether you like having customers or not. > Basic Internet services will work (web browsing, email, Facebook, Youtube,...), but: > - Less torrenting > - Less Netflix watching > - Less FTP downloads > - Less video streaming in general (webcams, etc.) > > You might take a hit on online gaming, but what else is there not to love? :) > + More support phone calls + More unhappy customers + More cancellations + Less revenue + More costs + CALEA joy > Your sales department / helpdesk might have a bit of hassle of trying to undestand / explain this new Intertubes to the suck^H^H^H^Hcustomers, but most of them won't care either way. > An interesting theory. > Now correct me if I'm wrong, but isn't some kind of NAT/PAT going to be required to join the IPv4 and IPv6 domains in all foreseeable futures? If so, aren't we going to have to deal with these issues in any case? > No, we need to move forward with IPv6 on all levels in order to reduce the need for these solutions. Joining the IPv4/IPv6 domains doesn't work out all that well and a dependency on doing so is broken in a number of ways, many of which are documented in the draft. Owen From matt.newsom at rackspace.com Fri Feb 18 08:30:56 2011 From: matt.newsom at rackspace.com (Matt Newsom) Date: Fri, 18 Feb 2011 14:30:56 +0000 Subject: Switch with 10 Gig and GRE support in hardware. Message-ID: <18886_1298039457_p1IEUpvU024871_93717E08238F7B4392FAD1F82A87FBD3365F2E87@SAT2EXD02.RACKSPACE.CORP> 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. Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse at rackspace.com, and delete the original message. Your cooperation is appreciated. From jeffrey.lyon at blacklotus.net Fri Feb 18 08:37:38 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 18 Feb 2011 09:37:38 -0500 Subject: Switch with 10 Gig and GRE support in hardware. In-Reply-To: <18886_1298039457_p1IEUpvU024871_93717E08238F7B4392FAD1F82A87FBD3365F2E87@SAT2EXD02.RACKSPACE.CORP> References: <18886_1298039457_p1IEUpvU024871_93717E08238F7B4392FAD1F82A87FBD3365F2E87@SAT2EXD02.RACKSPACE.CORP> Message-ID: On Fri, Feb 18, 2011 at 9:30 AM, Matt Newsom 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. > > > Confidentiality Notice: This e-mail message (including any attached or > embedded documents) is intended for the exclusive and confidential use of the > individual or entity to which this message is addressed, and unless otherwise > expressly indicated, is confidential and privileged information of Rackspace. > Any dissemination, distribution or copying of the enclosed material is prohibited. > If you receive this transmission in error, please notify us immediately by e-mail > at abuse at rackspace.com, and delete the original message. > Your cooperation is appreciated. > > Yes, Juniper EX4500. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From owen at delong.com Fri Feb 18 08:48:12 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 18 Feb 2011 06:48:12 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net><616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com><245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com><8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at><09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com><54CC2B0D-EAE0-4B79-AF19-20BBD233A581@istaff.org> <38565.1297953177@localhost> <5A6D953473350C4B9995546AFE9939EE0BC13BB8@RWC-EX1.corp.seven.com> Message-ID: On Feb 18, 2011, at 2:50 AM, Iljitsch van Beijnum wrote: > On 17 feb 2011, at 17:35, George Bonser wrote: > >> Considering v4 is likely to be around for another decade or two, getting >> Class E into general use seems easy enough to do. > > You really think people will be communicating over the public internet using IPv4 in 2031? > For some minimal definition of two endpoints both of which are IPv4, sure. It'll be across 4in6 tunnels or something like that, but, I'm sure there will still be die-hard legacy systems doing that in 2031. As to whether IPv4 will still be generally routed on the internet? I actually suspect that will end before 2021 and might start winding down as early as 2014. Many people think that is overly optimistic, but, I look at the scaling problems IPv4 routing will face in a post depletion world and I suspect the motivations to deprecate IPv4 will come on strong and fast as a result. Before you ask, no, I'm not going to promise to eat my column. (Hi Bob!) > It will take a long time before the first people are going to turn off IPv4, but once that starts there will be no stopping it and IPv4 will be gone very, very quickly. > Define long time. I'm thinking 3 to 5 years, maybe. > (Of course there will be legacy stuff, just like some people are still running IPX or AppleTalk today. I'm talking about the public internet here.) > > Today people are complaining how annoying it is to have to learn new things to be able to run IPv6, but that doesn't compare to how annoying it is to have to learn OLD things to keep running a protocol that is way past its sell by date. I still need to teach class A/B/C despite the fact that CIDR is old enough to drink in most countries because without knowing that you can't configure a Cisco router. That's annoying now. Think about how insane that will be in the 2020s when the notion of requesting IPv4 addresses from an RIR is ancient history and young people don't know any better than having a /64 on every LAN that is big enough to connect all ethernet NICs ever made. > I am not convinced you can't configure a cisco router without knowing about classful addressing. True, you will have to understand classful routing for the way Cisco displays routes to make sense to you, but, if you don't, all that happens is you wonder why they display things so strangely, grouping these octet-bounded collections of routes. Owen From owen at delong.com Fri Feb 18 08:51:10 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 18 Feb 2011 06:51:10 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <3155646E-CC94-4242-83C6-B16C378D42BA@muada.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <8B0FDF52-A36D-46E8-9408-3C1A4C5D30CD@delong.com> <868vxepnad.fsf@seastrom.com> <3155646E-CC94-4242-83C6-B16C378D42BA@muada.com> Message-ID: <83AC307C-5236-404B-9807-59EC92E615A0@delong.com> On Feb 18, 2011, at 2:54 AM, Iljitsch van Beijnum wrote: > On 17 feb 2011, at 18:57, John Curran wrote: > >> Actually, as I have noted before, the US DoD has contractually >> agreed to return to ARIN unneeded IPv4 address space if/when >> such becomes available, so that it may be used by the Internet >> community. > > How can they "return" stuff to ARIN that they got from IANA in the first place? > > ARIN seems to be getting the very long end of the legacy stick. The same way people have returned to ARIN resources obtained from: SRI Internic Network Solutions Internic ARIN is the successor registry and maintains the whois and in-addr data for the blocks. An attempt to return them to IANA directly would probably be met with a "go return these to ARIN" response. I don't know that for sure, but, that is what I would expect. As to ARIN getting the long end of the legacy stick, well, the ARIN region got the long end of the costs of developing and making the early deployments of the Internet, so, many of the legacy allocations and assignments are within the ARIN region. This is simple historical fact. I'm not sure why anyone feels we should attempt to revise history. Owen From owen at delong.com Fri Feb 18 08:55:49 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 18 Feb 2011 06:55:49 -0800 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: <4B39A00D-EF5A-41D3-980F-85FDBB32B080@muada.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <09599885-AF04-4C1A-B84F-9F1AC393E13F@muada.com> <8B0FDF52-A36D-46E8-9408-3C1A4C5D30CD@delong.com> <868vxepnad.fsf@seastrom.com> <3155646E-CC94-4242-83C6-B16C378D42BA@muada.com> <33743D00-0DA9-4580-BD38-5037FE16CBAF@ianai.net> <4B39A00D-EF5A-41D3-980F-85FDBB32B080@muada.com> Message-ID: On Feb 18, 2011, at 3:16 AM, Iljitsch van Beijnum wrote: > On 18 feb 2011, at 12:00, Patrick W. Gilmore wrote: > >>> How can they "return" stuff to ARIN that they got from IANA in the first place? > >>> ARIN seems to be getting the very long end of the legacy stick. > >> But last time I checked, the United States is in the ARIN region. And ARIN did not exist when the US DoD got its space. (In fact, I do believe the reason "IP space" exists is because the DoD paid someone to come up with the idea? :) > > True, but how is all of that relevant? > >> If the US DoD wants more space, it has to ask ARIN, right? Are you suggesting it should deal with a different organization depending on which direction the IP addresses flow? > >> Supposed it was space ARIN assigned the DoD? > > Policies like giving each RIR one of the final five /8s were carefully created to give each RIR equal access to address space. Automatically giving legacy space to the RIR for the region that the holder of the legacy space is in is incompatible with that, and means that ARIN will get virtually all of it. > > To me, it seems both natural and fair that legacy space (especially /8s) is returned to IANA and then redistributed over the RIRs. > > By the way, IANA only deals in /8s. However, a lot of people got legacy /16s or other non-/8 sizes, so some /8s that are marked "legacy" actually contain a lot of unused space. Each of those /8 is "administered" by a RIR, but it's unclear (to me at least) whether that means that RIR gets to give out that space in its region or not. And if not, what is supposed to happen with this space. It's a significant amount, about half the size of the class E space: > > RIR Administerd by Delegated Free > > afrinic 33.55 M 8.71 M 24.85 M > apnic 100.66 M 77.95 M 22.72 M > arin 671.09 M 592.04 M 79.05 M > ripencc 67.11 M 63.01 M 4.10 M > To the best of my knowledge, any RIR is free to allocate or assign any space it administers according to the policies set by that RIRs policy development process. If you feel that legacy resources returned to ARIN should be fed back to IANA, you are welcome to submit an appropriate policy to the ARIN policy development process in order to encourage such an action. Absent such a policy, I think your odds of achieving what you consider natural and fair are limited. I think that what is considered natural and fair by some is not considered so by others. Owen From owen at delong.com Fri Feb 18 08:59:09 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 18 Feb 2011 06:59:09 -0800 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: References: <9F8063EB-C9A3-444D-B9CB-7CA12BEE335E@puck.nether.net> <921881.85954.qm@web114701.mail.gq1.yahoo.com> Message-ID: <2CF5E5C3-4E51-4D63-BDD3-CBFD81948ACB@delong.com> On Feb 18, 2011, at 3:33 AM, Andrew Yourtchenko wrote: > On Fri, Feb 18, 2011 at 9:24 AM, Zed Usser wrote: > >> Now correct me if I'm wrong, but isn't some kind of NAT/PAT going to be required to join the IPv4 and IPv6 >> domains in all foreseeable futures? If so, aren't we going to have to deal with these issues in any case? > > I'd compare it with borrowing some money: > > When you make NAT64 to reach from IPv6 to IPv4, you are borrowing the > money to build a new house. > When you make NAT444, you borrow the money to repay the debt you made > by borrowing the previous month. > > Both are borrowing. > > Depending on the circumstances you may need both. > > cheers, > andrew If you are in a circumstance where you need to borrow money this month to repay your debt from last month, then, generally, you are on the fast track to bankruptcy court or a congressional investigation, perhaps both, depending on the size of debt snowball you are able to build. In the first case, you borrow money to leverage equity and there is a reasonable chance that by the time you pay off the loan, the value of what you built exceeds the amount borrowed. In the second case, you end up in a lather-rinse-repeat process where your debt load continues to grow and grow until it overpowers you. It's a good analogy, but, the second form of borrowing is far worse than the first. Owen From zzuser at yahoo.com Fri Feb 18 09:34:51 2011 From: zzuser at yahoo.com (Zed Usser) Date: Fri, 18 Feb 2011 07:34:51 -0800 (PST) Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: Message-ID: <398436.89934.qm@web114716.mail.gq1.yahoo.com> --- On Fri, 2/18/11, Owen DeLong wrote: > > Now correct me if I'm wrong, but isn't some kind of > NAT/PAT going to be required to join the IPv4 and IPv6 > domains in all foreseeable futures? If so, aren't we going > to have to deal with these issues in any case? > > > No, we need to move forward with IPv6 on all levels in > order to reduce the need for these solutions. Reduce, yes. Remove, no. Without a global cutoff date for the IPv6 transition, it's not like IPv4 is going to disappear overnight. Furthermore, without any IPv4/IPv6 translation, the first IPv6 only networks are going to be awfully lonely. > Joining the IPv4/IPv6 domains doesn't work out all that > well and a dependency on doing so is > broken in a number of ways, many of which are documented in > the draft. We agree that IPv4/IPv6 domain interoperability is broken, but it's not like we can ignore the issue. So, unless I'm very much mistaken, the NAT/PAT issues are going to have to be dealt with. Or do you propose an alternative solution? Please note that this is not an anti-IPv6 stance. To me it looks like the problems plaguing NAT444 need to be solved just to make IPv4 and IPv6 co-exist. Perhaps not the very same problems, but similar NAT/PAT problems in any case. Please do tell me I'm wrong. Bonus points for explaining why I am wrong or how the IPv4/IPv6 thing is to be solved without NAT/PAT. - Zed From owen at delong.com Fri Feb 18 10:05:45 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 18 Feb 2011 08:05:45 -0800 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <398436.89934.qm@web114716.mail.gq1.yahoo.com> References: <398436.89934.qm@web114716.mail.gq1.yahoo.com> Message-ID: <45BF34F3-5720-4E49-BD82-CA74336AC9B4@delong.com> On Feb 18, 2011, at 7:34 AM, Zed Usser wrote: > --- On Fri, 2/18/11, Owen DeLong wrote: > >>> Now correct me if I'm wrong, but isn't some kind of >> NAT/PAT going to be required to join the IPv4 and IPv6 >> domains in all foreseeable futures? If so, aren't we going >> to have to deal with these issues in any case? >>> >> No, we need to move forward with IPv6 on all levels in >> order to reduce the need for these solutions. > Reduce, yes. Remove, no. Without a global cutoff date for the IPv6 transition, it's not like IPv4 is going to disappear overnight. Furthermore, without any IPv4/IPv6 translation, the first IPv6 only networks are going to be awfully lonely. > That depends on the number of IPv4 only networks vs. dual stack networks when that happens. >> Joining the IPv4/IPv6 domains doesn't work out all that >> well and a dependency on doing so is >> broken in a number of ways, many of which are documented in >> the draft. > We agree that IPv4/IPv6 domain interoperability is broken, but it's not like we can ignore the issue. So, unless I'm very much mistaken, the NAT/PAT issues are going to have to be dealt with. Or do you propose an alternative solution? > Dual stacking all the IPv4 networks is the alternative solution. Initially it will be the IPv6 only users that are lonely. Relatively quickly, it will be the IPv4 only networks that are lonely as the bulk of users will, I suspect, become IPv6 preferred relatively quickly once there is no more IPv4 at the RIR level. > Please note that this is not an anti-IPv6 stance. To me it looks like the problems plaguing NAT444 need to be solved just to make IPv4 and IPv6 co-exist. Perhaps not the very same problems, but similar NAT/PAT problems in any case. Please do tell me I'm wrong. Bonus points for explaining why I am wrong or how the IPv4/IPv6 thing is to be solved without NAT/PAT. > I think that effort spent trying to solve those problems is better spent moving existing IPv4 things forward to dual stack. You only need to solve those problems to the extent that there are meaningful things still trapped in an IPv4-only world. Move them to dual stack and the problem goes away. Owen From jsw at inconcepts.biz Fri Feb 18 10:13:09 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Fri, 18 Feb 2011 11:13:09 -0500 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <398436.89934.qm@web114716.mail.gq1.yahoo.com> References: <398436.89934.qm@web114716.mail.gq1.yahoo.com> Message-ID: On Fri, Feb 18, 2011 at 10:34 AM, Zed Usser wrote: > ?Reduce, yes. Remove, no. Without a global cutoff date for the IPv6 transition, it's not like IPv4 is going to disappear overnight. Furthermore, without any IPv4/IPv6 translation, the first IPv6 only networks are going to be awfully lonely. I suspect Google, Microsoft, and others have already figured out a beneficial (to everyone) way to monetize this. If I'm an ISP with working IPv6, and my competitor in a given region is an ISP without IPv6, I'd like to advertise to all the end-users of that ISP whenever they go to a search engine that sells ads. Since these search engine companies have figured out white-listing users into "good IPv6," it's no great leap to suggest that they'll eventually black-list IPv4 users into "bad," and tie that into their advertising system for ISPs to purchase nicely-targeted banners/links. If my ISP is reading this, please tell both your residential and business technical and sales departments to come up with a better answer than "we are not going to support IPv6 because that's only for ISPs that run out of IPv4." Otherwise, I'd bet Google will be more than willing to let your competitors give customers a different answer in the near future! -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From lowen at pari.edu Fri Feb 18 10:21:44 2011 From: lowen at pari.edu (Lamar Owen) Date: Fri, 18 Feb 2011 11:21:44 -0500 Subject: quietly.... In-Reply-To: <11445089.286.1297832266043.JavaMail.root@benjamin.baylink.com> References: <11445089.286.1297832266043.JavaMail.root@benjamin.baylink.com> Message-ID: <201102181121.44433.lowen@pari.edu> On Tuesday, February 15, 2011 11:57:46 pm Jay Ashworth wrote: > > From: "Michael Dillon" > > This sounds a lot like bellhead speak. > As a long time fan of David Isen, I almost fell off my chair laughing at > that, Michael: Bell *wanted* things -- specifically the network -- smart > and complicated; Isen's POV, which got him... well, I don't know if > "laughed out of" AT&T is the right way to phrase it, but it's close enough, > was: > > Stupid network; smart endpoints. The bellhead PoV isn't wrong; it's just different. Stupid endpoints tend to be more usable when such usage matters, such as emergencies (power outages, need to call 911, etc). The problem is we're in neither of the two worlds at the moment; we're in between, with complex/smart networks (QoS, etc) and smart/complex endpoints. Which, IMO, is the worst of both worlds. Stupid network and smart endpoint: a smart endpoint user or said user's tech person has a chance to fully troubleshoot and correct issues; Smart network and stupid endpoint: net op tech has a chance to fully troubleshoot and correct issues; Smart network and smart endpoint: nobody can fully troubleshoot anything, and much fingerpointing and hilarity ensues.... From morrowc.lists at gmail.com Fri Feb 18 10:23:29 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 18 Feb 2011 11:23:29 -0500 Subject: BGP (in)security makes the AP wire In-Reply-To: <4D5E7736.2050508@tonal.clara.co.uk> References: <308599F2-201F-4C34-862B-4E4B6BF4C875@cs.columbia.edu> <4BE6DAC6.8080204@cox.net> <20100509163047.GN1964@leitl.org> <4BE6E4FA.6000308@bogus.com> <20110218122652.GG23560@leitl.org> <4D5E7736.2050508@tonal.clara.co.uk> Message-ID: On Fri, Feb 18, 2011 at 8:42 AM, Neil Harris wrote: > The fact that the usable bandwidth resulting from ad-hoc mesh wiki would be > tiny compared to broadband connections doesn't mean this sort of thing isn't > worth trying: a few tens of kilobits a second is plenty for speech, and even > a few hundred bits per second useful for basic text messaging. it seemed that the 'freedombox' was targeted at (or so I thought from the snippet I read) striking a blow against regimes that cut off network access during 'high stress' periods. A few kbps would still be better than nothing :) of course, a coffee grinder (or something more sophisticated that'd be available to the repressive regime du jour) can wipe out that few kbps easily enough as well. -chris From nanogwp at gmail.com Fri Feb 18 10:47:36 2011 From: nanogwp at gmail.com (Robert Lusby) Date: Fri, 18 Feb 2011 16:47:36 +0000 Subject: 123.45.67.89 Message-ID: --- Friday miscellaneous --- What can anyone tell me about IPv4: 123.45.67.89 ? Other than it's used by Samsung in Korea? Do they have any cool applications for it? Do you have, or know of any other "cherished" IPv4s? What do you use it for? Google DNS is a good example (4.4.4.4). From joelja at bogus.com Fri Feb 18 10:59:58 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 18 Feb 2011 08:59:58 -0800 Subject: 123.45.67.89 In-Reply-To: References: Message-ID: <4D5EA58E.1060907@bogus.com> normally ip addresses like that just attract additional unwanted traffic towards the advertised prefix... joel On 2/18/11 8:47 AM, Robert Lusby wrote: > --- Friday miscellaneous --- > > What can anyone tell me about IPv4: 123.45.67.89 ? > > Other than it's used by Samsung in Korea? Do they have any cool applications > for it? > > Do you have, or know of any other "cherished" IPv4s? What do you use it for? > > > Google DNS is a good example (4.4.4.4). > From MatlockK at exempla.org Fri Feb 18 11:01:45 2011 From: MatlockK at exempla.org (Matlock, Kenneth L) Date: Fri, 18 Feb 2011 10:01:45 -0700 Subject: 123.45.67.89 In-Reply-To: References: Message-ID: <4288131ED5E3024C9CD4782CECCAD2C70B9A347D@LMC-MAIL2.exempla.org> I'm not sure what all I'd do with it (besides have the hostname 'Jenny'), but I'd love to have 86.75.30.9.... Ken Matlock Network Analyst Exempla Healthcare (303) 467-4671 matlockk at exempla.org -----Original Message----- From: Robert Lusby [mailto:nanogwp at gmail.com] Sent: Friday, February 18, 2011 9:48 AM To: nanog at nanog.org Subject: 123.45.67.89 --- Friday miscellaneous --- What can anyone tell me about IPv4: 123.45.67.89 ? Other than it's used by Samsung in Korea? Do they have any cool applications for it? Do you have, or know of any other "cherished" IPv4s? What do you use it for? Google DNS is a good example (4.4.4.4). From mike-nanog at tiedyenetworks.com Fri Feb 18 11:09:06 2011 From: mike-nanog at tiedyenetworks.com (Mike) Date: Fri, 18 Feb 2011 09:09:06 -0800 Subject: 123.45.67.89 In-Reply-To: <4D5EA58E.1060907@bogus.com> References: <4D5EA58E.1060907@bogus.com> Message-ID: <4D5EA7B2.8020309@tiedyenetworks.com> On 02/18/2011 08:59 AM, Joel Jaeggli wrote: > normally ip addresses like that just attract additional unwanted traffic > towards the advertised prefix... > > Way back when ml.org was first doing dynamic dns, I tried it out and gave myself 'workgroup.ml.org'. All of a sudden, I started being bombarded with windows netbios traffic from all over creation (this was like 1998 or so, don't recall exactly but it was port 137 I think). I tried to get an explanation and to divine why all of a sudden having 'workgroup.ml.org' made me a target, but I never got to the truth of it. The closest I came simply had to do with the default 'wrokgroup' name of windows 95 machines and something to do with dns/netbios resolution (bug?). It looked like it was stripping dots a little too agressively but then it's been many years and I don't do windows. To this day I wonder seriously if 'workgroup.com' or variations had or has a similar problem.... Mike- From jco at direwolf.com Fri Feb 18 11:25:18 2011 From: jco at direwolf.com (John Orthoefer) Date: Fri, 18 Feb 2011 12:25:18 -0500 Subject: 123.45.67.89 In-Reply-To: References: Message-ID: <09F0D73D-66F0-4413-A099-7420F1E508E1@direwolf.com> Are you sure that Google has 4.4.4.4 and is running DNS on it? Google's website says 8.8.8.8 and 8.8.4.4. I know 4.2.2.1, 4.2.2.2, and 4.2.2.3 belong to Level3/Genuity/BBNPlanet and dig times-out on 4.4.4.4 for me. I would wonder more about 12.34.56.78 which belongs to AT&T. Doing 123.45.67.89 doesn't seem as natural. johno On Feb 18, 2011, at 11:47 AM, Robert Lusby wrote: > Google DNS is a good example (4.4.4.4). From richard.barnes at gmail.com Fri Feb 18 11:30:45 2011 From: richard.barnes at gmail.com (Richard Barnes) Date: Fri, 18 Feb 2011 12:30:45 -0500 Subject: 123.45.67.89 In-Reply-To: <4288131ED5E3024C9CD4782CECCAD2C70B9A347D@LMC-MAIL2.exempla.org> References: <4288131ED5E3024C9CD4782CECCAD2C70B9A347D@LMC-MAIL2.exempla.org> Message-ID: Looks like that's in a CEGETEL dynamic pool in France. Maybe you should sign up for their service? On Fri, Feb 18, 2011 at 12:01 PM, Matlock, Kenneth L wrote: > I'm not sure what all I'd do with it (besides have the hostname > 'Jenny'), but I'd love to have 86.75.30.9.... > > Ken Matlock > Network Analyst > Exempla Healthcare > (303) 467-4671 > matlockk at exempla.org > > > -----Original Message----- > From: Robert Lusby [mailto:nanogwp at gmail.com] > Sent: Friday, February 18, 2011 9:48 AM > To: nanog at nanog.org > Subject: 123.45.67.89 > > --- Friday miscellaneous --- > > What can anyone tell me about IPv4: 123.45.67.89 ? > > Other than it's used by Samsung in Korea? Do they have any cool > applications > for it? > > Do you have, or know of any other "cherished" IPv4s? What do you use it > for? > > > Google DNS is a good example (4.4.4.4). > > From eschoedler at viavale.com.br Fri Feb 18 11:40:02 2011 From: eschoedler at viavale.com.br (Eduardo Schoedler) Date: Fri, 18 Feb 2011 15:40:02 -0200 Subject: New transit tests Message-ID: Hi everyone. This is my first post here in Nanog. First of all, sorry my bad english -- I'm Brazilian. We are activating a new transit connection with 40 Mbps and I need to test it, but here in Brazil all the international transits are weak. I'm looking for a server that I can download/upload with full speed at New York or Miami, places that this transit have presence in some NAP/IXP (interconnections). Can be one url with a file of 1GB 'dd' generated file, but the server need to have this bandwidth avaliable. Someone can help me ? Thanks in advance. Regards, -- Eduardo Schoedler -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6506 bytes Desc: not available URL: From jonny at jonnynet.net Thu Feb 17 20:50:23 2011 From: jonny at jonnynet.net (Jonny Martin) Date: Fri, 18 Feb 2011 02:50:23 -0000 Subject: APNIC 30 - Call for Papers Message-ID: <8710F339-D12A-4D85-B3EE-30C65EA320CC@jonnynet.net> [Apologies for duplicates] ________________________________________________________________________ APNIC 30 - Call for Papers ________________________________________________________________________ The APNIC 30 Program Committee is now seeking presentations for APNIC 30 to be held at Gold Coast, Australia from 24 - 27 August 2010. We are looking for presentations that would suit technical conference sessions. Please submit proposals online at: http://submission.apnic.net/ KEY DATES --------- Call for Papers Opens: 8 June 2010 First Deadline for Submissions: 9 July 2010 First Draft Program Published: 16 July 2010 Final Deadline for Submissions: 6 August 2010 Final Program Published: 10 August 2010 Final Slides Received: 20 August 2010 PROGRAM MATERIAL ---------------- APNIC 30 Technical sessions will include presentations relevant to Internet Operations and Technologies. Here are some ideas for technical sessions relevant to APNIC 30: - IPv4 exhaustion / IPv6 deployment & operations - ISP, Peering, Carrier, and IXP services - Network security - Internet policy - Access and Transport Technologies - Content & Service Delivery If you have another idea, feel free to submit your proposal. CFP SUBMISSION -------------- Draft slides must be provided with all submissions. For work in progress, the most current information available at the time of submission is acceptable. Remember to submit early so you have plenty of time to arrange visas and travel! If you have questions, please email the Program Chair: pc-chair at apnic.net For more information about APNIC 30, please visit: http://meetings.apnic.net/30 Regards, Jonny Martin Chair, APNIC 30 Program Committee From gbonser at seven.com Fri Feb 18 12:14:04 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 18 Feb 2011 10:14:04 -0800 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6naysayer...) In-Reply-To: References: <398436.89934.qm@web114716.mail.gq1.yahoo.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13C26@RWC-EX1.corp.seven.com> > From: Jeff Wheeler > Sent: Friday, February 18, 2011 8:13 AM > To: nanog at nanog.org > Subject: Re: [arin-ppml] NAT444 rumors (was Re: Looking for an > IPv6naysayer...) > > > I suspect Google, Microsoft, and others have already figured out a > beneficial (to everyone) way to monetize this. If I'm an ISP with > working IPv6, and my competitor in a given region is an ISP without > IPv6, I'd like to advertise to all the end-users of that ISP whenever > they go to a search engine that sells ads. > One thing they can do, and I would live to see some popular destination site do this, is to say something like: "we have this really cool new thing we are rolling out but, sorry, it is available only via IPv6" or "we will continue supporting all of today's features on v4 but all new features will be rolled out on v6 only". That would result in eyeballs demanding access to that content and nothing drives innovation like customer demand does. From khelms at ispalliance.net Fri Feb 18 12:19:29 2011 From: khelms at ispalliance.net (Scott Helms) Date: Fri, 18 Feb 2011 13:19:29 -0500 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6naysayer...) In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13C26@RWC-EX1.corp.seven.com> References: <398436.89934.qm@web114716.mail.gq1.yahoo.com> <5A6D953473350C4B9995546AFE9939EE0BC13C26@RWC-EX1.corp.seven.com> Message-ID: <4D5EB831.5060403@ispalliance.net> Given that virtually all of the "popular" applications are ignorant of the underlying infrastructure I don't see this happening. Its simply too expensive to build something and not get it in front of as many eyeballs as possible even (perhaps especially) if your application is free (ad supported). We've only seen the large scale shift to applications really being mobile aware in the last few years. Anyone else remember when WAP was supposed to (and didn't) make a huge splash on mobile web use? > One thing they can do, and I would live to see some popular destination > site do this, is to say something like: > > "we have this really cool new thing we are rolling out but, sorry, it is > available only via IPv6" or "we will continue supporting all of today's > features on v4 but all new features will be rolled out on v6 only". > > That would result in eyeballs demanding access to that content and > nothing drives innovation like customer demand does. > > > > -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From morrowc.lists at gmail.com Fri Feb 18 12:20:48 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 18 Feb 2011 13:20:48 -0500 Subject: 123.45.67.89 In-Reply-To: References: Message-ID: On Fri, Feb 18, 2011 at 11:47 AM, Robert Lusby wrote: > --- Friday miscellaneous --- > > Google DNS is a good example (4.4.4.4). if you are getting DNS services from 4.4.4.4 you are not getting them from the-Google... From mikea at mikea.ath.cx Fri Feb 18 12:21:51 2011 From: mikea at mikea.ath.cx (mikea) Date: Fri, 18 Feb 2011 12:21:51 -0600 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6naysayer...) In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13C26@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13C26@RWC-EX1.corp.seven.com> Message-ID: <20110218182151.GA94617@mikea.ath.cx> On Fri, Feb 18, 2011 at 10:14:04AM -0800, George Bonser wrote: > > From: Jeff Wheeler > > Sent: Friday, February 18, 2011 8:13 AM > > To: nanog at nanog.org > > Subject: Re: [arin-ppml] NAT444 rumors (was Re: Looking for an > > IPv6naysayer...) > > > > > > I suspect Google, Microsoft, and others have already figured out a > > beneficial (to everyone) way to monetize this. If I'm an ISP with > > working IPv6, and my competitor in a given region is an ISP without > > IPv6, I'd like to advertise to all the end-users of that ISP whenever > > they go to a search engine that sells ads. > One thing they can do, and I would live to see some popular destination > site do this, is to say something like: > > "we have this really cool new thing we are rolling out but, sorry, it is > available only via IPv6" or "we will continue supporting all of today's > features on v4 but all new features will be rolled out on v6 only". > > That would result in eyeballs demanding access to that content and > nothing drives innovation like customer demand does. You never been told something like "We don't do (or stock) that because there's no demand for it! You know, you're the Nth person to ask about it today." I have, and many more times than merely once. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From cscora at apnic.net Fri Feb 18 12:27:23 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 19 Feb 2011 04:27:23 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201102181827.p1IIRNUE031085@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 19 Feb, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 347279 Prefixes after maximum aggregation: 156690 Deaggregation factor: 2.22 Unique aggregates announced to Internet: 171504 Total ASes present in the Internet Routing Table: 35911 Prefixes per ASN: 9.67 Origin-only ASes present in the Internet Routing Table: 30942 Origin ASes announcing only one prefix: 14976 Transit ASes present in the Internet Routing Table: 4969 Transit-only ASes present in the Internet Routing Table: 122 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 31 Max AS path prepend of ASN (36992) 29 Prefixes from unregistered ASNs in the Routing Table: 333 Unregistered ASNs in the Routing Table: 135 Number of 32-bit ASNs allocated by the RIRs: 1131 Prefixes from 32-bit ASNs in the Routing Table: 1 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 206 Number of addresses announced to Internet: 2396213440 Equivalent to 142 /8s, 211 /16s and 80 /24s Percentage of available address space announced: 64.6 Percentage of allocated address space announced: 64.6 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 88.0 Total number of prefixes smaller than registry allocations: 143943 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 85964 Total APNIC prefixes after maximum aggregation: 29310 APNIC Deaggregation factor: 2.93 Prefixes being announced from the APNIC address blocks: 82763 Unique aggregates announced from the APNIC address blocks: 35864 APNIC Region origin ASes present in the Internet Routing Table: 4330 APNIC Prefixes per ASN: 19.11 APNIC Region origin ASes announcing only one prefix: 1205 APNIC Region transit ASes present in the Internet Routing Table: 691 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 18 Number of APNIC addresses announced to Internet: 589615904 Equivalent to 35 /8s, 36 /16s and 211 /24s Percentage of available APNIC address space announced: 74.8 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 139812 Total ARIN prefixes after maximum aggregation: 71478 ARIN Deaggregation factor: 1.96 Prefixes being announced from the ARIN address blocks: 110606 Unique aggregates announced from the ARIN address blocks: 44958 ARIN Region origin ASes present in the Internet Routing Table: 14208 ARIN Prefixes per ASN: 7.78 ARIN Region origin ASes announcing only one prefix: 5412 ARIN Region transit ASes present in the Internet Routing Table: 1470 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 27 Number of ARIN addresses announced to Internet: 787367552 Equivalent to 46 /8s, 238 /16s and 70 /24s Percentage of available ARIN address space announced: 62.6 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 82060 Total RIPE prefixes after maximum aggregation: 46598 RIPE Deaggregation factor: 1.76 Prefixes being announced from the RIPE address blocks: 75405 Unique aggregates announced from the RIPE address blocks: 49074 RIPE Region origin ASes present in the Internet Routing Table: 15325 RIPE Prefixes per ASN: 4.92 RIPE Region origin ASes announcing only one prefix: 7790 RIPE Region transit ASes present in the Internet Routing Table: 2392 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 30 Number of RIPE addresses announced to Internet: 460222144 Equivalent to 27 /8s, 110 /16s and 110 /24s Percentage of available RIPE address space announced: 74.1 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 31784 Total LACNIC prefixes after maximum aggregation: 7387 LACNIC Deaggregation factor: 4.30 Prefixes being announced from the LACNIC address blocks: 30548 Unique aggregates announced from the LACNIC address blocks: 15959 LACNIC Region origin ASes present in the Internet Routing Table: 1429 LACNIC Prefixes per ASN: 21.38 LACNIC Region origin ASes announcing only one prefix: 436 LACNIC Region transit ASes present in the Internet Routing Table: 261 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 19 Number of LACNIC addresses announced to Internet: 80804992 Equivalent to 4 /8s, 208 /16s and 252 /24s Percentage of available LACNIC address space announced: 53.5 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 7445 Total AfriNIC prefixes after maximum aggregation: 1807 AfriNIC Deaggregation factor: 4.12 Prefixes being announced from the AfriNIC address blocks: 5842 Unique aggregates announced from the AfriNIC address blocks: 1841 AfriNIC Region origin ASes present in the Internet Routing Table: 437 AfriNIC Prefixes per ASN: 13.37 AfriNIC Region origin ASes announcing only one prefix: 132 AfriNIC Region transit ASes present in the Internet Routing Table: 95 Average AfriNIC Region AS path length visible: 5.4 Max AfriNIC Region AS path length visible: 31 Number of AfriNIC addresses announced to Internet: 21857280 Equivalent to 1 /8s, 77 /16s and 132 /24s Percentage of available AfriNIC address space announced: 32.6 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2307 9497 819 Korea Telecom (KIX) 7545 1628 302 87 TPG Internet Pty Ltd 4755 1417 634 163 TATA Communications formerly 17974 1409 475 29 PT TELEKOMUNIKASI INDONESIA 24560 1113 323 182 Bharti Airtel Ltd., Telemedia 9583 1044 77 488 Sify Limited 4808 1042 2142 294 CNCGROUP IP network: China169 17488 950 162 103 Hathway IP Over Cable Interne 18101 929 117 141 Reliance Infocom Ltd Internet 9829 898 763 42 BSNL National Internet Backbo Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3694 3855 261 bellsouth.net, inc. 4323 2623 1109 405 Time Warner Telecom 19262 1843 4955 283 Verizon Global Networks 1785 1784 697 131 PaeTec Communications, Inc. 20115 1527 1534 646 Charter Communications 6478 1510 295 78 AT&T Worldnet Services 18566 1433 320 158 Covad Communications 7018 1358 6674 878 AT&T WorldNet Services 2386 1297 553 934 AT&T Data Communications Serv 11492 1280 236 73 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6830 513 1764 318 UPC Distribution Services 9198 468 267 15 Kazakhtelecom Data Network Ad 34984 463 98 143 BILISIM TELEKOM 3292 447 1996 388 TDC Tele Danmark 8866 440 133 23 Bulgarian Telecommunication C 20940 412 99 318 Akamai Technologies European 3320 410 7620 357 Deutsche Telekom AG 8551 403 353 46 Bezeq International 702 396 1800 309 UUNET - Commercial IP service 3301 383 1822 341 TeliaNet Sweden Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1374 255 166 TVCABLE BOGOTA 8151 1342 2664 359 UniNet S.A. de C.V. 28573 1232 961 82 NET Servicos de Comunicao S.A 6503 1187 354 73 AVANTEL, S.A. 7303 898 463 142 Telecom Argentina Stet-France 14420 638 57 92 CORPORACION NACIONAL DE TELEC 22047 545 310 15 VTR PUNTO NET S.A. 3816 508 221 97 Empresa Nacional de Telecomun 7738 478 922 30 Telecomunicacoes da Bahia S.A 14117 461 34 33 Telefonica del Sur S.A. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 763 147 39 LINKdotNET AS number 8452 730 445 11 TEDATA 15475 496 90 12 Nile Online 36992 301 271 14 Etisalat MISR 3741 264 987 226 The Internet Solution 24835 219 78 10 RAYA Telecom - Egypt 6713 205 199 12 Itissalat Al-MAGHRIB 33776 194 12 15 Starcomms Nigeria Limited 29571 192 17 11 Ci Telecom Autonomous system 16637 149 422 85 MTN Network Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3694 3855 261 bellsouth.net, inc. 4323 2623 1109 405 Time Warner Telecom 4766 2307 9497 819 Korea Telecom (KIX) 19262 1843 4955 283 Verizon Global Networks 1785 1784 697 131 PaeTec Communications, Inc. 7545 1628 302 87 TPG Internet Pty Ltd 20115 1527 1534 646 Charter Communications 6478 1510 295 78 AT&T Worldnet Services 18566 1433 320 158 Covad Communications 4755 1417 634 163 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 2623 2218 Time Warner Telecom 1785 1784 1653 PaeTec Communications, Inc. 19262 1843 1560 Verizon Global Networks 7545 1628 1541 TPG Internet Pty Ltd 4766 2307 1488 Korea Telecom (KIX) 6478 1510 1432 AT&T Worldnet Services 17974 1409 1380 PT TELEKOMUNIKASI INDONESIA 18566 1433 1275 Covad Communications 4755 1417 1254 TATA Communications formerly 10620 1374 1208 TVCABLE BOGOTA Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.0.0.0/16 12654 RIPE NCC RIS Project 5.1.0.0/21 12654 RIPE NCC RIS Project 5.1.24.0/24 12654 RIPE NCC RIS Project 24.129.192.0/19 7922 Continental Cablevision 37.0.0.0/16 12654 RIPE NCC RIS Project 37.1.0.0/21 12654 RIPE NCC RIS Project 37.1.24.0/24 12654 RIPE NCC RIS Project 39.0.0.0/8 237 Merit Network 41.57.192.0/18 22750 BCSNET 41.222.79.0/24 36938 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:21 /9:10 /10:26 /11:72 /12:215 /13:445 /14:764 /15:1368 /16:11511 /17:5649 /18:9326 /19:18851 /20:24423 /21:24899 /22:33017 /23:31756 /24:181723 /25:1076 /26:1274 /27:657 /28:169 /29:16 /30:3 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2281 3694 bellsouth.net, inc. 6478 1464 1510 AT&T Worldnet Services 4323 1413 2623 Time Warner Telecom 18566 1411 1433 Covad Communications 10620 1265 1374 TVCABLE BOGOTA 11492 1237 1280 Cable One 1785 1054 1784 PaeTec Communications, Inc. 7011 1054 1157 Citizens Utilities 6503 969 1187 AVANTEL, S.A. 19262 954 1843 Verizon Global Networks Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:196 2:42 4:13 5:1 8:334 12:2029 13:1 14:409 15:15 16:3 17:8 20:9 23:1 24:1489 27:587 32:60 33:4 34:2 37:1 38:706 40:101 41:2241 44:3 46:617 47:4 49:149 50:93 52:12 55:2 56:2 57:32 58:862 59:475 60:391 61:1107 62:1053 63:1940 64:3828 65:2349 66:4224 67:1781 68:1028 69:2949 70:736 71:403 72:2020 73:1 74:2344 75:292 76:346 77:871 78:710 79:446 80:1053 81:823 82:503 83:475 84:634 85:1043 86:559 87:750 88:355 89:1573 90:157 91:3516 92:493 93:1039 94:1208 95:768 96:453 97:251 98:824 99:33 101:31 107:3 108:88 109:929 110:480 111:706 112:314 113:369 114:500 115:656 116:928 117:687 118:675 119:1021 120:242 121:701 122:1627 123:1052 124:1286 125:1257 128:266 129:156 130:170 131:569 132:109 133:20 134:216 135:49 136:215 137:146 138:292 139:119 140:494 141:203 142:359 143:376 144:486 145:51 146:437 147:199 148:638 149:276 150:160 151:229 152:298 153:180 154:3 155:349 156:176 157:342 158:129 159:380 160:313 161:206 162:274 163:161 164:486 165:338 166:502 167:422 168:737 169:150 170:754 171:69 172:11 173:1318 174:530 175:317 176:1 177:9 178:783 180:810 182:361 183:247 184:210 186:1010 187:826 188:895 189:1067 190:4404 192:5802 193:4803 194:3509 195:2955 196:1191 197:3 198:3573 199:3834 200:5595 201:1581 202:8260 203:8442 204:4101 205:2341 206:2624 207:3086 208:3903 209:3496 210:2632 211:1340 212:1930 213:1737 214:739 215:62 216:4892 217:1621 218:540 219:379 220:1201 221:452 222:312 223:100 End of report From mksmith at adhost.com Fri Feb 18 12:39:24 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Fri, 18 Feb 2011 18:39:24 +0000 Subject: Internet Exchange Point(IXP) questions In-Reply-To: References: Message-ID: From: Yaoqing(Joey) Liu [mailto:joey.liuyq at gmail.com] Sent: Thursday, February 17, 2011 7:04 PM To: Michael K. Smith - Adhost Cc: nanog at nanog.org Subject: Re: Internet Exchange Point(IXP) questions On Thu, Feb 17, 2011 at 8:17 PM, Michael K. Smith - Adhost > wrote: > -----Original Message----- > From: Yaoqing(Joey) Liu [mailto:joey.liuyq at gmail.com] > Sent: Thursday, February 17, 2011 6:03 PM > To: nanog at nanog.org > Subject: Internet Exchange Point(IXP) questions > > I'm doing some research on multiple origin AS problems of IXPs. As I know, > generally there are two types of IXPs > type 1: use exchange routers, which works in layer 3 > type 2: use switches and Ethernet topology, which works in layer 2. > So I have a couple of qustions: > 1. For type 1, the exchange routers may use several IP prefixes for routing, > how often does the IP prefixes have their own AS? > 2. For type 2, all peers connected to the IXP must work in the same subnet > required by Ethernet rules. Is possible that the subnet IP prefixes belong > to some private IP address space, such as 192.168.x.x? How often does this > happen? If the subnet only contains public IP addresses, how are the > addresses announced? > > Thanks, > Yaoqing Hello: On the Seattle Internet Exchange (SIX) we have ARIN-assigned addresses that we use on the Layer 2 fabric (your type 2 above). Hopefully the addresses aren't being announced at all, although we sometimes have to chase down people that announce it. Those addresses aren't the destination for any traffic, they are merely part of the transport to a destination, so there is no need for them to be in the DFZ. But I just checked the IXP prefix list, and found SIX owns prefix 206.81.80.0/23. And it has been announced by three ASNs, AS11537(Internet 2), AS3130(RGnet, LLC) and AS25973(Mzima Networks, Inc). I'm not sure if my info is correct. Does SIX own its own ASN other than the three above? Yaoqing From gbonser at seven.com Fri Feb 18 12:42:22 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 18 Feb 2011 10:42:22 -0800 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6naysayer...) In-Reply-To: <20110218182151.GA94617@mikea.ath.cx> References: <5A6D953473350C4B9995546AFE9939EE0BC13C26@RWC-EX1.corp.seven.com> <20110218182151.GA94617@mikea.ath.cx> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13C2A@RWC-EX1.corp.seven.com> > > You never been told something like "We don't do (or stock) that because > there's no demand for it! You know, you're the Nth person to ask about > it > today." I have, and many more times than merely once. > > -- > Mike Andrews, W5EGO > mikea at mikea.ath.cx > Tired old sysadmin Right, so what it takes is someone out there to create the demand. It would actually be a great public service if someone were to do that. Some social networking, gaming, or some other sort of site that only the "cool kids" can access via v6, maybe. Nothing drives people nuts more than knowing there is something out there that they can't access. Create something like that AND generate some buzz surrounding it, particularly if someone hears people talking about it and they can't access it themselves to see what the buzz is all about, and you have just built the required demand for v6 migration. It is going to take v6-only content to do that, I think. Frankly, a v6 only service is easier to build and deploy. Dual stacking causes problems with many applications, if it is native v6 and v6 only, it removes a lot of the "issues" with v6 migration. From mksmith at adhost.com Fri Feb 18 12:43:29 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Fri, 18 Feb 2011 18:43:29 +0000 Subject: Internet Exchange Point(IXP) questions In-Reply-To: References: Message-ID: -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) From: Yaoqing(Joey) Liu [mailto:joey.liuyq at gmail.com] Sent: Thursday, February 17, 2011 7:04 PM To: Michael K. Smith - Adhost Cc: nanog at nanog.org Subject: Re: Internet Exchange Point(IXP) questions On Thu, Feb 17, 2011 at 8:17 PM, Michael K. Smith - Adhost wrote: > -----Original Message----- > From: Yaoqing(Joey) Liu [mailto:joey.liuyq at gmail.com] > Sent: Thursday, February 17, 2011 6:03 PM > To: nanog at nanog.org > Subject: Internet Exchange Point(IXP) questions > > I'm doing some research on multiple origin AS problems of IXPs. As I know, > generally there are two types of IXPs > type 1: use exchange routers, which works in layer 3 > type 2: use switches and Ethernet topology, which works in layer 2. > So I have a couple of qustions: > 1. For type 1, the exchange routers may use several IP prefixes for routing, > how often does the IP prefixes have their own AS? > 2. For type 2, all peers connected to the IXP must work in the same subnet > required by Ethernet rules. Is possible that the subnet IP prefixes belong > to some private IP address space, such as 192.168.x.x? How often does this > happen? If the subnet only contains public IP addresses, how are the > addresses announced? > > Thanks, > Yaoqing >Hello: >On the Seattle Internet Exchange (SIX) we have ARIN-assigned addresses that we use on the Layer 2 fabric (your type 2 above). ?Hopefully the addresses aren't being announced at all, although >we sometimes have to chase down people that announce it. ?Those addresses aren't the destination for any traffic, they are merely part of the transport to a destination, so there is no need for >them to be in the DFZ. >But I just checked the IXP prefix list, and found SIX owns prefix 206.81.80.0/23. And it has been announced by three ASNs, AS11537(Internet 2), AS3130(RGnet, LLC) and AS25973(Mzima >Networks, Inc). I'm not sure if my info is correct. Does SIX own its own ASN other than the three above? Sorry for the misfire on my last email. The 206.81.80.0/23 network is assigned to the SIX from ARIN. In general, we don't want people to announce that space to the DFZ, so the three providers listed above are not filtering their announcements properly. It is, as others have said, a good idea to announce the exchange block to your customers, but not out to the DFZ. Regards, Mike From franck at genius.com Fri Feb 18 12:53:52 2011 From: franck at genius.com (Franck Martin) Date: Sat, 19 Feb 2011 07:53:52 +1300 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6naysayer...) In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13C2A@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13C26@RWC-EX1.corp.seven.com> <20110218182151.GA94617@mikea.ath.cx> <5A6D953473350C4B9995546AFE9939EE0BC13C2A@RWC-EX1.corp.seven.com> Message-ID: http://www.jetcafe.org/~npc/isp/large.html If you take the 5 top US ISPs and get them to do dual stack IPv6, that's 50 million subscribers in the US only. I think google and others will notice some serious traffic happening. It took a market share of 10 to 20% of Mozilla for web developers to go back to support ALL browsers. Same for mobile web site a 10% surfing rate got many companies to develop web sites for mobiles. If I recall Comcast and Time Warner are participating in IPv6 day. This should create enough eyeballs to show on web analytics graph and provide the shift that makes nat444 irrelevant. For a network operator I'm looking at the ipv6 ipv4 ASN ratio. Once it passes 10% we will have a snow ball effect in the core. Toute connaissance est une r?ponse ? une question > From khelms at ispalliance.net Fri Feb 18 13:07:54 2011 From: khelms at ispalliance.net (Scott Helms) Date: Fri, 18 Feb 2011 14:07:54 -0500 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6naysayer...) In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE0BC13C26@RWC-EX1.corp.seven.com> <20110218182151.GA94617@mikea.ath.cx> <5A6D953473350C4B9995546AFE9939EE0BC13C2A@RWC-EX1.corp.seven.com> Message-ID: <4D5EC38A.4000905@ispalliance.net> On 2/18/2011 1:53 PM, Franck Martin wrote: > http://www.jetcafe.org/~npc/isp/large.html > > If you take the 5 top US ISPs and get them to do dual stack IPv6, that's 50 million subscribers in the US only. > > I think google and others will notice some serious traffic happening. We're years from the point where any one of them will have more than a tiny fraction of their traffic as IPv6 and that's assuming that all we have to deal with are the known problems. > It took a market share of 10 to 20% of Mozilla for web developers to go back to support ALL browsers. Same for mobile web site a 10% surfing rate got many companies to develop web sites for mobiles. Not really comparable because in both of those cases users were making a choice, because they perceived some benefit, and hence there was demand to adapt to those new platforms. There is almost 0 demand for IPv6 from consumers and what is there is from the technologists. We don't have a situation where the existing infrastructure doesn't work, it does. > If I recall Comcast and Time Warner are participating in IPv6 day. This should create enough eyeballs to show on web analytics graph and provide the shift that makes nat444 irrelevant. I wish, but IPv6 day will be much more of a media event than anything else. Keep in mind that none of these things are what I wish only what I believe to be accurate. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From cb.list6 at gmail.com Fri Feb 18 13:09:32 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Fri, 18 Feb 2011 11:09:32 -0800 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6naysayer...) In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13C2A@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13C26@RWC-EX1.corp.seven.com> <20110218182151.GA94617@mikea.ath.cx> <5A6D953473350C4B9995546AFE9939EE0BC13C2A@RWC-EX1.corp.seven.com> Message-ID: On Fri, Feb 18, 2011 at 10:42 AM, George Bonser wrote: >> >> You never been told something like "We don't do (or stock) that > because >> there's no demand for it! You know, you're the Nth person to ask about >> it >> today." I have, and many more times than merely once. >> >> -- >> Mike Andrews, W5EGO >> mikea at mikea.ath.cx >> Tired old sysadmin > > Right, so what it takes is someone out there to create the demand. ?It > would actually be a great public service if someone were to do that. > Some social networking, gaming, or some other sort of site that only the > "cool kids" can access via v6, maybe. > > Nothing drives people nuts more than knowing there is something out > there that they can't access. ?Create something like that AND generate > some buzz surrounding it, particularly if someone hears people talking > about it and they can't access it themselves to see what the buzz is all > about, and you have just built the required demand for v6 migration. ?It > is going to take v6-only content to do that, I think. Frankly, a v6 only > service is easier to build and deploy. ?Dual stacking causes problems > with many applications, if it is native v6 and v6 only, it removes a lot > of the "issues" with v6 migration. > 100% agree. No volunteers yet for making their awesome new service IPv6-only :( From nmaxpierson at gmail.com Fri Feb 18 13:13:54 2011 From: nmaxpierson at gmail.com (Max Pierson) Date: Fri, 18 Feb 2011 13:13:54 -0600 Subject: Graph Utils (Open-Source) Message-ID: Hi List, Anyone out there using something other than rrdtool for creating graphs?? I have a project that will need a trend taken, and unfortunately rrdtool doesn't fit the bill. All of the scripting, data collection, database archival, etc will be custom written or is already done (with some hacks of course :). So really what i'm looking for is something along the lines of GNUplot. Has anyone used it before and would like to share experiences?? Seems like it will be able to my plot data accordingly, but wanted to see if there were any other popular tools I've yet to come across. (Open-Source only please) TIA, M From jlintz at gmail.com Fri Feb 18 13:17:44 2011 From: jlintz at gmail.com (Justin Lintz) Date: Fri, 18 Feb 2011 14:17:44 -0500 Subject: Telmex ISP contacts Message-ID: Hi, If anyone has a contact at the Mexican ISP Telmex http://www.telmex.com , please contact me off list. We're having an issue with them blocking our traffic and having trouble getting in touch with them. Thanks - Justin Lintz From jsw at inconcepts.biz Fri Feb 18 13:19:57 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Fri, 18 Feb 2011 14:19:57 -0500 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6naysayer...) In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13C26@RWC-EX1.corp.seven.com> References: <398436.89934.qm@web114716.mail.gq1.yahoo.com> <5A6D953473350C4B9995546AFE9939EE0BC13C26@RWC-EX1.corp.seven.com> Message-ID: On Fri, Feb 18, 2011 at 1:14 PM, George Bonser wrote: > One thing they can do, and I would live to see some popular destination > site do this, is to say something like: > > "we have this really cool new thing we are rolling out but, sorry, it is > available only via IPv6" or "we will continue supporting all of today's > features on v4 but all new features will be rolled out on v6 only". I doubt any top web sites or popular services will do this, because there is no commercial advantage to it. It is great to see Google, Yahoo, and other companies taking a big step by deciding to serve up AAAA by default for one day. It also should indicate to everyone how far we are from the goal line, not because Google or Yahoo aren't doing their homework, but because their end-users' ISPs aren't. If these companies are only willing to do AAAA by default for one day on a trial basis, and that with months of notice and perhaps preparation, they clearly should not be willing to make some cool new revenue-generating feature exclusive to IPv6 end-users. On Fri, Feb 18, 2011 at 1:53 PM, Franck Martin wrote: > If I recall Comcast and Time Warner are participating in IPv6 day. This should create enough eyeballs to show on web analytics graph and provide the shift that makes nat444 irrelevant. I am afraid you may be a little disappointed. The number of users with IPv6-capable CPE, to say nothing of home LANs, may still be quite limited by that time. It's still progress, but I don't think anything except IPv4 depletion will increase IPv6 adoption. > For a network operator I'm looking at the ipv6 ipv4 ASN ratio. Once it passes 10% we will have a snow ball effect in the core. Unfortunately, many ASNs who originate IPv6 address space have few or no functioning services on IPv6. A simple "ASN ratio" is not a very useful metric. You also do not have visibility into how much infrastructure is based on tunnels, whether or not v6 even reaches customer access ports or even is enabled backbone-wide, etc. I agree it is encouraging to see new ASNs originating IPv6 routes every day, but again, this is more an indicator of "we got a /32 from the RIR and configured it on our router" than "we are using v6 in a production capacity (or are prepared to flip the switch.)" I really do think that advertising may be the thing that eventually forces some end-user ISPs to get in gear. If end-users went to www.google.com on "IPv6 day" (and perhaps after) and got a message saying "your ISP is great" or "here are some ISPs you might want to consider, because yours can no longer reach some Internet destinations," I suspect that would give ISPs a very serious reason to spend the necessary resources to get v6 done. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From paul at paulgraydon.co.uk Fri Feb 18 13:21:22 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Fri, 18 Feb 2011 09:21:22 -1000 Subject: Graph Utils (Open-Source) In-Reply-To: References: Message-ID: <4D5EC6B2.90202@paulgraydon.co.uk> On 02/18/2011 09:13 AM, Max Pierson wrote: > Hi List, > > Anyone out there using something other than rrdtool for creating graphs?? I > have a project that will need a trend taken, and unfortunately rrdtool > doesn't fit the bill. All of the scripting, data collection, > database archival, etc will be custom written or is already done (with some > hacks of course :). So really what i'm looking for is something along the > lines of GNUplot. Has anyone used it before and would like to share > experiences?? Seems like it will be able to my plot data accordingly, but > wanted to see if there were any other popular tools I've yet to come across. > > (Open-Source only please) > > TIA, > M If you're comfortable with Python, Graphite is gaining some serious traction http://graphite.wikidot.com/ Paul From jloiacon at csc.com Fri Feb 18 13:21:59 2011 From: jloiacon at csc.com (Joe Loiacono) Date: Fri, 18 Feb 2011 14:21:59 -0500 Subject: Graph Utils (Open-Source) In-Reply-To: References: Message-ID: Thomas Boutrell's 'GD'. http://www.libgd.org/Main_Page Joe From: Max Pierson To: nanog group Date: 02/18/2011 02:15 PM Subject: Graph Utils (Open-Source) Hi List, Anyone out there using something other than rrdtool for creating graphs?? I have a project that will need a trend taken, and unfortunately rrdtool doesn't fit the bill. All of the scripting, data collection, database archival, etc will be custom written or is already done (with some hacks of course :). So really what i'm looking for is something along the lines of GNUplot. Has anyone used it before and would like to share experiences?? Seems like it will be able to my plot data accordingly, but wanted to see if there were any other popular tools I've yet to come across. (Open-Source only please) TIA, M From morrowc.lists at gmail.com Fri Feb 18 13:34:21 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 18 Feb 2011 14:34:21 -0500 Subject: Internet Exchange Point(IXP) questions In-Reply-To: References: Message-ID: On Fri, Feb 18, 2011 at 1:43 PM, Michael K. Smith - Adhost wrote: > Sorry for the misfire on my last email. ?The 206.81.80.0/23 network is assigned to the SIX from ARIN. ? In general, we don't want > people to announce that space to the DFZ, so the three providers listed above are not filtering their announcements properly. ?It is, as > others have said, a good idea to announce the exchange block to your customers, but not out to the DFZ. why is it a good idea to send this to your customers? the next-hop info is surely only useful to your local network? done right it's even only relevant to the IX connected router, right? it seems wholely unusful to your customers. (to me at least) From drais at icantclick.org Fri Feb 18 13:38:18 2011 From: drais at icantclick.org (david raistrick) Date: Fri, 18 Feb 2011 14:38:18 -0500 (EST) Subject: Graph Utils (Open-Source) In-Reply-To: References: Message-ID: On Fri, 18 Feb 2011, Max Pierson wrote: > Hi List, > > Anyone out there using something other than rrdtool for creating graphs?? I > have a project that will need a trend taken, and unfortunately rrdtool > doesn't fit the bill. All of the scripting, data collection, > database archival, etc will be custom written or is already done (with some > hacks of course :). So really what i'm looking for is something along the we use both gd (in php and in perl and in c++) and google's graphing magic in various places. http://code.google.com/apis/chart/ -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From cocoloco.lopez at gmail.com Fri Feb 18 14:20:30 2011 From: cocoloco.lopez at gmail.com (cocoloco) Date: Fri, 18 Feb 2011 15:20:30 -0500 Subject: Contact for msn.com NOC Message-ID: Anyone have a working contact for the msn.com NOC? I tried the email listed in Arin - noc at microsoft.com and it bounces back. Thanks Dan From pafriend at octavian.org Fri Feb 18 14:34:34 2011 From: pafriend at octavian.org (Peter A. Friend) Date: Fri, 18 Feb 2011 12:34:34 -0800 Subject: Graph Utils (Open-Source) In-Reply-To: References: Message-ID: I've used gnuplot for several projects and found it very flexible. Gnuplot is also handy because it's easy to feed it commands over a pipe. I also recommend the "Gnuplot In Action" book - it saved me a ton of time. I have also used matplotlib within Python. For more interactive graphs I've played with the Processing environment a bit, but not enough to provide a useful comparison with the other tools. Peter On Feb 18, 2011, at 11:13 AM, Max Pierson wrote: > Hi List, > > Anyone out there using something other than rrdtool for creating > graphs?? I > have a project that will need a trend taken, and unfortunately rrdtool > doesn't fit the bill. All of the scripting, data collection, > database archival, etc will be custom written or is already done > (with some > hacks of course :). So really what i'm looking for is something > along the > lines of GNUplot. Has anyone used it before and would like to share > experiences?? Seems like it will be able to my plot data > accordingly, but > wanted to see if there were any other popular tools I've yet to come > across. > > (Open-Source only please) > > TIA, > M From john-nanog at johnpeach.com Fri Feb 18 14:35:01 2011 From: john-nanog at johnpeach.com (John Peach) Date: Fri, 18 Feb 2011 15:35:01 -0500 Subject: Contact for msn.com NOC In-Reply-To: References: Message-ID: <20110218153501.606fac43@jpeach-desktop.anbg.mssm.edu> On Fri, 18 Feb 2011 15:20:30 -0500 cocoloco wrote: > Anyone have a working contact for the msn.com NOC? I tried the email > listed in Arin - noc at microsoft.com and it bounces back. > > Thanks > > Dan whois msn.com Tech Email........... msnhst at microsoft.com Tech Phone........... +1.4258828080 -- John From jlewis at lewis.org Fri Feb 18 14:36:05 2011 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 18 Feb 2011 15:36:05 -0500 (EST) Subject: Graph Utils (Open-Source) In-Reply-To: References: Message-ID: On Fri, 18 Feb 2011, Max Pierson wrote: > hacks of course :). So really what i'm looking for is something along the > lines of GNUplot. Has anyone used it before and would like to share > experiences?? Seems like it will be able to my plot data accordingly, but > wanted to see if there were any other popular tools I've yet to come across. What's wrong with GNUplot? I used it to do graphing of dialup server port utilization in some CGI I did back in the mid 90s. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From cocoloco.lopez at gmail.com Fri Feb 18 14:47:51 2011 From: cocoloco.lopez at gmail.com (cocoloco) Date: Fri, 18 Feb 2011 15:47:51 -0500 Subject: Contact for msn.com NOC In-Reply-To: <20110218153501.606fac43@jpeach-desktop.anbg.mssm.edu> References: <20110218153501.606fac43@jpeach-desktop.anbg.mssm.edu> Message-ID: Thanks Mark and John I will try these. Dan On Fri, Feb 18, 2011 at 3:35 PM, John Peach wrote: > On Fri, 18 Feb 2011 15:20:30 -0500 > cocoloco wrote: > > > Anyone have a working contact for the msn.com NOC? I tried the email > > listed in Arin - noc at microsoft.com and it bounces back. > > > > Thanks > > > > Dan > > whois msn.com > > Tech Email........... msnhst at microsoft.com > Tech Phone........... +1.4258828080 > > > > > -- > John > > -- http://www.thepetitionsite.com/takeaction/724210624 - Save the Dolphins. From franck at genius.com Fri Feb 18 14:48:05 2011 From: franck at genius.com (Franck Martin) Date: Sat, 19 Feb 2011 09:48:05 +1300 (FJST) Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6naysayer...) In-Reply-To: <4D5EC38A.4000905@ispalliance.net> Message-ID: <30789884.16.1298061465106.JavaMail.franck@franck-martins-macbook-pro.local> ----- Original Message ----- > From: "Scott Helms" > To: nanog at nanog.org > Sent: Saturday, 19 February, 2011 8:07:54 AM > Subject: Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6naysayer...) > On 2/18/2011 1:53 PM, Franck Martin wrote: > > http://www.jetcafe.org/~npc/isp/large.html > > > > If you take the 5 top US ISPs and get them to do dual stack IPv6, > > that's 50 million subscribers in the US only. > > > > I think google and others will notice some serious traffic > > happening. > We're years from the point where any one of them will have more than a > tiny fraction of their traffic as IPv6 and that's assuming that all we > have to deal with are the known problems. May be, may be not, but yes non of them are ready like free did to "switch on" IPv6 on their CPE. US ISPs have been caught their pants down. It is going to be ugly. > > > It took a market share of 10 to 20% of Mozilla for web developers to > > go back to support ALL browsers. Same for mobile web site a 10% > > surfing rate got many companies to develop web sites for mobiles. > > Not really comparable because in both of those cases users were making > a > choice, because they perceived some benefit, and hence there was > demand > to adapt to those new platforms. There is almost 0 demand for IPv6 > from > consumers and what is there is from the technologists. We don't have a > situation where the existing infrastructure doesn't work, it does. Yes there is no demand from consumers, but a consumer on IPv6 is a consumer on IPv6, and that will happen with IPv4 depletion, now once we reach 10% of them, then web analytic tools and email marketing tools and anything that tracks consumer behavior will have to be IPv6 compliant. You don't want to ignore 10% of your consumers, and that was my point. Google IPv6 traffic is at 0.3%, nice, but hardly significant to have a boss to ask: "I want those IPv6 consumers counted". I'm looking at where is the critical mass point, when the machine will work on itself, I say 10%. > > > If I recall Comcast and Time Warner are participating in IPv6 day. > > This should create enough eyeballs to show on web analytics graph > > and provide the shift that makes nat444 irrelevant. > > I wish, but IPv6 day will be much more of a media event than anything > else. Keep in mind that none of these things are what I wish only what > I believe to be accurate. > Sure on IPv6 day they won't light up all their customers, but they made a commitment to be there sooner than later. And yes it is a media event where many companies are saying me too, we are ready, or about to! Or "it will be in next release" which is better than "gosh, there is no demand for that and you are the first one to ask me", which is better than "it will fail". From zzuser at yahoo.com Fri Feb 18 14:50:00 2011 From: zzuser at yahoo.com (Zed Usser) Date: Fri, 18 Feb 2011 12:50:00 -0800 (PST) Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <45BF34F3-5720-4E49-BD82-CA74336AC9B4@delong.com> Message-ID: <480805.6221.qm@web114707.mail.gq1.yahoo.com> --- On Sat, 2/19/11, Owen DeLong wrote: > You only need to solve those problems to the > extent that there are meaningful things still > trapped in an IPv4-only world. Are you willing to bet that IPv4 address exhaustion will not result in IPv6-only hosts before we run out of meaningful IPv4-only hosts? - Zed From nmaxpierson at gmail.com Fri Feb 18 15:03:51 2011 From: nmaxpierson at gmail.com (Max Pierson) Date: Fri, 18 Feb 2011 15:03:51 -0600 Subject: Graph Utils (Open-Source) In-Reply-To: References: Message-ID: > What's wrong with GNUplot? Nothing at all :) My problem is with rrdtool. It doesn't scale for this project. I was looking into GNUplot, but wanted to see what else was out there as well. Thanks for all of the on and off list replies so far. I'll follow up after test driving a few of the mentioned tools. On Fri, Feb 18, 2011 at 2:36 PM, Jon Lewis wrote: > On Fri, 18 Feb 2011, Max Pierson wrote: > > hacks of course :). So really what i'm looking for is something along the >> lines of GNUplot. Has anyone used it before and would like to share >> experiences?? Seems like it will be able to my plot data accordingly, but >> wanted to see if there were any other popular tools I've yet to come >> across. >> > > What's wrong with GNUplot? I used it to do graphing of dialup server port > utilization in some CGI I did back in the mid 90s. > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > From paul at paulgraydon.co.uk Fri Feb 18 15:13:12 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Fri, 18 Feb 2011 11:13:12 -1000 Subject: Graph Utils (Open-Source) In-Reply-To: References: Message-ID: <4D5EE0E8.5010809@paulgraydon.co.uk> Mostly I've heard bad things about matplotlib under Python. Lots of good features, but buggy and a bit of a memory hog. How did you find it? On 02/18/2011 10:34 AM, Peter A. Friend wrote: > I've used gnuplot for several projects and found it very flexible. > Gnuplot is also handy because it's easy to feed it commands over a > pipe. I also recommend the "Gnuplot In Action" book - it saved me a > ton of time. I have also used matplotlib within Python. > > For more interactive graphs I've played with the Processing > environment a bit, but not enough to provide a useful comparison with > the other tools. > > Peter > > On Feb 18, 2011, at 11:13 AM, Max Pierson wrote: > >> Hi List, >> >> Anyone out there using something other than rrdtool for creating >> graphs?? I >> have a project that will need a trend taken, and unfortunately rrdtool >> doesn't fit the bill. All of the scripting, data collection, >> database archival, etc will be custom written or is already done >> (with some >> hacks of course :). So really what i'm looking for is something along >> the >> lines of GNUplot. Has anyone used it before and would like to share >> experiences?? Seems like it will be able to my plot data accordingly, >> but >> wanted to see if there were any other popular tools I've yet to come >> across. >> >> (Open-Source only please) >> >> TIA, >> M > > From mksmith at adhost.com Fri Feb 18 15:24:37 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Fri, 18 Feb 2011 21:24:37 +0000 Subject: Internet Exchange Point(IXP) questions In-Reply-To: References: Message-ID: > -----Original Message----- > From: christopher.morrow at gmail.com > [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow > Sent: Friday, February 18, 2011 11:34 AM > To: Michael K. Smith - Adhost > Cc: Yaoqing(Joey) Liu; nanog at nanog.org > Subject: Re: Internet Exchange Point(IXP) questions > > On Fri, Feb 18, 2011 at 1:43 PM, Michael K. Smith - Adhost > wrote: > > > Sorry for the misfire on my last email. ?The 206.81.80.0/23 network is > assigned to the SIX from ARIN. ? In general, we don't want > > people to announce that space to the DFZ, so the three providers listed > above are not filtering their announcements properly. ?It is, as > > others have said, a good idea to announce the exchange block to your > customers, but not out to the DFZ. > > why is it a good idea to send this to your customers? the next-hop > info is surely only useful to your local network? done right it's even > only relevant to the IX connected router, right? it seems wholely > unusful to your customers. (to me at least) I was thinking about what Leo said about tools that test each hop through a path. At least my downstream customers will be able to test through the SIX connection if I announce the /23 to them. Mike From jabley at hopcount.ca Fri Feb 18 15:28:01 2011 From: jabley at hopcount.ca (Joe Abley) Date: Fri, 18 Feb 2011 16:28:01 -0500 Subject: Internet Exchange Point(IXP) questions In-Reply-To: References: Message-ID: <0A0C553F-2BB5-4221-8B4B-F3E63ADA1D46@hopcount.ca> On 2011-02-18, at 14:34, Christopher Morrow wrote: > On Fri, Feb 18, 2011 at 1:43 PM, Michael K. Smith - Adhost > wrote: > >> Sorry for the misfire on my last email. The 206.81.80.0/23 network is assigned to the SIX from ARIN. In general, we don't want >> people to announce that space to the DFZ, so the three providers listed above are not filtering their announcements properly. It is, as >> others have said, a good idea to announce the exchange block to your customers, but not out to the DFZ. > > why is it a good idea to send this to your customers? the next-hop > info is surely only useful to your local network? done right it's even > only relevant to the IX connected router, right? it seems wholely > unusful to your customers. (to me at least) Well, except for the reason that Leo mentioned. The NEXT_HOP in the exchange point subnet will not make it to the customer router. It's not a transitive attribute. The customer will see a NEXT_HOP corresponding to the provider router (or whatever they decide to re-write it as). See RFC 4271 section 5.1.3. Joe From owen at delong.com Fri Feb 18 15:27:51 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 18 Feb 2011 13:27:51 -0800 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6naysayer...) In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13C26@RWC-EX1.corp.seven.com> References: <398436.89934.qm@web114716.mail.gq1.yahoo.com> <5A6D953473350C4B9995546AFE9939EE0BC13C26@RWC-EX1.corp.seven.com> Message-ID: <84BCB757-79C7-41E0-AEC0-7CA7A4C7E3CA@delong.com> On Feb 18, 2011, at 10:14 AM, George Bonser wrote: >> From: Jeff Wheeler >> Sent: Friday, February 18, 2011 8:13 AM >> To: nanog at nanog.org >> Subject: Re: [arin-ppml] NAT444 rumors (was Re: Looking for an >> IPv6naysayer...) >> >> >> I suspect Google, Microsoft, and others have already figured out a >> beneficial (to everyone) way to monetize this. If I'm an ISP with >> working IPv6, and my competitor in a given region is an ISP without >> IPv6, I'd like to advertise to all the end-users of that ISP whenever >> they go to a search engine that sells ads. >> > > One thing they can do, and I would live to see some popular destination > site do this, is to say something like: > > "we have this really cool new thing we are rolling out but, sorry, it is > available only via IPv6" or "we will continue supporting all of today's > features on v4 but all new features will be rolled out on v6 only". > > That would result in eyeballs demanding access to that content and > nothing drives innovation like customer demand does. > > Eyeball demand on ISPs will _NOT_ be the lagging problem in IPv6 deployment. The consumer side laggage will be CPE and Consumer Eelectronics. Consumer ISPs are going to be the first ones forced to put subscribers on IPv6 whether they're ready or not because: + Residential Internet Services is the single largest address consumer + They pay less for their services than any other class of user + In many cases they have few or no choices in provider selection + They provide the narrowest margins These factors mean that providers that are strictly residential will run out of addresses faster than other providers. Providers which are in multiple lines of business, including residential are likely to start harvesting residential addresses for higher-paying services. The question is whether content providers will recognize and prepare for this reality before it arrives, or, react to it afterwards. Owen From bicknell at ufp.org Fri Feb 18 15:29:12 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 18 Feb 2011 13:29:12 -0800 Subject: Internet Exchange Point(IXP) questions In-Reply-To: References: Message-ID: <20110218212912.GA71511@ussenterprise.ufp.org> In a message written on Fri, Feb 18, 2011 at 02:34:21PM -0500, Christopher Morrow wrote: > why is it a good idea to send this to your customers? the next-hop > info is surely only useful to your local network? done right it's even > only relevant to the IX connected router, right? it seems wholely > unusful to your customers. (to me at least) If by "done right" you mean perhaps a feature like returning ICMP's from a loopback IP rather than the interface IP, there are two issues with that: The far end ISP controls this feature. If they don't enable it you must work around by announcing the prefix to your customer. One person doing it wrong at the exchange is enough that you have to work around it. I at least find it useful when traceroute shows the interface. I believe it saves time for your NOC, and burning IP's for interfaces makes a lot of sense in terms of speeding troubleshooting. Even if all of my gear allowed me to send ICMP's from the loopback it's quite likely I would not use that feature. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From morrowc.lists at gmail.com Fri Feb 18 15:36:28 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 18 Feb 2011 16:36:28 -0500 Subject: Internet Exchange Point(IXP) questions In-Reply-To: <20110218212912.GA71511@ussenterprise.ufp.org> References: <20110218212912.GA71511@ussenterprise.ufp.org> Message-ID: On Fri, Feb 18, 2011 at 4:29 PM, Leo Bicknell wrote: > In a message written on Fri, Feb 18, 2011 at 02:34:21PM -0500, Christopher Morrow wrote: >> why is it a good idea to send this to your customers? the next-hop >> info is surely only useful to your local network? done right it's even >> only relevant to the IX connected router, right? it seems wholely >> unusful to your customers. (to me at least) > > If by "done right" you mean perhaps a feature like returning ICMP's from > a loopback IP rather than the interface IP, there are two issues with sorry, I was only talking|thinking about routing bits, I missed your point about people being able to ping an IX interface... I'd submit that in many networks the path to the nexthop may be a vastly different one than the path to 'the broken thing' through the isp/ixp/isp set of routers. I meant: "Is the nexthop in your (the ixp connected isp) network the IXP interface IP, or the loopback of your IXP connected router?" 'Done right' (I agree that this is an individual perspective) here meant, to me, that the IXP prefix wasn't necessary in the IXP connected ISP's network, reset to loopback in ibgp policy and never send the IXP prefix (connected route) off the IXP connected router. leaking the IX prefix to customers, to me, seems like a recipe for much wider/unintended leakage :( From morrowc.lists at gmail.com Fri Feb 18 15:37:05 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 18 Feb 2011 16:37:05 -0500 Subject: Internet Exchange Point(IXP) questions In-Reply-To: References: Message-ID: On Fri, Feb 18, 2011 at 4:24 PM, Michael K. Smith - Adhost wrote: >> -----Original Message----- >> From: christopher.morrow at gmail.com >> why is it a good idea to send this to your customers? the next-hop >> info is surely only useful to your local network? done right it's even >> only relevant to the IX connected router, right? it seems wholely >> unusful to your customers. (to me at least) > > I was thinking about what Leo said about tools that test each hop through a path. ?At least my downstream customers will be able to test through the SIX connection if I announce the /23 to them. > hopefully the path to the IXP prefix is the same as to the item they are testing failure of? :) From owen at delong.com Fri Feb 18 15:34:55 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 18 Feb 2011 13:34:55 -0800 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6naysayer...) In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13C2A@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13C26@RWC-EX1.corp.seven.com> <20110218182151.GA94617@mikea.ath.cx> <5A6D953473350C4B9995546AFE9939EE0BC13C2A@RWC-EX1.corp.seven.com> Message-ID: <325AC679-1BA8-410C-9786-535293D3DC59@delong.com> You can't get yourself an IPv6 Sage certification if you aren't running IPv6. http://tunnelbroker.net Owen On Feb 18, 2011, at 10:42 AM, George Bonser wrote: >> >> You never been told something like "We don't do (or stock) that > because >> there's no demand for it! You know, you're the Nth person to ask about >> it >> today." I have, and many more times than merely once. >> >> -- >> Mike Andrews, W5EGO >> mikea at mikea.ath.cx >> Tired old sysadmin > > Right, so what it takes is someone out there to create the demand. It > would actually be a great public service if someone were to do that. > Some social networking, gaming, or some other sort of site that only the > "cool kids" can access via v6, maybe. > > Nothing drives people nuts more than knowing there is something out > there that they can't access. Create something like that AND generate > some buzz surrounding it, particularly if someone hears people talking > about it and they can't access it themselves to see what the buzz is all > about, and you have just built the required demand for v6 migration. It > is going to take v6-only content to do that, I think. Frankly, a v6 only > service is easier to build and deploy. Dual stacking causes problems > with many applications, if it is native v6 and v6 only, it removes a lot > of the "issues" with v6 migration. > > > > From bicknell at ufp.org Fri Feb 18 15:44:56 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 18 Feb 2011 13:44:56 -0800 Subject: Internet Exchange Point(IXP) questions In-Reply-To: References: <20110218212912.GA71511@ussenterprise.ufp.org> Message-ID: <20110218214456.GA72337@ussenterprise.ufp.org> In a message written on Fri, Feb 18, 2011 at 04:36:28PM -0500, Christopher Morrow wrote: > leaking the IX prefix to customers, to me, seems like a recipe for > much wider/unintended leakage :( Oh, it is. I remember when MAE-EAST was injected by at least 50 people into the DFZ because back then people weren't careful enough to just send such things to customers. AMS-IX (and others) have the better solution. They have AS1200, announce the exchange LAN from AS1200 (195.69.144.0/22). They will peer with you if you are at the exchange, see http://www.ams-ix.net/as1200-peering/. I believe, but can't find a reference really quick that they get transit for it from a couple of providers so those that don't peer still have the route. I mean really, you have a block. If your IXP matters it's already taking up space in all of the largest ISP's tables anyway, so there's no "saving a route argument". Get an ASN, which since your multi-homed is trivial, announce the block from there and peer with your exchange participants. Everyone is happy, the route is consistent, and life is good. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From bicknell at ufp.org Fri Feb 18 15:46:11 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 18 Feb 2011 13:46:11 -0800 Subject: Internet Exchange Point(IXP) questions In-Reply-To: References: Message-ID: <20110218214611.GB72337@ussenterprise.ufp.org> In a message written on Fri, Feb 18, 2011 at 04:37:05PM -0500, Christopher Morrow wrote: > On Fri, Feb 18, 2011 at 4:24 PM, Michael K. Smith - Adhost > > I was thinking about what Leo said about tools that test each hop through a path. ?At least my downstream customers will be able to test through the SIX connection if I announce the /23 to them. > > hopefully the path to the IXP prefix is the same as to the item they > are testing failure of? :) Of course it isn't. Perhaps you missed my implication in the original mail I wrote. :) The customers cloging up your help desk with this sort of stuff are idiots. Unfortunately that's where the majority of your helpdesk time goes... -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From morrowc.lists at gmail.com Fri Feb 18 15:48:15 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 18 Feb 2011 16:48:15 -0500 Subject: Internet Exchange Point(IXP) questions In-Reply-To: <20110218214611.GB72337@ussenterprise.ufp.org> References: <20110218214611.GB72337@ussenterprise.ufp.org> Message-ID: On Fri, Feb 18, 2011 at 4:46 PM, Leo Bicknell wrote: > The customers cloging up your help desk with this sort of stuff are > idiots. ?Unfortunately that's where the majority of your helpdesk time > goes... i admit to missing it :( but yes, now with the explanation, I get your point :) From owen at delong.com Fri Feb 18 15:54:06 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 18 Feb 2011 13:54:06 -0800 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6naysayer...) In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE0BC13C26@RWC-EX1.corp.seven.com> <20110218182151.GA94617@mikea.ath.cx> <5A6D953473350C4B9995546AFE9939EE0BC13C2A@RWC-EX1.corp.seven.com> Message-ID: <01C94B36-E854-4ABC-9A8E-BCA2C7EF1CB8@delong.com> On Feb 18, 2011, at 10:53 AM, Franck Martin wrote: > http://www.jetcafe.org/~npc/isp/large.html > > If you take the 5 top US ISPs and get them to do dual stack IPv6, that's 50 million subscribers in the US only. > > I think google and others will notice some serious traffic happening. > Google would probably notice significant traffic increases on IPv6 if they started providing AAAA records to non-white-listed DNS resolvers. > It took a market share of 10 to 20% of Mozilla for web developers to go back to support ALL browsers. Same for mobile web site a 10% surfing rate got many companies to develop web sites for mobiles. > > If I recall Comcast and Time Warner are participating in IPv6 day. This should create enough eyeballs to show on web analytics graph and provide the shift that makes nat444 irrelevant. > They have not yet deployed to more than a handful of trial customers. In fact, I think TW has not yet started their trials. > For a network operator I'm looking at the ipv6 ipv4 ASN ratio. Once it passes 10% we will have a snow ball effect in the core. > It's just short of 9% today and climbing rapidly. > Toute connaissance est une r?ponse ? une question > The trick is combining the correct knowledge with the right question. Owen From cidr-report at potaroo.net Fri Feb 18 16:00:01 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 18 Feb 2011 22:00:01 GMT Subject: BGP Update Report Message-ID: <201102182200.p1IM01S1016109@wattle.apnic.net> BGP Update Report Interval: 10-Feb-11 -to- 17-Feb-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS7029 23922 1.2% 8.7 -- WINDSTREAM - Windstream Communications Inc 2 - AS17974 20691 1.0% 14.7 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 3 - AS33475 19734 1.0% 91.8 -- RSN-1 - RockSolid Network, Inc. 4 - AS10113 18227 0.9% 98.0 -- DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 5 - AS14522 18063 0.9% 42.5 -- Satnet 6 - AS9829 17630 0.9% 19.6 -- BSNL-NIB National Internet Backbone 7 - AS9498 17392 0.8% 22.4 -- BBIL-AP BHARTI Airtel Ltd. 8 - AS24560 15789 0.8% 14.2 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 9 - AS23681 15777 0.8% 1753.0 -- ITU-TRANSIT-AS-AP Paradox Digital ASN on behalf of IT Universe. To provide BGP interconnects to VIX and Paradox. 10 - AS10620 15310 0.7% 11.1 -- Telmex Colombia S.A. 11 - AS32528 13956 0.7% 1744.5 -- ABBOTT Abbot Labs 12 - AS35931 13736 0.7% 2289.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 13 - AS11492 12831 0.6% 9.8 -- CABLEONE - CABLE ONE, INC. 14 - AS9198 11986 0.6% 25.7 -- KAZTELECOM-AS JSC Kazakhtelecom 15 - AS6389 11866 0.6% 3.2 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 16 - AS27738 11587 0.6% 55.2 -- Ecuadortelecom S.A. 17 - AS1785 11358 0.6% 6.3 -- AS-PAETEC-NET - PaeTec Communications, Inc. 18 - AS28573 10957 0.5% 8.8 -- NET Servicos de Comunicao S.A. 19 - AS174 9538 0.5% 4.5 -- COGENT Cogent/PSI 20 - AS4829 9512 0.5% 9512.0 -- MYTELECOM-PL-AS-AU-AP My Telecom Holdings Pty. Ltd. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS4829 9512 0.5% 9512.0 -- MYTELECOM-PL-AS-AU-AP My Telecom Holdings Pty. Ltd. 2 - AS4858 8370 0.4% 8370.0 -- CORPITA-AS-AP Corpita Pty Ltd 3 - AS35931 13736 0.7% 2289.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 4 - AS49776 2202 0.1% 2202.0 -- GORSET-AS Gorodskaya Set Ltd. 5 - AS49600 1761 0.1% 1761.0 -- LASEDA La Seda de Barcelona, S.A 6 - AS23681 15777 0.8% 1753.0 -- ITU-TRANSIT-AS-AP Paradox Digital ASN on behalf of IT Universe. To provide BGP interconnects to VIX and Paradox. 7 - AS32528 13956 0.7% 1744.5 -- ABBOTT Abbot Labs 8 - AS35738 1685 0.1% 1685.0 -- KVANT-AS Kvant ltd. 9 - AS22289 1582 0.1% 1582.0 -- BARRISTER-GLOBAL - Barrister Global Services Network, Inc. 10 - AS38714 5862 0.3% 1465.5 -- EVISION-AS-AP E-Vision Internet, 11 - AS5572 2065 0.1% 1032.5 -- BOTIK Botik Technologies LTD 12 - AS18188 2008 0.1% 1004.0 -- ATENEO-AS-AP Ateneo de Manila University 13 - AS24491 1574 0.1% 787.0 -- WORLDWEB-THAILAND-AS-AP Internet Service Provider Thailand 14 - AS36952 710 0.0% 710.0 -- KENCALL-EPZ 15 - AS35385 2808 0.1% 702.0 -- QOU Al Quds Open University 16 - AS19743 4628 0.2% 661.1 -- 17 - AS48561 580 0.0% 580.0 -- AUTOMIR-AS NP Automir CJSC 18 - AS35619 569 0.0% 569.0 -- APISNET APIS Ltd. 19 - AS45550 521 0.0% 521.0 -- NGT-AS-VN New Generations Telecommunications Corporation 20 - AS30119 1984 0.1% 496.0 -- TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.92.235.0/24 10928 0.5% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 2 - 202.61.252.0/24 10515 0.4% AS10113 -- DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD AS23681 -- ITU-TRANSIT-AS-AP Paradox Digital ASN on behalf of IT Universe. To provide BGP interconnects to VIX and Paradox. 3 - 202.61.212.0/24 10515 0.4% AS10113 -- DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD AS23681 -- ITU-TRANSIT-AS-AP Paradox Digital ASN on behalf of IT Universe. To provide BGP interconnects to VIX and Paradox. 4 - 202.61.234.0/24 10515 0.4% AS10113 -- DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD AS23681 -- ITU-TRANSIT-AS-AP Paradox Digital ASN on behalf of IT Universe. To provide BGP interconnects to VIX and Paradox. 5 - 203.153.192.0/20 9512 0.4% AS4829 -- MYTELECOM-PL-AS-AU-AP My Telecom Holdings Pty. Ltd. 6 - 63.211.68.0/22 8479 0.3% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 7 - 203.90.24.0/22 8370 0.3% AS4858 -- CORPITA-AS-AP Corpita Pty Ltd 8 - 216.126.136.0/22 8243 0.3% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 9 - 130.36.35.0/24 6970 0.3% AS32528 -- ABBOTT Abbot Labs 10 - 130.36.34.0/24 6966 0.3% AS32528 -- ABBOTT Abbot Labs 11 - 198.140.43.0/24 5151 0.2% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 12 - 208.54.82.0/24 3893 0.2% AS701 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 13 - 68.65.152.0/22 3715 0.1% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 14 - 85.197.100.0/22 3370 0.1% AS25220 -- GLOBALNOC-AS Averbo GmbH 15 - 206.184.16.0/24 3208 0.1% AS174 -- COGENT Cogent/PSI 16 - 202.153.174.0/24 2951 0.1% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 17 - 213.108.216.0/21 2202 0.1% AS49776 -- GORSET-AS Gorodskaya Set Ltd. 18 - 193.232.174.0/24 2062 0.1% AS5572 -- BOTIK Botik Technologies LTD 19 - 213.170.59.0/24 1761 0.1% AS49600 -- LASEDA La Seda de Barcelona, S.A 20 - 80.245.240.0/20 1697 0.1% AS15468 -- KLGELECS-AS ru.klgelecs Local Registry Autonomous System AS35738 -- KVANT-AS Kvant ltd. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Feb 18 16:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 18 Feb 2011 22:00:00 GMT Subject: The Cidr Report Message-ID: <201102182200.p1IM008r016100@wattle.apnic.net> This report has been generated at Fri Feb 18 21:12:00 2011 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 11-02-11 347465 203301 12-02-11 347823 203256 13-02-11 347615 203244 14-02-11 347766 203645 15-02-11 348010 203285 16-02-11 347242 203931 17-02-11 348317 204188 18-02-11 348860 204845 AS Summary 36808 Number of ASes in routing system 15577 Number of ASes announcing only one prefix 3694 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 108778496 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 18Feb11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 349062 204813 144249 41.3% All ASes AS6389 3694 266 3428 92.8% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 2613 410 2203 84.3% TWTC - tw telecom holdings, inc. AS19262 1843 283 1560 84.6% VZGNI-TRANSIT - Verizon Online LLC AS4766 2307 837 1470 63.7% KIXS-AS-KR Korea Telecom AS22773 1268 88 1180 93.1% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1419 341 1078 76.0% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS6478 1510 468 1042 69.0% ATT-INTERNET3 - AT&T Services, Inc. AS1785 1787 763 1024 57.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS28573 1232 309 923 74.9% NET Servicos de Comunicao S.A. AS7545 1629 721 908 55.7% TPG-INTERNET-AP TPG Internet Pty Ltd AS10620 1374 483 891 64.8% Telmex Colombia S.A. AS18566 1433 591 842 58.8% COVAD - Covad Communications Co. AS18101 929 154 775 83.4% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS7303 901 153 748 83.0% Telecom Argentina S.A. AS24560 1113 377 736 66.1% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS4808 1046 323 723 69.1% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS6503 1167 445 722 61.9% Axtel, S.A.B. de C.V. AS3356 1190 490 700 58.8% LEVEL3 Level 3 Communications AS11492 1280 601 679 53.0% CABLEONE - CABLE ONE, INC. AS17488 950 275 675 71.1% HATHWAY-NET-AP Hathway IP Over Cable Internet AS8151 1350 677 673 49.9% Uninet S.A. de C.V. AS9498 764 130 634 83.0% BBIL-AP BHARTI Airtel Ltd. AS17676 651 70 581 89.2% GIGAINFRA Softbank BB Corp. AS855 633 58 575 90.8% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS7552 663 110 553 83.4% VIETEL-AS-AP Vietel Corporation AS4780 767 226 541 70.5% SEEDNET Digital United Inc. AS14420 638 103 535 83.9% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS3549 882 364 518 58.7% GBLX Global Crossing Ltd. AS22047 545 29 516 94.7% VTR BANDA ANCHA S.A. AS9443 570 75 495 86.8% INTERNETPRIMUS-AS-AP Primus Telecommunications Total 38148 10220 27928 73.2% Top 30 total Possible Bogus Routes 5.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 5.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 5.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 24.129.192.0/19 AS7922 COMCAST-7922 - Comcast Cable Communications, Inc. 37.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 37.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 37.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 39.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 41.57.192.0/18 AS22750 BCSNET 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 45.127.0.0/16 AS13767 DBANK - DataBank Holdings, Ltd. 46.31.168.0/21 AS39295 SWIP-AS SWITCH IP LTD 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.18.224.0/20 AS12129 123NET - 123.Net, Inc. 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 72.22.32.0/19 AS33150 72.22.61.0/24 AS33150 72.22.62.0/24 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 91.223.139.0/24 AS8304 AS8304 ECRITEL Company 106.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 110.173.64.0/19 AS37963 CNNIC-ALIBABA-CN-NET-AP Alibaba (China) Technology Co., Ltd. 115.42.28.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.30.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.40.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.42.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.44.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.47.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.48.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.49.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.50.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.51.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.52.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.53.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.54.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.55.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.56.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.57.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.58.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.59.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.61.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.62.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.63.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.54.160.0/24 AS38890 121.54.161.0/24 AS38890 121.54.162.0/24 AS38890 121.54.163.0/24 AS38890 121.54.164.0/24 AS38890 121.54.166.0/24 AS38890 121.54.167.0/24 AS38890 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 172.220.0.0/24 AS28175 176.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 176.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 176.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 180.148.96.0/19 AS45646 OVEE-AS-AP OVEE PTY LTD 181.82.176.224/27 AS45976 CNYGE-AS-KR chungcheongnamdo yeongi office of education 181.82.177.0/26 AS45976 CNYGE-AS-KR chungcheongnamdo yeongi office of education 188.254.128.0/17 AS43205 BULSATCOM-BG-AS Bulsatcom AD 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.101.46.0/24 AS6503 Axtel, S.A.B. de C.V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.145.251.0/24 AS10026 PACNET Pacnet Services (Japan) Corp. 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 193.0.10.0/23 AS3333 RIPE-NCC-AS RIPE Network Coordination Centre 193.0.22.0/23 AS3333 RIPE-NCC-AS RIPE Network Coordination Centre 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.15.4.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.15.5.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.175.231.0/24 AS19262 VZGNI-TRANSIT - Verizon Online LLC 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.24.73.0/24 AS26061 Equant Colombia 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.20.108.0/23 AS17885 JKTXLNET-AS-AP PT Excelcomindo Pratama 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.176.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.146.186.0/24 AS23655 SNAP-NZ-AS Snap Internet Limited 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.130.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.133.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.149.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.150.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.18.156.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.22.78.0/24 AS18117 HARBOURMSP-AU-AP Harbour MSP Pty. Ltd 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.27.123.0/24 AS4739 CIX-ADELAIDE-AS Internode Systems Pty Ltd 203.30.26.0/23 AS3491 BTN-ASN - Beyond The Network America, Inc. 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.10.232.0/21 AS33150 204.19.14.0/23 AS577 BACOM - Bell Canada 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 206.72.192.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.72.194.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.73.160.0/24 AS32767 208.78.165.0/24 AS16565 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.89.60.0/22 AS40626 208.92.196.0/22 AS10929 NETELLIGENT - Netelligent Hosting Services Inc. 208.92.199.0/24 AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.10.235.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.10.236.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From owen at delong.com Fri Feb 18 16:03:13 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 18 Feb 2011 14:03:13 -0800 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6naysayer...) In-Reply-To: <4D5EC38A.4000905@ispalliance.net> References: <5A6D953473350C4B9995546AFE9939EE0BC13C26@RWC-EX1.corp.seven.com> <20110218182151.GA94617@mikea.ath.cx> <5A6D953473350C4B9995546AFE9939EE0BC13C2A@RWC-EX1.corp.seven.com> <4D5EC38A.4000905@ispalliance.net> Message-ID: <619C0B25-D447-4BCD-A369-049B9B413CB3@delong.com> On Feb 18, 2011, at 11:07 AM, Scott Helms wrote: > On 2/18/2011 1:53 PM, Franck Martin wrote: >> http://www.jetcafe.org/~npc/isp/large.html >> >> If you take the 5 top US ISPs and get them to do dual stack IPv6, that's 50 million subscribers in the US only. >> >> I think google and others will notice some serious traffic happening. > We're years from the point where any one of them will have more than a tiny fraction of their traffic as IPv6 and that's assuming that all we have to deal with are the known problems. > If by years, you mean 18 months and by tiny fraction you mean more than 10%, then, sure, you are correct. >> It took a market share of 10 to 20% of Mozilla for web developers to go back to support ALL browsers. Same for mobile web site a 10% surfing rate got many companies to develop web sites for mobiles. > > Not really comparable because in both of those cases users were making a choice, because they perceived some benefit, and hence there was demand to adapt to those new platforms. There is almost 0 demand for IPv6 from consumers and what is there is from the technologists. We don't have a situation where the existing infrastructure doesn't work, it does. > I'm betting that after IPv4 runout, users will continue to perceive a benefit in making the choice to connect to the internet even though they cannot get a unique IPv4 address. >> If I recall Comcast and Time Warner are participating in IPv6 day. This should create enough eyeballs to show on web analytics graph and provide the shift that makes nat444 irrelevant. > > I wish, but IPv6 day will be much more of a media event than anything else. Keep in mind that none of these things are what I wish only what I believe to be accurate. > The problem with this type of belief is that it serves to incite others to inaction, leading it to become a self-fulfilling prophecy. Owen From bensons at queuefull.net Fri Feb 18 16:26:57 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 18 Feb 2011 16:26:57 -0600 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: References: <921881.85954.qm@web114701.mail.gq1.yahoo.com> Message-ID: <813D8351-9884-4820-A10E-BD3B2FB632CE@queuefull.net> On Feb 18, 2011, at 8:27 AM, Owen DeLong wrote: > On Feb 18, 2011, at 12:24 AM, Zed Usser wrote: >> >> There's a bit of critique on the NAT444 document on the BEHAVE IETF WG list. >> >> "draft-donley-nat444-impacts-01 is somewhat misleading. It claims to analyze NAT444, but it really analyzes what fails when two problems occur: (a) port forwarding isn't configured and (b) UPnP is unavailable or is broken. Several architectures share those two problems: >> >> * NAT444 (NAPT44 in the home + NAPT44 in the carrier's network) >> * LSN (NAPT44 in the carrier's network, without a NAPT44 in the home) >> * DS-Lite (which is an LSN / NAPT44 in the carrier's network) >> * stateful NAT64" >> > > I don't think the draft makes any attempt to claim that the problems are unique to NAT444, so, the above, while > technically accurate isn't particulrarly meaningful. The document is titled "Assessing the Impact of NAT444 on Network Applications" and it claims to discuss NAT444 issues. However, it conflates NAT444 with CGN. And it is often used as an explanation for supporting alternative technology such as DS-lite, even though DS-lite also leverages CGN. This line of reasoning is broken and, as I've stated already, I'm waiting for somebody to offer evidence that NAT444 is more problematic than CGN. >> http://www.ietf.org/mail-archive/web/behave/current/msg09027.html >> >> Be that as it may and putting my devil's advocate hat on, aren't the unintended consequences of NAT444 a net win for ISPs? :) >> > I guess that depends on whether you like having customers or not. Yes. And today's customers enjoy being able to communicate with the IPv4 Internet. CGN may be sub-optimal, but it's the lesser of two evils (disconnection being the other choice). Of course, tomorrow morning's customers will enjoy communicating with the IPv6 Internet even more, so as somebody else already said: deploy IPv6 alongside any CGN solution. Cheers, -Benson From owen at delong.com Fri Feb 18 16:26:07 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 18 Feb 2011 14:26:07 -0800 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <480805.6221.qm@web114707.mail.gq1.yahoo.com> References: <480805.6221.qm@web114707.mail.gq1.yahoo.com> Message-ID: <6475D41F-E5F1-4F38-A3C0-BE1A52F6069E@delong.com> On Feb 18, 2011, at 12:50 PM, Zed Usser wrote: > --- On Sat, 2/19/11, Owen DeLong wrote: >> You only need to solve those problems to the >> extent that there are meaningful things still >> trapped in an IPv4-only world. > Are you willing to bet that IPv4 address exhaustion will not result in IPv6-only hosts before we run out of meaningful IPv4-only hosts? > > - Zed > > > No, but, I am willing to bet that we will not meaningfully make the situation better for those IPv4-only hosts or the IPv6-only hosts attempting to reach them by any mechanism more efficient than encouraging them to add IPv6 capability, whether or not that happens after the fact. Owen From leigh.porter at ukbroadband.com Fri Feb 18 16:31:14 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Fri, 18 Feb 2011 22:31:14 +0000 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6naysayer...) In-Reply-To: <480805.6221.qm@web114707.mail.gq1.yahoo.com> References: <480805.6221.qm@web114707.mail.gq1.yahoo.com> Message-ID: <0DFFE3D3-17D6-4D89-B493-620646B954C1@ukbroadband.com> On 18 Feb 2011, at 20:55, "Zed Usser" wrote: > --- On Sat, 2/19/11, Owen DeLong wrote: >> You only need to solve those problems to the >> extent that there are meaningful things still >> trapped in an IPv4-only world. > Are you willing to bet that IPv4 address exhaustion will not result in IPv6-only hosts before we run out of meaningful IPv4-only hosts? > > - Zed > IPv6 only hosts are a good thing to speed up v6 adoption. Nothing like a good carrot to get the donkeys moving. -- Leigh From marcod at acm.org Fri Feb 18 16:32:02 2011 From: marcod at acm.org (Marco F. Delaurenti) Date: Fri, 18 Feb 2011 23:32:02 +0100 Subject: Graph Utils (Open-Source) In-Reply-To: References: Message-ID: <20110218223202.GA3221@adventure-galley> On Fri, Feb 18, 2011 at 01:13:54PM -0600, Max Pierson wrote: > Hi List, > > Anyone out there using something other than rrdtool for creating graphs?? I > have a project that will need a trend taken, and unfortunately rrdtool > doesn't fit the bill. All of the scripting, data collection, > database archival, etc will be custom written or is already done (with some > hacks of course :). So really what i'm looking for is something along the > lines of GNUplot. Has anyone used it before and would like to share > experiences?? Seems like it will be able to my plot data accordingly, but > wanted to see if there were any other popular tools I've yet to come across. If you're searching something like Gnuplot, you could also try GNU R: http://www.r-project.org/ HTH, -- Marco Delaurenti http://about.me/hiraedd {twitter, flickr, posterous}/hiraedd From cnielsen at microsoft.com Fri Feb 18 16:47:31 2011 From: cnielsen at microsoft.com (Christian Nielsen) Date: Fri, 18 Feb 2011 22:47:31 +0000 Subject: Contact for msn.com NOC In-Reply-To: References: <20110218153501.606fac43@jpeach-desktop.anbg.mssm.edu> Message-ID: On Fri, Feb 18, 2011 at 3:35 PM, John Peach wrote: > On Fri, 18 Feb 2011 15:20:30 -0500 > cocoloco wrote: > > > Anyone have a working contact for the msn.com NOC? I tried the email > > listed in Arin - noc at microsoft.com and it bounces back. > > > > Thanks > > > > Dan > > whois msn.com > > Tech Email........... msnhst at microsoft.com > Tech Phone........... +1.4258828080 ioc at microsoft.com From owen at delong.com Fri Feb 18 16:46:23 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 18 Feb 2011 14:46:23 -0800 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <813D8351-9884-4820-A10E-BD3B2FB632CE@queuefull.net> References: <921881.85954.qm@web114701.mail.gq1.yahoo.com> <813D8351-9884-4820-A10E-BD3B2FB632CE@queuefull.net> Message-ID: <7B0A68EE-7E63-4768-816D-9DC491346033@delong.com> On Feb 18, 2011, at 2:26 PM, Benson Schliesser wrote: > > On Feb 18, 2011, at 8:27 AM, Owen DeLong wrote: > >> On Feb 18, 2011, at 12:24 AM, Zed Usser wrote: >>> >>> There's a bit of critique on the NAT444 document on the BEHAVE IETF WG list. >>> >>> "draft-donley-nat444-impacts-01 is somewhat misleading. It claims to analyze NAT444, but it really analyzes what fails when two problems occur: (a) port forwarding isn't configured and (b) UPnP is unavailable or is broken. Several architectures share those two problems: >>> >>> * NAT444 (NAPT44 in the home + NAPT44 in the carrier's network) >>> * LSN (NAPT44 in the carrier's network, without a NAPT44 in the home) >>> * DS-Lite (which is an LSN / NAPT44 in the carrier's network) >>> * stateful NAT64" >>> >> >> I don't think the draft makes any attempt to claim that the problems are unique to NAT444, so, the above, while >> technically accurate isn't particulrarly meaningful. > > The document is titled "Assessing the Impact of NAT444 on Network Applications" and it claims to discuss NAT444 issues. However, it conflates NAT444 with CGN. And it is often used as an explanation for supporting alternative technology such as DS-lite, even though DS-lite also leverages CGN. This line of reasoning is broken and, as I've stated already, I'm waiting for somebody to offer evidence that NAT444 is more problematic than CGN. > NAT444 is one implementation of CGN and the issues it describes all apply to NAT444. It does not claim that it discusses issues unique to NAT444. It claims that all of the issues it discusses apply to NAT444. That claim is accurate. > >>> http://www.ietf.org/mail-archive/web/behave/current/msg09027.html >>> >>> Be that as it may and putting my devil's advocate hat on, aren't the unintended consequences of NAT444 a net win for ISPs? :) >>> >> I guess that depends on whether you like having customers or not. > > Yes. And today's customers enjoy being able to communicate with the IPv4 Internet. CGN may be sub-optimal, but it's the lesser of two evils (disconnection being the other choice). > I remain unconvinced of the accuracy of this statement. > Of course, tomorrow morning's customers will enjoy communicating with the IPv6 Internet even more, so as somebody else already said: deploy IPv6 alongside any CGN solution. > Absolutely. Also, I think the intent of the draft is to serve as a further heads-up to content and application providers that their customer experience in a NAT-444 environment is going to suck and they need to deploy IPv6. Further, it also serves to provide a guide for help-desks to deal with the consequences of having deployed a NAT444 solution in their network. Owen From bensons at queuefull.net Fri Feb 18 17:07:30 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 18 Feb 2011 17:07:30 -0600 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <7B0A68EE-7E63-4768-816D-9DC491346033@delong.com> References: <921881.85954.qm@web114701.mail.gq1.yahoo.com> <813D8351-9884-4820-A10E-BD3B2FB632CE@queuefull.net> <7B0A68EE-7E63-4768-816D-9DC491346033@delong.com> Message-ID: On Feb 18, 2011, at 4:46 PM, Owen DeLong wrote: > On Feb 18, 2011, at 2:26 PM, Benson Schliesser wrote: >> The document is titled "Assessing the Impact of NAT444 on Network Applications" and it claims to discuss NAT444 issues. However, it conflates NAT444 with CGN. And it is often used as an explanation for supporting alternative technology such as DS-lite, even though DS-lite also leverages CGN. This line of reasoning is broken and, as I've stated already, I'm waiting for somebody to offer evidence that NAT444 is more problematic than CGN. >> > NAT444 is one implementation of CGN and the issues it describes all apply to NAT444. > > It does not claim that it discusses issues unique to NAT444. It claims that all of the issues it discusses > apply to NAT444. That claim is accurate. You continue to conflate NAT444 and CGN. I'm not sure I can say anything that hasn't already been said, but perhaps an example will help: Broken DNS will result in problems browsing the web. That doesn't make it accurate to claim that the web is broken, and it's particularly weak support for claims that email would work better. >> Yes. And today's customers enjoy being able to communicate with the IPv4 Internet. CGN may be sub-optimal, but it's the lesser of two evils (disconnection being the other choice). >> > I remain unconvinced of the accuracy of this statement. Well, if your user does nothing but send email then perhaps even UUCP would be good enough. But for the rest of us, until IPv6 penetration reaches all the content/services we care about, we need dual v4+v6 connectivity. Cheers, -Benson From cgrundemann at gmail.com Fri Feb 18 17:27:13 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 18 Feb 2011 16:27:13 -0700 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: References: <921881.85954.qm@web114701.mail.gq1.yahoo.com> <813D8351-9884-4820-A10E-BD3B2FB632CE@queuefull.net> <7B0A68EE-7E63-4768-816D-9DC491346033@delong.com> Message-ID: On Fri, Feb 18, 2011 at 16:07, Benson Schliesser wrote: > Broken DNS will result in problems browsing the web. ?That doesn't make it accurate to claim that the web is broken, and it's particularly weak support for claims that email would work better. I don't think that's a great analogy. NAT444 is CGN, the web is not DNS. If I say I can chop down a tree with a red ax, can you disprove that by saying that you can chop it down with any color ax? > Well, if your user does nothing but send email then perhaps even UUCP would be good enough. ?But for the rest of us, until IPv6 penetration reaches all the content/services we care about, we need dual v4+v6 connectivity. If we get dual v4+v6 connectivity quickly enough, we do not need LSN (including NAT444). Cheers, ~Chris > Cheers, > -Benson > > > > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From cgrundemann at gmail.com Fri Feb 18 17:31:18 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 18 Feb 2011 16:31:18 -0700 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6naysayer...) In-Reply-To: <4D5EC38A.4000905@ispalliance.net> References: <5A6D953473350C4B9995546AFE9939EE0BC13C26@RWC-EX1.corp.seven.com> <20110218182151.GA94617@mikea.ath.cx> <5A6D953473350C4B9995546AFE9939EE0BC13C2A@RWC-EX1.corp.seven.com> <4D5EC38A.4000905@ispalliance.net> Message-ID: On Fri, Feb 18, 2011 at 12:07, Scott Helms wrote: > > We don't have a situation where the existing infrastructure doesn't work, it does. It does today. IPv4 addresses are still freely available today though. As soon as we introduce LSN, the infrastructure starts to stop working. When that happens, IPv6 will have demand. Hopefully we can deploy it before then and avoid the brokeness though... Cheers, ~Chris > -- > Scott Helms > Vice President of Technology > ISP Alliance, Inc. DBA ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From bensons at queuefull.net Fri Feb 18 17:48:25 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 18 Feb 2011 17:48:25 -0600 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: References: <921881.85954.qm@web114701.mail.gq1.yahoo.com> <813D8351-9884-4820-A10E-BD3B2FB632CE@queuefull.net> <7B0A68EE-7E63-4768-816D-9DC491346033@delong.com> Message-ID: <142C67D8-9018-40C6-B052-0C6A577F519C@queuefull.net> On Feb 18, 2011, at 5:27 PM, Chris Grundemann wrote: > On Fri, Feb 18, 2011 at 16:07, Benson Schliesser wrote: > >> Broken DNS will result in problems browsing the web. That doesn't make it accurate to claim that the web is broken, and it's particularly weak support for claims that email would work better. > > I don't think that's a great analogy. NAT444 is CGN, the web is not > DNS. If I say I can chop down a tree with a red ax, can you disprove > that by saying that you can chop it down with any color ax? I agree that it's an imperfect analogy, so I won't bother defending it. :) But my point remains: NAT444 is a deployment scenario, which includes a CGN element. Other deployment scenarios that also include a CGN element will have the same issues, and perhaps more. And, indeed, a number of "transition" (i.e. exhaustion) scenarios include a CGN. Thus it is appropriate to focus on the root of the problem (CGN) rather than pointing at just one scenario that leverages it. So... I agree that CGN is painful, relative to native connectivity and even relative to CPE-based NAT44. But I'd like to understand why NAT444 is better or worse than other CGN-based scenarios, before I agree with that conclusion. > If we get dual v4+v6 connectivity quickly enough, we do not need LSN > (including NAT444). Amen, brother. I guess I'm just pessimistic about the definition of "quickly" versus operationally realistic timeframes. Cheers, -Benson From marka at isc.org Fri Feb 18 18:16:52 2011 From: marka at isc.org (Mark Andrews) Date: Sat, 19 Feb 2011 11:16:52 +1100 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6naysayer...) In-Reply-To: Your message of "Sat, 19 Feb 2011 07:53:52 +1300." References: <5A6D953473350C4B9995546AFE9939EE0BC13C26@RWC-EX1.corp.seven.com> <20110218182151.GA94617@mikea.ath.cx> <5A6D953473350C4B9995546AFE9939EE0BC13C2A@RWC-EX1.corp.seven.com> Message-ID: <20110219001652.E7A61A50C75@drugs.dv.isc.org> In message , Franck Martin wri tes: > http://www.jetcafe.org/~npc/isp/large.html > > If you take the 5 top US ISPs and get them to do dual stack IPv6, that's 50 m > = > illion subscribers in the US only. > > I think google and others will notice some serious traffic happening. > > It took a market share of 10 to 20% of Mozilla for web developers to go back= > to support ALL browsers. Same for mobile web site a 10% surfing rate got ma= > ny companies to develop web sites for mobiles. > > If I recall Comcast and Time Warner are participating in IPv6 day. This shou= > ld create enough eyeballs to show on web analytics graph and provide the shi= > ft that makes nat444 irrelevant. Comcast and Time Warner can enable it, they can't however turn it on in many cases as it requires the customer to do something. > For a network operator I'm looking at the ipv6 ipv4 ASN ratio. Once it passe= > s 10% we will have a snow ball effect in the core. > > Toute connaissance est une r=C3=A9ponse =C3=A0 une question > > >=20 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jg at freedesktop.org Fri Feb 18 18:19:09 2011 From: jg at freedesktop.org (Jim Gettys) Date: Fri, 18 Feb 2011 19:19:09 -0500 Subject: Graph Utils (Open-Source) In-Reply-To: <20110218223202.GA3221@adventure-galley> References: <20110218223202.GA3221@adventure-galley> Message-ID: <4D5F0C7D.9020005@freedesktop.org> On 02/18/2011 05:32 PM, Marco F. Delaurenti wrote: > On Fri, Feb 18, 2011 at 01:13:54PM -0600, Max Pierson wrote: >> Hi List, >> >> Anyone out there using something other than rrdtool for creating graphs?? I >> have a project that will need a trend taken, and unfortunately rrdtool >> doesn't fit the bill. All of the scripting, data collection, >> database archival, etc will be custom written or is already done (with some >> hacks of course :). So really what i'm looking for is something along the >> lines of GNUplot. Has anyone used it before and would like to share >> experiences?? Seems like it will be able to my plot data accordingly, but >> wanted to see if there were any other popular tools I've yet to come across. > > If you're searching something like Gnuplot, you could > also try GNU R: > http://www.r-project.org/ > Also qtiplot an SciDAVIS. Not to mention others such as found on the exhaustive list: http://en.wikipedia.org/wiki/List_of_graphing_software From nmaxpierson at gmail.com Fri Feb 18 18:40:31 2011 From: nmaxpierson at gmail.com (Max Pierson) Date: Fri, 18 Feb 2011 18:40:31 -0600 Subject: Graph Utils (Open-Source) In-Reply-To: <4D5F0C7D.9020005@freedesktop.org> References: <20110218223202.GA3221@adventure-galley> <4D5F0C7D.9020005@freedesktop.org> Message-ID: >Not to mention others such as found on the exhaustive list: >http://en.wikipedia.org/wiki/List_of_graphing_software wow, layer 8 issue on my part :) should have checked wiki before I posted. Thanks Jim and thanks for all the feedback. I believe a combination of Graph.pm and some Perl/PHP foo will do nicely. M On Fri, Feb 18, 2011 at 6:19 PM, Jim Gettys wrote: > On 02/18/2011 05:32 PM, Marco F. Delaurenti wrote: > >> On Fri, Feb 18, 2011 at 01:13:54PM -0600, Max Pierson wrote: >> >>> Hi List, >>> >>> Anyone out there using something other than rrdtool for creating graphs?? >>> I >>> have a project that will need a trend taken, and unfortunately rrdtool >>> doesn't fit the bill. All of the scripting, data collection, >>> database archival, etc will be custom written or is already done (with >>> some >>> hacks of course :). So really what i'm looking for is something along the >>> lines of GNUplot. Has anyone used it before and would like to share >>> experiences?? Seems like it will be able to my plot data accordingly, but >>> wanted to see if there were any other popular tools I've yet to come >>> across. >>> >> >> If you're searching something like Gnuplot, you could >> also try GNU R: >> http://www.r-project.org/ >> >> Also qtiplot an SciDAVIS. > > Not to mention others such as found on the exhaustive list: > > http://en.wikipedia.org/wiki/List_of_graphing_software > > > From cgrundemann at gmail.com Fri Feb 18 19:59:00 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 18 Feb 2011 18:59:00 -0700 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <142C67D8-9018-40C6-B052-0C6A577F519C@queuefull.net> References: <921881.85954.qm@web114701.mail.gq1.yahoo.com> <813D8351-9884-4820-A10E-BD3B2FB632CE@queuefull.net> <7B0A68EE-7E63-4768-816D-9DC491346033@delong.com> <142C67D8-9018-40C6-B052-0C6A577F519C@queuefull.net> Message-ID: On Fri, Feb 18, 2011 at 16:48, Benson Schliesser wrote: > > I agree that it's an imperfect analogy, so I won't bother defending it. :) ?But my point remains: ?NAT444 is a deployment scenario, which includes a CGN element. ?Other deployment scenarios that also include a CGN element will have the same issues, and perhaps more. ?And, indeed, a number of "transition" (i.e. exhaustion) scenarios include a CGN. ?Thus it is appropriate to focus on the root of the problem (CGN) rather than pointing at just one scenario that leverages it. That I'll agree with. It seems to me that what's called for is an expansion of the tests done for the draft in question to include other, currently in-vogue, CGN/LSN technologies. > So... ?I agree that CGN is painful, relative to native connectivity and even relative to CPE-based NAT44. ?But I'd like to understand why NAT444 is better or worse than other CGN-based scenarios, before I agree with that conclusion. That wasn't the conclusion I drew, can't speak for others of course. My conclusion is that CGN/LSN is broken, as evidenced by brokenness in NAT444. I agree that a comparison of all (or some reasonable subset of all) LSN technologies would be valuable, especially as folks may begin to be forced to choose one. For now I stick with the ideal: Avoid if possible. (Dual-stack early, dual-stack often?) >> If we get dual v4+v6 connectivity quickly enough, we do not need LSN >> (including NAT444). > > Amen, brother. ?I guess I'm just pessimistic about the definition of "quickly" versus operationally realistic timeframes. Fair enough, I still have hope. =) ~Chris > Cheers, > -Benson > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From owen at delong.com Sat Feb 19 00:00:00 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 18 Feb 2011 22:00:00 -0800 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: References: <921881.85954.qm@web114701.mail.gq1.yahoo.com> <813D8351-9884-4820-A10E-BD3B2FB632CE@queuefull.net> <7B0A68EE-7E63-4768-816D-9DC491346033@delong.com> <142C67D8-9018-40C6-B052-0C6A577F519C@queuefull.net> Message-ID: <34A73F6D-E441-431F-8251-1CECCD5FA179@delong.com> On Feb 18, 2011, at 5:59 PM, Chris Grundemann wrote: > On Fri, Feb 18, 2011 at 16:48, Benson Schliesser wrote: >> >> I agree that it's an imperfect analogy, so I won't bother defending it. :) But my point remains: NAT444 is a deployment scenario, which includes a CGN element. Other deployment scenarios that also include a CGN element will have the same issues, and perhaps more. And, indeed, a number of "transition" (i.e. exhaustion) scenarios include a CGN. Thus it is appropriate to focus on the root of the problem (CGN) rather than pointing at just one scenario that leverages it. > > That I'll agree with. It seems to me that what's called for is an > expansion of the tests done for the draft in question to include > other, currently in-vogue, CGN/LSN technologies. > That's a serious expansion to the testing matrix. I would rather see those other technologies get their own draft with their own testing matrix as this is far more likely to be achievable. >> So... I agree that CGN is painful, relative to native connectivity and even relative to CPE-based NAT44. But I'd like to understand why NAT444 is better or worse than other CGN-based scenarios, before I agree with that conclusion. > > That wasn't the conclusion I drew, can't speak for others of course. > My conclusion is that CGN/LSN is broken, as evidenced by brokenness in > NAT444. I agree that a comparison of all (or some reasonable subset of > all) LSN technologies would be valuable, especially as folks may begin > to be forced to choose one. For now I stick with the ideal: Avoid if > possible. (Dual-stack early, dual-stack often?) > Agreed. >>> If we get dual v4+v6 connectivity quickly enough, we do not need LSN >>> (including NAT444). >> >> Amen, brother. I guess I'm just pessimistic about the definition of "quickly" versus operationally realistic timeframes. > > Fair enough, I still have hope. =) > ~Chris > My thinking is that faced with disconnection after the fact suddenly causing me to choose between restoration by dual stacking vs. restoration by NAT444 (or almost any other form of LSN) leads any sane person to restoration by dual stacking. Owen From randy at psg.com Sat Feb 19 00:23:47 2011 From: randy at psg.com (Randy Bush) Date: Sat, 19 Feb 2011 14:23:47 +0800 Subject: Libya Message-ID: gossip that libya is off net. any actual data? randy From toasty at dragondata.com Sat Feb 19 00:36:46 2011 From: toasty at dragondata.com (Kevin Day) Date: Sat, 19 Feb 2011 00:36:46 -0600 Subject: Libya In-Reply-To: References: Message-ID: <01545A48-CB3B-4B2E-A8CE-03F937CA4C21@dragondata.com> On Feb 19, 2011, at 12:23 AM, Randy Bush wrote: > gossip that libya is off net. any actual data? > > randy > I was just looking into this myself. http://techcrunch.com/2011/02/18/reports-libya-follows-egypts-lead-starts-shutting-off-internet-services/ http://news.yahoo.com/s/afp/20110218/tc_afp/libyapoliticsunrestinternetfacebook_20110218214522 But I'm still seeing routes announced by AS21003 (Libya Telecom) and http://www.ltt.ly/ loads for me, so if things are blocked they're taking a different approach than Egypt's "SHUT DOWN EVERYTHING" tactic. In my table right now from LTT, all showing some kind of change about 30 minutes ago: 41.208.64.0/18 *[BGP/170] 00:28:54, MED 100, localpref 100 41.252.0.0/14 *[BGP/170] 00:28:54, MED 100, localpref 100 41.252.0.0/18 *[BGP/170] 00:23:48, MED 100, localpref 100 41.252.64.0/18 *[BGP/170] 00:24:46, MED 100, localpref 100 41.252.128.0/18 *[BGP/170] 00:23:48, MED 100, localpref 100 41.252.192.0/18 *[BGP/170] 00:28:54, MED 100, localpref 100 41.254.0.0/24 *[BGP/170] 00:25:33, MED 100, localpref 100 41.254.1.0/24 *[BGP/170] 00:28:54, MED 100, localpref 100 41.254.2.0/24 *[BGP/170] 00:24:46, MED 100, localpref 100 41.254.3.0/24 *[BGP/170] 00:28:54, MED 100, localpref 100 62.68.32.0/19 *[BGP/170] 00:28:54, MED 100, localpref 100 62.240.32.0/19 *[BGP/170] 00:28:54, MED 100, localpref 100 -- Kevin From labovit at gmail.com Sat Feb 19 00:38:08 2011 From: labovit at gmail.com (Craig Labovitz) Date: Sat, 19 Feb 2011 07:38:08 +0100 Subject: Libya In-Reply-To: References: Message-ID: <52C32A9F-5153-4705-A75B-AC3DA08679AF@gmail.com> http://www.monkey.org/~labovit/libya_pulls_plug.png -C Sent from my iPhone On Feb 19, 2011, at 7:23 AM, Randy Bush wrote: > gossip that libya is off net. any actual data? > > randy > From hescominsoon at emmanuelcomputerconsulting.com Sat Feb 19 00:41:24 2011 From: hescominsoon at emmanuelcomputerconsulting.com (William Warren) Date: Sat, 19 Feb 2011 01:41:24 -0500 Subject: Libya In-Reply-To: References: Message-ID: <4D5F6614.4080501@emmanuelcomputerconsulting.com> On 2/19/2011 1:23 AM, Randy Bush wrote: > gossip that libya is off net. any actual data? > > randy > renesys shows libya is offline.. From randy at psg.com Sat Feb 19 00:45:17 2011 From: randy at psg.com (Randy Bush) Date: Sat, 19 Feb 2011 14:45:17 +0800 Subject: Libya In-Reply-To: <52C32A9F-5153-4705-A75B-AC3DA08679AF@gmail.com> References: <52C32A9F-5153-4705-A75B-AC3DA08679AF@gmail.com> Message-ID: thanks, craig luckily, we have no problems like this http://www.boingboing.net/2011/02/17/dhs-erroneously-seiz.html randy From cowie at renesys.com Sat Feb 19 00:59:20 2011 From: cowie at renesys.com (Jim Cowie) Date: Fri, 18 Feb 2011 22:59:20 -0800 Subject: Libya In-Reply-To: <4D5F6614.4080501@emmanuelcomputerconsulting.com> References: <4D5F6614.4080501@emmanuelcomputerconsulting.com> Message-ID: On Fri, Feb 18, 2011 at 10:41 PM, William Warren wrote: > On 2/19/2011 1:23 AM, Randy Bush wrote: >> >> gossip that libya is off net. ?any actual data? >> >> randy >> > renesys shows libya is offline.. > > And .... they're back, 6h52m later. http://www.renesys.com/blog/2011/02/libyan-disconnect-1.shtml --jim From millnert at gmail.com Sat Feb 19 01:06:11 2011 From: millnert at gmail.com (Martin Millnert) Date: Sat, 19 Feb 2011 02:06:11 -0500 Subject: Libya In-Reply-To: References: <52C32A9F-5153-4705-A75B-AC3DA08679AF@gmail.com> Message-ID: On Sat, Feb 19, 2011 at 1:45 AM, Randy Bush wrote: > thanks, craig > > luckily, we have no problems like this > > ? ?http://www.boingboing.net/2011/02/17/dhs-erroneously-seiz.html mm what would we do without these well-functioning blacklists ( http://boingboing.net/2010/09/30/only-17-of-sites-blo.html - 1.7% accuracy, few minutes work emailing - few hours resolution time - clearly the blacklists are doing the job well) Regards, Martin From gbonser at seven.com Sat Feb 19 01:33:25 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 18 Feb 2011 23:33:25 -0800 Subject: Libya In-Reply-To: References: <52C32A9F-5153-4705-A75B-AC3DA08679AF@gmail.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13C54@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Randy Bush [mailto:randy at psg.com] > Sent: Friday, February 18, 2011 10:45 PM > To: Craig Labovitz > Cc: NANOG Operators' Group > Subject: Re: Libya > > thanks, craig > > luckily, we have no problems like this > > http://www.boingboing.net/2011/02/17/dhs-erroneously-seiz.html > > randy Double facepalm http://tinypic.com/r/35irr0g/7 From tvhawaii at shaka.com Sat Feb 19 01:53:24 2011 From: tvhawaii at shaka.com (Michael Painter) Date: Fri, 18 Feb 2011 21:53:24 -1000 Subject: Libya References: Message-ID: <54B50F2A4BD24E708ECC626267180468@DELL16> ----- Original Message ----- From: "Randy Bush" To: "NANOG Operators' Group" Sent: Friday, February 18, 2011 8:23 PM Subject: Libya > gossip that libya is off net. any actual data? > > randy > Scuttlebutt has it that because of 'political unrest', Formula 1 was going to move the upcoming race from Bahrain to ...umm hmm. From gbonser at seven.com Sat Feb 19 01:56:12 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 18 Feb 2011 23:56:12 -0800 Subject: Libya In-Reply-To: <54B50F2A4BD24E708ECC626267180468@DELL16> References: <54B50F2A4BD24E708ECC626267180468@DELL16> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13C55@RWC-EX1.corp.seven.com> > > > gossip that libya is off net. any actual data? > > > > randy > > > > Scuttlebutt has it that because of 'political unrest', Formula 1 was > going to move the upcoming race from Bahrain to > ...umm hmm. > http://www.theregister.co.uk/2011/02/18/bahrain_internet_disruption/ From nanog at studio442.com.au Sat Feb 19 01:57:45 2011 From: nanog at studio442.com.au (Julien Goodwin) Date: Sat, 19 Feb 2011 18:57:45 +1100 Subject: Switch with 10 Gig and GRE support in hardware. In-Reply-To: References: <18886_1298039457_p1IEUpvU024871_93717E08238F7B4392FAD1F82A87FBD3365F2E87@SAT2EXD02.RACKSPACE.CORP> Message-ID: <4D5F77F9.9040103@studio442.com.au> On 19/02/11 01:37, Jeffrey Lyon wrote: > On Fri, Feb 18, 2011 at 9:30 AM, Matt Newsom 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. > Yes, Juniper EX4500. No. from [1] "Layer 3 Protocols Not Supported on EX Series Switches" GRE Not supported 1: http://www.juniper.net/techpubs/en_US/junos10.4/topics/reference/general/ex-series-l3-protocols-not-supported.html From aa at tenet.ac.za Sat Feb 19 02:04:09 2011 From: aa at tenet.ac.za (Andrew Alston) Date: Sat, 19 Feb 2011 10:04:09 +0200 Subject: Libya References: <52C32A9F-5153-4705-A75B-AC3DA08679AF@gmail.com> Message-ID: > http://www.boingboing.net/2011/02/17/dhs-erroneously-seiz.html And people wonder why I have such deep concerns about RPKI.... how long before something like this happens with prefix certificates... ooops... we revoked a few thousand certs for a few thousand prefix's because they happened to have the servers serving 84 thousand domains we shut down by accident.... Nice.... real nice... Andrew From randy at psg.com Sat Feb 19 02:12:36 2011 From: randy at psg.com (Randy Bush) Date: Sat, 19 Feb 2011 16:12:36 +0800 Subject: Libya In-Reply-To: References: <52C32A9F-5153-4705-A75B-AC3DA08679AF@gmail.com> Message-ID: >> http://www.boingboing.net/2011/02/17/dhs-erroneously-seiz.html > And people wonder why I have such deep concerns about RPKI. there are a thousand means. the problem lies with the intent. randy From aa at tenet.ac.za Sat Feb 19 02:15:05 2011 From: aa at tenet.ac.za (Andrew Alston) Date: Sat, 19 Feb 2011 10:15:05 +0200 Subject: Libya References: <52C32A9F-5153-4705-A75B-AC3DA08679AF@gmail.com> Message-ID: >>> http://www.boingboing.net/2011/02/17/dhs-erroneously-seiz.html >> And people wonder why I have such deep concerns about RPKI. > there are a thousand means. the problem lies with the intent. Agreed... doesn't mean its a great idea to create an even easier way to screw up... Andrew From zzuser at yahoo.com Sat Feb 19 02:41:08 2011 From: zzuser at yahoo.com (Zed Usser) Date: Sat, 19 Feb 2011 00:41:08 -0800 (PST) Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <6475D41F-E5F1-4F38-A3C0-BE1A52F6069E@delong.com> Message-ID: <831304.5346.qm@web114714.mail.gq1.yahoo.com> --- On Sat, 2/19/11, Owen DeLong wrote: > >? Are you willing to bet that IPv4 address > exhaustion will not result in IPv6-only hosts before we run > out of meaningful IPv4-only hosts? > No, but, I am willing to bet that we will not meaningfully > make the situation better for those IPv4-only hosts or the IPv6-only > hosts attempting to reach them by any mechanism more efficient > than encouraging them to add IPv6 capability, whether or not > that happens after the fact. So, in essence, you are advocating not to interconnect the IPv4-only and IPv6-only domains in any way? - Zed From owen at delong.com Sat Feb 19 10:08:51 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 19 Feb 2011 08:08:51 -0800 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <831304.5346.qm@web114714.mail.gq1.yahoo.com> References: <831304.5346.qm@web114714.mail.gq1.yahoo.com> Message-ID: <4DD50F56-49FD-4A0F-A6FC-5A9907DBE822@delong.com> On Feb 19, 2011, at 12:41 AM, Zed Usser wrote: > --- On Sat, 2/19/11, Owen DeLong wrote: >>> Are you willing to bet that IPv4 address >> exhaustion will not result in IPv6-only hosts before we run >> out of meaningful IPv4-only hosts? >> No, but, I am willing to bet that we will not meaningfully >> make the situation better for those IPv4-only hosts or the IPv6-only >> hosts attempting to reach them by any mechanism more efficient >> than encouraging them to add IPv6 capability, whether or not >> that happens after the fact. > So, in essence, you are advocating not to interconnect the IPv4-only and IPv6-only domains in any way? > > - Zed > > > > I'm advocating not depending on any such interaction working as it's pretty clear that the available solution set is fairly broken. I'm advocating not expending significant development resources on enhancing that situation when it's pretty clear they are better spent facilitating IPv6 deployment to obviate the need for this level of hackery. Owen From nanogwp at gmail.com Sat Feb 19 10:14:33 2011 From: nanogwp at gmail.com (Robert Lusby) Date: Sat, 19 Feb 2011 16:14:33 +0000 Subject: 123.45.67.89 In-Reply-To: References: Message-ID: Sorry, Google DNS typo is my bad. It is of course 8.8.8.8 ... On Fri, Feb 18, 2011 at 6:20 PM, Christopher Morrow wrote: > On Fri, Feb 18, 2011 at 11:47 AM, Robert Lusby wrote: > > --- Friday miscellaneous --- > > > > Google DNS is a good example (4.4.4.4). > > if you are getting DNS services from 4.4.4.4 you are not getting them > from the-Google... > From smb at cs.columbia.edu Sat Feb 19 10:31:36 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Sat, 19 Feb 2011 11:31:36 -0500 Subject: Libya In-Reply-To: References: <52C32A9F-5153-4705-A75B-AC3DA08679AF@gmail.com> Message-ID: <789BB041-373E-4BE8-B17B-B71A18FC74E4@cs.columbia.edu> On Feb 19, 2011, at 3:12 36AM, Randy Bush wrote: >>> http://www.boingboing.net/2011/02/17/dhs-erroneously-seiz.html >> And people wonder why I have such deep concerns about RPKI. > > there are a thousand means. the problem lies with the intent. > Yes. Remember what happened to Youtube because of (a) a government's intent, and (b) the lack of RPKI. > --Steve Bellovin, http://www.cs.columbia.edu/~smb From kmedcalf at dessus.com Sat Feb 19 12:11:48 2011 From: kmedcalf at dessus.com (kmedcalf at dessus.com) Date: Sat, 19 Feb 2011 13:11:48 -0500 Subject: quietly.... In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9011F76964EA0@PUR-EXCH07.ox.com> Message-ID: <144e2840f3c99449ada5202f81d3b022@mail.dessus.com> And that has nothing to do with whether a protocol is a peer protocol or not. IP is a peer-to-peer protocol. As SMTP is implemented over IP, it is also a peer-to-peer protocol. In IP, all hosts/nodes are peers. That you may wish that this were not the case and thereby impose completely arbitrary "paper based controls" does not in any way change the fact that IP is a peer to peer protocol and that all IP hosts/nodes are peers on the network. Your "paper based controls" are just as effective in turning an IP host/node into a non-peer host/node as is holding up a copy of a restraining order preventing Johhny X from hitting you in the face in front of Johhny's fist just before he breaks your nose. That you believe that your "paper controls" have any effect on reality is saddening. Just because someone writes a bit of paper saying that the moon is made of green cheese does not make it so. Writing on a bit of paper that IP is not a peer-peer protocol does not make it so. If your security is based on such wishful thinking and self-delusion, you really ought to invest in some technical controls that are reality-based and stop with the paper-compliance-tiger as it provides no useful benefit whatsoever. --- ()? ascii ribbon campaign against html e-mail /\? www.asciiribbon.org >-----Original Message----- >From: Matthew Huff [mailto:mhuff at ox.com] >Sent: Thursday, 03 February, 2011 16:41 >To: Matthew Palmer; nanog at nanog.org >Subject: RE: quietly.... > >SMTP is definitely not a p2p protocol in most corporate environments. In ours, >all email (even ones that you would think should be host2host) go to a central >"smarthost" that processes the mail, and archive it for compliance. All >internal to external and external to internal email is tightly controlled and >only goes through a very specific route. > >Again, big difference between a univerisity or ISP environment and a corporate >one. > > > >> -----Original Message----- >> From: Matthew Palmer [mailto:mpalmer at hezmatt.org] >> Sent: Thursday, February 03, 2011 4:00 PM >> To: nanog at nanog.org >> Subject: Re: quietly.... >> >> On Thu, Feb 03, 2011 at 03:20:25PM -0500, Lamar Owen wrote: >> > On Thursday, February 03, 2011 02:28:32 pm Valdis.Kletnieks at vt.edu wrote: >> > > The only reason FTP works through a NAT is because the NAT has already >> > > been hacked up to further mangle the data stream to make up for the >> > > mangling it does. >> > >> > FTP is a in essence a peer-to-peer protocol, as both ends initiate TCP >> > streams. I know that's nitpicking, but it is true. >> >> So is SMTP, by the same token. Aptly demonstrating why the term "P2P" is so >> mind-alteringly stupid. >> >> - Matt > From martin.pels at ams-ix.net Sat Feb 19 12:26:15 2011 From: martin.pels at ams-ix.net (Martin Pels) Date: Sat, 19 Feb 2011 19:26:15 +0100 Subject: Internet Exchange Point(IXP) questions In-Reply-To: <20110218214456.GA72337@ussenterprise.ufp.org> References: <20110218212912.GA71511@ussenterprise.ufp.org> <20110218214456.GA72337@ussenterprise.ufp.org> Message-ID: <20110219192615.3cf1e0a9@fizzix> Hi, On Fri, 18 Feb 2011 13:44:56 -0800 Leo Bicknell wrote: > In a message written on Fri, Feb 18, 2011 at 04:36:28PM -0500, > Christopher Morrow wrote: > > leaking the IX prefix to customers, to me, seems like a recipe for > > much wider/unintended leakage :( > > Oh, it is. I remember when MAE-EAST was injected by at least 50 > people into the DFZ because back then people weren't careful enough > to just send such things to customers. > > AMS-IX (and others) have the better solution. They have AS1200, > announce the exchange LAN from AS1200 (195.69.144.0/22). They will > peer with you if you are at the exchange, see > http://www.ams-ix.net/as1200-peering/. I believe, but can't find > a reference really quick that they get transit for it from a couple > of providers so those that don't peer still have the route. We advertise 195.69.144.0/22 with no-export. Kind regards, Martin From zzuser at yahoo.com Sat Feb 19 13:31:36 2011 From: zzuser at yahoo.com (Zed Usser) Date: Sat, 19 Feb 2011 11:31:36 -0800 (PST) Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <4DD50F56-49FD-4A0F-A6FC-5A9907DBE822@delong.com> Message-ID: <552452.5847.qm@web114715.mail.gq1.yahoo.com> --- On Sun, 2/20/11, Owen DeLong wrote: >>? So, in essence, you are advocating not to >> interconnect the IPv4-only and IPv6-only domains in any way? > > I'm advocating not depending on any such interaction > working as it's pretty clear that > the available solution set is fairly broken. Fair enough. This approach will, however, relegate IPv6-only networks to second class citizenship status. Access to the "real" Internet will require IPv4 and IPv6-only will be seen as the inferior choice, to be avoided as best as you can. Not quite a ringing endorsement for IPv6, in other words. This position also assumes that there will be enough IPv4 addresses to go around for everybody to dual stack. Anybody not so fortunate will simply be left out in the cold. - Zed From eschoedler at viavale.com.br Sat Feb 19 13:41:28 2011 From: eschoedler at viavale.com.br (Eduardo Schoedler) Date: Sat, 19 Feb 2011 17:41:28 -0200 Subject: New transit tests Message-ID: <003101cbd06d$00302900$00907b00$@com.br> Hi everyone. This is my first post here in Nanog. First of all, sorry my bad english -- I'm Brazilian. We are activating a new transit connection with 40 Mbps and I need to test it, but here in Brazil all the international transits are weak. I'm looking for a server that I can download/upload with full speed at New York or Miami, places that this transit have presence in some NAP/IXP (interconnections). Can be one url with a file of 1GB 'dd' generated file, but the server need to have this bandwidth avaliable. Can someone help me ? Thanks in advance. Regards, -- Eduardo Schoedler From dhc2 at dcrocker.net Sat Feb 19 13:42:17 2011 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Sat, 19 Feb 2011 11:42:17 -0800 Subject: quietly.... In-Reply-To: <144e2840f3c99449ada5202f81d3b022@mail.dessus.com> References: <144e2840f3c99449ada5202f81d3b022@mail.dessus.com> Message-ID: <4D601D19.60902@dcrocker.net> On 2/19/2011 10:11 AM, kmedcalf at dessus.com wrote: > > And that has nothing to do with whether a protocol is a peer protocol or not. > IP is a peer-to-peer protocol. As SMTP is implemented over IP, it is also a > peer-to-peer protocol. At each layer of an architecture, the question of whether a mechanism is peer to peer can be newly defined. Even within a layer it can be, depending upon configuration choices. IP is typically /not/ peer to peer, since getting from the originating host to the target host is typically mediated by many routers. That is the essence of /not/ being peer to peer. One layer up, we find that TCP typically /is/ peer-to-peer. "SMTP" as a one-hop email transmission protocol is peer-to-peer from the SMTP client to the corresponding SMTP server. However email exchange from an author's MUA to a recipient's MUA is, again, the essence of /not/ being peer to peer. It is typically massively mediated by lots of different email servers. One could configure two MUAs to talk with each other 'directly' using SMTP, but that's never done. Instant message services similarly are not peer-to-peer technical terms. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From fred at cisco.com Sat Feb 19 15:14:12 2011 From: fred at cisco.com (Fred Baker) Date: Sat, 19 Feb 2011 13:14:12 -0800 Subject: Libya In-Reply-To: References: <52C32A9F-5153-4705-A75B-AC3DA08679AF@gmail.com> Message-ID: <56D50259-0D43-4F6F-B0BB-8C32736B1762@cisco.com> On Feb 19, 2011, at 12:12 AM, Randy Bush wrote: > there are a thousand means. the problem lies with the intent. yes From rene.skjoldmose at gmail.com Sat Feb 19 17:53:58 2011 From: rene.skjoldmose at gmail.com (Rene Skjoldmose) Date: Sun, 20 Feb 2011 00:53:58 +0100 Subject: Graph Utils (Open-Source) In-Reply-To: References: Message-ID: <4D605816.2010503@gmail.com> On 2011-02-18 22:03, Max Pierson wrote: > Nothing at all :) My problem is with rrdtool. It doesn't scale for this > project. I was looking into GNUplot, but wanted to see what else was out > there as well. Is scaling of rrdtool still a problem for you with rrdcached? http://oss.oetiker.ch/rrdtool/doc/rrdcached.en.html Cheers, Ren? From perldork at webwizarddesign.com Sat Feb 19 19:22:21 2011 From: perldork at webwizarddesign.com (Max) Date: Sat, 19 Feb 2011 20:22:21 -0500 Subject: Graph Utils (Open-Source) In-Reply-To: <4D605816.2010503@gmail.com> References: <4D605816.2010503@gmail.com> Message-ID: Even with rrdcached, the I/O from many RRD files being updated often will hammer the I/O subsydtem of most hosts :) We have a host with around 50k RRD data files and rrdcached running, most are updated every 5 mins, some every minute (Nagios + PNP) - with RAID 10 and 10k rpm disks the io wait on the system hangs out at about 15-20 pct, while load hangs around 1-2. I like rrd a lot but scaling it is hard. Max On 2/19/11, Rene Skjoldmose wrote: > On 2011-02-18 22:03, Max Pierson wrote: >> Nothing at all :) My problem is with rrdtool. It doesn't scale for this >> project. I was looking into GNUplot, but wanted to see what else was out >> there as well. > Is scaling of rrdtool still a problem for you with rrdcached? > http://oss.oetiker.ch/rrdtool/doc/rrdcached.en.html > > Cheers, > Ren? > > From perldork at webwizarddesign.com Sat Feb 19 19:25:55 2011 From: perldork at webwizarddesign.com (Max) Date: Sat, 19 Feb 2011 20:25:55 -0500 Subject: Graph Utils (Open-Source) In-Reply-To: References: <4D605816.2010503@gmail.com> Message-ID: Twitter is releasing a high volume metrics collection store based on cassandra as open source soon - if you will be scaling big, might be worth looking into. On 2/19/11, Max wrote: > Even with rrdcached, the I/O from many RRD files being updated often > will hammer the I/O subsydtem of most hosts :) > > We have a host with around 50k RRD data files and rrdcached running, > most are updated every 5 mins, some every minute (Nagios + PNP) - with > RAID 10 and 10k rpm disks the io wait on the system hangs out at about > 15-20 pct, while load hangs around 1-2. > > I like rrd a lot but scaling it is hard. > > Max > > On 2/19/11, Rene Skjoldmose wrote: >> On 2011-02-18 22:03, Max Pierson wrote: >>> Nothing at all :) My problem is with rrdtool. It doesn't scale for >>> this >>> project. I was looking into GNUplot, but wanted to see what else was out >>> there as well. >> Is scaling of rrdtool still a problem for you with rrdcached? >> http://oss.oetiker.ch/rrdtool/doc/rrdcached.en.html >> >> Cheers, >> Ren? >> >> > From swmike at swm.pp.se Sat Feb 19 19:31:24 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 20 Feb 2011 02:31:24 +0100 (CET) Subject: Switch with 10 Gig and GRE support in hardware. In-Reply-To: <18886_1298039457_p1IEUpvU024871_93717E08238F7B4392FAD1F82A87FBD3365F2E87@SAT2EXD02.RACKSPACE.CORP> References: <18886_1298039457_p1IEUpvU024871_93717E08238F7B4392FAD1F82A87FBD3365F2E87@SAT2EXD02.RACKSPACE.CORP> Message-ID: On Fri, 18 Feb 2011, Matt Newsom 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. I'd imagine there is no such beast right now. Only one that comes to mind is the 6500/7600 but there is no fixed-configuration small box that fits your port needs, you need a 7604 to get that amount of ports. -- Mikael Abrahamsson email: swmike at swm.pp.se From joelja at bogus.com Sat Feb 19 19:46:27 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 19 Feb 2011 17:46:27 -0800 Subject: Switch with 10 Gig and GRE support in hardware. In-Reply-To: References: <18886_1298039457_p1IEUpvU024871_93717E08238F7B4392FAD1F82A87FBD3365F2E87@SAT2EXD02.RACKSPACE.CORP> Message-ID: <4D607273.7030600@bogus.com> On 2/19/11 5:31 PM, Mikael Abrahamsson wrote: > On Fri, 18 Feb 2011, Matt Newsom 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. juniper mx80 can get 12x10GB using 2x 4x10Gb mics mx platform does gre in hardware. > I'd imagine there is no such beast right now. Only one that comes to > mind is the 6500/7600 but there is no fixed-configuration small box that > fits your port needs, you need a 7604 to get that amount of ports. From joelja at bogus.com Sat Feb 19 19:51:25 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 19 Feb 2011 17:51:25 -0800 Subject: Switch with 10 Gig and GRE support in hardware. In-Reply-To: <4D607273.7030600@bogus.com> References: <18886_1298039457_p1IEUpvU024871_93717E08238F7B4392FAD1F82A87FBD3365F2E87@SAT2EXD02.RACKSPACE.CORP> <4D607273.7030600@bogus.com> Message-ID: <4D60739D.3050203@bogus.com> On 2/19/11 5:46 PM, Joel Jaeggli wrote: > On 2/19/11 5:31 PM, Mikael Abrahamsson wrote: >> On Fri, 18 Feb 2011, Matt Newsom 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. > > juniper mx80 can get 12x10GB using 2x 4x10Gb mics mx platform does gre > in hardware. appologies it appears only the 2 x 10Gbe mic is supported, so that's 8... >> I'd imagine there is no such beast right now. Only one that comes to >> mind is the 6500/7600 but there is no fixed-configuration small box that >> fits your port needs, you need a 7604 to get that amount of ports. > > > From owen at delong.com Sat Feb 19 20:03:08 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 19 Feb 2011 18:03:08 -0800 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <552452.5847.qm@web114715.mail.gq1.yahoo.com> References: <552452.5847.qm@web114715.mail.gq1.yahoo.com> Message-ID: On Feb 19, 2011, at 11:31 AM, Zed Usser wrote: > --- On Sun, 2/20/11, Owen DeLong wrote: >>> So, in essence, you are advocating not to >>> interconnect the IPv4-only and IPv6-only domains in any way? >> >> I'm advocating not depending on any such interaction >> working as it's pretty clear that >> the available solution set is fairly broken. > Fair enough. This approach will, however, relegate IPv6-only networks to second class citizenship status. Access to the "real" Internet will require IPv4 and IPv6-only will be seen as the inferior choice, to be avoided as best as you can. Not quite a ringing endorsement for IPv6, in other words. > > This position also assumes that there will be enough IPv4 addresses to go around for everybody to dual stack. Anybody not so fortunate will simply be left out in the cold. > > - Zed > > > Oh, I expect CGN/LSN to be connectivity of last resort, no question. However, I don't expect it to work. I don't expect us to be able to resolve the issues with it, and I expect that to fairly rapidly serve as motivation for content providers to adopt IPv6. Owen From owen at delong.com Sat Feb 19 20:15:25 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 19 Feb 2011 18:15:25 -0800 Subject: quietly.... In-Reply-To: <4D601D19.60902@dcrocker.net> References: <144e2840f3c99449ada5202f81d3b022@mail.dessus.com> <4D601D19.60902@dcrocker.net> Message-ID: <53EE2F9C-7E9B-42E1-A059-D87FB7EF7F01@delong.com> My understanding of peer-to-peer was that it indicated that all hosts had equal ability to originate or terminate (as in accept, not as in end) sessions. That is, the role of client or server is defined by the choice of the application and/or software on the host and not by the network. IP is a peer to peer network because all nodes are equal at the protocol level. IP does not make a protocol-level distinction between clients or servers. See: http://en.wikipedia.org/wiki/Peer-to-peer Noting specifically from http://en.wikipedia.org/wiki/Client-server#Comparison_to_peer-to-peer_architecture It would appear to me that IP is, by definition peer to peer while TCP seems inherently client-server in most implementations and UDP is ambiguous and can be used in either mode, as in DNS where a recursive resolver operates simultaneously as both a server and a client or peer and an authoritative server with secondaries also operates simultaneously as a server and as a peer. You are correct about the peer to peer or not nature of an architecture being possibly different at different layers, but, I don't think you are right in saying that having routers in between makes two IP nodes not peers. Owen On Feb 19, 2011, at 11:42 AM, Dave CROCKER wrote: > > > On 2/19/2011 10:11 AM, kmedcalf at dessus.com wrote: >> >> And that has nothing to do with whether a protocol is a peer protocol or not. >> IP is a peer-to-peer protocol. As SMTP is implemented over IP, it is also a >> peer-to-peer protocol. > > > At each layer of an architecture, the question of whether a mechanism is peer to > peer can be newly defined. Even within a layer it can be, depending upon > configuration choices. > > IP is typically /not/ peer to peer, since getting from the originating host to > the target host is typically mediated by many routers. That is the essence of > /not/ being peer to peer. > > One layer up, we find that TCP typically /is/ peer-to-peer. > > "SMTP" as a one-hop email transmission protocol is peer-to-peer from the SMTP > client to the corresponding SMTP server. However email exchange from an > author's MUA to a recipient's MUA is, again, the essence of /not/ being peer to > peer. It is typically massively mediated by lots of different email servers. > > One could configure two MUAs to talk with each other 'directly' using SMTP, but that's never done. > > Instant message services similarly are not peer-to-peer technical terms. > > d/ > > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net From dhc2 at dcrocker.net Sat Feb 19 21:32:27 2011 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Sat, 19 Feb 2011 19:32:27 -0800 Subject: quietly.... In-Reply-To: <144e2840f3c99449ada5202f81d3b022@mail.dessus.com> References: <144e2840f3c99449ada5202f81d3b022@mail.dessus.com> Message-ID: <4D608B4B.3000208@dcrocker.net> On 2/19/2011 10:11 AM, kmedcalf at dessus.com wrote: > > And that has nothing to do with whether a protocol is a peer protocol or not. > IP is a peer-to-peer protocol. As SMTP is implemented over IP, it is also a > peer-to-peer protocol. At each layer of an architecture, the question of whether a mechanism is peer to peer can be newly defined. Even within a layer it can be, depending upon configuration choices. IP is typically /not/ peer to peer, since getting from the originating host to the target host is typically mediated by many routers. That is the essence of /not/ being peer to peer. One layer up, we find that TCP typically /is/ peer-to-peer. "SMTP" as a one-hop email transmission protocol is peer-to-peer from the SMTP client to the corresponding SMTP server. However email exchange from an author's MUA to a recipient's MUA is, again, the essence of /not/ being peer to peer. It is typically massively mediated by lots of different email servers. One could configure two MUAs to talk with each other 'directly' using SMTP, but that's never done. Instant message services similarly are not peer-to-peer technical terms. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jra at baylink.com Sat Feb 19 21:48:08 2011 From: jra at baylink.com (Jay Ashworth) Date: Sat, 19 Feb 2011 22:48:08 -0500 (EST) Subject: Libya In-Reply-To: <789BB041-373E-4BE8-B17B-B71A18FC74E4@cs.columbia.edu> Message-ID: <9912673.566.1298173688662.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Steven Bellovin" > On Feb 19, 2011, at 3:12 36AM, Randy Bush wrote: > >>> http://www.boingboing.net/2011/02/17/dhs-erroneously-seiz.html > >> And people wonder why I have such deep concerns about RPKI. > > > > there are a thousand means. the problem lies with the intent. > > > Yes. Remember what happened to Youtube because of (a) a government's > intent, and (b) the lack of RPKI. This is true. But since no one ever seems to be RFC 3514[1] compliant, it's necessary to attempt to intuit intent from behavior. This works equally poorly in nearly all arenas. Cheers, -- jr 'capability creep is a bitch' a [1] pleased to discover that my memory served up the correct number on the first try. From diogo.montagner at gmail.com Sat Feb 19 22:00:38 2011 From: diogo.montagner at gmail.com (Diogo Montagner) Date: Sun, 20 Feb 2011 12:00:38 +0800 Subject: New transit tests In-Reply-To: <003101cbd06d$00302900$00907b00$@com.br> References: <003101cbd06d$00302900$00907b00$@com.br> Message-ID: Hi Eduardo, don't expect you will be able to download a single connection at 40Mbps. Your test will be limited by the latency. You can do some tweak in the TCP but it will not improve too much considering the latency between BR and US. Here are two links which can give you some directions: http://en.wikipedia.org/wiki/Measuring_network_throughput http://www.speedguide.net/bdp.php HTH ./diogo -montagner On Sun, Feb 20, 2011 at 3:41 AM, Eduardo Schoedler wrote: > Hi everyone. > > This is my first post here in Nanog. > First of all, sorry my bad english -- I'm Brazilian. > > We are activating a new transit connection with 40 Mbps and I need to test > it, but here in Brazil all the international transits are weak. > I'm looking for a server that I can download/upload with full speed at New > York or Miami, places that this transit have presence in some NAP/IXP > (interconnections). > Can be one url with a file of 1GB 'dd' generated file, but the server need > to have this bandwidth avaliable. > > Can someone help me ? > > Thanks in advance. > > Regards, > > -- > Eduardo Schoedler > > > From swmike at swm.pp.se Sat Feb 19 22:38:57 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 20 Feb 2011 05:38:57 +0100 (CET) Subject: New transit tests In-Reply-To: References: <003101cbd06d$00302900$00907b00$@com.br> Message-ID: On Sun, 20 Feb 2011, Diogo Montagner wrote: > Your test will be limited by the latency. You can do some tweak in the > TCP but it will not improve too much considering the latency between BR > and US. With 200ms delay he only needs 1 megabyte of TCP window to reach 40 megabit/s. This is definitely not out of reach in case the transport is loss free. The world speed record a few years ago was approximately 10 gigabit/s in a single TCP session, I don't know if someone has bested that yet. -- Mikael Abrahamsson email: swmike at swm.pp.se From matt.newsom at RACKSPACE.COM Sun Feb 20 00:00:22 2011 From: matt.newsom at RACKSPACE.COM (Matt Newsom) Date: Sun, 20 Feb 2011 06:00:22 +0000 Subject: Switch with 10 Gig and GRE support in hardware. In-Reply-To: <4D60739D.3050203@bogus.com> References: <18886_1298039457_p1IEUpvU024871_93717E08238F7B4392FAD1F82A87FBD3365F2E87@SAT2EXD02.RACKSPACE.CORP> <4D607273.7030600@bogus.com> <4D60739D.3050203@bogus.com> Message-ID: <13702_1298181629_p1K60NTu008696_93717E08238F7B4392FAD1F82A87FBD3365F4961@SAT2EXD02.RACKSPACE.CORP> Those are the two options I am looking at now. Unfortunately both of those require the chassis tax and a decent amount of real estate and power. It looks like that is what I am going to be stuck with though because I can't seem to find anyone that has small 1-2U solution that can do the full shake and bake. -----Original Message----- From: Joel Jaeggli [mailto:joelja at bogus.com] Sent: Saturday, February 19, 2011 7:51 PM To: Mikael Abrahamsson Cc: nanog at nanog.org Subject: Re: Switch with 10 Gig and GRE support in hardware. On 2/19/11 5:46 PM, Joel Jaeggli wrote: > On 2/19/11 5:31 PM, Mikael Abrahamsson wrote: >> On Fri, 18 Feb 2011, Matt Newsom 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. > > juniper mx80 can get 12x10GB using 2x 4x10Gb mics mx platform does gre > in hardware. appologies it appears only the 2 x 10Gbe mic is supported, so that's 8... >> I'd imagine there is no such beast right now. Only one that comes to >> mind is the 6500/7600 but there is no fixed-configuration small box that >> fits your port needs, you need a 7604 to get that amount of ports. > > > Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse at rackspace.com, and delete the original message. Your cooperation is appreciated. From mksmith at adhost.com Sun Feb 20 00:05:43 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Sun, 20 Feb 2011 06:05:43 +0000 Subject: Switch with 10 Gig and GRE support in hardware. In-Reply-To: <18886_1298039457_p1IEUpvU024871_93717E08238F7B4392FAD1F82A87FBD3365F2E87@SAT2EXD02.RACKSPACE.CORP> Message-ID: Potentially the Cisco 4900M. I can't find specifically about the GRE support however. My google-fu just finds discussion about v4 to v6 tunnels in software. The chassis has 8 built-in ports and two expansion modules that can each do another 4 TenG ports in a not-oversubscribed configuration. Mike -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) On 2/18/11 6:30 AM, "Matt Newsom" 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. > > >Confidentiality Notice: This e-mail message (including any attached or >embedded documents) is intended for the exclusive and confidential use of >the >individual or entity to which this message is addressed, and unless >otherwise >expressly indicated, is confidential and privileged information of >Rackspace. >Any dissemination, distribution or copying of the enclosed material is >prohibited. >If you receive this transmission in error, please notify us immediately >by e-mail >at abuse at rackspace.com, and delete the original message. >Your cooperation is appreciated. > From mksmith at adhost.com Sun Feb 20 00:07:53 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Sun, 20 Feb 2011 06:07:53 +0000 Subject: ipv6 transit over tunneled connection In-Reply-To: Message-ID: I have both Level3 and NTT v6 connections and there are no additional charges for the service. I recall NTT had one a few years ago, but I think that's fallen by the wayside. Mike -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) On 2/17/11 7:01 PM, "Jack Carrozzo" wrote: >We pick up v6 from HE currently (like the rest of the world). L3 offered >us >dual stack also, but they wanted money to set it up plus MRC. None of our >Bits That Matter (tm) go over v6 anyhow. (I guess the right phrase would >be >"revenue producing bits"). > >-Jack Carrozzo > >On Mon, May 17, 2010 at 9:51 AM, Eric Van Tol wrote: > >> > -----Original Message----- >> > From: Jared Mauch [mailto:jared at puck.nether.net] >> > Sent: Friday, May 14, 2010 2:49 PM >> > To: Jack Carrozzo >> > Cc: nanog at nanog.org >> > Subject: Re: ipv6 transit over tunneled connection >> > >> > I'm curious what providers have not gotten their IPv6 >> > plans/networks/customer ports enabled. >> > >> > I know that Comcast is doing their trials now (Thanks John!) and will >>be >> > presenting at the upcoming NANOG about their experiences. >> > >> > What parts of the big "I" Internet are not enabled or ready? >> > >> >> We don't see Savvis, Level3, or AboveNet with IPv6 capabilities in our >> region (DC). Two years ago, neither Verizon or AT&T had IPv6, either. >>Not >> sure about them now, as we no longer use them for transit. One would >>think >> everyone would have v6 capabilities in the heart of government >>territory, >> but okay. >> >> For whatever reason, Verio actually charges (or used to) for their IPv6 >> separately from IPv4 and to top it all off, it wasn't significantly >> discounted. >> >> -evt >> >> >> From matt.newsom at RACKSPACE.COM Sun Feb 20 00:19:32 2011 From: matt.newsom at RACKSPACE.COM (Matt Newsom) Date: Sun, 20 Feb 2011 06:19:32 +0000 Subject: Switch with 10 Gig and GRE support in hardware. In-Reply-To: References: <18886_1298039457_p1IEUpvU024871_93717E08238F7B4392FAD1F82A87FBD3365F2E87@SAT2EXD02.RACKSPACE.CORP> Message-ID: <20862_1298182779_p1K6JX2d011053_93717E08238F7B4392FAD1F82A87FBD3365F49A9@SAT2EXD02.RACKSPACE.CORP> The 4900M doesn't do GRE in hardware. -----Original Message----- From: Michael K. Smith - Adhost [mailto:mksmith at adhost.com] Sent: Sunday, February 20, 2011 12:06 AM To: Matt Newsom; NANOG list Subject: Re: Switch with 10 Gig and GRE support in hardware. Potentially the Cisco 4900M. I can't find specifically about the GRE support however. My google-fu just finds discussion about v4 to v6 tunnels in software. The chassis has 8 built-in ports and two expansion modules that can each do another 4 TenG ports in a not-oversubscribed configuration. Mike -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) On 2/18/11 6:30 AM, "Matt Newsom" 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. > > >Confidentiality Notice: This e-mail message (including any attached or >embedded documents) is intended for the exclusive and confidential use of >the >individual or entity to which this message is addressed, and unless >otherwise >expressly indicated, is confidential and privileged information of >Rackspace. >Any dissemination, distribution or copying of the enclosed material is >prohibited. >If you receive this transmission in error, please notify us immediately >by e-mail >at abuse at rackspace.com, and delete the original message. >Your cooperation is appreciated. > Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse at rackspace.com, and delete the original message. Your cooperation is appreciated. From zzuser at yahoo.com Sun Feb 20 05:27:57 2011 From: zzuser at yahoo.com (Zed Usser) Date: Sun, 20 Feb 2011 03:27:57 -0800 (PST) Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: Message-ID: <857967.14970.qm@web114719.mail.gq1.yahoo.com> --- On Sun, 2/20/11, Owen DeLong wrote: > Oh, I expect CGN/LSN to be connectivity of last resort, no > question. Ok, so let's just deploy it and not even try to fix it? Even when it is a required functionality for IPv6-only hosts to access the IPv4 domain? That'll go down real well with end-users and really cut down on the operational and support issues enumerated earlier. - Zed From lukasz at bromirski.net Sun Feb 20 09:04:17 2011 From: lukasz at bromirski.net (=?ISO-8859-2?Q?=A3ukasz_Bromirski?=) Date: Sun, 20 Feb 2011 16:04:17 +0100 Subject: Switch with 10 Gig and GRE support in hardware. In-Reply-To: References: <18886_1298039457_p1IEUpvU024871_93717E08238F7B4392FAD1F82A87FBD3365F2E87@SAT2EXD02.RACKSPACE.CORP> Message-ID: <4D612D71.8050407@bromirski.net> On 2011-02-18 15:37, Jeffrey Lyon 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. > Yes, Juniper EX4500. Interesting: http://www.juniper.net/techpubs/en_US/junos10.4/topics/reference/general/ex-series-l3-protocols-not-supported.html -- "There's no sense in being precise when | ?ukasz Bromirski you don't know what you're talking | jid:lbromirski at jabber.org about." John von Neumann | http://lukasz.bromirski.net From Greg.Whynott at oicr.on.ca Sun Feb 20 09:46:47 2011 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Sun, 20 Feb 2011 10:46:47 -0500 Subject: Switch with 10 Gig and GRE support in hardware. In-Reply-To: <4D612D71.8050407@bromirski.net> Message-ID: Extreme 650, but not sure of the gre in hardware req. These are awesome switches, bgp support, VSS like clustering, and many other nice features. G ----- Original Message ----- From: ?ukasz Bromirski [mailto:lukasz at bromirski.net] Sent: Sunday, February 20, 2011 10:04 AM To: nanog at nanog.org Subject: Re: Switch with 10 Gig and GRE support in hardware. On 2011-02-18 15:37, Jeffrey Lyon 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. > Yes, Juniper EX4500. Interesting: http://www.juniper.net/techpubs/en_US/junos10.4/topics/reference/general/ex-series-l3-protocols-not-supported.html -- "There's no sense in being precise when | ?ukasz Bromirski you don't know what you're talking | jid:lbromirski at jabber.org about." John von Neumann | http://lukasz.bromirski.net -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. From straterra at fuhell.com Sun Feb 20 10:01:13 2011 From: straterra at fuhell.com (Thomas York) Date: Sun, 20 Feb 2011 11:01:13 -0500 Subject: Off list contact for Quadranet Message-ID: If the network contact at Quadranet could contact me off list, I'd appreciate it. This is concerning the continual spamming of a proxy server I run from multiple hosts at Quadranet. Thomas York -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6400 bytes Desc: not available URL: From karim.adel at gmail.com Sun Feb 20 10:05:44 2011 From: karim.adel at gmail.com (Kasper Adel) Date: Sun, 20 Feb 2011 18:05:44 +0200 Subject: Software Bugs Message-ID: Good Day, I have always been exposed to one vendor only so i can never compare but I am curious to know what every one here have seen in their lives on the below: 1) Which vendor has more bugs than others, what are the top 3 2) Who is doing a better job fixing them 3) What do you consider is a good job in fixing these bugs : response from technical support, educated support engineers From karim.adel at gmail.com Sun Feb 20 10:10:02 2011 From: karim.adel at gmail.com (Kasper Adel) Date: Sun, 20 Feb 2011 18:10:02 +0200 Subject: Software Bugs In-Reply-To: References: Message-ID: Good Day, I have always been exposed to one vendor only so i can never compare but I am curious to know what every one here have seen in their lives on the below: 1) Which vendor has more bugs than others, what are the top 3 ? 2) Who is doing a better job fixing/handling these bugs overall 3) What do you consider is a good job in fixing/handling these bugs : A) Response from technical support B) Educated support engineers being able to respond to questions C) Taking less time to identify bugs D) Less time in fixing them E) Transparent communication on their issues F) Transparency from their teams allow us to plan better for our network G) etc.....please add more 4) Specially Huawei, are they doing a good job or its a mess? I would like to try to do some rating and ranking when it comes to bugs but i need to know what i have to be looking at? Regards, Kim From jra at baylink.com Sun Feb 20 10:26:47 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 20 Feb 2011 11:26:47 -0500 (EST) Subject: VZW LTE provisioning Message-ID: <13340258.640.1298219207082.JavaMail.root@benjamin.baylink.com> Is there anyone on the list who can comment, on- or off-list, for-attribution or not, on what kind of job Verizon Wireless has done provisioning the data backbone for their new LTE "4G"[1] rollout? Given the fact that it is at 700MHz and will therefore have *substantially* better building penetration, and the fact that -- due to the Google imposed "any device, any app" restrictions the FCC placed on their license -- there is quite a bit higher possibility that we'll see better device competition on this service than we've seen before... the odds that we'll have to deal with it, as operators of larger end-networks, seem pretty high. Knowing what we're getting into would be nice. :-) Cheers, -- jra [1] The ITU has said that none of {HSDPA,LTE,WiMax} qualifies for "4G" designation by the standards, of which they (I understand) are the promulgating agency. From owen at delong.com Sun Feb 20 11:08:43 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 20 Feb 2011 09:08:43 -0800 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <857967.14970.qm@web114719.mail.gq1.yahoo.com> References: <857967.14970.qm@web114719.mail.gq1.yahoo.com> Message-ID: <83F83E4B-B03E-44B5-8F39-2D94219A1C54@delong.com> On Feb 20, 2011, at 3:27 AM, Zed Usser wrote: > --- On Sun, 2/20/11, Owen DeLong wrote: >> Oh, I expect CGN/LSN to be connectivity of last resort, no >> question. > Ok, so let's just deploy it and not even try to fix it? Even when it is a required functionality for IPv6-only hosts to access the IPv4 domain? That'll go down real well with end-users and really cut down on the operational and support issues enumerated earlier. > > - Zed > > > Again, I think that it is unfixable and that development efforts are better focused on getting the IPv4 only hosts onto IPv6 as that IS a workable solution to the problem where NAT444 is an awful hack made worse by layering. IPv6 deployment is the only thing that will cut down on the operational and support issues enumerated. Trying to fix NAT444 is like trying to use more gas to get yourself out of the mud in a 2-wheel drive automobile. If you take a limited view, you might think that pushing harder will help, but, in reality, you're just digging a deeper hole. Owen From nmaxpierson at gmail.com Sat Feb 19 19:58:13 2011 From: nmaxpierson at gmail.com (Max Pierson) Date: Sat, 19 Feb 2011 19:58:13 -0600 Subject: Graph Utils (Open-Source) In-Reply-To: <4D605816.2010503@gmail.com> References: <4D605816.2010503@gmail.com> Message-ID: >Is scaling of rrdtool still a problem for you with rrdcached? This helps on some of my network/server related graphs, but this data is not exactly time based (well timestamps are recorded, but not at cyclic intervals). Plus the dataset is extremely large (100's of millions or rows already in mySQL). This isn't really network or server related metrics i'm trying to plot. Regards, Max On Sat, Feb 19, 2011 at 5:53 PM, Rene Skjoldmose wrote: > On 2011-02-18 22:03, Max Pierson wrote: > >> Nothing at all :) My problem is with rrdtool. It doesn't scale for this >> project. I was looking into GNUplot, but wanted to see what else was out >> there as well. >> > Is scaling of rrdtool still a problem for you with rrdcached? > http://oss.oetiker.ch/rrdtool/doc/rrdcached.en.html > > Cheers, > Ren? > > From tammy-lists at wiztech.biz Sun Feb 20 12:22:27 2011 From: tammy-lists at wiztech.biz (Tammy A Wisdom) Date: Sun, 20 Feb 2011 11:22:27 -0700 Subject: Switch with 10 Gig and GRE support in hardware. In-Reply-To: References: Message-ID: <5E903B49-F23C-462C-A016-DE8F20EAB1D7@wiztech.biz> Ugh they're nice except for the power supplies becoming a fireball & they're high dos rate. Ymmv Tammy Sent from my iPhone On Feb 20, 2011, at 8:46, Greg Whynott wrote: > Extreme 650, but not sure of the gre in hardware req. These are awesome switches, bgp support, VSS like clustering, and many other nice features. > > G > > > ----- Original Message ----- > From: ?ukasz Bromirski [mailto:lukasz at bromirski.net] > Sent: Sunday, February 20, 2011 10:04 AM > To: nanog at nanog.org > Subject: Re: Switch with 10 Gig and GRE support in hardware. > > On 2011-02-18 15:37, Jeffrey Lyon 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. >> Yes, Juniper EX4500. > > Interesting: > http://www.juniper.net/techpubs/en_US/junos10.4/topics/reference/general/ex-series-l3-protocols-not-supported.html > > -- > "There's no sense in being precise when | ?ukasz Bromirski > you don't know what you're talking | jid:lbromirski at jabber.org > about." John von Neumann | http://lukasz.bromirski.net > > > -- > > This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. ****************************************************************************** Disclaimer: This e-mail may contain trade secrets or privileged, undisclosed or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation. ****************************************************************************** From tammy-lists at wiztech.biz Sun Feb 20 12:32:31 2011 From: tammy-lists at wiztech.biz (Tammy A. Wisdom) Date: Sun, 20 Feb 2011 11:32:31 -0700 (MST) Subject: Switch with 10 Gig and GRE support in hardware. In-Reply-To: <5E903B49-F23C-462C-A016-DE8F20EAB1D7@wiztech.biz> Message-ID: <93be0b06-9284-4064-b66f-6419f295202d@lordsofacid.wiztech.biz> Gah that should have read doa rate. @#$@#$ing autocorrect. sorry about that. ----- Original Message ----- > From: "Tammy A Wisdom" > To: "Greg Whynott" > Cc: nanog at nanog.org > Sent: Sunday, February 20, 2011 11:22:27 AM > Subject: Re: Switch with 10 Gig and GRE support in hardware. > > Ugh they're nice except for the power supplies becoming a fireball & > they're high dos rate. Ymmv > Tammy > > Sent from my iPhone > > On Feb 20, 2011, at 8:46, Greg Whynott > wrote: > > > Extreme 650, but not sure of the gre in hardware req. These are > > awesome switches, bgp support, VSS like clustering, and many > > other nice features. > > > > G > > > > > > ----- Original Message ----- > > From: ?ukasz Bromirski [mailto:lukasz at bromirski.net] > > Sent: Sunday, February 20, 2011 10:04 AM > > To: nanog at nanog.org > > Subject: Re: Switch with 10 Gig and GRE support in hardware. > > > > On 2011-02-18 15:37, Jeffrey Lyon 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. > >> Yes, Juniper EX4500. > > > > Interesting: > > http://www.juniper.net/techpubs/en_US/junos10.4/topics/reference/general/ex-series-l3-protocols-not-supported.html > > > > -- > > "There's no sense in being precise when | ?ukasz > > Bromirski > > you don't know what you're talking | > > jid:lbromirski at jabber.org > > about." John von Neumann | > > http://lukasz.bromirski.net > > > > > > -- > > > > This message and any attachments may contain confidential and/or > > privileged information for the sole use of the intended recipient. > > Any review or distribution by anyone other than the person for > > whom it was originally intended is strictly prohibited. If you > > have received this message in error, please contact the sender and > > delete all copies. Opinions, conclusions or other information > > contained in this message may not be that of the organization. > > ****************************************************************************** > Disclaimer: > > This e-mail may contain trade secrets or privileged, undisclosed or > otherwise confidential information. If you have received this e-mail > in error, you are hereby notified that any review, copying or > distribution of it is strictly prohibited. Please inform us > immediately and destroy the original transmittal. Thank you for your > cooperation. > > ****************************************************************************** > > > ****************************************************************************** Disclaimer: This e-mail may contain trade secrets or privileged, undisclosed or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation. ****************************************************************************** From Valdis.Kletnieks at vt.edu Sun Feb 20 13:43:36 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 20 Feb 2011 14:43:36 -0500 Subject: Software Bugs In-Reply-To: Your message of "Sun, 20 Feb 2011 18:05:44 +0200." References: Message-ID: <59302.1298231016@localhost> On Sun, 20 Feb 2011 18:05:44 +0200, Kasper Adel said: (Disclaimer - I've never filed a bug report with Cisco or Juniper, but I've spent 3 decades filing bugs with almost everybody else in the computer industry, it seems... Questions like the ones you asked are almost always pointless unless the asker and answerer are sharing a set of base assumptions. In other words, "which one is best/worst?" is a meaningless question unless you either tell us what *your* criteria are in detail, or are willing to listen to advice that uses other criteria (without stating how they're different from yours). > 1) Which vendor has more bugs than others, what are the top 3 More actual bugs, more known and acknowledged bugs, or more serious bugs that actually affect day to day operations in a major manner? The total number of actual bugs for each vendor is probably unknownable, other than "there's at least one more in there". The vendor probably can produce a number representing how many bug reports they've accepted as valid. The vendor's number is guaranteed to be different than the customer's number - how divergent, *and why*, probably tells you a lot about the vendor and the customer base. The vendor may be difficult about accepting a bug report, or the customer base may be clueless about what the product is supposed to be doing and calling in a lot of non-bugs - almost every trouble ticket closed with RTFM status is one of these non-bugs. If there's a lot of non-bugs, it usually indicates a documentation/training issue, not an actual software quality issue. And of course, bug severity *has* to be considered. "Router falls over if somebody in Zimbabwe sends it a christmas-tree packet" is different than "the CLI insists on a ;; where a ; should suffice". You may be willing to tolerate or work around dozens or even hundreds of the latter (in fact, there's probably hundreds of such bugs in your current vendor that you don't know about simply because they don't trigger in your environment), but it only takes 2 or 3 of the former to render the box undeployable. > 2) Who is doing a better job fixing them Again, see the above discussion of severity. If a vendor is good about fixing the real show-stoppers in a matter of hours or days, but has a huge backlog of fixes for minor things, is that better or worse than a vendor that fixes half of both serious and minor things? In addition, the question of how fixes get deployed matters too. If a vendor is consistently good about finding a root cause, fixing it, and then saying "we'll ship the fix in the next dot-rev release", is that good or bad? Remember that if they ship a new, updated, more-fixed image every week, that means you get to re-qualify a new image every week.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From gbonser at seven.com Sun Feb 20 14:15:20 2011 From: gbonser at seven.com (George Bonser) Date: Sun, 20 Feb 2011 12:15:20 -0800 Subject: Switch with 10 Gig and GRE support in hardware. In-Reply-To: <20862_1298182779_p1K6JX2d011053_93717E08238F7B4392FAD1F82A87FBD3365F49A9@SAT2EXD02.RACKSPACE.CORP> References: <18886_1298039457_p1IEUpvU024871_93717E08238F7B4392FAD1F82A87FBD3365F2E87@SAT2EXD02.RACKSPACE.CORP> <20862_1298182779_p1K6JX2d011053_93717E08238F7B4392FAD1F82A87FBD3365F49A9@SAT2EXD02.RACKSPACE.CORP> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13C5D@RWC-EX1.corp.seven.com> > On 2/18/11 6:30 AM, "Matt Newsom" 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. From gbonser at seven.com Sun Feb 20 14:22:20 2011 From: gbonser at seven.com (George Bonser) Date: Sun, 20 Feb 2011 12:22:20 -0800 Subject: Software Bugs In-Reply-To: <59302.1298231016@localhost> References: <59302.1298231016@localhost> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13C5E@RWC-EX1.corp.seven.com> > > 2) Who is doing a better job fixing them > > Again, see the above discussion of severity. If a vendor is good about > fixing the real show-stoppers in a matter of hours or days, but has a > huge backlog of fixes for minor things, is that better or worse than a > vendor that fixes half of both serious and minor things? > > In addition, the question of how fixes get deployed matters too. If a > vendor is consistently good about finding a root cause, fixing it, and > then saying "we'll ship the fix in the next dot-rev release", is that > good or bad? > Remember that if they ship a new, updated, more-fixed image every week, > that means you get to re-qualify a new image every week.... That also changes over time. A vendor that might have been slow to fix bugs 5 years ago might be completely different today or a vendor that was particularly buggy 5 years ago might be rock solid today and the opposite is also true. Vendors can put out buggy stuff when they had been very stable. Use cases also vary widely and a portion of the software that might be very buggy for some feature set might be completely transparent to you because you don't use those features. The question is widely variable and very dependent on the deployment. Generally, the simpler you build your network, the less bugs you are going to run into. The more features you use, the more likely you are to run into them. From karim.adel at gmail.com Sun Feb 20 17:44:44 2011 From: karim.adel at gmail.com (Kasper Adel) Date: Mon, 21 Feb 2011 01:44:44 +0200 Subject: Software Bugs In-Reply-To: <59302.1298231016@localhost> References: <59302.1298231016@localhost> Message-ID: Thanks Valdis. On Sun, Feb 20, 2011 at 9:43 PM, wrote: > On Sun, 20 Feb 2011 18:05:44 +0200, Kasper Adel said: > > (Disclaimer - I've never filed a bug report with Cisco or Juniper, > but I've spent 3 decades filing bugs with almost everybody else in > the computer industry, it seems... Questions like the ones you asked > are almost always pointless unless the asker and answerer are sharing > a set of base assumptions. In other words, "which one is best/worst?" > is a meaningless question unless you either tell us what *your* criteria > are in detail, or are willing to listen to advice that uses other > criteria (without stating how they're different from yours). > I tried to put details and criteria below and yes i am mainly interested in Juniper, Cisco, Alcatel and Huawei Routers and Switches, mostly High End Equipment and yes i am willing to listen to advice on criteria, why wouldnt I :) ? > > > 1) Which vendor has more bugs than others, what are the top 3 > > More actual bugs, more known and acknowledged bugs, or more serious bugs > that > actually affect day to day operations in a major manner? > What i wanted to ask is from the field experience of experts on the alias if there is a clear winner on which vendor has throughout history shown more bugs impacting operation and interrupting traffic....poor written code or bad internal testing, can we have some sort of a general assumption here or that is not possible? > > The total number of actual bugs for each vendor is probably unknownable, > other > than "there's at least one more in there". The vendor probably can produce > a > number representing how many bug reports they've accepted as valid. The > vendor's number is guaranteed to be different than the customer's number - > how > divergent, *and why*, probably tells you a lot about the vendor and the > customer base. The vendor may be difficult about accepting a bug report, or > the > customer base may be clueless about what the product is supposed to be > doing > and calling in a lot of non-bugs - almost every trouble ticket closed with > RTFM > status is one of these non-bugs. If there's a lot of non-bugs, it usually > indicates a documentation/training issue, not an actual software quality > issue. > > And of course, bug severity *has* to be considered. "Router falls over if > somebody in Zimbabwe sends it a christmas-tree packet" is different than > "the > CLI insists on a ;; where a ; should suffice". You may be willing to > tolerate > or work around dozens or even hundreds of the latter (in fact, there's > probably > hundreds of such bugs in your current vendor that you don't know about > simply > because they don't trigger in your environment), but it only takes 2 or 3 > of > the former to render the box undeployable. > > > 2) Who is doing a better job fixing them > > Again, see the above discussion of severity. If a vendor is good about > fixing > the real show-stoppers in a matter of hours or days, but has a huge backlog > of > fixes for minor things, is that better or worse than a vendor that fixes > half > of both serious and minor things? > > In addition, the question of how fixes get deployed matters too. If a > vendor > is consistently good about finding a root cause, fixing it, and then saying > "we'll ship the fix in the next dot-rev release", is that good or bad? > Remember that if they ship a new, updated, more-fixed image every week, > that > means you get to re-qualify a new image every week.... > > What you have mentioned is operations headache, so one questions comes to mind here is what are issues a vendor will never be able to find in their internal testing, i mean are there issues that will definitely be discovered on the customer networks or we can assume that software needs to come out with less number of sev1/2 bugs because internal testing is not doing a good job? thanks From jra at baylink.com Sun Feb 20 20:31:13 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 20 Feb 2011 21:31:13 -0500 (EST) Subject: [dnsext] zone cut semantics In-Reply-To: <06E17E6C-B8B7-47B5-A4A7-28BEBC9DE968@rfc1035.com> Message-ID: <9617566.814.1298255473149.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jim Reid" > On 21 Feb 2011, at 01:44, Jay Ashworth wrote: > > > So: people-who-do: is my supposition/assertion above correct? If it is, > > is it reasonable to draw from it the inference that I do (IE, that Jim is > > correct and Brandon's not)? > > It's more than reasonable Jay: it's true! Then again, I would say > that. :-) > > But don't take my word for it. See for yourself. Query the parent > zone's name servers and the child's for the zone's NS RRset. Look who > sets and does not set the AA bit. You've misunderstood the granularity of my question, though, Jim. :-) I asked not what the default behavior was, but *whether it was even manually possible to override* that default behavior. I believe it is not, which would serve as much stronger evidence for your case. > You will of course need to use a decent lookup tool like dig to do > this. Or you could just read Section 6 of RFC2181. Brandon clearly > hasn't. :-) Yes; I know how to drive dig. +trace is *really* cool, in fact. I've been wanting to wrap +trace for nagios, so I can monitor my registries/registrars. :-) > BTW, BIND8 got zone cut semantics wrong. It used one monolithic data > structure (a hash table) for everything. [BIND9 uses discrete red- > black trees for each zone.] So the parent would set the AA bit in a > referral response even though it shouldn't have done that. This > incorrect behaviour broke things and also permitted zone and server > misconfigurations to appear to work: for instance no NS records in the > child. Another weird error this caused was phantom A records that > didn't exist in either the parent or child zone files! Secure DNS put > an end to this brokenness -- and as a side effect killed BIND8 -- > because it demands much stricter (and correct) zone cut sematics. Good you made a point of this discrepancy. When you say, though, that this permitted child zones to have no NS records in them, I presume you mean "when the same server is serving both the parent and the child in question"? Cheers, -- jra From mpetach at netflight.com Sun Feb 20 21:01:06 2011 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 20 Feb 2011 19:01:06 -0800 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6naysayer...) In-Reply-To: <0DFFE3D3-17D6-4D89-B493-620646B954C1@ukbroadband.com> References: <480805.6221.qm@web114707.mail.gq1.yahoo.com> <0DFFE3D3-17D6-4D89-B493-620646B954C1@ukbroadband.com> Message-ID: On Fri, Feb 18, 2011 at 2:31 PM, Leigh Porter wrote: > ... > > IPv6 only hosts are a good thing to speed up v6 adoption. Nothing like a good carrot to get the donkeys moving. > > -- > Leigh > Well, speaking of carrots...a few years back we _did_ have http://ipv6experiment.com/ though, unfortunately, the original content of the experiment has changed somewhat, and the delta between the A record and the quad-A has diminished. :/ Would be nice to see if someone was willing to host some v6-only content, and see what level of penetration was achieved... Matt From mysidia at gmail.com Sun Feb 20 22:45:02 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 20 Feb 2011 22:45:02 -0600 Subject: Graph Utils (Open-Source) In-Reply-To: References: Message-ID: On Fri, Feb 18, 2011 at 1:13 PM, Max Pierson wrote: > Anyone out there using something other than rrdtool for creating graphs?? I > have a project that will need a trend taken, and unfortunately rrdtool > doesn't fit the bill. All of the scripting, data collection, > database archival, etc will be custom written or is already done (with some > hacks of course :). So really what i'm looking for is something along the > lines of GNUplot. Has anyone used it before and would like to share I haven't heard of gnuplot used often with other software as a framework for graphing/visualizations. For simple visualizations, I think usually a 'native' framework/API is preferred, e.g. JGraph for java apps. I suspect one reason gnuplot is not used as widely as it could be otherwise is, its licensing is not as "friendly" as other graphics frameworks. gnuplot license is GPL incompatible and does not seem to even fully meet the open source definition, Because redistributing complete modified source code of gnuplot itself is not allowed by the license; a clear reading of gnuplot license suggests only patches, unmodified source code, can be freely redistributed, redistributed binaries based on modified source have special rules). Aside from that caveat, which most likely does not normally impair private use by a network operator: gnuplot is a really good tool. If you need to paint a bunch of arbitrary X and Y values on a graph from an input file or based on simple equations, gnuplot will happily oblige; it can handle chart types rrdtool cannot, and you have more direct control of output. If you want some 3D / surface graphs, RRDTool won't do it, anyways. Gnuplot's less expensive than Matlab / Maple. You can even set terminal type to "dumb" in gnuplot, and generate some fancy ASCII art graphs on stdout. In regards to scalability... About the millions of rows... err.. Try plotting a test dataset with 500 million datapoints. Chances are gnuplot won't necessarily scale that well either, and you need some method to be selective of which rows are provided as input to the plotting framework, in that case. If you have a million datapoints on your X axis, each X position is smaller than 1/1000 of a display pixel (on a graph that fits on a display at say 1920x1080); displaying such high resolution of all datapoints at once on the unzoomed graph is beyond the display hardware capabilitiy. there should normally be some form of averaging / smoothing / "selection of points" contemplated, if the dataset is huge > experiences?? Seems like it will be able to my plot data accordingly, but > wanted to see if there were any other popular tools I've yet to come across. > > (Open-Source only please) -- -JH From mysidia at gmail.com Mon Feb 21 00:35:09 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 21 Feb 2011 00:35:09 -0600 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <921881.85954.qm@web114701.mail.gq1.yahoo.com> References: <9F8063EB-C9A3-444D-B9CB-7CA12BEE335E@puck.nether.net> <921881.85954.qm@web114701.mail.gq1.yahoo.com> Message-ID: On Fri, Feb 18, 2011 at 2:24 AM, Zed Usser wrote: > Basic Internet services will work (web browsing, email, Facebook, Youtube,...), but: > - Less torrenting > - Less Netflix watching > - Less FTP downloads > - Less video streaming in general (webcams, etc.) > You might take a hit on online gaming, but what else is there not to love? :) > Your sales department / helpdesk might have a bit of hassle of trying to undestand / explain this new Intertubes to the suck^H^H^H^Hcustomers, but most of them won't care either way. Until some competitor who's not using NAT444 comes along and advertises that those functions work properly, maybe. Only for very liberal definitions of the phrase "won't care either way" Tolerate != won't care Most of them != People who won't eventually tell their friends or tweet about their frustrations For those who are connecting to watch Netflix, it is only marginally less annoying for the user than removing the "always on" feature of DSL, requiring customers to manually click an icon to dial in, and get a busy tone played / "All dialin 'lines are busy'" / "Please use IPv6 while you wait, wait 10 minutes and try dialing in again", if there are no global IPv4 IPs available at the moment they are trying to connect. Some might even strongly prefer that (time limited access and pay per connected hour) for periods of access to proper unique IPs over NAT444 brokenness; possibly with a customer choice between NAT444 and "time metered dynamic unique IP" and reasonably automatic simple means of switching between IP types on demand. -- -JH From owen at delong.com Mon Feb 21 02:48:30 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 21 Feb 2011 00:48:30 -0800 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: References: <9F8063EB-C9A3-444D-B9CB-7CA12BEE335E@puck.nether.net> <921881.85954.qm@web114701.mail.gq1.yahoo.com> Message-ID: On Feb 20, 2011, at 10:35 PM, Jimmy Hess wrote: > On Fri, Feb 18, 2011 at 2:24 AM, Zed Usser wrote: >> Basic Internet services will work (web browsing, email, Facebook, Youtube,...), but: Actually, many facebook and youtube features will also be degraded. >> - Less torrenting >> - Less Netflix watching >> - Less FTP downloads >> - Less video streaming in general (webcams, etc.) >> You might take a hit on online gaming, but what else is there not to love? :) > You're joking, right? I don't think that most customers are going to take kindly to having their internet experience on their computer(s) reduced to what they expect from their cell phone. >> Your sales department / helpdesk might have a bit of hassle of trying to undestand / explain this new Intertubes to the suck^H^H^H^Hcustomers, but most of them won't care either way. > > Until some competitor who's not using NAT444 comes along and > advertises that those functions work properly, maybe. > Only for very liberal definitions of the phrase "won't care either way" > > Tolerate != won't care > Most of them != People who won't eventually tell their friends or > tweet about their frustrations > Nah... Just make sure tweeting is one of the things you break along with the rest of the itner-tubes. (joking, of course). > > For those who are connecting to watch Netflix, it is only marginally > less annoying for the user than > removing the "always on" feature of DSL, requiring customers to > manually click an icon to dial in, > and get a busy tone played / "All dialin 'lines are busy'" / "Please > use IPv6 while you wait, > wait 10 minutes and try dialing in again", if there are no global > IPv4 IPs available at the moment > they are trying to connect. > As long as you give them IPv6, their Netflix and Youtube will work. > Some might even strongly prefer that (time limited access and pay > per connected hour) > for periods of access to proper unique IPs over NAT444 brokenness; > You guys are making me very very glad that I: 1. Do not depend on my provider for IPv4 addresses. 2. Have a fully dual-stack environment at home. 3. Do not depend on my residential provider to deliver anything more than the ability to shove GRE across the internet encapsulated in whatever protocol (v4/v6) works at the time. > possibly with a customer choice between NAT444 and "time metered > dynamic unique IP" and reasonably > automatic simple means of switching between IP types on demand. > I encourage my competitors to try this. Owen From mir at ripe.net Mon Feb 21 07:36:19 2011 From: mir at ripe.net (Mirjam Kuehne) Date: Mon, 21 Feb 2011 14:36:19 +0100 Subject: Traffic to 5/8 and 37/8 - stats on RIPE Labs Message-ID: <4D626A53.9060808@ripe.net> Hello, During NANOG 51, Manish Karir gave a Lightning Talk showing how much and what kind of traffic is going to unallocated address space in 5/8 and 37/8 (among other ranges he tested). This is now also available on RIPE Labs: http://labs.ripe.net/Members/mkarir/first-impressions-of-pollution-in-two-ripe-ncc-darknets Kind Regards, Mirjam Kuehne RIPE NCC From ryan at u13.net Mon Feb 21 08:24:47 2011 From: ryan at u13.net (Ryan Rawdon) Date: Mon, 21 Feb 2011 09:24:47 -0500 Subject: Traffic to 5/8 and 37/8 - stats on RIPE Labs In-Reply-To: <4D626A53.9060808@ripe.net> References: <4D626A53.9060808@ripe.net> Message-ID: <2B31E6E7-60FA-4636-8C55-1B2241760224@u13.net> Doesn't the LogMeIn Hamachi "VPN service" use 5.0.0.0/8? Perhaps the spikes to 5.5.5.0/24 or the space in general are from fluctuations or waves of disconnects of Hamachi users, so when they are disconnected their Hamachi traffic heads out in to the DFZ? This service is particularly popular amongst gamers who like to play LAN games over the Internet when Internet play is not possible, which could account for the diverse set of source addresses and UDP traffic (and I'm sure a long tail of other applications/uses) I can't say I am terribly familiar with the service, but it is one of the first things that came to mind when reading the RIPE writeup. It would be interesting to see what the distribution of source/destination ports are in the traffic headed into 5/8 or 5.5.5.0/24 to see if they can be correlated to common games or applications that may be used over Hamachi. On Feb 21, 2011, at 8:36 AM, Mirjam Kuehne wrote: > Hello, > > During NANOG 51, Manish Karir gave a Lightning Talk showing how much and what kind of traffic is going to unallocated address space in 5/8 and 37/8 (among other ranges he tested). > > This is now also available on RIPE Labs: > > http://labs.ripe.net/Members/mkarir/first-impressions-of-pollution-in-two-ripe-ncc-darknets > > Kind Regards, > Mirjam Kuehne > RIPE NCC > From sysoleg at yandex.ru Mon Feb 21 10:55:07 2011 From: sysoleg at yandex.ru (Oleg A. Arkhangelsky) Date: Mon, 21 Feb 2011 19:55:07 +0300 Subject: Traffic to 5/8 and 37/8 - stats on RIPE Labs In-Reply-To: <4D626A53.9060808@ripe.net> References: <4D626A53.9060808@ripe.net> Message-ID: <581331298307307@web26.yandex.ru> Hello, > http://labs.ripe.net/Members/mkarir/first-impressions-of-pollution-in-two-ripe-ncc-darknets Quote from the link: > Note that in the 37/8, most traffic comes from TTLs around 100. These are Linux hosts. > The smaller humps are at ~32 (Windows) and ~250 (Solaris). I don't agree. TTL around 100 is most probably Windows hosts with initial TTL of 128. Everything below 64 can be Linux or FreeBSD. ~250 can be Solaris host but Cisco IOS also set initial TTL to 255. -- wbr, Oleg. From labovit at gmail.com Mon Feb 21 11:44:48 2011 From: labovit at gmail.com (Craig Labovitz) Date: Mon, 21 Feb 2011 12:44:48 -0500 Subject: Libya In-Reply-To: References: <52C32A9F-5153-4705-A75B-AC3DA08679AF@gmail.com> Message-ID: <9D059D07-95C4-47AA-B156-6A1613AF9935@gmail.com> Updated data on Libya and other Internet traffic issues in the region: http://goo.gl/07ONC - Craig From obriapqz at bc.edu Mon Feb 21 12:21:36 2011 From: obriapqz at bc.edu (Christopher O'Brien) Date: Mon, 21 Feb 2011 13:21:36 -0500 Subject: Graph Utils (Open-Source) In-Reply-To: References: Message-ID: <4D62AD30.9070806@bc.edu> On 02/20/11 23:45, Jimmy Hess wrote: > On Fri, Feb 18, 2011 at 1:13 PM, Max Pierson wrote: >> Anyone out there using something other than rrdtool for creating graphs?? I >> have a project that will need a trend taken, and unfortunately rrdtool >> doesn't fit the bill. All of the scripting, data collection, >> database archival, etc will be custom written or is already done (with some >> hacks of course :). So really what i'm looking for is something along the >> lines of GNUplot. Has anyone used it before and would like to share > > I haven't heard of gnuplot used often with other software as a framework > for graphing/visualizations. For simple visualizations, I think usually a > 'native' framework/API is preferred, e.g. JGraph for java apps. > > I suspect one reason gnuplot is not used as widely as it could be otherwise > is, its licensing is not as "friendly" as other graphics frameworks. > gnuplot license is GPL incompatible and does not seem to even fully meet > the open source definition, > > Because redistributing complete modified source code of gnuplot itself > is not allowed by the license; a clear reading of gnuplot license suggests > only patches, unmodified source code, can be freely redistributed, > redistributed binaries based on modified source have special rules). > > > Aside from that caveat, which most likely does not normally impair private > use by a network operator: gnuplot is a really good tool. > If you need to paint a bunch of arbitrary X and Y values on a graph from > an input file or based on simple equations, gnuplot will happily > oblige; it can > handle chart types rrdtool cannot, and you have more direct control of output. > > If you want some 3D / surface graphs, RRDTool won't do it, anyways. > Gnuplot's less expensive > than Matlab / Maple. > > You can even set terminal type to "dumb" in gnuplot, and generate some fancy > ASCII art graphs on stdout. > > > In regards to scalability... > > About the millions of rows... err.. > Try plotting a test dataset with 500 million datapoints. Chances > are gnuplot won't > necessarily scale that well either, and you need some method to be > selective of which rows are > provided as input to the plotting framework, in that case. > > If you have a million datapoints on your X axis, each X position is > smaller than 1/1000 of > a display pixel (on a graph that fits on a display at say 1920x1080); > displaying such high resolution of all datapoints at once on the > unzoomed graph is beyond > the display hardware capabilitiy. > > there should normally be some form of averaging / smoothing / > "selection of points" contemplated, > if the dataset is huge > >> experiences?? Seems like it will be able to my plot data accordingly, but >> wanted to see if there were any other popular tools I've yet to come across. >> >> (Open-Source only please) > > -- > -JH > If you can use Java, JfreeChart is pretty nice. It has the ability to create many different types of charts/grpahs. I've only used it a little bit for a project I was looking into that uses it, but it seems really capable. I think it's licensed under gpl or lgpl, but the creator charges for documentation/examples if you need them. http://www.jfree.org/jfreechart/ From dwing at cisco.com Mon Feb 21 14:37:50 2011 From: dwing at cisco.com (Dan Wing) Date: Mon, 21 Feb 2011 12:37:50 -0800 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> <4C060A07-4FA7-467B-8BA8-8D4D04A0BA9A@queuefull.net> Message-ID: <117f01cbd207$34f42290$9edc67b0$@com> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Chris Grundemann > Sent: Thursday, February 17, 2011 5:55 PM > To: Benson Schliesser > Cc: NANOG list; ARIN-PPML List > Subject: Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 > naysayer...) > > On Thu, Feb 10, 2011 at 14:17, Benson Schliesser > wrote: > > > If you have more experience (not including rumors) that suggests > otherwise, I'd very much like to hear about it. ?I'm open to the > possibility that NAT444 breaks stuff - that feels right in my gut - but > I haven't found any valid evidence of this. > > In case you have not already found this: > http://tools.ietf.org/html/draft-donley-nat444-impacts-01 That document conflates problems of NAT444 with problems of NAT44 with problems of bandwidth starvation with problems of CGN. For details, see my comments at http://www.ietf.org/mail-archive/web/behave/current/msg09027.html and see Reinaldo Penno's comments at http://www.ietf.org/mail-archive/web/behave/current/msg09030.html -d > Cheers, > ~Chris > > > > > Regardless, I think we can agree that IPv6 is the way to avoid NAT- > related growing pains. ?We've known this for a long time. > > > > Cheers, > > -Benson > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > > > > > > > -- > @ChrisGrundemann > weblog.chrisgrundemann.com > www.burningwiththebush.com > www.theIPv6experts.net > www.coisoc.org > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From kate at quadranet.com Mon Feb 21 14:41:57 2011 From: kate at quadranet.com (Kate Gerry) Date: Mon, 21 Feb 2011 12:41:57 -0800 Subject: Contact for APEWS.org? Message-ID: <4B4120B1642DCF48ACA84E4F82C8E1F65A9961CE50@EXCH> We've been advised by a client that they're incorrectly listing a /15. The listing is: (E-431420) 96.44.0.0/15 According to their FAQ they only take delistings via newsgroups and Google News isn't co-operating with me in regards to them. Meanwhilst we're affected with our range 96.44.128.0/18. -- Kate QuadraNet, Inc 530 W 6th Street #901 Los Angeles, CA 90014 kate at quadranet.com From owen at delong.com Mon Feb 21 14:58:45 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 21 Feb 2011 12:58:45 -0800 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <117f01cbd207$34f42290$9edc67b0$@com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> <4C060A07-4FA7-467B-8BA8-8D4D04A0BA9A@queuefull.net> <117f01cbd207$34f42290$9edc67b0$@com> Message-ID: <41EE506B-D6BA-4AB5-A211-41BFE114F70E@delong.com> On Feb 21, 2011, at 12:37 PM, Dan Wing wrote: >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of Chris Grundemann >> Sent: Thursday, February 17, 2011 5:55 PM >> To: Benson Schliesser >> Cc: NANOG list; ARIN-PPML List >> Subject: Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 >> naysayer...) >> >> On Thu, Feb 10, 2011 at 14:17, Benson Schliesser >> wrote: >> >>> If you have more experience (not including rumors) that suggests >> otherwise, I'd very much like to hear about it. I'm open to the >> possibility that NAT444 breaks stuff - that feels right in my gut - but >> I haven't found any valid evidence of this. >> >> In case you have not already found this: >> http://tools.ietf.org/html/draft-donley-nat444-impacts-01 > > That document conflates problems of NAT444 with problems of NAT44 > with problems of bandwidth starvation with problems of CGN. > > For details, see my comments at > http://www.ietf.org/mail-archive/web/behave/current/msg09027.html > and see Reinaldo Penno's comments at > http://www.ietf.org/mail-archive/web/behave/current/msg09030.html > > -d > The document describes problems that will exist in NAT444 environments. It does not state that these problems would be specific to NAT444, but, NAT444 will cause or exacerbate each of the problems described. Yes, the problems may have other underlying root causes, but, they will all be present in a NAT444 environment, even if they were not present in the same environment prior to deployment of NAT444. Let me put it this way... IPv4 has a TITANIC lack of numeric addresses and has been stretched beyond its limits for some time now. IPv6 is a life boat. NAT is a seat cushion used for floatation. NAT444 (and other NAT-based extensions) are deck chairs. Attempting to improve them beyond their current states is an effort to rearrange the deck chairs. Owen From bruns at 2mbit.com Mon Feb 21 15:04:46 2011 From: bruns at 2mbit.com (Brielle Bruns) Date: Mon, 21 Feb 2011 14:04:46 -0700 Subject: Contact for APEWS.org? In-Reply-To: <4B4120B1642DCF48ACA84E4F82C8E1F65A9961CE50@EXCH> References: <4B4120B1642DCF48ACA84E4F82C8E1F65A9961CE50@EXCH> Message-ID: <4D62D36E.4040400@2mbit.com> On 2/21/11 1:41 PM, Kate Gerry wrote: > We've been advised by a client that they're incorrectly listing a > /15. The listing is: > > (E-431420) 96.44.0.0/15 > > According to their FAQ they only take delistings via newsgroups and > Google News isn't co-operating with me in regards to them. Meanwhilst > we're affected with our range 96.44.128.0/18. > Kate, It is unlikely you will find a direct contact for APEWS - your best bet is to get access to usenet through one of the Usenet providers or even through aioe or eternal-september. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From lists at iamchriswallace.com Mon Feb 21 15:10:19 2011 From: lists at iamchriswallace.com (Chris Wallace) Date: Mon, 21 Feb 2011 16:10:19 -0500 Subject: BGP Failover Question Message-ID: <49274CE9-307A-4C36-B311-01B42DD0C735@iamchriswallace.com> I am looking for some help with an issue we recently had with one of our BGP peers recently. I currently have two DIA providers each terminated into their own edge router and I am doing iBGP to exchange routes between the two edge routers. Last week Provider A made a policy change "somewhere" in their network in the middle of the day causing traffic to stop routing. Of course this connection happens to be the preferred route for the majority of our inbound and outbound traffic. I never saw our physical link go down and never saw our peer drop therefore BGP did not stop advertising routes, this caused most of our customers traffic to go nowhere. In order to fix the issue I had to manually shutdown the peer till Provider A confirmed the change they made had been reverted. This isn't the first time we have seen this issue with our various providers, how can I prevent issues like this from happening in the future? ---Chris From nmaxpierson at gmail.com Mon Feb 21 15:15:46 2011 From: nmaxpierson at gmail.com (Max Pierson) Date: Mon, 21 Feb 2011 15:15:46 -0600 Subject: Graph Utils (Open-Source) In-Reply-To: References: Message-ID: Hiya Jimmy!! How has it been? >For simple visualizations, I think usually a 'native' framework/API is preferred, e.g. JGraph for java apps. Unfortunately, I'm not savvy with Java at all, so the really cool viz API's wont work for me (there's just something about Java ... I simply can't get into it and I see alot of Java based apps that are resource hogs). I was looking at mostly using some simple Perl + PHP (or even Python) for the graph generation. My own cacti if you will, just not as feature filled but template driven. >If you need to paint a bunch of arbitrary X and Y values on a graph from >an input file or based on simple equations, gnuplot will happily >oblige; it can >handle chart types rrdtool cannot, and you have more direct control of output. >If you want some 3D / surface graphs, RRDTool won't do it, anyways. >Gnuplot's less expensive >than Matlab / Maple. This is why rrdtool won't work for me. I'll be inputting data sets for charts that rrdtool doesn't understand and I would like to add a z-axis for some data that would be better understood on a 3D plot. The Graph.pm has hooks for xrt3d which looks pretty neat. I'm also looking at Grace as well using that same module (xmgrace), and it also has gnuplot I can work with. This way I can reuse code if I decide to use one over the other. The other issue is that all of this data is already stored (at least most of it) in mysql, and I don't need to waste cycles and chunks on riping data from one DB and have to create another just to display a graph. Plus some of the RRA's would be huge and therefore slow. >Try plotting a test dataset with 500 million datapoints. >there should normally be some form of averaging / smoothing / "selection of points" contemplated, if the dataset is huge The few hundred million rows are spread out across different servers and are not all the same table types. I believe it's 280-300 million rows by first estimates, but they will be represented in different manors. I won't be injecting the volume of inserts aggregate onto one plot over time. I haven't gone that mad yet :) For measurements such as that, averaging will be used for such trends. Good talking to you again, Max On Sun, Feb 20, 2011 at 10:45 PM, Jimmy Hess wrote: > On Fri, Feb 18, 2011 at 1:13 PM, Max Pierson > wrote: > > Anyone out there using something other than rrdtool for creating graphs?? > I > > have a project that will need a trend taken, and unfortunately rrdtool > > doesn't fit the bill. All of the scripting, data collection, > > database archival, etc will be custom written or is already done (with > some > > hacks of course :). So really what i'm looking for is something along the > > lines of GNUplot. Has anyone used it before and would like to share > > I haven't heard of gnuplot used often with other software as a framework > for graphing/visualizations. For simple visualizations, I think usually a > 'native' framework/API is preferred, e.g. JGraph for java apps. > > I suspect one reason gnuplot is not used as widely as it could be otherwise > is, its licensing is not as "friendly" as other graphics frameworks. > gnuplot license is GPL incompatible and does not seem to even fully meet > the open source definition, > > Because redistributing complete modified source code of gnuplot itself > is not allowed by the license; a clear reading of gnuplot license suggests > only patches, unmodified source code, can be freely redistributed, > redistributed binaries based on modified source have special rules). > > > Aside from that caveat, which most likely does not normally impair private > use by a network operator: gnuplot is a really good tool. > If you need to paint a bunch of arbitrary X and Y values on a graph from > an input file or based on simple equations, gnuplot will happily > oblige; it can > handle chart types rrdtool cannot, and you have more direct control of > output. > > If you want some 3D / surface graphs, RRDTool won't do it, anyways. > Gnuplot's less expensive > than Matlab / Maple. > > You can even set terminal type to "dumb" in gnuplot, and generate some > fancy > ASCII art graphs on stdout. > > > In regards to scalability... > > About the millions of rows... err.. > Try plotting a test dataset with 500 million datapoints. Chances > are gnuplot won't > necessarily scale that well either, and you need some method to be > selective of which rows are > provided as input to the plotting framework, in that case. > > If you have a million datapoints on your X axis, each X position is > smaller than 1/1000 of > a display pixel (on a graph that fits on a display at say 1920x1080); > displaying such high resolution of all datapoints at once on the > unzoomed graph is beyond > the display hardware capabilitiy. > > there should normally be some form of averaging / smoothing / > "selection of points" contemplated, > if the dataset is huge > > > experiences?? Seems like it will be able to my plot data accordingly, but > > wanted to see if there were any other popular tools I've yet to come > across. > > > > (Open-Source only please) > > -- > -JH > From trelane at trelane.net Mon Feb 21 15:17:38 2011 From: trelane at trelane.net (Andrew Kirch) Date: Mon, 21 Feb 2011 16:17:38 -0500 Subject: Contact for APEWS.org? In-Reply-To: <4D62D36E.4040400@2mbit.com> References: <4B4120B1642DCF48ACA84E4F82C8E1F65A9961CE50@EXCH> <4D62D36E.4040400@2mbit.com> Message-ID: <4D62D672.1080701@trelane.net> On 2/21/2011 4:04 PM, Brielle Bruns wrote: > On 2/21/11 1:41 PM, Kate Gerry wrote: > > Kate, > > It is unlikely you will find a direct contact for APEWS - your best > bet is to get access to usenet through one of the Usenet providers or > even through aioe or eternal-september. > > APEWS is braindead in execution, if not in fact. They list about half of all IPv4 space, and one might reasonably state that anyone using them deserves their own self-inflicted SMTP intranet. http://www.dnsbl.com/2007/08/apews-news-and-commentary-roundup.html Andrew From linford at spamhaus.org Mon Feb 21 15:19:08 2011 From: linford at spamhaus.org (Steve Linford) Date: Mon, 21 Feb 2011 21:19:08 +0000 Subject: Contact for APEWS.org? In-Reply-To: <4B4120B1642DCF48ACA84E4F82C8E1F65A9961CE50@EXCH> References: <4B4120B1642DCF48ACA84E4F82C8E1F65A9961CE50@EXCH> Message-ID: On 21 Feb 2011, at 21:41, Kate Gerry wrote: > We've been advised by a client that they're incorrectly listing a /15. APEWS is one of the many fringe hobby DNSBLs run from kids bedrooms. Nobody has ever heard of any network using APEWS so your client can not possibly be experiencing any mail issue due to any APEWS listing. Your client has simply looked up their IP address on some advert-laden "check your IP against a gazillion blacklists" website which happily reports every IP is 'listed' somewhere without mentioning that half the lists it checked against are not used by anyone except the kid running it. Steve Linford The Spamhaus Project http://www.spamhaus.org From bjohnson at drtel.com Mon Feb 21 15:21:45 2011 From: bjohnson at drtel.com (Brian Johnson) Date: Mon, 21 Feb 2011 21:21:45 +0000 Subject: BGP Failover Question In-Reply-To: <49274CE9-307A-4C36-B311-01B42DD0C735@iamchriswallace.com> References: <49274CE9-307A-4C36-B311-01B42DD0C735@iamchriswallace.com> Message-ID: Chris, The best way to resolve this issue is to not use a service provider who takes down your connectivity outside of maintenance windows, but I digress. This is the nature of BGP. You send your providers routes about your network prefixes and they send you routes to say the DFZ. When you forward packets to them ,because they sent you routes saying they can get the destinations your packets have on them, it is now outside of anything you can do about it. It is now up to the peer to forward the packets as they said they would by sending you prefixes. This is a trust relationship as you trust they will forward your packets because that is why you are paying them. - Brian J. -----Original Message----- From: Chris Wallace [mailto:lists at iamchriswallace.com] Sent: Monday, February 21, 2011 3:10 PM To: NANOG Subject: BGP Failover Question I am looking for some help with an issue we recently had with one of our BGP peers recently. I currently have two DIA providers each terminated into their own edge router and I am doing iBGP to exchange routes between the two edge routers. Last week Provider A made a policy change "somewhere" in their network in the middle of the day causing traffic to stop routing. Of course this connection happens to be the preferred route for the majority of our inbound and outbound traffic. I never saw our physical link go down and never saw our peer drop therefore BGP did not stop advertising routes, this caused most of our customers traffic to go nowhere. In order to fix the issue I had to manually shutdown the peer till Provider A confirmed the change they made had been reverted. This isn't the first time we have seen this issue with our various providers, how can I prevent issues like this from happening in the future? ---Chris From jloiacon at csc.com Mon Feb 21 15:24:28 2011 From: jloiacon at csc.com (Joe Loiacono) Date: Mon, 21 Feb 2011 16:24:28 -0500 Subject: Graph Utils (Open-Source) In-Reply-To: References: Message-ID: Max Pierson wrote on 02/21/2011 04:15:46 PM: > Unfortunately, I'm not savvy with Java at all, so the really cool viz API's > wont work for me (there's just something about Java ... I simply can't get > into it and I see alot of Java based apps that are resource hogs). I was > looking at mostly using some simple Perl + PHP (or even Python) for the > graph generation. My own cacti if you will, just not as feature filled > but template driven. The GD 'C' package has great Perl interfaces called GD, and GD:Graph. Easy to work with ... GD: http://search.cpan.org/~lds/GD-2.30/GD.pm GD:Graph: http://search.cpan.org/~bwarfield/GDGraph-1.44/ Joe From nmaxpierson at gmail.com Mon Feb 21 15:25:11 2011 From: nmaxpierson at gmail.com (Max Pierson) Date: Mon, 21 Feb 2011 15:25:11 -0600 Subject: BGP Failover Question In-Reply-To: <49274CE9-307A-4C36-B311-01B42DD0C735@iamchriswallace.com> References: <49274CE9-307A-4C36-B311-01B42DD0C735@iamchriswallace.com> Message-ID: I would simply monitor PPS on those links and set a threshold which will kick off an alert at least. If your scripting savvy, other tools such as IP SLA and EEM on Cisco could be used to automate the failover. Juniper also has a similar scripting tool that can probably do the same. I've had this happen before and is a real pain. Regards, M On Mon, Feb 21, 2011 at 3:10 PM, Chris Wallace wrote: > I am looking for some help with an issue we recently had with one of our > BGP peers recently. I currently have two DIA providers each terminated into > their own edge router and I am doing iBGP to exchange routes between the two > edge routers. Last week Provider A made a policy change "somewhere" in > their network in the middle of the day causing traffic to stop routing. Of > course this connection happens to be the preferred route for the majority of > our inbound and outbound traffic. I never saw our physical link go down and > never saw our peer drop therefore BGP did not stop advertising routes, this > caused most of our customers traffic to go nowhere. In order to fix the > issue I had to manually shutdown the peer till Provider A confirmed the > change they made had been reverted. This isn't the first time we have seen > this issue with our various providers, how can I prevent issues like this > from happening in the future? > > ---Chris > From sethm at rollernet.us Mon Feb 21 15:35:51 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 21 Feb 2011 13:35:51 -0800 Subject: BGP Failover Question In-Reply-To: <49274CE9-307A-4C36-B311-01B42DD0C735@iamchriswallace.com> References: <49274CE9-307A-4C36-B311-01B42DD0C735@iamchriswallace.com> Message-ID: <4D62DAB7.1050904@rollernet.us> On 2/21/2011 13:10, Chris Wallace wrote: > I am looking for some help with an issue we recently had with one of our BGP peers recently. I currently have two DIA providers each terminated into their own edge router and I am doing iBGP to exchange routes between the two edge routers. Last week Provider A made a policy change "somewhere" in their network in the middle of the day causing traffic to stop routing. Of course this connection happens to be the preferred route for the majority of our inbound and outbound traffic. I never saw our physical link go down and never saw our peer drop therefore BGP did not stop advertising routes, this caused most of our customers traffic to go nowhere. In order to fix the issue I had to manually shutdown the peer till Provider A confirmed the change they made had been reverted. This isn't the first time we have seen this issue with our various providers, how can I prevent issues like this from happening in the future? > I had a provider like that a long time ago; it was an ATG T1 (which was fine) but when they were bought by Eschelon the exact problem you're describing would happen every other month like clockwork. The first time was forgivable. The second time I was annoyed. After the third I was angry, unplugged it, and told them to stuff it because apparently they didn't know how to deal with BGP. You can't prevent it from happening. You can only come up with band-aids to notify you. Save yourself the headache and find a new provider that knows how to handle BGP. What happens if the other circuit is not available (outage, planned maintenance, etc.) at the same time the problem one decides to black hole you? If you're facing the same repeating problem they are obviously not the best fit for you. ~Seth From nenolod at systeminplace.net Mon Feb 21 15:37:05 2011 From: nenolod at systeminplace.net (William Pitcock) Date: Mon, 21 Feb 2011 15:37:05 -0600 Subject: Contact for APEWS.org? In-Reply-To: <4B4120B1642DCF48ACA84E4F82C8E1F65A9961CE50@EXCH> References: <4B4120B1642DCF48ACA84E4F82C8E1F65A9961CE50@EXCH> Message-ID: <20110221153705.7ea2e40c@petrie> Hi, On Mon, 21 Feb 2011 12:41:57 -0800 Kate Gerry wrote: > We've been advised by a client that they're incorrectly listing > a /15. The listing is: > > (E-431420) 96.44.0.0/15 > > According to their FAQ they only take delistings via newsgroups and > Google News isn't co-operating with me in regards to them. Meanwhilst > we're affected with our range 96.44.128.0/18. Nobody in their right mind uses APEWS when there are more legitimate DNSBLs around like Spamhaus, AHBL, DroneBL, etc. Your client is unlikely having any problem with this listing. But, if you really want to bother, my advice is get a Supernews account and go for it. William From nmaxpierson at gmail.com Mon Feb 21 15:44:32 2011 From: nmaxpierson at gmail.com (Max Pierson) Date: Mon, 21 Feb 2011 15:44:32 -0600 Subject: BGP Failover Question In-Reply-To: <4D62DAB7.1050904@rollernet.us> References: <49274CE9-307A-4C36-B311-01B42DD0C735@iamchriswallace.com> <4D62DAB7.1050904@rollernet.us> Message-ID: >Save yourself the headache and find a new provider that knows how to handle BGP I've had this happen with providers that do know how to handle BGP. Just because you peer with 3356, 701, etc, doesn't mean operators can't make a mistake. I've even seen this happen due to some wierd BGP behavior caused by some cool new "features". IMHO, better to plan for it and deploy it as a policy (by whatever means). M On Mon, Feb 21, 2011 at 3:35 PM, Seth Mattinen wrote: > On 2/21/2011 13:10, Chris Wallace wrote: > > I am looking for some help with an issue we recently had with one of our > BGP peers recently. I currently have two DIA providers each terminated into > their own edge router and I am doing iBGP to exchange routes between the two > edge routers. Last week Provider A made a policy change "somewhere" in > their network in the middle of the day causing traffic to stop routing. Of > course this connection happens to be the preferred route for the majority of > our inbound and outbound traffic. I never saw our physical link go down and > never saw our peer drop therefore BGP did not stop advertising routes, this > caused most of our customers traffic to go nowhere. In order to fix the > issue I had to manually shutdown the peer till Provider A confirmed the > change they made had been reverted. This isn't the first time we have seen > this issue with our various providers, how can I prevent issues like this > from happening in the future? > > > > > I had a provider like that a long time ago; it was an ATG T1 (which was > fine) but when they were bought by Eschelon the exact problem you're > describing would happen every other month like clockwork. The first time > was forgivable. The second time I was annoyed. After the third I was > angry, unplugged it, and told them to stuff it because apparently they > didn't know how to deal with BGP. > > You can't prevent it from happening. You can only come up with band-aids > to notify you. Save yourself the headache and find a new provider that > knows how to handle BGP. What happens if the other circuit is not > available (outage, planned maintenance, etc.) at the same time the > problem one decides to black hole you? If you're facing the same > repeating problem they are obviously not the best fit for you. > > ~Seth > > From trelane at trelane.net Mon Feb 21 15:45:40 2011 From: trelane at trelane.net (Andrew Kirch) Date: Mon, 21 Feb 2011 16:45:40 -0500 Subject: Contact for APEWS.org? In-Reply-To: <20110221153705.7ea2e40c@petrie> References: <4B4120B1642DCF48ACA84E4F82C8E1F65A9961CE50@EXCH> <20110221153705.7ea2e40c@petrie> Message-ID: <4D62DD04.2000205@trelane.net> On 2/21/2011 4:37 PM, William Pitcock wrote: > Hi, > Nobody in their right mind uses APEWS when there are more legitimate > DNSBLs around like Spamhaus, AHBL, DroneBL, etc. > > Your client is unlikely having any problem with this listing. But, if > you really want to bother, my advice is get a Supernews account and go > for it. > > William > Most likely, given the toxic environment on USENET's NANAE, you'll simply be derided, mocked, or harassed by the inhabitants there instead of getting any sort of valid de-listing advice. Andrew From nmaxpierson at gmail.com Mon Feb 21 15:34:10 2011 From: nmaxpierson at gmail.com (Max Pierson) Date: Mon, 21 Feb 2011 15:34:10 -0600 Subject: Graph Utils (Open-Source) In-Reply-To: References: Message-ID: >The GD 'C' package has great Perl interfaces called GD, and GD:Graph I'm test driving GD as well. Trying out a few other tools that were mentioned here also. Trying to get a feel for which I like best. Thanks for all of the replies! On Mon, Feb 21, 2011 at 3:24 PM, Joe Loiacono wrote: > > Max Pierson wrote on 02/21/2011 04:15:46 PM: > > > > Unfortunately, I'm not savvy with Java at all, so the really cool viz > API's > > wont work for me (there's just something about Java ... I simply can't > get > > into it and I see alot of Java based apps that are resource hogs). I was > > looking at mostly using some simple Perl + PHP (or even Python) for the > > graph generation. My own cacti if you will, just not as feature filled > > but template driven. > > > The GD 'C' package has great Perl interfaces called GD, and GD:Graph. Easy > to work with ... > > GD: http://search.cpan.org/~lds/GD-2.30/GD.pm > > GD:Graph: http://search.cpan.org/~bwarfield/GDGraph-1.44/ > > Joe From sethm at rollernet.us Mon Feb 21 16:19:20 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 21 Feb 2011 14:19:20 -0800 Subject: BGP Failover Question In-Reply-To: References: <49274CE9-307A-4C36-B311-01B42DD0C735@iamchriswallace.com> <4D62DAB7.1050904@rollernet.us> Message-ID: <4D62E4E8.2010005@rollernet.us> On 2/21/2011 13:44, Max Pierson wrote: >>Save yourself the headache and find a new provider that knows how to > handle BGP > > I've had this happen with providers that do know how to handle BGP. Just > because you peer with 3356, 701, etc, doesn't mean operators can't make > a mistake. I've even seen this happen due to some wierd BGP behavior > caused by some cool new "features". > > IMHO, better to plan for it and deploy it as a policy (by whatever means). > On a predictable schedule? That's where I drew the line: they were "fixing" something that was not "normal" to them every two months that resulted in the problem the OP described. Yes, mistakes happen, but identical repeating mistakes don't count in my book. I would expect my providers to document changes and whoever is making changes to consult it when they see a deviation from common config. ~Seth From cgucker at onesc.net Mon Feb 21 17:36:13 2011 From: cgucker at onesc.net (Charles Gucker) Date: Mon, 21 Feb 2011 18:36:13 -0500 Subject: BGP Failover Question In-Reply-To: <49274CE9-307A-4C36-B311-01B42DD0C735@iamchriswallace.com> References: <49274CE9-307A-4C36-B311-01B42DD0C735@iamchriswallace.com> Message-ID: On Mon, Feb 21, 2011 at 4:10 PM, Chris Wallace wrote: >This isn't the first time we have seen this issue with our various providers, how can I prevent issues like this from happening in the future? Quick question, are you running with a default route from your provider? If so, you're better off either finding another provider, or upgrading the router (if necessary) to carry a full table. If they do something to partition their network, you will see the decrease in routes learned from them, provided you see those routes and not the default route as asked above. charles From godinezj at gmail.com Mon Feb 21 19:58:07 2011 From: godinezj at gmail.com (Javier Godinez) Date: Mon, 21 Feb 2011 17:58:07 -0800 Subject: raw bgp traffic Message-ID: Deal NANOG, Does anyone know where I can get real/raw BGP traffic, maybe in pcap format? I just need maybe a few days of raw data for an inline analysis tool I am developing. Thank you, Javier From randy at psg.com Mon Feb 21 20:00:50 2011 From: randy at psg.com (Randy Bush) Date: Tue, 22 Feb 2011 10:00:50 +0800 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <117f01cbd207$34f42290$9edc67b0$@com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> <4C060A07-4FA7-467B-8BA8-8D4D04A0BA9A@queuefull.net> <117f01cbd207$34f42290$9edc67b0$@com> Message-ID: >> http://tools.ietf.org/html/draft-donley-nat444-impacts-01 > That document conflates problems of NAT444 with problems of NAT44 > with problems of bandwidth starvation with problems of CGN. it may require a delicate palate to differentiate the different flavors of randy From dwing at cisco.com Mon Feb 21 20:08:34 2011 From: dwing at cisco.com (Dan Wing) Date: Mon, 21 Feb 2011 18:08:34 -0800 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <41EE506B-D6BA-4AB5-A211-41BFE114F70E@delong.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> <4C060A07-4FA7-467B-8BA8-8D4D04A0BA9A@queuefull.net> <117f01cbd207$34f42290$9edc67b0$@com> <41EE506B-D6BA-4AB5-A211-41BFE114F70E@delong.com> Message-ID: <132601cbd235$69298720$3b7c9560$@com> > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Monday, February 21, 2011 12:59 PM > To: Dan Wing > Cc: 'Chris Grundemann'; 'Benson Schliesser'; 'NANOG list'; 'ARIN-PPML > List' > Subject: Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 > naysayer...) > > > On Feb 21, 2011, at 12:37 PM, Dan Wing wrote: > > >> -----Original Message----- > >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On > >> Behalf Of Chris Grundemann > >> Sent: Thursday, February 17, 2011 5:55 PM > >> To: Benson Schliesser > >> Cc: NANOG list; ARIN-PPML List > >> Subject: Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 > >> naysayer...) > >> > >> On Thu, Feb 10, 2011 at 14:17, Benson Schliesser > >> wrote: > >> > >>> If you have more experience (not including rumors) that suggests > >> otherwise, I'd very much like to hear about it. I'm open to the > >> possibility that NAT444 breaks stuff - that feels right in my gut - > but > >> I haven't found any valid evidence of this. > >> > >> In case you have not already found this: > >> http://tools.ietf.org/html/draft-donley-nat444-impacts-01 > > > > That document conflates problems of NAT444 with problems of NAT44 > > with problems of bandwidth starvation with problems of CGN. > > > > For details, see my comments at > > http://www.ietf.org/mail-archive/web/behave/current/msg09027.html > > and see Reinaldo Penno's comments at > > http://www.ietf.org/mail-archive/web/behave/current/msg09030.html > > > > -d > > The document describes problems that will exist in NAT444 environments. > It does not state that these problems would be specific to NAT444, but, > NAT444 will cause or exacerbate each of the problems described. To the contrary. Its title, filename, abstract, and introduction all say the problems are specific to NAT444. Which is untrue. > Yes, the problems may have other underlying root causes, but, they > will all be present in a NAT444 environment, even if they were not > present in the same environment prior to deployment of NAT444. > > > Let me put it this way... > > IPv4 has a TITANIC lack of numeric addresses and has been > stretched beyond its limits for some time now. > > IPv6 is a life boat. > > NAT is a seat cushion used for floatation. > > NAT444 (and other NAT-based extensions) are deck chairs. > > Attempting to improve them beyond their current states is > an effort to rearrange the deck chairs. -d From dwing at cisco.com Mon Feb 21 20:17:04 2011 From: dwing at cisco.com (Dan Wing) Date: Mon, 21 Feb 2011 18:17:04 -0800 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> <4C060A07-4FA7-467B-8BA8-8D4D04A0BA9A@queuefull.net> <117f01cbd207$34f42290$9edc67b0$@com> Message-ID: <133301cbd236$9910c0b0$cb324210$@com> > >> http://tools.ietf.org/html/draft-donley-nat444-impacts-01 > > That document conflates problems of NAT444 with problems of NAT44 > > with problems of bandwidth starvation with problems of CGN. > > it may require a delicate palate to differentiate the different flavors > of Running out of bandwidth for Netflix is pretty distinct from the flavor of fried gNAT. -d From patrick at ianai.net Mon Feb 21 20:21:23 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 21 Feb 2011 21:21:23 -0500 Subject: raw bgp traffic In-Reply-To: References: Message-ID: On Feb 21, 2011, at 8:58 PM, Javier Godinez wrote: > Does anyone know where I can get real/raw BGP traffic, maybe in pcap > format? I just need maybe a few days of raw data for an inline > analysis tool I am developing. I believe has some info, but I don't know if it is "raw". RIPE RIS may also have data, I don't remember. -- TTFN, patrick From mkarir at merit.edu Mon Feb 21 20:29:51 2011 From: mkarir at merit.edu (Manish Karir) Date: Mon, 21 Feb 2011 21:29:51 -0500 Subject: Traffic to 5/8 and 37/8 - stats on RIPE Labs Message-ID: Hi Oleg, You are correct. We got our default values mixed up. We will correct this on the blog post. Thanks. -manish > Hello, > > > http://labs.ripe.net/Members/mkarir/first-impressions-of-pollution-in-two-ripe-ncc-darknets > > Quote from the link: > > > Note that in the 37/8, most traffic comes from TTLs around 100. These are Linux hosts. > > The smaller humps are at ~32 (Windows) and ~250 (Solaris). > > I don't agree. TTL around 100 is most probably Windows hosts with initial TTL of 128. > Everything below 64 can be Linux or FreeBSD. ~250 can be Solaris host but Cisco > IOS also set initial TTL to 255. > > -- > wbr, Oleg. > From ops.lists at gmail.com Mon Feb 21 20:41:59 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 22 Feb 2011 08:11:59 +0530 Subject: Contact for APEWS.org? In-Reply-To: <4B4120B1642DCF48ACA84E4F82C8E1F65A9961CE50@EXCH> References: <4B4120B1642DCF48ACA84E4F82C8E1F65A9961CE50@EXCH> Message-ID: Nobody with half a brain uses it, especially not on a production network rather than "man, his girlfriend and the family dog running a linux box on a dsl line" Ignore would be the best advice. On Tue, Feb 22, 2011 at 2:11 AM, Kate Gerry wrote: > We've been advised by a client that they're incorrectly listing a /15. The listing is: > > (E-431420) 96.44.0.0/15 > > According to their FAQ they only take delistings via newsgroups and Google News isn't co-operating with me in regards to them. Meanwhilst we're affected with our range 96.44.128.0/18. > > -- > Kate > QuadraNet, Inc > 530 W 6th Street #901 > Los Angeles, CA 90014 > kate at quadranet.com > > > > -- Suresh Ramasubramanian (ops.lists at gmail.com) From mjwise at kapu.net Mon Feb 21 21:03:25 2011 From: mjwise at kapu.net (Michael J Wise) Date: Mon, 21 Feb 2011 22:03:25 -0500 Subject: Contact for APEWS.org? In-Reply-To: <4B4120B1642DCF48ACA84E4F82C8E1F65A9961CE50@EXCH> References: <4B4120B1642DCF48ACA84E4F82C8E1F65A9961CE50@EXCH> Message-ID: On Feb 21, 2011, at 3:41 PM, Kate Gerry wrote: > We've been advised by a client that they're incorrectly listing a /15. What do your LOGS say? What did the BOUNCE say? Aloha, Michael. -- "Please have your Internet License http://kapu.net/~mjwise/ and Usenet Registration handy..." From tme at multicasttech.com Mon Feb 21 21:04:42 2011 From: tme at multicasttech.com (Marshall Eubanks) Date: Mon, 21 Feb 2011 22:04:42 -0500 Subject: Christchurch New Zealand Message-ID: <1FF5B3DC-364E-48A5-A2C2-F27E5E93C27F@multicasttech.com> There has been a bad Earthquake in Christchurch New Zealand with reports of fatalities. http://www.facebook.com/photo.php?fbid=10150099324847752&set=a.125583977751.103665.119452527751&theater Telecom New Zealand reports "Heavy damage" to their Christchurch building, but no deaths there. Is there any report of issues with the undersea cables to / from the South Island ? Regards Marshall P.S. On a more personal note, Google has a people finder up @ http://christchurch-2011.person-finder.appspot.com/ There is a DFAT # - 1300 555 135 - for people outside of NZ to call. Telecom New Zealand has asked people to stay off of the wireless network except for true emergencies. From trelane at trelane.net Mon Feb 21 21:08:05 2011 From: trelane at trelane.net (Andrew Kirch) Date: Mon, 21 Feb 2011 22:08:05 -0500 Subject: Christchurch New Zealand In-Reply-To: <1FF5B3DC-364E-48A5-A2C2-F27E5E93C27F@multicasttech.com> References: <1FF5B3DC-364E-48A5-A2C2-F27E5E93C27F@multicasttech.com> Message-ID: <4D632895.1070306@trelane.net> On 2/21/2011 10:04 PM, Marshall Eubanks wrote: > There has been a bad Earthquake in Christchurch New Zealand with reports of > fatalities. > > http://www.facebook.com/photo.php?fbid=10150099324847752&set=a.125583977751.103665.119452527751&theater > > Telecom New Zealand reports "Heavy damage" to their Christchurch building, but no deaths there. > > Is there any report of issues with the undersea cables to / from the South Island ? > > Regards > Marshall > > P.S. On a more personal note, > Google has a people finder up @ > > http://christchurch-2011.person-finder.appspot.com/ > > There is a DFAT # - 1300 555 135 - for people outside of NZ to call. > > Telecom New Zealand has asked people to stay off of the wireless network except for true emergencies. > > I'm currently chatting with a close friend via kinect.co.nz. She lives on the very south tip of the south island. The damage in christchurch is extensive, and devastating, including damage to hospitals and emergency response equipment. They're having a really rough day down there. Andrew From kyhwana at gmail.com Mon Feb 21 21:20:47 2011 From: kyhwana at gmail.com (Daniel Richards) Date: Tue, 22 Feb 2011 16:20:47 +1300 Subject: Christchurch New Zealand In-Reply-To: <1FF5B3DC-364E-48A5-A2C2-F27E5E93C27F@multicasttech.com> References: <1FF5B3DC-364E-48A5-A2C2-F27E5E93C27F@multicasttech.com> Message-ID: <4D632B8F.6090007@gmail.com> There aren't any major international cables to the south island. The big one is the southern Cross cable that lands on either side of Auckland, which is the north of the North Island, which is operating normally. KAREN (The Kiwi Advanced Research Network) core in the south island is still operating, but most of the member sites in Christchurch are down: http://karen.net.nz/news-earthquake-network-update/ News is reporting deaths now, sadly. On 22/02/11 16:04, Marshall Eubanks wrote: > There has been a bad Earthquake in Christchurch New Zealand with reports of > fatalities. > > http://www.facebook.com/photo.php?fbid=10150099324847752&set=a.125583977751.103665.119452527751&theater > > Telecom New Zealand reports "Heavy damage" to their Christchurch building, but no deaths there. > > Is there any report of issues with the undersea cables to / from the South Island ? > > Regards > Marshall > > P.S. On a more personal note, > Google has a people finder up @ > > http://christchurch-2011.person-finder.appspot.com/ > > There is a DFAT # - 1300 555 135 - for people outside of NZ to call. > > Telecom New Zealand has asked people to stay off of the wireless network except for true emergencies. > > From blakjak at blakjak.net Mon Feb 21 21:46:44 2011 From: blakjak at blakjak.net (Mark Foster) Date: Tue, 22 Feb 2011 16:46:44 +1300 (NZDT) Subject: Christchurch New Zealand In-Reply-To: <4D632B8F.6090007@gmail.com> References: <1FF5B3DC-364E-48A5-A2C2-F27E5E93C27F@multicasttech.com> <4D632B8F.6090007@gmail.com> Message-ID: Folks on Twitter should search for hashtag #eqnz. Major news sites in NZ: www.stuff.co.nz www.nzherald.co.nz www.tvnz.co.nz www.3news.co.nz Plenty of Vids, Stills and some Streaming available. Can confirm the reports of multiple casualties. TV News is live broadcasting reports of many folks trapped within buildings, largely because of things like stairwells collapsing, etc. A few buildings have been hit pretty hard, with some notable collapses, damage to vehicles, etc. The 111 network (911 equiv) is experiencing problems in the South Island, folks are being asked to stay the phones (etc) except for genuine emergencies. Urban Search and Rescue teams in NZ are based in Christchurch, Palmerston North and Auckland. I gather all three teams are stood-to, and an offer from Australia for additional USAR resource has been accepted. CD Emergency has been declared and the Military are already getting involved. Christchurch experienced a major quake (magnitude 7.2) in September last year, which received a lot of press as its effects were widespread and severe - but there was little loss of life. This quake, magnitute 6.3, hit much closer to the CBD and during a business day, so the casualty count is much higher. Being a more shallow quake, much closer to town, but also lesser in magnitude, my uneducated view based on media coverage is that the effects are not as widespread, but where they're felt, are very significant. Mark. (in Auckland, some 1000 km away...) On Tue, 22 Feb 2011, Daniel Richards wrote: > There aren't any major international cables to the south island. The big one > is the southern Cross cable that lands on either side of Auckland, which is > the north of the North Island, which is operating normally. > > KAREN (The Kiwi Advanced Research Network) core in the south island is still > operating, but most of the member sites in Christchurch are down: > http://karen.net.nz/news-earthquake-network-update/ > > News is reporting deaths now, sadly. > > On 22/02/11 16:04, Marshall Eubanks wrote: >> There has been a bad Earthquake in Christchurch New Zealand with reports of >> fatalities. >> >> http://www.facebook.com/photo.php?fbid=10150099324847752&set=a.125583977751.103665.119452527751&theater >> >> Telecom New Zealand reports "Heavy damage" to their Christchurch building, >> but no deaths there. >> >> Is there any report of issues with the undersea cables to / from the South >> Island ? >> >> Regards >> Marshall >> >> P.S. On a more personal note, >> Google has a people finder up @ >> >> http://christchurch-2011.person-finder.appspot.com/ >> >> There is a DFAT # - 1300 555 135 - for people outside of NZ to call. >> >> Telecom New Zealand has asked people to stay off of the wireless network >> except for true emergencies. >> >> > > > From arturo.servin at gmail.com Mon Feb 21 21:49:14 2011 From: arturo.servin at gmail.com (Arturo Servin) Date: Tue, 22 Feb 2011 01:49:14 -0200 Subject: raw bgp traffic In-Reply-To: References: Message-ID: here: http://www.ripe.net/data-tools/stats/ris/ris-raw-data -as On 22 Feb 2011, at 00:21, Patrick W. Gilmore wrote: > On Feb 21, 2011, at 8:58 PM, Javier Godinez wrote: > >> Does anyone know where I can get real/raw BGP traffic, maybe in pcap >> format? I just need maybe a few days of raw data for an inline >> analysis tool I am developing. > > I believe has some info, but I don't know if it is "raw". > > RIPE RIS may also have data, I don't remember. > > -- > TTFN, > patrick > From tme at americafree.tv Mon Feb 21 22:08:02 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Mon, 21 Feb 2011 23:08:02 -0500 Subject: Christchurch New Zealand In-Reply-To: References: <1FF5B3DC-364E-48A5-A2C2-F27E5E93C27F@multicasttech.com> <4D632B8F.6090007@gmail.com> Message-ID: <6E646135-DD9E-4150-B9DB-DC2B0F4FAB7A@americafree.tv> On Feb 21, 2011, at 10:46 PM, Mark Foster wrote: > Folks on Twitter should search for hashtag #eqnz. > > Major news sites in NZ: > > www.stuff.co.nz > www.nzherald.co.nz > www.tvnz.co.nz > www.3news.co.nz > > Plenty of Vids, Stills and some Streaming available. > > Can confirm the reports of multiple casualties. TV News is live broadcasting reports of many folks trapped within buildings, largely because of things like stairwells collapsing, etc. A few buildings have been hit pretty hard, with some notable collapses, damage to vehicles, etc. > > The 111 network (911 equiv) is experiencing problems in the South Island, folks are being asked to stay the phones (etc) except for genuine emergencies. > > Urban Search and Rescue teams in NZ are based in Christchurch, Palmerston North and Auckland. I gather all three teams are stood-to, and an offer from Australia for additional USAR resource has been accepted. CD Emergency has been declared and the Military are already getting involved. > > Christchurch experienced a major quake (magnitude 7.2) in September last year, which received a lot of press as its effects were widespread and severe - but there was little loss of life. This quake, magnitute 6.3, hit much closer to the CBD and during a business day, so the casualty count is much higher. Being a more shallow quake, much closer to town, but also lesser in magnitude, my uneducated view based on media coverage is that the effects are not as widespread, but where they're felt, are very significant. The 2010 quake was 10 km deep, which is not that deep. It was 40 km away from Christchurch, however. This quake's epicenter is at Lyttelton, which is apparently only 12 km away, and so it isn't too surprising the damage is heaver. (That depends a lot on the property of the bedrock and sediments, and whether there is any seismic wave reflection and focusing going on.) Regards Marshall > > Mark. > (in Auckland, some 1000 km away...) > > On Tue, 22 Feb 2011, Daniel Richards wrote: > >> There aren't any major international cables to the south island. The big one is the southern Cross cable that lands on either side of Auckland, which is the north of the North Island, which is operating normally. >> >> KAREN (The Kiwi Advanced Research Network) core in the south island is still operating, but most of the member sites in Christchurch are down: http://karen.net.nz/news-earthquake-network-update/ >> >> News is reporting deaths now, sadly. >> >> On 22/02/11 16:04, Marshall Eubanks wrote: >>> There has been a bad Earthquake in Christchurch New Zealand with reports of >>> fatalities. >>> http://www.facebook.com/photo.php?fbid=10150099324847752&set=a.125583977751.103665.119452527751&theater >>> Telecom New Zealand reports "Heavy damage" to their Christchurch building, but no deaths there. >>> Is there any report of issues with the undersea cables to / from the South Island ? >>> Regards >>> Marshall >>> P.S. On a more personal note, >>> Google has a people finder up @ >>> http://christchurch-2011.person-finder.appspot.com/ >>> There is a DFAT # - 1300 555 135 - for people outside of NZ to call. >>> Telecom New Zealand has asked people to stay off of the wireless network except for true emergencies. >> >> >> > > From cgrundemann at gmail.com Mon Feb 21 22:16:34 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 21 Feb 2011 21:16:34 -0700 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <132601cbd235$69298720$3b7c9560$@com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> <4C060A07-4FA7-467B-8BA8-8D4D04A0BA9A@queuefull.net> <117f01cbd207$34f42290$9edc67b0$@com> <41EE506B-D6BA-4AB5-A211-41BFE114F70E@delong.com> <132601cbd235$69298720$3b7c9560$@com> Message-ID: On Mon, Feb 21, 2011 at 19:08, Dan Wing wrote: > Its title, filename, abstract, and introduction all say the problems > are specific to NAT444. ?Which is untrue. I just re-read the filename, abstract and introduction, and I disagree that any of those say that the problems are specific to NAT444. They all do state that these problems are present in NAT444, but not that it's the only technology/scenario/configuration where you might find them. More importantly, I am unsure the point of this argument. Are you trying to say that the items listed as broken in the draft are not actually broken? Because in my experience they are. IMHO, the fact that they are also broken in other (similar) scenarios is not evidence that they are not broken in this one. On the contrary, this scenario seems to be evidence to the brokenness in the others (until we get a chance to test and document them all - are you volunteering? ;). Cheers, ~Chris > -d > > > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From joelja at bogus.com Mon Feb 21 22:35:44 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 21 Feb 2011 20:35:44 -0800 Subject: =?windows-1252?Q?Re=3A_Local_root_zone_=28Was_NYTimes=3A?= =?windows-1252?Q?_Egypt_Leaders_Found_=91Off=92_Switch_for_?= =?windows-1252?Q?Internet=29?= In-Reply-To: References: <26249556.338.1297885804108.JavaMail.franck@franck-martins-macbook-pro.local> <5E883CE1-AE35-41B6-971B-F40A36730771@cisco.com> Message-ID: <4D633D20.6050106@bogus.com> On 2/16/11 5:37 PM, Randy Bush wrote: >> I don't think that the Egyptian shutdown of domain names had much >> effect > > what shutdown of egyptian domain names? > > randy, who has a server which serves them there's an interesting point to be made about the geographic administrative and political distribution of secondaries being essential to insuring their survivability. Oddly your name is on bcp 16. From tme at americafree.tv Mon Feb 21 23:29:11 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Tue, 22 Feb 2011 00:29:11 -0500 Subject: Christchurch New Zealand In-Reply-To: References: <1FF5B3DC-364E-48A5-A2C2-F27E5E93C27F@multicasttech.com> <4D632B8F.6090007@gmail.com> Message-ID: Here is an animated seismic map http://www.christchurchquakemap.co.nz/today Marshall On Feb 21, 2011, at 10:46 PM, Mark Foster wrote: > Folks on Twitter should search for hashtag #eqnz. > > Major news sites in NZ: > > www.stuff.co.nz > www.nzherald.co.nz > www.tvnz.co.nz > www.3news.co.nz > > Plenty of Vids, Stills and some Streaming available. > > Can confirm the reports of multiple casualties. TV News is live broadcasting reports of many folks trapped within buildings, largely because of things like stairwells collapsing, etc. A few buildings have been hit pretty hard, with some notable collapses, damage to vehicles, etc. > > The 111 network (911 equiv) is experiencing problems in the South Island, folks are being asked to stay the phones (etc) except for genuine emergencies. > > Urban Search and Rescue teams in NZ are based in Christchurch, Palmerston North and Auckland. I gather all three teams are stood-to, and an offer from Australia for additional USAR resource has been accepted. CD Emergency has been declared and the Military are already getting involved. > > Christchurch experienced a major quake (magnitude 7.2) in September last year, which received a lot of press as its effects were widespread and severe - but there was little loss of life. This quake, magnitute 6.3, hit much closer to the CBD and during a business day, so the casualty count is much higher. Being a more shallow quake, much closer to town, but also lesser in magnitude, my uneducated view based on media coverage is that the effects are not as widespread, but where they're felt, are very significant. > > Mark. > (in Auckland, some 1000 km away...) > > On Tue, 22 Feb 2011, Daniel Richards wrote: > >> There aren't any major international cables to the south island. The big one is the southern Cross cable that lands on either side of Auckland, which is the north of the North Island, which is operating normally. >> >> KAREN (The Kiwi Advanced Research Network) core in the south island is still operating, but most of the member sites in Christchurch are down: http://karen.net.nz/news-earthquake-network-update/ >> >> News is reporting deaths now, sadly. >> >> On 22/02/11 16:04, Marshall Eubanks wrote: >>> There has been a bad Earthquake in Christchurch New Zealand with reports of >>> fatalities. >>> http://www.facebook.com/photo.php?fbid=10150099324847752&set=a.125583977751.103665.119452527751&theater >>> Telecom New Zealand reports "Heavy damage" to their Christchurch building, but no deaths there. >>> Is there any report of issues with the undersea cables to / from the South Island ? >>> Regards >>> Marshall >>> P.S. On a more personal note, >>> Google has a people finder up @ >>> http://christchurch-2011.person-finder.appspot.com/ >>> There is a DFAT # - 1300 555 135 - for people outside of NZ to call. >>> Telecom New Zealand has asked people to stay off of the wireless network except for true emergencies. >> >> >> > > From nickellman at gmail.com Mon Feb 21 23:38:56 2011 From: nickellman at gmail.com (b nickell) Date: Mon, 21 Feb 2011 22:38:56 -0700 Subject: Christchurch New Zealand In-Reply-To: References: <1FF5B3DC-364E-48A5-A2C2-F27E5E93C27F@multicasttech.com> <4D632B8F.6090007@gmail.com> Message-ID: prayers.............hopes......... anything i can do I will On 2/21/11, Marshall Eubanks wrote: > Here is an animated seismic map > > http://www.christchurchquakemap.co.nz/today > > Marshall > > On Feb 21, 2011, at 10:46 PM, Mark Foster wrote: > >> Folks on Twitter should search for hashtag #eqnz. >> >> Major news sites in NZ: >> >> www.stuff.co.nz >> www.nzherald.co.nz >> www.tvnz.co.nz >> www.3news.co.nz >> >> Plenty of Vids, Stills and some Streaming available. >> >> Can confirm the reports of multiple casualties. TV News is live >> broadcasting reports of many folks trapped within buildings, largely >> because of things like stairwells collapsing, etc. A few buildings have >> been hit pretty hard, with some notable collapses, damage to vehicles, >> etc. >> >> The 111 network (911 equiv) is experiencing problems in the South Island, >> folks are being asked to stay the phones (etc) except for genuine >> emergencies. >> >> Urban Search and Rescue teams in NZ are based in Christchurch, Palmerston >> North and Auckland. I gather all three teams are stood-to, and an offer >> from Australia for additional USAR resource has been accepted. CD >> Emergency has been declared and the Military are already getting involved. >> >> Christchurch experienced a major quake (magnitude 7.2) in September last >> year, which received a lot of press as its effects were widespread and >> severe - but there was little loss of life. This quake, magnitute 6.3, >> hit much closer to the CBD and during a business day, so the casualty >> count is much higher. Being a more shallow quake, much closer to town, >> but also lesser in magnitude, my uneducated view based on media coverage >> is that the effects are not as widespread, but where they're felt, are >> very significant. >> >> Mark. >> (in Auckland, some 1000 km away...) >> >> On Tue, 22 Feb 2011, Daniel Richards wrote: >> >>> There aren't any major international cables to the south island. The big >>> one is the southern Cross cable that lands on either side of Auckland, >>> which is the north of the North Island, which is operating normally. >>> >>> KAREN (The Kiwi Advanced Research Network) core in the south island is >>> still operating, but most of the member sites in Christchurch are down: >>> http://karen.net.nz/news-earthquake-network-update/ >>> >>> News is reporting deaths now, sadly. >>> >>> On 22/02/11 16:04, Marshall Eubanks wrote: >>>> There has been a bad Earthquake in Christchurch New Zealand with reports >>>> of >>>> fatalities. >>>> http://www.facebook.com/photo.php?fbid=10150099324847752&set=a.125583977751.103665.119452527751&theater >>>> Telecom New Zealand reports "Heavy damage" to their Christchurch >>>> building, but no deaths there. >>>> Is there any report of issues with the undersea cables to / from the >>>> South Island ? >>>> Regards >>>> Marshall >>>> P.S. On a more personal note, >>>> Google has a people finder up @ >>>> http://christchurch-2011.person-finder.appspot.com/ >>>> There is a DFAT # - 1300 555 135 - for people outside of NZ to call. >>>> Telecom New Zealand has asked people to stay off of the wireless network >>>> except for true emergencies. >>> >>> >>> >> >> > > > -- -B From gbonser at seven.com Mon Feb 21 23:55:08 2011 From: gbonser at seven.com (George Bonser) Date: Mon, 21 Feb 2011 21:55:08 -0800 Subject: Christchurch New Zealand In-Reply-To: References: <1FF5B3DC-364E-48A5-A2C2-F27E5E93C27F@multicasttech.com><4D632B8F.6090007@gmail.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13C6B@RWC-EX1.corp.seven.com> > From: Marshall Eubanks > Sent: Monday, February 21, 2011 9:29 PM > To: Mark Foster > Cc: nanog at nanog.org > Subject: Re: Christchurch New Zealand > > Here is an animated seismic map > > http://www.christchurchquakemap.co.nz/today > > Marshall According to one article I read this evening, liquefaction was a more significant factor in this quake than in the last one. From randy at psg.com Tue Feb 22 01:43:23 2011 From: randy at psg.com (Randy Bush) Date: Tue, 22 Feb 2011 15:43:23 +0800 Subject: Local root zone (Was NYTimes: Egypt Leaders Found =?UTF-8?B?4oCYT2Zm4oCZ?= Switch for Internet) In-Reply-To: <4D633D20.6050106@bogus.com> References: <26249556.338.1297885804108.JavaMail.franck@franck-martins-macbook-pro.local> <5E883CE1-AE35-41B6-971B-F40A36730771@cisco.com> <4D633D20.6050106@bogus.com> Message-ID: >>> I don't think that the Egyptian shutdown of domain names had much >>> effect >> what shutdown of egyptian domain names? >> randy, who has a server which serves them > there's an interesting point to be made about the geographic > administrative and political distribution of secondaries being > essential to insuring their survivability. > Oddly your name is on bcp 16. clearly a forgery randy From bensons at queuefull.net Tue Feb 22 02:29:23 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Tue, 22 Feb 2011 02:29:23 -0600 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> <4C060A07-4FA7-467B-8BA8-8D4D04A0BA9A@queuefull.net> <117f01cbd207$34f42290$9edc67b0$@com> <41EE506B-D6BA-4AB5-A211-41BFE114F70E@delong.com> <132601cbd235$69298720$3b7c9560$@com> Message-ID: <41DC9C32-7902-459E-A4FA-8A70EED53AB4@queuefull.net> On Feb 21, 2011, at 10:16 PM, Chris Grundemann wrote: > On Mon, Feb 21, 2011 at 19:08, Dan Wing wrote: > >> Its title, filename, abstract, and introduction all say the problems >> are specific to NAT444. Which is untrue. > > I just re-read the filename, abstract and introduction, and I disagree > that any of those say that the problems are specific to NAT444. They > all do state that these problems are present in NAT444, but not that > it's the only technology/scenario/configuration where you might find > them. Let's at least agree that the text isn't precise. I've had a large number of conversations in which relatively intelligent people advocated other (non-NAT444) scenarios involving CGN, built on the premise that NAT444 is broken and draft-donley-nat444-impacts is evidence. Either the draft is perfectly clear and all of these people are stupid, or the draft is misleading (intentionally or unintentionally). > More importantly, I am unsure the point of this argument. Are you > trying to say that the items listed as broken in the draft are not > actually broken? Because in my experience they are. IMHO, the fact > that they are also broken in other (similar) scenarios is not evidence > that they are not broken in this one. On the contrary, this scenario > seems to be evidence to the brokenness in the others (until we get a > chance to test and document them all - are you volunteering? ;). There seems to be a position, taken by others on these lists, that IPv6 is the only address family that matters. Interestingly, this position seems to be most pronounced from people not involved in operating production networks. But, regardless, if I were to accept this position then I might also agree that it doesn't matter whether or not draft-donley-nat444-impacts is misleading. On the contrary: While I emphatically agree that IPv6 is the path forward, I don't accept the notion that IPv4 no longer matters. IPv4 is the present-day Internet, and IPv4 connectivity is demanded by present-day paying customers - you don't burn the bridge until *after* you've crossed it. Further, given that IPv4 does matter yet has an exhausted address supply, there exists a need for IPv4 address sharing technology. Fundamentally, this means that we need to discuss and engineer the best possible address sharing technology. It may never be as good as native end-to-end IPv6, but sub-optimal is not the same thing as "broken" as others have claimed, and sub-optimal might be acceptable if it's the only alternative. Of course, we can also rely on an IPv4 address market to avoid NAT in the more sensitive situations (i.e. situations with more sensitive users). But that's a different conversation. Cheers, -Benson From srgqwerty at gmail.com Tue Feb 22 02:41:53 2011 From: srgqwerty at gmail.com (srg) Date: Tue, 22 Feb 2011 09:41:53 +0100 Subject: raw bgp traffic In-Reply-To: References: Message-ID: <1298364113.2336.0.camel@ping01> Hope this helps http://packetlife.net/captures/category/routing-protocols/ Regards On Mon, 2011-02-21 at 17:58 -0800, Javier Godinez wrote: > Deal NANOG, > > Does anyone know where I can get real/raw BGP traffic, maybe in pcap > format? I just need maybe a few days of raw data for an inline > analysis tool I am developing. > > > Thank you, > Javier > From randy at psg.com Tue Feb 22 03:14:18 2011 From: randy at psg.com (Randy Bush) Date: Tue, 22 Feb 2011 17:14:18 +0800 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <41DC9C32-7902-459E-A4FA-8A70EED53AB4@queuefull.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> <4C060A07-4FA7-467B-8BA8-8D4D04A0BA9A@queuefull.net> <117f01cbd207$34f42290$9edc67b0$@com> <41EE506B-D6BA-4AB5-A211-41BFE114F70E@delong.com> <132601cbd235$69298720$3b7c9560$@com> <41DC9C32-7902-459E-A4FA-8A70EED53AB4@queuefull.net> Message-ID: [ arin cesspool removed from cc: as i can not post there anyway ] > There seems to be a position, taken by others on these lists, that > IPv6 is the only address family that matters. Interestingly, this > position seems to be most pronounced from people not involved in > operating production networks. excuse me! randy From owen at delong.com Tue Feb 22 03:40:59 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Feb 2011 01:40:59 -0800 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <41DC9C32-7902-459E-A4FA-8A70EED53AB4@queuefull.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> <4C060A07-4FA7-467B-8BA8-8D4D04A0BA9A@queuefull.net> <117f01cbd207$34f42290$9edc67b0$@com> <41EE506B-D6BA-4AB5-A211-41BFE114F70E@delong.com> <132601cbd235$69298720$3b7c9560$@com> <41DC9C32-7902-459E-A4FA-8A70EED53AB4@queuefull.net> Message-ID: <7277A6F9-C21C-4EF0-8220-A3F3A707A836@delong.com> On Feb 22, 2011, at 12:29 AM, Benson Schliesser wrote: > > On Feb 21, 2011, at 10:16 PM, Chris Grundemann wrote: > >> On Mon, Feb 21, 2011 at 19:08, Dan Wing wrote: >> >>> Its title, filename, abstract, and introduction all say the problems >>> are specific to NAT444. Which is untrue. >> >> I just re-read the filename, abstract and introduction, and I disagree >> that any of those say that the problems are specific to NAT444. They >> all do state that these problems are present in NAT444, but not that >> it's the only technology/scenario/configuration where you might find >> them. > > Let's at least agree that the text isn't precise. I've had a large number of conversations in which relatively intelligent people advocated other (non-NAT444) scenarios involving CGN, built on the premise that NAT444 is broken and draft-donley-nat444-impacts is evidence. Either the draft is perfectly clear and all of these people are stupid, or the draft is misleading (intentionally or unintentionally). > I would point out to them that the fact that their technology choice isn't NAT 444 does not mean that they don't have the same problems, merely that their technology wasn't part of the testing documented in the draft. I think the draft is perfectly clear and that humans, even intelligent humans often have problems with this level of logic. If A is a subset of B, it does not mean that A is not a subset of C. Therefore, a draft that states that technology B has problem A is not and cannot be logically construed as a statement that technology C does not have problem A, no matter how common it is for seemingly intelligent humans to make the mistake of doing so. >> More importantly, I am unsure the point of this argument. Are you >> trying to say that the items listed as broken in the draft are not >> actually broken? Because in my experience they are. IMHO, the fact >> that they are also broken in other (similar) scenarios is not evidence >> that they are not broken in this one. On the contrary, this scenario >> seems to be evidence to the brokenness in the others (until we get a >> chance to test and document them all - are you volunteering? ;). > > There seems to be a position, taken by others on these lists, that IPv6 is the only address family that matters. Interestingly, this position seems to be most pronounced from people not involved in operating production networks. But, regardless, if I were to accept this position then I might also agree that it doesn't matter whether or not draft-donley-nat444-impacts is misleading. > I don't think anyone has said that IPv6 is the only address family that matters. What I think people, myself included, have been saying is that IPv6 is the only way forward that does not involve many of these problems. (See my earlier Titanic post). As to whether or not it matters that people misinterpred draft-donly..., I'm not sure whether it actually does or not. There is no flavor of NAT that is particularly desirable. It's a matter of choosing the one that is least damaging to your environment where least damage may boil down to a choice between 5% and 3% remaining functionality. > On the contrary: While I emphatically agree that IPv6 is the path forward, I don't accept the notion that IPv4 no longer matters. IPv4 is the present-day Internet, and IPv4 connectivity is demanded by present-day paying customers - you don't burn the bridge until *after* you've crossed it. Further, given that IPv4 does matter yet has an exhausted address supply, there exists a need for IPv4 address sharing technology. Fundamentally, this means that we need to discuss and engineer the best possible address sharing technology. It may never be as good as native end-to-end IPv6, but sub-optimal is not the same thing as "broken" as others have claimed, and sub-optimal might be acceptable if it's the only alternative. > I don't think anyone is saying IPv4 no longer matters. I think we are saying that effort spent attempting to make the deteriorating IPv4 situation deteriorate less is both futile and better spent on making the IPv6 deployment situation better. > Of course, we can also rely on an IPv4 address market to avoid NAT in the more sensitive situations (i.e. situations with more sensitive users). But that's a different conversation. > Only if you expect that you can rely on a supply side in such a market. I am unconvinced that such will be reliable, especially after about 6 months of trading. This also presumes that more sensitive users can be defined in terms of what those users are willing (or able) to pay. Owen (who is very glad he has provider-independent addresses in both families as we approach this iceberg) From dwing at cisco.com Tue Feb 22 10:00:37 2011 From: dwing at cisco.com (Dan Wing) Date: Tue, 22 Feb 2011 08:00:37 -0800 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> <4C060A07-4FA7-467B-8BA8-8D4D04A0BA9A@queuefull.net> <117f01cbd207$34f42290$9edc67b0$@com> <41EE506B-D6BA-4AB5-A211-41BFE114F70E@delong.com> <132601cbd235$69298720$3b7c9560$@com> Message-ID: <14a601cbd2a9$a6d47ac0$f47d7040$@com> > -----Original Message----- > From: Chris Grundemann [mailto:cgrundemann at gmail.com] > Sent: Monday, February 21, 2011 8:17 PM > To: Dan Wing > Cc: Owen DeLong; Benson Schliesser; NANOG list; ARIN-PPML List > Subject: Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 > naysayer...) > > On Mon, Feb 21, 2011 at 19:08, Dan Wing wrote: > > > Its title, filename, abstract, and introduction all say the problems > > are specific to NAT444. ?Which is untrue. > > I just re-read the filename, abstract and introduction, and I disagree > that any of those say that the problems are specific to NAT444. They > all do state that these problems are present in NAT444, but not that > it's the only technology/scenario/configuration where you might find > them. > > More importantly, I am unsure the point of this argument. My point is that: NAT breaks things, but NAT444 is /not/ the only case where breakage occurs. > Are you > trying to say that the items listed as broken in the draft are not > actually broken? Because in my experience they are. IMHO, the fact > that they are also broken in other (similar) scenarios is not evidence > that they are not broken in this one. On the contrary, this scenario > seems to be evidence to the brokenness in the others (until we get a > chance to test and document them all - are you volunteering? ;). Vendor test results don't carry much value. The authors of draft-donley-nat444-impacts did testing, and I sincerely hope will publish results that split the impacts of access bandwidth starvation from home NAT from CGN from NAT444. -d > Cheers, > ~Chris > > > > -d > > > > > > > > > > > -- > @ChrisGrundemann > weblog.chrisgrundemann.com > www.burningwiththebush.com > www.theIPv6experts.net > www.coisoc.org From lists at iamchriswallace.com Tue Feb 22 11:17:05 2011 From: lists at iamchriswallace.com (Chris Wallace) Date: Tue, 22 Feb 2011 12:17:05 -0500 Subject: BGP Failover Question In-Reply-To: References: <49274CE9-307A-4C36-B311-01B42DD0C735@iamchriswallace.com> Message-ID: <87D0D567-2B79-4124-8524-2492D2EFFA64@iamchriswallace.com> We are recieving full routes from both providers. ---Chris On Feb 21, 2011, at 6:36 PM, Charles Gucker wrote: > On Mon, Feb 21, 2011 at 4:10 PM, Chris Wallace > wrote: >> This isn't the first time we have seen this issue with our various providers, how can I prevent issues like this from happening in the future? > > Quick question, are you running with a default route from your > provider? If so, you're better off either finding another provider, > or upgrading the router (if necessary) to carry a full table. If > they do something to partition their network, you will see the > decrease in routes learned from them, provided you see those routes > and not the default route as asked above. > > charles From bhmccie at gmail.com Tue Feb 22 11:23:13 2011 From: bhmccie at gmail.com (Hammer) Date: Tue, 22 Feb 2011 11:23:13 -0600 Subject: BGP Failover Question In-Reply-To: <87D0D567-2B79-4124-8524-2492D2EFFA64@iamchriswallace.com> References: <49274CE9-307A-4C36-B311-01B42DD0C735@iamchriswallace.com> <87D0D567-2B79-4124-8524-2492D2EFFA64@iamchriswallace.com> Message-ID: As Max stated, you can set triggers based on thresholds that are monitered via multiple methods in Cisco IOS. That way you could force the route down dynamically. There's always a risk when letting the machines do the thinking but this would help in situations like this. Can't speak for other vendors but I'm sure the features are similar. -Hammer- "I was a normal American nerd." -Jack Herer On Tue, Feb 22, 2011 at 11:17 AM, Chris Wallace wrote: > We are recieving full routes from both providers. > > ---Chris > > On Feb 21, 2011, at 6:36 PM, Charles Gucker wrote: > > > On Mon, Feb 21, 2011 at 4:10 PM, Chris Wallace > > wrote: > >> This isn't the first time we have seen this issue with our various > providers, how can I prevent issues like this from happening in the future? > > > > Quick question, are you running with a default route from your > > provider? If so, you're better off either finding another provider, > > or upgrading the router (if necessary) to carry a full table. If > > they do something to partition their network, you will see the > > decrease in routes learned from them, provided you see those routes > > and not the default route as asked above. > > > > charles > > > From Gavin.Pearce at 3seven9.com Tue Feb 22 12:05:16 2011 From: Gavin.Pearce at 3seven9.com (Gavin Pearce) Date: Tue, 22 Feb 2011 18:05:16 -0000 Subject: Contact for APEWS.org? In-Reply-To: <4D62D672.1080701@trelane.net> References: <4B4120B1642DCF48ACA84E4F82C8E1F65A9961CE50@EXCH><4D62D36E.4040400@2mbit.com> <4D62D672.1080701@trelane.net> Message-ID: > APEWS is braindead in execution, if not in fact. They list about half > of all IPv4 space, and one might reasonably state that anyone using them > deserves their own self-inflicted SMTP intranet. > http://www.dnsbl.com/2007/08/apews-news-and-commentary-roundup.html > Andrew The link Andrew sent over contains some great advice - make sure to read through to: http://www.dnsbl.com/2007/08/what-to-do-if-you-are-listed-on-apews.html From bclark at spectraaccess.com Tue Feb 22 12:11:28 2011 From: bclark at spectraaccess.com (Bret Clark) Date: Tue, 22 Feb 2011 13:11:28 -0500 Subject: BGP Failover Question In-Reply-To: References: <49274CE9-307A-4C36-B311-01B42DD0C735@iamchriswallace.com> <87D0D567-2B79-4124-8524-2492D2EFFA64@iamchriswallace.com> Message-ID: <4D63FC50.9050400@spectraaccess.com> On 02/22/2011 12:23 PM, Hammer wrote: > As Max stated, you can set triggers based on thresholds that are monitered > via multiple methods in Cisco IOS. That way you could force the route down > dynamically. There's always a risk when letting the machines do the thinking > but this would help in situations like this. Can't speak for other vendors > but I'm sure the features are similar. > Well as someone else stated, if an upstream provider can't provide BGP reliably then it's time to give them the boot. Once in a year, okay, but beyond that, then it's time to read riot act with that provider. Bret From bhmccie at gmail.com Tue Feb 22 12:15:39 2011 From: bhmccie at gmail.com (Hammer) Date: Tue, 22 Feb 2011 12:15:39 -0600 Subject: BGP Failover Question In-Reply-To: <4D63FC50.9050400@spectraaccess.com> References: <49274CE9-307A-4C36-B311-01B42DD0C735@iamchriswallace.com> <87D0D567-2B79-4124-8524-2492D2EFFA64@iamchriswallace.com> <4D63FC50.9050400@spectraaccess.com> Message-ID: I'm not argueing that at all. But it wasn't relevent to the question at hand. And depending on the scale of your business dumping providers is not something done on a whim. It's not like your fed up with DSL and want to convert to Cable. -Hammer- "I was a normal American nerd." -Jack Herer On Tue, Feb 22, 2011 at 12:11 PM, Bret Clark wrote: > On 02/22/2011 12:23 PM, Hammer wrote: > >> As Max stated, you can set triggers based on thresholds that are monitered >> via multiple methods in Cisco IOS. That way you could force the route down >> dynamically. There's always a risk when letting the machines do the >> thinking >> but this would help in situations like this. Can't speak for other vendors >> but I'm sure the features are similar. >> >> Well as someone else stated, if an upstream provider can't provide BGP > reliably then it's time to give them the boot. Once in a year, okay, but > beyond that, then it's time to read riot act with that provider. > Bret > > From owen at delong.com Tue Feb 22 12:38:55 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Feb 2011 10:38:55 -0800 Subject: BGP Failover Question In-Reply-To: References: <49274CE9-307A-4C36-B311-01B42DD0C735@iamchriswallace.com> <87D0D567-2B79-4124-8524-2492D2EFFA64@iamchriswallace.com> <4D63FC50.9050400@spectraaccess.com> Message-ID: <6A111CD4-6F1E-4965-BC64-88E2B90FBC40@delong.com> Assuming that he has provider independent space (why run full BGP feeds if you are not multihomed?), then, actually it's about on par and less disruptive in general. Add new provider, wait a day or two, then disconnect old provider. If he's using provider assigned space, then, the big hurdle is switching to provider independent (requires a renumber), but, that's a good idea for a variety of reasons. I would hardly call the type and frequency of outages described a "whim" when using that as a reason to change providers. Sounds like he is suffering severe impact to his business. Owen On Feb 22, 2011, at 10:15 AM, Hammer wrote: > I'm not argueing that at all. But it wasn't relevent to the question at > hand. And depending on the scale of your business dumping providers is not > something done on a whim. It's not like your fed up with DSL and want to > convert to Cable. > > > -Hammer- > > "I was a normal American nerd." > -Jack Herer > > > > > > On Tue, Feb 22, 2011 at 12:11 PM, Bret Clark wrote: > >> On 02/22/2011 12:23 PM, Hammer wrote: >> >>> As Max stated, you can set triggers based on thresholds that are monitered >>> via multiple methods in Cisco IOS. That way you could force the route down >>> dynamically. There's always a risk when letting the machines do the >>> thinking >>> but this would help in situations like this. Can't speak for other vendors >>> but I'm sure the features are similar. >>> >>> Well as someone else stated, if an upstream provider can't provide BGP >> reliably then it's time to give them the boot. Once in a year, okay, but >> beyond that, then it's time to read riot act with that provider. >> Bret >> >> From bhmccie at gmail.com Tue Feb 22 12:52:10 2011 From: bhmccie at gmail.com (Hammer) Date: Tue, 22 Feb 2011 12:52:10 -0600 Subject: BGP Failover Question In-Reply-To: <6A111CD4-6F1E-4965-BC64-88E2B90FBC40@delong.com> References: <49274CE9-307A-4C36-B311-01B42DD0C735@iamchriswallace.com> <87D0D567-2B79-4124-8524-2492D2EFFA64@iamchriswallace.com> <4D63FC50.9050400@spectraaccess.com> <6A111CD4-6F1E-4965-BC64-88E2B90FBC40@delong.com> Message-ID: I agree. But swapping providers is not the default answer in some environments. I work in an enterprise with multiple GE circuits from multiple providers to the Internet. The lead time on calling up a different carrier and saying "I need a gigabit connection to the Internet" would probably be 90-120 days. And then you get to go thru the contracts/negotiations and MSAs. You don't just flip. In smaller operations I understand. But I was simply saying that it's not always that easy. If I went to my boss and said one of our carriers sucks and we should dump them he would just laugh and throw me out. 1. What are the SLAs with the carrier in question? Do you have them clearly defined? Are they out of SLA? If so, what compensation is entitled based on violation of said SLA? 2. What trending are you doing to document the failures in SLA of the carrier in question? Do we have a documented pattern of poor performence by using that trending? 3. What are our contractual or legal options based on items 1 and 2? 4. Don't forget about the Layer8 (political) factor. If your telco manager is buddies with the carrier then you have to double your documentation against them. Some companies spend tens of millions a month on circuits. You better be ready to justify yourself. -Hammer- "I was a normal American nerd." -Jack Herer On Tue, Feb 22, 2011 at 12:38 PM, Owen DeLong wrote: > Assuming that he has provider independent space (why run full BGP feeds if > you > are not multihomed?), then, actually it's about on par and less disruptive > in > general. Add new provider, wait a day or two, then disconnect old > provider. > > If he's using provider assigned space, then, the big hurdle is switching to > provider > independent (requires a renumber), but, that's a good idea for a variety of > reasons. > > I would hardly call the type and frequency of outages described a "whim" > when > using that as a reason to change providers. Sounds like he is suffering > severe impact to his business. > > Owen > > On Feb 22, 2011, at 10:15 AM, Hammer wrote: > > > I'm not argueing that at all. But it wasn't relevent to the question at > > hand. And depending on the scale of your business dumping providers is > not > > something done on a whim. It's not like your fed up with DSL and want to > > convert to Cable. > > > > > > -Hammer- > > > > "I was a normal American nerd." > > -Jack Herer > > > > > > > > > > > > On Tue, Feb 22, 2011 at 12:11 PM, Bret Clark >wrote: > > > >> On 02/22/2011 12:23 PM, Hammer wrote: > >> > >>> As Max stated, you can set triggers based on thresholds that are > monitered > >>> via multiple methods in Cisco IOS. That way you could force the route > down > >>> dynamically. There's always a risk when letting the machines do the > >>> thinking > >>> but this would help in situations like this. Can't speak for other > vendors > >>> but I'm sure the features are similar. > >>> > >>> Well as someone else stated, if an upstream provider can't provide BGP > >> reliably then it's time to give them the boot. Once in a year, okay, but > >> beyond that, then it's time to read riot act with that provider. > >> Bret > >> > >> > > From bhmccie at gmail.com Tue Feb 22 12:54:06 2011 From: bhmccie at gmail.com (Hammer) Date: Tue, 22 Feb 2011 12:54:06 -0600 Subject: BGP Failover Question In-Reply-To: References: <49274CE9-307A-4C36-B311-01B42DD0C735@iamchriswallace.com> <87D0D567-2B79-4124-8524-2492D2EFFA64@iamchriswallace.com> <4D63FC50.9050400@spectraaccess.com> <6A111CD4-6F1E-4965-BC64-88E2B90FBC40@delong.com> Message-ID: Funny, I was just at your IPv6 sight this morning while researching multihoming scenarios. "That name sounds familiar....." -Hammer- "I was a normal American nerd." -Jack Herer On Tue, Feb 22, 2011 at 12:52 PM, Hammer wrote: > I agree. But swapping providers is not the default answer in some > environments. I work in an enterprise with multiple GE circuits from > multiple providers to the Internet. The lead time on calling up a different > carrier and saying "I need a gigabit connection to the Internet" would > probably be 90-120 days. And then you get to go thru the > contracts/negotiations and MSAs. You don't just flip. In smaller operations > I understand. But I was simply saying that it's not always that easy. If I > went to my boss and said one of our carriers sucks and we should dump them > he would just laugh and throw me out. > > 1. What are the SLAs with the carrier in question? Do you have them clearly > defined? Are they out of SLA? If so, what compensation is entitled based on > violation of said SLA? > > 2. What trending are you doing to document the failures in SLA of the > carrier in question? Do we have a documented pattern of poor performence by > using that trending? > > 3. What are our contractual or legal options based on items 1 and 2? > > 4. Don't forget about the Layer8 (political) factor. If your telco manager > is buddies with the carrier then you have to double your documentation > against them. Some companies spend tens of millions a month on circuits. You > better be ready to justify yourself. > > > -Hammer- > > "I was a normal American nerd." > -Jack Herer > > > > > > On Tue, Feb 22, 2011 at 12:38 PM, Owen DeLong wrote: > >> Assuming that he has provider independent space (why run full BGP feeds if >> you >> are not multihomed?), then, actually it's about on par and less disruptive >> in >> general. Add new provider, wait a day or two, then disconnect old >> provider. >> >> If he's using provider assigned space, then, the big hurdle is switching >> to provider >> independent (requires a renumber), but, that's a good idea for a variety >> of reasons. >> >> I would hardly call the type and frequency of outages described a "whim" >> when >> using that as a reason to change providers. Sounds like he is suffering >> severe impact to his business. >> >> Owen >> >> On Feb 22, 2011, at 10:15 AM, Hammer wrote: >> >> > I'm not argueing that at all. But it wasn't relevent to the question at >> > hand. And depending on the scale of your business dumping providers is >> not >> > something done on a whim. It's not like your fed up with DSL and want to >> > convert to Cable. >> > >> > >> > -Hammer- >> > >> > "I was a normal American nerd." >> > -Jack Herer >> > >> > >> > >> > >> > >> > On Tue, Feb 22, 2011 at 12:11 PM, Bret Clark > >wrote: >> > >> >> On 02/22/2011 12:23 PM, Hammer wrote: >> >> >> >>> As Max stated, you can set triggers based on thresholds that are >> monitered >> >>> via multiple methods in Cisco IOS. That way you could force the route >> down >> >>> dynamically. There's always a risk when letting the machines do the >> >>> thinking >> >>> but this would help in situations like this. Can't speak for other >> vendors >> >>> but I'm sure the features are similar. >> >>> >> >>> Well as someone else stated, if an upstream provider can't provide BGP >> >> reliably then it's time to give them the boot. Once in a year, okay, >> but >> >> beyond that, then it's time to read riot act with that provider. >> >> Bret >> >> >> >> >> >> > From owen at delong.com Tue Feb 22 13:20:12 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Feb 2011 11:20:12 -0800 Subject: BGP Failover Question In-Reply-To: References: <49274CE9-307A-4C36-B311-01B42DD0C735@iamchriswallace.com> <87D0D567-2B79-4124-8524-2492D2EFFA64@iamchriswallace.com> <4D63FC50.9050400@spectraaccess.com> <6A111CD4-6F1E-4965-BC64-88E2B90FBC40@delong.com> Message-ID: <97F0D171-A49D-4BE2-BCAE-18F481086304@delong.com> On Feb 22, 2011, at 10:52 AM, Hammer wrote: > I agree. But swapping providers is not the default answer in some environments. I work in an enterprise with multiple GE circuits from multiple providers to the Internet. The lead time on calling up a different carrier and saying "I need a gigabit connection to the Internet" would probably be 90-120 days. And then you get to go thru the contracts/negotiations and MSAs. You don't just flip. In smaller operations I understand. But I was simply saying that it's not always that easy. If I went to my boss and said one of our carriers sucks and we should dump them he would just laugh and throw me out. > That depends on where you are. If you have a router in one or more of the many "carrier hotels" around the world, you can usually order a new Gig-E cross-connect with service in less than a week. If you need to have a circuit engineered, then, 30-90 days is probably about right. If you need to have facilities installed to provide said circuit, it can be as much as 180 days. However, I don't think the point was "disconnect them tomorrow". I think the point was "If the impact is that severe, the sooner you start the new provider process, the sooner you get relief." > 1. What are the SLAs with the carrier in question? Do you have them clearly defined? Are they out of SLA? If so, what compensation is entitled based on violation of said SLA? 99.99% of all SLAs are a pittance of money refunded IF you jump through extreme hoops to collect. They are rarely sufficient to resolve or even compensate for outages. > > 2. What trending are you doing to document the failures in SLA of the carrier in question? Do we have a documented pattern of poor performence by using that trending? > > 3. What are our contractual or legal options based on items 1 and 2? > > 4. Don't forget about the Layer8 (political) factor. If your telco manager is buddies with the carrier then you have to double your documentation against them. Some companies spend tens of millions a month on circuits. You better be ready to justify yourself. Yeah, this is usually the biggest problem. Owen > > > -Hammer- > > "I was a normal American nerd." > -Jack Herer > > > > > > On Tue, Feb 22, 2011 at 12:38 PM, Owen DeLong wrote: > Assuming that he has provider independent space (why run full BGP feeds if you > are not multihomed?), then, actually it's about on par and less disruptive in > general. Add new provider, wait a day or two, then disconnect old provider. > > If he's using provider assigned space, then, the big hurdle is switching to provider > independent (requires a renumber), but, that's a good idea for a variety of reasons. > > I would hardly call the type and frequency of outages described a "whim" when > using that as a reason to change providers. Sounds like he is suffering > severe impact to his business. > > Owen > > On Feb 22, 2011, at 10:15 AM, Hammer wrote: > > > I'm not argueing that at all. But it wasn't relevent to the question at > > hand. And depending on the scale of your business dumping providers is not > > something done on a whim. It's not like your fed up with DSL and want to > > convert to Cable. > > > > > > -Hammer- > > > > "I was a normal American nerd." > > -Jack Herer > > > > > > > > > > > > On Tue, Feb 22, 2011 at 12:11 PM, Bret Clark wrote: > > > >> On 02/22/2011 12:23 PM, Hammer wrote: > >> > >>> As Max stated, you can set triggers based on thresholds that are monitered > >>> via multiple methods in Cisco IOS. That way you could force the route down > >>> dynamically. There's always a risk when letting the machines do the > >>> thinking > >>> but this would help in situations like this. Can't speak for other vendors > >>> but I'm sure the features are similar. > >>> > >>> Well as someone else stated, if an upstream provider can't provide BGP > >> reliably then it's time to give them the boot. Once in a year, okay, but > >> beyond that, then it's time to read riot act with that provider. > >> Bret > >> > >> > > From goemon at anime.net Tue Feb 22 13:44:47 2011 From: goemon at anime.net (goemon at anime.net) Date: Tue, 22 Feb 2011 11:44:47 -0800 (PST) Subject: admin-c/tech-c deny responsibility/ownership of netblock Message-ID: Is there a process to revoke netblocks from entities which deny ownership? http://www.db.ripe.net/whois?searchtext=77.223.129.43 The admin-c, tech-c deny any responsibility for this netblock. -Dan From ristic.sasa at gmail.com Tue Feb 22 14:11:03 2011 From: ristic.sasa at gmail.com (Sasa Ristic) Date: Tue, 22 Feb 2011 21:11:03 +0100 Subject: admin-c/tech-c deny responsibility/ownership of netblock In-Reply-To: References: Message-ID: What do you mean: "deny any responsibility"? I'm not sure I follow exactly, please be more specific? -- ricky From iljitsch at muada.com Tue Feb 22 14:11:33 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 22 Feb 2011 21:11:33 +0100 Subject: admin-c/tech-c deny responsibility/ownership of netblock In-Reply-To: References: Message-ID: <639615FC-5EA1-4DD1-AE69-CEB6621DF48A@muada.com> On 22 feb 2011, at 20:44, goemon at anime.net wrote: > The admin-c, tech-c deny any responsibility for this netblock. Have you talked to RIPE? From netgeek at bgp4.net Tue Feb 22 14:26:11 2011 From: netgeek at bgp4.net (Janet Sullivan) Date: Tue, 22 Feb 2011 12:26:11 -0800 Subject: [OT] Internet connectivity options in Afghanistan? Message-ID: <4D641BE3.5030608@bgp4.net> I'm looking for cheap/slow internet connectivity options in Kabul, Jalalabad, and Herat. The connections will be used by AFCECO orphanages, so speed isn't as much of an issue as cost. I'm guessing that satellite might be the only game in town, but if any of you fine folks know of connectivity options, I'd appreciate an email. From bhmccie at gmail.com Tue Feb 22 14:58:07 2011 From: bhmccie at gmail.com (Hammer) Date: Tue, 22 Feb 2011 14:58:07 -0600 Subject: BGP Failover Question In-Reply-To: <97F0D171-A49D-4BE2-BCAE-18F481086304@delong.com> References: <49274CE9-307A-4C36-B311-01B42DD0C735@iamchriswallace.com> <87D0D567-2B79-4124-8524-2492D2EFFA64@iamchriswallace.com> <4D63FC50.9050400@spectraaccess.com> <6A111CD4-6F1E-4965-BC64-88E2B90FBC40@delong.com> <97F0D171-A49D-4BE2-BCAE-18F481086304@delong.com> Message-ID: Uncle! -Hammer- "I was a normal American nerd." -Jack Herer On Tue, Feb 22, 2011 at 1:20 PM, Owen DeLong wrote: > > On Feb 22, 2011, at 10:52 AM, Hammer wrote: > > I agree. But swapping providers is not the default answer in some > environments. I work in an enterprise with multiple GE circuits from > multiple providers to the Internet. The lead time on calling up a different > carrier and saying "I need a gigabit connection to the Internet" would > probably be 90-120 days. And then you get to go thru the > contracts/negotiations and MSAs. You don't just flip. In smaller operations > I understand. But I was simply saying that it's not always that easy. If I > went to my boss and said one of our carriers sucks and we should dump them > he would just laugh and throw me out. > > > That depends on where you are. If you have a router in one or more of the > many "carrier hotels" around the world, you can usually order a new Gig-E > cross-connect with service in less than a week. If you need to have a > circuit engineered, then, 30-90 days is probably about right. If you need to > have facilities installed to provide said circuit, it can be as much as 180 > days. > > However, I don't think the point was "disconnect them tomorrow". I think > the point was "If the impact is that severe, the sooner you start the new > provider process, the sooner you get relief." > > 1. What are the SLAs with the carrier in question? Do you have them > clearly defined? Are they out of SLA? If so, what compensation is entitled > based on violation of said SLA? > > > 99.99% of all SLAs are a pittance of money refunded IF you jump through > extreme hoops to collect. They are rarely sufficient to resolve > or even compensate for outages. > > > 2. What trending are you doing to document the failures in SLA of the > carrier in question? Do we have a documented pattern of poor performence by > using that trending? > > 3. What are our contractual or legal options based on items 1 and 2? > > 4. Don't forget about the Layer8 (political) factor. If your telco manager > is buddies with the carrier then you have to double your documentation > against them. Some companies spend tens of millions a month on circuits. You > better be ready to justify yourself. > > > Yeah, this is usually the biggest problem. > > Owen > > > > -Hammer- > > "I was a normal American nerd." > -Jack Herer > > > > > > On Tue, Feb 22, 2011 at 12:38 PM, Owen DeLong wrote: > >> Assuming that he has provider independent space (why run full BGP feeds if >> you >> are not multihomed?), then, actually it's about on par and less disruptive >> in >> general. Add new provider, wait a day or two, then disconnect old >> provider. >> >> If he's using provider assigned space, then, the big hurdle is switching >> to provider >> independent (requires a renumber), but, that's a good idea for a variety >> of reasons. >> >> I would hardly call the type and frequency of outages described a "whim" >> when >> using that as a reason to change providers. Sounds like he is suffering >> severe impact to his business. >> >> Owen >> >> On Feb 22, 2011, at 10:15 AM, Hammer wrote: >> >> > I'm not argueing that at all. But it wasn't relevent to the question at >> > hand. And depending on the scale of your business dumping providers is >> not >> > something done on a whim. It's not like your fed up with DSL and want to >> > convert to Cable. >> > >> > >> > -Hammer- >> > >> > "I was a normal American nerd." >> > -Jack Herer >> > >> > >> > >> > >> > >> > On Tue, Feb 22, 2011 at 12:11 PM, Bret Clark > >wrote: >> > >> >> On 02/22/2011 12:23 PM, Hammer wrote: >> >> >> >>> As Max stated, you can set triggers based on thresholds that are >> monitered >> >>> via multiple methods in Cisco IOS. That way you could force the route >> down >> >>> dynamically. There's always a risk when letting the machines do the >> >>> thinking >> >>> but this would help in situations like this. Can't speak for other >> vendors >> >>> but I'm sure the features are similar. >> >>> >> >>> Well as someone else stated, if an upstream provider can't provide BGP >> >> reliably then it's time to give them the boot. Once in a year, okay, >> but >> >> beyond that, then it's time to read riot act with that provider. >> >> Bret >> >> >> >> >> >> > > From jeffrey.lyon at blacklotus.net Tue Feb 22 15:34:18 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Tue, 22 Feb 2011 16:34:18 -0500 Subject: [OT] Internet connectivity options in Afghanistan? In-Reply-To: <4D641BE3.5030608@bgp4.net> References: <4D641BE3.5030608@bgp4.net> Message-ID: On Tue, Feb 22, 2011 at 3:26 PM, Janet Sullivan wrote: > I'm looking for cheap/slow internet connectivity options in Kabul, > Jalalabad, and Herat. ?The connections will be used by AFCECO orphanages, so > speed isn't as much of an issue as cost. ?I'm guessing that satellite might > be the only game in town, but if any of you fine folks know of connectivity > options, I'd appreciate an email. > > > You can get expensive and slow, not so sure about cheap and slow. Bentley Walker and ts2.pl is what basically everyone is using out there, and it's all 100% garbage. Our company had a contract to provide 6 Mbps of connectivity to a NATO base, so I can share notes with anyone who is interested. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From bensons at queuefull.net Tue Feb 22 15:36:12 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Tue, 22 Feb 2011 15:36:12 -0600 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> <4C060A07-4FA7-467B-8BA8-8D4D04A0BA9A@queuefull.net> <117f01cbd207$34f42290$9edc67b0$@com> <41EE506B-D6BA-4AB5-A211-41BFE114F70E@delong.com> <132601cbd235$69298720$3b7c9560$@com> <41DC9C32-7902-459E-A4FA-8A70EED53AB4@queuefull.net> Message-ID: On Feb 22, 2011, at 3:14 AM, Randy Bush wrote: >> There seems to be a position, taken by others on these lists, that >> IPv6 is the only address family that matters. Interestingly, this >> position seems to be most pronounced from people not involved in >> operating production networks. > > excuse me! Hi, Randy. I didn't mean to deny you exist; you apparently do. ;) But in my sampling, operators with the opinion that 'IPv4 doesn't matter' represent the minority. Of course, it also depends on how you define "doesn't matter". I think that ongoing operation matters, especially when "ongoing" means a continued expectation of both existing and new customers. It's easy to say, "burn the IPv4 bridge" so we're forced to migrate to IPv6. But it's another thing to actually do it, when you're competing for customers that want IPv4 connectivity. That said, we're not forced to choose only one: IPv4 vs. IPv6. We should migrate to IPv6 because it makes sense - IPv4 is going to become more expensive and painful (to use and support). That doesn't preclude us from patching IPv4 together long enough to cross the bridge first. Thoughts? Cheers, -Benson From dhubbard at dino.hostasaurus.com Tue Feb 22 15:42:28 2011 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Tue, 22 Feb 2011 16:42:28 -0500 Subject: Howto for BGP black holing/null routing Message-ID: I was wondering if anyone has a howto floating around on the step by step setup of having an internal bgp peer for sending quick updates to border routers to null route sources of undesirable traffic? I've seen it discussed on nanog from time to time, typically suggesting using Zebra, but could not search up a link on a step by step. Thanks, David From lukasz at bromirski.net Tue Feb 22 15:54:04 2011 From: lukasz at bromirski.net (=?ISO-8859-2?Q?=A3ukasz_Bromirski?=) Date: Tue, 22 Feb 2011 22:54:04 +0100 Subject: Howto for BGP black holing/null routing In-Reply-To: References: Message-ID: <4D64307C.9040106@bromirski.net> On 2011-02-22 22:42, David Hubbard wrote: > I was wondering if anyone has a howto floating around on the > step by step setup of having an internal bgp peer for sending > quick updates to border routers to null route sources of > undesirable traffic? I've seen it discussed on nanog from > time to time, typically suggesting using Zebra, but could > not search up a link on a step by step. Take a look here for starters: http://www.cisco.com/web/about/security/intelligence/blackhole.pdf Searching through NANOG archives will return a couple of sessions that went through the other vendor configs for such functionality. -- "There's no sense in being precise when | ?ukasz Bromirski you don't know what you're talking | jid:lbromirski at jabber.org about." John von Neumann | http://lukasz.bromirski.net From jack at crepinc.com Tue Feb 22 15:55:44 2011 From: jack at crepinc.com (Jack Carrozzo) Date: Tue, 22 Feb 2011 16:55:44 -0500 Subject: Howto for BGP black holing/null routing In-Reply-To: References: Message-ID: Maybe I read your question wrong, but null-routing things at your border is often not very useful if the traffic is flooding your transit links. Most transits publish their community lists - you just need to tag the prefix you want to blackhole with the right community. See example from HE: http://www.he.net/adm/blackhole.html -Jack Carrozzo On Tue, Feb 22, 2011 at 4:42 PM, David Hubbard < dhubbard at dino.hostasaurus.com> wrote: > I was wondering if anyone has a howto floating around on the > step by step setup of having an internal bgp peer for sending > quick updates to border routers to null route sources of > undesirable traffic? I've seen it discussed on nanog from > time to time, typically suggesting using Zebra, but could > not search up a link on a step by step. > > Thanks, > > David > > From Valdis.Kletnieks at vt.edu Tue Feb 22 15:54:42 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 22 Feb 2011 16:54:42 -0500 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: Your message of "Tue, 22 Feb 2011 02:29:23 CST." <41DC9C32-7902-459E-A4FA-8A70EED53AB4@queuefull.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> <4C060A07-4FA7-467B-8BA8-8D4D04A0BA9A@queuefull.net> <117f01cbd207$34f42290$9edc67b0$@com> <41EE506B-D6BA-4AB5-A211-41BFE114F70E@delong.com> <132601cbd235$69298720$3b7c9560$@com> <41DC9C32-7902-459E-A4FA-8A70EED53AB4@queuefull.net> Message-ID: <34623.1298411682@localhost> On Tue, 22 Feb 2011 02:29:23 CST, Benson Schliesser said: > There seems to be a position, taken by others on these lists, that IPv6 > is the only address family that matters. Interestingly, this position > seems to be most pronounced from people not involved in operating > production networks. "most pronounced from people not involved in operating production networks that are way behind the planning curve for IPv6 deployment". There, fixed that for you. (Full disclosure - yesterday's MRTG graphs show our border routers averaging 4Gbit/sec of IPv4 traffic and 150 Mbits/sec of IPv6 - so 4% or so of our production off-campus traffic is already IPv6) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jared at puck.nether.net Tue Feb 22 15:57:21 2011 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 22 Feb 2011 16:57:21 -0500 Subject: Howto for BGP black holing/null routing In-Reply-To: <4D64307C.9040106@bromirski.net> References: <4D64307C.9040106@bromirski.net> Message-ID: Also: http://docs.as701.net/tmp/CustomerBlackhole.txt Remember to set eBGP multihop on sessions for the next-hop rewrite capability :) - Jared On Feb 22, 2011, at 4:54 PM, ?ukasz Bromirski wrote: > On 2011-02-22 22:42, David Hubbard wrote: >> I was wondering if anyone has a howto floating around on the >> step by step setup of having an internal bgp peer for sending >> quick updates to border routers to null route sources of >> undesirable traffic? I've seen it discussed on nanog from >> time to time, typically suggesting using Zebra, but could >> not search up a link on a step by step. > > Take a look here for starters: > http://www.cisco.com/web/about/security/intelligence/blackhole.pdf > > Searching through NANOG archives will return a couple of sessions > that went through the other vendor configs for such functionality. > > -- > "There's no sense in being precise when | ?ukasz Bromirski > you don't know what you're talking | jid:lbromirski at jabber.org > about." John von Neumann | http://lukasz.bromirski.net From morrowc.lists at gmail.com Tue Feb 22 16:06:00 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 22 Feb 2011 17:06:00 -0500 Subject: Howto for BGP black holing/null routing In-Reply-To: References: <4D64307C.9040106@bromirski.net> Message-ID: 2011/2/22 Jared Mauch : > Also: > > http://docs.as701.net/tmp/CustomerBlackhole.txt > > Remember to set eBGP multihop on sessions for the next-hop rewrite capability :) oh hey, I was looking for that! :) (I'll try to re-setup the www.secsup.org links tonight) ... this is a 'how to setup so a customer can blackhole', which you should be able to easily hack to 'make my quagga server a customer, make him be able to blackhole all of 0/0 by /32s' keep in mind also that somethings do not react well to k's of /32's ... > - Jared > > On Feb 22, 2011, at 4:54 PM, ?ukasz Bromirski wrote: > >> On 2011-02-22 22:42, David Hubbard wrote: >>> I was wondering if anyone has a howto floating around on the >>> step by step setup of having an internal bgp peer for sending >>> quick updates to border routers to null route sources of >>> undesirable traffic? ?I've seen it discussed on nanog from >>> time to time, typically suggesting using Zebra, but could >>> not search up a link on a step by step. >> >> Take a look here for starters: >> http://www.cisco.com/web/about/security/intelligence/blackhole.pdf >> >> Searching through NANOG archives will return a couple of sessions >> that went through the other vendor configs for such functionality. >> >> -- >> "There's no sense in being precise when | ? ? ? ? ? ? ? ?ukasz Bromirski >> you don't know what you're talking ? ? | ? ? ?jid:lbromirski at jabber.org >> about." ? ? ? ? ? ? ? John von Neumann | ? ?http://lukasz.bromirski.net > > > From bensons at queuefull.net Tue Feb 22 16:08:23 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Tue, 22 Feb 2011 16:08:23 -0600 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <34623.1298411682@localhost> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> <4C060A07-4FA7-467B-8BA8-8D4D04A0BA9A@queuefull.net> <117f01cbd207$34f42290$9edc67b0$@com> <41EE506B-D6BA-4AB5-A211-41BFE114F70E@delong.com> <132601cbd235$69298720$3b7c9560$@com> <41DC9C32-7902-459E-A4FA-8A70EED53AB4@queuefull.net> <34623.1298411682@localhost> Message-ID: On Feb 22, 2011, at 3:54 PM, Valdis.Kletnieks at vt.edu wrote: > On Tue, 22 Feb 2011 02:29:23 CST, Benson Schliesser said: >> There seems to be a position, taken by others on these lists, that IPv6 >> is the only address family that matters. Interestingly, this position >> seems to be most pronounced from people not involved in operating >> production networks. > > "most pronounced from people not involved in operating production networks > that are way behind the planning curve for IPv6 deployment". > > There, fixed that for you. My original text remains true, because I tend to hear IPv6-only advocacy from vendors and policy folks more than operators - even more so versus operators of commercial ISP networks. But I take your point, that operators ahead of the IPv6 deployment curve are most likely to stand up with that opinion. Of course, the "network effect" being what it is... Your network being 100% IPv6 doesn't solve the overall problem of reachability. I think your example of 4% traffic from VT is applicable - you will have to worry about IPv4 connectivity, in one form or another, until it diminishes significantly. It's a bit like a tragedy of the commons. Cheers, -Benson From mylists at battleop.com Tue Feb 22 16:10:02 2011 From: mylists at battleop.com (Richey) Date: Tue, 22 Feb 2011 17:10:02 -0500 Subject: SmartNet Alternatives In-Reply-To: <1297850165.v2.mailanyonewebmail-761213@fuseweb2d> References: <060EDFC2221B014B9504AC06B747F58A499BCC3B57@ex01.alentus.lan> <5A6D953473350C4B9995546AFE9939EE0BC13A7C@RWC-EX1.corp.seven.com> <6EFFEFBAC68377459A2E972105C759EC036456FC@EXVBE005-2.exch005intermedia .net> <87pqqvfzuj.fsf@mid.deneb.enyo.de> <1297850165.v2.mailanyonewebmail-761213@fuseweb2d> Message-ID: <11ec01cbd2dd$40c838a0$c258a9e0$@battleop.com> I've used them as well and they have been pretty good with gear that's common place. Just be careful if you get off the beaten path and are using gear like an IAD-2431-16FXS. They can help you with the hardware side on that kind of stuff but not so much with the software. Richey -----Original Message----- From: Neil J. McRae [mailto:neil at domino.org] Sent: Wednesday, February 16, 2011 4:56 AM To: gbonser at seven.com; tbraning at gmail.com Cc: nanog at nanog.org Subject: Re: SmartNet Alternatives I've used NHR for a number of deployments over the past couple of years and they are a fantastic organisation to work with. I've used them for maintenance support in the US for replacement of parts - highly recommended. ----- Original Message ----- From: tbraning at gmail.com Sent: Tue, February 15, 2011, 11:04 PM Subject: Re: SmartNet Alternatives I know NHR has a alternative that looks to be comparable. http://www.networkhardware.com/Maintenance/ -tb From bensons at queuefull.net Tue Feb 22 16:16:11 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Tue, 22 Feb 2011 16:16:11 -0600 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <7277A6F9-C21C-4EF0-8220-A3F3A707A836@delong.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> <4C060A07-4FA7-467B-8BA8-8D4D04A0BA9A@queuefull.net> <117f01cbd207$34f42290$9edc67b0$@com> <41EE506B-D6BA-4AB5-A211-41BFE114F70E@delong.com> <132601cbd235$69298720$3b7c9560$@com> <41DC9C32-7902-459E-A4FA-8A70EED53AB4@queuefull.net> <7277A6F9-C21C-4EF0-8220-A3F3A707A836@delong.com> Message-ID: <31BBAC11-53B0-49A9-80AA-94AE1CD9BDF3@queuefull.net> On Feb 22, 2011, at 3:40 AM, Owen DeLong wrote: >> There seems to be a position, taken by others on these lists, that IPv6 is the only address family that matters. Interestingly, this position seems to be most pronounced from people not involved in operating production networks. But, regardless, if I were to accept this position then I might also agree that it doesn't matter whether or not draft-donley-nat444-impacts is misleading. >> > I don't think anyone has said that IPv6 is the only address family > that matters. What I think people, myself included, have been saying > is that IPv6 is the only way forward that does not involve many of these > problems. (See my earlier Titanic post). I agree completely: IPv6 is the only way forward that avoids these problems. In fact, an understanding of CGN impacts should be enough motivation for operators and users to start deploying IPv6 immediately. > As to whether or not it matters that people misinterpred draft-donly..., > I'm not sure whether it actually does or not. There is no flavor of NAT > that is particularly desirable. It's a matter of choosing the one that is > least damaging to your environment where least damage may > boil down to a choice between 5% and 3% remaining functionality. I agree with your sentiment, that we should choose the least damaging solutions. Call it the "lesser evil" if you'd like. However, I think your estimates (5% vs 3%) are backwards. CGN-based solutions work for the vast majority of network traffic today - it's the stuff in the margin that breaks, according to all test reports I've seen. > I don't think anyone is saying IPv4 no longer matters. I think we are > saying that effort spent attempting to make the deteriorating IPv4 > situation deteriorate less is both futile and better spent on making > the IPv6 deployment situation better. It's not an exclusive situation - we can roll out IPv6 while continuing to maintain our existing IPv4 connectivity, support new customers with IPv4 needs, etc. As I mentioned before, we have to support the bridge we're crossing (crumbling IPv4 infrastructure) until we're on the other side (fertile IPv6 farmland). >> Of course, we can also rely on an IPv4 address market to avoid NAT in the more sensitive situations (i.e. situations with more sensitive users). But that's a different conversation. >> > Only if you expect that you can rely on a supply side in such a market. > I am unconvinced that such will be reliable, especially after about 6 > months of trading. This also presumes that more sensitive users can > be defined in terms of what those users are willing (or able) to pay. This is an interesting discussion, because the timeframe is central to everything I've commented above. Considering RIR exhaustion (4-12 months) plus ISP exhaustion (TBD, but let's say anywhere from 1 month to 5+ years after RIR exhaustion), I expect some network providers to struggle with IPv4 address exhaustion before the 3rd quarter of 2011. On the other hand, other network providers will have enough resources to last for years - let's call that "excess supply". By all realistic estimates, any network provider that hasn't deployed IPv6 support into their infrastructure will need anywhere from 3 months to 3 years or more - let's generously say around 18 months to the point where 60% - 80% of hosts have reached IPv6 connectivity. Just considering these facts, I think we can see why some ISPs might be interested in acquiring more addresses through 2012. And those with excess supply might be motivated (financially) by a marketplace to share their resources, to meet this need. Further, let's consider that some network services (such as content / hosting) will need IPv4 connectivity longer than others, in order to reach the long-tail. For this category, I can see why some networks might be interested in acquiring more addresses through 2013 - 2016. Fortunately, on the other side of 2012 prices should decrease because supply goes up (as some people give up IPv4). Thus the market value of an address probably can be represented by a curve peaking in a couple years and then declining to zero a few years after that. Feedback on this would be appreciated - but my current belief is that it's realistic to plan for a couple years of trading rather than "about 6 months". (Side note: If we really wanted people to move to IPv6 before now, we should have instituted increasing prices for RIR-provided addresses. I posit that we just didn't have the collective balls to do this.) Cheers, -Benson From alh-ietf at tndh.net Tue Feb 22 16:42:03 2011 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 22 Feb 2011 14:42:03 -0800 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> <4C060A07-4FA7-467B-8BA8-8D4D04A0BA9A@queuefull.net> <117f01cbd207$34f42290$9edc67b0$@com> <41EE506B-D6BA-4AB5-A211-41BFE114F70E@delong.com> <132601cbd235$69298720$3b7c9560$@com> <41DC9C32-7902-459E-A4FA-8A70EED53AB4@queuefull.net> Message-ID: <179801cbd2e1$bb904560$32b0d020$@net> Benson Schliesser wrote: > On Feb 22, 2011, at 3:14 AM, Randy Bush wrote: > > >> There seems to be a position, taken by others on these lists, that > >> IPv6 is the only address family that matters. Interestingly, this > >> position seems to be most pronounced from people not involved in > >> operating production networks. > > > > excuse me! > > Hi, Randy. I didn't mean to deny you exist; you apparently do. ;) But > in my sampling, operators with the opinion that 'IPv4 doesn't matter' > represent the minority. Of course, it also depends on how you define > "doesn't matter". I think that ongoing operation matters, especially > when "ongoing" means a continued expectation of both existing and new > customers. It's easy to say, "burn the IPv4 bridge" so we're forced to > migrate to IPv6. But it's another thing to actually do it, when you're > competing for customers that want IPv4 connectivity. > > That said, we're not forced to choose only one: IPv4 vs. IPv6. We > should migrate to IPv6 because it makes sense - IPv4 is going to become > more expensive and painful (to use and support). That doesn't preclude > us from patching IPv4 together long enough to cross the bridge first. > > Thoughts? The patching started in 1994 with RFC 1627.... how much time is needed??? Seriously, some people will not move until the path they are on is already burning, which is why they did nothing over the last 5 years despite knowing that the IANA pool was exhausting much faster than they had wanted to believe. It took getting within months of exhausting the IANA pool before the crowd woke up and noticed the path was on fire. Now you want 'just a little more'... after which it will be 'just a little more'. Fortunately Randy and a few others took action and demonstrated that 'this is not hard', it just takes some effort. Pouring more effort into hack upon hack is not making progress, it is stalling for the sake of stalling. Consumers don't want IPv4, they want connectivity to their favorite content. Hacks in the network to make that content appear to be available will be expensive to maintain, and irrelevant as soon as the content has realized the mess that has been made between them and their customers. More energy into moving content and apps will result in less energy wasted in deploying short lived hacks. Tony > > Cheers, > -Benson From bensons at queuefull.net Tue Feb 22 16:58:19 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Tue, 22 Feb 2011 16:58:19 -0600 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <179801cbd2e1$bb904560$32b0d020$@net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> <4C060A07-4FA7-467B-8BA8-8D4D04A0BA9A@queuefull.net> <117f01cbd207$34f42290$9edc67b0$@com> <41EE506B-D6BA-4AB5-A211-41BFE114F70E@delong.com> <132601cbd235$69298720$3b7c9560$@com> <41DC9C32-7902-459E-A4FA-8A70EED53AB4@queuefull.net> <179801cbd2e1$bb904560$32b0d020$@net> Message-ID: <155A8B44-B826-469D-9246-73DD5454CBCC@queuefull.net> On Feb 22, 2011, at 4:42 PM, Tony Hain wrote: > Seriously, some people will not move until the path they are on is already > burning, which is why they did nothing over the last 5 years despite knowing > that the IANA pool was exhausting much faster than they had wanted to > believe. It took getting within months of exhausting the IANA pool before > the crowd woke up and noticed the path was on fire. Now you want 'just a > little more'... after which it will be 'just a little more'. This won't go on forever. The "price" of IPv4 has been kept artificially low for the past decade, through a RIR-based system of rationing. There was never an immediate incentive to migrate. If we really wanted to motivate people before they reached the precipice, we should have increasingly raised the cost of an IPv4 address. Now, IPv4 exhaustion has effectively raised that cost for us, and people are motivated to migrate to IPv6. But since we didn't force this situation sooner, we now also have to deal with the effects of exhaustion. That's all I'm talking about. IPv4 hacks will not be better or cheaper than IPv6, and they're nothing to fear in terms of IPv6 adoption. Cheers, -Benson From semih at alanadi.net Tue Feb 22 17:36:42 2011 From: semih at alanadi.net (Yasar Semih Alev) Date: Wed, 23 Feb 2011 01:36:42 +0200 Subject: admin-c/tech-c deny responsibility/ownership of netblock Message-ID: <004801cbd2e9$5c02a040$1407e0c0$@alanadi.net> I am responsibility of the subnet. How can i help you? We already added abuse-mailbox to whois information. Semih. From owen at delong.com Tue Feb 22 17:41:26 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Feb 2011 15:41:26 -0800 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> <4C060A07-4FA7-467B-8BA8-8D4D04A0BA9A@queuefull.net> <117f01cbd207$34f42290$9edc67b0$@com> <41EE506B-D6BA-4AB5-A211-41BFE114F70E@delong.com> <132601cbd235$69298720$3b7c9560$@com> <41DC9C32-7902-459E-A4FA-8A70EED53AB4@queuefull.net> Message-ID: <14652950-382A-4256-A9A5-646AB7E8C84D@delong.com> On Feb 22, 2011, at 1:36 PM, Benson Schliesser wrote: > > On Feb 22, 2011, at 3:14 AM, Randy Bush wrote: > >>> There seems to be a position, taken by others on these lists, that >>> IPv6 is the only address family that matters. Interestingly, this >>> position seems to be most pronounced from people not involved in >>> operating production networks. >> >> excuse me! > > Hi, Randy. I didn't mean to deny you exist; you apparently do. ;) But in my sampling, operators with the opinion that 'IPv4 doesn't matter' represent the minority. Of course, it also depends on how you define "doesn't matter". I think that ongoing operation matters, especially when "ongoing" means a continued expectation of both existing and new customers. It's easy to say, "burn the IPv4 bridge" so we're forced to migrate to IPv6. But it's another thing to actually do it, when you're competing for customers that want IPv4 connectivity. > We may be the minority, but, we have a lot more address space and no shortage of IP addresses. How many IPv4 providers can say that? > That said, we're not forced to choose only one: IPv4 vs. IPv6. We should migrate to IPv6 because it makes sense - IPv4 is going to become more expensive and painful (to use and support). That doesn't preclude us from patching IPv4 together long enough to cross the bridge first. > > Thoughts? > Patching the deck chairs does not change the fact that the boat is sinking. I suggest focusing on getting in a life boat. Deck chairs don't float very well. IPv6 is a life boat. NAT444 and other IPv4 preservation hacks are deck chairs. You can rearrange them all you want. Owen From ryan at deadfrog.net Tue Feb 22 17:44:27 2011 From: ryan at deadfrog.net (Ryan Wilkins) Date: Tue, 22 Feb 2011 17:44:27 -0600 Subject: [OT] Internet connectivity options in Afghanistan? In-Reply-To: <4D641BE3.5030608@bgp4.net> References: <4D641BE3.5030608@bgp4.net> Message-ID: <4E881895-1015-4BCB-8542-BA3B0A1BA499@deadfrog.net> On Feb 22, 2011, at 2:26 PM, Janet Sullivan wrote: > I'm looking for cheap/slow internet connectivity options in Kabul, Jalalabad, and Herat. The connections will be used by AFCECO orphanages, so speed isn't as much of an issue as cost. I'm guessing that satellite might be the only game in town, but if any of you fine folks know of connectivity options, I'd appreciate an email. There is fiber infrastructure around there but I'm not sure how reliable, available, or costly it is to use. The communications challenges that I have worked on into and out of Afghanistan have all been solved by satellite. I can tell you that if you want to push IP over satellite from the US, your options are very limited and more likely to be expensive. You may want to look into shared satellite providers in that part of the world. Europe has a number of them, as does Japan and China. You may even find a service point out of Dubai. Cheers, Ryan Wilkins From rdobbins at arbor.net Tue Feb 22 17:47:08 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 22 Feb 2011 23:47:08 +0000 Subject: Howto for BGP black holing/null routing In-Reply-To: References: Message-ID: <4987A6BA-50C5-4DBD-8003-C726EFADC6EA@arbor.net> On Feb 23, 2011, at 5:42 AM, David Hubbard wrote: > I've seen it discussed on nanog from time to time, typically suggesting using Zebra, but could not search up a link on a step by step. ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From owen at delong.com Tue Feb 22 17:53:52 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Feb 2011 15:53:52 -0800 Subject: Howto for BGP black holing/null routing In-Reply-To: References: Message-ID: <1EAA9AD3-676B-4604-9849-429B3BE4BBD0@delong.com> I can't give you a step-by-step with configuration examples off the top of my head, but, hopefully this helps: 1. Create a static anchor route to a magic "next-hop" value such as 192.168.99.99 or whatever you choose. 2. Configure all your routers to route 192.168.99.99 to null. 3. Advertise that into your iBGP mesh from the blackhole anchor router. Owen On Feb 22, 2011, at 1:42 PM, David Hubbard wrote: > I was wondering if anyone has a howto floating around on the > step by step setup of having an internal bgp peer for sending > quick updates to border routers to null route sources of > undesirable traffic? I've seen it discussed on nanog from > time to time, typically suggesting using Zebra, but could > not search up a link on a step by step. > > Thanks, > > David From ryan.g at atwgpc.net Tue Feb 22 17:59:18 2011 From: ryan.g at atwgpc.net (Ryan Gelobter) Date: Tue, 22 Feb 2011 17:59:18 -0600 Subject: Internet Issues in Europe Tonight? Message-ID: Does anyone have some detailed information about the internet issues going on in Sweden and other parts of Europe right now? I've read some reports about a large Telia outage in Sweden indicating a fault somewhere in Frankfurt or London as the cause. http://www.aftonbladet.se/nyheter/article8609308.ab http://www.dn.se/nyheter/sverige/stort-internetfel-i-europa From tim at haitabu.net Tue Feb 22 18:12:58 2011 From: tim at haitabu.net (Tim Kleefass) Date: Wed, 23 Feb 2011 01:12:58 +0100 Subject: Internet Issues in Europe Tonight? In-Reply-To: References: Message-ID: <4D64510A.30909@haitabu.net> On 02/23/2011 12:59 AM, Ryan Gelobter wrote: > Does anyone have some detailed information about the internet issues > going on in Sweden and other parts of Europe right now? I've read > some reports about a large Telia outage in Sweden indicating a fault > somewhere in Frankfurt or London as the cause. Telia has a "major outage in Frankfurt", but they are claiming, that they have build a temporary solution. I didn't get any more specific from the customer care... My traffic dropped from 1.2gbit/s to 0.2 gbit/s, then I shutdown the link to telia. -tim From arnold at nipper.de Tue Feb 22 18:15:15 2011 From: arnold at nipper.de (Arnold Nipper) Date: Wed, 23 Feb 2011 01:15:15 +0100 Subject: Internet Issues in Europe Tonight? In-Reply-To: References: Message-ID: <4D645193.50300@nipper.de> on 23.02.2011 00:59 Ryan Gelobter wrote: > Does anyone have some detailed information about the internet issues > going on in Sweden and other parts of Europe right now? I've read > some reports about a large Telia outage in Sweden indicating a fault > somewhere in Frankfurt or London as the cause. > A partner network just reported about Telia having problems with a router in Frankfurt. Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold at nipper.de phone: +49 6224 9259 299 mobile: +49 152 53717690 fax: +49 6224 9259 333 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From rmaunier at neotelecoms.com Tue Feb 22 18:19:28 2011 From: rmaunier at neotelecoms.com (Raphael Maunier) Date: Wed, 23 Feb 2011 01:19:28 +0100 Subject: Internet Issues in Europe Tonight? In-Reply-To: <4D645193.50300@nipper.de> References: <4D645193.50300@nipper.de> Message-ID: Confirmed here. It's solved with a temporary solution. The ticket is still open with in Telia. -- Rapha?l Maunier NEO TELECOMS CTO / Responsable Ing?nierie AS8218 On Feb 23, 2011, at 1:15 AM, Arnold Nipper wrote: > on 23.02.2011 00:59 Ryan Gelobter wrote: > >> Does anyone have some detailed information about the internet issues >> going on in Sweden and other parts of Europe right now? I've read >> some reports about a large Telia outage in Sweden indicating a fault >> somewhere in Frankfurt or London as the cause. >> > > A partner network just reported about Telia having problems with a > router in Frankfurt. > > > > Arnold > -- > Arnold Nipper / nIPper consulting, Sandhausen, Germany > email: arnold at nipper.de phone: +49 6224 9259 299 > mobile: +49 152 53717690 fax: +49 6224 9259 333 > From randy at psg.com Tue Feb 22 18:29:25 2011 From: randy at psg.com (Randy Bush) Date: Wed, 23 Feb 2011 08:29:25 +0800 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> <4C060A07-4FA7-467B-8BA8-8D4D04A0BA9A@queuefull.net> <117f01cbd207$34f42290$9edc67b0$@com> <41EE506B-D6BA-4AB5-A211-41BFE114F70E@delong.com> <132601cbd235$69298720$3b7c9560$@com> <41DC9C32-7902-459E-A4FA-8A70EED53AB4@queuefull.net> Message-ID: >>> There seems to be a position, taken by others on these lists, that >>> IPv6 is the only address family that matters. Interestingly, this >>> position seems to be most pronounced from people not involved in >>> operating production networks. >> >> excuse me! > > Hi, Randy. I didn't mean to deny you exist; you apparently do. ;) But > in my sampling, operators benson, vendors saying what operators want went *seriously* out of fashion a couple of years back. we can speak for ourselves, tyvm. randy From jlewis at lewis.org Tue Feb 22 18:38:37 2011 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 22 Feb 2011 19:38:37 -0500 (EST) Subject: Howto for BGP black holing/null routing In-Reply-To: References: Message-ID: On Tue, 22 Feb 2011, David Hubbard wrote: > I was wondering if anyone has a howto floating around on the > step by step setup of having an internal bgp peer for sending > quick updates to border routers to null route sources of > undesirable traffic? I've seen it discussed on nanog from > time to time, typically suggesting using Zebra, but could > not search up a link on a step by step. I actually did a blog entry just a couple weeks ago about this with relatively step by step [cisco] instructions. http://jonsblog.lewis.org/2011/02/05#blackhole I'm curious what others think of the setup. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From bensons at queuefull.net Tue Feb 22 18:51:45 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Tue, 22 Feb 2011 18:51:45 -0600 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> <4C060A07-4FA7-467B-8BA8-8D4D04A0BA9A@queuefull.net> <117f01cbd207$34f42290$9edc67b0$@com> <41EE506B-D6BA-4AB5-A211-41BFE114F70E@delong.com> <132601cbd235$69298720$3b7c9560$@com> <41DC9C32-7902-459E-A4FA-8A70EED53AB4@queuefull.net> Message-ID: <0A85C1AD-7238-49C2-8187-0633BCE7E007@queuefull.net> On Feb 22, 2011, at 6:29 PM, Randy Bush wrote: >>>> There seems to be a position, taken by others on these lists, that >>>> IPv6 is the only address family that matters. Interestingly, this >>>> position seems to be most pronounced from people not involved in >>>> operating production networks. >>> >>> excuse me! >> >> Hi, Randy. I didn't mean to deny you exist; you apparently do. ;) But >> in my sampling, operators > > benson, > > vendors saying what operators want went *seriously* out of fashion a > couple of years back. we can speak for ourselves, tyvm. I agree completely. I'm responding to what I've heard from operators. Cheers, -Benson From rcarpen at network1.net Tue Feb 22 22:39:05 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Tue, 22 Feb 2011 23:39:05 -0500 (EST) Subject: atdn.net issues In-Reply-To: Message-ID: <168b3cff-5eea-4819-aac5-5944de90be35@zimbra.network1.net> Anyone know who to contact for issues with atdn.net? Their website is not exactly a well of information. All connections from my network to anything at atdn (AOL, etc.) are dying at atdn's edge. Traceroutes go out through xo.net. I have verified that both of my upstream providers can get there fine (via the same path), so it appears to be a problem specifically with our net blocks (74.115.180.0/22 and 74.219.82.0/24) or ASN (15088) If anyone has any visibility from the other side of atdn.net, and can give me any info, I would appreciate it. thanks, -Randy From ben at 708x.com Tue Feb 22 22:44:23 2011 From: ben at 708x.com (Ben Carleton) Date: Tue, 22 Feb 2011 23:44:23 -0500 Subject: atdn.net issues In-Reply-To: <168b3cff-5eea-4819-aac5-5944de90be35@zimbra.network1.net> References: <168b3cff-5eea-4819-aac5-5944de90be35@zimbra.network1.net> Message-ID: <4D6490A7.3030009@708x.com> On 2/22/2011 11:39 PM, Randy Carpenter wrote: > Anyone know who to contact for issues with atdn.net? Their website is not exactly a well of information. > > All connections from my network to anything at atdn (AOL, etc.) are dying at atdn's edge. > > Traceroutes go out through xo.net. I have verified that both of my upstream providers can get there fine (via the same path), so it appears to be a problem specifically with our net blocks (74.115.180.0/22 and 74.219.82.0/24) or ASN (15088) > > If anyone has any visibility from the other side of atdn.net, and can give me any info, I would appreciate it. > > thanks, > -Randy > Did you try this: Technical Vikas Mehta +703-265-2011 vikas.mehta at corp.aol.com NOC NOC +703-265-4662 opt 4 noc at atdn.net NOC Maintenance Notification +703-265-4662 opt 4 maint at atdn.net On the side, a traceroute to AOL from my location in New York sent me from Chicago to Vienna, Austria, and then back to AOL... :) -- Ben From joe at nethead.com Wed Feb 23 00:38:57 2011 From: joe at nethead.com (Joe Hamelin) Date: Tue, 22 Feb 2011 22:38:57 -0800 Subject: Christchurch New Zealand In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13C6B@RWC-EX1.corp.seven.com> References: <1FF5B3DC-364E-48A5-A2C2-F27E5E93C27F@multicasttech.com> <4D632B8F.6090007@gmail.com> <5A6D953473350C4B9995546AFE9939EE0BC13C6B@RWC-EX1.corp.seven.com> Message-ID: The other CERT: Community Emergency Response Team. Kind of off-topic for NANOG but I know that most of us are concerned with disaster recovery. This is the first local line. For US folks, there should be a CERT for you city or county, if not ask why. For Canadians, check with PEP. The CERT program trains you what to do when the offal hits the fan and the first responders are overloaded. https://www.citizencorps.gov/cert/about.shtm "The Community Emergency Response Team (CERT) Program educates people about disaster preparedness for hazards that may impact their area and trains them in basic disaster response skills, such as fire safety, light search and rescue, team organization, and disaster medical operations. Using the training learned in the classroom and during exercises, CERT members can assist others in their neighborhood or workplace following an event when professional responders are not immediately available to help." -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From jsw at inconcepts.biz Wed Feb 23 09:36:51 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Wed, 23 Feb 2011 10:36:51 -0500 Subject: Howto for BGP black holing/null routing In-Reply-To: References: Message-ID: On Tue, Feb 22, 2011 at 4:55 PM, Jack Carrozzo wrote: > Maybe I read your question wrong, but null-routing things at your border is > often not very useful if the traffic is flooding your transit links. Most > transits publish their community lists - you just need to tag the prefix you > want to blackhole with the right community. This is certainly true. Although most "big transit networks" offer this feature today, there are some important differences in what some of them will and won't accept. Some will only learn /32s, some say they'll accept /30-/32 but nothing shorter, some will honor anything you send them. This may be undocumented. Some networks seem to have forgotten about this feature when implementing IPv6, even though it is offered for IPv4. I don't see any value in not accepting a RTBH /24 but accepting a /30. I also don't know of any platform issues which would make deploying RTBH for IPv6 BGP customers any more difficult than doing so for IPv4. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From rsm at fast-serv.com Wed Feb 23 10:54:44 2011 From: rsm at fast-serv.com (Randy McAnally) Date: Wed, 23 Feb 2011 11:54:44 -0500 Subject: Howto for BGP black holing/null routing In-Reply-To: References: Message-ID: <20110223163806.M72561@fast-serv.com> On Tue, 22 Feb 2011 16:42:28 -0500, David Hubbard wrote > I was wondering if anyone has a howto floating around on the > step by step setup of having an internal bgp peer for sending > quick updates to border routers to null route sources of > undesirable traffic? I've seen it discussed on nanog from > time to time, typically suggesting using Zebra, but could > not search up a link on a step by step. Ultimately it depends on the transit provider. For example, some have you set up a separate BGP session with a black hole router. Any prefix sent will be blackholed network wide. Some, such as the case of Level3, they are looking for specific community tags on your primary BGP session. So in a nutshell...lets blackhole a host: ip route x.x.x.x 255.255.255.255 null0 tag 255 Then set up a static-to-bgp with route-map to add community strings (for example 3356:9999 for level3) to your routes with tag 255. route-map STATIC-TO-BGP permit 10 match tag 255 set community 3356:9999 set origin igp And in your BGP config: redistribute static route-map STATIC-TO-BGP Now, for the case of level3, you're already set (just be sure to apply send-community on the neighbor). Now for a provider having a unique blackhole BGP session, you want a special route-map to filter prefixes going out that session: ip community-list BLACKHOLE seq 10 permit 3356:9999 route-map BLACKHOLE permit 10 match community BLACKHOLE Now for the blackhole session: neighbor route-map out BLACKHOLE It can get more complicated than this (for example, you've got more than one EBGP router) but this is just a simple case. I hope it helps... ~Randy From packetjockey at gmail.com Wed Feb 23 11:25:51 2011 From: packetjockey at gmail.com (Rafael Rodriguez) Date: Wed, 23 Feb 2011 12:25:51 -0500 Subject: Howto for BGP black holing/null routing In-Reply-To: References: Message-ID: Team Cymru has some really good examples on how to configure something similar (utilizing their BOGON feed). http://www.team-cymru.org/Services/Bogons/bgp.html Scroll down to "AUTOMATICALLY FILTERING BOGONS" for IOS, JUNOS, etc examples On Tue, Feb 22, 2011 at 4:42 PM, David Hubbard < dhubbard at dino.hostasaurus.com> wrote: > I was wondering if anyone has a howto floating around on the > step by step setup of having an internal bgp peer for sending > quick updates to border routers to null route sources of > undesirable traffic? I've seen it discussed on nanog from > time to time, typically suggesting using Zebra, but could > not search up a link on a step by step. > > Thanks, > > David > > From jcdill.lists at gmail.com Wed Feb 23 12:08:39 2011 From: jcdill.lists at gmail.com (JC Dill) Date: Wed, 23 Feb 2011 10:08:39 -0800 Subject: Christchurch New Zealand In-Reply-To: References: <1FF5B3DC-364E-48A5-A2C2-F27E5E93C27F@multicasttech.com> <4D632B8F.6090007@gmail.com> <5A6D953473350C4B9995546AFE9939EE0BC13C6B@RWC-EX1.corp.seven.com> Message-ID: <4D654D27.9080109@gmail.com> On 22/02/11 10:38 PM, Joe Hamelin wrote: > The other CERT: Community Emergency Response Team. > https://www.citizencorps.gov/cert/about.shtm +1 for CERT. I also think that taking a CERT class is a great way to re-evaluate your own network emergency procedures. You may find new ways to prepare for network disasters, and to triage damage when a network disaster occurs. jc From jeroen at mompl.net Wed Feb 23 19:38:07 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 23 Feb 2011 17:38:07 -0800 Subject: Contact for APEWS.org? In-Reply-To: References: <4B4120B1642DCF48ACA84E4F82C8E1F65A9961CE50@EXCH> Message-ID: <4D65B67F.9070805@mompl.net> Steve Linford wrote: > APEWS is one of the many fringe hobby DNSBLs run from kids bedrooms. I don't deny APEWS is pretty much useless, though I disagree with the (perceived) condescending sentiment about hobby projects. Many successful enterprises sprung from hobby projects. Greetings, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From ops.lists at gmail.com Wed Feb 23 19:48:01 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 24 Feb 2011 07:18:01 +0530 Subject: Contact for APEWS.org? In-Reply-To: <4D65B67F.9070805@mompl.net> References: <4B4120B1642DCF48ACA84E4F82C8E1F65A9961CE50@EXCH> <4D65B67F.9070805@mompl.net> Message-ID: On Thu, Feb 24, 2011 at 7:08 AM, Jeroen van Aart wrote: > Steve Linford wrote: >> >> APEWS is one of the many fringe hobby DNSBLs run from kids bedrooms. > > I don't deny APEWS is pretty much useless, though I disagree with the > (perceived) condescending sentiment about hobby projects. Many successful > enterprises sprung from hobby projects. So did spamhaus for quite a while. But this is specifically in the context of dnsbls. Where steve's mostly right. -- Suresh Ramasubramanian (ops.lists at gmail.com) From jra at baylink.com Wed Feb 23 21:23:54 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 23 Feb 2011 22:23:54 -0500 (EST) Subject: Spam from *where*? Mars? Message-ID: <32281925.24.1298517834871.JavaMail.root@benjamin.baylink.com> I saw in my mail logs tonight, a bounced spam from 'unknown[1.52.36.176]' 1/8? When did that happen? (Yes, yes, I know; last year. Just never seen one before...) Cheers, -- jra From swmike at swm.pp.se Wed Feb 23 21:49:49 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 24 Feb 2011 04:49:49 +0100 (CET) Subject: Spam from *where*? Mars? In-Reply-To: <32281925.24.1298517834871.JavaMail.root@benjamin.baylink.com> References: <32281925.24.1298517834871.JavaMail.root@benjamin.baylink.com> Message-ID: On Wed, 23 Feb 2011, Jay Ashworth wrote: > 1/8? When did that happen? For this block, end of january judging from the changed:-line below. inetnum: 1.52.0.0 - 1.52.127.255 netname: FPT-NET country: VN descr: IP range for FPT Broadband Service descr: 48 Van Bao str,Ba Dinh Dist, Ha Noi admin-c: LPC5-AP tech-c: LPC5-AP status: ASSIGNED NON-PORTABLE remarks: For spamming matters, mail to abuse at fpt.vn mnt-irt: IRT-VNNIC-AP mnt-by: MAINT-VN-FPT source: APNIC changed: hm-changed at vnnic.net.vn 20110124 -- Mikael Abrahamsson email: swmike at swm.pp.se From ops.lists at gmail.com Wed Feb 23 21:53:14 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 24 Feb 2011 09:23:14 +0530 Subject: Spam from *where*? Mars? In-Reply-To: References: <32281925.24.1298517834871.JavaMail.root@benjamin.baylink.com> Message-ID: On Thu, Feb 24, 2011 at 9:19 AM, Mikael Abrahamsson wrote: > remarks: ? ? ? ?For spamming matters, mail to abuse at fpt.vn aka /dev/null as far as I can see. Huge volumes of abuse from this range and from VNPT. If any ops from there are around please email me offlist --srs (postmaster for AS27477) -- Suresh Ramasubramanian (ops.lists at gmail.com) From joelja at bogus.com Wed Feb 23 23:28:15 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 23 Feb 2011 21:28:15 -0800 Subject: Howto for BGP black holing/null routing In-Reply-To: References: Message-ID: <4D65EC6F.3050807@bogus.com> On 2/22/11 1:42 PM, David Hubbard wrote: > I was wondering if anyone has a howto floating around on the > step by step setup of having an internal bgp peer for sending > quick updates to border routers to null route sources of > undesirable traffic? I've seen it discussed on nanog from > time to time, typically suggesting using Zebra, but could > not search up a link on a step by step. > > Thanks, I'd include: https://tools.ietf.org/html/rfc5635 in your list of reading materials. > David > > From rekoil at semihuman.com Wed Feb 23 23:55:23 2011 From: rekoil at semihuman.com (Chris Woodfield) Date: Wed, 23 Feb 2011 21:55:23 -0800 Subject: Submarine cable sample? Message-ID: <382C1FD4-ABF5-41F6-A2AE-0B844CA47435@semihuman.com> Hi, Was wondering where one in the SF Bay area might be able to borrow (or otherwise procure at a reasonable cost) a short - less than 1 meter - section of undersea fiber cable for a presentation I'll be giving in a few weeks. Feel free to unicast your reply if you are in a position to assist. Thanks, -Chris From rekoil at semihuman.com Thu Feb 24 00:10:41 2011 From: rekoil at semihuman.com (Chris Woodfield) Date: Wed, 23 Feb 2011 22:10:41 -0800 Subject: ARIN and IPv6 Requests In-Reply-To: References: <6aacabfd$67a3507c$6792f96a$@com> Message-ID: <00B27B87-025C-4D43-8B05-4AAD748855FA@semihuman.com> (Yeah, high reply latency...) Is Carrier V still filtering at sub-/32 on their IPv6 peerings? Last I was in a position to check, not even Apple's /45 was visible from inside AS701. -C On Feb 10, 2011, at 12:25 PM, Eric Clark wrote: > Don't remember about the v4 part, but 3 years ago they issued me a /48, specifically for my first site and indicated that a block was reserved for additional sites. I can probably dig that up. > > Sent from my iPad > > On Feb 10, 2011, at 12:18 PM, Jason Iannone wrote: > >> It also looks like there isn't a policy for orgs with multiple >> multihomed sites to get a /48 per site. Is there an exception policy >> somewhere? >> >> On Thu, Feb 10, 2011 at 12:50 PM, wrote: >>> Initial. Documenting IPv4 usage is in the request template. >>> >>> -- >>> Adam Webb >>> >>> >>> >>> >>> >>> From: >>> "Nick Olsen" >>> To: >>> >>> Date: >>> 02/10/2011 01:45 PM >>> Subject: >>> re: ARIN and IPv6 Requests >>> >>> >>> >>> We requested our initial allocation without any such questions. Is this >>> your initial or additional? >>> >>> Nick Olsen >>> Network Operations >>> (855) FLSPEED x106 >>> >>> ---------------------------------------- >>> >>> From: ADWebb at dstsystems.com >>> Sent: Thursday, February 10, 2011 2:38 PM >>> To: nanog at nanog.org >>> Subject: ARIN and IPv6 Requests >>> >>> Why does ARIN require detailed usage of IPv4 space when requesting IPv6 >>> space? Seems completely irrelevant to me. >>> >>> -- >>> Adam Webb >>> EN & ES Team >>> desk: 816.737.9717 >>> cell: 916.949.1345 >>> --------------------------------------- >>> The biggest secret of innovation is that anyone can do it. >>> --------------------------------------- >>> >>> ----------------------------------------- >>> Please consider the environment before printing this email and any >>> attachments. >>> >>> This e-mail and any attachments are intended only for the >>> individual or company to which it is addressed and may contain >>> information which is privileged, confidential and prohibited from >>> disclosure or unauthorized use under applicable law. If you are >>> not the intended recipient of this e-mail, you are hereby notified >>> that any use, dissemination, or copying of this e-mail or the >>> information contained in this e-mail is strictly prohibited by the >>> sender. If you have received this transmission in error, please >>> return the material received to the sender and delete all copies >>> from your system. >>> >>> >>> >> > From joelja at bogus.com Thu Feb 24 00:20:06 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 23 Feb 2011 22:20:06 -0800 Subject: ARIN and IPv6 Requests In-Reply-To: <00B27B87-025C-4D43-8B05-4AAD748855FA@semihuman.com> References: <6aacabfd$67a3507c$6792f96a$@com> <00B27B87-025C-4D43-8B05-4AAD748855FA@semihuman.com> Message-ID: <4D65F896.4070706@bogus.com> On 2/23/11 10:10 PM, Chris Woodfield wrote: > (Yeah, high reply latency...) > > Is Carrier V still filtering at sub-/32 on their IPv6 peerings? Last I was in a position to check, not even Apple's /45 was visible from inside AS701. evidence says that they are now accepting longer prefixes. > -C > > On Feb 10, 2011, at 12:25 PM, Eric Clark wrote: > >> Don't remember about the v4 part, but 3 years ago they issued me a /48, specifically for my first site and indicated that a block was reserved for additional sites. I can probably dig that up. >> >> Sent from my iPad >> >> On Feb 10, 2011, at 12:18 PM, Jason Iannone wrote: >> >>> It also looks like there isn't a policy for orgs with multiple >>> multihomed sites to get a /48 per site. Is there an exception policy >>> somewhere? >>> >>> On Thu, Feb 10, 2011 at 12:50 PM, wrote: >>>> Initial. Documenting IPv4 usage is in the request template. >>>> >>>> -- >>>> Adam Webb >>>> >>>> >>>> >>>> >>>> >>>> From: >>>> "Nick Olsen" >>>> To: >>>> >>>> Date: >>>> 02/10/2011 01:45 PM >>>> Subject: >>>> re: ARIN and IPv6 Requests >>>> >>>> >>>> >>>> We requested our initial allocation without any such questions. Is this >>>> your initial or additional? >>>> >>>> Nick Olsen >>>> Network Operations >>>> (855) FLSPEED x106 >>>> >>>> ---------------------------------------- >>>> >>>> From: ADWebb at dstsystems.com >>>> Sent: Thursday, February 10, 2011 2:38 PM >>>> To: nanog at nanog.org >>>> Subject: ARIN and IPv6 Requests >>>> >>>> Why does ARIN require detailed usage of IPv4 space when requesting IPv6 >>>> space? Seems completely irrelevant to me. >>>> >>>> -- >>>> Adam Webb >>>> EN & ES Team >>>> desk: 816.737.9717 >>>> cell: 916.949.1345 >>>> --------------------------------------- >>>> The biggest secret of innovation is that anyone can do it. >>>> --------------------------------------- >>>> >>>> ----------------------------------------- >>>> Please consider the environment before printing this email and any >>>> attachments. >>>> >>>> This e-mail and any attachments are intended only for the >>>> individual or company to which it is addressed and may contain >>>> information which is privileged, confidential and prohibited from >>>> disclosure or unauthorized use under applicable law. If you are >>>> not the intended recipient of this e-mail, you are hereby notified >>>> that any use, dissemination, or copying of this e-mail or the >>>> information contained in this e-mail is strictly prohibited by the >>>> sender. If you have received this transmission in error, please >>>> return the material received to the sender and delete all copies >>>> from your system. >>>> >>>> >>>> >>> >> > > > From jahiel at gmail.com Thu Feb 24 01:05:42 2011 From: jahiel at gmail.com (Graham Freeman) Date: Wed, 23 Feb 2011 23:05:42 -0800 Subject: My upstream ISP does support IPv6 In-Reply-To: References: <1127264403.2346.1296791643752.JavaMail.root@zimbra.network1.net> <185E6979-5F80-4F7A-8DE6-562132264990@delong.com> Message-ID: On 11 Feb 11, at 19:24 , Matthew Petach wrote: > On Fri, Feb 4, 2011 at 4:33 PM, Owen DeLong wrote: >> I'll start.. >> >> Hurricane Electric Happily and readily provided me IPv6 Transit on request. >> Layer42 Happily and readily provided me IPv6 Transit on request. >> >> Owen > > I'll second that--I've had native v6 connectivity with Layer42 at home, with a > secondary path via HE tunnelbroker via a secondary physical path for many, > many moons, and have had no complaints. > For those with smaller-sized connectivity needs, it's likely you'll have better > success getting v6 connectivity from a tier-2 provider, as there's less non-v6- > compliant hardware and software that needs to be taken into consideration. > There's also likely to be some level of impedance mismatch between the > upgrade priority for high-bandwidth-customer gear and low-bandwidth-customer > gear at large-sized ISPs, which may relegate you to a slower deployment > scheduled than if you bring the question up with your local tier 2 provider. > > Matt Thirded. Layer42.net : Dual-stack IPv6 and IPv4 at our cabinets in their new Mountain View (CA, USA) facility. Works well; basically no hassle getting it going. Having reverse DNS delegated was a breeze. HE.net via Tunnelbroker.net : Bridging the connectivity gaps where my home/office ISPs do not yet offer IPv6. Very useful service. UnitedLayer.com : apparently ready to provide IPv6 at our cabinets in their suite at 200 Paul (San Francisco, CA, USA) as soon as we install a suitable router. Can't yet speak from experience as to how well it works, but their network folks certainly know their IPv6. jump.net.uk : dual-stack IPv6 and IPv4 at a VPS hosted by a customer of theirs in in Telehouse North (London, England). Works well; no hassle. Graham (https://cernio.com/) From owen at delong.com Thu Feb 24 01:30:29 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 23 Feb 2011 23:30:29 -0800 Subject: ARIN and IPv6 Requests In-Reply-To: <4D65F896.4070706@bogus.com> References: <6aacabfd$67a3507c$6792f96a$@com> <00B27B87-025C-4D43-8B05-4AAD748855FA@semihuman.com> <4D65F896.4070706@bogus.com> Message-ID: I discussed this with Randy Whitney a few months ago. He informed me that they had been taking down to /48s for some time now. Owen On Feb 23, 2011, at 10:20 PM, Joel Jaeggli wrote: > On 2/23/11 10:10 PM, Chris Woodfield wrote: >> (Yeah, high reply latency...) >> >> Is Carrier V still filtering at sub-/32 on their IPv6 peerings? Last I was in a position to check, not even Apple's /45 was visible from inside AS701. > > evidence says that they are now accepting longer prefixes. > >> -C >> >> On Feb 10, 2011, at 12:25 PM, Eric Clark wrote: >> >>> Don't remember about the v4 part, but 3 years ago they issued me a /48, specifically for my first site and indicated that a block was reserved for additional sites. I can probably dig that up. >>> >>> Sent from my iPad >>> >>> On Feb 10, 2011, at 12:18 PM, Jason Iannone wrote: >>> >>>> It also looks like there isn't a policy for orgs with multiple >>>> multihomed sites to get a /48 per site. Is there an exception policy >>>> somewhere? >>>> >>>> On Thu, Feb 10, 2011 at 12:50 PM, wrote: >>>>> Initial. Documenting IPv4 usage is in the request template. >>>>> >>>>> -- >>>>> Adam Webb >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> From: >>>>> "Nick Olsen" >>>>> To: >>>>> >>>>> Date: >>>>> 02/10/2011 01:45 PM >>>>> Subject: >>>>> re: ARIN and IPv6 Requests >>>>> >>>>> >>>>> >>>>> We requested our initial allocation without any such questions. Is this >>>>> your initial or additional? >>>>> >>>>> Nick Olsen >>>>> Network Operations >>>>> (855) FLSPEED x106 >>>>> >>>>> ---------------------------------------- >>>>> >>>>> From: ADWebb at dstsystems.com >>>>> Sent: Thursday, February 10, 2011 2:38 PM >>>>> To: nanog at nanog.org >>>>> Subject: ARIN and IPv6 Requests >>>>> >>>>> Why does ARIN require detailed usage of IPv4 space when requesting IPv6 >>>>> space? Seems completely irrelevant to me. >>>>> >>>>> -- >>>>> Adam Webb >>>>> EN & ES Team >>>>> desk: 816.737.9717 >>>>> cell: 916.949.1345 >>>>> --------------------------------------- >>>>> The biggest secret of innovation is that anyone can do it. >>>>> --------------------------------------- >>>>> >>>>> ----------------------------------------- >>>>> Please consider the environment before printing this email and any >>>>> attachments. >>>>> >>>>> This e-mail and any attachments are intended only for the >>>>> individual or company to which it is addressed and may contain >>>>> information which is privileged, confidential and prohibited from >>>>> disclosure or unauthorized use under applicable law. If you are >>>>> not the intended recipient of this e-mail, you are hereby notified >>>>> that any use, dissemination, or copying of this e-mail or the >>>>> information contained in this e-mail is strictly prohibited by the >>>>> sender. If you have received this transmission in error, please >>>>> return the material received to the sender and delete all copies >>>>> from your system. >>>>> >>>>> >>>>> >>>> >>> >> >> >> > From list.stuff2 at gmail.com Thu Feb 24 07:52:11 2011 From: list.stuff2 at gmail.com (lists lists) Date: Thu, 24 Feb 2011 08:52:11 -0500 Subject: Verizon MPLS service in Anchorage Message-ID: Hello, I've got a bunch of sites connected to the Verizon Private IP MPLS service, and recently brought online a location in Anchorage connected to the brand-new PE node in the same city. I'm seeing that packets marked as DSCP EF are given fantastic treatment (low jitter, no packet loss), but other packets, including AF41, AF31, and BE are given what appears to be the "junk bucket" treatment. I'm having a difficult time getting anyone to acknowledge this problem, but it's causing interactive applications to be unusable for times of the day. Can anyone point me in a good direction? thanks. From mikea at mikea.ath.cx Thu Feb 24 08:39:09 2011 From: mikea at mikea.ath.cx (mikea) Date: Thu, 24 Feb 2011 08:39:09 -0600 Subject: Christchurch New Zealand In-Reply-To: <4D654D27.9080109@gmail.com> References: <1FF5B3DC-364E-48A5-A2C2-F27E5E93C27F@multicasttech.com> <4D632B8F.6090007@gmail.com> <5A6D953473350C4B9995546AFE9939EE0BC13C6B@RWC-EX1.corp.seven.com> <4D654D27.9080109@gmail.com> Message-ID: <20110224143909.GA48950@mikea.ath.cx> On Wed, Feb 23, 2011 at 10:08:39AM -0800, JC Dill wrote: > On 22/02/11 10:38 PM, Joe Hamelin wrote: > >The other CERT: Community Emergency Response Team. > > >https://www.citizencorps.gov/cert/about.shtm > > +1 for CERT. I also think that taking a CERT class is a great way to > re-evaluate your own network emergency procedures. You may find new > ways to prepare for network disasters, and to triage damage when a > network disaster occurs. Agreed on CERT. I diffidently suggest that amateur radio licensing, together with some battery-operated gear (think 2-meter or 70-cm handy-talkies at a minimum for short-haul comms, HF gear for longer-haul) may be Very Good Indeed in a disaster that takes down POTS service or government emergency communications. Folks interested in this might want to investigate ARES and/or RACES in the US, or similar activities in other countries. Examples: New Orleans: hams did EMCOMM for police, fire, and other services after grid power failed, until FEMA was able to move generators and other hardware in. NYC, 9/11/2001: EMCOMM repeaters were on one of the WTC buildings. When that collapsed, hams did EMCOMM for police, fire, and other services until FEMA and NY State got EMCOMM repeater hardware moved in. Hurricane Ike, Galveston TX and surrounding area: Grid power failed and many areas flooded, taking out government EMCOMM. Hams provided EMCOMM. I helped work this one, and *KNOW* there were lives saved by hams poviding EMCOMM services for government. Oklahoma City, after the Murrah Building bombing: wired POTS overloaded, cell services were restricted. Hams provided EMCOMM. This won't help you get your networks back in service, except indirectly, but you certainly can help others while you're waiting for things to improve. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From bross at pobox.com Thu Feb 24 09:01:00 2011 From: bross at pobox.com (Brandon Ross) Date: Thu, 24 Feb 2011 10:01:00 -0500 (EST) Subject: Verizon MPLS service in Anchorage In-Reply-To: References: Message-ID: On Thu, 24 Feb 2011, lists lists wrote: > I'm seeing that packets marked as DSCP EF are given fantastic treatment (low > jitter, no packet loss), but other packets, including AF41, AF31, and BE are > given what appears to be the "junk bucket" treatment. Hah, just a few days ago I spoke with an "engineer" at VZ that tried to claim that each of the treatments were different, but that they only charged extra for EF. I asked why I shouldn't just put all my traffic in the highest "free" treatment and beat out all the other customers for the best treatment for mine. He told me that "most of his customers weren't trying to get their traffic through at the expense of other customers". Anyway, despite what their "engineers" say, only EF is actually treated on the VZ network better than BE, the rest are just to prioritize traffic at your own egress port. -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss From franck at genius.com Thu Feb 24 09:03:58 2011 From: franck at genius.com (Franck Martin) Date: Thu, 24 Feb 2011 10:03:58 -0500 (EST) Subject: Christchurch New Zealand In-Reply-To: <20110224143909.GA48950@mikea.ath.cx> Message-ID: <16209229.651.1298559834102.JavaMail.franck@franck-martins-macbook-pro.local> You have products like a cell on wheels. A container containing a phone switch and a mobile cell, easily installable. You place it at the center of the disaster zone and all mobile phones start to work... if you are worried about congestion, then only the "right" sims are registered/enabled. ----- Original Message ----- From: "mikea" To: nanog at nanog.org Sent: Thursday, 24 February, 2011 9:39:09 AM Subject: Re: Christchurch New Zealand On Wed, Feb 23, 2011 at 10:08:39AM -0800, JC Dill wrote: > On 22/02/11 10:38 PM, Joe Hamelin wrote: > >The other CERT: Community Emergency Response Team. > > >https://www.citizencorps.gov/cert/about.shtm > > +1 for CERT. I also think that taking a CERT class is a great way to > re-evaluate your own network emergency procedures. You may find new > ways to prepare for network disasters, and to triage damage when a > network disaster occurs. Agreed on CERT. I diffidently suggest that amateur radio licensing, together with some battery-operated gear (think 2-meter or 70-cm handy-talkies at a minimum for short-haul comms, HF gear for longer-haul) may be Very Good Indeed in a disaster that takes down POTS service or government emergency communications. Folks interested in this might want to investigate ARES and/or RACES in the US, or similar activities in other countries. From morrowc.lists at gmail.com Thu Feb 24 09:08:37 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 24 Feb 2011 10:08:37 -0500 Subject: Verizon MPLS service in Anchorage In-Reply-To: References: Message-ID: On Thu, Feb 24, 2011 at 10:01 AM, Brandon Ross wrote: > On Thu, 24 Feb 2011, lists lists wrote: > >> I'm seeing that packets marked as DSCP EF are given fantastic treatment >> (low >> jitter, no packet loss), but other packets, including AF41, AF31, and BE >> are >> given what appears to be the "junk bucket" treatment. > > Hah, just a few days ago I spoke with an "engineer" at VZ that tried to > claim that each of the treatments were different, but that they only charged > extra for EF. ?I asked why I shouldn't just put all my traffic in the > highest "free" treatment and beat out all the other customers for the best > treatment for mine. ?He told me that "most of his customers weren't trying > to get their traffic through at the expense of other customers". > > Anyway, despite what their "engineers" say, only EF is actually treated on > the VZ network better than BE, the rest are just to prioritize traffic at > your own egress port. 'at your egress port' .. or 'where you are attempting to put 10lbs of crap in a 5lb bag'.. chances are the anchorage node is actually a partner node anyway, fyi. From list.stuff2 at gmail.com Thu Feb 24 09:10:18 2011 From: list.stuff2 at gmail.com (lists lists) Date: Thu, 24 Feb 2011 10:10:18 -0500 Subject: Verizon MPLS service in Anchorage In-Reply-To: References: Message-ID: On Thu, Feb 24, 2011 at 10:01 AM, Brandon Ross wrote: > On Thu, 24 Feb 2011, lists lists wrote: > > I'm seeing that packets marked as DSCP EF are given fantastic treatment >> (low >> jitter, no packet loss), but other packets, including AF41, AF31, and BE >> are >> given what appears to be the "junk bucket" treatment. >> > > Hah, just a few days ago I spoke with an "engineer" at VZ that tried to > claim that each of the treatments were different, but that they only charged > extra for EF. I asked why I shouldn't just put all my traffic in the > highest "free" treatment and beat out all the other customers for the best > treatment for mine. He told me that "most of his customers weren't trying > to get their traffic through at the expense of other customers". > > Anyway, despite what their "engineers" say, only EF is actually treated on > the VZ network better than BE, the rest are just to prioritize traffic at > your own egress port. > > -- > Brandon Ross AIM: > BrandonNRoss > ICQ: 2269442 > Skype: brandonross Yahoo: BrandonNRoss > Brandon, VZ does or can apply a PE-egress profile that handles traffic differently based on DSCP marking. Your account team should be able to provide this to you. As far as unique treatment within their P network, it sure looks to me that the higher AF classes do get better treatment. My problem is that non-EF is handled terribly, and it's causing a big problem with interactive traffic. Voice is fine. thanks. From nanogwp at gmail.com Thu Feb 24 10:00:45 2011 From: nanogwp at gmail.com (Robert Lusby) Date: Thu, 24 Feb 2011 16:00:45 +0000 Subject: Submarine cable sample? In-Reply-To: <382C1FD4-ABF5-41F6-A2AE-0B844CA47435@semihuman.com> References: <382C1FD4-ABF5-41F6-A2AE-0B844CA47435@semihuman.com> Message-ID: Pacnet have a nice cable running under the actual SF Bay you could borrow a bit of. Don't think people would mind. ;) On Thu, Feb 24, 2011 at 5:55 AM, Chris Woodfield wrote: > Hi, > > Was wondering where one in the SF Bay area might be able to borrow (or > otherwise procure at a reasonable cost) a short - less than 1 meter - > section of undersea fiber cable for a presentation I'll be giving in a few > weeks. Feel free to unicast your reply if you are in a position to assist. > > Thanks, > > -Chris > From achatz at forthnet.gr Thu Feb 24 10:13:13 2011 From: achatz at forthnet.gr (Tassos Chatzithomaoglou) Date: Thu, 24 Feb 2011 18:13:13 +0200 Subject: Infrastructure addresses definition Message-ID: <4D668399.70402@forthnet.gr> How do you define infrastructure addresses in your network? Ok, probably router loopbacks are some of them. Router LANs also. But what about addresses used on WAN (or LAN p2p) links that are used for interconnections with customers? What about addresses used for public servers (dns, mail, web, etc)? Do you consider these as infrastructure addresses? If yes, how do you define your iACLs with these included? Regards, Tassos From jra at baylink.com Thu Feb 24 10:26:43 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 24 Feb 2011 11:26:43 -0500 (EST) Subject: Christchurch New Zealand In-Reply-To: <16209229.651.1298559834102.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <556747.162.1298564803068.JavaMail.root@benjamin.baylink.com> > ----- Original Message ----- > From: "mikea" > I diffidently suggest that amateur radio licensing, together with some > battery-operated gear (think 2-meter or 70-cm handy-talkies at a minimum > for short-haul comms, HF gear for longer-haul) may be Very Good Indeed > in a disaster that takes down POTS service or government emergency > communications. Folks interested in this might want to investigate > ARES and/or RACES in the US, or similar activities in other countries. Diffident, hell. When did we get diffident? :-) We use "When All Else Fails" as a slogan for Amateur Radio Emergency Communications for a reason... The *real* problem is getting petty politics out of local ARES/RACES orgs. Cheers, -- jra From bill at herrin.us Thu Feb 24 10:39:24 2011 From: bill at herrin.us (William Herrin) Date: Thu, 24 Feb 2011 11:39:24 -0500 Subject: Infrastructure addresses definition In-Reply-To: <4D668399.70402@forthnet.gr> References: <4D668399.70402@forthnet.gr> Message-ID: On Thu, Feb 24, 2011 at 11:13 AM, Tassos Chatzithomaoglou wrote: > How do you define infrastructure addresses in your network? > Ok, probably router loopbacks are some of them. Router LANs also. > > But what about addresses used on WAN (or LAN p2p) links that are used for > interconnections with customers? > What about addresses used for public servers (dns, mail, web, etc)? > > Do you consider these as infrastructure addresses? > If yes, how do you define your iACLs with these included? Defining customer interconnect addresses as infrastructure subject to filtering is a bad idea. One of my ISPs does that: you can't reach the serial interface of my router from outside their network because of the filtering. There are customer applications where it's useful to originate a tunnel from the customer serial interface. I had to carve off a chunk of an extra assignment, introducing an extra route into their system. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From lists at mtin.net Thu Feb 24 10:57:54 2011 From: lists at mtin.net (Justin Wilson) Date: Thu, 24 Feb 2011 11:57:54 -0500 Subject: Infrastructure addresses definition In-Reply-To: <4D668399.70402@forthnet.gr> Message-ID: I consider anything not facing the customer to be infrastructure. In terms of CPE, routers, etc. If it's a point to point connection (t1,wireless,etc) the address on the router on my end facing the customer router is considered a customer address. Justin -- Justin Wilson Aol & Yahoo IM: j2sw http://www.mtin.net/blog ? xISP News http://www.twitter.com/j2sw ? Follow me on Twitter Wisp Consulting ? Tower Climbing ? Network Support On 2/24/11 11:13 AM, "Tassos Chatzithomaoglou" wrote: >How do you define infrastructure addresses in your network? >Ok, probably router loopbacks are some of them. Router LANs also. > >But what about addresses used on WAN (or LAN p2p) links that are used >for interconnections with customers? >What about addresses used for public servers (dns, mail, web, etc)? > >Do you consider these as infrastructure addresses? >If yes, how do you define your iACLs with these included? > >Regards, >Tassos > > From trelane at trelane.net Thu Feb 24 11:33:40 2011 From: trelane at trelane.net (Andrew Kirch) Date: Thu, 24 Feb 2011 12:33:40 -0500 Subject: Christchurch New Zealand In-Reply-To: <16209229.651.1298559834102.JavaMail.franck@franck-martins-macbook-pro.local> References: <16209229.651.1298559834102.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4D669674.4060102@trelane.net> The problem with this is that both ARES and RACES hams have gotten there first (orange lights and strobes flashing) and are now engaged in small-arms fire over who gets to set their repeater up. You're now hiding under your vehicle. What is your next move? Andrew On 2/24/2011 10:03 AM, Franck Martin wrote: > You have products like a cell on wheels. A container containing a phone switch and a mobile cell, easily installable. You place it at the center of the disaster zone and all mobile phones start to work... > > if you are worried about congestion, then only the "right" sims are registered/enabled. > > ----- Original Message ----- > From: "mikea" > To: nanog at nanog.org > Sent: Thursday, 24 February, 2011 9:39:09 AM > Subject: Re: Christchurch New Zealand > > On Wed, Feb 23, 2011 at 10:08:39AM -0800, JC Dill wrote: >> On 22/02/11 10:38 PM, Joe Hamelin wrote: >>> The other CERT: Community Emergency Response Team. >>> https://www.citizencorps.gov/cert/about.shtm >> +1 for CERT. I also think that taking a CERT class is a great way to >> re-evaluate your own network emergency procedures. You may find new >> ways to prepare for network disasters, and to triage damage when a >> network disaster occurs. > Agreed on CERT. > > I diffidently suggest that amateur radio licensing, together with some > battery-operated gear (think 2-meter or 70-cm handy-talkies at a minimum > for short-haul comms, HF gear for longer-haul) may be Very Good Indeed > in a disaster that takes down POTS service or government emergency > communications. Folks interested in this might want to investigate ARES > and/or RACES in the US, or similar activities in other countries. > > From nathan at atlasnetworks.us Thu Feb 24 11:53:05 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Thu, 24 Feb 2011 17:53:05 +0000 Subject: Christchurch New Zealand In-Reply-To: <4D669674.4060102@trelane.net> References: <16209229.651.1298559834102.JavaMail.franck@franck-martins-macbook-pro.local> <4D669674.4060102@trelane.net> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B39A383@ex-mb-1.corp.atlasnetworks.us> > The problem with this is that both ARES and RACES hams have gotten there > first (orange lights and strobes flashing) and are now engaged in small-arms > fire over who gets to set their repeater up. You're now hiding under your > vehicle. What is your next move? Larger-arms fire? From nanog at jima.tk Thu Feb 24 12:01:54 2011 From: nanog at jima.tk (Jima) Date: Thu, 24 Feb 2011 12:01:54 -0600 Subject: Christchurch New Zealand In-Reply-To: <4D669674.4060102@trelane.net> References: <16209229.651.1298559834102.JavaMail.franck@franck-martins-macbook-pro.local> <4D669674.4060102@trelane.net> Message-ID: <4D669D12.3060808@jima.tk> On 02/24/2011 11:33 AM, Andrew Kirch wrote: > The problem with this is that both ARES and RACES hams have gotten there > first (orange lights and strobes flashing) and are now engaged in > small-arms fire over who gets to set their repeater up. You're now > hiding under your vehicle. What is your next move? Wait for a winner to prevail. Whoever comes out on top is clearly more prepared to deal with emergencies. Jima From rrc.jneal at gmail.com Thu Feb 24 12:14:53 2011 From: rrc.jneal at gmail.com (Jeremy Neal) Date: Thu, 24 Feb 2011 18:14:53 +0000 Subject: Christchurch New Zealand Message-ID: <1275846580-1298571295-cardhu_decombobulator_blackberry.rim.net-703258928-@bda504.bisx.prod.on.blackberry> > Date: Thu, 24 Feb 2011 11:26:43 -0500 (EST) > From: Jay Ashworth > Subject: Re: Christchurch New Zealand > To: NANOG > > The *real* problem is getting petty politics out of > local ARES/RACES orgs. > > Cheers, > -- jra Here's my $0.02 on the subject of hams for em-comm, and my apologies in advance for continuing this OT discussion. The real problem is getting hams to stop wearing the cheesy gear with their callsigns all over it, the antenna hat toppers, LED scrolling name badges, and - for the love of everything holy - to put an end to the phrase "HI HI" once and for all. I've had slightly more experience in commercial and public safety comms than I have as a ham, as my elmers (ham radio mentors) worked on commercial radio systems by trade. Now, after working with the ARES/RACES groups in the area as part of my position with the state emergency management agency, I can tell you that I am, at times, ashamed to call myself a ham, because of the ridiculous (often even downright childish) behavior some display. The bottom line: If you can get hams to stop acting so self-righteous about their hobby, to practice passing traffic (messages read aloud and copied over the air) so they can do so efficiently (most hams don't have a clue how), get them certified in NIMS (the National Incident Management System, certification available for anyone online at ), and teach them to display some degree of professionalism - the "bigger picture" will begin to emerge, and the focus will return to providing a service to the community...which is where it needs to be to begin with. In retrospect, maybe that was more like $0.25... 73 ("best regards", in ham speak), Jeremy From jared at puck.nether.net Thu Feb 24 15:59:52 2011 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 24 Feb 2011 16:59:52 -0500 Subject: 6453 routing leaks (January and Today) Message-ID: It appears there have been a large number of routing leaks from 6453 today based on my detection scripts that have been running. (shameless plug for http://puck.nether.net/bgp/leakinfo.cgi) A quick report of the data show (for today so far) a few thousand of leaks more than is normal for a day like today. I included a snapshot of yesterday below as well. I've included a more detailed report of the prefixes observed involved here: http://puck.nether.net/~jared/tata-leak-20110224.txt This seems to be a somewhat common event for 6453, loking through the history of data available, another event happened on 2011-01-28 as well. I'm interested in what best operational practices people have employed to help avoid the leaks seen here so I can document them for others to learn to prevent this from happening again. - Jared bgp=# select count(blame_asn),blame_asn,asn_responsible from leakinfo where aprox_time::date = '2011-02-24' group by blame_asn,asn_responsible order by 1 desc; count | blame_asn | asn_responsible -------+-----------+----------------- 2208 | 6453 | 6453 360 | 7473 | 3257 230 | | 170 | 17379 | 5511 130 | 8068 | 3356 39 | 3225 | 6453 34 | 45419 | 3356 26 | 3356 | 3356 25 | 12180 | 2828 18 | 22351 | 701 16 | 7991 | 2914 16 | 14051 | 1239 10 | 29571 | 5511 4 | 32327 | 2828 4 | 8966 | 2914 4 | 19080 | 1239 4 | 30209 | 7018 4 | 18734 | 701 4 | 4657 | 3320 3 | 33748 | 1239 2 | 5056 | 1239 2 | 10026 | 2828 2 | 12252 | 2914 1 | 11696 | 2828 (24 rows) bgp=# select count(blame_asn),blame_asn,asn_responsible from leakinfo where aprox_time::date = '2011-02-23' group by blame_asn,asn_responsible order by 1 desc; count | blame_asn | asn_responsible -------+-----------+----------------- 384 | 7473 | 3257 120 | 17379 | 5511 48 | | 27 | 45419 | 3356 24 | 12180 | 2828 11 | 23456 | 2914 (6 rows) bgp=# select count(blame_asn),blame_asn,asn_responsible from leakinfo where aprox_time::date = '2011-01-28' group by blame_asn,asn_responsible order by 1 desc; count | blame_asn | asn_responsible -------+-----------+----------------- 9119 | 6453 | 6453 2265 | | 355 | 2914 | 2914 313 | 7473 | 3257 250 | 17379 | 5511 213 | 32592 | 701 106 | 3790 | 1239 72 | 19108 | 6461 62 | 14051 | 1239 51 | 34977 | 6453 48 | 31133 | 3356 47 | 8657 | 174 32 | 7713 | 2914 31 | 1257 | 1239 31 | 8966 | 2914 30 | 30209 | 7018 30 | 31133 | 1299 29 | 8342 | 1239 24 | 38925 | 3320 24 | 12180 | 2828 22 | 8657 | 3549 21 | 15641 | 3549 18 | 31133 | 2914 16 | 15412 | 2914 15 | 7473 | 3549 10 | 6762 | 1299 10 | 6762 | 7018 10 | 20299 | 1239 10 | 6762 | 3561 10 | 6762 | 174 9 | 4323 | 2914 7 | 26163 | 6461 7 | 9505 | 174 7 | 15149 | 6461 7 | 9070 | 3549 7 | 7819 | 6461 6 | 7473 | 174 6 | 3216 | 3549 6 | 1273 | 174 5 | 8657 | 3356 5 | 26769 | 3549 5 | 6762 | 2914 5 | 6762 | 3356 4 | 8047 | 701 4 | 8877 | 174 4 | 174 | 174 2 | 20299 | 174 2 | 7843 | 174 2 | 7473 | 6453 2 | 8928 | 3320 2 | 7991 | 2914 1 | 1273 | 3549 1 | 20485 | 2914 1 | 3216 | 1239 (54 rows) From Bryan at bryanfields.net Thu Feb 24 16:02:03 2011 From: Bryan at bryanfields.net (Bryan Fields) Date: Thu, 24 Feb 2011 17:02:03 -0500 Subject: Christchurch New Zealand In-Reply-To: <4D669D12.3060808@jima.tk> References: <16209229.651.1298559834102.JavaMail.franck@franck-martins-macbook-pro.local> <4D669674.4060102@trelane.net> <4D669D12.3060808@jima.tk> Message-ID: <4D66D55B.6040703@bryanfields.net> On 2/24/2011 13:01, Jima wrote: > Wait for a winner to prevail. Whoever comes out on top is clearly more > prepared to deal with emergencies. http://www.hamsexy.com -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From mike.lyon at gmail.com Thu Feb 24 16:23:31 2011 From: mike.lyon at gmail.com (Mike Lyon) Date: Thu, 24 Feb 2011 14:23:31 -0800 Subject: Christchurch New Zealand In-Reply-To: <4D669674.4060102@trelane.net> References: <16209229.651.1298559834102.JavaMail.franck@franck-martins-macbook-pro.local> <4D669674.4060102@trelane.net> Message-ID: The old pin--through-the-center-of-the coax trick while you go on setting up your repeater? :) 73's, Mike KE6MRE On Thu, Feb 24, 2011 at 9:33 AM, Andrew Kirch wrote: > The problem with this is that both ARES and RACES hams have gotten there > first (orange lights and strobes flashing) and are now engaged in > small-arms fire over who gets to set their repeater up. You're now > hiding under your vehicle. What is your next move? > > Andrew > > > On 2/24/2011 10:03 AM, Franck Martin wrote: > > You have products like a cell on wheels. A container containing a phone > switch and a mobile cell, easily installable. You place it at the center of > the disaster zone and all mobile phones start to work... > > > > if you are worried about congestion, then only the "right" sims are > registered/enabled. > > > > ----- Original Message ----- > > From: "mikea" > > To: nanog at nanog.org > > Sent: Thursday, 24 February, 2011 9:39:09 AM > > Subject: Re: Christchurch New Zealand > > > > On Wed, Feb 23, 2011 at 10:08:39AM -0800, JC Dill wrote: > >> On 22/02/11 10:38 PM, Joe Hamelin wrote: > >>> The other CERT: Community Emergency Response Team. > >>> https://www.citizencorps.gov/cert/about.shtm > >> +1 for CERT. I also think that taking a CERT class is a great way to > >> re-evaluate your own network emergency procedures. You may find new > >> ways to prepare for network disasters, and to triage damage when a > >> network disaster occurs. > > Agreed on CERT. > > > > I diffidently suggest that amateur radio licensing, together with some > > battery-operated gear (think 2-meter or 70-cm handy-talkies at a minimum > > for short-haul comms, HF gear for longer-haul) may be Very Good Indeed > > in a disaster that takes down POTS service or government emergency > > communications. Folks interested in this might want to investigate ARES > > and/or RACES in the US, or similar activities in other countries. > > > > > > > From owen at delong.com Thu Feb 24 17:06:41 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 24 Feb 2011 15:06:41 -0800 Subject: Christchurch New Zealand In-Reply-To: References: <16209229.651.1298559834102.JavaMail.franck@franck-martins-macbook-pro.local> <4D669674.4060102@trelane.net> Message-ID: <10EBD7CA-AEAE-4B47-989D-69B4A27342B7@delong.com> FWIW, in my experience, when ARES and RACES both arrive on a scene together, they rarely get into small arms fire over any thing, rather, preferring to work together to help each other set up both repeaters and to coordinate which parts of the workload will be handled by which operation in order to maximize the efficiency with which the job gets done. Perhaps this is unique to California (yeah, I know we're known as the land of Granola out there), or, perhaps as I perceive, hams world wide tend to be community-minded decent folks trying to help. Owen KB6MER On Feb 24, 2011, at 2:23 PM, Mike Lyon wrote: > The old pin--through-the-center-of-the coax trick while you go on setting up > your repeater? :) > > 73's, > Mike > KE6MRE > > > On Thu, Feb 24, 2011 at 9:33 AM, Andrew Kirch wrote: > >> The problem with this is that both ARES and RACES hams have gotten there >> first (orange lights and strobes flashing) and are now engaged in >> small-arms fire over who gets to set their repeater up. You're now >> hiding under your vehicle. What is your next move? >> >> Andrew >> >> >> On 2/24/2011 10:03 AM, Franck Martin wrote: >>> You have products like a cell on wheels. A container containing a phone >> switch and a mobile cell, easily installable. You place it at the center of >> the disaster zone and all mobile phones start to work... >>> >>> if you are worried about congestion, then only the "right" sims are >> registered/enabled. >>> >>> ----- Original Message ----- >>> From: "mikea" >>> To: nanog at nanog.org >>> Sent: Thursday, 24 February, 2011 9:39:09 AM >>> Subject: Re: Christchurch New Zealand >>> >>> On Wed, Feb 23, 2011 at 10:08:39AM -0800, JC Dill wrote: >>>> On 22/02/11 10:38 PM, Joe Hamelin wrote: >>>>> The other CERT: Community Emergency Response Team. >>>>> https://www.citizencorps.gov/cert/about.shtm >>>> +1 for CERT. I also think that taking a CERT class is a great way to >>>> re-evaluate your own network emergency procedures. You may find new >>>> ways to prepare for network disasters, and to triage damage when a >>>> network disaster occurs. >>> Agreed on CERT. >>> >>> I diffidently suggest that amateur radio licensing, together with some >>> battery-operated gear (think 2-meter or 70-cm handy-talkies at a minimum >>> for short-haul comms, HF gear for longer-haul) may be Very Good Indeed >>> in a disaster that takes down POTS service or government emergency >>> communications. Folks interested in this might want to investigate ARES >>> and/or RACES in the US, or similar activities in other countries. >>> >>> >> >> >> From tmagill at providecommerce.com Thu Feb 24 17:43:26 2011 From: tmagill at providecommerce.com (Thomas Magill) Date: Thu, 24 Feb 2011 23:43:26 +0000 Subject: Time Warner - Roadrunner Route-server? Message-ID: Does anyone know if there is a route-server for AS 20001 available? All I can find is TW (4323). Thomas Magill Network Engineer Office: (858) 909-3777 Cell: (858) 869-9685 mailto:tmagill at providecommerce.com provide-commerce 4840 Eastgate Mall San Diego, CA 92121 ProFlowers | redENVELOPE | Cherry Moon Farms | Shari's Berries From blakjak at blakjak.net Thu Feb 24 17:48:38 2011 From: blakjak at blakjak.net (Mark Foster) Date: Fri, 25 Feb 2011 12:48:38 +1300 (NZDT) Subject: Christchurch New Zealand In-Reply-To: <10EBD7CA-AEAE-4B47-989D-69B4A27342B7@delong.com> References: <16209229.651.1298559834102.JavaMail.franck@franck-martins-macbook-pro.local> <4D669674.4060102@trelane.net> <10EBD7CA-AEAE-4B47-989D-69B4A27342B7@delong.com> Message-ID: I'm glad someone said something nice about Radio Hams on this thread (which started as being about Christchurch!) or i'd have risked polluting Christchurch's good rep with all this noise about whackers! FWIW AREC (NZ's ARES equivalent) are active in Christchurch, mainly on VHF, though there's been a little activity on HF as well as I gather. I'm too far away (or too poorly equipped) to verify those reports. For the most part though the major Telcos are succeeding on providing sufficient resources to limp things along. Hundreds of Generators are operating to provide cover for critical comms infrastructure (when not being stolen!). Back in September I blogged about the NZ Fire Service's new HAZMAT-Command vehicles and how they had proven their worth. During that quake they had ~1-2 operational. http://www.blakjak.net/node/1380 (photos etc) This is outside the main Christchurch Fire Station where one is currently operating as Command Unit, taken Yesterday: http://www.aucklandfirepolice.org.nz/images/christchurch/5.jpg NZ recently fielded 17 of those trucks, I gather there's ~5 of them deployed in Christchurch now, plus at least a couple of the previous-generation command units they replaced. They're equipped with Cellular, Satcom and Radio. >From what i've seen connectivity is still available for the majority of Christchurch based ISP's and major networks - assuming their building's are still servicable. NZNOG is currently collating offers of assistance from the local NOG community, and there's some wider stuff going on: http://www.nznog.org/?page_id=31 http://www.geekzone.co.nz/freitasm/7561 http://business.eq.org.nz/ As usual, if you filter through the crims, scammers and others who would take advantage of such a situation, there's plenty of good people doing their bit to assist. I for one was very grateful to see so much international assistance popping up promptly too. Mark ZL1VMF Auckland, NZ On Thu, 24 Feb 2011, Owen DeLong wrote: > FWIW, in my experience, when ARES and RACES both arrive on a scene > together, they rarely get into small arms fire over any thing, rather, preferring > to work together to help each other set up both repeaters and to coordinate > which parts of the workload will be handled by which operation in order to > maximize the efficiency with which the job gets done. > > Perhaps this is unique to California (yeah, I know we're known as the > land of Granola out there), or, perhaps as I perceive, hams world wide > tend to be community-minded decent folks trying to help. > > Owen > KB6MER > > On Feb 24, 2011, at 2:23 PM, Mike Lyon wrote: > >> The old pin--through-the-center-of-the coax trick while you go on setting up >> your repeater? :) >> >> 73's, >> Mike >> KE6MRE >> *snip* From diogo.montagner at gmail.com Thu Feb 24 18:10:30 2011 From: diogo.montagner at gmail.com (Diogo Montagner) Date: Fri, 25 Feb 2011 08:10:30 +0800 Subject: SLA for voice and video over IP/MPLS Message-ID: Hello, I am looking for industry standard parameters to base the SLA of one network regarding to voice, video and data application. Which are the the accepted values for jiiter, delay, latency and packet loss for voice, video and data in a IP/MPLS ? Thanks ./diogo -montagner From oberman at es.net Thu Feb 24 18:50:19 2011 From: oberman at es.net (Kevin Oberman) Date: Thu, 24 Feb 2011 16:50:19 -0800 Subject: 6453 routing leaks (January and Today) In-Reply-To: Your message of "Thu, 24 Feb 2011 16:59:52 EST." Message-ID: <20110225005019.825711CC0B@ptavv.es.net> > From: Jared Mauch > Date: Thu, 24 Feb 2011 16:59:52 -0500 > > It appears there have been a large number of routing leaks from 6453 today based on my detection scripts that have been running. > > (shameless plug for http://puck.nether.net/bgp/leakinfo.cgi) > > A quick report of the data show (for today so far) a few thousand of leaks more than is normal for a day like today. I included a snapshot of yesterday below as well. > > I've included a more detailed report of the prefixes observed involved here: > > http://puck.nether.net/~jared/tata-leak-20110224.txt > > This seems to be a somewhat common event for 6453, loking through the history of data available, another event happened on 2011-01-28 as well. > > I'm interested in what best operational practices people have employed to help avoid the leaks seen here so I can document them for others to learn to prevent this from happening again. > > - Jared > > bgp=# select count(blame_asn),blame_asn,asn_responsible from leakinfo where aprox_time::date = '2011-02-24' group by blame_asn,asn_responsible order by 1 desc; > count | blame_asn | asn_responsible > -------+-----------+----------------- > 2208 | 6453 | 6453 > 360 | 7473 | 3257 > 230 | | > 170 | 17379 | 5511 > 130 | 8068 | 3356 > 39 | 3225 | 6453 > 34 | 45419 | 3356 > 26 | 3356 | 3356 > 25 | 12180 | 2828 > 18 | 22351 | 701 > 16 | 7991 | 2914 > 16 | 14051 | 1239 > 10 | 29571 | 5511 > 4 | 32327 | 2828 > 4 | 8966 | 2914 > 4 | 19080 | 1239 > 4 | 30209 | 7018 > 4 | 18734 | 701 > 4 | 4657 | 3320 > 3 | 33748 | 1239 > 2 | 5056 | 1239 > 2 | 10026 | 2828 > 2 | 12252 | 2914 > 1 | 11696 | 2828 > (24 rows) > > bgp=# select count(blame_asn),blame_asn,asn_responsible from leakinfo where aprox_time::date = '2011-02-23' group by blame_asn,asn_responsible order by 1 desc; > count | blame_asn | asn_responsible > -------+-----------+----------------- > 384 | 7473 | 3257 > 120 | 17379 | 5511 > 48 | | > 27 | 45419 | 3356 > 24 | 12180 | 2828 > 11 | 23456 | 2914 > (6 rows) > > bgp=# select count(blame_asn),blame_asn,asn_responsible from leakinfo where aprox_time::date = '2011-01-28' group by blame_asn,asn_responsible order by 1 desc; > count | blame_asn | asn_responsible > -------+-----------+----------------- > 9119 | 6453 | 6453 > 2265 | | > 355 | 2914 | 2914 > 313 | 7473 | 3257 > 250 | 17379 | 5511 > 213 | 32592 | 701 > 106 | 3790 | 1239 > 72 | 19108 | 6461 > 62 | 14051 | 1239 > 51 | 34977 | 6453 > 48 | 31133 | 3356 > 47 | 8657 | 174 > 32 | 7713 | 2914 > 31 | 1257 | 1239 > 31 | 8966 | 2914 > 30 | 30209 | 7018 > 30 | 31133 | 1299 > 29 | 8342 | 1239 > 24 | 38925 | 3320 > 24 | 12180 | 2828 > 22 | 8657 | 3549 > 21 | 15641 | 3549 > 18 | 31133 | 2914 > 16 | 15412 | 2914 > 15 | 7473 | 3549 > 10 | 6762 | 1299 > 10 | 6762 | 7018 > 10 | 20299 | 1239 > 10 | 6762 | 3561 > 10 | 6762 | 174 > 9 | 4323 | 2914 > 7 | 26163 | 6461 > 7 | 9505 | 174 > 7 | 15149 | 6461 > 7 | 9070 | 3549 > 7 | 7819 | 6461 > 6 | 7473 | 174 > 6 | 3216 | 3549 > 6 | 1273 | 174 > 5 | 8657 | 3356 > 5 | 26769 | 3549 > 5 | 6762 | 2914 > 5 | 6762 | 3356 > 4 | 8047 | 701 > 4 | 8877 | 174 > 4 | 174 | 174 > 2 | 20299 | 174 > 2 | 7843 | 174 > 2 | 7473 | 6453 > 2 | 8928 | 3320 > 2 | 7991 | 2914 > 1 | 1273 | 3549 > 1 | 20485 | 2914 > 1 | 3216 | 1239 > (54 rows) Can't say if it was a leak or de aggregation, but TATA announcements to us jumped from about 70,000 to almost 190,000 for a while today, then dropped back down. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From patrick at ianai.net Thu Feb 24 20:27:17 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 24 Feb 2011 21:27:17 -0500 Subject: Time Warner - Roadrunner Route-server? In-Reply-To: References: Message-ID: <051DF9D9-7682-4DFB-8465-05369E84CF8D@ianai.net> On Feb 24, 2011, at 18:43, Thomas Magill wrote: > Does anyone know if there is a route-server for AS 20001 available? All I can find is TW (4323). I believe as20001 is a stub AS behind as7843. Of course, I do not think as7843 has a looking glass. -- TTFN, patrick From jared at puck.nether.net Thu Feb 24 21:05:19 2011 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 24 Feb 2011 22:05:19 -0500 Subject: 6453 routing leaks (January and Today) In-Reply-To: <20110225005019.825711CC0B@ptavv.es.net> References: <20110225005019.825711CC0B@ptavv.es.net> Message-ID: <2AE07924-9369-4D18-8BAF-33605FB226D4@puck.nether.net> On Feb 24, 2011, at 7:50 PM, Kevin Oberman wrote: > Can't say if it was a leak or de aggregation, but TATA announcements to > us jumped from about 70,000 to almost 190,000 for a while today, then > dropped back down. It very much appears to be a leak based on the route-views MRT format updates. There's not a good reason for this observed prefix/path combination: 41.194.32.0/24 | 3549 6453 3356 22351 36939 I don't believe 3549 nor 3356 are buying transit from 6453 to reach each other. One of the interesting measurements I track (people accuse me of pcaping all bgp updates, which is sorta true with this MRT archive) is the average file sizes of the route-views archive: http://archive.routeviews.org/bgpdata/2011.02/UPDATES/ This is a good measure of how stable/unstable the network is. You can typically see when a network has performed some grooming or an event like this just by getting a feel for the file sizes. When they go from ~300KiB on average to something in the multiple megs, you know something happened. - Jared From jra at baylink.com Thu Feb 24 23:08:32 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 25 Feb 2011 00:08:32 -0500 (EST) Subject: Christchurch New Zealand In-Reply-To: <10EBD7CA-AEAE-4B47-989D-69B4A27342B7@delong.com> Message-ID: <17172363.334.1298610512764.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > FWIW, in my experience, when ARES and RACES both arrive on a scene > together, they rarely get into small arms fire over any thing, rather, > preferring to work together to help each other set up both repeaters and to > coordinate which parts of the workload will be handled by which operation in > order to maximize the efficiency with which the job gets done. Ok; I started this, so I guess I should finish it. I'm sure when the rubber(-duckies) hit the road, everyone gets along fine. I was talking more about political stuff internal to the orgs in some places, WRT interfacing with the officials *before* there are active emergencies. I gather that's a bit dicey and old-boy-ish in at least some locales. Cheers, -- jra From maxsec at gmail.com Fri Feb 25 00:27:30 2011 From: maxsec at gmail.com (Martin Hepworth) Date: Fri, 25 Feb 2011 06:27:30 +0000 Subject: SLA for voice and video over IP/MPLS In-Reply-To: References: Message-ID: I'd be looking at packet ordering perhaps for voice and esp video, having the packets arrive in order makes a huge difference for video On Friday, 25 February 2011, Diogo Montagner wrote: > Hello, > > I am looking for industry standard parameters to base the SLA of one > network regarding to voice, video and data application. > > Which are the the accepted values for jiiter, delay, latency and > packet loss for voice, video and data in a IP/MPLS ? > > Thanks > > ./diogo -montagner > > -- -- Martin Hepworth Oxford, UK From regnauld at nsrc.org Fri Feb 25 03:54:37 2011 From: regnauld at nsrc.org (Phil Regnauld) Date: Fri, 25 Feb 2011 10:54:37 +0100 Subject: A pragmatic issue with running out of v4 :) Message-ID: <20110225095432.GB15601@macbook.catpipe.net> http://xkcd.com/865/ From tagno25 at gmail.com Fri Feb 25 04:00:17 2011 From: tagno25 at gmail.com (Philip Dorr) Date: Fri, 25 Feb 2011 04:00:17 -0600 Subject: A pragmatic issue with running out of v4 :) In-Reply-To: <20110225095432.GB15601@macbook.catpipe.net> References: <20110225095432.GB15601@macbook.catpipe.net> Message-ID: It is actually about moving away from IPv6 "I think the IETF hit the right balance with the 128 bits thing. We can fit MAC addresses in a /64 subnet, and the nanobots will only be able to devour half the planet." On Fri, Feb 25, 2011 at 3:54 AM, Phil Regnauld wrote: > http://xkcd.com/865/ > > From bmanning at vacation.karoshi.com Fri Feb 25 04:03:03 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 25 Feb 2011 10:03:03 +0000 Subject: A pragmatic issue with running out of v4 :) In-Reply-To: <20110225095432.GB15601@macbook.catpipe.net> References: <20110225095432.GB15601@macbook.catpipe.net> Message-ID: <20110225100303.GA25850@vacation.karoshi.com.> On Fri, Feb 25, 2011 at 10:54:37AM +0100, Phil Regnauld wrote: > http://xkcd.com/865/ all they have to do is turn off SLLAC and RA/RD and the'll be good to go... --bill From jared at puck.nether.net Fri Feb 25 06:22:36 2011 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 25 Feb 2011 07:22:36 -0500 Subject: 6453 routing leaks (January and Today) In-Reply-To: References: Message-ID: Update: I have had a source ask me to post the following: -- snip -- The problem with route leaking was caused by specific routing platform resulting in some peer routes not being properly tagged. We are deploying additional measures to prevent this from happening in the future -- snip -- - Jared On Feb 24, 2011, at 4:59 PM, Jared Mauch wrote: > It appears there have been a large number of routing leaks from 6453 today based on my detection scripts that have been running. > > (shameless plug for http://puck.nether.net/bgp/leakinfo.cgi) > > A quick report of the data show (for today so far) a few thousand of leaks more than is normal for a day like today. I included a snapshot of yesterday below as well. > > I've included a more detailed report of the prefixes observed involved here: > > http://puck.nether.net/~jared/tata-leak-20110224.txt > > This seems to be a somewhat common event for 6453, loking through the history of data available, another event happened on 2011-01-28 as well. > > I'm interested in what best operational practices people have employed to help avoid the leaks seen here so I can document them for others to learn to prevent this from happening again. > > - Jared > > bgp=# select count(blame_asn),blame_asn,asn_responsible from leakinfo where aprox_time::date = '2011-02-24' group by blame_asn,asn_responsible order by 1 desc; > count | blame_asn | asn_responsible > -------+-----------+----------------- > 2208 | 6453 | 6453 > 360 | 7473 | 3257 > 230 | | > 170 | 17379 | 5511 > 130 | 8068 | 3356 > 39 | 3225 | 6453 > 34 | 45419 | 3356 > 26 | 3356 | 3356 > 25 | 12180 | 2828 > 18 | 22351 | 701 > 16 | 7991 | 2914 > 16 | 14051 | 1239 > 10 | 29571 | 5511 > 4 | 32327 | 2828 > 4 | 8966 | 2914 > 4 | 19080 | 1239 > 4 | 30209 | 7018 > 4 | 18734 | 701 > 4 | 4657 | 3320 > 3 | 33748 | 1239 > 2 | 5056 | 1239 > 2 | 10026 | 2828 > 2 | 12252 | 2914 > 1 | 11696 | 2828 > (24 rows) > > bgp=# select count(blame_asn),blame_asn,asn_responsible from leakinfo where aprox_time::date = '2011-02-23' group by blame_asn,asn_responsible order by 1 desc; > count | blame_asn | asn_responsible > -------+-----------+----------------- > 384 | 7473 | 3257 > 120 | 17379 | 5511 > 48 | | > 27 | 45419 | 3356 > 24 | 12180 | 2828 > 11 | 23456 | 2914 > (6 rows) > > bgp=# select count(blame_asn),blame_asn,asn_responsible from leakinfo where aprox_time::date = '2011-01-28' group by blame_asn,asn_responsible order by 1 desc; > count | blame_asn | asn_responsible > -------+-----------+----------------- > 9119 | 6453 | 6453 > 2265 | | > 355 | 2914 | 2914 > 313 | 7473 | 3257 > 250 | 17379 | 5511 > 213 | 32592 | 701 > 106 | 3790 | 1239 > 72 | 19108 | 6461 > 62 | 14051 | 1239 > 51 | 34977 | 6453 > 48 | 31133 | 3356 > 47 | 8657 | 174 > 32 | 7713 | 2914 > 31 | 1257 | 1239 > 31 | 8966 | 2914 > 30 | 30209 | 7018 > 30 | 31133 | 1299 > 29 | 8342 | 1239 > 24 | 38925 | 3320 > 24 | 12180 | 2828 > 22 | 8657 | 3549 > 21 | 15641 | 3549 > 18 | 31133 | 2914 > 16 | 15412 | 2914 > 15 | 7473 | 3549 > 10 | 6762 | 1299 > 10 | 6762 | 7018 > 10 | 20299 | 1239 > 10 | 6762 | 3561 > 10 | 6762 | 174 > 9 | 4323 | 2914 > 7 | 26163 | 6461 > 7 | 9505 | 174 > 7 | 15149 | 6461 > 7 | 9070 | 3549 > 7 | 7819 | 6461 > 6 | 7473 | 174 > 6 | 3216 | 3549 > 6 | 1273 | 174 > 5 | 8657 | 3356 > 5 | 26769 | 3549 > 5 | 6762 | 2914 > 5 | 6762 | 3356 > 4 | 8047 | 701 > 4 | 8877 | 174 > 4 | 174 | 174 > 2 | 20299 | 174 > 2 | 7843 | 174 > 2 | 7473 | 6453 > 2 | 8928 | 3320 > 2 | 7991 | 2914 > 1 | 1273 | 3549 > 1 | 20485 | 2914 > 1 | 3216 | 1239 > (54 rows) > From eric at roxanne.org Fri Feb 25 07:52:44 2011 From: eric at roxanne.org (Eric Gauthier) Date: Fri, 25 Feb 2011 08:52:44 -0500 Subject: A pragmatic issue with running out of v4 :) In-Reply-To: <20110225100303.GA25850@vacation.karoshi.com.> References: <20110225095432.GB15601@macbook.catpipe.net> <20110225100303.GA25850@vacation.karoshi.com.> Message-ID: <20110225135243.GA6008@roxanne.org> I wonder if Skynet upgraded to v6... Eric :) On Fri, Feb 25, 2011 at 10:03:03AM +0000, bmanning at vacation.karoshi.com wrote: > On Fri, Feb 25, 2011 at 10:54:37AM +0100, Phil Regnauld wrote: > > http://xkcd.com/865/ > > all they have to do is turn off SLLAC and RA/RD and the'll be > good to go... > > --bill From jra at baylink.com Fri Feb 25 08:25:01 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 25 Feb 2011 09:25:01 -0500 (EST) Subject: Christchurch New Zealand In-Reply-To: <4D674B61.6060700@trelane.net> Message-ID: <22356955.392.1298643901203.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Andrew Kirch" > Lets argue this one on IRC... where I'm a channel admin in #hamradio, > and have to keep these two separated most of the time. Me and Owen? I'm almost never on that channel... :-) Cheers, -- jra From isabeldias1 at yahoo.com Fri Feb 25 10:06:56 2011 From: isabeldias1 at yahoo.com (isabel dias) Date: Fri, 25 Feb 2011 08:06:56 -0800 (PST) Subject: A pragmatic issue with running out of v4 :) In-Reply-To: <20110225135243.GA6008@roxanne.org> References: <20110225095432.GB15601@macbook.catpipe.net> <20110225100303.GA25850@vacation.karoshi.com.> <20110225135243.GA6008@roxanne.org> Message-ID: <472688.60641.qm@web121619.mail.ne1.yahoo.com> how relevant is that information? ----- Original Message ---- From: Eric Gauthier To: nanog at nanog.org Sent: Fri, February 25, 2011 1:52:44 PM Subject: Re: A pragmatic issue with running out of v4 :) I wonder if Skynet upgraded to v6... Eric :) On Fri, Feb 25, 2011 at 10:03:03AM +0000, bmanning at vacation.karoshi.com wrote: > On Fri, Feb 25, 2011 at 10:54:37AM +0100, Phil Regnauld wrote: > > http://xkcd.com/865/ > > ??? all they have to do is turn off SLLAC and RA/RD and the'll be > ??? good to go... > > --bill From eugen at leitl.org Fri Feb 25 10:27:11 2011 From: eugen at leitl.org (Eugen Leitl) Date: Fri, 25 Feb 2011 17:27:11 +0100 Subject: A pragmatic issue with running out of v4 :) In-Reply-To: <20110225135243.GA6008@roxanne.org> References: <20110225095432.GB15601@macbook.catpipe.net> <20110225100303.GA25850@vacation.karoshi.com.> <20110225135243.GA6008@roxanne.org> Message-ID: <20110225162711.GV23560@leitl.org> On Fri, Feb 25, 2011 at 08:52:44AM -0500, Eric Gauthier wrote: > > I wonder if Skynet upgraded to v6... http://www.skynet.be/jack-nl/high-tech/dossier_belgacom-bereidt-zich-voor-ipv6?articleId=835562 .be afraid. > Eric :) From nathan at atlasnetworks.us Fri Feb 25 11:21:48 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Fri, 25 Feb 2011 17:21:48 +0000 Subject: Contact for the Microsoft Teredo Cloud? Message-ID: <8C26A4FDAE599041A13EB499117D3C286B39EDDB@ex-mb-1.corp.atlasnetworks.us> Does anyone know who to ping at Microsoft about their teredo platform? Their relay(s) doesn't/don't seem to have reachability to some bits of IPv6 space. Nathan From owen at delong.com Fri Feb 25 11:28:13 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 25 Feb 2011 09:28:13 -0800 Subject: Christchurch New Zealand In-Reply-To: <22356955.392.1298643901203.JavaMail.root@benjamin.baylink.com> References: <22356955.392.1298643901203.JavaMail.root@benjamin.baylink.com> Message-ID: <68CF17E8-6104-49AF-A3A3-9681ADC5725F@delong.com> On Feb 25, 2011, at 6:25 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Andrew Kirch" >> Lets argue this one on IRC... where I'm a channel admin in #hamradio, >> and have to keep these two separated most of the time. > > Me and Owen? I'm almost never on that channel... :-) > > Cheers, > -- jra LoL... I'm almost never on IRC. Owen From owen at delong.com Fri Feb 25 11:27:35 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 25 Feb 2011 09:27:35 -0800 Subject: A pragmatic issue with running out of v4 :) In-Reply-To: <20110225135243.GA6008@roxanne.org> References: <20110225095432.GB15601@macbook.catpipe.net> <20110225100303.GA25850@vacation.karoshi.com.> <20110225135243.GA6008@roxanne.org> Message-ID: Apparently not: [owen-delongs-macbook-pro:~] owen% host www.skynet.net www.skynet.net has address 66.165.165.53 [owen-delongs-macbook-pro:~] owen% host -t aaaa www.skynet.net www.skynet.net has no AAAA record Owen On Feb 25, 2011, at 5:52 AM, Eric Gauthier wrote: > > I wonder if Skynet upgraded to v6... > > Eric :) > > On Fri, Feb 25, 2011 at 10:03:03AM +0000, bmanning at vacation.karoshi.com wrote: >> On Fri, Feb 25, 2011 at 10:54:37AM +0100, Phil Regnauld wrote: >>> http://xkcd.com/865/ >> >> all they have to do is turn off SLLAC and RA/RD and the'll be >> good to go... >> >> --bill From ras at e-gerbil.net Fri Feb 25 11:51:45 2011 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Fri, 25 Feb 2011 11:51:45 -0600 Subject: 6453 routing leaks (January and Today) In-Reply-To: References: Message-ID: <20110225175144.GI38726@gerbil.cluepon.net> On Fri, Feb 25, 2011 at 07:22:36AM -0500, Jared Mauch wrote: > Update: > > I have had a source ask me to post the following: > > -- snip -- > The problem with route leaking was caused by specific routing platform > resulting in some peer routes not being properly tagged. > We are deploying additional measures to prevent this from happening in > the future > -- snip -- Hopefully someone learned a lesson about BGP community design, and how it should fail safe by NOT leaking if you accidentally fail to tag a route. Always require a positive match on a route to advertise to peers, not the absence of a negative match. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From jeroen at unfix.org Fri Feb 25 12:04:39 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 25 Feb 2011 19:04:39 +0100 Subject: Contact for the Microsoft Teredo Cloud? In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B39EDDB@ex-mb-1.corp.atlasnetworks.us> References: <8C26A4FDAE599041A13EB499117D3C286B39EDDB@ex-mb-1.corp.atlasnetworks.us> Message-ID: <4D67EF37.7050505@unfix.org> On 2011-02-25 18:21, Nathan Eisenberg wrote: > Does anyone know who to ping at Microsoft about their teredo > platform? Their relay(s) doesn't/don't seem to have reachability to > some bits of IPv6 space. (Afaik) Microsoft only operates Teredo servers, no Teredo Relays, those are run by other networks. Greets, Jeroen From paul at paulstewart.org Fri Feb 25 12:24:13 2011 From: paul at paulstewart.org (Paul Stewart) Date: Fri, 25 Feb 2011 13:24:13 -0500 Subject: 6453 routing leaks (January and Today) In-Reply-To: <20110225175144.GI38726@gerbil.cluepon.net> References: <20110225175144.GI38726@gerbil.cluepon.net> Message-ID: <03bb01cbd519$34de1760$9e9a4620$@org> Yes, very scary actually.... Human error is unavoidable - it's going to happen at times - BUT.... In our communities design, there has been times where we have missed a tag on an inbound customer for example. It scares the crap out of me to think that something like that simple mistake could cause route leakage. Thankfully, anytime it has happened it would caught pretty quickly and fixed - in the meantime the routes simply didn't leave our network (the way it should be). Obviously the scales are different between someone like ourselves and that of TATA - but the principles and common sense remain. Paul -----Original Message----- From: Richard A Steenbergen [mailto:ras at e-gerbil.net] Sent: Friday, February 25, 2011 12:52 PM To: Jared Mauch Cc: NANOG list Subject: Re: 6453 routing leaks (January and Today) On Fri, Feb 25, 2011 at 07:22:36AM -0500, Jared Mauch wrote: > Update: > > I have had a source ask me to post the following: > > -- snip -- > The problem with route leaking was caused by specific routing platform > resulting in some peer routes not being properly tagged. > We are deploying additional measures to prevent this from happening in > the future > -- snip -- Hopefully someone learned a lesson about BGP community design, and how it should fail safe by NOT leaking if you accidentally fail to tag a route. Always require a positive match on a route to advertise to peers, not the absence of a negative match. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From cscora at apnic.net Fri Feb 25 12:36:46 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 26 Feb 2011 04:36:46 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201102251836.p1PIak63030156@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 26 Feb, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 348212 Prefixes after maximum aggregation: 157161 Deaggregation factor: 2.22 Unique aggregates announced to Internet: 171859 Total ASes present in the Internet Routing Table: 35939 Prefixes per ASN: 9.69 Origin-only ASes present in the Internet Routing Table: 30974 Origin ASes announcing only one prefix: 14951 Transit ASes present in the Internet Routing Table: 4965 Transit-only ASes present in the Internet Routing Table: 120 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 31 Max AS path prepend of ASN (36992) 29 Prefixes from unregistered ASNs in the Routing Table: 340 Unregistered ASNs in the Routing Table: 141 Number of 32-bit ASNs allocated by the RIRs: 1141 Prefixes from 32-bit ASNs in the Routing Table: 2 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 202 Number of addresses announced to Internet: 2366402016 Equivalent to 141 /8s, 12 /16s and 109 /24s Percentage of available address space announced: 63.8 Percentage of allocated address space announced: 63.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 88.1 Total number of prefixes smaller than registry allocations: 144236 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 86615 Total APNIC prefixes after maximum aggregation: 29555 APNIC Deaggregation factor: 2.93 Prefixes being announced from the APNIC address blocks: 83423 Unique aggregates announced from the APNIC address blocks: 35959 APNIC Region origin ASes present in the Internet Routing Table: 4335 APNIC Prefixes per ASN: 19.24 APNIC Region origin ASes announcing only one prefix: 1203 APNIC Region transit ASes present in the Internet Routing Table: 691 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 18 Number of APNIC addresses announced to Internet: 592208160 Equivalent to 35 /8s, 76 /16s and 97 /24s Percentage of available APNIC address space announced: 75.1 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 139724 Total ARIN prefixes after maximum aggregation: 71567 ARIN Deaggregation factor: 1.95 Prefixes being announced from the ARIN address blocks: 110380 Unique aggregates announced from the ARIN address blocks: 45012 ARIN Region origin ASes present in the Internet Routing Table: 14211 ARIN Prefixes per ASN: 7.77 ARIN Region origin ASes announcing only one prefix: 5395 ARIN Region transit ASes present in the Internet Routing Table: 1471 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 23 Number of ARIN addresses announced to Internet: 787499648 Equivalent to 46 /8s, 240 /16s and 74 /24s Percentage of available ARIN address space announced: 62.6 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 82337 Total RIPE prefixes after maximum aggregation: 46749 RIPE Deaggregation factor: 1.76 Prefixes being announced from the RIPE address blocks: 75631 Unique aggregates announced from the RIPE address blocks: 49313 RIPE Region origin ASes present in the Internet Routing Table: 15346 RIPE Prefixes per ASN: 4.93 RIPE Region origin ASes announcing only one prefix: 7786 RIPE Region transit ASes present in the Internet Routing Table: 2386 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 30 Number of RIPE addresses announced to Internet: 461025600 Equivalent to 27 /8s, 122 /16s and 177 /24s Percentage of available RIPE address space announced: 74.3 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 31872 Total LACNIC prefixes after maximum aggregation: 7374 LACNIC Deaggregation factor: 4.32 Prefixes being announced from the LACNIC address blocks: 30668 Unique aggregates announced from the LACNIC address blocks: 15906 LACNIC Region origin ASes present in the Internet Routing Table: 1435 LACNIC Prefixes per ASN: 21.37 LACNIC Region origin ASes announcing only one prefix: 434 LACNIC Region transit ASes present in the Internet Routing Table: 264 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 18 Number of LACNIC addresses announced to Internet: 80968832 Equivalent to 4 /8s, 211 /16s and 124 /24s Percentage of available LACNIC address space announced: 53.6 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 7451 Total AfriNIC prefixes after maximum aggregation: 1805 AfriNIC Deaggregation factor: 4.13 Prefixes being announced from the AfriNIC address blocks: 5870 Unique aggregates announced from the AfriNIC address blocks: 1836 AfriNIC Region origin ASes present in the Internet Routing Table: 434 AfriNIC Prefixes per ASN: 13.53 AfriNIC Region origin ASes announcing only one prefix: 133 AfriNIC Region transit ASes present in the Internet Routing Table: 92 Average AfriNIC Region AS path length visible: 5.4 Max AfriNIC Region AS path length visible: 31 Number of AfriNIC addresses announced to Internet: 21888000 Equivalent to 1 /8s, 77 /16s and 252 /24s Percentage of available AfriNIC address space announced: 32.6 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2421 9501 886 Korea Telecom (KIX) 7545 1614 302 85 TPG Internet Pty Ltd 4755 1418 634 164 TATA Communications formerly 17974 1415 475 29 PT TELEKOMUNIKASI INDONESIA 24560 1115 323 184 Bharti Airtel Ltd., Telemedia 4808 1046 2142 294 CNCGROUP IP network: China169 9583 1045 77 488 Sify Limited 17488 940 161 102 Hathway IP Over Cable Interne 18101 931 117 139 Reliance Infocom Ltd Internet 9829 895 761 45 BSNL National Internet Backbo Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3690 3855 261 bellsouth.net, inc. 4323 2604 1109 404 Time Warner Telecom 19262 1787 4954 285 Verizon Global Networks 1785 1786 697 131 PaeTec Communications, Inc. 20115 1528 1535 647 Charter Communications 6478 1522 296 84 AT&T Worldnet Services 18566 1447 321 156 Covad Communications 7018 1357 6689 874 AT&T WorldNet Services 2386 1297 553 933 AT&T Data Communications Serv 11492 1286 236 70 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6830 514 1780 319 UPC Distribution Services 9198 470 267 15 Kazakhtelecom Data Network Ad 34984 465 98 145 BILISIM TELEKOM 3292 447 1996 388 TDC Tele Danmark 8866 442 133 23 Bulgarian Telecommunication C 20940 412 98 316 Akamai Technologies European 3320 410 7620 357 Deutsche Telekom AG 8551 403 353 46 Bezeq International 702 396 1800 310 UUNET - Commercial IP service 3301 383 1822 341 TeliaNet Sweden Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1383 257 166 TVCABLE BOGOTA 8151 1353 2686 362 UniNet S.A. de C.V. 28573 1234 961 82 NET Servicos de Comunicao S.A 6503 1169 354 73 AVANTEL, S.A. 7303 907 464 145 Telecom Argentina Stet-France 14420 641 57 94 CORPORACION NACIONAL DE TELEC 22047 543 310 15 VTR PUNTO NET S.A. 3816 508 221 101 Empresa Nacional de Telecomun 7738 478 922 30 Telecomunicacoes da Bahia S.A 11172 462 83 82 Servicios Alestra S.A de C.V Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 770 445 11 TEDATA 24863 692 147 39 LINKdotNET AS number 15475 473 90 12 Nile Online 36992 299 271 14 Etisalat MISR 3741 264 987 226 The Internet Solution 33776 230 13 5 Starcomms Nigeria Limited 24835 218 78 10 RAYA Telecom - Egypt 6713 205 199 12 Itissalat Al-MAGHRIB 29571 192 17 11 Ci Telecom Autonomous system 16637 156 439 87 MTN Network Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3690 3855 261 bellsouth.net, inc. 4323 2604 1109 404 Time Warner Telecom 4766 2421 9501 886 Korea Telecom (KIX) 19262 1787 4954 285 Verizon Global Networks 1785 1786 697 131 PaeTec Communications, Inc. 7545 1614 302 85 TPG Internet Pty Ltd 20115 1528 1535 647 Charter Communications 6478 1522 296 84 AT&T Worldnet Services 18566 1447 321 156 Covad Communications 4755 1418 634 164 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 2604 2200 Time Warner Telecom 1785 1786 1655 PaeTec Communications, Inc. 4766 2421 1535 Korea Telecom (KIX) 7545 1614 1529 TPG Internet Pty Ltd 19262 1787 1502 Verizon Global Networks 6478 1522 1438 AT&T Worldnet Services 17974 1415 1386 PT TELEKOMUNIKASI INDONESIA 18566 1447 1291 Covad Communications 4755 1418 1254 TATA Communications formerly 10620 1383 1217 TVCABLE BOGOTA Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.0.0.0/16 12654 RIPE NCC RIS Project 5.1.0.0/21 12654 RIPE NCC RIS Project 5.1.24.0/24 12654 RIPE NCC RIS Project 24.129.192.0/19 7922 Continental Cablevision 31.43.64.0/19 30886 ISP LvivLan autonomous system 37.0.0.0/16 12654 RIPE NCC RIS Project 37.1.0.0/21 12654 RIPE NCC RIS Project 37.1.24.0/24 12654 RIPE NCC RIS Project 41.57.192.0/18 22750 BCSNET 41.222.79.0/24 36938 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:10 /10:26 /11:72 /12:215 /13:444 /14:765 /15:1372 /16:11536 /17:5667 /18:9352 /19:18904 /20:24452 /21:24996 /22:33336 /23:31719 /24:181897 /25:1150 /26:1378 /27:706 /28:169 /29:16 /30:3 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2277 3690 bellsouth.net, inc. 6478 1476 1522 AT&T Worldnet Services 18566 1425 1447 Covad Communications 4323 1403 2604 Time Warner Telecom 10620 1274 1383 TVCABLE BOGOTA 11492 1243 1286 Cable One 7011 1056 1158 Citizens Utilities 1785 1054 1786 PaeTec Communications, Inc. 6503 952 1169 AVANTEL, S.A. 19262 899 1787 Verizon Global Networks Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:251 2:40 4:13 5:1 8:333 12:2029 13:1 14:412 15:15 16:3 17:8 20:9 23:1 24:1493 27:596 32:60 33:4 34:2 37:1 38:706 40:101 41:2307 44:3 46:641 47:4 49:153 50:95 52:12 55:2 56:2 57:31 58:865 59:475 60:383 61:1108 62:1042 63:1940 64:3848 65:2360 66:4254 67:1778 68:1030 69:2892 70:730 71:399 72:2012 73:1 74:2350 75:292 76:346 77:854 78:697 79:445 80:1064 81:812 82:522 83:464 84:636 85:1046 86:576 87:738 88:355 89:1578 90:157 91:3542 92:494 93:1047 94:1207 95:771 96:455 97:251 98:790 99:33 101:35 107:3 108:88 109:930 110:484 111:718 112:315 113:369 114:499 115:651 116:946 117:685 118:685 119:1020 120:244 121:696 122:1624 123:1056 124:1291 125:1258 128:266 129:156 130:173 131:568 132:108 133:20 134:220 135:49 136:215 137:146 138:294 139:117 140:490 141:203 142:355 143:386 144:484 145:51 146:441 147:199 148:636 149:273 150:169 151:229 152:298 153:179 154:3 155:377 156:176 157:344 158:128 159:381 160:315 161:208 162:276 163:156 164:486 165:339 166:502 167:411 168:737 169:150 170:755 171:69 172:2 173:1224 174:505 175:320 176:1 177:23 178:771 180:816 181:2 182:363 183:247 184:213 186:1020 187:828 188:896 189:1055 190:4423 192:5806 193:4798 194:3503 195:2964 196:1194 197:3 198:3586 199:3833 200:5603 201:1577 202:8292 203:8444 204:4085 205:2300 206:2644 207:3073 208:3922 209:3485 210:2646 211:1347 212:1932 213:1739 214:768 215:63 216:4856 217:1639 218:547 219:365 220:1201 221:452 222:314 223:104 End of report From MGauvin at dryden.ca Fri Feb 25 12:39:49 2011 From: MGauvin at dryden.ca (Mark Gauvin) Date: Fri, 25 Feb 2011 12:39:49 -0600 Subject: 6453 routing leaks (January and Today) In-Reply-To: <03bb01cbd519$34de1760$9e9a4620$@org> References: <20110225175144.GI38726@gerbil.cluepon.net> <03bb01cbd519$34de1760$9e9a4620$@org> Message-ID: <0894734D-6CD5-4064-8197-8850C9EE7221@dryden.ca> Would love a pm on the platform in question Sent from my iPhone On 2011-02-25, at 12:23 PM, "Paul Stewart" wrote: > Yes, very scary actually.... > > Human error is unavoidable - it's going to happen at times - BUT.... > > In our communities design, there has been times where we have missed > a tag > on an inbound customer for example. It scares the crap out of me to > think > that something like that simple mistake could cause route leakage. > Thankfully, anytime it has happened it would caught pretty quickly > and fixed > - in the meantime the routes simply didn't leave our network (the > way it > should be). > > Obviously the scales are different between someone like ourselves > and that > of TATA - but the principles and common sense remain. > > Paul > > > > -----Original Message----- > From: Richard A Steenbergen [mailto:ras at e-gerbil.net] > Sent: Friday, February 25, 2011 12:52 PM > To: Jared Mauch > Cc: NANOG list > Subject: Re: 6453 routing leaks (January and Today) > > On Fri, Feb 25, 2011 at 07:22:36AM -0500, Jared Mauch wrote: >> Update: >> >> I have had a source ask me to post the following: >> >> -- snip -- >> The problem with route leaking was caused by specific routing >> platform >> resulting in some peer routes not being properly tagged. >> We are deploying additional measures to prevent this from happening >> in >> the future >> -- snip -- > > Hopefully someone learned a lesson about BGP community design, and how > it should fail safe by NOT leaking if you accidentally fail to tag a > route. Always require a positive match on a route to advertise to > peers, > not the absence of a negative match. > > -- > Richard A Steenbergen http://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 > 2CBC) > > From toivo at usf.edu Fri Feb 25 14:28:36 2011 From: toivo at usf.edu (Voll, Toivo) Date: Fri, 25 Feb 2011 15:28:36 -0500 Subject: SmartNet Alternatives In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13A7C@RWC-EX1.corp.seven.com> References: <060EDFC2221B014B9504AC06B747F58A499BCC3B57@ex01.alentus.lan><6EFFEFBAC68377459A2E972105C759EC036456FC@EXVBE005-2.exch005intermedia.net> <87pqqvfzuj.fsf@mid.deneb.enyo.de> <5A6D953473350C4B9995546AFE9939EE0BC13A7C@RWC-EX1.corp.seven.com> Message-ID: At least for the FCX line we were told when trying to open a support case that the limited lifetime warranty only applies to hardware and does not make you eligible for any kind of support or software beyond getting hardware replaced. -----Original Message----- From: George Bonser [mailto:gbonser at seven.com] Sent: Sunday, February 13, 2011 15:59 To: Florian Weimer; Ryan Finnesey Cc: nanog at nanog.org; John Macleod Subject: RE: SmartNet Alternatives > * Ryan Finnesey: > > > This is one of the reasons we are starting to look at Juniper for a > > new network build. It is my understanding we set software updates > > for life for free. > > My understanding is that it's free for customers who have a service > contract in place. Most downloads are not self-service, and I haven't > tested if you can get JTAC to provide images for devices you don't > own. Brocade is now offering 5 years (what they consider lifetime) support to the original purchaser of the equipment on some product lines: FastIron SX800, SX1600, CX, WS, and TurboIron that includes software updates. We use a lot of the FCX units. From gbonser at seven.com Fri Feb 25 14:35:27 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 25 Feb 2011 12:35:27 -0800 Subject: SmartNet Alternatives In-Reply-To: References: <060EDFC2221B014B9504AC06B747F58A499BCC3B57@ex01.alentus.lan><6EFFEFBAC68377459A2E972105C759EC036456FC@EXVBE005-2.exch005intermedia.net><87pqqvfzuj.fsf@mid.deneb.enyo.de><5A6D953473350C4B9995546AFE9939EE0BC13A7C@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13D9F@RWC-EX1.corp.seven.com> > > At least for the FCX line we were told when trying to open a support > case that the limited lifetime warranty only applies to hardware and > does not make you eligible for any kind of support or software beyond > getting hardware replaced. > Yeah, you need to buy "phone support" if you want that. It is the lowest level of support and still pretty inexpensive compared to other vendors. In other words, 5 years of free hardware support and 5 years of Remote "phone" support (under $300/year I think) isn't bad when compared to annual support costs for other gear in that class. From jeroen at mompl.net Fri Feb 25 15:33:57 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Fri, 25 Feb 2011 13:33:57 -0800 Subject: humour: nanobots and ipv6 Message-ID: <4D682045.5040308@mompl.net> Apologies if someone posted it already, but I thought this was quite funny :-) http://xkcd.com/865/ -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From cidr-report at potaroo.net Fri Feb 25 16:00:01 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 25 Feb 2011 22:00:01 GMT Subject: BGP Update Report Message-ID: <201102252200.p1PM01Lt055420@wattle.apnic.net> BGP Update Report Interval: 17-Feb-11 -to- 24-Feb-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS8402 28786 1.9% 14.3 -- CORBINA-AS Corbina Telecom 2 - AS15475 27052 1.7% 53.0 -- NOL 3 - AS24863 25704 1.6% 36.7 -- LINKdotNET-AS 4 - AS9829 22084 1.4% 25.3 -- BSNL-NIB National Internet Backbone 5 - AS10113 16370 1.1% 194.9 -- DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 6 - AS23681 15843 1.0% 5281.0 -- ITU-TRANSIT-AS-AP Paradox Digital ASN on behalf of IT Universe. To provide BGP interconnects to VIX and Paradox. 7 - AS36992 14656 0.9% 25.7 -- ETISALAT-MISR 8 - AS3548 13684 0.9% 1368.4 -- Centro de Investigacion y de EstudiosAvanzados del 9 - AS14522 13312 0.8% 34.0 -- Satnet 10 - AS17974 13155 0.8% 14.2 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 11 - AS4755 12281 0.8% 8.6 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 12 - AS35931 12153 0.8% 2025.5 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 13 - AS8452 11678 0.8% 13.5 -- TE-AS TE-AS 14 - AS17224 11363 0.7% 668.4 -- ATT-CERFNET-BLOCK - AT&T Enhanced Network Services 15 - AS9498 10751 0.7% 14.4 -- BBIL-AP BHARTI Airtel Ltd. 16 - AS13675 10168 0.7% 82.0 -- FAIRPO-3 - FAIRPOINT COMMUNICATIONS, INC. 17 - AS17488 10161 0.7% 10.7 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 18 - AS24560 8462 0.5% 7.7 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 19 - AS28573 8246 0.5% 9.1 -- NET Servicos de Comunicao S.A. 20 - AS1785 8235 0.5% 6.0 -- AS-PAETEC-NET - PaeTec Communications, Inc. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS23681 15843 1.0% 5281.0 -- ITU-TRANSIT-AS-AP Paradox Digital ASN on behalf of IT Universe. To provide BGP interconnects to VIX and Paradox. 2 - AS19367 2642 0.2% 2642.0 -- CAROUSEL-INDUSTRIES - Carousel Industries of North America Inc 3 - AS48561 2465 0.2% 2465.0 -- AUTOMIR-AS NP Automir CJSC 4 - AS35931 12153 0.8% 2025.5 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 5 - AS49600 1389 0.1% 1389.0 -- LASEDA La Seda de Barcelona, S.A 6 - AS3548 13684 0.9% 1368.4 -- Centro de Investigacion y de EstudiosAvanzados del 7 - AS17874 1267 0.1% 1267.0 -- NPC-AS-KR National Pension Corporation 8 - AS36952 1102 0.1% 1102.0 -- KENCALL-EPZ 9 - AS28154 4761 0.3% 952.2 -- 10 - AS10432 1653 0.1% 826.5 -- APC-AS-2 - American Personal Communications 11 - AS3407 1544 0.1% 772.0 -- INTERPATH-NC - Interpath 12 - AS17225 721 0.1% 721.0 -- ATT-CERFNET-BLOCK - AT&T Enhanced Network Services 13 - AS17224 11363 0.7% 668.4 -- ATT-CERFNET-BLOCK - AT&T Enhanced Network Services 14 - AS9929 4419 0.3% 631.3 -- CNCNET-CN China Netcom Corp. 15 - AS17408 3119 0.2% 623.8 -- ABOVE-AS-AP AboveNet Communications Taiwan 16 - AS25220 7999 0.5% 615.3 -- GLOBALNOC-AS Averbo GmbH 17 - AS37080 1122 0.1% 561.0 -- connecteo-cameroun-as 18 - AS9974 2700 0.2% 540.0 -- KRA-AS-KR Korea Racing Association 19 - AS7907 1059 0.1% 529.5 -- NETWORLDTRON - Networldtron Corp 20 - AS10845 1014 0.1% 507.0 -- HITCOMASN - HITCOM CORP TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 148.247.0.0/17 13660 0.8% AS278 -- Red Academica de Mexico AS3548 -- Centro de Investigacion y de EstudiosAvanzados del 2 - 202.61.252.0/24 10562 0.6% AS10113 -- DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD AS23681 -- ITU-TRANSIT-AS-AP Paradox Digital ASN on behalf of IT Universe. To provide BGP interconnects to VIX and Paradox. 3 - 202.61.212.0/24 10562 0.6% AS10113 -- DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD AS23681 -- ITU-TRANSIT-AS-AP Paradox Digital ASN on behalf of IT Universe. To provide BGP interconnects to VIX and Paradox. 4 - 202.61.234.0/24 10562 0.6% AS10113 -- DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD AS23681 -- ITU-TRANSIT-AS-AP Paradox Digital ASN on behalf of IT Universe. To provide BGP interconnects to VIX and Paradox. 5 - 202.92.235.0/24 8091 0.5% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 6 - 85.197.100.0/22 7953 0.5% AS25220 -- GLOBALNOC-AS Averbo GmbH 7 - 63.211.68.0/22 7543 0.5% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 8 - 187.49.218.0/23 4748 0.3% AS28154 -- 9 - 198.140.43.0/24 4336 0.3% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 10 - 68.65.152.0/22 3544 0.2% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 11 - 206.184.16.0/24 3109 0.2% AS174 -- COGENT Cogent/PSI 12 - 202.153.174.0/24 3100 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 13 - 184.182.239.0/24 2642 0.2% AS19367 -- CAROUSEL-INDUSTRIES - Carousel Industries of North America Inc 14 - 195.2.198.0/23 2465 0.1% AS48561 -- AUTOMIR-AS NP Automir CJSC 15 - 216.126.136.0/22 2087 0.1% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 16 - 85.235.42.0/23 1826 0.1% AS25086 -- URALTC-AS CJSC "COMSTAR-regions" 17 - 213.170.59.0/24 1389 0.1% AS49600 -- LASEDA La Seda de Barcelona, S.A 18 - 211.173.99.0/24 1267 0.1% AS17874 -- NPC-AS-KR National Pension Corporation 19 - 208.54.82.0/24 1129 0.1% AS701 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 20 - 210.82.242.0/23 1114 0.1% AS9929 -- CNCNET-CN China Netcom Corp. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Feb 25 16:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 25 Feb 2011 22:00:00 GMT Subject: The Cidr Report Message-ID: <201102252200.p1PM00IP055408@wattle.apnic.net> This report has been generated at Fri Feb 25 21:12:10 2011 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 18-02-11 348860 204973 19-02-11 349174 204549 20-02-11 349198 204486 21-02-11 349125 204807 22-02-11 349245 205018 23-02-11 349677 204960 24-02-11 349881 204886 25-02-11 350116 205262 AS Summary 36871 Number of ASes in routing system 15575 Number of ASes announcing only one prefix 3690 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 108779520 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 25Feb11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 350137 205378 144759 41.3% All ASes AS6389 3690 262 3428 92.9% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 2593 408 2185 84.3% TWTC - tw telecom holdings, inc. AS4766 2421 904 1517 62.7% KIXS-AS-KR Korea Telecom AS19262 1787 285 1502 84.1% VZGNI-TRANSIT - Verizon Online LLC AS6478 1522 213 1309 86.0% ATT-INTERNET3 - AT&T Services, Inc. AS22773 1275 89 1186 93.0% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1420 343 1077 75.8% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS1785 1789 763 1026 57.4% AS-PAETEC-NET - PaeTec Communications, Inc. AS10620 1383 458 925 66.9% Telmex Colombia S.A. AS28573 1234 309 925 75.0% NET Servicos de Comunicao S.A. AS7545 1617 716 901 55.7% TPG-INTERNET-AP TPG Internet Pty Ltd AS18566 1447 589 858 59.3% COVAD - Covad Communications Co. AS18101 932 155 777 83.4% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS24560 1115 350 765 68.6% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7303 907 155 752 82.9% Telecom Argentina S.A. AS4808 1050 323 727 69.2% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS6503 1170 446 724 61.9% Axtel, S.A.B. de C.V. AS3356 1188 488 700 58.9% LEVEL3 Level 3 Communications AS11492 1283 583 700 54.6% CABLEONE - CABLE ONE, INC. AS8151 1356 676 680 50.1% Uninet S.A. de C.V. AS17488 940 268 672 71.5% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4780 869 230 639 73.5% SEEDNET Digital United Inc. AS17676 649 70 579 89.2% GIGAINFRA Softbank BB Corp. AS855 633 58 575 90.8% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS7552 663 122 541 81.6% VIETEL-AS-AP Vietel Corporation AS14420 641 105 536 83.6% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS9498 770 244 526 68.3% BBIL-AP BHARTI Airtel Ltd. AS3549 887 368 519 58.5% GBLX Global Crossing Ltd. AS22047 543 29 514 94.7% VTR BANDA ANCHA S.A. AS9443 570 75 495 86.8% INTERNETPRIMUS-AS-AP Primus Telecommunications Total 38344 10084 28260 73.7% Top 30 total Possible Bogus Routes 5.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 5.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 5.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 24.129.192.0/19 AS7922 COMCAST-7922 - Comcast Cable Communications, Inc. 37.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 37.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 37.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 41.57.192.0/18 AS22750 BCSNET 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 45.127.0.0/16 AS13767 DBANK - DataBank Holdings, Ltd. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.18.224.0/20 AS12129 123NET - 123.Net, Inc. 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.207.192.0/24 AS30304 64.207.193.0/24 AS30304 64.207.194.0/24 AS30304 64.207.195.0/24 AS30304 64.207.196.0/24 AS30304 64.207.197.0/24 AS30304 64.207.198.0/24 AS30304 64.207.200.0/24 AS30304 64.207.201.0/24 AS30304 64.207.202.0/24 AS30304 64.207.203.0/24 AS30304 64.207.204.0/24 AS30304 64.207.205.0/24 AS30304 64.207.206.0/24 AS30304 64.207.208.0/20 AS30304 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 72.22.32.0/19 AS33150 72.22.61.0/24 AS33150 72.22.62.0/24 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 110.173.64.0/19 AS37963 CNNIC-ALIBABA-CN-NET-AP Alibaba (China) Technology Co., Ltd. 115.42.28.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.30.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.40.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.42.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.44.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.47.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.48.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.49.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.50.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.51.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.52.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.53.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.54.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.55.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.56.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.57.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.58.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.59.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.61.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.62.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.63.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.54.160.0/24 AS38890 121.54.161.0/24 AS38890 121.54.162.0/24 AS38890 121.54.163.0/24 AS38890 121.54.164.0/24 AS38890 121.54.166.0/24 AS38890 121.54.167.0/24 AS38890 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 176.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 176.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 176.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 188.255.0.0/17 AS42610 NCNET-AS National Cable Networks 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.101.46.0/24 AS6503 Axtel, S.A.B. de C.V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.145.251.0/24 AS10026 PACNET Pacnet Global Ltd 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.15.4.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.15.5.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.175.231.0/24 AS19262 VZGNI-TRANSIT - Verizon Online LLC 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.24.73.0/24 AS26061 Equant Colombia 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.20.108.0/23 AS17885 JKTXLNET-AS-AP PT Excelcomindo Pratama 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.176.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.146.186.0/24 AS23655 SNAP-NZ-AS Snap Internet Limited 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.130.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.133.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.149.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.150.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.18.156.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.22.78.0/24 AS18117 HARBOURMSP-AU-AP Harbour MSP Pty. Ltd 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.27.123.0/24 AS4739 CIX-ADELAIDE-AS Internode Systems Pty Ltd 203.30.26.0/23 AS3491 BTN-ASN - Beyond The Network America, Inc. 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.10.232.0/21 AS33150 204.19.14.0/23 AS577 BACOM - Bell Canada 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 206.72.192.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.72.194.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.73.160.0/24 AS32767 208.78.165.0/24 AS16565 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.92.196.0/22 AS10929 NETELLIGENT - Netelligent Hosting Services Inc. 208.92.199.0/24 AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.10.235.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.10.236.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From jeroen at mompl.net Fri Feb 25 16:14:50 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Fri, 25 Feb 2011 14:14:50 -0800 Subject: A pragmatic issue with running out of v4 :) In-Reply-To: <20110225095432.GB15601@macbook.catpipe.net> References: <20110225095432.GB15601@macbook.catpipe.net> Message-ID: <4D6829DA.60609@mompl.net> Phil Regnauld wrote: > http://xkcd.com/865/ Ack, and how did I miss that? ;-) -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From santino.codispoti at gmail.com Fri Feb 25 19:02:51 2011 From: santino.codispoti at gmail.com (Santino Codispoti) Date: Fri, 25 Feb 2011 20:02:51 -0500 Subject: Contact for the Microsoft Teredo Cloud? In-Reply-To: <4D67EF37.7050505@unfix.org> References: <8C26A4FDAE599041A13EB499117D3C286B39EDDB@ex-mb-1.corp.atlasnetworks.us> <4D67EF37.7050505@unfix.org> Message-ID: What is Teredo Cloud? On Fri, Feb 25, 2011 at 1:04 PM, Jeroen Massar wrote: > On 2011-02-25 18:21, Nathan Eisenberg wrote: >> Does anyone know who to ping at Microsoft about their teredo >> platform? ?Their relay(s) doesn't/don't seem to have reachability to >> some bits of IPv6 space. > > (Afaik) Microsoft only operates Teredo servers, no Teredo Relays, those > are run by other networks. > > Greets, > ?Jeroen > > From tony at lava.net Fri Feb 25 19:22:49 2011 From: tony at lava.net (Antonio Querubin) Date: Fri, 25 Feb 2011 15:22:49 -1000 (HST) Subject: Contact for the Microsoft Teredo Cloud? In-Reply-To: References: <8C26A4FDAE599041A13EB499117D3C286B39EDDB@ex-mb-1.corp.atlasnetworks.us> <4D67EF37.7050505@unfix.org> Message-ID: On Fri, 25 Feb 2011, Santino Codispoti wrote: > What is Teredo Cloud? One could define this to be just the constellation of Teredo servers, relays, and clients if you want to make it more concrete. Antonio Querubin e-mail/xmpp: tony at lava.net From msa at latt.net Fri Feb 25 20:58:13 2011 From: msa at latt.net (Majdi S. Abbas) Date: Fri, 25 Feb 2011 19:58:13 -0700 Subject: A pragmatic issue with running out of v4 :) In-Reply-To: References: <20110225095432.GB15601@macbook.catpipe.net> <20110225100303.GA25850@vacation.karoshi.com.> <20110225135243.GA6008@roxanne.org> Message-ID: <20110226025813.GB70626@puck.nether.net> On Fri, Feb 25, 2011 at 09:27:35AM -0800, Owen DeLong wrote: > Apparently not: > > [owen-delongs-macbook-pro:~] owen% host www.skynet.net > www.skynet.net has address 66.165.165.53 > [owen-delongs-macbook-pro:~] owen% host -t aaaa www.skynet.net > www.skynet.net has no AAAA record Owen, Does this mean you won't be joining Skynet either? --msa From owen at delong.com Fri Feb 25 21:58:17 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 25 Feb 2011 19:58:17 -0800 Subject: A pragmatic issue with running out of v4 :) In-Reply-To: <20110226025813.GB70626@puck.nether.net> References: <20110225095432.GB15601@macbook.catpipe.net> <20110225100303.GA25850@vacation.karoshi.com.> <20110225135243.GA6008@roxanne.org> <20110226025813.GB70626@puck.nether.net> Message-ID: Sent from my iPad On Feb 25, 2011, at 6:58 PM, "Majdi S. Abbas" wrote: > On Fri, Feb 25, 2011 at 09:27:35AM -0800, Owen DeLong wrote: >> Apparently not: >> >> [owen-delongs-macbook-pro:~] owen% host www.skynet.net >> www.skynet.net has address 66.165.165.53 >> [owen-delongs-macbook-pro:~] owen% host -t aaaa www.skynet.net >> www.skynet.net has no AAAA record > > Owen, > > Does this mean you won't be joining Skynet either? > > --msa Not unless they want me to lead their v6 deployment. ;-) Owen (who did join NANOG once v6 worked) From rps at maine.edu Sat Feb 26 21:10:33 2011 From: rps at maine.edu (Ray Soucy) Date: Sat, 26 Feb 2011 22:10:33 -0500 Subject: Mac OS X 10.7, still no DHCPv6 Message-ID: With copies out to developers we now have confirmation that Apple still hasn't included DHCPv6 in the next release of OS X. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From randy at psg.com Sat Feb 26 23:05:47 2011 From: randy at psg.com (Randy Bush) Date: Sun, 27 Feb 2011 14:05:47 +0900 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: Message-ID: > With copies out to developers we now have confirmation that Apple > still hasn't included DHCPv6 in the next release of OS X. what is it about ipv6 which attracts religious nuts? randy From joelja at bogus.com Sat Feb 26 23:14:58 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 26 Feb 2011 21:14:58 -0800 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: Message-ID: <4D69DDD2.8050903@bogus.com> On 2/26/11 9:05 PM, Randy Bush wrote: >> With copies out to developers we now have confirmation that Apple >> still hasn't included DHCPv6 in the next release of OS X. > > what is it about ipv6 which attracts religious nuts? you sure it's not macos (says joel from a v6 enabled mac). > randy > From swmike at swm.pp.se Sat Feb 26 23:27:52 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 27 Feb 2011 06:27:52 +0100 (CET) Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <4D69DDD2.8050903@bogus.com> References: <4D69DDD2.8050903@bogus.com> Message-ID: On Sat, 26 Feb 2011, Joel Jaeggli wrote: > On 2/26/11 9:05 PM, Randy Bush wrote: >>> With copies out to developers we now have confirmation that Apple >>> still hasn't included DHCPv6 in the next release of OS X. >> >> what is it about ipv6 which attracts religious nuts? > > you sure it's not macos (says joel from a v6 enabled mac). On a more serious note, I can on my Ubuntu machine just "apt-get install wide-dhcpv6-client" and I get dhcpv6, it'll properly put stuff in resolv.conf for dns-over-ipv6 transport, even though the connection manager knows nothing about it, at least dual stack works properly. Can one do the equivalent easy addition to OSX? -- Mikael Abrahamsson email: swmike at swm.pp.se From joelja at bogus.com Sat Feb 26 23:40:56 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 26 Feb 2011 21:40:56 -0800 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: Message-ID: <4D69E3E8.5080404@bogus.com> You're going to have to perform stateless autconfiguration in ipv6 and provide an ipv4 nameserver at the very minimum for a long time, if you don't do it for macos you'll have to do it for windows xp... On 2/26/11 7:10 PM, Ray Soucy wrote: > With copies out to developers we now have confirmation that Apple > still hasn't included DHCPv6 in the next release of OS X. > From joelja at bogus.com Sat Feb 26 23:46:17 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 26 Feb 2011 21:46:17 -0800 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <4D69DDD2.8050903@bogus.com> Message-ID: <4D69E529.5090109@bogus.com> On 2/26/11 9:27 PM, Mikael Abrahamsson wrote: > On Sat, 26 Feb 2011, Joel Jaeggli wrote: > >> On 2/26/11 9:05 PM, Randy Bush wrote: >>>> With copies out to developers we now have confirmation that Apple >>>> still hasn't included DHCPv6 in the next release of OS X. >>> >>> what is it about ipv6 which attracts religious nuts? >> >> you sure it's not macos (says joel from a v6 enabled mac). > > On a more serious note, I can on my Ubuntu machine just "apt-get install > wide-dhcpv6-client" and I get dhcpv6, it'll properly put stuff in > resolv.conf for dns-over-ipv6 transport, even though the connection > manager knows nothing about it, at least dual stack works properly. > > Can one do the equivalent easy addition to OSX? You can, the actual integration issue is that network mangler (on ubuntu/fedora etal) and the osX airport connection manager will give up on a subnet on which they can't obtain an ipv4 address in prefernce to one where they can... this can also be worked around but it makes v6-only operation (Assuming that were desired, or even a good idea at this point) something that the majority of the users wouldn't be able to achive without the default behavior changing. From regnauld at nsrc.org Sun Feb 27 00:30:17 2011 From: regnauld at nsrc.org (Phil Regnauld) Date: Sun, 27 Feb 2011 07:30:17 +0100 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <4D69E3E8.5080404@bogus.com> References: <4D69E3E8.5080404@bogus.com> Message-ID: <20110227063017.GA2217@macbook.catpipe.net> Joel Jaeggli (joelja) writes: > You're going to have to perform stateless autconfiguration in ipv6 and > provide an ipv4 nameserver at the very minimum for a long time, if you > don't do it for macos you'll have to do it for windows xp... One of those operating systems is 10 years old and unmaintained... From patrick at ianai.net Sun Feb 27 00:53:50 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 27 Feb 2011 01:53:50 -0500 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <20110227063017.GA2217@macbook.catpipe.net> References: <4D69E3E8.5080404@bogus.com> <20110227063017.GA2217@macbook.catpipe.net> Message-ID: <24841A2D-AD78-4B73-AE71-62D6886D6391@ianai.net> On Feb 27, 2011, at 1:30, Phil Regnauld wrote: > Joel Jaeggli (joelja) writes: >> You're going to have to perform stateless autconfiguration in ipv6 and >> provide an ipv4 nameserver at the very minimum for a long time, if you >> don't do it for macos you'll have to do it for windows xp... > > One of those operating systems is 10 years old and unmaintained... Which one has more machines in production? -- TTFN, patrick From swmike at swm.pp.se Sun Feb 27 00:56:38 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 27 Feb 2011 07:56:38 +0100 (CET) Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <4D69E529.5090109@bogus.com> References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> Message-ID: On Sat, 26 Feb 2011, Joel Jaeggli wrote: > On 2/26/11 9:27 PM, Mikael Abrahamsson wrote: >> On Sat, 26 Feb 2011, Joel Jaeggli wrote: >> >>> On 2/26/11 9:05 PM, Randy Bush wrote: >>>>> With copies out to developers we now have confirmation that Apple >>>>> still hasn't included DHCPv6 in the next release of OS X. >>>> >>>> what is it about ipv6 which attracts religious nuts? >>> >>> you sure it's not macos (says joel from a v6 enabled mac). >> >> On a more serious note, I can on my Ubuntu machine just "apt-get install >> wide-dhcpv6-client" and I get dhcpv6, it'll properly put stuff in >> resolv.conf for dns-over-ipv6 transport, even though the connection >> manager knows nothing about it, at least dual stack works properly. >> >> Can one do the equivalent easy addition to OSX? > > You can, the actual integration issue is that network mangler (on > ubuntu/fedora etal) and the osX airport connection manager will give up > on a subnet on which they can't obtain an ipv4 address in prefernce to > one where they can... this can also be worked around but it makes > v6-only operation (Assuming that were desired, or even a good idea at > this point) something that the majority of the users wouldn't be able to > achive without the default behavior changing. I'm not that interested in v6 only, I'm after requiring DHCPv6 and disallowing SLAAC, which clients can use IPv6 then? List afaik: Can: Windows Vista/Win7 (default) Linux (with non-default software) *BSD (with non-default software) Probably: OSX (with non-default software) Can't: Windows XP Don't know: Symbian Android Apple iOS -- Mikael Abrahamsson email: swmike at swm.pp.se From dougb at dougbarton.us Sun Feb 27 01:13:00 2011 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 26 Feb 2011 23:13:00 -0800 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <20110227063017.GA2217@macbook.catpipe.net> References: <4D69E3E8.5080404@bogus.com> <20110227063017.GA2217@macbook.catpipe.net> Message-ID: <4D69F97C.6010801@dougbarton.us> On 02/26/2011 22:30, Phil Regnauld wrote: > Joel Jaeggli (joelja) writes: >> You're going to have to perform stateless autconfiguration in ipv6 and >> provide an ipv4 nameserver at the very minimum for a long time, if you >> don't do it for macos you'll have to do it for windows xp... > > One of those operating systems is 10 years old and unmaintained... If you're talking about XP, I still get patches from Microsoft, and I've heard reliable reports that they plan to keep supporting it until 2014. If that's true you can expect that the actual time when it becomes a non-issue will be at least 2020. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From joelja at bogus.com Sun Feb 27 01:32:42 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 26 Feb 2011 23:32:42 -0800 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> Message-ID: <4D69FE1A.7030401@bogus.com> On 2/26/11 10:56 PM, Mikael Abrahamsson wrote: > On Sat, 26 Feb 2011, Joel Jaeggli wrote: > >> On 2/26/11 9:27 PM, Mikael Abrahamsson wrote: >>> On Sat, 26 Feb 2011, Joel Jaeggli wrote: >>> >>>> On 2/26/11 9:05 PM, Randy Bush wrote: >>>>>> With copies out to developers we now have confirmation that Apple >>>>>> still hasn't included DHCPv6 in the next release of OS X. >>>>> >>>>> what is it about ipv6 which attracts religious nuts? >>>> >>>> you sure it's not macos (says joel from a v6 enabled mac). >>> >>> On a more serious note, I can on my Ubuntu machine just "apt-get install >>> wide-dhcpv6-client" and I get dhcpv6, it'll properly put stuff in >>> resolv.conf for dns-over-ipv6 transport, even though the connection >>> manager knows nothing about it, at least dual stack works properly. >>> >>> Can one do the equivalent easy addition to OSX? >> >> You can, the actual integration issue is that network mangler (on >> ubuntu/fedora etal) and the osX airport connection manager will give up >> on a subnet on which they can't obtain an ipv4 address in prefernce to >> one where they can... this can also be worked around but it makes >> v6-only operation (Assuming that were desired, or even a good idea at >> this point) something that the majority of the users wouldn't be able to >> achive without the default behavior changing. > > I'm not that interested in v6 only, I'm after requiring DHCPv6 and > disallowing SLAAC, which clients can use IPv6 then? > > List afaik: > > Can: > Windows Vista/Win7 (default) > Linux (with non-default software) > *BSD (with non-default software) > > Probably: > > OSX (with non-default software) > > Can't: > > Windows XP also can't query an ipv6 nameserver, meaning it has to obtain one via ipv4. > Don't know: > > Symbian has it > Android does not have it per the currently open ticket/rfe. > Apple iOS > From tore.anderson at redpill-linpro.com Sun Feb 27 02:44:52 2011 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Sun, 27 Feb 2011 09:44:52 +0100 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> Message-ID: <4D6A0F04.6050709@redpill-linpro.com> * Mikael Abrahamsson > On Sat, 26 Feb 2011, Joel Jaeggli wrote: > >> You can, the actual integration issue is that network mangler (on >> ubuntu/fedora etal) and the osX airport connection manager will give up >> on a subnet on which they can't obtain an ipv4 address in prefernce to >> one where they can... this can also be worked around but it makes >> v6-only operation (Assuming that were desired, or even a good idea at >> this point) something that the majority of the users wouldn't be able to >> achive without the default behavior changing. > > I'm not that interested in v6 only, I'm after requiring DHCPv6 and > disallowing SLAAC, which clients can use IPv6 then? > > List afaik: > > Can: > Windows Vista/Win7 (default) > Linux (with non-default software) > *BSD (with non-default software) Actually, with Linux, you do not need any non-default software. For quite some time now, the GNOME NetworkManager have supported most IPv6 flavours: * Static addressing, * SLAAC (including the RDNSS option), * Information-only DHCPv6, * Stateful DHCPv6, and * Any combination of the above. The problem is only that IPv6 support is not enabled in the default connection profile. In the default case, the kernel will on its own do SLAAC, but you won't get any IPv6 resolvers used, nor will it be able to connect to a IPv6-only network, due to the fact that NetworkManager will shut down the interface if it do not get any IPv4 connectivity (at least on wireless connections). See: https://bugzilla.redhat.com/show_bug.cgi?id=538499 Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From kauer at biplane.com.au Sun Feb 27 03:42:30 2011 From: kauer at biplane.com.au (Karl Auer) Date: Sun, 27 Feb 2011 20:42:30 +1100 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> Message-ID: <1298799750.15754.2.camel@karl> On Sun, 2011-02-27 at 07:56 +0100, Mikael Abrahamsson wrote: > I'm not that interested in v6 only, I'm after requiring DHCPv6 and > disallowing SLAAC, which clients can use IPv6 then? > > List afaik: > [...] > Can't: > Windows XP > [...] The Dibbler DHCPv6 client(non-standard software) works on XP (I think). Not sure about disallowing SLAAC. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From randy at psg.com Sun Feb 27 05:27:49 2011 From: randy at psg.com (Randy Bush) Date: Sun, 27 Feb 2011 20:27:49 +0900 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <4D69E3E8.5080404@bogus.com> References: <4D69E3E8.5080404@bogus.com> Message-ID: > You're going to have to perform stateless autconfiguration in ipv6 and > provide an ipv4 nameserver at the very minimum for a long time apple is gonna look very very st00pid on world ipv6 day. and a bunch of folk are considering not turning things off after that day. randy From randy at psg.com Sun Feb 27 06:21:07 2011 From: randy at psg.com (Randy Bush) Date: Sun, 27 Feb 2011 21:21:07 +0900 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <4D69E3E8.5080404@bogus.com> Message-ID: >> You're going to have to perform stateless autconfiguration in ipv6 >> and provide an ipv4 nameserver at the very minimum for a long time > apple is gonna look very very st00pid on world ipv6 day. and a bunch > of folk are considering not turning things off after that day. on second thought, guess where the support calls are gonna go. our customer support lines, because we deliver zipless ipv6. NOC: are you running a macintosh? User: yes, how did you guess? NOC: because it is broken. get vista. randy From tshaw at oitc.com Sun Feb 27 06:39:18 2011 From: tshaw at oitc.com (TR Shaw) Date: Sun, 27 Feb 2011 07:39:18 -0500 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> Message-ID: <347737D7-35C0-476B-8852-CA8B404BC7D6@oitc.com> On Feb 27, 2011, at 1:56 AM, Mikael Abrahamsson wrote: > On Sat, 26 Feb 2011, Joel Jaeggli wrote: > >> On 2/26/11 9:27 PM, Mikael Abrahamsson wrote: >>> On Sat, 26 Feb 2011, Joel Jaeggli wrote: >>> >>>> On 2/26/11 9:05 PM, Randy Bush wrote: >>>>>> With copies out to developers we now have confirmation that Apple >>>>>> still hasn't included DHCPv6 in the next release of OS X. >>>>> >>>>> what is it about ipv6 which attracts religious nuts? >>>> >>>> you sure it's not macos (says joel from a v6 enabled mac). >>> >>> On a more serious note, I can on my Ubuntu machine just "apt-get install >>> wide-dhcpv6-client" and I get dhcpv6, it'll properly put stuff in >>> resolv.conf for dns-over-ipv6 transport, even though the connection >>> manager knows nothing about it, at least dual stack works properly. >>> >>> Can one do the equivalent easy addition to OSX? >> >> You can, the actual integration issue is that network mangler (on >> ubuntu/fedora etal) and the osX airport connection manager will give up >> on a subnet on which they can't obtain an ipv4 address in prefernce to >> one where they can... this can also be worked around but it makes >> v6-only operation (Assuming that were desired, or even a good idea at >> this point) something that the majority of the users wouldn't be able to >> achive without the default behavior changing. > > I'm not that interested in v6 only, I'm after requiring DHCPv6 and disallowing SLAAC, which clients can use IPv6 then? > > List afaik: > > Can: > Windows Vista/Win7 (default) > Linux (with non-default software) > *BSD (with non-default software) > > Probably: > > OSX (with non-default software) > > Can't: > > Windows XP > > Don't know: > > Symbian > Android > Apple iOS > Mikael, try: http://sourceforge.net/projects/wide-dhcpv6/ http://wouter.horre.be/doc/stateless-dhcpv6-on-mac-os-x or http://klub.com.pl/dhcpv6/ There are others out there. I prefer wide for now. Works on 10.6. Haven't tried it on 10.5. Tom From tshaw at oitc.com Sun Feb 27 07:05:41 2011 From: tshaw at oitc.com (TR Shaw) Date: Sun, 27 Feb 2011 08:05:41 -0500 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <4D69E3E8.5080404@bogus.com> Message-ID: <87AD0BA7-65EA-472B-A7DF-6A4D67A4154A@oitc.com> On Feb 27, 2011, at 6:27 AM, Randy Bush wrote: >> You're going to have to perform stateless autconfiguration in ipv6 and >> provide an ipv4 nameserver at the very minimum for a long time > > apple is gonna look very very st00pid on world ipv6 day. and a bunch of > folk are considering not turning things off after that day. Now why would you say that, Randy? My home is dual stacked with a IPv6 tunnel to HE at my router. All off the shelf. No special config. All Apple. So whats the beef? Tom From rps at maine.edu Sun Feb 27 07:56:33 2011 From: rps at maine.edu (Ray Soucy) Date: Sun, 27 Feb 2011 08:56:33 -0500 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <87AD0BA7-65EA-472B-A7DF-6A4D67A4154A@oitc.com> References: <4D69E3E8.5080404@bogus.com> <87AD0BA7-65EA-472B-A7DF-6A4D67A4154A@oitc.com> Message-ID: SLAAC is fine (even great) for small environments. For a lot of enterprise (or in our case, academic) networks you really want the central control of what addresses hosts get. Saw some mention of being unsure that it was possible to disable SLAAC. Every OS I've tested so far respects the A flag (which signals whether a prefix can be used for SLAAC or not) of an RA, so of course you can disable SLAAC (right from the prefix you advertise). Apple has said before that they don't want to use DHCPv6 because IPv6 should be "easy". I'm not really sure what about DHCPv6 is difficult. Mac OS X 10.7 does support RDNSS (RFC 5001) so it is able to get DNS server information in an IPv6-only environment. Of course nobody else has implemented that yet, making Apple a "special case" host once again (I don't even think Cisco supports the option in their T series yet). Once again, SLAAC and RDNSS is great for quick, small, plug-and-play networks, and maybe even the opposite end: very very large (mobile) networks. But DHCPv6 is a powerful tool and one that shouldn't be thrown out. With SLAAC, as soon as you enable it every host on a network starts talking IPv6, by disabling SLAAC and using DHCPv6, you can selectively respond to hosts and do a phased deployment, enabling IPv6 on a per-host basis. Even though we have good native IPv6 available, we've adopted a DHCPv6 only deployment model. It works great for Windows and Linux systems, and even Android devices (I believe the iPhone even supports DHCPv6), really too bad that OS X doesn't support it because on our network it means they won't be getting IPv6 anytime soon. On Sun, Feb 27, 2011 at 8:05 AM, TR Shaw wrote: > > On Feb 27, 2011, at 6:27 AM, Randy Bush wrote: > >>> You're going to have to perform stateless autconfiguration in ipv6 and >>> provide an ipv4 nameserver at the very minimum for a long time >> >> apple is gonna look very very st00pid on world ipv6 day. ?and a bunch of >> folk are considering not turning things off after that day. > > Now why would you say that, Randy? ?My home is dual stacked with a IPv6 tunnel to HE at my router. All off the shelf. No special config. All Apple. So whats the beef? > > Tom > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From cra at WPI.EDU Sun Feb 27 08:03:21 2011 From: cra at WPI.EDU (Chuck Anderson) Date: Sun, 27 Feb 2011 09:03:21 -0500 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <4D69E529.5090109@bogus.com> References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> Message-ID: <20110227140321.GM9424@angus.ind.WPI.EDU> On Sat, Feb 26, 2011 at 09:46:17PM -0800, Joel Jaeggli wrote: > On 2/26/11 9:27 PM, Mikael Abrahamsson wrote: > > On a more serious note, I can on my Ubuntu machine just "apt-get install > > wide-dhcpv6-client" and I get dhcpv6, it'll properly put stuff in > > resolv.conf for dns-over-ipv6 transport, even though the connection > > manager knows nothing about it, at least dual stack works properly. > > > > Can one do the equivalent easy addition to OSX? > > You can, the actual integration issue is that network mangler (on > ubuntu/fedora etal) and the osX airport connection manager will give up > on a subnet on which they can't obtain an ipv4 address in prefernce to > one where they can... this can also be worked around but it makes > v6-only operation (Assuming that were desired, or even a good idea at > this point) something that the majority of the users wouldn't be able to > achive without the default behavior changing. NetworkManager on Fedora fully supports IPv6 now, including DHCPv6. You can easily configure it to require an IPv4 address or an IPv6 address or both to consider the connection successfull. From leigh.porter at ukbroadband.com Sun Feb 27 08:47:37 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Sun, 27 Feb 2011 14:47:37 +0000 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <20110227140321.GM9424@angus.ind.WPI.EDU> References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227140321.GM9424@angus.ind.WPI.EDU> Message-ID: Does anybody have anything neat to keep logs of what host gets what ipv6 address in an SLAAC environment? This is often required for legislation compliance. DHCP does this well. -- Leigh Porter On 27 Feb 2011, at 14:04, "Chuck Anderson" wrote: > On Sat, Feb 26, 2011 at 09:46:17PM -0800, Joel Jaeggli wrote: >> On 2/26/11 9:27 PM, Mikael Abrahamsson wrote: >>> On a more serious note, I can on my Ubuntu machine just "apt-get install >>> wide-dhcpv6-client" and I get dhcpv6, it'll properly put stuff in >>> resolv.conf for dns-over-ipv6 transport, even though the connection >>> manager knows nothing about it, at least dual stack works properly. >>> >>> Can one do the equivalent easy addition to OSX? >> >> You can, the actual integration issue is that network mangler (on >> ubuntu/fedora etal) and the osX airport connection manager will give up >> on a subnet on which they can't obtain an ipv4 address in prefernce to >> one where they can... this can also be worked around but it makes >> v6-only operation (Assuming that were desired, or even a good idea at >> this point) something that the majority of the users wouldn't be able to >> achive without the default behavior changing. > > NetworkManager on Fedora fully supports IPv6 now, including DHCPv6. > You can easily configure it to require an IPv4 address or an IPv6 > address or both to consider the connection successfull. > From patrick at zill.net Sun Feb 27 09:16:13 2011 From: patrick at zill.net (Patrick Giagnocavo) Date: Sun, 27 Feb 2011 10:16:13 -0500 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: Message-ID: <4D6A6ABD.2040000@zill.net> On 2/27/2011 12:05 AM, Randy Bush wrote: >> With copies out to developers we now have confirmation that Apple >> still hasn't included DHCPv6 in the next release of OS X. > > what is it about ipv6 which attracts religious nuts? > > randy > > OSX beta (fanbois + journalists who get paid by word) + IPv6 = perfect storm --Patrick From swmike at swm.pp.se Sun Feb 27 09:22:06 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 27 Feb 2011 16:22:06 +0100 (CET) Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227140321.GM9424@angus.ind.WPI.EDU> Message-ID: On Sun, 27 Feb 2011, Leigh Porter wrote: > Does anybody have anything neat to keep logs of what host gets what ipv6 > address in an SLAAC environment? You'd have to correlate ND information in the router to some kind of record of who has what MAC address at any given time. With SLAAC the host doesn't "get" an IPv6 address, it "takes" one. > This is often required for legislation compliance. DHCP does this well. Which is one of the reasons why some of us want DHCPv6 support in hosts. -- Mikael Abrahamsson email: swmike at swm.pp.se From rdobbins at arbor.net Sun Feb 27 09:25:25 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 27 Feb 2011 15:25:25 +0000 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227140321.GM9424@angus.ind.WPI.EDU> Message-ID: <72B7B4EA-0E25-4D31-B9A1-653308E4D675@arbor.net> On Feb 27, 2011, at 10:22 PM, Mikael Abrahamsson wrote: > Which is one of the reasons why some of us want DHCPv6 support in hosts. Also for traceback when hunting down compromised/abusive hosts. ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From sthaug at nethelp.no Sun Feb 27 09:35:43 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sun, 27 Feb 2011 16:35:43 +0100 (CET) Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <20110227140321.GM9424@angus.ind.WPI.EDU> Message-ID: <20110227.163543.74686837.sthaug@nethelp.no> > > Does anybody have anything neat to keep logs of what host gets what ipv6 > > address in an SLAAC environment? > > You'd have to correlate ND information in the router to some kind of > record of who has what MAC address at any given time. With SLAAC the host > doesn't "get" an IPv6 address, it "takes" one. > > > This is often required for legislation compliance. DHCP does this well. > > Which is one of the reasons why some of us want DHCPv6 support in hosts. Agreed. In our environment Mac OSX hosts will either have to get the necessary DHCPv6 functionality, or the customer will have to buy a router (which can then get DHCPv6 PD from us, and offer RA/SLAAC on the LAN side). SLAAC for our ISP customers just won't happen, for a lot of reasons. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From leigh.porter at ukbroadband.com Sun Feb 27 10:45:53 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Sun, 27 Feb 2011 16:45:53 +0000 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <20110227.163543.74686837.sthaug@nethelp.no> References: <20110227140321.GM9424@angus.ind.WPI.EDU> <20110227.163543.74686837.sthaug@nethelp.no> Message-ID: <593A29C5-71BE-4871-93C5-112544ED11AA@ukbroadband.com> On 27 Feb 2011, at 15:35, sthaug at nethelp.no wrote: >>> Does anybody have anything neat to keep logs of what host gets what ipv6 >>> address in an SLAAC environment? >> >> You'd have to correlate ND information in the router to some kind of >> record of who has what MAC address at any given time. With SLAAC the host >> doesn't "get" an IPv6 address, it "takes" one. >> >>> This is often required for legislation compliance. DHCP does this well. >> >> Which is one of the reasons why some of us want DHCPv6 support in hosts. > > Agreed. In our environment Mac OSX hosts will either have to get the > necessary DHCPv6 functionality, or the customer will have to buy a > router (which can then get DHCPv6 PD from us, and offer RA/SLAAC on > the LAN side). > > SLAAC for our ISP customers just won't happen, for a lot of reasons. I really do not get the lack of DHCPv6, the Apple 'it should be easy' is all very well and good, but it really does not help those people who have to run the networks at all. So for the foreseeable future SLAAC seems to be a requirement especially for WiFi operators for example who will have to support a multitude of unknown hosts. Has anybody found a usable method of achieving IPv6 address logs for such networks or will I just have to write some awful sniffer that spits out into a database that later on I'll have to correlate with WiFi AP RADIUS logs? -- Leigh Porter From tony at lava.net Sun Feb 27 13:07:55 2011 From: tony at lava.net (Antonio Querubin) Date: Sun, 27 Feb 2011 09:07:55 -1000 (HST) Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227140321.GM9424@angus.ind.WPI.EDU> Message-ID: On Sun, 27 Feb 2011, Mikael Abrahamsson wrote: > On Sun, 27 Feb 2011, Leigh Porter wrote: > >> Does anybody have anything neat to keep logs of what host gets what ipv6 >> address in an SLAAC environment? > > You'd have to correlate ND information in the router to some kind of record > of who has what MAC address at any given time. With SLAAC the host doesn't > "get" an IPv6 address, it "takes" one. > >> This is often required for legislation compliance. DHCP does this well. > > Which is one of the reasons why some of us want DHCPv6 support in hosts. So how does DHCP prevent a host from just taking or hijacking an IP address? Antonio Querubin e-mail/xmpp: tony at lava.net From leigh.porter at ukbroadband.com Sun Feb 27 13:17:20 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Sun, 27 Feb 2011 19:17:20 +0000 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227140321.GM9424@angus.ind.WPI.EDU> Message-ID: On 27 Feb 2011, at 19:07, Antonio Querubin wrote: > On Sun, 27 Feb 2011, Mikael Abrahamsson wrote: > >> On Sun, 27 Feb 2011, Leigh Porter wrote: >> >>> Does anybody have anything neat to keep logs of what host gets what ipv6 address in an SLAAC environment? >> >> You'd have to correlate ND information in the router to some kind of record of who has what MAC address at any given time. With SLAAC the host doesn't "get" an IPv6 address, it "takes" one. >> >>> This is often required for legislation compliance. DHCP does this well. >> >> Which is one of the reasons why some of us want DHCPv6 support in hosts. > > So how does DHCP prevent a host from just taking or hijacking an IP address? > > Antonio Querubin > e-mail/xmpp: tony at lava.net > You can have devices that peek at the DHCP messages and then open filters so that you at least know that any host that pops up on the network has used DHCP to obtain an IP address. Now you cannot usually prevent somebody from later hijacking that IP address using a fake MAC unless you do something else as well but at least you have something of a statefull relationship between an host and the IP address it uses. -- Leigh Porter From richard.barnes at gmail.com Sun Feb 27 13:53:23 2011 From: richard.barnes at gmail.com (Richard Barnes) Date: Sun, 27 Feb 2011 14:53:23 -0500 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227140321.GM9424@angus.ind.WPI.EDU> Message-ID: In fairness, said device can do the same sort of inspection of SLAAC traffic. It just looks at neighbor discovery messages instead of DHCP messages. On Sun, Feb 27, 2011 at 2:17 PM, Leigh Porter wrote: > > > On 27 Feb 2011, at 19:07, Antonio Querubin wrote: > >> On Sun, 27 Feb 2011, Mikael Abrahamsson wrote: >> >>> On Sun, 27 Feb 2011, Leigh Porter wrote: >>> >>>> Does anybody have anything neat to keep logs of what host gets what ipv6 address in an SLAAC environment? >>> >>> You'd have to correlate ND information in the router to some kind of record of who has what MAC address at any given time. With SLAAC the host doesn't "get" an IPv6 address, it "takes" one. >>> >>>> This is often required for legislation compliance. DHCP does this well. >>> >>> Which is one of the reasons why some of us want DHCPv6 support in hosts. >> >> So how does DHCP prevent a host from just taking or hijacking an IP address? >> >> Antonio Querubin >> e-mail/xmpp: ?tony at lava.net >> > > You can have devices that peek at the DHCP messages and then open filters so that you at least know that any host that pops up on the network has used DHCP to obtain an IP address. > > Now you cannot usually prevent somebody from later hijacking that IP address using a fake MAC unless you do something else as well but at least you have something of a statefull relationship between an host and the IP address it uses. > > > -- > Leigh Porter > From marka at isc.org Sun Feb 27 14:22:08 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 28 Feb 2011 07:22:08 +1100 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: Your message of "Sun, 27 Feb 2011 14:47:37 -0000." References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227140321.GM9424@angus.ind.WPI.EDU> Message-ID: <20110227202208.804C6B0DF80@drugs.dv.isc.org> In message , "Leigh Porte r" writes: > > > Does anybody have anything neat to keep logs of what host gets what ipv6 add= > ress in an SLAAC environment? > > This is often required for legislation compliance. DHCP does this well. Does it really matter what address a customer has as long as it comes from the /64, /56 or /48 assigned to them? Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From simon at slimey.org Sun Feb 27 14:45:12 2011 From: simon at slimey.org (Simon Lockhart) Date: Sun, 27 Feb 2011 20:45:12 +0000 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <20110227202208.804C6B0DF80@drugs.dv.isc.org> References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227202208.804C6B0DF80@drugs.dv.isc.org> Message-ID: <20110227204511.GM27578@virtual.bogons.net> On Mon Feb 28, 2011 at 07:22:08AM +1100, Mark Andrews wrote: > > This is often required for legislation compliance. DHCP does this well. > > Does it really matter what address a customer has as long as it comes from > the /64, /56 or /48 assigned to them? You are assuming an access technology that lends itself to subnet-per-customer. I run a network with 50,000+ end users using ethernet-based access to the user's room. In IPv4, I run 1 or more subnets per building (depending on the number of rooms in the build). I use DHCP to assign IPs, and record the DHCP assignments allow me to trace users in the event of abuse complaints. I use DHCP Option82 to allow me to correlate multiple devices in a user's room. I feed the DHCP information into my bandwidth management platform to enforce different levels (i.e. speeds) of service per user depending on what they've purchased. I have yet to come up with a viable solution to do all of the above in IPv6 without using DHCPv6. At the moment, that means that OSX users are not going to get IPv6. Simon For IPv4, I use DHCP to From sthaug at nethelp.no Sun Feb 27 14:58:07 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sun, 27 Feb 2011 21:58:07 +0100 (CET) Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: Message-ID: <20110227.215807.74719328.sthaug@nethelp.no> > In fairness, said device can do the same sort of inspection of SLAAC > traffic. It just looks at neighbor discovery messages instead of DHCP > messages. > > Any known (existing) or planned implementations of this? Steinar Haug, Nethelp consulting, sthaug at nethelp.no From richard.barnes at gmail.com Sun Feb 27 15:00:42 2011 From: richard.barnes at gmail.com (Richard Barnes) Date: Sun, 27 Feb 2011 16:00:42 -0500 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <20110227.215807.74719328.sthaug@nethelp.no> References: <20110227.215807.74719328.sthaug@nethelp.no> Message-ID: >> In fairness, said device can do the same sort of inspection of SLAAC >> traffic. ?It just looks at neighbor discovery messages instead of DHCP >> messages. >> >> > > Any known (existing) or planned implementations of this? None that you can buy off the shelf. I understand that Tsinghua University in Beijing has prototype code running on several types of switches. From mpalmer at hezmatt.org Sun Feb 27 15:06:29 2011 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Mon, 28 Feb 2011 08:06:29 +1100 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <4D69E3E8.5080404@bogus.com> <87AD0BA7-65EA-472B-A7DF-6A4D67A4154A@oitc.com> Message-ID: <20110227210629.GS6259@hezmatt.org> On Sun, Feb 27, 2011 at 08:56:33AM -0500, Ray Soucy wrote: > Mac OS X 10.7 does support RDNSS (RFC 5001) so it is able to get DNS > server information in an IPv6-only environment. Of course nobody else > has implemented that yet, making Apple a "special case" host once > again (I don't even think Cisco supports the option in their T series > yet). radvd and rdnssd work together on Linux nicely to provide RDNSS support. Works a treat. - Matt From fernando at gont.com.ar Sun Feb 27 15:05:46 2011 From: fernando at gont.com.ar (Fernando Gont) Date: Sun, 27 Feb 2011 18:05:46 -0300 Subject: Weekend Gedankenexperiment - The Kill Switch In-Reply-To: <4D4EF1D1.7050708@dcrocker.net> References: <8325481.4769.1296790989030.JavaMail.root@benjamin.baylink.com> <96503CEA-C922-47A6-9691-FCF157DF15D5@internode.com.au> <10A940BA-6D90-4663-B942-5FFF2CB49D7A@internode.com.au> <4D4BAD13.9090301@gmail.com> <88BC6885D33A9D42A1CCB45E8749525E013CBC58@pigeon.sandiego.nextlevelinternet.com> <72609B8A-05D2-4039-85C4-A0578B9E6911@cisco.com> <4D4E0361.3060505@dcrocker.net> <19790.60580.225216.4089@world.std.com> <4D4EF1D1.7050708@dcrocker.net> Message-ID: <4D6ABCAA.80108@gont.com.ar> Hi, Dave, On 06/02/2011 04:09 p.m., Dave CROCKER wrote: > Sorry, but I think the technical implications of a goal to survive > 'hostile battlefield conditions' versus 'nuclear attack' are (small pun) > massively different. Hence I think the actual language used matters. > > And the fact that the common language around the net during the '70s was > the former and not the latter matters. Which is why it would be helpful > to get some credible documentation about use of the latter. How about: Clark, D. 1988. "The Design Philosophy of the DARPA Internet Protocols". Computer Communication Review, Vol. 18, No. 4, 1988. ? Thanks, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From powerzone7 at gmail.com Sun Feb 27 15:08:28 2011 From: powerzone7 at gmail.com (powerzone7 at gmail.com) Date: Sun, 27 Feb 2011 16:08:28 -0500 Subject: NTT as a service provider in the US Message-ID: Anyone have any thoughts on NTT as a service provider in the US ? Anyone currently or previously using them please chime in. thank you From tkapela at gmail.com Sun Feb 27 15:20:18 2011 From: tkapela at gmail.com (Anton Kapela) Date: Sun, 27 Feb 2011 15:20:18 -0600 Subject: SLA for voice and video over IP/MPLS In-Reply-To: References: Message-ID: On Thu, Feb 24, 2011 at 6:10 PM, Diogo Montagner wrote: > Hello, > > I am looking for industry standard parameters to base the SLA of one > network regarding to voice, video and data application. 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. > Which are the the accepted values for jiiter, delay, latency and > packet loss for voice, video and data in a IP/MPLS ? This question is being framed backwards -- an engineer should ask ask what the particular codecs can tollerate, then seek out networks which can deliver on those needs. If the a/v equipment vendor can't tell the customer or user what sort of network is required, I recommend selecting a new a/v vendor. In any event, audio codecs such as ILBC, g729, and 722 are well positioned for 'loss concealment' mechanisms in the decoders, masking some reasonable amount of loss. This has been exhaustively tested, and the data is readily available [0]. Video codecs that degrade gracefully are also fairly common, though the industry focus seems to be on concealing loss for generic real-time data, and offloading this work onto a different abstraction. One example would be packetized 'forward error correction' schemes, which can be configured or adapted to nearly arbitrarily 'high' loss rates (eg. "ProMPEG" [1] and related work). If the a/v system in question can support FEC of any sort, then this should substantially reduce ones transport-layer loss rate concerns. -Tk [0]: http://www.vocal.com/speech_coders/psqm_data.html [1]: http://www.ispa-sat.ru/info/Inside%20Pro-MPEG%20FEC%20(IBC)%20.pdf From franck at genius.com Sun Feb 27 15:25:45 2011 From: franck at genius.com (Franck Martin) Date: Sun, 27 Feb 2011 16:25:45 -0500 (EST) Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <20110227210629.GS6259@hezmatt.org> Message-ID: <7187091.752.1298841943188.JavaMail.franck@franck-martins-macbook-pro.local> Yes I don't understand why we need DHCPv6, true RD did not have DNS information to pass, but that is fixed, no? ----- Original Message ----- From: "Matthew Palmer" To: nanog at nanog.org Sent: Sunday, 27 February, 2011 4:06:29 PM Subject: Re: Mac OS X 10.7, still no DHCPv6 On Sun, Feb 27, 2011 at 08:56:33AM -0500, Ray Soucy wrote: > Mac OS X 10.7 does support RDNSS (RFC 5001) so it is able to get DNS > server information in an IPv6-only environment. Of course nobody else > has implemented that yet, making Apple a "special case" host once > again (I don't even think Cisco supports the option in their T series > yet). radvd and rdnssd work together on Linux nicely to provide RDNSS support. Works a treat. - Matt From vixie at isc.org Sun Feb 27 15:48:49 2011 From: vixie at isc.org (Paul Vixie) Date: Sun, 27 Feb 2011 21:48:49 +0000 Subject: NTT as a service provider in the US In-Reply-To: (powerzone7@gmail.com's message of "Sun, 27 Feb 2011 16:08:28 -0500") References: Message-ID: "powerzone7 at gmail.com" writes: > Anyone have any thoughts on NTT as a service provider in the US ? Anyone > currently or previously using them please chime in. can't do it. i have thoughts but i won't answer a freemail address. i'm taking the time to say so because your post looks like trolling to me. if you ask again with a real domain name and a real meatspace signature, i'll be happy to say what i think about ntt as a service provider in the US. -- Paul Vixie KI6YSY From jackson.tim at gmail.com Sun Feb 27 15:51:35 2011 From: jackson.tim at gmail.com (Tim Jackson) Date: Sun, 27 Feb 2011 15:51:35 -0600 Subject: SLA for voice and video over IP/MPLS Message-ID: For video, the SCTE 168 doc covers this.. (first hit on google) Its fairly strict, but in depth. On Feb 24, 2011 6:12 PM, "Diogo Montagner" wrote: From rps at maine.edu Sun Feb 27 16:16:47 2011 From: rps at maine.edu (Ray Soucy) Date: Sun, 27 Feb 2011 17:16:47 -0500 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: Message-ID: The topic should likely be re-written to "DHCPv6 expected in OS X 10.7" with rainbows, stars, and prancing unicorns. Apparently I was misinformed. Several people with access to the preview had informed me that DHCPv6 was not in 10.7. This seems to have upset at least one Apple engineer who dropped the NDA bomb on me; while he didn't confirm it was there, he did imply it, and it did make me have people give a second look. (I tried to get him to admit it but he's obviously been through Apple secret keeping training). After having others look more closely it seems that DHCPv6, or the beginnings of DHCPv6 support are in 10.7, though there are no UI options to indicate this, and a reboot of the OS seems to be required before it will make a request (?) Hopefully that is also wrong, or is being worked on. Mainly, the user should have an easy way to determine their DUID. So it looks like the next release of OS X might have a full implementation of DHCPv6 and RDNSS to boot. If that's the case then I applaud Apple at finally delivering on DHCPv6; it's been requested for at least a few years now. It will be interesting to see how this looks when we get closer to a release. Will also be interesting to see some test cases for IPv6 configuration (e.g. can a Mac get both SLAAC and DHCPv6 addresses, if it follows the standard it should be able to). My apologies to Apple and the team that has been working hard on DHCPv6 implementation; If anything the post has shown you that your work is not only worthwhile but also necessary and will be widely appreciated. Funny how Apple keeps everything a secret then get worked up when people don't have correct information to go by ;-) For context, this was incorrect: On Sat, Feb 26, 2011 at 10:10 PM, Ray Soucy wrote: > With copies out to developers we now have confirmation that Apple > still hasn't included DHCPv6 in the next release of OS X. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From kauer at biplane.com.au Sun Feb 27 16:24:58 2011 From: kauer at biplane.com.au (Karl Auer) Date: Mon, 28 Feb 2011 09:24:58 +1100 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <7187091.752.1298841943188.JavaMail.franck@franck-martins-macbook-pro.local> References: <7187091.752.1298841943188.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <1298845498.2109.2.camel@karl> On Sun, 2011-02-27 at 16:25 -0500, Franck Martin wrote: > Yes I don't understand why we need DHCPv6, true RD did not have DNS > information to pass, but that is fixed, no? Well - that draft very recently (i.e., only a few months, if that) became standards track, so it'll be a while before it's built into everything as a matter of course, but yes, it's "fixed". RFC 6109. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From kauer at biplane.com.au Sun Feb 27 16:32:52 2011 From: kauer at biplane.com.au (Karl Auer) Date: Mon, 28 Feb 2011 09:32:52 +1100 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227140321.GM9424@angus.ind.WPI.EDU> Message-ID: <1298845972.2109.10.camel@karl> On Sun, 2011-02-27 at 14:47 +0000, Leigh Porter wrote: > Does anybody have anything neat to keep logs of what host gets what > ipv6 address in an SLAAC environment? How do you define "what host"? If it's by MAC address (and you are not using temporary, cryptographic or random addresses), then the MAC is in the address the host ends up using. Also, as someone else said, hosts don't "get" addresses via SLAAC - they generate them. That means that while you may be able to predict what they *will* use, you would need to snoop NDP to find out what they *are* using, and even more so for temporary, cryptographic and random addresses. I have no experience of anything that actually does this, but it would be fairly simple to do. NDP will end up snooped in routers and switches for lots of reasons, so expect to see such features in real kit pretty soon. Make sure you let your vendor know what you want/need... Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From tony at lava.net Sun Feb 27 16:30:52 2011 From: tony at lava.net (Antonio Querubin) Date: Sun, 27 Feb 2011 12:30:52 -1000 (HST) Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <1298845498.2109.2.camel@karl> References: <7187091.752.1298841943188.JavaMail.franck@franck-martins-macbook-pro.local> <1298845498.2109.2.camel@karl> Message-ID: On Mon, 28 Feb 2011, Karl Auer wrote: > Well - that draft very recently (i.e., only a few months, if that) > became standards track, so it'll be a while before it's built into > everything as a matter of course, but yes, it's "fixed". RFC 6109. ^ Maybe you mean RFC 6106? Antonio Querubin e-mail/xmpp: tony at lava.net From owen at delong.com Sun Feb 27 16:35:50 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 27 Feb 2011 14:35:50 -0800 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <4D69E3E8.5080404@bogus.com> Message-ID: <563D900A-7B72-4AC6-BE3C-473632648FAA@delong.com> On Feb 27, 2011, at 4:21 AM, Randy Bush wrote: >>> You're going to have to perform stateless autconfiguration in ipv6 >>> and provide an ipv4 nameserver at the very minimum for a long time >> apple is gonna look very very st00pid on world ipv6 day. and a bunch >> of folk are considering not turning things off after that day. > > on second thought, guess where the support calls are gonna go. our > customer support lines, because we deliver zipless ipv6. > > NOC: are you running a macintosh? > User: yes, how did you guess? > NOC: because it is broken. get vista. > > randy While I'm as big a fan of IPv6 as anybody, I think in a comparison of relative brokenness, Mac comes out quite favorably compared to Vista in spite of their DHCPv6 deficiencies. Owen From gbonser at seven.com Sun Feb 27 16:39:04 2011 From: gbonser at seven.com (George Bonser) Date: Sun, 27 Feb 2011 14:39:04 -0800 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <4D69DDD2.8050903@bogus.com><4D69E529.5090109@bogus.com><20110227140321.GM9424@angus.ind.WPI.EDU> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13DC6@RWC-EX1.corp.seven.com> > From: Leigh Porter > Sent: Sunday, February 27, 2011 6:48 AM > To: Chuck Anderson > Cc: nanog at nanog.org; I2 IPv6 working group > Subject: Re: Mac OS X 10.7, still no DHCPv6 > > > > Does anybody have anything neat to keep logs of what host gets what > ipv6 address in an SLAAC environment? > > This is often required for legislation compliance. DHCP does this well. > > -- > Leigh Porter Do the hosts register themselves in DNS? You might be able to look at your DNS logs. From marka at isc.org Sun Feb 27 16:39:24 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 28 Feb 2011 09:39:24 +1100 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: Your message of "Sun, 27 Feb 2011 20:45:12 -0000." <20110227204511.GM27578@virtual.bogons.net> References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227202208.804C6B0DF80@drugs.dv.isc.org><20110227204511.GM27578@virtual.bogons.net> Message-ID: <20110227223924.DF0E3B0E741@drugs.dv.isc.org> In message <20110227204511.GM27578 at virtual.bogons.net>, Simon Lockhart writes: > On Mon Feb 28, 2011 at 07:22:08AM +1100, Mark Andrews wrote: > > > This is often required for legislation compliance. DHCP does this well. > > > > Does it really matter what address a customer has as long as it comes from > > the /64, /56 or /48 assigned to them? > > You are assuming an access technology that lends itself to subnet-per-custome > r. > > I run a network with 50,000+ end users using ethernet-based access to the > user's room. In IPv4, I run 1 or more subnets per building (depending on the > number of rooms in the build). I use DHCP to assign IPs, and record the > DHCP assignments allow me to trace users in the event of abuse complaints. I > use DHCP Option82 to allow me to correlate multiple devices in a user's room. > I feed the DHCP information into my bandwidth management platform to enforce > different levels (i.e. speeds) of service per user depending on what they've > purchased. > > I have yet to come up with a viable solution to do all of the above in IPv6 > without using DHCPv6. At the moment, that means that OSX users are not going > to get IPv6. Have you *asked* your vendors for a alternate solution? DHCP kills privacy addresses. DHCP kills CGAs. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From rps at maine.edu Sun Feb 27 16:42:19 2011 From: rps at maine.edu (Ray Soucy) Date: Sun, 27 Feb 2011 17:42:19 -0500 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <1298845972.2109.10.camel@karl> References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227140321.GM9424@angus.ind.WPI.EDU> <1298845972.2109.10.camel@karl> Message-ID: You can write script to poll routers for IPv6 neighbors, and store those in a database. That will get you the IPv6 to MAC association. Then poll L2 devices for MAC address tables for the MAC to port association. We've had such a system in place for a few years now to map addresses to ports, etc., it also checks for rogue RA. It's messy (and I don't like the extra load it causes on routers). If we had things like DHCPv6 snooping, RA guard (which you can implement with PACLs), and IPv6 source verification we wouldn't need it. Thankfully most of these are all in the pipeline. On Sun, Feb 27, 2011 at 5:32 PM, Karl Auer wrote: > On Sun, 2011-02-27 at 14:47 +0000, Leigh Porter wrote: >> Does anybody have anything neat to keep logs of what host gets what >> ipv6 address in an SLAAC environment? > > How do you define "what host"? If it's by MAC address (and you are not > using temporary, cryptographic or random addresses), then the MAC is in > the address the host ends up using. > > Also, as someone else said, hosts don't "get" addresses via SLAAC - they > generate them. That means that while you may be able to predict what > they *will* use, you would need to snoop NDP to find out what they *are* > using, and even more so for temporary, cryptographic and random > addresses. > > I have no experience of anything that actually does this, but it would > be fairly simple to do. NDP will end up snooped in routers and switches > for lots of reasons, so expect to see such features in real kit pretty > soon. Make sure you let your vendor know what you want/need... > > Regards, K. > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer at 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 > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From owen at delong.com Sun Feb 27 17:04:55 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 27 Feb 2011 15:04:55 -0800 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227140321.GM9424@angus.ind.WPI.EDU> Message-ID: 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. Owen On Feb 27, 2011, at 11:53 AM, Richard Barnes wrote: > In fairness, said device can do the same sort of inspection of SLAAC > traffic. It just looks at neighbor discovery messages instead of DHCP > messages. > > > > > On Sun, Feb 27, 2011 at 2:17 PM, Leigh Porter > wrote: >> >> >> On 27 Feb 2011, at 19:07, Antonio Querubin wrote: >> >>> On Sun, 27 Feb 2011, Mikael Abrahamsson wrote: >>> >>>> On Sun, 27 Feb 2011, Leigh Porter wrote: >>>> >>>>> Does anybody have anything neat to keep logs of what host gets what ipv6 address in an SLAAC environment? >>>> >>>> You'd have to correlate ND information in the router to some kind of record of who has what MAC address at any given time. With SLAAC the host doesn't "get" an IPv6 address, it "takes" one. >>>> >>>>> This is often required for legislation compliance. DHCP does this well. >>>> >>>> Which is one of the reasons why some of us want DHCPv6 support in hosts. >>> >>> So how does DHCP prevent a host from just taking or hijacking an IP address? >>> >>> Antonio Querubin >>> e-mail/xmpp: tony at lava.net >>> >> >> You can have devices that peek at the DHCP messages and then open filters so that you at least know that any host that pops up on the network has used DHCP to obtain an IP address. >> >> Now you cannot usually prevent somebody from later hijacking that IP address using a fake MAC unless you do something else as well but at least you have something of a statefull relationship between an host and the IP address it uses. >> >> >> -- >> Leigh Porter >> From owen at delong.com Sun Feb 27 17:08:28 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 27 Feb 2011 15:08:28 -0800 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <7187091.752.1298841943188.JavaMail.franck@franck-martins-macbook-pro.local> References: <7187091.752.1298841943188.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> Look, can we stop arguing about whether someone needs DHCP or not, whether they need SLAAC or not. Let's just get both solutions to a mature and useful state where a network administrator can pick the one that works best for their environment and move on. Devices, routers, OSs, etc. should support both. The IETF should stop letting the two working groups focus on damaging the other protocol and we should stop treating this as a competition or a battle and start treating it as options to accomplish a task. Owen On Feb 27, 2011, at 1:25 PM, Franck Martin wrote: > Yes I don't understand why we need DHCPv6, true RD did not have DNS information to pass, but that is fixed, no? > > ----- Original Message ----- > From: "Matthew Palmer" > To: nanog at nanog.org > Sent: Sunday, 27 February, 2011 4:06:29 PM > Subject: Re: Mac OS X 10.7, still no DHCPv6 > > On Sun, Feb 27, 2011 at 08:56:33AM -0500, Ray Soucy wrote: >> Mac OS X 10.7 does support RDNSS (RFC 5001) so it is able to get DNS >> server information in an IPv6-only environment. Of course nobody else >> has implemented that yet, making Apple a "special case" host once >> again (I don't even think Cisco supports the option in their T series >> yet). > > radvd and rdnssd work together on Linux nicely to provide RDNSS support. > Works a treat. > > - Matt > From dougb at dougbarton.us Sun Feb 27 17:17:15 2011 From: dougb at dougbarton.us (Doug Barton) Date: Sun, 27 Feb 2011 15:17:15 -0800 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <20110227223924.DF0E3B0E741@drugs.dv.isc.org> References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227202208.804C6B0DF80@drugs.dv.isc.org><20110227204511.GM27578@virtual.bogons.net> <20110227223924.DF0E3B0E741@drugs.dv.isc.org> Message-ID: <4D6ADB7B.40105@dougbarton.us> On 02/27/2011 14:39, Mark Andrews wrote: > DHCP kills privacy addresses. > DHCP kills CGAs. In some environments that's a feature. :) Also, I think people forget the original motivation behind privacy addresses. If you use RA/SLAAC on every different network that you use IPv6 (say, with your laptop) then the bottom 64 bits are always going to be the same. The theory was that this could provide a way to track the same user across multiple networks, thus the desire to have the ability to generate host identifiers that are "unique-but-temporary." If you're on your home network (where the network prefix is always going to be the same) privacy addresses have limited (although non-zero) utility. If you're at work you're subject to the policies there, and if they say "dhcpv6 + no privacy addresses" then that's that. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owen at delong.com Sun Feb 27 17:17:06 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 27 Feb 2011 15:17:06 -0800 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <20110227223924.DF0E3B0E741@drugs.dv.isc.org> References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227202208.804C6B0DF80@drugs.dv.isc.org><20110227204511.GM27578@virtual.bogons.net> <20110227223924.DF0E3B0E741@drugs.dv.isc.org> Message-ID: On Feb 27, 2011, at 2:39 PM, Mark Andrews wrote: > > In message <20110227204511.GM27578 at virtual.bogons.net>, Simon Lockhart writes: >> On Mon Feb 28, 2011 at 07:22:08AM +1100, Mark Andrews wrote: >>>> This is often required for legislation compliance. DHCP does this well. >>> >>> Does it really matter what address a customer has as long as it comes from >>> the /64, /56 or /48 assigned to them? >> >> You are assuming an access technology that lends itself to subnet-per-custome >> r. >> >> I run a network with 50,000+ end users using ethernet-based access to the >> user's room. In IPv4, I run 1 or more subnets per building (depending on the >> number of rooms in the build). I use DHCP to assign IPs, and record the >> DHCP assignments allow me to trace users in the event of abuse complaints. I >> use DHCP Option82 to allow me to correlate multiple devices in a user's room. >> I feed the DHCP information into my bandwidth management platform to enforce >> different levels (i.e. speeds) of service per user depending on what they've >> purchased. >> >> I have yet to come up with a viable solution to do all of the above in IPv6 >> without using DHCPv6. At the moment, that means that OSX users are not going >> to get IPv6. > > Have you *asked* your vendors for a alternate solution? > > DHCP kills privacy addresses. In many environments, this is a feature, not a bug. > DHCP kills CGAs. > In many environments, this is a feature, not a bug. I would, in fact, posit that some of the people complaining about the lack of DHCP are doing so precisely because of a desire to kill these things in their environment. Owen From joelja at bogus.com Sun Feb 27 17:23:59 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 27 Feb 2011 15:23:59 -0800 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> References: <7187091.752.1298841943188.JavaMail.franck@franck-martins-macbook-pro.local> <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> Message-ID: <4D6ADD0F.3070504@bogus.com> On 2/27/11 3:08 PM, Owen DeLong wrote: > Look, can we stop arguing about whether someone needs DHCP or not, > whether they need SLAAC or not. Let's just get both solutions to a mature > and useful state where a network administrator can pick the one that works > best for their environment and move on. > > Devices, routers, OSs, etc. should support both. The IETF should stop letting > the two working groups focus on damaging the other protocol and we should > stop treating this as a competition or a battle and start treating it as options > to accomplish a task. The documents are done at least for sufficient pieces to make it work. it's in the hands of vendors and has been for a while. The simple fact is that if you want to do it a particular way and you have an installed base that doesn't support doing it that way, then you're not doing it that way. > Owen > > On Feb 27, 2011, at 1:25 PM, Franck Martin wrote: > >> Yes I don't understand why we need DHCPv6, true RD did not have DNS information to pass, but that is fixed, no? >> >> ----- Original Message ----- >> From: "Matthew Palmer" >> To: nanog at nanog.org >> Sent: Sunday, 27 February, 2011 4:06:29 PM >> Subject: Re: Mac OS X 10.7, still no DHCPv6 >> >> On Sun, Feb 27, 2011 at 08:56:33AM -0500, Ray Soucy wrote: >>> Mac OS X 10.7 does support RDNSS (RFC 5001) so it is able to get DNS >>> server information in an IPv6-only environment. Of course nobody else >>> has implemented that yet, making Apple a "special case" host once >>> again (I don't even think Cisco supports the option in their T series >>> yet). >> >> radvd and rdnssd work together on Linux nicely to provide RDNSS support. >> Works a treat. >> >> - Matt >> > > > From joelja at bogus.com Sun Feb 27 17:25:13 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 27 Feb 2011 15:25:13 -0800 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227202208.804C6B0DF80@drugs.dv.isc.org><20110227204511.GM27578@virtual.bogons.net> <20110227223924.DF0E3B0E741@drugs.dv.isc.org> Message-ID: <4D6ADD59.3070401@bogus.com> On 2/27/11 3:17 PM, Owen DeLong wrote: > > On Feb 27, 2011, at 2:39 PM, Mark Andrews wrote: > >> >> In message <20110227204511.GM27578 at virtual.bogons.net>, Simon Lockhart writes: >>> On Mon Feb 28, 2011 at 07:22:08AM +1100, Mark Andrews wrote: >>>>> This is often required for legislation compliance. DHCP does this well. >>>> >>>> Does it really matter what address a customer has as long as it comes from >>>> the /64, /56 or /48 assigned to them? >>> >>> You are assuming an access technology that lends itself to subnet-per-custome >>> r. >>> >>> I run a network with 50,000+ end users using ethernet-based access to the >>> user's room. In IPv4, I run 1 or more subnets per building (depending on the >>> number of rooms in the build). I use DHCP to assign IPs, and record the >>> DHCP assignments allow me to trace users in the event of abuse complaints. I >>> use DHCP Option82 to allow me to correlate multiple devices in a user's room. >>> I feed the DHCP information into my bandwidth management platform to enforce >>> different levels (i.e. speeds) of service per user depending on what they've >>> purchased. >>> >>> I have yet to come up with a viable solution to do all of the above in IPv6 >>> without using DHCPv6. At the moment, that means that OSX users are not going >>> to get IPv6. >> >> Have you *asked* your vendors for a alternate solution? >> >> DHCP kills privacy addresses. > > In many environments, this is a feature, not a bug. > >> DHCP kills CGAs. >> > In many environments, this is a feature, not a bug. > > I would, in fact, posit that some of the people complaining about the lack of > DHCP are doing so precisely because of a desire to kill these things in their > environment. which is fine they just have to kill of their legacy software deployments while they're at it. > Owen > > > From dougb at dougbarton.us Sun Feb 27 17:34:13 2011 From: dougb at dougbarton.us (Doug Barton) Date: Sun, 27 Feb 2011 15:34:13 -0800 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> References: <7187091.752.1298841943188.JavaMail.franck@franck-martins-macbook-pro.local> <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> Message-ID: <4D6ADF75.5060207@dougbarton.us> On 02/27/2011 15:08, Owen DeLong wrote: > Look, can we stop arguing about whether someone needs DHCP or not, > whether they need SLAAC or not. Let's just get both solutions to a mature > and useful state where a network administrator can pick the one that works > best for their environment and move on. Speaking as an OS implementor, no, please don't do that. :) Let SLAAC be what it is, and give DHCPv6 feature parity with DHCPv4. Having all options supported in both methods is N-squared complexity for OS developers, never mind how difficult it's going to make actually using the stuff. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From marka at isc.org Sun Feb 27 17:40:56 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 28 Feb 2011 10:40:56 +1100 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: Your message of "Sun, 27 Feb 2011 15:17:06 -0800." References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227202208.804C6B0DF80@drugs.dv.isc.org><20110227204511.GM27578@virtual.bogons.net> <20110227223924.DF0E3B0E741@drugs.dv.isc.org> Message-ID: <20110227234057.025E2B179DB@drugs.dv.isc.org> In message , Owen DeLong writes: > > On Feb 27, 2011, at 2:39 PM, Mark Andrews wrote: > > >=20 > > In message <20110227204511.GM27578 at virtual.bogons.net>, Simon Lockhart = > writes: > >> On Mon Feb 28, 2011 at 07:22:08AM +1100, Mark Andrews wrote: > >>>> This is often required for legislation compliance. DHCP does this = > well. > >>>=20 > >>> Does it really matter what address a customer has as long as it = > comes from > >>> the /64, /56 or /48 assigned to them? > >>=20 > >> You are assuming an access technology that lends itself to = > subnet-per-custome > >> r. > >>=20 > >> I run a network with 50,000+ end users using ethernet-based access to = > the > >> user's room. In IPv4, I run 1 or more subnets per building (depending = > on the=20 > >> number of rooms in the build). I use DHCP to assign IPs, and record = > the=20 > >> DHCP assignments allow me to trace users in the event of abuse = > complaints. I > >> use DHCP Option82 to allow me to correlate multiple devices in a = > user's room. > >> I feed the DHCP information into my bandwidth management platform to = > enforce > >> different levels (i.e. speeds) of service per user depending on what = > they've > >> purchased. > >>=20 > >> I have yet to come up with a viable solution to do all of the above = > in IPv6 > >> without using DHCPv6. At the moment, that means that OSX users are = > not going > >> to get IPv6. > >=20 > > Have you *asked* your vendors for a alternate solution? > >=20 > > DHCP kills privacy addresses. > > In many environments, this is a feature, not a bug. > > > DHCP kills CGAs. > >=20 > In many environments, this is a feature, not a bug. > > I would, in fact, posit that some of the people complaining about the = > lack of > DHCP are doing so precisely because of a desire to kill these things in = > their > environment. > > Owen Sure there are some envionments where it is a feature. But in many you really don't care what address the machine gets. You are actually looking for to tie the address(mac) to a accounting record and DHCP is the only currently available solution and rather than look for a better solution DHCP is being used. One could have the machine generate its own addresses and register them using DHCP. You get the accounting without throwing out the ability to do things like privacy addresses and CGA. The DHCP server can also prevent the machine using a reserved address for the few things on the net that need it. You also get IPv6 reverse maintenance thrown in for free. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From tore.anderson at redpill-linpro.com Sun Feb 27 17:41:34 2011 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Mon, 28 Feb 2011 00:41:34 +0100 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <563D900A-7B72-4AC6-BE3C-473632648FAA@delong.com> References: <4D69E3E8.5080404@bogus.com> <563D900A-7B72-4AC6-BE3C-473632648FAA@delong.com> Message-ID: <4D6AE12E.1020701@redpill-linpro.com> * Owen DeLong > On Feb 27, 2011, at 4:21 AM, Randy Bush wrote: > >> NOC: are you running a macintosh? >> User: yes, how did you guess? >> NOC: because it is broken. get vista. > > While I'm as big a fan of IPv6 as anybody, I think in a comparison of > relative brokenness, Mac comes out quite favorably compared to > Vista in spite of their DHCPv6 deficiencies. Absolutely not. Mac OS X does not do proper source address selection according to RFC 3484. That makes it do things like preferring the use of link-local IPv6 addresses when connecting to global dual-stacked destinations, which of course won't work - as a result a 75 second long timeout is incurred for every single outgoing TCP connection. Versions earlier than 10.6.5, still in use by a considerable amount of users, will also prefer the use of 6to4 to IPv4, again something which is causing lots of brokenness. (Windows ICS is responsible for causing lots of OS X hosts to have 6to4 addresses in the first place, though.) OS X also has a bug that will make it interpret a router lifetime of 0 in a RA as infinite, causing more troubles when found behind IPv6 CE routers using ULAs in compliance with I-D.ietf-v6ops-ipv6-cpe-router, one example of which is the AVM FritzBox as far as I understand. See also: http://getipv6.info/index.php/Customer_problems_that_could_occur http://fud.no/ipv6/snapshot-20101221/gnuplot/noosx-t10-historic.png My guess is that about 70-80% of the users calling Randy and others to report problems on ?World IPv6 Day? will be running Mac OS X. Ray: Do you know if RFC 3484 has been implemented in OS X 10.7? -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From randy at psg.com Sun Feb 27 18:01:48 2011 From: randy at psg.com (Randy Bush) Date: Mon, 28 Feb 2011 09:01:48 +0900 Subject: World IPv6 Day (was: Mac OS X 10.7, still no DHCPv6) Message-ID: Me: >>> NOC: are you running a macintosh? >>> User: yes, how did you guess? >>> NOC: because it is broken. get vista. btw, i run macosx 10.6.6 Some Clueless Mac Fanchild: >> While I'm as big a fan of IPv6 as anybody, I think in a comparison of >> relative brokenness, Mac comes out quite favorably compared to Vista >> in spite of their DHCPv6 deficiencies. Tore: > Absolutely not. Mac OS X does not do proper source address selection > according to RFC 3484. That makes it do things like preferring the use > of link-local IPv6 addresses when connecting to global dual-stacked > destinations, which of course won't work - as a result a 75 second > long timeout is incurred for every single outgoing TCP connection. i have hope for lion, and maybe even a patch for 10.6. this stuff just has to be fixed before world ipv6 day. > My guess is that about 70-80% of the users calling Randy and others to > report problems on ?World IPv6 Day? will be running Mac OS X. sad to say, probably not. the biggest problem here in japan is ntt [0]. they provide no global v6 [1], but an ipv6 walled garden against which users will bang heads when they get a quad-a. they own the last km, provide the cpe, and own the government. so we have to use them for transport. our customers will hit their broken implementation and call us. sweet! the isps, in cooperation with ntt, are trying to sort this problem before it occurs. but it is not pretty and there is no good solution. randy --- [0] - not the ntt which provides layers three and above, and even ipv6 in the states and much of asia except japan. this is ntt the telco semi-monopoly local bearer provider in japan and their ngn implementation. [1] - apocrypha of japan being ipv6 rich are utter bs. From rps at maine.edu Sun Feb 27 18:26:26 2011 From: rps at maine.edu (Ray Soucy) Date: Sun, 27 Feb 2011 19:26:26 -0500 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <4D6AE12E.1020701@redpill-linpro.com> References: <4D69E3E8.5080404@bogus.com> <563D900A-7B72-4AC6-BE3C-473632648FAA@delong.com> <4D6AE12E.1020701@redpill-linpro.com> Message-ID: (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 ::ffff:0:0/96 10 4 ----8<---- On Sun, Feb 27, 2011 at 6:41 PM, Tore Anderson wrote: > * Owen DeLong > >> On Feb 27, 2011, at 4:21 AM, Randy Bush wrote: >> >>> NOC: are you running a macintosh? >>> User: yes, how did you guess? >>> NOC: because it is broken. ?get vista. >> >> While I'm as big a fan of IPv6 as anybody, I think in a comparison of >> relative brokenness, Mac comes out quite favorably compared to >> Vista in spite of their DHCPv6 deficiencies. > > Absolutely not. Mac OS X does not do proper source address selection > according to RFC 3484. That makes it do things like preferring the use > of link-local IPv6 addresses when connecting to global dual-stacked > destinations, which of course won't work - as a result a 75 second long > timeout is incurred for every single outgoing TCP connection. Versions > earlier than 10.6.5, still in use by a considerable amount of users, > will also prefer the use of 6to4 to IPv4, again something which is > causing lots of brokenness. (Windows ICS is responsible for causing lots > of OS X hosts to have 6to4 addresses in the first place, though.) > > OS X also has a bug that will make it interpret a router lifetime of 0 > in a RA as infinite, causing more troubles when found behind IPv6 CE > routers using ULAs in compliance with I-D.ietf-v6ops-ipv6-cpe-router, > one example of which is the AVM FritzBox as far as I understand. > > See also: > > http://getipv6.info/index.php/Customer_problems_that_could_occur > http://fud.no/ipv6/snapshot-20101221/gnuplot/noosx-t10-historic.png > > My guess is that about 70-80% of the users calling Randy and others to > report problems on ?World IPv6 Day? will be running Mac OS X. > > Ray: Do you know if RFC 3484 has been implemented in OS X 10.7? > > -- > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com/ > Tel: +47 21 54 41 27 > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From nanog at nq4i.com Sun Feb 27 18:54:17 2011 From: nanog at nq4i.com (Bobby Lacey) Date: Sun, 27 Feb 2011 18:54:17 -0600 Subject: DSL/Fiber/MetroE Options for Fort Worth, TX Message-ID: Hi All, Looking for a provider/contact of a dsl circuit, MetroE, or other >8mbps alternative in the Fort Worth, TX area. Specifically this will be used as internet access for a conference at the Fort Worth Convention center at 1201 Houston St Fort Worth, TX. Sorry for the bandwidth, but we are desperately looking for a provider. Please respond offlist. Thank you, Bobby KF4GTA From bicknell at ufp.org Sun Feb 27 19:34:21 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 27 Feb 2011 17:34:21 -0800 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <20110227223924.DF0E3B0E741@drugs.dv.isc.org> References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227223924.DF0E3B0E741@drugs.dv.isc.org> Message-ID: <20110228013421.GA32758@ussenterprise.ufp.org> In a message written on Mon, Feb 28, 2011 at 09:39:24AM +1100, Mark Andrews wrote: > Have you *asked* your vendors for a alternate solution? > > DHCP kills privacy addresses. > DHCP kills CGAs. Not true. Some would like to use DHCPv6 to hand a host things like DNS servers, NTP servers, PXE boot information, domain name search paths, and the like. There's no reason once the host gets a DHCP address and that information it can't also generate and use a privacy address or CGA. While this thread has focused on folks who want to use DHCPv6 to preclude these items by for instance having switches and routers filtered to only the "allowed" address (assigned via DHCP) there's no requirement a network operator do that. DHCP has a couple of hundred defined options. Vendors have tried adding ONE to the RA protocol (DNS servers) as replacement functionality. That leaves them a few hundred options short, in my book. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From morrowc.lists at gmail.com Sun Feb 27 19:42:42 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 27 Feb 2011 20:42:42 -0500 Subject: SLA for voice and video over IP/MPLS In-Reply-To: References: Message-ID: On Sun, Feb 27, 2011 at 4:20 PM, Anton Kapela wrote: > On Thu, Feb 24, 2011 at 6:10 PM, Diogo Montagner > wrote: >> Hello, >> >> I am looking for industry standard parameters to base the SLA of one >> network regarding to voice, video and data application. > > 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. out of pure curiosity, have you ever gotten a reasonable answer when asking a carrier about this? I can imagine a sale-rep's brain essentially exploding upon asking it. Additionally 'the network' is not 'the path my packets take' ... so what number are you really getting here? -Chris From morrowc.lists at gmail.com Sun Feb 27 19:46:27 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 27 Feb 2011 20:46:27 -0500 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <7187091.752.1298841943188.JavaMail.franck@franck-martins-macbook-pro.local> References: <20110227210629.GS6259@hezmatt.org> <7187091.752.1298841943188.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On Sun, Feb 27, 2011 at 4:25 PM, Franck Martin wrote: > Yes I don't understand why we need DHCPv6, true RD did not have DNS information to pass, but that is fixed, no? > where's my tftp-boot image location? root nfs mount? .... pick lots of other features used in enterprises today... to flip the coin the other way, what's the harm in dhcpv6? (different strokes and all that) -chris From marka at isc.org Sun Feb 27 19:57:22 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 28 Feb 2011 12:57:22 +1100 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: Your message of "Sun, 27 Feb 2011 17:34:21 -0800." <20110228013421.GA32758@ussenterprise.ufp.org> References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227223924.DF0E3B0E741@drugs.dv.isc.org> <20110228013421.GA32758@ussenterprise.ufp.org> Message-ID: <20110228015722.B0A7AB19587@drugs.dv.isc.org> In message <20110228013421.GA32758 at ussenterprise.ufp.org>, Leo Bicknell writes: > In a message written on Mon, Feb 28, 2011 at 09:39:24AM +1100, Mark Andrews= > wrote: > > Have you *asked* your vendors for a alternate solution? > >=20 > > DHCP kills privacy addresses. > > DHCP kills CGAs. > > Not true. > > Some would like to use DHCPv6 to hand a host things like DNS servers, > NTP servers, PXE boot information, domain name search paths, and > the like. And you can do most of that without requiring DHCP for addresses. PXE boot may be the exception. > There's no reason once the host gets a DHCP address and > that information it can't also generate and use a privacy address > or CGA. Except in the senarios being described they are also blocking the other addresses. I would also think setting the "M" bit would prelude the host from generating such addresses as they are unmanaged. > While this thread has focused on folks who want to use DHCPv6 to > preclude these items by for instance having switches and routers > filtered to only the "allowed" address (assigned via DHCP) there's > no requirement a network operator do that. > > DHCP has a couple of hundred defined options. Vendors have tried > adding ONE to the RA protocol (DNS servers) as replacement > functionality. That leaves them a few hundred options short, in > my book. Which is what the O bit was for. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From owen at delong.com Sun Feb 27 19:55:53 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 27 Feb 2011 17:55:53 -0800 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <4D6ADD0F.3070504@bogus.com> References: <7187091.752.1298841943188.JavaMail.franck@franck-martins-macbook-pro.local> <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> <4D6ADD0F.3070504@bogus.com> Message-ID: The documents are done, but, I would argue that neither provides a mature set of features. Yes, they've (sort of) resolved the DNS server issue for SLAAC, but, that's recent and getting it into vendor support will be nice. 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. For DHCP, the lack of ability to deliver routing policies or recommendations through DHCP is a roadblock for some deployments which is still in place in the documents and should be fixed to produce a mature implementation. Owen On Feb 27, 2011, at 3:23 PM, Joel Jaeggli wrote: > On 2/27/11 3:08 PM, Owen DeLong wrote: >> Look, can we stop arguing about whether someone needs DHCP or not, >> whether they need SLAAC or not. Let's just get both solutions to a mature >> and useful state where a network administrator can pick the one that works >> best for their environment and move on. >> >> Devices, routers, OSs, etc. should support both. The IETF should stop letting >> the two working groups focus on damaging the other protocol and we should >> stop treating this as a competition or a battle and start treating it as options >> to accomplish a task. > > The documents are done at least for sufficient pieces to make it work. > it's in the hands of vendors and has been for a while. The simple fact > is that if you want to do it a particular way and you have an installed > base that doesn't support doing it that way, then you're not doing it > that way. > >> Owen >> >> On Feb 27, 2011, at 1:25 PM, Franck Martin wrote: >> >>> Yes I don't understand why we need DHCPv6, true RD did not have DNS information to pass, but that is fixed, no? >>> >>> ----- Original Message ----- >>> From: "Matthew Palmer" >>> To: nanog at nanog.org >>> Sent: Sunday, 27 February, 2011 4:06:29 PM >>> Subject: Re: Mac OS X 10.7, still no DHCPv6 >>> >>> On Sun, Feb 27, 2011 at 08:56:33AM -0500, Ray Soucy wrote: >>>> Mac OS X 10.7 does support RDNSS (RFC 5001) so it is able to get DNS >>>> server information in an IPv6-only environment. Of course nobody else >>>> has implemented that yet, making Apple a "special case" host once >>>> again (I don't even think Cisco supports the option in their T series >>>> yet). >>> >>> radvd and rdnssd work together on Linux nicely to provide RDNSS support. >>> Works a treat. >>> >>> - Matt >>> >> >> >> From jra at baylink.com Sun Feb 27 20:00:18 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 27 Feb 2011 21:00:18 -0500 (EST) Subject: Sunday Funnies: Using a smart phone as a diagnostic tool Message-ID: <25327548.48.1298858418949.JavaMail.root@benjamin.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? (My motivation? Well, um, Lee, I'm looking at buying an HTC Thunderbolt, if everyone can get their thumbs out, and I want to get a feeling for the lanscape, if you'll pardon the pun. :-) Cheers, -- jra From owen at delong.com Sun Feb 27 20:01:44 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 27 Feb 2011 18:01:44 -0800 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <4D6AE12E.1020701@redpill-linpro.com> References: <4D69E3E8.5080404@bogus.com> <563D900A-7B72-4AC6-BE3C-473632648FAA@delong.com> <4D6AE12E.1020701@redpill-linpro.com> Message-ID: On Feb 27, 2011, at 3:41 PM, Tore Anderson wrote: > * Owen DeLong > >> On Feb 27, 2011, at 4:21 AM, Randy Bush wrote: >> >>> NOC: are you running a macintosh? >>> User: yes, how did you guess? >>> NOC: because it is broken. get vista. >> >> While I'm as big a fan of IPv6 as anybody, I think in a comparison of >> relative brokenness, Mac comes out quite favorably compared to >> Vista in spite of their DHCPv6 deficiencies. > > Absolutely not. Mac OS X does not do proper source address selection > according to RFC 3484. That makes it do things like preferring the use > of link-local IPv6 addresses when connecting to global dual-stacked > destinations, which of course won't work - as a result a 75 second long > timeout is incurred for every single outgoing TCP connection. Versions > earlier than 10.6.5, still in use by a considerable amount of users, > will also prefer the use of 6to4 to IPv4, again something which is > causing lots of brokenness. (Windows ICS is responsible for causing lots > of OS X hosts to have 6to4 addresses in the first place, though.) > > OS X also has a bug that will make it interpret a router lifetime of 0 > in a RA as infinite, causing more troubles when found behind IPv6 CE > routers using ULAs in compliance with I-D.ietf-v6ops-ipv6-cpe-router, > one example of which is the AVM FritzBox as far as I understand. > You're talking about IPv6-specific brokenness. I'm talking about overall OS brokenness. On IPv6, yes, Micr0$0ft actually (finally) got something mostly right. On just about everything else... Windows... Nah, can't say I miss it at all. Owen From charles at knownelement.com Sun Feb 27 22:14:53 2011 From: charles at knownelement.com (Charles N Wyble) Date: Sun, 27 Feb 2011 20:14:53 -0800 Subject: Sunday Funnies: Using a smart phone as a diagnostic tool In-Reply-To: <25327548.48.1298858418949.JavaMail.root@benjamin.baylink.com> References: <25327548.48.1298858418949.JavaMail.root@benjamin.baylink.com> Message-ID: <4D6B213D.5080203@knownelement.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/27/2011 06:00 PM, Jay Ashworth wrote: > Do you have a smartphone? Blackberry? iPhone? Android? Yes. Had all 3. Android is my only tool now. It's superb. I've used/supported and developed applications for all 3 platforms. Android has been the most pleasant by far. > > Do you use it as a technical tool in your work, either for accessing > devices or testing connectivity -- or something else? Yes. All the time. For out of band connectivity at customer sites to various diagnostic applications on the phone. > > If so, what kind of phone, My Touch 3g from t-mobile. and what (if you don't mind letting on) are > your magic apps for this sort of work? Built in browser on Froyo (often times need to search something when a network is down), mail client (k9mail). Also netSwissTool. Oh and of course I tether my phone. > > (My motivation? Well, um, Lee, I'm looking at buying an HTC Thunderbolt, > if everyone can get their thumbs out, and I want to get a feeling for > the lanscape, if you'll pardon the pun. :-) I keep meaning to pickup a cheap android tablet. Load ubuntu on it (android os is quite nice on a phone. larger system i would prefer to have ubuntu). (before you sneer at me, i've been using linux for almost 15 years, and want something that just works :) - -- Charles N Wyble (charles at knownelement.com) Systems craftsman for the stars http://www.knownelement.com Mobile: 626 539 4344 Office: 310 929 8793 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNayE2AAoJEMvvG/TyLEAtV7oQAI8Ezh8ZUmB4HaAM28gyC4UV aD4KTMSxwDyAKXpGdWzgWMe1kqFcKCmswN4NDhpIkXMi0y1t03B3ZTdlOK+gUYiG i7ZKVD4SusZKJE5QzQpAHPvwQue5Hg1tciD3EeHZHbfg4AhIGF6QnYQFtOdsaPQO WyuTmJ4oNJYqOXCEVmZyEq+kbgl0KEZwhYlDV7kzHFkQSyooYs4+Opq1Evoi0Tbg 9+2vrNpEButSKld2Av2vG+nSXg4Um8qCnU/QepOmHiHcXxC/9KM54xsrABLC66d1 7pc4PncurON8sO6xd0Fzi3mzGHUeaVBqm3V01gT2INOrP0gGE+tYUajoLRmvSmii re0s94Wpaw8WLMYvzLSaOBSJVkFqYPWPyutuj+iYwiKHdqOJhXYXV4jB+tnFXDbB 5Z9U2+WfBpD5WUZrQHhAr/LVRfjE8KPyfFFCQ2bxx78qCQv0KwsLdSFPFnU9gpIj FpAe8V0GAi0nLaItw6sAIsgjgAA52UV0jGYZo6VT0UAKVOQJWe5c6Ofcm3eAZTBi +GAn1Jl8iELbeFkTD+UPNoBCgpz3YuelF4qdhK8mMhjV9Sx1T5PsTwW9nMmQFYpr oOrnOkqUsisz2AHKKg8CvjMeKXA7/od9N6l6Uu0XIlh9+8znbGai2Rs9FbbWquiX /fVRLQ0aSScb6xRF1DLJ =vOOX -----END PGP SIGNATURE----- From grobe0ba at gmail.com Sun Feb 27 20:20:45 2011 From: grobe0ba at gmail.com (Atticus) Date: Sun, 27 Feb 2011 21:20:45 -0500 Subject: Sunday Funnies: Using a smart phone as a diagnostic tool In-Reply-To: References: <25327548.48.1298858418949.JavaMail.root@benjamin.baylink.com> Message-ID: I use Android phones, mostly for remote administration. SSH using ConnectBot. If you want a really durable phone, with the option of a little bit of additional functionality, I would take a Motorola Droid 1, throw CyanogenMod on it with a p3droid kernel. The phone itself can survive 3ft falls @ 30 mph (proven myself on accident), the keyboard is very useable, and overall is an amazing phone. You can also use a fair number of command line tools, and add your own statically compiled tools, or dynamically compiled with a bit more work. On Feb 27, 2011 9:03 PM, "Jay Ashworth" wrote: 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? (My motivation? Well, um, Lee, I'm looking at buying an HTC Thunderbolt, if everyone can get their thumbs out, and I want to get a feeling for the lanscape, if you'll pardon the pun. :-) Cheers, -- jra From george.herbert at gmail.com Sun Feb 27 20:29:20 2011 From: george.herbert at gmail.com (George Herbert) Date: Sun, 27 Feb 2011 18:29:20 -0800 Subject: Sunday Funnies: Using a smart phone as a diagnostic tool In-Reply-To: <25327548.48.1298858418949.JavaMail.root@benjamin.baylink.com> References: <25327548.48.1298858418949.JavaMail.root@benjamin.baylink.com> Message-ID: Related topic - ACM's CHIMIT (Computer Human Interfaces for the Management of Information Technology) workshop 2010 was co-located with the Usenix LISA conference this year (http://www.chimit10.org/home.html); I was on a panel discussion on mobile devices in system administration. This topic and the workshop could use more networking people participation. On Sun, Feb 27, 2011 at 6:00 PM, Jay Ashworth wrote: > 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? > > (My motivation? ?Well, um, Lee, I'm looking at buying an HTC Thunderbolt, > if everyone can get their thumbs out, and I want to get a feeling for > the lanscape, if you'll pardon the pun. :-) > > Cheers, > -- jra > > -- -george william herbert george.herbert at gmail.com From diogo.montagner at gmail.com Sun Feb 27 20:33:48 2011 From: diogo.montagner at gmail.com (Diogo Montagner) Date: Mon, 28 Feb 2011 10:33:48 +0800 Subject: SLA for voice and video over IP/MPLS In-Reply-To: References: Message-ID: Hi Chris, I never got this answer. Chris, Tim, Anton and Martin, thank you for all inputs. Really appreciate them. Thanks ./diogo -montagner On Mon, Feb 28, 2011 at 9:42 AM, Christopher Morrow wrote: > On Sun, Feb 27, 2011 at 4:20 PM, Anton Kapela wrote: >> On Thu, Feb 24, 2011 at 6:10 PM, Diogo Montagner >> wrote: >>> Hello, >>> >>> I am looking for industry standard parameters to base the SLA of one >>> network regarding to voice, video and data application. >> >> 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. > > out of pure curiosity, have you ever gotten a reasonable answer when > asking a carrier about this? I can imagine a sale-rep's brain > essentially exploding upon asking it. Additionally 'the network' is > not 'the path my packets take' ... so what number are you really > getting here? > > -Chris > From nanog at lacutt.com Sun Feb 27 20:46:50 2011 From: nanog at lacutt.com (LaDerrick H.) Date: Sun, 27 Feb 2011 20:46:50 -0600 Subject: Sunday Funnies: Using a smart phone as a diagnostic tool In-Reply-To: <25327548.48.1298858418949.JavaMail.root@benjamin.baylink.com> References: <25327548.48.1298858418949.JavaMail.root@benjamin.baylink.com> Message-ID: <20110228024650.GS30113@nm.lacutt> On Sun, Feb 27, 2011 at 09:00:18PM -0500, Jay Ashworth wrote: > 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? > > (My motivation? Well, um, Lee, I'm looking at buying an HTC Thunderbolt, > if everyone can get their thumbs out, and I want to get a feeling for > the lanscape, if you'll pardon the pun. :-) > > Cheers, > -- jra Nokia N900. Slide-out, physical keyboard. Debian Linux based OS. Fair amount of free packages/apps available and then there's always GCC. No hackery needed for full system access. IPV6 capable and actually working on T-Mobile. Not quite as slick as newer Android phones and iPhones but more of a workhorse. LaDerrick From jeff-kell at utc.edu Sun Feb 27 20:52:43 2011 From: jeff-kell at utc.edu (Jeff Kell) Date: Sun, 27 Feb 2011 21:52:43 -0500 Subject: Sunday Funnies: Using a smart phone as a diagnostic tool In-Reply-To: <25327548.48.1298858418949.JavaMail.root@benjamin.baylink.com> References: <25327548.48.1298858418949.JavaMail.root@benjamin.baylink.com> Message-ID: <4D6B0DFB.9020906@utc.edu> On 2/27/2011 9:00 PM, Jay Ashworth wrote: > 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? I have a Droid2 with the "WiFi Analyzer" freebie app by Kevin Yuan. Compared to dragging around a real analyzer, it's helpful in the field. Certainly haven't gone to any great lengths to "find" more, or purposefully use my phone as a test device, but at least that one is handy (was discovered by our WiFi guy) and the price is right. Jeff From morrowc.lists at gmail.com Sun Feb 27 21:07:56 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 27 Feb 2011 22:07:56 -0500 Subject: SLA for voice and video over IP/MPLS In-Reply-To: References: Message-ID: On Sun, Feb 27, 2011 at 9:33 PM, Diogo Montagner wrote: > Hi Chris, > > I never got this answer. I suspect you won't... at least not a reasonable/usrful answer. From smb at cs.columbia.edu Sun Feb 27 21:47:58 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Sun, 27 Feb 2011 22:47:58 -0500 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <72B7B4EA-0E25-4D31-B9A1-653308E4D675@arbor.net> References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227140321.GM9424@angus.ind.WPI.EDU> <72B7B4EA-0E25-4D31-B9A1-653308E4D675@arbor.net> Message-ID: <071A89DA-A414-4DCC-BC47-3C86AB67EFE0@cs.columbia.edu> On Feb 27, 2011, at 10:25 25AM, Dobbins, Roland wrote: > > On Feb 27, 2011, at 10:22 PM, Mikael Abrahamsson wrote: > >> Which is one of the reasons why some of us want DHCPv6 support in hosts. > > Also for traceback when hunting down compromised/abusive hosts. > You really need to look at switch logs for that, even with IPv4: http://www.cs.columbia.edu/~smb/talks/arp-attack.pdf Also don't forget privacy-enhanced addresses. We all know that bad guys make up addresses whenever it suits their needs. (I'm part of an ongoing discussion about a currently-active series of incidents, all relying on spoofed source addresses.) DHCP logs or configurations are not going to help against the folks we really care about. For the ankle-biters -- well, SLAAC is better in many ways, since the IP address itself tells you the MAC address, which makes applying filters so much easier... 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. I am saying that security is not a strong argument. --Steve Bellovin, http://www.cs.columbia.edu/~smb From tvhawaii at shaka.com Sun Feb 27 21:50:33 2011 From: tvhawaii at shaka.com (Michael Painter) Date: Sun, 27 Feb 2011 17:50:33 -1000 Subject: Sunday Funnies: Using a smart phone as a diagnostic tool References: <25327548.48.1298858418949.JavaMail.root@benjamin.baylink.com> Message-ID: Jay Ashworth wrote: > 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? > > (My motivation? Well, um, Lee, I'm looking at buying an HTC Thunderbolt, > if everyone can get their thumbs out, and I want to get a feeling for > the lanscape, if you'll pardon the pun. :-) > > Cheers, > -- jra Please get one that has a mail app that posts to these lists correctly. From jsw at inconcepts.biz Sun Feb 27 22:17:05 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Sun, 27 Feb 2011 23:17:05 -0500 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: Message-ID: On Sun, Feb 27, 2011 at 5:16 PM, Ray Soucy wrote: > This seems to have upset at least one Apple engineer who dropped the > NDA bomb on me; while he didn't confirm it was there, he did imply it, > and it did make me have people give a second look. (I tried to get him > to admit it but he's obviously been through Apple secret keeping > training). If work on DHCPv6 or other common tools are obscured by NDA, and thus information is not available to potential customers, and IT departments who must plan to support those customers, Apple is at fault, not Ray or anyone else. There is a lesson for Apple here. Secrets are cool and there is often a legitimate need to keep new features under wraps until you are actually ready to ship them (competition, delays, whatever.) Somehow, I don't think Steve Jobs is going to give a presentation on DHCPv6, and I doubt Apple's decision to ship it with their OS is going to cause Microsoft or other "competitors" to .. do anything differently. Obscuring some things behind NDA is good for business. IPv6 matters (specific to DHCPv6 or otherwise) are not among those things, and Apple ought to take notice of this very discussion and make their intentions and progress more public, so IT departments know what to expect. Secrecy is good for business, except when it's not. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From swmike at swm.pp.se Sun Feb 27 22:17:56 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 28 Feb 2011 05:17:56 +0100 (CET) Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <071A89DA-A414-4DCC-BC47-3C86AB67EFE0@cs.columbia.edu> References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227140321.GM9424@angus.ind.WPI.EDU> <72B7B4EA-0E25-4D31-B9A1-653308E4D675@arbor.net> <071A89DA-A414-4DCC-BC47-3C86AB67EFE0@cs.columbia.edu> Message-ID: On Sun, 27 Feb 2011, Steven Bellovin 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. I am saying that security is not a strong argument. Well, rest assurend that you have plenty of people disagreeing with you. The again your views are shared by a lot of people for IPv4 as well, thus meaning it took until now before the IETF even hade a SAVI like working group to handle the security issues that has been around since forever but that was solved for IPv4 outside of IETF around 10 years ago but stil has no widespread implementation for IPv6 (but it's getting there). -- Mikael Abrahamsson email: swmike at swm.pp.se From rdobbins at arbor.net Sun Feb 27 22:35:37 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 28 Feb 2011 04:35:37 +0000 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <071A89DA-A414-4DCC-BC47-3C86AB67EFE0@cs.columbia.edu> References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227140321.GM9424@angus.ind.WPI.EDU> <72B7B4EA-0E25-4D31-B9A1-653308E4D675@arbor.net> <071A89DA-A414-4DCC-BC47-3C86AB67EFE0@cs.columbia.edu> Message-ID: <49E671D6-F789-4427-890E-CA0D81423C5D@arbor.net> On Feb 28, 2011, at 10:47 AM, Steven Bellovin wrote: > You really need to look at switch logs for that, even with IPv4: http://www.cs.columbia.edu/~smb/talks/arp-attack.pdf And flow telemetry, and so forth, yes. With BCP deployment in terms of anti-ARP-spoofing and DCHP snooping/source guard, traceback becomes whole lot easier. > Also don't forget privacy-enhanced addresses. Yes, which have extremely negative opsec connotations in terms of complicating traceback. ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From franck at genius.com Sun Feb 27 22:53:31 2011 From: franck at genius.com (Franck Martin) Date: Sun, 27 Feb 2011 23:53:31 -0500 (EST) Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> Message-ID: <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> 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. ----- Original Message ----- From: "Owen DeLong" To: "Franck Martin" Cc: "Matthew Palmer" , nanog at nanog.org Sent: Sunday, 27 February, 2011 6:08:28 PM Subject: Re: Mac OS X 10.7, still no DHCPv6 Look, can we stop arguing about whether someone needs DHCP or not, whether they need SLAAC or not. Let's just get both solutions to a mature and useful state where a network administrator can pick the one that works best for their environment and move on. Devices, routers, OSs, etc. should support both. The IETF should stop letting the two working groups focus on damaging the other protocol and we should stop treating this as a competition or a battle and start treating it as options to accomplish a task. Owen On Feb 27, 2011, at 1:25 PM, Franck Martin wrote: > Yes I don't understand why we need DHCPv6, true RD did not have DNS information to pass, but that is fixed, no? > > ----- Original Message ----- > From: "Matthew Palmer" > To: nanog at nanog.org > Sent: Sunday, 27 February, 2011 4:06:29 PM > Subject: Re: Mac OS X 10.7, still no DHCPv6 > > On Sun, Feb 27, 2011 at 08:56:33AM -0500, Ray Soucy wrote: >> Mac OS X 10.7 does support RDNSS (RFC 5001) so it is able to get DNS >> server information in an IPv6-only environment. Of course nobody else >> has implemented that yet, making Apple a "special case" host once >> again (I don't even think Cisco supports the option in their T series >> yet). > > radvd and rdnssd work together on Linux nicely to provide RDNSS support. > Works a treat. > > - Matt > From vixie at isc.org Sun Feb 27 23:33:56 2011 From: vixie at isc.org (Paul Vixie) Date: Mon, 28 Feb 2011 05:33:56 +0000 Subject: Mac OS X 10.7, still no DHCPv6 Message-ID: <24858.1298871236@nsa.vix.com> there are two replies here. --- Christopher Morrow writes: > ..., what's the harm in dhcpv6? (different strokes and all that) only the egos and reputations of those who said that stateless autoconf was all ipv6 needed. (which is a small price to pay, according to me.) --- "Dobbins, Roland" writes: > On Feb 28, 2011, at 10:47 AM, Steven Bellovin wrote: > >> Also don't forget privacy-enhanced addresses. > > Yes, which have extremely negative opsec connotations in terms of > complicating traceback. /64 csma subnets with low order 64 bits controlled by infectable pc's means we'll be blackholing by /64 when we blackhole in ipv6. it's no big deal. -- Paul Vixie KI6YSY From randy at psg.com Mon Feb 28 00:09:19 2011 From: randy at psg.com (Randy Bush) Date: Mon, 28 Feb 2011 15:09:19 +0900 Subject: Sunday Funnies: Using a smart phone as a diagnostic tool In-Reply-To: <4D6B0DFB.9020906@utc.edu> References: <25327548.48.1298858418949.JavaMail.root@benjamin.baylink.com> <4D6B0DFB.9020906@utc.edu> Message-ID: > I have a Droid2 with the "WiFi Analyzer" freebie app by Kevin Yuan. i run it on a nexus one. way coolquite useful. i just can't excuse the $600 cost of a wi-spy. but it sure would be nice to have a general rf peek at the wifi ranges. two weeks ago, in hk, we had rf interference that essentially killed the wifi, but it did not show on wifi analyzer. randy From randy at psg.com Mon Feb 28 00:10:21 2011 From: randy at psg.com (Randy Bush) Date: Mon, 28 Feb 2011 15:10:21 +0900 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <071A89DA-A414-4DCC-BC47-3C86AB67EFE0@cs.columbia.edu> References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227140321.GM9424@angus.ind.WPI.EDU> <72B7B4EA-0E25-4D31-B9A1-653308E4D675@arbor.net> <071A89DA-A414-4DCC-BC47-3C86AB67EFE0@cs.columbia.edu> Message-ID: > 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 randy From joelja at bogus.com Mon Feb 28 00:31:11 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 27 Feb 2011 22:31:11 -0800 Subject: Sunday Funnies: Using a smart phone as a diagnostic tool In-Reply-To: References: <25327548.48.1298858418949.JavaMail.root@benjamin.baylink.com> <4D6B0DFB.9020906@utc.edu> Message-ID: <4D6B412F.8020900@bogus.com> On 2/27/11 10:09 PM, Randy Bush wrote: >> I have a Droid2 with the "WiFi Analyzer" freebie app by Kevin Yuan. > > i run it on a nexus one. way coolquite useful. i just can't excuse the > $600 cost of a wi-spy. http://ubnt.com/airview 2.4ghz model is more Like $50 and works nearly as well as the wi-spy. wi-spy DBx is stll about the cheapest I've seen for a 5ghz spectrum analyzer, and is worth it for that alone but the interference problem you're trying to nip in the bud is is likely in 2.4ghz anyway. > but it sure would be nice to have a general rf peek at the wifi ranges. > two weeks ago, in hk, we had rf interference that essentially killed the > wifi, but it did not show on wifi analyzer. > > randy > From paul at paulgraydon.co.uk Mon Feb 28 00:31:11 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Sun, 27 Feb 2011 20:31:11 -1000 Subject: Sunday Funnies: Using a smart phone as a diagnostic tool In-Reply-To: <25327548.48.1298858418949.JavaMail.root@benjamin.baylink.com> References: <25327548.48.1298858418949.JavaMail.root@benjamin.baylink.com> Message-ID: <4D6B412F.4020704@paulgraydon.co.uk> On 2/27/2011 4:00 PM, Jay Ashworth wrote: > Do you have a smartphone? Blackberry? iPhone? Android? Android, a Nexus One. > 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? Absolutely, I use it on a regular basis. ConnectbotSSH is small, simple and just works. Integrated VPN on the OS enables me to get in safe and secure, then I can ssh to whatever box I need to. There are various password safe types of programs with native smartphone apps (mostly Android and iPhone as far as I'm aware). USB Tethering and Wireless Hotspot ability (currently no extra charge on T-Mobile network) also enable me to do a quick bit of easy checking from outside infrastructure without need for a separate 3G dongle or similar. > (My motivation? Well, um, Lee, I'm looking at buying an HTC Thunderbolt, > if everyone can get their thumbs out, and I want to get a feeling for > the lanscape, if you'll pardon the pun. :-) I think ultimately I'd prefer a physical keyboard on my phone. Most of the time it's fine with a touch-screen keyboard, texting, e-mailing and surfing, when the keyboard can predict what you're typing (alternative keyboard swiftkey is excellent and learns from SMSs etc.) However with ssh it can occasionally be a little irritating (alternative keyboard "Full Keyboard" helps.) I'd be a lot faster with a physical keyboard. I often still keep my old Nokia Internet Tablet around, just in case, then pair it to my phone using wifi. Paul From kauer at biplane.com.au Sun Feb 27 17:38:45 2011 From: kauer at biplane.com.au (Karl Auer) Date: Mon, 28 Feb 2011 10:38:45 +1100 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <7187091.752.1298841943188.JavaMail.franck@franck-martins-macbook-pro.local> <1298845498.2109.2.camel@karl> Message-ID: <1298849925.2109.19.camel@karl> On Sun, 2011-02-27 at 12:30 -1000, Antonio Querubin wrote: > On Mon, 28 Feb 2011, Karl Auer wrote: > > > Well - that draft very recently (i.e., only a few months, if that) > > became standards track, so it'll be a while before it's built into > > everything as a matter of course, but yes, it's "fixed". RFC 6109. > ^ > Maybe you mean RFC 6106? Er - yes. Thanks :-) It comes from being south of the equator - we have to concentrate really hard on the 6 vs 9 thing. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From kauer at biplane.com.au Sun Feb 27 17:53:55 2011 From: kauer at biplane.com.au (Karl Auer) Date: Mon, 28 Feb 2011 10:53:55 +1100 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <20110227223924.DF0E3B0E741@drugs.dv.isc.org> References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227202208.804C6B0DF80@drugs.dv.isc.org> <20110227204511.GM27578@virtual.bogons.net> <20110227223924.DF0E3B0E741@drugs.dv.isc.org> Message-ID: <1298850835.2109.33.camel@karl> 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)? 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. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From joshua.klubi at gmail.com Mon Feb 28 01:10:13 2011 From: joshua.klubi at gmail.com (Joshua William Klubi) Date: Mon, 28 Feb 2011 07:10:13 +0000 Subject: Sunday Funnies: Using a smart phone as a diagnostic tool In-Reply-To: <25327548.48.1298858418949.JavaMail.root@benjamin.baylink.com> References: <25327548.48.1298858418949.JavaMail.root@benjamin.baylink.com> Message-ID: On Mon, Feb 28, 2011 at 2:00 AM, Jay Ashworth wrote: > Do you have a smartphone? Blackberry? iPhone? Android? > Try a Nokia N900 Maemo device, Brief History it is a pet project of Nokia, it is 100% Linux (Debian Based), you don't need to hack it or do anything or install any apps on it, full Linux ie, ssh, lamp stack , name it, you can get it for about $300 this a full fledge site for it http://maemo.org/ > > 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. > > If so, what kind of phone, and what (if you don't mind letting on) are > your magic apps for this sort of work? > > Android, BB, iOS are cool OS but compared to a real Linux OS stack (Debian) 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. > (My motivation? Well, um, Lee, I'm looking at buying an HTC Thunderbolt, > if everyone can get their thumbs out, and I want to get a feeling for > the lanscape, if you'll pardon the pun. :-) > > 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. > Cheers, > -- jra > > From tvhawaii at shaka.com Mon Feb 28 01:20:07 2011 From: tvhawaii at shaka.com (Michael Painter) Date: Sun, 27 Feb 2011 21:20:07 -1000 Subject: Sunday Funnies: Using a smart phone as a diagnostic tool References: <25327548.48.1298858418949.JavaMail.root@benjamin.baylink.com> <4D6B0DFB.9020906@utc.edu> <4D6B412F.8020900@bogus.com> Message-ID: <0601FBDB074A4199B95F591835EF9C27@DELL16> Joel Jaeggli wrote: > On 2/27/11 10:09 PM, Randy Bush wrote: >>> I have a Droid2 with the "WiFi Analyzer" freebie app by Kevin Yuan. >> >> i run it on a nexus one. way coolquite useful. i just can't excuse the >> $600 cost of a wi-spy. > > http://ubnt.com/airview > > 2.4ghz model is more Like $50 and works nearly as well as the wi-spy. > > wi-spy DBx is stll about the cheapest I've seen for a 5ghz spectrum > analyzer, and is worth it for that alone but the interference problem > you're trying to nip in the bud is is likely in 2.4ghz anyway. > >> but it sure would be nice to have a general rf peek at the wifi ranges. >> two weeks ago, in hk, we had rf interference that essentially killed the >> wifi, but it did not show on wifi analyzer. >> >> randy If you need some directionality (and more gain), get the AirView-EXT model and get one of these: http://www.superpass.com/SPDG11F.html Mine came without the S/S mounting plate and I just velcroed the thing to the lid of the laptop (~4x2x1 in.). I also have a higher gain omni that goes on the same velcro, so after you identify the interference, switch to the Sector ant. to get the direction if needed. --Michael From kauer at biplane.com.au Mon Feb 28 01:49:36 2011 From: kauer at biplane.com.au (Karl Auer) Date: Mon, 28 Feb 2011 18:49:36 +1100 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <20110228015722.B0A7AB19587@drugs.dv.isc.org> References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227223924.DF0E3B0E741@drugs.dv.isc.org> <20110228013421.GA32758@ussenterprise.ufp.org> <20110228015722.B0A7AB19587@drugs.dv.isc.org> Message-ID: <1298879376.2109.63.camel@karl> On Mon, 2011-02-28 at 12:57 +1100, Mark Andrews wrote: > Except in the senarios being described they are also blocking the > other addresses. I would also think setting the "M" bit would > prelude the host from generating such addresses as they are unmanaged. I think the M flag says "you can get an address via DHCP" - it doesn't say "and don't get an address via any other means". From RFC 4861: M 1-bit "Managed address configuration" flag. When set, it indicates that addresses are available via Dynamic Host Configuration Protocol [DHCPv6]. If you want to disable SLAAC, you instead use the AdvAutonomousFlag in the Prefix Information option included for the given prefix in the link's Prefix List. > > DHCP has a couple of hundred defined options. Vendors have tried > > adding ONE to the RA protocol (DNS servers) as replacement > > functionality. That leaves them a few hundred options short, in > > my book. > > Which is what the O bit was for. Welll - the number of options defined so far for DHCPv6 is very small compared to the number of options defined for DHCPv4. I think that's what Leo meant. The "O" bit will avail you naught if you want, for example, a boot server address. 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? 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! With apologies to the musical "Keating": "Give us back our comfy little network Take us back to safer days of yore Nothing alien or scary, la-di-da or airy-fairy Just put it back the way it was before..." Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From mohacsi at niif.hu Mon Feb 28 02:11:18 2011 From: mohacsi at niif.hu (Mohacsi Janos) Date: Mon, 28 Feb 2011 09:11:18 +0100 (CET) Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <4D69E3E8.5080404@bogus.com> <563D900A-7B72-4AC6-BE3C-473632648FAA@delong.com> <4D6AE12E.1020701@redpill-linpro.com> Message-ID: 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 > ::ffff:0:0/96 10 4 > ----8<---- Awesome! Best Regards, From dr at cluenet.de Mon Feb 28 02:28:20 2011 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 28 Feb 2011 09:28:20 +0100 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <7187091.752.1298841943188.JavaMail.franck@franck-martins-macbook-pro.local> <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> <4D6ADD0F.3070504@bogus.com> Message-ID: <20110228082820.GA2598@srv03.cluenet.de> 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: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From mansaxel at besserwisser.org Mon Feb 28 02:48:30 2011 From: mansaxel at besserwisser.org (Mans Nilsson) Date: Mon, 28 Feb 2011 09:48:30 +0100 Subject: Sunday Funnies: Using a smart phone as a diagnostic tool In-Reply-To: <25327548.48.1298858418949.JavaMail.root@benjamin.baylink.com> References: <25327548.48.1298858418949.JavaMail.root@benjamin.baylink.com> Message-ID: <20110228084830.GF10703@besserwisser.org> Subject: Sunday Funnies: Using a smart phone as a diagnostic tool Date: Sun, Feb 27, 2011 at 09:00:18PM -0500 Quoting Jay Ashworth (jra at 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From marka at isc.org Mon Feb 28 05:06:00 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 28 Feb 2011 22:06:00 +1100 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: Your message of "Mon, 28 Feb 2011 10:53:55 +1100." <1298850835.2109.33.camel@karl> References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227202208.804C6B0DF80@drugs.dv.isc.org> <20110227204511.GM27578@virtual.bogons.net> <20110227223924.DF0E3B0E741@drugs.dv.isc.org> <1298850835.2109.33.camel@karl> Message-ID: <20110228110600.81C71B24790@drugs.dv.isc.org> In message <1298850835.2109.33.camel at 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 (kauer at 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: marka at isc.org From dot at dotat.at Mon Feb 28 06:35:23 2011 From: dot at dotat.at (Tony Finch) Date: Mon, 28 Feb 2011 12:35:23 +0000 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227140321.GM9424@angus.ind.WPI.EDU> Message-ID: 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 http://dotat.at/ Trafalgar: North 5 to 7, occasionally gale 8 in Biscay. Moderate or rough. Squally showers. Good. From rdobbins at arbor.net Mon Feb 28 06:49:07 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 28 Feb 2011 12:49:07 +0000 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227140321.GM9424@angus.ind.WPI.EDU> Message-ID: <89F521A9-8481-459E-BE9F-D8915B242655@arbor.net> 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 // The basis of optimism is sheer terror. -- Oscar Wilde From smb at cs.columbia.edu Mon Feb 28 07:25:53 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Mon, 28 Feb 2011 08:25:53 -0500 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227140321.GM9424@angus.ind.WPI.EDU> <72B7B4EA-0E25-4D31-B9A1-653308E4D675@arbor.net> <071A89DA-A414-4DCC-BC47-3C86AB67EFE0@cs.columbia.edu> Message-ID: <70835095-819D-419A-830E-2B6ECCFE3102@cs.columbia.edu> 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 From jg at freedesktop.org Mon Feb 28 07:40:45 2011 From: jg at freedesktop.org (Jim Gettys) Date: Mon, 28 Feb 2011 08:40:45 -0500 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <70835095-819D-419A-830E-2B6ECCFE3102@cs.columbia.edu> References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227140321.GM9424@angus.ind.WPI.EDU> <72B7B4EA-0E25-4D31-B9A1-653308E4D675@arbor.net> <071A89DA-A414-4DCC-BC47-3C86AB67EFE0@cs.columbia.edu> <70835095-819D-419A-830E-2B6ECCFE3102@cs.columbia.edu> Message-ID: <4D6BA5DD.2050504@freedesktop.org> 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 From rdobbins at arbor.net Mon Feb 28 07:44:31 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 28 Feb 2011 13:44:31 +0000 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <4D6BA5DD.2050504@freedesktop.org> References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227140321.GM9424@angus.ind.WPI.EDU> <72B7B4EA-0E25-4D31-B9A1-653308E4D675@arbor.net> <071A89DA-A414-4DCC-BC47-3C86AB67EFE0@cs.columbia.edu> <70835095-819D-419A-830E-2B6ECCFE3102@cs.columbia.edu> <4D6BA5DD.2050504@freedesktop.org> Message-ID: <35826B01-F1D5-48CF-809E-FEC7329D1231@arbor.net> 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 // The basis of optimism is sheer terror. -- Oscar Wilde From rps at maine.edu Mon Feb 28 07:52:02 2011 From: rps at maine.edu (Ray Soucy) Date: Mon, 28 Feb 2011 08:52:02 -0500 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> References: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On Sun, Feb 27, 2011 at 11:53 PM, Franck Martin 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, Mac, and BSD will all have full IPv6 implementations, and if you don't want to use DHCPv6 for addressing you don't have to. If the goal was really to keep DNS simple for IPv6, rather than RDNSS, they should have written an autonomous anycast or multicast DNS spec rather than cluttering up RA with DNS server messages. RDNSS is a cancer IMHO and I hope we don't see it implemented. Just replace RDNSS with "DHCPv6 Light" and you get the same thing without breaking IPv6. Most of the people who want RDNSS wanted to avoid implementing DHCPv6, but its already been implemented, so I'm not sure what all the extra effort bought us, except that now we're seeing confused companies like Apple implement both RDNSS and DHCPv6 because they don't know which one will be needed. So what I'm saying here is that RDNSS is successful is doing the opposite of its goal: Instead of making IPv6 implementation more simple, they've made it more complex. DHCPv6 has nothing to do with "wanting to do things the way we always have". It has everything to do with "we might not always do things the same way we do today, so lets split this from being in RA". When it comes down to it, for hosts that provide content (servers) you'll always need a way of knowing that address. I'm sure manual IPv6 configuration works fine for you, but in something significant, say a VM cluster, I for one would rather not go back to the dark ages of manually configuring IPv6 addresses on each host. Privacy addressing is more to mask the MAC address of a host than to provide "privacy". This is because some systems are easily identifiable by their MAC address, such as Apple computers, and embedding that into the source IP provides potential attackers with a guess as to what the device is. That said, host that use both DHCPv6 and Stateless addresses will use their stateless address for new outgoing requests, by the way, effectively making the stateful address an alias. So I'm not sure what the issue is here. Apple is probably cringing at this thread going on for so long and not getting berried because of the inaccurate topic. :-) On Sun, Feb 27, 2011 at 11:53 PM, Franck Martin 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. > > ----- Original Message ----- > From: "Owen DeLong" > To: "Franck Martin" > Cc: "Matthew Palmer" , nanog at nanog.org > Sent: Sunday, 27 February, 2011 6:08:28 PM > Subject: Re: Mac OS X 10.7, still no DHCPv6 > > Look, can we stop arguing about whether someone needs DHCP or not, > whether they need SLAAC or not. Let's just get both solutions to a mature > and useful state where a network administrator can pick the one that works > best for their environment and move on. > > Devices, routers, OSs, etc. should support both. The IETF should stop letting > the two working groups focus on damaging the other protocol and we should > stop treating this as a competition or a battle and start treating it as options > to accomplish a task. > > Owen > > On Feb 27, 2011, at 1:25 PM, Franck Martin wrote: > >> Yes I don't understand why we need DHCPv6, true RD did not have DNS information to pass, but that is fixed, no? >> >> ----- Original Message ----- >> From: "Matthew Palmer" >> To: nanog at nanog.org >> Sent: Sunday, 27 February, 2011 4:06:29 PM >> Subject: Re: Mac OS X 10.7, still no DHCPv6 >> >> On Sun, Feb 27, 2011 at 08:56:33AM -0500, Ray Soucy wrote: >>> Mac OS X 10.7 does support RDNSS (RFC 5001) so it is able to get DNS >>> server information in an IPv6-only environment. ?Of course nobody else >>> has implemented that yet, making Apple a "special case" host once >>> again (I don't even think Cisco supports the option in their T series >>> yet). >> >> radvd and rdnssd work together on Linux nicely to provide RDNSS support. >> Works a treat. >> >> - Matt >> > > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From rdobbins at arbor.net Mon Feb 28 07:55:58 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 28 Feb 2011 13:55:58 +0000 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: 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 // The basis of optimism is sheer terror. -- Oscar Wilde From jg at freedesktop.org Mon Feb 28 07:58:34 2011 From: jg at freedesktop.org (Jim Gettys) Date: Mon, 28 Feb 2011 08:58:34 -0500 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <35826B01-F1D5-48CF-809E-FEC7329D1231@arbor.net> References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227140321.GM9424@angus.ind.WPI.EDU> <72B7B4EA-0E25-4D31-B9A1-653308E4D675@arbor.net> <071A89DA-A414-4DCC-BC47-3C86AB67EFE0@cs.columbia.edu> <70835095-819D-419A-830E-2B6ECCFE3102@cs.columbia.edu> <4D6BA5DD.2050504@freedesktop.org> <35826B01-F1D5-48CF-809E-FEC7329D1231@arbor.net> Message-ID: <4D6BAA0A.2090805@freedesktop.org> 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 From jabley at hopcount.ca Mon Feb 28 08:01:28 2011 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 28 Feb 2011 09:01:28 -0500 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <35826B01-F1D5-48CF-809E-FEC7329D1231@arbor.net> References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227140321.GM9424@angus.ind.WPI.EDU> <72B7B4EA-0E25-4D31-B9A1-653308E4D675@arbor.net> <071A89DA-A414-4DCC-BC47-3C86AB67EFE0@cs.columbia.edu> <70835095-819D-419A-830E-2B6ECCFE3102@cs.columbia.edu> <4D6BA5DD.2050504@freedesktop.org> <35826B01-F1D5-48CF-809E-FEC7329D1231@arbor.net> Message-ID: 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 From rdobbins at arbor.net Mon Feb 28 08:10:06 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 28 Feb 2011 14:10:06 +0000 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227140321.GM9424@angus.ind.WPI.EDU> <72B7B4EA-0E25-4D31-B9A1-653308E4D675@arbor.net> <071A89DA-A414-4DCC-BC47-3C86AB67EFE0@cs.columbia.edu> <70835095-819D-419A-830E-2B6ECCFE3102@cs.columbia.edu> <4D6BA5DD.2050504@freedesktop.org> <35826B01-F1D5-48CF-809E-FEC7329D1231@arbor.net> Message-ID: <05C2A666-A562-4E4E-B399-34C160553222@arbor.net> 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 // The basis of optimism is sheer terror. -- Oscar Wilde From jeff-kell at utc.edu Mon Feb 28 08:48:39 2011 From: jeff-kell at utc.edu (Jeff Kell) Date: Mon, 28 Feb 2011 09:48:39 -0500 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <35826B01-F1D5-48CF-809E-FEC7329D1231@arbor.net> References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227140321.GM9424@angus.ind.WPI.EDU> <72B7B4EA-0E25-4D31-B9A1-653308E4D675@arbor.net> <071A89DA-A414-4DCC-BC47-3C86AB67EFE0@cs.columbia.edu> <70835095-819D-419A-830E-2B6ECCFE3102@cs.columbia.edu> <4D6BA5DD.2050504@freedesktop.org> <35826B01-F1D5-48CF-809E-FEC7329D1231@arbor.net> Message-ID: <4D6BB5C7.8050009@utc.edu> 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 From nick at foobar.org Mon Feb 28 08:51:07 2011 From: nick at foobar.org (Nick Hilliard) Date: Mon, 28 Feb 2011 14:51:07 +0000 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4D6BB65B.8050309@foobar.org> 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 From jra at baylink.com Mon Feb 28 08:51:39 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 28 Feb 2011 09:51:39 -0500 (EST) Subject: Sunday Funnies: Using a smart phone as a diagnostic tool In-Reply-To: Message-ID: <20015514.184.1298904699196.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Joshua William Klubi" > On Mon, Feb 28, 2011 at 2:00 AM, Jay Ashworth 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 From bjohnson at drtel.com Mon Feb 28 08:53:04 2011 From: bjohnson at drtel.com (Brian Johnson) Date: Mon, 28 Feb 2011 14:53:04 +0000 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <4D6BB5C7.8050009@utc.edu> References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227140321.GM9424@angus.ind.WPI.EDU> <72B7B4EA-0E25-4D31-B9A1-653308E4D675@arbor.net> <071A89DA-A414-4DCC-BC47-3C86AB67EFE0@cs.columbia.edu> <70835095-819D-419A-830E-2B6ECCFE3102@cs.columbia.edu> <4D6BA5DD.2050504@freedesktop.org> <35826B01-F1D5-48CF-809E-FEC7329D1231@arbor.net> <4D6BB5C7.8050009@utc.edu> Message-ID: >-----Original Message----- >From: Jeff Kell [mailto:jeff-kell at 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 From jabley at hopcount.ca Mon Feb 28 08:59:42 2011 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 28 Feb 2011 09:59:42 -0500 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <4D6BB65B.8050309@foobar.org> References: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> <4D6BB65B.8050309@foobar.org> Message-ID: <28D10D13-988B-4C7D-833B-EBA6E1BC1A63@hopcount.ca> 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 From jabley at hopcount.ca Mon Feb 28 09:04:23 2011 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 28 Feb 2011 10:04:23 -0500 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227140321.GM9424@angus.ind.WPI.EDU> <72B7B4EA-0E25-4D31-B9A1-653308E4D675@arbor.net> <071A89DA-A414-4DCC-BC47-3C86AB67EFE0@cs.columbia.edu> <70835095-819D-419A-830E-2B6ECCFE3102@cs.columbia.edu> <4D6BA5DD.2050504@freedesktop.org> <35826B01-F1D5-48CF-809E-FEC7329D1231@arbor.net> <4D6BB5C7.8050009@utc.edu> Message-ID: <77274A15-7E08-484E-921D-2E527D5B0364@hopcount.ca> 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 From rdobbins at arbor.net Mon Feb 28 09:11:14 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 28 Feb 2011 15:11:14 +0000 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <28D10D13-988B-4C7D-833B-EBA6E1BC1A63@hopcount.ca> References: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> <4D6BB65B.8050309@foobar.org> <28D10D13-988B-4C7D-833B-EBA6E1BC1A63@hopcount.ca> Message-ID: <4EA51BD5-F15F-48E9-8EBB-087DAB1610B8@arbor.net> 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 // The basis of optimism is sheer terror. -- Oscar Wilde From nick at foobar.org Mon Feb 28 09:27:00 2011 From: nick at foobar.org (Nick Hilliard) Date: Mon, 28 Feb 2011 15:27:00 +0000 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <28D10D13-988B-4C7D-833B-EBA6E1BC1A63@hopcount.ca> References: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> <4D6BB65B.8050309@foobar.org> <28D10D13-988B-4C7D-833B-EBA6E1BC1A63@hopcount.ca> Message-ID: <4D6BBEC4.9050403@foobar.org> 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 From owen at delong.com Mon Feb 28 09:27:18 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 28 Feb 2011 07:27:18 -0800 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <35826B01-F1D5-48CF-809E-FEC7329D1231@arbor.net> References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227140321.GM9424@angus.ind.WPI.EDU> <72B7B4EA-0E25-4D31-B9A1-653308E4D675@arbor.net> <071A89DA-A414-4DCC-BC47-3C86AB67EFE0@cs.columbia.edu> <70835095-819D-419A-830E-2B6ECCFE3102@cs.columbia.edu> <4D6BA5DD.2050504@freedesktop.org> <35826B01-F1D5-48CF-809E-FEC7329D1231@arbor.net> Message-ID: 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 From jabley at hopcount.ca Mon Feb 28 09:34:54 2011 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 28 Feb 2011 10:34:54 -0500 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <4D6BBEC4.9050403@foobar.org> References: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> <4D6BB65B.8050309@foobar.org> <28D10D13-988B-4C7D-833B-EBA6E1BC1A63@hopcount.ca> <4D6BBEC4.9050403@foobar.org> Message-ID: <19B340FC-F628-4535-992C-D39D84CE99BD@hopcount.ca> 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 From rdobbins at arbor.net Mon Feb 28 09:39:45 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 28 Feb 2011 15:39:45 +0000 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227140321.GM9424@angus.ind.WPI.EDU> <72B7B4EA-0E25-4D31-B9A1-653308E4D675@arbor.net> <071A89DA-A414-4DCC-BC47-3C86AB67EFE0@cs.columbia.edu> <70835095-819D-419A-830E-2B6ECCFE3102@cs.columbia.edu> <4D6BA5DD.2050504@freedesktop.org> <35826B01-F1D5-48CF-809E-FEC7329D1231@arbor.net> Message-ID: 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 // The basis of optimism is sheer terror. -- Oscar Wilde From rdobbins at arbor.net Mon Feb 28 09:45:31 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 28 Feb 2011 15:45:31 +0000 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <4D6BBEC4.9050403@foobar.org> References: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> <4D6BB65B.8050309@foobar.org> <28D10D13-988B-4C7D-833B-EBA6E1BC1A63@hopcount.ca> <4D6BBEC4.9050403@foobar.org> Message-ID: 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 // The basis of optimism is sheer terror. -- Oscar Wilde From owen at delong.com Mon Feb 28 10:01:47 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 28 Feb 2011 08:01:47 -0800 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: > 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 some things right in the first half of that paragraph, there are real world problems with the approach in the second half and there are changes that are needed. RDNSS is a positive step in the right direction (making router-centric host configuration more viable). Making server-centric configuration more viable is also necessary. > 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. > That's all great in a purely theoretical world or a small organization. In the real world, there are many organizations for whom that set of tradeoffs and combination of dependencies is far from optimal. > 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. > Which is a major change in the administrative boundaries for the vast majority of enterprises. Such changes may not be so welcome at the layer 8-10 levels of the stack and may, indeed, create substantial resistance to deployment. > 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. > Only in theoretical implementations or implementations where the routers and host policy are administered by the same organization. > 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? > Which is why it would be better if RA supported a more flexible set of host configuration options rather than just cobbling DNS onto it. > 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. > I guess that really depends on your perspective. In the real world, it does a better job of keeping IPv6 from getting deployed in the enterprise. > 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 framing of the issue utterly ignores the reality of how things are handled in the real world and what happens in the enterprise environment across organizational boundaries. > 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." > It certainly was such a war for some time in the IETF and it was carried out in a way that much damage was done to both sides of the equation. The end result is a construct with a very limited set of choices for implementers almost all of which include cross-organizational interdependency in most enterprise environments that will create continuing friction and exacerbate the usual level of dysfunction. > Thankfully, with Apple seemingly supporting DHCPv6, that means > Windows, Linux, Mac, and BSD will all have full IPv6 implementations, > and if you don't want to use DHCPv6 for addressing you don't have to. > However, if you want to put host policy completely in the hands of the host administrators, you still can't. If you want to have the router administration group provide a complete set of host parameters, you still can't. The only way to provide a complete set of host configuration information through automated processes is to get some fraction from the routers and some fraction from other servers. This should be improved. > If the goal was really to keep DNS simple for IPv6, rather than RDNSS, > they should have written an autonomous anycast or multicast DNS spec > rather than cluttering up RA with DNS server messages. RDNSS is a > cancer IMHO and I hope we don't see it implemented. > We can agree to disagree. > > DHCPv6 has nothing to do with "wanting to do things the way we always > have". It has everything to do with "we might not always do things > the same way we do today, so lets split this from being in RA". When > it comes down to it, for hosts that provide content (servers) you'll > always need a way of knowing that address. I'm sure manual IPv6 > configuration works fine for you, but in something significant, say a > VM cluster, I for one would rather not go back to the dark ages of > manually configuring IPv6 addresses on each host. > True, as far as it goes, but, there is also an issue of not wanting to completely redesign the org-chart because IPv6 is utterly dysfunctional with the current organizational boundaries. In some organizations, you have to get up to the point of a VP before you find common management shared by the groups that have to cooperate in the current implementation. The average VP regards the details of host configuration relatively below his pay grade and will likely consider any protocol that requires major changes to his org chart to be, well, broken. > Privacy addressing is more to mask the MAC address of a host than to > provide "privacy". This is because some systems are easily > identifiable by their MAC address, such as Apple computers, and > embedding that into the source IP provides potential attackers with a > guess as to what the device is. That said, host that use both DHCPv6 > and Stateless addresses will use their stateless address for new > outgoing requests, by the way, effectively making the stateful address > an alias. So I'm not sure what the issue is here. > Uh, no, it's more to mask the MAC address of devices that move around so that you can't track their movement easily by matching up the last 64 bits of their IPv6 address and using the first 64 as a location identifier. > Apple is probably cringing at this thread going on for so long and not > getting berried because of the inaccurate topic. :-) > Whether or not Apple is cringing, this thread (or something like it) will probably continue until theory and implementation in IPv6 advance to the point of matching reality. Owen From nick at foobar.org Mon Feb 28 10:15:24 2011 From: nick at foobar.org (Nick Hilliard) Date: Mon, 28 Feb 2011 16:15:24 +0000 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> <4D6BB65B.8050309@foobar.org> <28D10D13-988B-4C7D-833B-EBA6E1BC1A63@hopcount.ca> <4D6BBEC4.9050403@foobar.org> Message-ID: <4D6BCA1C.30206@foobar.org> 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 From owen at delong.com Mon Feb 28 10:14:24 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 28 Feb 2011 08:14:24 -0800 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <28D10D13-988B-4C7D-833B-EBA6E1BC1A63@hopcount.ca> References: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> <4D6BB65B.8050309@foobar.org> <28D10D13-988B-4C7D-833B-EBA6E1BC1A63@hopcount.ca> Message-ID: <7B8766B1-55EC-49C1-BCCA-E6D0917EA63A@delong.com> 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 From rps at maine.edu Mon Feb 28 10:29:54 2011 From: rps at maine.edu (Ray Soucy) Date: Mon, 28 Feb 2011 11:29:54 -0500 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: 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 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 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 some things right in the first half of that paragraph, > there are real world problems with the approach in the second half > and there are changes that are needed. RDNSS is a positive step > in the right direction (making router-centric host configuration > more viable). Making server-centric configuration more viable > is also necessary. > >> 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. >> > That's all great in a purely theoretical world or a small organization. > In the real world, there are many organizations for whom that set of > tradeoffs and combination of dependencies is far from optimal. > >> 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. >> > Which is a major change in the administrative boundaries for the vast > majority of enterprises. Such changes may not be so welcome at the > layer 8-10 levels of the stack and may, indeed, create substantial > resistance to deployment. > >> 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. >> > Only in theoretical implementations or implementations where the routers > and host policy are administered by the same organization. > >> 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? >> > Which is why it would be better if RA supported a more flexible set > of host configuration options rather than just cobbling DNS onto it. > >> 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. >> > I guess that really depends on your perspective. In the real world, it > does a better job of keeping IPv6 from getting deployed in the enterprise. > >> 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 framing of the issue utterly ignores the reality of how things are > handled in the real world and what happens in the enterprise > environment across organizational boundaries. > >> 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." >> > It certainly was such a war for some time in the IETF and it was > carried out in a way that much damage was done to both sides > of the equation. > > The end result is a construct with a very limited set of choices > for implementers almost all of which include cross-organizational > interdependency in most enterprise environments that will create > continuing friction and exacerbate the usual level of dysfunction. > >> Thankfully, with Apple seemingly supporting DHCPv6, that means >> Windows, Linux, Mac, and BSD will all have full IPv6 implementations, >> and if you don't want to use DHCPv6 for addressing you don't have to. >> > However, if you want to put host policy completely in the hands of the > host administrators, you still can't. > > If you want to have the router administration group provide a complete > set of host parameters, you still can't. > > The only way to provide a complete set of host configuration information > through automated processes is to get some fraction from the routers > and some fraction from other servers. This should be improved. > >> If the goal was really to keep DNS simple for IPv6, rather than RDNSS, >> they should have written an autonomous anycast or multicast DNS spec >> rather than cluttering up RA with DNS server messages. ?RDNSS is a >> cancer IMHO and I hope we don't see it implemented. >> > We can agree to disagree. >> >> DHCPv6 has nothing to do with "wanting to do things the way we always >> have". ?It has everything to do with "we might not always do things >> the same way we do today, so lets split this from being in RA". ?When >> it comes down to it, for hosts that provide content (servers) you'll >> always need a way of knowing that address. ?I'm sure manual IPv6 >> configuration works fine for you, but in something significant, say a >> VM cluster, I for one would rather not go back to the dark ages of >> manually configuring IPv6 addresses on each host. >> > True, as far as it goes, but, there is also an issue of not wanting to > completely redesign the org-chart because IPv6 is utterly dysfunctional > with the current organizational boundaries. In some organizations, > you have to get up to the point of a VP before you find common > management shared by the groups that have to cooperate in the > current implementation. The average VP regards the details of > host configuration relatively below his pay grade and will likely > consider any protocol that requires major changes to his org > chart to be, well, broken. > >> Privacy addressing is more to mask the MAC address of a host than to >> provide "privacy". ?This is because some systems are easily >> identifiable by their MAC address, such as Apple computers, and >> embedding that into the source IP provides potential attackers with a >> guess as to what the device is. ?That said, host that use both DHCPv6 >> and Stateless addresses will use their stateless address for new >> outgoing requests, by the way, effectively making the stateful address >> an alias. ?So I'm not sure what the issue is here. >> > Uh, no, it's more to mask the MAC address of devices that move around > so that you can't track their movement easily by matching up the last 64 bits > of their IPv6 address and using the first 64 as a location identifier. > >> Apple is probably cringing at this thread going on for so long and not >> getting berried because of the inaccurate topic. :-) >> > Whether or not Apple is cringing, this thread (or something like it) will > probably continue until theory and implementation in IPv6 advance > to the point of matching reality. > > Owen > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From rdobbins at arbor.net Mon Feb 28 10:34:34 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 28 Feb 2011 16:34:34 +0000 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <7B8766B1-55EC-49C1-BCCA-E6D0917EA63A@delong.com> References: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> <4D6BB65B.8050309@foobar.org> <28D10D13-988B-4C7D-833B-EBA6E1BC1A63@hopcount.ca> <7B8766B1-55EC-49C1-BCCA-E6D0917EA63A@delong.com> Message-ID: <753A3C00-D74B-4D88-8783-BFA127806F25@arbor.net> 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 // The basis of optimism is sheer terror. -- Oscar Wilde From rdobbins at arbor.net Mon Feb 28 10:36:45 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 28 Feb 2011 16:36:45 +0000 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <4D6BCA1C.30206@foobar.org> References: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> <4D6BB65B.8050309@foobar.org> <28D10D13-988B-4C7D-833B-EBA6E1BC1A63@hopcount.ca> <4D6BBEC4.9050403@foobar.org> <4D6BCA1C.30206@foobar.org> Message-ID: <7C2298B4-D015-4024-91EB-1F8BD9ED3F30@arbor.net> 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 // The basis of optimism is sheer terror. -- Oscar Wilde From owen at delong.com Mon Feb 28 10:40:03 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 28 Feb 2011 08:40:03 -0800 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <19B340FC-F628-4535-992C-D39D84CE99BD@hopcount.ca> References: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> <4D6BB65B.8050309@foobar.org> <28D10D13-988B-4C7D-833B-EBA6E1BC1A63@hopcount.ca> <4D6BBEC4.9050403@foobar.org> <19B340FC-F628-4535-992C-D39D84CE99BD@hopcount.ca> Message-ID: 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 From Valdis.Kletnieks at vt.edu Mon Feb 28 10:57:09 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 28 Feb 2011 11:57:09 -0500 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: Your message of "Mon, 28 Feb 2011 10:04:23 EST." <77274A15-7E08-484E-921D-2E527D5B0364@hopcount.ca> References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227140321.GM9424@angus.ind.WPI.EDU> <72B7B4EA-0E25-4D31-B9A1-653308E4D675@arbor.net> <071A89DA-A414-4DCC-BC47-3C86AB67EFE0@cs.columbia.edu> <70835095-819D-419A-830E-2B6ECCFE3102@cs.columbia.edu> <4D6BA5DD.2050504@freedesktop.org> <35826B01-F1D5-48CF-809E-FEC7329D1231@arbor.net> <4D6BB5C7.8050009@utc.edu> <77274A15-7E08-484E-921D-2E527D5B0364@hopcount.ca> Message-ID: <13034.1298912229@localhost> 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...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From leigh.porter at ukbroadband.com Mon Feb 28 11:12:35 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Mon, 28 Feb 2011 17:12:35 +0000 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <13034.1298912229@localhost> References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227140321.GM9424@angus.ind.WPI.EDU> <72B7B4EA-0E25-4D31-B9A1-653308E4D675@arbor.net> <071A89DA-A414-4DCC-BC47-3C86AB67EFE0@cs.columbia.edu> <70835095-819D-419A-830E-2B6ECCFE3102@cs.columbia.edu> <4D6BA5DD.2050504@freedesktop.org> <35826B01-F1D5-48CF-809E-FEC7329D1231@arbor.net> <4D6BB5C7.8050009@utc.edu> <77274A15-7E08-484E-921D-2E527D5B0364@hopcount.ca> <13034.1298912229@localhost> Message-ID: <4E35742A-163F-4613-AB08-FD669924D389@ukbroadband.com> On 28 Feb 2011, at 16:57, Valdis.Kletnieks at 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 From brunner at nic-naa.net Mon Feb 28 11:25:56 2011 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Mon, 28 Feb 2011 12:25:56 -0500 Subject: OT: What vexes VoIP users? Message-ID: <4D6BDAA4.1080002@nic-naa.net> 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 From nathan at atlasnetworks.us Mon Feb 28 11:32:32 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Mon, 28 Feb 2011 17:32:32 +0000 Subject: What vexes VoIP users? In-Reply-To: <4D6BDAA4.1080002@nic-naa.net> References: <4D6BDAA4.1080002@nic-naa.net> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B3A5EEB@ex-mb-1.corp.atlasnetworks.us> 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). From cb.list6 at gmail.com Mon Feb 28 11:42:27 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Mon, 28 Feb 2011 09:42:27 -0800 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> <4D6BB65B.8050309@foobar.org> <28D10D13-988B-4C7D-833B-EBA6E1BC1A63@hopcount.ca> <4D6BBEC4.9050403@foobar.org> <19B340FC-F628-4535-992C-D39D84CE99BD@hopcount.ca> Message-ID: On Feb 28, 2011 8:45 AM, "Owen DeLong" 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 > > From nanog at ilk.net Mon Feb 28 11:55:41 2011 From: nanog at ilk.net (nanog at ilk.net) Date: Mon, 28 Feb 2011 18:55:41 +0100 Subject: What vexes VoIP users? In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B3A5EEB@ex-mb-1.corp.atlasnetworks.us> References: <4D6BDAA4.1080002@nic-naa.net> <8C26A4FDAE599041A13EB499117D3C286B3A5EEB@ex-mb-1.corp.atlasnetworks.us> Message-ID: <344A1A048FD34A6FAAA3F4BACD19C138@intra.ilk.net> 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:nathan at 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). From leigh.porter at ukbroadband.com Mon Feb 28 12:17:44 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Mon, 28 Feb 2011 18:17:44 +0000 Subject: What vexes VoIP users? In-Reply-To: <344A1A048FD34A6FAAA3F4BACD19C138@intra.ilk.net> References: <4D6BDAA4.1080002@nic-naa.net> <8C26A4FDAE599041A13EB499117D3C286B3A5EEB@ex-mb-1.corp.atlasnetworks.us> <344A1A048FD34A6FAAA3F4BACD19C138@intra.ilk.net> Message-ID: <05801A27-7430-483F-A542-EDAC312FE173@ukbroadband.com> 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, 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:nathan at 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). > > From bclark at spectraaccess.com Mon Feb 28 12:29:08 2011 From: bclark at spectraaccess.com (Bret Clark) Date: Mon, 28 Feb 2011 13:29:08 -0500 Subject: What vexes VoIP users? In-Reply-To: <05801A27-7430-483F-A542-EDAC312FE173@ukbroadband.com> References: <4D6BDAA4.1080002@nic-naa.net> <8C26A4FDAE599041A13EB499117D3C286B3A5EEB@ex-mb-1.corp.atlasnetworks.us> <344A1A048FD34A6FAAA3F4BACD19C138@intra.ilk.net> <05801A27-7430-483F-A542-EDAC312FE173@ukbroadband.com> Message-ID: <4D6BE974.5060402@spectraaccess.com> 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! From Valdis.Kletnieks at vt.edu Mon Feb 28 12:37:43 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 28 Feb 2011 13:37:43 -0500 Subject: What vexes VoIP users? In-Reply-To: Your message of "Mon, 28 Feb 2011 13:29:08 EST." <4D6BE974.5060402@spectraaccess.com> References: <4D6BDAA4.1080002@nic-naa.net> <8C26A4FDAE599041A13EB499117D3C286B3A5EEB@ex-mb-1.corp.atlasnetworks.us> <344A1A048FD34A6FAAA3F4BACD19C138@intra.ilk.net> <05801A27-7430-483F-A542-EDAC312FE173@ukbroadband.com> <4D6BE974.5060402@spectraaccess.com> Message-ID: <18237.1298918263@localhost> 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? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From khelms at ispalliance.net Mon Feb 28 12:41:13 2011 From: khelms at ispalliance.net (Scott Helms) Date: Mon, 28 Feb 2011 13:41:13 -0500 Subject: What vexes VoIP users? In-Reply-To: <4D6BE974.5060402@spectraaccess.com> References: <4D6BDAA4.1080002@nic-naa.net> <8C26A4FDAE599041A13EB499117D3C286B3A5EEB@ex-mb-1.corp.atlasnetworks.us> <344A1A048FD34A6FAAA3F4BACD19C138@intra.ilk.net> <05801A27-7430-483F-A542-EDAC312FE173@ukbroadband.com> <4D6BE974.5060402@spectraaccess.com> Message-ID: <4D6BEC49.3090804@ispalliance.net> 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 -------------------------------- From leigh.porter at ukbroadband.com Mon Feb 28 12:45:52 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Mon, 28 Feb 2011 18:45:52 +0000 Subject: What vexes VoIP users? In-Reply-To: <4D6BE974.5060402@spectraaccess.com> References: <4D6BDAA4.1080002@nic-naa.net> <8C26A4FDAE599041A13EB499117D3C286B3A5EEB@ex-mb-1.corp.atlasnetworks.us> <344A1A048FD34A6FAAA3F4BACD19C138@intra.ilk.net> <05801A27-7430-483F-A542-EDAC312FE173@ukbroadband.com> <4D6BE974.5060402@spectraaccess.com> Message-ID: <53AC0594-E830-4FCD-B5ED-82D2A74ADE83@ukbroadband.com> 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 From leigh.porter at ukbroadband.com Mon Feb 28 12:48:51 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Mon, 28 Feb 2011 18:48:51 +0000 Subject: What vexes VoIP users? In-Reply-To: <18237.1298918263@localhost> References: <4D6BDAA4.1080002@nic-naa.net> <8C26A4FDAE599041A13EB499117D3C286B3A5EEB@ex-mb-1.corp.atlasnetworks.us> <344A1A048FD34A6FAAA3F4BACD19C138@intra.ilk.net> <05801A27-7430-483F-A542-EDAC312FE173@ukbroadband.com> <4D6BE974.5060402@spectraaccess.com> <18237.1298918263@localhost> Message-ID: On 28 Feb 2011, at 18:37, Valdis.Kletnieks at 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 From khelms at ispalliance.net Mon Feb 28 12:54:04 2011 From: khelms at ispalliance.net (Scott Helms) Date: Mon, 28 Feb 2011 13:54:04 -0500 Subject: What vexes VoIP users? In-Reply-To: <53AC0594-E830-4FCD-B5ED-82D2A74ADE83@ukbroadband.com> References: <4D6BDAA4.1080002@nic-naa.net> <8C26A4FDAE599041A13EB499117D3C286B3A5EEB@ex-mb-1.corp.atlasnetworks.us> <344A1A048FD34A6FAAA3F4BACD19C138@intra.ilk.net> <05801A27-7430-483F-A542-EDAC312FE173@ukbroadband.com> <4D6BE974.5060402@spectraaccess.com> <53AC0594-E830-4FCD-B5ED-82D2A74ADE83@ukbroadband.com> Message-ID: <4D6BEF4C.1050008@ispalliance.net> 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 -------------------------------- From jakari at bithose.com Mon Feb 28 13:03:01 2011 From: jakari at bithose.com (Jameel Akari) Date: Mon, 28 Feb 2011 14:03:01 -0500 (EST) Subject: What vexes VoIP users? In-Reply-To: References: <4D6BDAA4.1080002@nic-naa.net> <8C26A4FDAE599041A13EB499117D3C286B3A5EEB@ex-mb-1.corp.atlasnetworks.us> <344A1A048FD34A6FAAA3F4BACD19C138@intra.ilk.net> <05801A27-7430-483F-A542-EDAC312FE173@ukbroadband.com> <4D6BE974.5060402@spectraaccess.com> <18237.1298918263@localhost> Message-ID: On Mon, 28 Feb 2011, Leigh Porter wrote: > On 28 Feb 2011, at 18:37, Valdis.Kletnieks at 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 From bret at getjive.com Mon Feb 28 13:11:39 2011 From: bret at getjive.com (Bret Palsson) Date: Mon, 28 Feb 2011 12:11:39 -0700 Subject: What vexes VoIP users? In-Reply-To: <18237.1298918263@localhost> References: <4D6BDAA4.1080002@nic-naa.net> <8C26A4FDAE599041A13EB499117D3C286B3A5EEB@ex-mb-1.corp.atlasnetworks.us> <344A1A048FD34A6FAAA3F4BACD19C138@intra.ilk.net> <05801A27-7430-483F-A542-EDAC312FE173@ukbroadband.com> <4D6BE974.5060402@spectraaccess.com> <18237.1298918263@localhost> Message-ID: <6D8BB8D2-3401-45C2-8E4C-3E1FA41502C1@getjive.com> 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.Kletnieks at 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? > From leigh.porter at ukbroadband.com Mon Feb 28 13:15:44 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Mon, 28 Feb 2011 19:15:44 +0000 Subject: What vexes VoIP users? In-Reply-To: References: <4D6BDAA4.1080002@nic-naa.net> <8C26A4FDAE599041A13EB499117D3C286B3A5EEB@ex-mb-1.corp.atlasnetworks.us> <344A1A048FD34A6FAAA3F4BACD19C138@intra.ilk.net> <05801A27-7430-483F-A542-EDAC312FE173@ukbroadband.com> <4D6BE974.5060402@spectraaccess.com> <18237.1298918263@localhost> Message-ID: <19AD2F36-0B8A-415C-89EC-50433ED593E5@ukbroadband.com> 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 From owen at delong.com Mon Feb 28 13:25:48 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 28 Feb 2011 11:25:48 -0800 Subject: What vexes VoIP users? In-Reply-To: <6D8BB8D2-3401-45C2-8E4C-3E1FA41502C1@getjive.com> References: <4D6BDAA4.1080002@nic-naa.net> <8C26A4FDAE599041A13EB499117D3C286B3A5EEB@ex-mb-1.corp.atlasnetworks.us> <344A1A048FD34A6FAAA3F4BACD19C138@intra.ilk.net> <05801A27-7430-483F-A542-EDAC312FE173@ukbroadband.com> <4D6BE974.5060402@spectraaccess.com> <18237.1298918263@localhost> <6D8BB8D2-3401-45C2-8E4C-3E1FA41502C1@getjive.com> Message-ID: <9EA8D67A-6A1D-4500-AA1E-9062979B587D@delong.com> 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.Kletnieks at 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? >> > From bret at getjive.com Mon Feb 28 13:30:19 2011 From: bret at getjive.com (Bret Palsson) Date: Mon, 28 Feb 2011 12:30:19 -0700 Subject: What vexes VoIP users? In-Reply-To: <9EA8D67A-6A1D-4500-AA1E-9062979B587D@delong.com> References: <4D6BDAA4.1080002@nic-naa.net> <8C26A4FDAE599041A13EB499117D3C286B3A5EEB@ex-mb-1.corp.atlasnetworks.us> <344A1A048FD34A6FAAA3F4BACD19C138@intra.ilk.net> <05801A27-7430-483F-A542-EDAC312FE173@ukbroadband.com> <4D6BE974.5060402@spectraaccess.com> <18237.1298918263@localhost> <6D8BB8D2-3401-45C2-8E4C-3E1FA41502C1@getjive.com> <9EA8D67A-6A1D-4500-AA1E-9062979B587D@delong.com> Message-ID: <8E52DD4B-BA43-4436-9350-26569DD932AC@getjive.com> 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.Kletnieks at 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? >>> >> > From bret at getjive.com Mon Feb 28 13:34:42 2011 From: bret at getjive.com (Bret Palsson) Date: Mon, 28 Feb 2011 12:34:42 -0700 Subject: What vexes VoIP users? In-Reply-To: <9EA8D67A-6A1D-4500-AA1E-9062979B587D@delong.com> References: <4D6BDAA4.1080002@nic-naa.net> <8C26A4FDAE599041A13EB499117D3C286B3A5EEB@ex-mb-1.corp.atlasnetworks.us> <344A1A048FD34A6FAAA3F4BACD19C138@intra.ilk.net> <05801A27-7430-483F-A542-EDAC312FE173@ukbroadband.com> <4D6BE974.5060402@spectraaccess.com> <18237.1298918263@localhost> <6D8BB8D2-3401-45C2-8E4C-3E1FA41502C1@getjive.com> <9EA8D67A-6A1D-4500-AA1E-9062979B587D@delong.com> Message-ID: 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.Kletnieks at 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? >>> >> > From nathan at atlasnetworks.us Mon Feb 28 13:41:14 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Mon, 28 Feb 2011 19:41:14 +0000 Subject: What vexes VoIP users? In-Reply-To: <9EA8D67A-6A1D-4500-AA1E-9062979B587D@delong.com> References: <4D6BDAA4.1080002@nic-naa.net> <8C26A4FDAE599041A13EB499117D3C286B3A5EEB@ex-mb-1.corp.atlasnetworks.us> <344A1A048FD34A6FAAA3F4BACD19C138@intra.ilk.net> <05801A27-7430-483F-A542-EDAC312FE173@ukbroadband.com> <4D6BE974.5060402@spectraaccess.com> <18237.1298918263@localhost> <6D8BB8D2-3401-45C2-8E4C-3E1FA41502C1@getjive.com> <9EA8D67A-6A1D-4500-AA1E-9062979B587D@delong.com> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B3A627E@ex-mb-1.corp.atlasnetworks.us> 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:owen at delong.com] > Sent: Monday, February 28, 2011 11:26 AM > To: Bret Palsson > Cc: nanog at 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.Kletnieks at 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? > >> > > > > > > From bret at getjive.com Mon Feb 28 13:45:10 2011 From: bret at getjive.com (Bret Palsson) Date: Mon, 28 Feb 2011 12:45:10 -0700 Subject: What vexes VoIP users? In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B3A627E@ex-mb-1.corp.atlasnetworks.us> References: <4D6BDAA4.1080002@nic-naa.net> <8C26A4FDAE599041A13EB499117D3C286B3A5EEB@ex-mb-1.corp.atlasnetworks.us> <344A1A048FD34A6FAAA3F4BACD19C138@intra.ilk.net> <05801A27-7430-483F-A542-EDAC312FE173@ukbroadband.com> <4D6BE974.5060402@spectraaccess.com> <18237.1298918263@localhost> <6D8BB8D2-3401-45C2-8E4C-3E1FA41502C1@getjive.com> <9EA8D67A-6A1D-4500-AA1E-9062979B587D@delong.com> <8C26A4FDAE599041A13EB499117D3C286B3A627E@ex-mb-1.corp.atlasnetworks.us> Message-ID: <4E486520-659A-4A2D-AD42-2B332314CD01@getjive.com> 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? From randy at psg.com Mon Feb 28 14:27:04 2011 From: randy at psg.com (Randy Bush) Date: Tue, 01 Mar 2011 05:27:04 +0900 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <28D10D13-988B-4C7D-833B-EBA6E1BC1A63@hopcount.ca> References: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> <4D6BB65B.8050309@foobar.org> <28D10D13-988B-4C7D-833B-EBA6E1BC1A63@hopcount.ca> Message-ID: > 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 From jabley at hopcount.ca Mon Feb 28 14:34:46 2011 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 28 Feb 2011 15:34:46 -0500 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> <4D6BB65B.8050309@foobar.org> <28D10D13-988B-4C7D-833B-EBA6E1BC1A63@hopcount.ca> Message-ID: 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 From brian.e.carpenter at gmail.com Mon Feb 28 14:35:49 2011 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Tue, 01 Mar 2011 09:35:49 +1300 Subject: What If.... In-Reply-To: <2A4D7751-CAD5-4B40-B827-94E8BCD296F6@sfc.keio.ac.jp> References: <2A4D7751-CAD5-4B40-B827-94E8BCD296F6@sfc.keio.ac.jp> Message-ID: <4D6C0725.3010005@gmail.com> 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 From randy at psg.com Mon Feb 28 14:38:25 2011 From: randy at psg.com (Randy Bush) Date: Tue, 01 Mar 2011 05:38:25 +0900 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> <4D6BB65B.8050309@foobar.org> <28D10D13-988B-4C7D-833B-EBA6E1BC1A63@hopcount.ca> Message-ID: >> 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 From jeff-kell at utc.edu Mon Feb 28 14:39:10 2011 From: jeff-kell at utc.edu (Jeff Kell) Date: Mon, 28 Feb 2011 15:39:10 -0500 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> References: <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4D6C07EE.6020400@utc.edu> 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 From jabley at hopcount.ca Mon Feb 28 14:41:27 2011 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 28 Feb 2011 15:41:27 -0500 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> <4D6BB65B.8050309@foobar.org> <28D10D13-988B-4C7D-833B-EBA6E1BC1A63@hopcount.ca> Message-ID: <242E62DA-190D-4BFB-8892-81FF9711E9B2@hopcount.ca> 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 From gbonser at seven.com Mon Feb 28 14:42:28 2011 From: gbonser at seven.com (George Bonser) Date: Mon, 28 Feb 2011 12:42:28 -0800 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com><27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local><4D6BB65B.8050309@foobar.org><28D10D13-988B-4C7D-833B-EBA6E1BC1A63@hopcount.ca> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13DF9@RWC-EX1.corp.seven.com> > 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 From randy at psg.com Mon Feb 28 14:45:26 2011 From: randy at psg.com (Randy Bush) Date: Tue, 01 Mar 2011 05:45:26 +0900 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13DF9@RWC-EX1.corp.seven.com> References: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> <4D6BB65B.8050309@foobar.org> <28D10D13-988B-4C7D-833B-EBA6E1BC1A63@hopcount.ca> <5A6D953473350C4B9995546AFE9939EE0BC13DF9@RWC-EX1.corp.seven.com> Message-ID: > 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. the scenario i think of here is the enterprise which wishes not to use private space so deploys v6-only internally, and nat64 at the border to a dual-stack provider. randy From Ed.Lewis at neustar.biz Mon Feb 28 14:50:01 2011 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 28 Feb 2011 15:50:01 -0500 Subject: What If.... In-Reply-To: <4D6C0725.3010005@gmail.com> References: <2A4D7751-CAD5-4B40-B827-94E8BCD296F6@sfc.keio.ac.jp> <4D6C0725.3010005@gmail.com> Message-ID: 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! -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From jared at puck.nether.net Mon Feb 28 15:00:53 2011 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 28 Feb 2011 16:00:53 -0500 Subject: What vexes VoIP users? In-Reply-To: References: <4D6BDAA4.1080002@nic-naa.net> <8C26A4FDAE599041A13EB499117D3C286B3A5EEB@ex-mb-1.corp.atlasnetworks.us> <344A1A048FD34A6FAAA3F4BACD19C138@intra.ilk.net> <05801A27-7430-483F-A542-EDAC312FE173@ukbroadband.com> <4D6BE974.5060402@spectraaccess.com> <18237.1298918263@localhost> <6D8BB8D2-3401-45C2-8E4C-3E1FA41502C1@getjive.com> <9EA8D67A-6A1D-4500-AA1E-9062979B587D@delong.com> Message-ID: 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 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 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.Kletnieks at 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? >>>> >>> >> > > From jared at puck.nether.net Mon Feb 28 15:02:29 2011 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 28 Feb 2011 16:02:29 -0500 Subject: What vexes VoIP users? In-Reply-To: <4E486520-659A-4A2D-AD42-2B332314CD01@getjive.com> References: <4D6BDAA4.1080002@nic-naa.net> <8C26A4FDAE599041A13EB499117D3C286B3A5EEB@ex-mb-1.corp.atlasnetworks.us> <344A1A048FD34A6FAAA3F4BACD19C138@intra.ilk.net> <05801A27-7430-483F-A542-EDAC312FE173@ukbroadband.com> <4D6BE974.5060402@spectraaccess.com> <18237.1298918263@localhost> <6D8BB8D2-3401-45C2-8E4C-3E1FA41502C1@getjive.com> <9EA8D67A-6A1D-4500-AA1E-9062979B587D@delong.com> <8C26A4FDAE599041A13EB499117D3C286B3A627E@ex-mb-1.corp.atlasnetworks.us> <4E486520-659A-4A2D-AD42-2B332314CD01@getjive.com> Message-ID: <8C48E6AB-7F9C-42F3-B300-5169249926A4@puck.nether.net> 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 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? > > From bicknell at ufp.org Mon Feb 28 08:16:30 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 28 Feb 2011 06:16:30 -0800 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <1298879376.2109.63.camel@karl> References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227223924.DF0E3B0E741@drugs.dv.isc.org> <20110228013421.GA32758@ussenterprise.ufp.org> <20110228015722.B0A7AB19587@drugs.dv.isc.org> <1298879376.2109.63.camel@karl> Message-ID: <20110228141630.GA77326@ussenterprise.ufp.org> 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 - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From m.hallgren at free.fr Mon Feb 28 15:11:38 2011 From: m.hallgren at free.fr (Michael Hallgren) Date: Mon, 28 Feb 2011 22:11:38 +0100 Subject: What If.... In-Reply-To: References: <2A4D7751-CAD5-4B40-B827-94E8BCD296F6@sfc.keio.ac.jp> <4D6C0725.3010005@gmail.com> Message-ID: <1298927498.25008.5.camel@home> 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 From leigh.porter at ukbroadband.com Mon Feb 28 15:01:18 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Mon, 28 Feb 2011 21:01:18 +0000 Subject: What If.... In-Reply-To: References: <2A4D7751-CAD5-4B40-B827-94E8BCD296F6@sfc.keio.ac.jp> <4D6C0725.3010005@gmail.com> Message-ID: <1A838CCE-BC4A-4A0A-9139-B826B7ACDF1A@ukbroadband.com> 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 From james.cutler at consultant.com Mon Feb 28 15:33:04 2011 From: james.cutler at consultant.com (Cutler James R) Date: Mon, 28 Feb 2011 16:33:04 -0500 Subject: What vexes VoIP users? In-Reply-To: <4D6BE974.5060402@spectraaccess.com> References: <4D6BDAA4.1080002@nic-naa.net> <8C26A4FDAE599041A13EB499117D3C286B3A5EEB@ex-mb-1.corp.atlasnetworks.us> <344A1A048FD34A6FAAA3F4BACD19C138@intra.ilk.net> <05801A27-7430-483F-A542-EDAC312FE173@ukbroadband.com> <4D6BE974.5060402@spectraaccess.com> Message-ID: <890857CD-E9A3-4F81-B86C-63B5668FA207@consultant.com> 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.cutler at consultant.com From marka at isc.org Mon Feb 28 15:48:33 2011 From: marka at isc.org (Mark Andrews) Date: Tue, 01 Mar 2011 08:48:33 +1100 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: Your message of "Mon, 28 Feb 2011 09:59:42 CDT." <28D10D13-988B-4C7D-833B-EBA6E1BC1A63@hopcount.ca> References: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> <4D6BB65B.8050309@foobar.org><28D10D13-988B-4C7D-833B-EBA6E1BC1A63@hopcount.ca> Message-ID: <20110228214834.02308B30031@drugs.dv.isc.org> In message <28D10D13-988B-4C7D-833B-EBA6E1BC1A63 at 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: marka at isc.org From drc at virtualized.org Mon Feb 28 15:57:43 2011 From: drc at virtualized.org (David Conrad) Date: Mon, 28 Feb 2011 11:57:43 -1000 Subject: What If.... In-Reply-To: <1298927498.25008.5.camel@home> References: <2A4D7751-CAD5-4B40-B827-94E8BCD296F6@sfc.keio.ac.jp> <4D6C0725.3010005@gmail.com> <1298927498.25008.5.camel@home> Message-ID: <56BB4C90-BFAF-45F4-B094-D01C2BD74BEB@virtualized.org> 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 From os10rules at gmail.com Mon Feb 28 15:57:31 2011 From: os10rules at gmail.com (Greg Ihnen) Date: Mon, 28 Feb 2011 17:27:31 -0430 Subject: Hughesnet outage - where can I ask? Message-ID: <5138532B-C9D6-431B-A5AB-FB2EE1D0EC30@gmail.com> 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 From owen at delong.com Mon Feb 28 16:04:09 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 28 Feb 2011 14:04:09 -0800 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> <4D6BB65B.8050309@foobar.org> <28D10D13-988B-4C7D-833B-EBA6E1BC1A63@hopcount.ca> Message-ID: <635A2019-3CDF-47D4-9079-5C2282131849@delong.com> 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 From jgreco at ns.sol.net Mon Feb 28 16:15:48 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 28 Feb 2011 16:15:48 -0600 (CST) Subject: What vexes VoIP users? In-Reply-To: <18237.1298918263@localhost> Message-ID: <201102282215.p1SMFmKb064169@aurora.sol.net> > --==_Exmh_1298918263_6182P > Content-Type: text/plain; charset=us-ascii > > 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? The ILEC's are also losing POTS lines that were originally sold as secondary residential lines for Internet and to a (possibly much) lesser extent faxing. In the case of upselling a customer who has two POTS lines and your dialup service to having only one POTS line with DSL on it, it isn't entirely clear that it is fair or accurate to represent this as a lost POTS line, at least for some counts. Kids have also moved towards cell phones and away from landlines as the preferred method of communication, but you already mentioned cell phones. Just wanted to point out that there's probably been a huge loss of second POTS phone lines in residential for many reasons. ... 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. From jgreco at ns.sol.net Mon Feb 28 16:19:59 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 28 Feb 2011 16:19:59 -0600 (CST) Subject: What vexes VoIP users? In-Reply-To: <4D6BEF4C.1050008@ispalliance.net> Message-ID: <201102282219.p1SMJxg6064212@aurora.sol.net> > 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. From owen at delong.com Mon Feb 28 16:24:41 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 28 Feb 2011 14:24:41 -0800 Subject: What vexes VoIP users? In-Reply-To: References: <4D6BDAA4.1080002@nic-naa.net> <8C26A4FDAE599041A13EB499117D3C286B3A5EEB@ex-mb-1.corp.atlasnetworks.us> <344A1A048FD34A6FAAA3F4BACD19C138@intra.ilk.net> <05801A27-7430-483F-A542-EDAC312FE173@ukbroadband.com> <4D6BE974.5060402@spectraaccess.com> <18237.1298918263@localhost> <6D8BB8D2-3401-45C2-8E4C-3E1FA41502C1@getjive.com> <9EA8D67A-6A1D-4500-AA1E-9062979B587D@delong.com> Message-ID: <990DCA8B-A156-41D4-88A0-EE39E16697F2@delong.com> 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 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 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.Kletnieks at 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? >>>>> >>>> >>> >> >> From khelms at ispalliance.net Mon Feb 28 16:33:46 2011 From: khelms at ispalliance.net (Scott Helms) Date: Mon, 28 Feb 2011 17:33:46 -0500 Subject: What vexes VoIP users? In-Reply-To: <201102282219.p1SMJxg6064212@aurora.sol.net> References: <201102282219.p1SMJxg6064212@aurora.sol.net> Message-ID: <4D6C22CA.90201@ispalliance.net> 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 -------------------------------- From owen at delong.com Mon Feb 28 16:32:20 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 28 Feb 2011 14:32:20 -0800 Subject: What vexes VoIP users? In-Reply-To: <890857CD-E9A3-4F81-B86C-63B5668FA207@consultant.com> References: <4D6BDAA4.1080002@nic-naa.net> <8C26A4FDAE599041A13EB499117D3C286B3A5EEB@ex-mb-1.corp.atlasnetworks.us> <344A1A048FD34A6FAAA3F4BACD19C138@intra.ilk.net> <05801A27-7430-483F-A542-EDAC312FE173@ukbroadband.com> <4D6BE974.5060402@spectraaccess.com> <890857CD-E9A3-4F81-B86C-63B5668FA207@consultant.com> Message-ID: <4F4CB8CA-EF6F-4481-B069-193CEEBE37A7@delong.com> 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.cutler at 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 From jgreco at ns.sol.net Mon Feb 28 16:34:03 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 28 Feb 2011 16:34:03 -0600 (CST) Subject: What vexes VoIP users? In-Reply-To: Message-ID: <201102282234.p1SMY33h064358@aurora.sol.net> > On Mon, 28 Feb 2011, Leigh Porter wrote: > > On 28 Feb 2011, at 18:37, Valdis.Kletnieks at 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. Oh my, with other VoIP providers offering service at much cheaper rates, I simply don't get why anyone would pay $29/month to their cable company for phone service, unless maybe you really needed thousands of minutes a month and could justify an unlimited plan, and you wanted to be able to hold the cable guy's feet to the fire if any problems occurred... Services such as VoicePulse offer local unlimited with 200 minutes of US LD for ~$15 (not a customer, just aware of them as a reputable carrier from the Asterisk community), and some of the cheapies like InPhoneX have "World Unlimited" plans that work out to $20/month or thereabouts (again not a customer). 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. ... 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. From thegameiam at yahoo.com Mon Feb 28 16:45:03 2011 From: thegameiam at yahoo.com (David Barak) Date: Mon, 28 Feb 2011 14:45:03 -0800 (PST) Subject: What vexes VoIP users? In-Reply-To: <201102282234.p1SMY33h064358@aurora.sol.net> References: <201102282234.p1SMY33h064358@aurora.sol.net> Message-ID: <703315.73365.qm@web31805.mail.mud.yahoo.com> >From: Joe Greco >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 From jgreco at ns.sol.net Mon Feb 28 16:55:23 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 28 Feb 2011 16:55:23 -0600 (CST) Subject: What vexes VoIP users? In-Reply-To: <4D6C22CA.90201@ispalliance.net> Message-ID: <201102282255.p1SMtNSI064689@aurora.sol.net> > 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. From jgreco at ns.sol.net Mon Feb 28 17:00:57 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 28 Feb 2011 17:00:57 -0600 (CST) Subject: What vexes VoIP users? In-Reply-To: <703315.73365.qm@web31805.mail.mud.yahoo.com> Message-ID: <201102282300.p1SN0vhJ064805@aurora.sol.net> > >From: Joe Greco =0A>I have no idea why anyone would be = > paying Ma Bell $69/month for a phone=0A>line, 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. From jabley at hopcount.ca Mon Feb 28 17:03:21 2011 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 28 Feb 2011 18:03:21 -0500 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <635A2019-3CDF-47D4-9079-5C2282131849@delong.com> References: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> <4D6BB65B.8050309@foobar.org> <28D10D13-988B-4C7D-833B-EBA6E1BC1A63@hopcount.ca> <635A2019-3CDF-47D4-9079-5C2282131849@delong.com> Message-ID: 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 From khelms at ispalliance.net Mon Feb 28 17:05:13 2011 From: khelms at ispalliance.net (Scott Helms) Date: Mon, 28 Feb 2011 18:05:13 -0500 Subject: What vexes VoIP users? In-Reply-To: <201102282255.p1SMtNSI064689@aurora.sol.net> References: <201102282255.p1SMtNSI064689@aurora.sol.net> Message-ID: <4D6C2A29.5040204@ispalliance.net> > 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 -------------------------------- From jra at baylink.com Mon Feb 28 17:15:27 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 28 Feb 2011 18:15:27 -0500 (EST) Subject: What vexes VoIP users? In-Reply-To: <201102282255.p1SMtNSI064689@aurora.sol.net> Message-ID: <12254284.370.1298934926996.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Joe Greco" > 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 From jra at baylink.com Mon Feb 28 17:24:15 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 28 Feb 2011 18:24:15 -0500 (EST) Subject: What vexes VoIP users? In-Reply-To: <4F4CB8CA-EF6F-4481-B069-193CEEBE37A7@delong.com> Message-ID: <26566470.376.1298935455299.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > 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 From bill at herrin.us Mon Feb 28 17:23:56 2011 From: bill at herrin.us (William Herrin) Date: Mon, 28 Feb 2011 18:23:56 -0500 Subject: SLA for voice and video over IP/MPLS In-Reply-To: References: Message-ID: On Sun, Feb 27, 2011 at 4:20 PM, Anton Kapela 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 ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jgreco at ns.sol.net Mon Feb 28 17:35:23 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 28 Feb 2011 17:35:23 -0600 (CST) Subject: What vexes VoIP users? In-Reply-To: <4D6C2A29.5040204@ispalliance.net> Message-ID: <201102282335.p1SNZNDZ065306@aurora.sol.net> > > 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. From leigh.porter at ukbroadband.com Mon Feb 28 17:28:49 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Mon, 28 Feb 2011 23:28:49 +0000 Subject: What vexes VoIP users? In-Reply-To: <12254284.370.1298934926996.JavaMail.root@benjamin.baylink.com> References: <12254284.370.1298934926996.JavaMail.root@benjamin.baylink.com> Message-ID: On 28 Feb 2011, at 23:15, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Joe Greco" > >> 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 From cb.list6 at gmail.com Mon Feb 28 17:40:36 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Mon, 28 Feb 2011 15:40:36 -0800 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> <4D6BB65B.8050309@foobar.org> <28D10D13-988B-4C7D-833B-EBA6E1BC1A63@hopcount.ca> Message-ID: On Feb 28, 2011 12:28 PM, "Randy Bush" 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 > From sethm at rollernet.us Mon Feb 28 17:59:18 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 28 Feb 2011 15:59:18 -0800 Subject: What vexes VoIP users? In-Reply-To: <201102282335.p1SNZNDZ065306@aurora.sol.net> References: <201102282335.p1SNZNDZ065306@aurora.sol.net> Message-ID: <4D6C36D6.6050000@rollernet.us> 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 From owen at delong.com Mon Feb 28 18:00:16 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 28 Feb 2011 16:00:16 -0800 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> <4D6BB65B.8050309@foobar.org> <28D10D13-988B-4C7D-833B-EBA6E1BC1A63@hopcount.ca> <635A2019-3CDF-47D4-9079-5C2282131849@delong.com> Message-ID: > 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 From jgreco at ns.sol.net Mon Feb 28 18:09:38 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 28 Feb 2011 18:09:38 -0600 (CST) Subject: What vexes VoIP users? In-Reply-To: <12254284.370.1298934926996.JavaMail.root@benjamin.baylink.com> Message-ID: <201103010009.p2109cC7065716@aurora.sol.net> > ----- Original Message ----- > > From: "Joe Greco" > > > 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. From jra at baylink.com Mon Feb 28 18:13:47 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 28 Feb 2011 19:13:47 -0500 (EST) Subject: What vexes VoIP users? In-Reply-To: Message-ID: <6479491.388.1298938427812.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > 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 From jra at baylink.com Mon Feb 28 18:24:30 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 28 Feb 2011 19:24:30 -0500 (EST) Subject: What vexes VoIP users? In-Reply-To: <201103010009.p2109cC7065716@aurora.sol.net> Message-ID: <21527951.396.1298939070702.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Joe Greco" > 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 From jra at baylink.com Mon Feb 28 18:25:19 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 28 Feb 2011 19:25:19 -0500 (EST) Subject: What vexes VoIP users? In-Reply-To: Message-ID: <2666602.398.1298939119246.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > > 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 From tshaw at oitc.com Mon Feb 28 18:49:58 2011 From: tshaw at oitc.com (TR Shaw) Date: Mon, 28 Feb 2011 19:49:58 -0500 Subject: What vexes VoIP users? In-Reply-To: <21527951.396.1298939070702.JavaMail.root@benjamin.baylink.com> References: <21527951.396.1298939070702.JavaMail.root@benjamin.baylink.com> Message-ID: On Feb 28, 2011, at 7:24 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Joe Greco" > >> 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. From swmike at swm.pp.se Mon Feb 28 18:51:08 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 1 Mar 2011 01:51:08 +0100 (CET) Subject: What vexes VoIP users? In-Reply-To: <2666602.398.1298939119246.JavaMail.root@benjamin.baylink.com> References: <2666602.398.1298939119246.JavaMail.root@benjamin.baylink.com> Message-ID: On Mon, 28 Feb 2011, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Owen DeLong" > >> 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 Abrahamsson email: swmike at swm.pp.se From intensifysecurity at gmail.com Mon Feb 28 19:06:13 2011 From: intensifysecurity at gmail.com (Jeff Hartley) Date: Mon, 28 Feb 2011 20:06:13 -0500 Subject: Switch with 10 Gig and GRE support in hardware. In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13C5D@RWC-EX1.corp.seven.com> References: <18886_1298039457_p1IEUpvU024871_93717E08238F7B4392FAD1F82A87FBD3365F2E87@SAT2EXD02.RACKSPACE.CORP> <20862_1298182779_p1K6JX2d011053_93717E08238F7B4392FAD1F82A87FBD3365F49A9@SAT2EXD02.RACKSPACE.CORP> <5A6D953473350C4B9995546AFE9939EE0BC13C5D@RWC-EX1.corp.seven.com> Message-ID: On Sun, Feb 20, 2011 at 3:15 PM, George Bonser wrote: >> On 2/18/11 6:30 AM, "Matt Newsom" 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 From denys at visp.net.lb Mon Feb 28 19:17:33 2011 From: denys at visp.net.lb (denys at visp.net.lb) Date: Tue, 01 Mar 2011 03:17:33 +0200 Subject: Hughesnet outage - where can I =?UTF-8?Q?ask=3F?= In-Reply-To: <5138532B-C9D6-431B-A5AB-FB2EE1D0EC30@gmail.com> References: <5138532B-C9D6-431B-A5AB-FB2EE1D0EC30@gmail.com> Message-ID: <51357e8d4aa8ad9d80e6d95154717637@visp.net.lb> 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 From scott at doc.net.au Mon Feb 28 19:20:18 2011 From: scott at doc.net.au (Scott Howard) Date: Mon, 28 Feb 2011 17:20:18 -0800 Subject: [v6z] Re: What vexes VoIP users? In-Reply-To: <201102282300.p1SN0vhJ064805@aurora.sol.net> References: <703315.73365.qm@web31805.mail.mud.yahoo.com> <201102282300.p1SN0vhJ064805@aurora.sol.net> Message-ID: On Mon, Feb 28, 2011 at 3:00 PM, Joe Greco 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 AT&T (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. From tsison at gmail.com Mon Feb 28 19:26:28 2011 From: tsison at gmail.com (Theo Sison) Date: Mon, 28 Feb 2011 18:26:28 -0700 Subject: Switch with 10 Gig and GRE support in hardware. In-Reply-To: References: <18886_1298039457_p1IEUpvU024871_93717E08238F7B4392FAD1F82A87FBD3365F2E87@SAT2EXD02.RACKSPACE.CORP> <20862_1298182779_p1K6JX2d011053_93717E08238F7B4392FAD1F82A87FBD3365F49A9@SAT2EXD02.RACKSPACE.CORP> <5A6D953473350C4B9995546AFE9939EE0BC13C5D@RWC-EX1.corp.seven.com> Message-ID: Jeff, I would try the 4900M 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 wrote: > On Sun, Feb 20, 2011 at 3:15 PM, George Bonser wrote: > >> On 2/18/11 6:30 AM, "Matt Newsom" 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 From rdobbins at arbor.net Mon Feb 28 19:32:06 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 1 Mar 2011 01:32:06 +0000 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <20110228141630.GA77326@ussenterprise.ufp.org> References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227223924.DF0E3B0E741@drugs.dv.isc.org> <20110228013421.GA32758@ussenterprise.ufp.org> <20110228015722.B0A7AB19587@drugs.dv.isc.org> <1298879376.2109.63.camel@karl> <20110228141630.GA77326@ussenterprise.ufp.org> Message-ID: 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 // The basis of optimism is sheer terror. -- Oscar Wilde From rdobbins at arbor.net Mon Feb 28 19:35:04 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 1 Mar 2011 01:35:04 +0000 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> <4D6BB65B.8050309@foobar.org> <28D10D13-988B-4C7D-833B-EBA6E1BC1A63@hopcount.ca> <635A2019-3CDF-47D4-9079-5C2282131849@delong.com> Message-ID: 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 // The basis of optimism is sheer terror. -- Oscar Wilde From msa at latt.net Mon Feb 28 19:38:08 2011 From: msa at latt.net (Majdi S. Abbas) Date: Mon, 28 Feb 2011 18:38:08 -0700 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> <4D6BB65B.8050309@foobar.org> <28D10D13-988B-4C7D-833B-EBA6E1BC1A63@hopcount.ca> <635A2019-3CDF-47D4-9079-5C2282131849@delong.com> Message-ID: <20110301013808.GG83831@puck.nether.net> 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 From brett at the-watsons.org Mon Feb 28 19:45:05 2011 From: brett at the-watsons.org (Brett Watson) Date: Mon, 28 Feb 2011 18:45:05 -0700 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <20110301013808.GG83831@puck.nether.net> References: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> <4D6BB65B.8050309@foobar.org> <28D10D13-988B-4C7D-833B-EBA6E1BC1A63@hopcount.ca> <635A2019-3CDF-47D4-9079-5C2282131849@delong.com> <20110301013808.GG83831@puck.nether.net> Message-ID: <7E63B828-735A-4C8D-8418-21D1546C9A5D@the-watsons.org> On Feb 28, 2011, at 6:38 PM, Majdi S. Abbas wrote: > Anyone care to start the IPv4 dead pool, Price is Right > style, for when the last v4 NLRI is removed from the DFZ? That's funny, I don't care what galaxy you're from :) -b From richard.barnes at gmail.com Mon Feb 28 19:49:32 2011 From: richard.barnes at gmail.com (Richard Barnes) Date: Mon, 28 Feb 2011 20:49:32 -0500 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <7E63B828-735A-4C8D-8418-21D1546C9A5D@the-watsons.org> References: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> <4D6BB65B.8050309@foobar.org> <28D10D13-988B-4C7D-833B-EBA6E1BC1A63@hopcount.ca> <635A2019-3CDF-47D4-9079-5C2282131849@delong.com> <20110301013808.GG83831@puck.nether.net> <7E63B828-735A-4C8D-8418-21D1546C9A5D@the-watsons.org> Message-ID: >> ? ? ? Anyone care to start the IPv4 dead pool, Price is Right >> style, for when the last v4 NLRI is removed from the DFZ? > > That's funny, I don't care what galaxy you're from :) So that puts your bet at more than 25,000 years? From gbonser at seven.com Mon Feb 28 19:50:36 2011 From: gbonser at seven.com (George Bonser) Date: Mon, 28 Feb 2011 17:50:36 -0800 Subject: Switch with 10 Gig and GRE support in hardware. In-Reply-To: References: <18886_1298039457_p1IEUpvU024871_93717E08238F7B4392FAD1F82A87FBD3365F2E87@SAT2EXD02.RACKSPACE.CORP><20862_1298182779_p1K6JX2d011053_93717E08238F7B4392FAD1F82A87FBD3365F49A9@SAT2EXD02.RACKSPACE.CORP><5A6D953473350C4B9995546AFE9939EE0BC13C5D@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13E29@RWC-EX1.corp.seven.com> > From: Jeff Hartley > Sent: Monday, February 28, 2011 5:06 PM > To: Matt Newsom; NANOG list > Subject: Re: Switch with 10 Gig and GRE support in hardware. > > On Sun, Feb 20, 2011 at 3:15 PM, George Bonser > wrote: > >> On 2/18/11 6:30 AM, "Matt Newsom" 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 Last time I checked, the TI24x wouldn't do GRE. From owen at delong.com Mon Feb 28 19:51:22 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 28 Feb 2011 17:51:22 -0800 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> <4D6BB65B.8050309@foobar.org> <28D10D13-988B-4C7D-833B-EBA6E1BC1A63@hopcount.ca> <635A2019-3CDF-47D4-9079-5C2282131849@delong.com> Message-ID: On Feb 28, 2011, at 5:35 PM, Dobbins, Roland wrote: > > 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 said beginning to turn it off, not done with it. > I think we're going to be dealing with IPv4 for a long, long time - far longer than two years. > Oh, I agree. However, I think in 5 years we'll start seeing a few residential providers announcing things like IPv4 is now a $20/month optional service. Owen From tkapela at gmail.com Mon Feb 28 20:08:58 2011 From: tkapela at gmail.com (Anton Kapela) Date: Mon, 28 Feb 2011 20:08:58 -0600 Subject: SLA for voice and video over IP/MPLS In-Reply-To: References: Message-ID: On Mon, Feb 28, 2011 at 5:23 PM, William Herrin wrote: > Who uses BER to measure packet switched networks? I do, some 'packet' test gear can, bitstream oriented software often will, etc. > 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? Absolutely -- folks can use BER in the context of packet networks, given that many bit-oriented applications are often packetized. Once processed by a bit, byte, or other message-level interleaving mechanism and encoded (or expanded with CRC and FEC-du-jour), BER is arguably more applicable. These types of packetized bitstreams, when subjected to a variable and sundry packet loss processes, may only present a few bits of residual error for to application. I would argue that in this way, BER and PER are flexible terms given (the OP's A/V) context. For example, if we have 1 bit lost in 1000000, that'd be ~1 packet lost every 82 packets we receive, for a IP packet of 1500 bytes. More importantly, this assumes we're able to *detect* a single bit error (eg. CRC isn't absolute, it's probabilistic). Such error-expansion due to packetization has the effect of making 10E-6 appear as if we lost the nearest 11,999 bits as well. However, not all networks check L2 CRC's, and some are designed to explicitly ignore them--an advantage given application-level encoding data encoding schemes. It follows that if 1 in ~82 packets becomes corrupted, regardless of a CRC system detecting and dropping it, then we have a link no *better* than 10E-6. If the CRC system detected an error, then it's possible that >1 bit was corrupted. This implies that we can't know precisely how much *worse* than 10E-6 the link is, since we're aggregated (or limited) to a resolution of +/- 12k bits at a time. -Tk From ml at kenweb.org Mon Feb 28 20:53:15 2011 From: ml at kenweb.org (ML) Date: Mon, 28 Feb 2011 21:53:15 -0500 Subject: Verizon Issues? East Coast US Message-ID: <4D6C5F9B.9080301@kenweb.org> Seeing some packet loss via Cogent. www.internetpulse.net seems to be lighting up. From matt.taber.nanog at gmail.com Mon Feb 28 20:58:46 2011 From: matt.taber.nanog at gmail.com (Matt Taber) Date: Mon, 28 Feb 2011 21:58:46 -0500 Subject: Verizon Issues? East Coast US In-Reply-To: <4D6C5F9B.9080301@kenweb.org> References: <4D6C5F9B.9080301@kenweb.org> Message-ID: I'm noticing it too. POP in Grand Rapids, circuit to Detroit. Packet loss, but no total loss of connectivity. -----Original Message----- From: ML [mailto:ml at kenweb.org] Sent: Monday, February 28, 2011 9:53 PM To: NANOG Subject: Verizon Issues? East Coast US Seeing some packet loss via Cogent. www.internetpulse.net seems to be lighting up. From ml at kenweb.org Mon Feb 28 20:59:45 2011 From: ml at kenweb.org (ML) Date: Mon, 28 Feb 2011 21:59:45 -0500 Subject: Verizon Issues? East Coast US In-Reply-To: <4D6C5F9B.9080301@kenweb.org> References: <4D6C5F9B.9080301@kenweb.org> Message-ID: <4D6C6121.2060902@kenweb.org> On 2/28/2011 9:53 PM, ML wrote: > Seeing some packet loss via Cogent. > > www.internetpulse.net seems to be lighting up. > Looking at from Level3 via San Jose, NLayer via Chicago, Cogent via NY. Seems like the trouble starts after: 0.ge-5-0-0.CHI01-BB-RTR1.ALTER.NET Substitute CHI for NY, SJC etc. From tkapela at gmail.com Mon Feb 28 21:07:06 2011 From: tkapela at gmail.com (Anton Kapela) Date: Mon, 28 Feb 2011 21:07:06 -0600 Subject: Switch with 10 Gig and GRE support in hardware. In-Reply-To: <13702_1298181629_p1K60NTu008696_93717E08238F7B4392FAD1F82A87FBD3365F4961@SAT2EXD02.RACKSPACE.CORP> References: <18886_1298039457_p1IEUpvU024871_93717E08238F7B4392FAD1F82A87FBD3365F2E87@SAT2EXD02.RACKSPACE.CORP> <4D607273.7030600@bogus.com> <4D60739D.3050203@bogus.com> <13702_1298181629_p1K60NTu008696_93717E08238F7B4392FAD1F82A87FBD3365F4961@SAT2EXD02.RACKSPACE.CORP> Message-ID: On Sun, Feb 20, 2011 at 12:00 AM, Matt Newsom wrote: [snip] > I can't seem to find anyone that has small 1-2U solution that can do the full shake and bake. [snip] If you don't need "all ports, all-line-rate, all the time" ... you could rig it with two rack units. I'd dirty it up with something like: First U: Brocade CER2k 48 (NI-CER-2048CX-ADVPREM-DC) 2x 10 gig + 48 sfp Second U: Arista 7148SX (DCS-7148SX-R) -- 48x 10 gig Ridiculous config #1231512: -take CER 2x 10 gig XFP, configure LAG & trunk host-facing and transit-facing vlans towards Arista 7148 -configure remaining 46 sfp+ ports as access interfaces for hosts on 7148 -configure static GRE on CER2k, transit neighbors, etc. -remember to crank mtu's on * -if box-router traffic is hashable, you could slum it with N x 1gig port LAG's for more bits/sec between the 7148 and the CER2k Of course, if two or more hosts are active, chances are good their inside-tunnel packets won't hash to either side of the 2x10g lag from the 7148. If your app is using IP in a more i-mix profile, the inner traffic could then be likewise flow-dense, meaning the hashing will effectively permit you to utilize all 20 gbits. Arista hashes on 7-tuples, whereas CER is l2+3+4 + labels (if doing mpls, etc), as of v5.1. I hear rumors that Brocbroc will be doing 1u N x 10 gig box where N will hopefully be >= 8 ints... of course, that doesn't help you now. Lastly, one could employ a 6716 blade + sup720b non-xl (for cheapness) in 6503E/7603 chassis... but ugh -- 4u, and almost 2x the runtime wattage of the ghetto-rigged config, and *still* internally oversubscribed to not-quite-40 gigs per slot! -Tk From mike at sentex.net Mon Feb 28 21:07:16 2011 From: mike at sentex.net (Mike Tancsa) Date: Mon, 28 Feb 2011 22:07:16 -0500 Subject: Verizon Issues? East Coast US In-Reply-To: <4D6C5F9B.9080301@kenweb.org> References: <4D6C5F9B.9080301@kenweb.org> Message-ID: <4D6C62E4.8010102@sentex.net> I was just looking at an issue between 701 in Toronto. Seems to be resolved now-- at least the issue I was seeing. the bad traceroute, looked like .... 3 if-3-0-2.core3.TNK-Toronto.as6453.net (64.86.81.3) 0.988 ms 0.978 ms 1.578 ms 4 209.58.94.10 (209.58.94.10) 1.902 ms 71.416 ms 3.472 ms 5 if-3-1-0-0.tcore1.NJY-Newark.as6453.net (216.6.98.34) 22.286 ms 21.957 ms 29.472 ms 6 if-12-0.mcore3.NJY-Newark.as6453.net (66.198.70.14) 67.961 ms if-3-0-0.mcore3.NJY-Newark.as6453.net (216.6.57.121) 21.449 ms 20.956 ms 7 if-10-0.core3.NTO-NewYork.as6453.net (216.6.57.66) 21.975 ms 22.467 ms 21.977 ms 8 Vlan1297.icore1.NTO-NewYork.as6453.net (209.58.26.49) 20.977 ms * 30.520 ms 9 0.ae20.BR2.NYC4.ALTER.NET (204.255.168.173) 21.478 ms 21.458 ms 21.477 ms 10 * 11 * Now its working .... 3 if-3-0-2.core3.TNK-Toronto.as6453.net (64.86.81.3) 0.975 ms 4 209.58.94.10 (209.58.94.10) 1.975 ms 5 if-3-1-0-0.tcore1.NJY-Newark.as6453.net (216.6.98.34) 21.445 ms 6 if-12-0.mcore3.NJY-Newark.as6453.net (66.198.70.14) 54.472 ms 7 if-10-0.core3.NTO-NewYork.as6453.net (216.6.57.66) 112.426 ms 8 Vlan1297.icore1.NTO-NewYork.as6453.net (209.58.26.49) 22.964 ms 9 0.ae20.BR2.NYC4.ALTER.NET (204.255.168.173) 21.455 ms 10 0.ae2.XL4.NYC4.ALTER.NET (152.63.3.117) 21.466 ms 11 0.so-5-1-0.XT2.TOR2.ALTER.NET (152.63.128.121) 34.958 ms 12 0.POS7-1.GW2.TOR2.ALTER.NET (152.63.131.205) 33.958 ms When it was not working, packets would not get from my AS (11647) to the target in IP in AS701. But packets from 701 would get back to my AS. The AS path in both directions are 701-6453-11647 and 11647 6453 701... I saw a similar outage to VPNs I have in AS15290 which I see as 11647 6453 701 15290. However, I did not have time to check if it was the same behaviour with loss being in one direction. In both cases, IPs that follow 11647 174 701 and 701 174 11647 and 11647 174 7018 15290 and 15290 7018 174 11647 were not impacted. ---Mike On 2/28/2011 9:53 PM, ML wrote: > Seeing some packet loss via Cogent. > > www.internetpulse.net seems to be lighting up. > > -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike at sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From m.hallgren at free.fr Mon Feb 28 21:08:54 2011 From: m.hallgren at free.fr (Michael Hallgren) Date: Tue, 01 Mar 2011 04:08:54 +0100 Subject: What If.... In-Reply-To: <56BB4C90-BFAF-45F4-B094-D01C2BD74BEB@virtualized.org> References: <2A4D7751-CAD5-4B40-B827-94E8BCD296F6@sfc.keio.ac.jp> <4D6C0725.3010005@gmail.com> <1298927498.25008.5.camel@home> <56BB4C90-BFAF-45F4-B094-D01C2BD74BEB@virtualized.org> Message-ID: <1298948934.25008.6.camel@home> Le lundi 28 f?vrier 2011 ? 11:57 -1000, David Conrad a ?crit : > 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 > From bill at herrin.us Mon Feb 28 21:44:19 2011 From: bill at herrin.us (William Herrin) Date: Mon, 28 Feb 2011 22:44:19 -0500 Subject: SLA for voice and video over IP/MPLS In-Reply-To: References: Message-ID: On Mon, Feb 28, 2011 at 9:08 PM, Anton Kapela wrote: > On Mon, Feb 28, 2011 at 5:23 PM, William Herrin wrote: > >> Who uses BER to measure packet switched networks? > > I do, some 'packet' test gear can, bitstream oriented software often will, etc. Hi Anton, So... Not really, no. You get a bit error on an Ethernet in the middle, the next router flunks the Ethernet CRC and you never see the packet. You get congestion in the middle, the router drops the packet and you never see it. You get a bit error on a 802.11 link in the middle, it retransmits and you get a clean packet with a little jitter and maybe out of order. Point is, you don't get a measurement that looks like Bit Error Rate because you don't have access to layer 1 and you see a very incomplete layer 2. Evaluating an MPLS virtual circuit, you want metrics that make sense for layer 3 in a packet switched network: loss at various sizes, delay, jitter, packet order. Don't take this the wrong way, but someone starts asking me about BER rates in the SLA on a packet switched network and the message I hear is that they're asking to be lied to. Like when I describe DSL quality in terms of the birds perched pooping on the lines. His mental model for datacom is stuck in the '80s and I'll have to accommodate that if I want to do business. And when he calls to complain that we owe him a day's credit because of a high BER, he'll be the nice gentleman who we humor because he pays his bills on time and the occasional service credits are built in to our price. Loss. Delay. Jitter. Not BER. BER is the wrong tool for even attempting to evaluate the end to end performance of an MPLS virtual circuit. > For example, if we have 1 bit lost in 1000000, that'd be ~1 packet > lost every 82 packets we receive, If you're losing 1 packet in 82, you're fired. Seriously, that's an order of magnitude off even for tasks less demanding than VoIP and streaming video. Doesn't matter if you flipped 1 bit or 20, 1.2% packet loss one way (2.4% round trip) is way excessive. That's at the level where you start to notice sluggish web browsing because of TCP's congestion control algorithms. -Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From joelja at bogus.com Mon Feb 28 22:11:00 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 28 Feb 2011 20:11:00 -0800 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <4D6BB5C7.8050009@utc.edu> References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227140321.GM9424@angus.ind.WPI.EDU> <72B7B4EA-0E25-4D31-B9A1-653308E4D675@arbor.net> <071A89DA-A414-4DCC-BC47-3C86AB67EFE0@cs.columbia.edu> <70835095-819D-419A-830E-2B6ECCFE3102@cs.columbia.edu> <4D6BA5DD.2050504@freedesktop.org> <35826B01-F1D5-48CF-809E-FEC7329D1231@arbor.net> <4D6BB5C7.8050009@utc.edu> Message-ID: <4D6C71D4.8090304@bogus.com> On 2/28/11 6:48 AM, Jeff Kell wrote: > 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. As is, present in layer-3... > Jeff > > From joelja at bogus.com Mon Feb 28 22:24:28 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 28 Feb 2011 20:24:28 -0800 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <4D6BB65B.8050309@foobar.org> References: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> <4D6BB65B.8050309@foobar.org> Message-ID: <4D6C74FC.1000707@bogus.com> On 2/28/11 6:51 AM, 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. Oddly enough the meeting NOC is in the business of providing services to customers and we generally assume that to be with the highest availability and minimum breakage feasible under the circumstances... > "But we couldn't do that??!?!", I hear you say. I would direct your attention to the ietf-v6ONLY SSID present during the meeting and ask you to ponder what purpose it serves. > I understand completely. I am mystified. > Nick > From intensifysecurity at gmail.com Mon Feb 28 22:42:22 2011 From: intensifysecurity at gmail.com (Jeff Hartley) Date: Mon, 28 Feb 2011 23:42:22 -0500 Subject: Switch with 10 Gig and GRE support in hardware. In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13E29@RWC-EX1.corp.seven.com> References: <18886_1298039457_p1IEUpvU024871_93717E08238F7B4392FAD1F82A87FBD3365F2E87@SAT2EXD02.RACKSPACE.CORP> <20862_1298182779_p1K6JX2d011053_93717E08238F7B4392FAD1F82A87FBD3365F49A9@SAT2EXD02.RACKSPACE.CORP> <5A6D953473350C4B9995546AFE9939EE0BC13C5D@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC13E29@RWC-EX1.corp.seven.com> Message-ID: >> >> >> Brocade TurboIron 24X fits all of those criteria. >> >> -Jeff > > Last time I checked, the TI24x wouldn't do GRE. > > > It was updated last year -- apparently handled in HW now. 24 ports of 10GE, routing, GRE, and small form-factor = everything the original inquiry listed. FYI, -Jeff From joelja at bogus.com Mon Feb 28 22:52:25 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 28 Feb 2011 20:52:25 -0800 Subject: What vexes VoIP users? In-Reply-To: <18237.1298918263@localhost> References: <4D6BDAA4.1080002@nic-naa.net> <8C26A4FDAE599041A13EB499117D3C286B3A5EEB@ex-mb-1.corp.atlasnetworks.us> <344A1A048FD34A6FAAA3F4BACD19C138@intra.ilk.net> <05801A27-7430-483F-A542-EDAC312FE173@ukbroadband.com> <4D6BE974.5060402@spectraaccess.com> <18237.1298918263@localhost> Message-ID: <4D6C7B89.2000203@bogus.com> On 2/28/11 10:37 AM, Valdis.Kletnieks at 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. My mother has comcast voice... they decided on that themselves after moving out of dsl range. >> Baloney...if that was the case, then all these ILEC's wouldn't be >> whining about POT's lines decreasing exponentially year over year! The temporary decade and half longe bump of dial modems, fax machines and second pots lines to keep the teen off the main one is over. > I do believe that the ILEC's are mostly losing POTS lines to cell phones, not > to VoIP. the only reason anyone under 30 would end up with a pots line anymore imhoas a new service activation has to do with the pricing for unbundled dsl. > 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? From newton at internode.com.au Mon Feb 28 23:23:47 2011 From: newton at internode.com.au (Mark Newton) Date: Tue, 1 Mar 2011 05:23:47 +0000 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227140321.GM9424@angus.ind.WPI.EDU> <72B7B4EA-0E25-4D31-B9A1-653308E4D675@arbor.net> <071A89DA-A414-4DCC-BC47-3C86AB67EFE0@cs.columbia.edu> <70835095-819D-419A-830E-2B6ECCFE3102@cs.columbia.edu> <4D6BA5DD.2050504@freedesktop.org> <35826B01-F1D5-48CF-809E-FEC7329D1231@arbor.net> <4D6BB5C7.8050009@utc.edu> Message-ID: <99B7A9A2-EBA4-48DB-AB72-D8A157BE1667@internode.com.au> On 01/03/2011, at 1:23 AM, Brian Johnson wrote: > Can someone explain what exactly the security threat is? If I see two IPv6 addresses which share the same 64 bit suffix, I can be reasonably certain that they both correspond to the same device because they'll both be generated by the same MAC address. Your IPv6 address has thereby become a token I can use to track your whereabouts, which is the kind of thing that privacy advocates often find upsetting. RFC4941 should be (but generally isn't) enabled by default. Having said that, implementation of RFC4941 is lossy. On MacOS, long-held TCP sessions time-out when a new privacy suffix is generated and the old one ages out. I'd have thought that a better outcome would be for old addresses to continue working until their refcount drops to zero. > 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. :) It's not about that; there are already plenty of other attack vectors that can be used to find out someone's IP address, such as web-bugs, logfiles behind phishing and malware distribution websites, etc. The new attack vector which SLAAC with EUI64 creates is one of "trackability." I can't passively accumulate IPv4 logs which tell me which ISPs you've used, which cities you're in, which WiFi hotspots you've used, which companies you've worked at, which websites you've visited, etc. I can accumulate logs which tell me which IP addresses have done those things, but I can't (for example) correlate them to your personal smartphone. I can with IPv6. That's new, and (to my mind) threatening. We've not even begun to consider the attack vectors that'll open up. - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From rdobbins at arbor.net Mon Feb 28 23:34:44 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 1 Mar 2011 05:34:44 +0000 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <99B7A9A2-EBA4-48DB-AB72-D8A157BE1667@internode.com.au> References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227140321.GM9424@angus.ind.WPI.EDU> <72B7B4EA-0E25-4D31-B9A1-653308E4D675@arbor.net> <071A89DA-A414-4DCC-BC47-3C86AB67EFE0@cs.columbia.edu> <70835095-819D-419A-830E-2B6ECCFE3102@cs.columbia.edu> <4D6BA5DD.2050504@freedesktop.org> <35826B01-F1D5-48CF-809E-FEC7329D1231@arbor.net> <4D6BB5C7.8050009@utc.edu> <99B7A9A2-EBA4-48DB-AB72-D8A157BE1667@internode.com.au> Message-ID: <7D231284-D15A-4482-8F05-71E65FBDD5F0@arbor.net> On Mar 1, 2011, at 12:23 PM, Mark Newton wrote: > That's new, and (to my mind) threatening. We've not even begun to consider the attack vectors that'll open up. I don't think it's new at all, given the amount of information available today that you already cite, down to and including sniffing on toxic hotel networks and the like. Folks are already easily pwn3d to extremes - look at HB Gary. This doesn't constitute some huge new attack surface or information leakage - especially given the existence of VPNs/proxies, the tendency to store more and more data/apps on servers/in 'the cloud', and so forth. In fact, the device one is actually using at any given moment and where one is located when using said device is becoming less and less relevant. >From a physical-security standpoint, leaky IM, SMTP headers, et. al. already give the game away. We've been living in this situation for years. Nothing about EUI-64 changes this fact, IMHO. I dislike it immensely, but it isn't a game-changer, IMHO. ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From joelja at bogus.com Mon Feb 28 23:43:35 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 28 Feb 2011 21:43:35 -0800 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <7D231284-D15A-4482-8F05-71E65FBDD5F0@arbor.net> References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227140321.GM9424@angus.ind.WPI.EDU> <72B7B4EA-0E25-4D31-B9A1-653308E4D675@arbor.net> <071A89DA-A414-4DCC-BC47-3C86AB67EFE0@cs.columbia.edu> <70835095-819D-419A-830E-2B6ECCFE3102@cs.columbia.edu> <4D6BA5DD.2050504@freedesktop.org> <35826B01-F1D5-48CF-809E-FEC7329D1231@arbor.net> <4D6BB5C7.8050009@utc.edu> <99B7A9A2-EBA4-48DB-AB72-D8A157BE1667@internode.com.au> <7D231284-D15A-4482-8F05-71E65FBDD5F0@arbor.net> Message-ID: <4D6C8787.2060803@bogus.com> On 2/28/11 9:34 PM, Dobbins, Roland wrote: > > On Mar 1, 2011, at 12:23 PM, Mark Newton wrote: > >> That's new, and (to my mind) threatening. We've not even begun to >> consider the attack vectors that'll open up. given that rfc 3041 had it's 10th birthday in january there's nothing new about any of this. > > I don't think it's new at all, given the amount of information > available today that you already cite, down to and including sniffing > on toxic hotel networks and the like. > > Folks are already easily pwn3d to extremes - look at HB Gary. This > doesn't constitute some huge new attack surface or information > leakage - especially given the existence of VPNs/proxies, the > tendency to store more and more data/apps on servers/in 'the cloud', > and so forth. > > In fact, the device one is actually using at any given moment and > where one is located when using said device is becoming less and less > relevant. > >> From a physical-security standpoint, leaky IM, SMTP headers, et. >> al. already give the game away. > > We've been living in this situation for years. Nothing about EUI-64 > changes this fact, IMHO. I dislike it immensely, but it isn't a > game-changer, IMHO. > > ----------------------------------------------------------------------- > > Roland Dobbins // > > The basis of optimism is sheer terror. > > -- Oscar Wilde > > >