From bjorn at mork.no Sat Sep 1 03:03:03 2012 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Sat, 01 Sep 2012 10:03:03 +0200 Subject: Bird vs Quagga revisited In-Reply-To: <503D5756.20306@rollernet.us> (Seth Mattinen's message of "Tue, 28 Aug 2012 16:42:14 -0700") References: <20120823222627.GH3728514@jupiter.n2.diac24.net> <503D5756.20306@rollernet.us> Message-ID: <87k3we41c7.fsf@nemi.mork.no> Seth Mattinen writes: > What's the state of MPLS on Linux these days? There was some renewed interest "recently" (i.e. last year). See the discussion starting at http://www.spinics.net/lists/netdev/msg180282.html But do note davem's replies in http://www.spinics.net/lists/netdev/msg180401.html http://www.spinics.net/lists/netdev/msg180646.html Don't put too much into the "fringe facility" comment. There have been similar comments on e.g. IPv6, and that went in some time ago :-) So in short: There is some interest and some people working on this in a direction which has some hope of mainline integration. Bj?rn From bjorn at mork.no Sat Sep 1 03:12:14 2012 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Sat, 01 Sep 2012 10:12:14 +0200 Subject: Bird vs Quagga revisited In-Reply-To: (Edward Dore's message of "Fri, 31 Aug 2012 22:41:38 +0100") References: <4277105.1655.1346254798425.JavaMail.Administrator@TMA01> <1346413447.18274.422.camel@pc2> Message-ID: <87fw7240wx.fsf@nemi.mork.no> Edward Dore writes: > They used to publish the source for their 2.4 kernel on > routerboard.com (in fact, it's still available at > http://routerboard.com/files/linux-2.4.31.zip), but I've not seen > anything for the 2.6 kernel however and the routerboard.com site was > redesigned a little while ago, seemingly without the links as far as I > can tell. > > It might be a case of you need to ask them for it. Would be > interesting to see which bits are GPL. There is no doubt that *all* bits of the Linux kernel are GPL. Whether vendors respect this is another question. But Mikrotik most certainly cannot distribute the Linux kernel, modified or not, without also providing the full source code. Bj?rn From me at anuragbhatia.com Sat Sep 1 12:51:11 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Sat, 1 Sep 2012 23:21:11 +0530 Subject: Finding "Name Servers" (not NS records) of domain name In-Reply-To: References: <20120817121424.GL3085@hezmatt.org> Message-ID: Thanks for helpful replies everyone! I missed to understand Owen's reply here but he was kind and helpful enough to explain me when I met him last week! So simple logic of reading given name from right to left looking for specific pattern (my old nameservers). I didn't realized that reading from right to left digging NS for each zone coming in can pretty much solve the issue. On Mon, Aug 20, 2012 at 6:08 PM, Antonio Querubin wrote: > On Fri, 17 Aug 2012, Matthew Palmer wrote: > > I religiously use http://squish.net/dnscheck/ the moment I suspect *any* >> sort of DNS hinkiness. Verbose, but *damn* if it doesn't hand me the >> answer >> practically every time. >> > > http://dnscheck.iis.se > > It's not as verbose and provides more direct diagnosis and recommendations > on what needs fixing. > > Antonio Querubin > e-mail: tony at lavanauts.org > xmpp: antonioquerubin at gmail.com > > -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter| Google+ From avg at kotovnik.com Sat Sep 1 17:54:16 2012 From: avg at kotovnik.com (Vadim Antonov) Date: Sat, 01 Sep 2012 15:54:16 -0700 Subject: Color vision for network techs In-Reply-To: <5040D7B0.4070004@Janoszka.pl> References: <5040D7B0.4070004@Janoszka.pl> Message-ID: The simple solution for color perception issues is to carry some cheap red/green 3d glasses... they would make discriminating between LED colors as easy as closing one eye:) From mpetach at netflight.com Sat Sep 1 18:22:48 2012 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 1 Sep 2012 16:22:48 -0700 Subject: Redundant Routes, BGP with MPLS provider In-Reply-To: <972EE2ECC5BFF44CA991510B8EDA469C0FBB015B@S4USJVSYAIC.ts-na.t-systems.com> References: <972EE2ECC5BFF44CA991510B8EDA469C0FBB015B@S4USJVSYAIC.ts-na.t-systems.com> Message-ID: On Fri, Aug 31, 2012 at 9:21 AM, wrote: > I think having a GRE tunnel for the internal routing protocol is > unnecessary. Can you explain the reasoning behind this? I understand > the technical issue whereby GRE will allow multicast for EIGRP, OSPF, > etc, but why not just redistribute into BGP? > > I work on a lot of MPLS CE routers, and in general you can accomplish > anything you need by redistributing your internal routing protocol into > BGP, and adjusting LP, MED and AS Prepend as needed. > > Thanks, > Bill So, rather than run an IGP between siteA and siteZ across a GRE tunnel, you'd prefer to redistribute your IGP into BGP at siteA, advertise those routes upstream...and at siteZ, accept the routes in via BGP, and then redistribute them into the IGP for the other routers at siteZ, and vice versa? Or would you have every router at siteA and siteZ participate in BGP, so that all the routers at siteZ get the routes from siteA intact? (choice B tends to have practical implications on what network gear you can run within the sites; many devices that will happily speak OSPF or EIGRP won't be quite so happy participating in an iBGP mesh. And choice A...well, I think we all know the pitfall with choice A, so enough said on that score). Curious to hear the actual mechanism you'd use to make this work in the real world. Thanks! Matt From edward.dore at freethought-internet.co.uk Sun Sep 2 05:44:24 2012 From: edward.dore at freethought-internet.co.uk (Edward Dore) Date: Sun, 2 Sep 2012 11:44:24 +0100 Subject: Bird vs Quagga revisited In-Reply-To: <87fw7240wx.fsf@nemi.mork.no> References: <4277105.1655.1346254798425.JavaMail.Administrator@TMA01> <1346413447.18274.422.camel@pc2> <87fw7240wx.fsf@nemi.mork.no> Message-ID: <7D14D712-ED2C-4D6D-8866-91E9C11E52D8@freethought-internet.co.uk> The Linux Kernel itself may be GPL (which I wasn't debating), however I see no reason why MikroTik's MPLS stack couldn't work in a similar way to the closed source NVidia driers where my understanding is that a GPL stub loads a binary blob. Have you asked MikroTik for a copy of the source? Edward Dore Freethought Internet On 1 Sep 2012, at 09:12, Bj?rn Mork wrote: > Edward Dore writes: > >> They used to publish the source for their 2.4 kernel on >> routerboard.com (in fact, it's still available at >> http://routerboard.com/files/linux-2.4.31.zip), but I've not seen >> anything for the 2.6 kernel however and the routerboard.com site was >> redesigned a little while ago, seemingly without the links as far as I >> can tell. >> >> It might be a case of you need to ask them for it. Would be >> interesting to see which bits are GPL. > > There is no doubt that *all* bits of the Linux kernel are GPL. Whether > vendors respect this is another question. But Mikrotik most certainly > cannot distribute the Linux kernel, modified or not, without also > providing the full source code. > > > Bj?rn From jim at neuse.net Sun Sep 2 08:00:26 2012 From: jim at neuse.net (Jim Ray) Date: Sun, 2 Sep 2012 09:00:26 -0400 Subject: Color vision for network techs In-Reply-To: References: <5040CCA7.1000008@l-w.ca> Message-ID: <530DFF0280267643A67908BB181189E5981F29@garcia.neuse.local> For pulling cable, the colors are fixed inside the jacket. I have found differences in cable manufacturers and prefer Mohawk brand cable because the colors are easier for me to see. White is white instead of clear. Blue, green, orange and brown are noticeably different. So, my take is stick to manufacturers that do a good job. If my tired old eyes can tell the difference, the employees that work with me probably won't have a problem. Regards, Jim Ray, President Neuse River Networks 2 Davis Drive, PO Box 13169 Research Triangle Park, NC 27709 919-838-1672 x100 www.NeuseRiverNetworks.com -----Original Message----- From: Larry LaBas [mailto:llabas at gmail.com] Sent: Friday, August 31, 2012 10:55 AM To: telmnstr at 757.org Cc: nanog at nanog.org Subject: Re: Color vision for network techs The Military has colour screening for obvious reasons but I am not sure if it's needed for Networking. My take is that I designed all to have a wide variance. IE: Red, Blue, Yellow and Black which helped lower issues. Not solve them but if you limit the use of Red to certain areas (ie: Yellow / Red on one patch panel) then it helps. Yes, I did have a team lead who was colour blind and that did help to lead me down that path. When he was on our internet facing patch panel which was Red/Yellow if he saw black he knew it was Red. Sincerely, Larry A. LaBas(CD) On Fri, Aug 31, 2012 at 7:46 AM, wrote: > > When doing Cat5 connectors, a friend couldn't tell the orange versus > brown (or was it green.) He found that with a red LED flashlight he > could then tell. > > There are ways to work around things. > > > From bzs at world.std.com Sun Sep 2 11:59:52 2012 From: bzs at world.std.com (Barry Shein) Date: Sun, 2 Sep 2012 12:59:52 -0400 Subject: Color vision for network techs In-Reply-To: References: <5040CCA7.1000008@l-w.ca> Message-ID: <20547.37000.341564.332401@world.std.com> In high school I worked in a men's clothing store for a couple of years. One of the guys on the floor was pretty much completely color blind. It was kind of amusing and annoying at the same time as he'd run over to me when someone was in the dressing room to ask if this tie matched this shirt etc (um, NO!) So one day, I am not making this up, I asked him what he was studying at college and he said "graphic design". I guess the right comment is "no comment", or perhaps "overcompensation much?" But the example at hand is a much more narrow domain. -- -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 cfillekes at gmail.com Sun Sep 2 12:31:00 2012 From: cfillekes at gmail.com (C. A. Fillekes) Date: Sun, 2 Sep 2012 12:31:00 -0500 Subject: Color vision for network techs In-Reply-To: <20547.37000.341564.332401@world.std.com> References: <5040CCA7.1000008@l-w.ca> <20547.37000.341564.332401@world.std.com> Message-ID: I suspect that if this objectively measurable physical infirmity that actually inhibits one's job function were more common in women than men, it would be used as a reason to discourage us all from even entering the profession in the first place. From paul.w.bennett at gmail.com Sun Sep 2 22:09:52 2012 From: paul.w.bennett at gmail.com (Paul Bennett) Date: Sun, 02 Sep 2012 23:09:52 -0400 Subject: 172.0.0.0/12 has been Allocated In-Reply-To: <50369C8E.6030003@mompl.net> References: <20120823052351.GA6614@dan.olp.net> <5FE1FB6D43B8A647BBC821840C1AEA8B017CBA@ocsbs.ocosa.com> <20120823053654.GB6614@dan.olp.net> <5FE1FB6D43B8A647BBC821840C1AEA8B017CBC@ocsbs.ocosa.com> <3F7370A2-82A8-486D-9528-F47B346E0108@delong.com> <50369C8E.6030003@mompl.net> Message-ID: On Thu, 23 Aug 2012 17:11:42 -0400, Jeroen van Aart wrote: > The 16777214 IP addresses (give or take) in their 12/8 assignment aren't > enough? Oh wait, it's probably used internally and renumbering to 10/8 > would be too big a hurdle to take. ;-) The 12/8 address space is fully allocated out, I believe entirely to customers. Do the math. 35,000,000 residential customers (plus) on DSL and FTTx (many with a /29, /27, or larger assigned), plus very many managed services customers with full /24s and even /16s. It's no wonder they're hungry for IP space. Their enormous customer base is hungry for it. -- Paul Bennett From randy at psg.com Mon Sep 3 06:27:12 2012 From: randy at psg.com (Randy Bush) Date: Mon, 03 Sep 2012 18:27:12 +0700 Subject: NANOG Website Redesign Project In-Reply-To: References: Message-ID: > NANOG is in the process of completely redeveloping its website > (http://www.nanog.org) and is looking for feedback from the community > and NANOG members. i have been exceedingly impressed by the current web site's serious feature set implemented without a whole bunch of web glorp. i use it as an example when folk want to start barfing java and all that crap at me. randy From lukas.lozovski at gmail.com Mon Sep 3 06:59:58 2012 From: lukas.lozovski at gmail.com (Lukas Lozovski) Date: Mon, 3 Sep 2012 07:59:58 -0400 Subject: Color vision for network techs In-Reply-To: References: <5040CCA7.1000008@l-w.ca> <20547.37000.341564.332401@world.std.com> Message-ID: I can only imagine how making ethernet cables is a pain. The different colored wires, putting them in the RJ-45. That must be an impossible task for colorblind people. On Sun, Sep 2, 2012 at 1:31 PM, C. A. Fillekes wrote: > I suspect that if this objectively measurable physical infirmity that > actually inhibits one's job function were more common in women than men, it > would be used as a reason to discourage us all from even entering the > profession in the first place. > -- Lukas Lozovski From oscar.vives at gmail.com Mon Sep 3 07:06:28 2012 From: oscar.vives at gmail.com (Tei) Date: Mon, 3 Sep 2012 14:06:28 +0200 Subject: Color vision for network techs In-Reply-To: References: <5040CCA7.1000008@l-w.ca> <20547.37000.341564.332401@world.std.com> Message-ID: Standards can have "bugs", and a standard that is not compatible with maybe 5% of the population is buggy. Almost any standard that start "this is red and this is green" is flawed this way. This mean any future standard created as to look into this type of stuff (and i18n and localization and others) to not create flawed buggy standards. Old standards can be updated ... (maybe include lines of the same color but different contrast), but we all know how hard is to update standards. If I where one of these dudes, I would download/create a app for my iphone that recolorice video to change colours to others I could tell the difference. -- -- ?in del ?ensaje. From rs at seastrom.com Mon Sep 3 09:01:41 2012 From: rs at seastrom.com (Robert E. Seastrom) Date: Mon, 03 Sep 2012 10:01:41 -0400 Subject: NANOG Website Redesign Project In-Reply-To: (Randy Bush's message of "Mon, 03 Sep 2012 18:27:12 +0700") References: Message-ID: <86harffbne.fsf@seastrom.com> Randy Bush writes: >> NANOG is in the process of completely redeveloping its website >> (http://www.nanog.org) and is looking for feedback from the community >> and NANOG members. > > i have been exceedingly impressed by the current web site's serious > feature set implemented without a whole bunch of web glorp. i use it as > an example when folk want to start barfing java and all that crap at me. I am not a fan of "fsmenu.js", which persists on nanog.org even when one clicks on the "text site" link, which to my way of thinking ought to be free of such stuff. I'm not an accessibility expert, but animated menus don't smell "accessible" to me unless input devices and screen readers have gotten a whole lot better while I was not paying attention. There are various accessibility standards - BS 8878:2010 (UK), Section 508 (US, a bit of a period piece) to name a couple. Which one gets chosen is not as important as choosing one and then subjecting the site to a periodic audit to make sure it is "clean". In my limited experience, conformance to such standards tends to make the site load more quickly and feel more snappy (which benefits everyone) though the difference may be fairly small on today's fast links. A clear statement of the goals of the redesign may inform the direction one's efforts take. My $0.02... -r From me at anuragbhatia.com Tue Sep 4 00:19:23 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Tue, 4 Sep 2012 10:49:23 +0530 Subject: Regarding smaller prefix for hijack protection In-Reply-To: References: Message-ID: I didn't realized the routing table size problem with /24's. Stupid me. Thanks everyone for updates. Appreciate good answers. On Fri, Aug 31, 2012 at 4:18 AM, George Herbert wrote: > On Thu, Aug 30, 2012 at 8:41 AM, William Herrin wrote: > > On Thu, Aug 30, 2012 at 7:54 AM, Anurag Bhatia > wrote: > >> Is using /24 a must to protect (a bit) against route hijacking? > > > > Hi Anurag, > > > > Not only is it _not_ a must, it doesn't work and it impairs your > > ability to detect the fault. > > > > In a route hijacking scenario, traffic for a particular prefix will > > flow to the site with the shortest AS path from the origin. Your /24 > > competes with their /24. Half the Internet, maybe more maybe less > > depending on how well connected each of you are, will be inaccessible > > to you. > > Preventively there seems to be no utility to this. > > Reactively, after a hijacking starts, has anyone tried announcing both > (say) /24s for the block and (say) 2x /25s for it as well, to get > more-specific under the hijacker? Yes, a lot of places will filter > and ignore, but those that don't ... > > (Yes, sign your prefixes now, on general principles) > > > -- > -george william herbert > george.herbert at gmail.com > > -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter| Google+ From aftab.siddiqui at gmail.com Tue Sep 4 00:29:57 2012 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Tue, 4 Sep 2012 10:29:57 +0500 Subject: Regarding smaller prefix for hijack protection In-Reply-To: References: Message-ID: The thing to acknowledge is that you've realized it otherwise if you follow the CIDR report than you will find bunch of arrogant folks/SPs not willing to understand the dilemma they are causing through de-aggregation. Regards, Aftab A. Siddiqui On Tue, Sep 4, 2012 at 10:19 AM, Anurag Bhatia wrote: > I didn't realized the routing table size problem with /24's. Stupid me. > > > > Thanks everyone for updates. Appreciate good answers. > > From kyle.creyts at gmail.com Tue Sep 4 03:04:45 2012 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Tue, 4 Sep 2012 01:04:45 -0700 Subject: Color vision for network techs In-Reply-To: References: <5040CCA7.1000008@l-w.ca> <20547.37000.341564.332401@world.std.com> Message-ID: Tei: such applications exist, see http://dankaminsky.com/2010/12/15/dankam/ http://www.wpcentral.com/augmented-reality-app-windows-phone-ids-colors-real-world-video http://daily-steampunk.com/steampunk-blog/2012/05/27/augmented-reality-steampunk-and-learing-color-vacuum/ On Sep 3, 2012 5:07 AM, "Tei" wrote: > Standards can have "bugs", and a standard that is not compatible with > maybe 5% of the population is buggy. > > Almost any standard that start "this is red and this is green" is > flawed this way. This mean any future standard created as to look > into this type of stuff (and i18n and localization and others) to not > create flawed buggy standards. > > Old standards can be updated ... (maybe include lines of the same > color but different contrast), but we all know how hard is to update > standards. > > If I where one of these dudes, I would download/create a app for my > iphone that recolorice video to change colours to others I could tell > the difference. > > > > -- > -- > ?in del ?ensaje. > > From ibrahim1 at gmail.com Tue Sep 4 05:07:28 2012 From: ibrahim1 at gmail.com (Ibrahim) Date: Tue, 4 Sep 2012 17:07:28 +0700 Subject: Blocking MX query Message-ID: Hi All, I've read old archive about blocking SMTP port (TCP port 25). In my current situation we are mobile operator and use NAT for our subscribers and we have few spammers, a bit difficult to track it because mostly our subscribers are prepaid services. If we block TCP port 25, there might be "good" subscribers will not be able to send email. We are thinking to block MX queries on our DNS server, so only spammer that use their own SMTP server will got affected. All DNS queries from our subscribers already redirected to our DNS cache servers. But seem Bind don't have feature to block MX query. Any best practice to block MX query? Regards Ibrahim From ops.lists at gmail.com Tue Sep 4 05:12:35 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 4 Sep 2012 15:42:35 +0530 Subject: Blocking MX query In-Reply-To: References: Message-ID: Feel free to block port 25. Most if not all mail providers offer email access on webmail and on an alternate smtp port (587) If you have NAT - the problem is that if you have spammers abusing your service (or abusing other services on port 25) providers will end up blocking your NAT gateway IP and then you have a problem. You will want to look at walled gardens or similar to block spamming / infected users. Please see the maawg best practice for walled gardens and port 25 management. On Tue, Sep 4, 2012 at 3:37 PM, Ibrahim wrote: > Hi All, > > I've read old archive about blocking SMTP port (TCP port 25). In my current > situation we are mobile operator and use NAT for our subscribers and we > have few spammers, a bit difficult to track it because mostly our > subscribers are prepaid services. If we block TCP port 25, there might be > "good" subscribers will not be able to send email. > We are thinking to block MX queries on our DNS server, so only spammer that > use their own SMTP server will got affected. All DNS queries from our > subscribers already redirected to our DNS cache servers. But seem Bind > don't have feature to block MX query. Any best practice to block MX query? > > > Regards > Ibrahim -- Suresh Ramasubramanian (ops.lists at gmail.com) From baconzombie at gmail.com Tue Sep 4 05:13:21 2012 From: baconzombie at gmail.com (Bacon Zombie) Date: Tue, 4 Sep 2012 11:13:21 +0100 Subject: Blocking MX query In-Reply-To: References: Message-ID: Are you saying that you only allow your subscribers to use your DNS Servers and block access to all other DNS Server? On 4 September 2012 11:07, Ibrahim wrote: > Hi All, > > I've read old archive about blocking SMTP port (TCP port 25). In my current > situation we are mobile operator and use NAT for our subscribers and we > have few spammers, a bit difficult to track it because mostly our > subscribers are prepaid services. If we block TCP port 25, there might be > "good" subscribers will not be able to send email. > We are thinking to block MX queries on our DNS server, so only spammer that > use their own SMTP server will got affected. All DNS queries from our > subscribers already redirected to our DNS cache servers. But seem Bind > don't have feature to block MX query. Any best practice to block MX query? > > > Regards > Ibrahim > -- ???????????????????? ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ??????????????????????????????????????????????????????????????????????????????????? BaconZombie LOAD "*",8,1 From ibrahim1 at gmail.com Tue Sep 4 05:18:16 2012 From: ibrahim1 at gmail.com (Ibrahim) Date: Tue, 4 Sep 2012 17:18:16 +0700 Subject: Blocking MX query In-Reply-To: References: Message-ID: Not block, but we use DNS transparent proxy mechanism. We need to do this as our government request all ISP to block porn sites :-) Regards Ibrahim On Tue, Sep 4, 2012 at 5:13 PM, Bacon Zombie wrote: > Are you saying that you only allow your subscribers to use your DNS Servers > and block access to all other DNS Server? > > On 4 September 2012 11:07, Ibrahim wrote: > > > Hi All, > > > > I've read old archive about blocking SMTP port (TCP port 25). In my > current > > situation we are mobile operator and use NAT for our subscribers and we > > have few spammers, a bit difficult to track it because mostly our > > subscribers are prepaid services. If we block TCP port 25, there might be > > "good" subscribers will not be able to send email. > > We are thinking to block MX queries on our DNS server, so only spammer > that > > use their own SMTP server will got affected. All DNS queries from our > > subscribers already redirected to our DNS cache servers. But seem Bind > > don't have feature to block MX query. Any best practice to block MX > query? > > > > > > Regards > > Ibrahim > > > > > > -- > ???????????????????? > > ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? > > ??????????????????????????????????????????????????????????????????????????????????? > > > BaconZombie > > LOAD "*",8,1 > From ops.lists at gmail.com Tue Sep 4 05:24:11 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 4 Sep 2012 15:54:11 +0530 Subject: Blocking MX query In-Reply-To: References: Message-ID: On Tue, Sep 4, 2012 at 3:48 PM, Ibrahim wrote: > Not block, but we use DNS transparent proxy mechanism. We need to do this > as our government request all ISP to block porn sites :-) Plenty of ways to work around that actually. This stops random people from accessing porn sites but you are not likely to see spammers or bots get deterred too much by this mechanism. Still it does come in useful as part of a larger walled garden strategy. -- Suresh Ramasubramanian (ops.lists at gmail.com) From ibrahim1 at gmail.com Tue Sep 4 05:24:47 2012 From: ibrahim1 at gmail.com (Ibrahim) Date: Tue, 4 Sep 2012 17:24:47 +0700 Subject: Blocking MX query In-Reply-To: References: Message-ID: Hi Suresh, We create special NAT that all destination use TCP port 25 will be NATed to one public IP address only. And this public IP address is registered on most of RBLs. But we are still receiving complaint about spammer from this public IP address :-) Regards Ibrahim On Tue, Sep 4, 2012 at 5:12 PM, Suresh Ramasubramanian wrote: > Feel free to block port 25. Most if not all mail providers offer > email access on webmail and on an alternate smtp port (587) > > If you have NAT - the problem is that if you have spammers abusing > your service (or abusing other services on port 25) providers will end > up blocking your NAT gateway IP and then you have a problem. > > You will want to look at walled gardens or similar to block spamming / > infected users. > > Please see the maawg best practice for walled gardens and port 25 > management. > > On Tue, Sep 4, 2012 at 3:37 PM, Ibrahim wrote: > > Hi All, > > > > I've read old archive about blocking SMTP port (TCP port 25). In my > current > > situation we are mobile operator and use NAT for our subscribers and we > > have few spammers, a bit difficult to track it because mostly our > > subscribers are prepaid services. If we block TCP port 25, there might be > > "good" subscribers will not be able to send email. > > We are thinking to block MX queries on our DNS server, so only spammer > that > > use their own SMTP server will got affected. All DNS queries from our > > subscribers already redirected to our DNS cache servers. But seem Bind > > don't have feature to block MX query. Any best practice to block MX > query? > > > > > > Regards > > Ibrahim > > > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) > From ops.lists at gmail.com Tue Sep 4 05:27:28 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 4 Sep 2012 15:57:28 +0530 Subject: Blocking MX query In-Reply-To: References: Message-ID: Sure you will get it - but there's also spam through various webmail services, spam through the outbounds of different ISPs etc that you won't prevent with your approach. On Tue, Sep 4, 2012 at 3:54 PM, Ibrahim wrote: > > We create special NAT that all destination use TCP port 25 will be NATed to > one public IP address only. And this public IP address is registered on most > of RBLs. But we are still receiving complaint about spammer from this public > IP address :-) -- Suresh Ramasubramanian (ops.lists at gmail.com) From dot at dotat.at Tue Sep 4 06:37:44 2012 From: dot at dotat.at (Tony Finch) Date: Tue, 4 Sep 2012 12:37:44 +0100 Subject: Blocking MX query In-Reply-To: References: Message-ID: Ibrahim wrote: > > We are thinking to block MX queries on our DNS server, so only spammer that > use their own SMTP server will got affected. [...] Any best practice to > block MX query? Don't do this. It won't hinder spammers and it'll cause problems for legit users. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From bill at herrin.us Tue Sep 4 07:05:06 2012 From: bill at herrin.us (William Herrin) Date: Tue, 4 Sep 2012 08:05:06 -0400 Subject: Blocking MX query In-Reply-To: References: Message-ID: On Tue, Sep 4, 2012 at 6:07 AM, Ibrahim wrote: > I've read old archive about blocking SMTP port (TCP port 25). In my current > situation we are mobile operator and use NAT for our subscribers and we > have few spammers, a bit difficult to track it because mostly our > subscribers are prepaid services. If we block TCP port 25, there might be > "good" subscribers will not be able to send email. Hi, There are no "good" subscribers trying to send email direct to a remote port 25 from behind a NAT. The "good" subscribers are either using your local smart host or they're using TCP port 587 on their remote mail server. You may safely block outbound TCP with a destination of port 25 from behind your NAT without harming reasonable use of your network. > We are thinking to block MX queries on our DNS server, so only spammer that > use their own SMTP server will got affected. All DNS queries from our > subscribers already redirected to our DNS cache servers. But seem Bind > don't have feature to block MX query. Any best practice to block MX query? Best practice is: don't mess with the DNS. I don't know if any resolver software supports what you want to do here. If it does, I don't know what the repercussions are likely to be. I do know that historically, altering DNS results has proven problematic. For example, returning an A record for your search server in place of no-host responses wreaks all manner of havoc. I also doubt the efficacy of the method. Were this to become common practice, a spammer could trivially evade it by using his own DNS software or simply pumping out the address list along with pre-resolved IP addresses to deliver the mail to. For all I know, they already do. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From richard.barnes at gmail.com Tue Sep 4 07:07:42 2012 From: richard.barnes at gmail.com (Richard Barnes) Date: Tue, 4 Sep 2012 19:07:42 +0700 Subject: Regarding smaller prefix for hijack protection In-Reply-To: References: Message-ID: This seems like an opportune time to remind people about RPKI-based origin validation as a hijack mitigation: I haven't run the numbers, but it seems like doing RPKI-based origin validation is probably a lot cheaper than upgrading routers to store a fully deaggregated route table :) On Tue, Sep 4, 2012 at 12:29 PM, Aftab Siddiqui wrote: > The thing to acknowledge is that you've realized it otherwise if you follow > the CIDR report than you will find bunch of arrogant folks/SPs not willing > to understand the dilemma they are causing through de-aggregation. > > Regards, > > Aftab A. Siddiqui > > > On Tue, Sep 4, 2012 at 10:19 AM, Anurag Bhatia wrote: > >> I didn't realized the routing table size problem with /24's. Stupid me. >> >> >> >> Thanks everyone for updates. Appreciate good answers. >> >> From bryn.sadler at essensys.co.uk Tue Sep 4 08:01:51 2012 From: bryn.sadler at essensys.co.uk (Bryn Sadler) Date: Tue, 4 Sep 2012 13:01:51 +0000 Subject: Strange Reachability Issue Message-ID: Hello all, I was wondering if anyone might be able to share their thoughts on a strange issue we're experiencing with NTT at the moment. We're AS48273 and are advertising a prefix 94.198.184.0/21 through AS 8190 (single upstream provider at the moment). We've been doing this for some years now, and all has been fine. The last few days we seem to have disappeared from NTT's worldwide routing tables, with the exception of Europe. If we use their looking glass to query any NTT european router we can see the prefix, being learned via AS 286 then AS 8190, as expected. If we look at any other router outside of europe, there is simply no entry for that prefix. Elsewhere in the world we seem to be fine, we're in every other network I've looked at and general reachability is fine. First step was to contact the NTT NOC, and they've confirmed that there's no Internal routing/config issue on their network, but that they cannot discuss their peering arrangements due to NDAs. We've also picked it up with KPN (AS 286), who have verified that the prefix is visible throughout their network (true), and that they are advertising it to NTT. One thing of note is that Global Crossing are learning our prefix from KPN as well, and the prefix is showing fine in their global tables. We seem to be caught in the classic finger pointing scenario, but I can't get my head around why the prefix is visible in NTT Europe, but not anywhere else, unless they have a config error somewhere on their network. We've checked a few of the routes from AS 8190 and they are in the NTT global tables just fine, and at least in Europe they seem to have the same community values etc. We're still following on with NTT, but can anyone offer some wisdom for new avenues to pursue? Thanks for your help, Bryn Sadler This message has been scanned for viruses by essensys mailcontrol From rsk at gsp.org Tue Sep 4 08:12:40 2012 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 4 Sep 2012 09:12:40 -0400 Subject: Blocking MX query In-Reply-To: References: Message-ID: <20120904131240.GA8186@gsp.org> On Tue, Sep 04, 2012 at 08:05:06AM -0400, William Herrin wrote: > I also doubt the efficacy of the method. Were this to become common > practice, a spammer could trivially evade it by using his own DNS > software or simply pumping out the address list along with > pre-resolved IP addresses to deliver the mail to. For all I know, they > already do. You're precisely correct. They've been doing this for many years, (a) because it's efficient (b) because it evades detection by techniques that monitor MX query volume (c) because few MX's change often (d) because it scales beautifully across large botnets. ---rsk From ralph.brandt at pateam.com Tue Sep 4 08:18:49 2012 From: ralph.brandt at pateam.com (Brandt, Ralph) Date: Tue, 4 Sep 2012 09:18:49 -0400 Subject: Strange Reachability Issue In-Reply-To: References: Message-ID: <51C66083768C2949A7EB14910C78B01701A98C8E@embgsr24.pateam.com> I will bet that will bet that within 48 hours of you checking and posting this the problem will mysteriously go away. Ralph Brandt Mechanicsburg PA 17055 -----Original Message----- From: Bryn Sadler [mailto:bryn.sadler at essensys.co.uk] Sent: Tuesday, September 04, 2012 9:02 AM To: nanog at nanog.org Subject: Strange Reachability Issue Hello all, I was wondering if anyone might be able to share their thoughts on a strange issue we're experiencing with NTT at the moment. We're AS48273 and are advertising a prefix 94.198.184.0/21 through AS 8190 (single upstream provider at the moment). We've been doing this for some years now, and all has been fine. The last few days we seem to have disappeared from NTT's worldwide routing tables, with the exception of Europe. If we use their looking glass to query any NTT european router we can see the prefix, being learned via AS 286 then AS 8190, as expected. If we look at any other router outside of europe, there is simply no entry for that prefix. Elsewhere in the world we seem to be fine, we're in every other network I've looked at and general reachability is fine. First step was to contact the NTT NOC, and they've confirmed that there's no Internal routing/config issue on their network, but that they cannot discuss their peering arrangements due to NDAs. We've also picked it up with KPN (AS 286), who have verified that the prefix is visible throughout their network (true), and that they are advertising it to NTT. One thing of note is that Global Crossing are learning our prefix from KPN as well, and the prefix is showing fine in their global tables. We seem to be caught in the classic finger pointing scenario, but I can't get my head around why the prefix is visible in NTT Europe, but not anywhere else, unless they have a config error somewhere on their network. We've checked a few of the routes from AS 8190 and they are in the NTT global tables just fine, and at least in Europe they seem to have the same community values etc. We're still following on with NTT, but can anyone offer some wisdom for new avenues to pursue? Thanks for your help, Bryn Sadler This message has been scanned for viruses by essensys mailcontrol From jared at puck.nether.net Tue Sep 4 09:12:56 2012 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 4 Sep 2012 10:12:56 -0400 Subject: Strange Reachability Issue In-Reply-To: <51C66083768C2949A7EB14910C78B01701A98C8E@embgsr24.pateam.com> References: <51C66083768C2949A7EB14910C78B01701A98C8E@embgsr24.pateam.com> Message-ID: <24625233-D236-48F7-A7D4-6344B4B49C8E@puck.nether.net> I know a few folks from NTT have looked into this. If someone from KPN would get in touch with Bryn I'm sure the issue could be quickly resolved. - Jared On Sep 4, 2012, at 9:18 AM, Brandt, Ralph wrote: > I will bet that will bet that within 48 hours of you checking and > posting this the problem will mysteriously go away. > > > > Ralph Brandt > Mechanicsburg PA 17055 > > -----Original Message----- > From: Bryn Sadler [mailto:bryn.sadler at essensys.co.uk] > Sent: Tuesday, September 04, 2012 9:02 AM > To: nanog at nanog.org > Subject: Strange Reachability Issue > > Hello all, > > I was wondering if anyone might be able to share their thoughts on a > strange issue we're experiencing with NTT at the moment. We're AS48273 > and are advertising a prefix 94.198.184.0/21 through AS 8190 (single > upstream provider at the moment). We've been doing this for some years > now, and all has been fine. The last few days we seem to have > disappeared from NTT's worldwide routing tables, with the exception of > Europe. If we use their looking glass to query any NTT european router > we can see the prefix, being learned via AS 286 then AS 8190, as > expected. If we look at any other router outside of europe, there is > simply no entry for that prefix. Elsewhere in the world we seem to be > fine, we're in every other network I've looked at and general > reachability is fine. > > First step was to contact the NTT NOC, and they've confirmed that > there's no Internal routing/config issue on their network, but that they > cannot discuss their peering arrangements due to NDAs. We've also picked > it up with KPN (AS 286), who have verified that the prefix is visible > throughout their network (true), and that they are advertising it to > NTT. One thing of note is that Global Crossing are learning our prefix > from KPN as well, and the prefix is showing fine in their global tables. > > We seem to be caught in the classic finger pointing scenario, but I > can't get my head around why the prefix is visible in NTT Europe, but > not anywhere else, unless they have a config error somewhere on their > network. We've checked a few of the routes from AS 8190 and they are in > the NTT global tables just fine, and at least in Europe they seem to > have the same community values etc. We're still following on with NTT, > but can anyone offer some wisdom for new avenues to pursue? > > Thanks for your help, > > Bryn Sadler > > > This message has been scanned for viruses by essensys mailcontrol > From bryn.sadler at essensys.co.uk Tue Sep 4 09:20:11 2012 From: bryn.sadler at essensys.co.uk (Bryn Sadler) Date: Tue, 4 Sep 2012 14:20:11 +0000 Subject: Strange Reachability Issue In-Reply-To: <24625233-D236-48F7-A7D4-6344B4B49C8E@puck.nether.net> Message-ID: Many thanks to Jared for jumping on this so quickly off-list, it's much appreciated and hopefully we're getting towards a solution now. Bryn On 04/09/2012 15:12, "Jared Mauch" wrote: >I know a few folks from NTT have looked into this. If someone >from KPN would get in touch with Bryn I'm sure the issue could be >quickly resolved. > >- Jared > >On Sep 4, 2012, at 9:18 AM, Brandt, Ralph wrote: > >> I will bet that will bet that within 48 hours of you checking and >> posting this the problem will mysteriously go away. >> >> >> >> Ralph Brandt >> Mechanicsburg PA 17055 >> >> -----Original Message----- >> From: Bryn Sadler [mailto:bryn.sadler at essensys.co.uk] >> Sent: Tuesday, September 04, 2012 9:02 AM >> To: nanog at nanog.org >> Subject: Strange Reachability Issue >> >> Hello all, >> >> I was wondering if anyone might be able to share their thoughts on a >> strange issue we're experiencing with NTT at the moment. We're AS48273 >> and are advertising a prefix 94.198.184.0/21 through AS 8190 (single >> upstream provider at the moment). We've been doing this for some years >> now, and all has been fine. The last few days we seem to have >> disappeared from NTT's worldwide routing tables, with the exception of >> Europe. If we use their looking glass to query any NTT european router >> we can see the prefix, being learned via AS 286 then AS 8190, as >> expected. If we look at any other router outside of europe, there is >> simply no entry for that prefix. Elsewhere in the world we seem to be >> fine, we're in every other network I've looked at and general >> reachability is fine. >> >> First step was to contact the NTT NOC, and they've confirmed that >> there's no Internal routing/config issue on their network, but that they >> cannot discuss their peering arrangements due to NDAs. We've also picked >> it up with KPN (AS 286), who have verified that the prefix is visible >> throughout their network (true), and that they are advertising it to >> NTT. One thing of note is that Global Crossing are learning our prefix >> from KPN as well, and the prefix is showing fine in their global tables. >> >> We seem to be caught in the classic finger pointing scenario, but I >> can't get my head around why the prefix is visible in NTT Europe, but >> not anywhere else, unless they have a config error somewhere on their >> network. We've checked a few of the routes from AS 8190 and they are in >> the NTT global tables just fine, and at least in Europe they seem to >> have the same community values etc. We're still following on with NTT, >> but can anyone offer some wisdom for new avenues to pursue? >> >> Thanks for your help, >> >> Bryn Sadler >> >> >> This message has been scanned for viruses by essensys mailcontrol >> > From jra at baylink.com Tue Sep 4 09:44:41 2012 From: jra at baylink.com (Jay Ashworth) Date: Tue, 4 Sep 2012 10:44:41 -0400 (EDT) Subject: Blocking MX query In-Reply-To: Message-ID: <22236243.23098.1346769881533.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "William Herrin" > There are no "good" subscribers trying to send email direct to a > remote port 25 from behind a NAT. Users, like myself, running Linux on home computers and laptops; our local sendmail-equivalents will in fact attempt direct delivery to remote SMTP MX servers, and we generally move around enough that setting a smarthost is semi-impractical, at least on laptops. I'm a bad subscriber, Bill? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From virendra.rode at gmail.com Tue Sep 4 10:12:19 2012 From: virendra.rode at gmail.com (virendra rode) Date: Tue, 04 Sep 2012 08:12:19 -0700 Subject: Strange Reachability Issue In-Reply-To: References: Message-ID: <50461A53.2080708@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, On 09/04/2012 07:20 AM, Bryn Sadler wrote: > Many thanks to Jared for jumping on this so quickly off-list, it's > much appreciated and hopefully we're getting towards a solution > now. > > Bryn - ------------------ yup you are in good hands, sounds more like filtering related among peers. Use can use communities to test this theory. regards, /virendra > > > > > On 04/09/2012 15:12, "Jared Mauch" wrote: > >> I know a few folks from NTT have looked into this. If someone >> from KPN would get in touch with Bryn I'm sure the issue could >> be quickly resolved. >> >> - Jared >> >> On Sep 4, 2012, at 9:18 AM, Brandt, Ralph wrote: >> >>> I will bet that will bet that within 48 hours of you checking >>> and posting this the problem will mysteriously go away. >>> >>> >>> >>> Ralph Brandt Mechanicsburg PA 17055 >>> >>> -----Original Message----- From: Bryn Sadler >>> [mailto:bryn.sadler at essensys.co.uk] Sent: Tuesday, September >>> 04, 2012 9:02 AM To: nanog at nanog.org Subject: Strange >>> Reachability Issue >>> >>> Hello all, >>> >>> I was wondering if anyone might be able to share their thoughts >>> on a strange issue we're experiencing with NTT at the moment. >>> We're AS48273 and are advertising a prefix 94.198.184.0/21 >>> through AS 8190 (single upstream provider at the moment). We've >>> been doing this for some years now, and all has been fine. The >>> last few days we seem to have disappeared from NTT's worldwide >>> routing tables, with the exception of Europe. If we use their >>> looking glass to query any NTT european router we can see the >>> prefix, being learned via AS 286 then AS 8190, as expected. If >>> we look at any other router outside of europe, there is simply >>> no entry for that prefix. Elsewhere in the world we seem to be >>> fine, we're in every other network I've looked at and general >>> reachability is fine. >>> >>> First step was to contact the NTT NOC, and they've confirmed >>> that there's no Internal routing/config issue on their network, >>> but that they cannot discuss their peering arrangements due to >>> NDAs. We've also picked it up with KPN (AS 286), who have >>> verified that the prefix is visible throughout their network >>> (true), and that they are advertising it to NTT. One thing of >>> note is that Global Crossing are learning our prefix from KPN >>> as well, and the prefix is showing fine in their global >>> tables. >>> >>> We seem to be caught in the classic finger pointing scenario, >>> but I can't get my head around why the prefix is visible in NTT >>> Europe, but not anywhere else, unless they have a config error >>> somewhere on their network. We've checked a few of the routes >>> from AS 8190 and they are in the NTT global tables just fine, >>> and at least in Europe they seem to have the same community >>> values etc. We're still following on with NTT, but can anyone >>> offer some wisdom for new avenues to pursue? >>> >>> Thanks for your help, >>> >>> Bryn Sadler >>> >>> >>> This message has been scanned for viruses by essensys >>> mailcontrol >>> >> > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iF4EAREIAAYFAlBGGlMACgkQ3HuimOHfh+GpNgD+PMX5zFgMcCc7pzLr9e/yskNs RESv+rEeZKC2t1UfpCYA/0vPN8JlgiRLoRi+S/kkJwOEXMlzYMnHS7eGkOn0YU4j =PJwR -----END PGP SIGNATURE----- From rayw at rayw.net Tue Sep 4 10:47:41 2012 From: rayw at rayw.net (Ray Wong) Date: Tue, 4 Sep 2012 08:47:41 -0700 Subject: Blocking MX query In-Reply-To: <22236243.23098.1346769881533.JavaMail.root@benjamin.baylink.com> References: <22236243.23098.1346769881533.JavaMail.root@benjamin.baylink.com> Message-ID: On Tue, Sep 4, 2012 at 7:44 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "William Herrin" > >> There are no "good" subscribers trying to send email direct to a >> remote port 25 from behind a NAT. > > Users, like myself, running Linux on home computers and laptops; our local > sendmail-equivalents will in fact attempt direct delivery to remote SMTP MX > servers, and we generally move around enough that setting a smarthost is > semi-impractical, at least on laptops. OpenVPN, et al... nice for being able to not only relay via the home server, but also access SMB or even NFS shares and the like, which you'd also not want reachable from the outside. From ops.lists at gmail.com Tue Sep 4 10:54:53 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 4 Sep 2012 21:24:53 +0530 Subject: Blocking MX query In-Reply-To: <22236243.23098.1346769881533.JavaMail.root@benjamin.baylink.com> References: <22236243.23098.1346769881533.JavaMail.root@benjamin.baylink.com> Message-ID: What sort of an mta do you run on your laptop that doesnt support smtp auth? On Tuesday, September 4, 2012, Jay Ashworth wrote: > ----- Original Message ----- > > From: "William Herrin" > > > > There are no "good" subscribers trying to send email direct to a > > remote port 25 from behind a NAT. > > Users, like myself, running Linux on home computers and laptops; our local > sendmail-equivalents will in fact attempt direct delivery to remote SMTP MX > servers, and we generally move around enough that setting a smarthost is > semi-impractical, at least on laptops. > > I'm a bad subscriber, Bill? > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > -- Suresh Ramasubramanian (ops.lists at gmail.com) From jra at baylink.com Tue Sep 4 10:57:38 2012 From: jra at baylink.com (Jay Ashworth) Date: Tue, 4 Sep 2012 11:57:38 -0400 (EDT) Subject: Blocking MX query In-Reply-To: Message-ID: <12181047.23108.1346774258434.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Suresh Ramasubramanian" > What sort of an mta do you run on your laptop that doesnt support smtp > auth? SMTP Auth to *arbitrary remote domains' MX servers*? Am I missing something, or are you? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Tue Sep 4 11:05:07 2012 From: jra at baylink.com (Jay Ashworth) Date: Tue, 4 Sep 2012 12:05:07 -0400 (EDT) Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <20120904120038.1e4374fa@bart> Message-ID: <29088432.23124.1346774707888.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "John Peach" > On Tue, 4 Sep 2012 11:57:38 -0400 (EDT) > Jay Ashworth wrote: > > SMTP Auth to *arbitrary remote domains' MX servers*? Am I missing > > something, > > or are you? > > I run an MTA on my server and auth to that from laptops and other > clients. Relaying allowed for authorised users. So, in other words, it's ok to rant and stomp our feet about the end-to-end architecture and how critical it is to support in order to diss NAT, but we're required to ignore it when discussing SMTP? I'm not sure I'm following, there. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From ops.lists at gmail.com Tue Sep 4 11:05:39 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 4 Sep 2012 21:35:39 +0530 Subject: Blocking MX query In-Reply-To: <12181047.23108.1346774258434.JavaMail.root@benjamin.baylink.com> References: <12181047.23108.1346774258434.JavaMail.root@benjamin.baylink.com> Message-ID: Have your desktop MTA configured to relay through your smarthost with smtp auth? Howtos for doing this on sendmail, qmail, postfix etc are over a decade old now. On Sep 4, 2012 9:28 PM, "Jay Ashworth" wrote: > ----- Original Message ----- > > From: "Suresh Ramasubramanian" > > > What sort of an mta do you run on your laptop that doesnt support smtp > > auth? > > SMTP Auth to *arbitrary remote domains' MX servers*? Am I missing > something, > or are you? > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > From sethm at rollernet.us Tue Sep 4 11:31:49 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 04 Sep 2012 09:31:49 -0700 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <29088432.23124.1346774707888.JavaMail.root@benjamin.baylink.com> References: <29088432.23124.1346774707888.JavaMail.root@benjamin.baylink.com> Message-ID: <50462CF5.6030503@rollernet.us> On 9/4/12 9:05 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "John Peach" > >> On Tue, 4 Sep 2012 11:57:38 -0400 (EDT) >> Jay Ashworth wrote: >>> SMTP Auth to *arbitrary remote domains' MX servers*? Am I missing >>> something, >>> or are you? >> >> I run an MTA on my server and auth to that from laptops and other >> clients. Relaying allowed for authorised users. > > So, in other words, it's ok to rant and stomp our feet about the end-to-end > architecture and how critical it is to support in order to diss NAT, but > we're required to ignore it when discussing SMTP? > > I'm not sure I'm following, there. > Feelings on spam = "this is why we can't have nice things" ~Seth From mike at mtcc.com Tue Sep 4 11:59:07 2012 From: mike at mtcc.com (Michael Thomas) Date: Tue, 04 Sep 2012 09:59:07 -0700 Subject: Blocking MX query In-Reply-To: References: Message-ID: <5046335B.80703@mtcc.com> On 09/04/2012 05:05 AM, William Herrin wrote: > There are no "good" subscribers trying to send email direct to a > remote port 25 from behind a NAT. The "good" subscribers are either > using your local smart host or they're using TCP port 587 on their > remote mail server. You may safely block outbound TCP with a > destination of port 25 from behind your NAT without harming reasonable > use of your network. > Would that were true going forward. Consider a world where your home is chock full of purpose built devices, most likely with an embedded web browser for configuration where you have a username/password for each. In the web world this works because there is a hidden assumption that you can use email for user/password reset/recovery and that it works well. When your boxen can't do that because email is blocked, what are you going to do? Reset to factory defaults? Every time I forget? And please lets not get another useless lecture on why the unwashed masses should be using password vaults. They won't. This hidden assumption of a reliable out of band mechanism for account recovery is going to come to the fore as v6 rolls out and ip is as gratuitously added to cheap devices as digital controls are now. Email is the glue that keeps the web world functioning. Until there's something else, it will continue to be needed and its role will expand in the home too. Mike From bill at herrin.us Tue Sep 4 12:22:39 2012 From: bill at herrin.us (William Herrin) Date: Tue, 4 Sep 2012 13:22:39 -0400 Subject: Blocking MX query In-Reply-To: <22236243.23098.1346769881533.JavaMail.root@benjamin.baylink.com> References: <22236243.23098.1346769881533.JavaMail.root@benjamin.baylink.com> Message-ID: On Tue, Sep 4, 2012 at 10:44 AM, Jay Ashworth wrote: >> There are no "good" subscribers trying to send email direct to a >> remote port 25 from behind a NAT. > > Users, like myself, running Linux on home computers and laptops; our local > sendmail-equivalents will in fact attempt direct delivery to remote SMTP MX > servers, and we generally move around enough that setting a smarthost is > semi-impractical, at least on laptops. > > I'm a bad subscriber, Bill? Okay, fair enough. There are no good users *expecting* to send email direct to a remote port 25 from behind a NAT. There are some good users who occasionally run slightly sloppy configurations which might attempt spurious port 25 connections. Good to block port 25. Not good to knee-jerk ban users whose machines happen to poke the port once or twice. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jra at baylink.com Tue Sep 4 13:17:06 2012 From: jra at baylink.com (Jay Ashworth) Date: Tue, 4 Sep 2012 14:17:06 -0400 (EDT) Subject: Blocking MX query In-Reply-To: Message-ID: <11403942.23140.1346782626232.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "William Herrin" > > I'm a bad subscriber, Bill? > > Okay, fair enough. There are no good users *expecting* to send email > direct to a remote port 25 from behind a NAT. There are some good > users who occasionally run slightly sloppy configurations which might > attempt spurious port 25 connections. I do, in fact, expect that. You're alleging that's a bad practice. > Good to block port 25. Not good to knee-jerk ban users whose machines > happen to poke the port once or twice. I wasn't even talking about banning or blocking me. I was, as you'll see in my other response, exercising the end-to-end architecture of the Internet, as members of this list regularly exhort that I should be able to. "This is why we can't have nice things" is not, actually, a sufficiently useful excuse for me to not agree with that principle. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Tue Sep 4 13:22:54 2012 From: jra at baylink.com (Jay Ashworth) Date: Tue, 4 Sep 2012 14:22:54 -0400 (EDT) Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: Message-ID: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > I am confused... I don't understand your comment. It is regularly alleged, on this mailing list, that NAT is bad *because it violates the end-to-end principle of the Internet*, where each host is a full-fledged host, able to connect to any other host to perform transactions. We see it now alleged that the opposite is true: that a laptop, say, like mine, which runs Linux and postfix, and does not require a smarthost to deliver mail to a remote server *is a bad actor* *precisely because it does that* (in attempting to send mail directly to a domain's MX server) *from behind a NAT router*, and possibly different ones at different times. I find these conflicting reports very conflicting. Either the end-to-end principle *is* the Prime Directive... or it is *not*. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From bill at herrin.us Tue Sep 4 13:55:32 2012 From: bill at herrin.us (William Herrin) Date: Tue, 4 Sep 2012 14:55:32 -0400 Subject: Blocking MX query In-Reply-To: <5046335B.80703@mtcc.com> References: <5046335B.80703@mtcc.com> Message-ID: On Tue, Sep 4, 2012 at 12:59 PM, Michael Thomas wrote: > On 09/04/2012 05:05 AM, William Herrin wrote: >> There are no "good" subscribers trying to send email direct to a >> remote port 25 from behind a NAT. The "good" subscribers are either >> using your local smart host or they're using TCP port 587 on their >> remote mail server. You may safely block outbound TCP with a >> destination of port 25 from behind your NAT without harming reasonable >> use of your network. > > Would that were true going forward. Consider a world where your > home is chock full of purpose built devices, most likely with an > embedded web browser for configuration where you have a > username/password for each. In the web world this works because > there is a hidden assumption that you can use email for user/password > reset/recovery and that it works well. Hi Mike, A. What device do you offer as an example of this? I haven't stumbled across one yet. Web sites yes. Physical home devices, no. What I *have* seen is devices that call out to a web server, you make an account on the remote web server to configure them and then all the normal rules about accounts on remote web servers apply. B. Bad hidden assumption. Expect it to fail as more than a few cable and DSL providers are blocking random port 25 outbound. Besides, some folks change email accounts like they change underwear. Relying on that email address still working a year from now is not smart. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Tue Sep 4 14:07:11 2012 From: bill at herrin.us (William Herrin) Date: Tue, 4 Sep 2012 15:07:11 -0400 Subject: Blocking MX query In-Reply-To: <12181047.23108.1346774258434.JavaMail.root@benjamin.baylink.com> References: <12181047.23108.1346774258434.JavaMail.root@benjamin.baylink.com> Message-ID: On Tue, Sep 4, 2012 at 11:57 AM, Jay Ashworth wrote: >> What sort of an mta do you run on your laptop that doesnt support smtp >> auth? > > SMTP Auth to *arbitrary remote domains' MX servers*? Am I missing something, > or are you? You are. You should be doing SMTP Auth to *your* email server on which you have an authorized account and then letting it relay your messages to the world. >> Okay, fair enough. There are no good users *expecting* to send email >> direct to a remote port 25 from behind a NAT. There are some good >> users who occasionally run slightly sloppy configurations which might >> attempt spurious port 25 connections. > > I do, in fact, expect that. You're alleging that's a bad practice. Yes, I am. Here's a few others. http://security.comcast.net/get-help/spam.aspx "Port 25 Blocking Port 25 is conduit on a computer that spammers can take control of and use to send their spam - often without the user ever knowing his/her computer has been "hijacked". Comcast works with our customers to block access to Port 25 and protect their PC. Comcast recommends that our customers establish a more secure email configuration on their PC - Port 587 - We have made it easy by creating a one-click fix that automatically configures your computers to this safer PC configuration." http://qwest.centurylink.com/internethelp/email-troubleshooting-port25.html "CenturyLink filters port 25 to reduce the spread of email viruses and spam (unsolicited email). Filtering port 25 has become the industry standard to reduce the spread of email viruses and spam. These email viruses allow malicious software to control infected computers. These viruses direct the infected machines to send email viruses and spam through port 25. " http://cbl.abuseat.org/nat.html "The simplest and most effective way to stop this is to configure your NAT to prohibit connections to the Internet on port 25 except from real mail servers. Not only does this stop all of these viruses and spams dead in their tracks, the NAT logs will immediately tell you the LAN address of the infected machine. " http://tools.ietf.org/html/rfc5068 "A proactive technique used by some providers is to block all use of port 25 SMTP for mail that is being sent outbound, or to automatically redirect this traffic through a local SMTP proxy, except for hosts that are explicitly authorized." http://www.microsoft.com/security/sir/strategy/default.aspx#!section_2_4 "Block access to port 25 from all hosts on your network other than those you explicitly authorize to perform SMTP relay functions." 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 at mtcc.com Tue Sep 4 14:12:56 2012 From: mike at mtcc.com (Michael Thomas) Date: Tue, 04 Sep 2012 12:12:56 -0700 Subject: Blocking MX query In-Reply-To: References: <5046335B.80703@mtcc.com> Message-ID: <504652B8.7030201@mtcc.com> On 09/04/2012 11:55 AM, William Herrin wrote: > On Tue, Sep 4, 2012 at 12:59 PM, Michael Thomas wrote: >> On 09/04/2012 05:05 AM, William Herrin wrote: >>> There are no "good" subscribers trying to send email direct to a >>> remote port 25 from behind a NAT. The "good" subscribers are either >>> using your local smart host or they're using TCP port 587 on their >>> remote mail server. You may safely block outbound TCP with a >>> destination of port 25 from behind your NAT without harming reasonable >>> use of your network. >> Would that were true going forward. Consider a world where your >> home is chock full of purpose built devices, most likely with an >> embedded web browser for configuration where you have a >> username/password for each. In the web world this works because >> there is a hidden assumption that you can use email for user/password >> reset/recovery and that it works well. > Hi Mike, > > A. What device do you offer as an example of this? I haven't stumbled > across one yet. Web sites yes. Physical home devices, no. > > What I *have* seen is devices that call out to a web server, you make > an account on the remote web server to configure them and then all the > normal rules about accounts on remote web servers apply. I want to buy hardware from people, not their ill-conceived "cloud" service that dies when there's no more business case for it and is probably evil anyway. > > B. Bad hidden assumption. Expect it to fail as more than a few cable > and DSL providers are blocking random port 25 outbound. Besides, some > folks change email accounts like they change underwear. Relying on > that email address still working a year from now is not smart. > I'm well aware of port 25 blocking. I'm saying your assumption that there is *never* any reason for a home originating port 25 traffic is a bad one. It's never been a good one, but the collateral damage was pretty low when NAT's are in the way. v6 will change that, and the collateral damage will rise. Unless you can come up with another ubiquitous out of band method for account recovery, expect the tension -- and help desk calls -- to increase. Mike From sean at seanharlow.info Tue Sep 4 14:21:25 2012 From: sean at seanharlow.info (Sean Harlow) Date: Tue, 4 Sep 2012 15:21:25 -0400 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> References: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> Message-ID: <3004FC06-3024-4688-8421-37E33301CC4D@seanharlow.info> On Sep 4, 2012, at 14:22, Jay Ashworth wrote: > I find these conflicting reports very conflicting. Either the end-to-end > principle *is* the Prime Directive... or it is *not*. Just because something is of extremely high importance does not mean it still can't be overridden when there's good enough reason. In this case, in the majority of "random computer on the internet" IP blocks the ratio of spambots to legitimate mail senders is so far off balance that a whitelisting approach to allowing outbound port 25 traffic is not unreasonable. Unlike the bad kinds of NAT, this doesn't also indiscriminately block thousands of other uses, it exclusively affects email traffic in a way which is trivial for the legitimate user to work around while stopping the random infected hosts in their tracks. Many providers also block traffic on ports like 137 (NetBIOS) on "consumer" space for similar reasons, the malicious or unwanted uses vastly outweigh the legitimate ones. The reason bad NATs get dumped on is because there are better solutions both known and available on the market. If you have an idea for a way to allow your laptop to send messages directly while still stopping or minimizing the ability of the thousands of zombies sharing an ISP with you from doing the same the world would love to hear it. --- Sean Harlow sean at seanharlow.info From jra at baylink.com Tue Sep 4 14:26:39 2012 From: jra at baylink.com (Jay Ashworth) Date: Tue, 4 Sep 2012 15:26:39 -0400 (EDT) Subject: Blocking MX query In-Reply-To: Message-ID: <7525724.23162.1346786799445.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "William Herrin" > > SMTP Auth to *arbitrary remote domains' MX servers*? Am I missing > > something, or are you? > > You are. You should be doing SMTP Auth to *your* email server on which > you have an authorized account and then letting it relay your messages > to the world. Ah; so then the End-To-End Principle is *not* The Prime Directive. Good; thanks. Can we stop flogging people with it who like DNAT, then? Cheers -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From bill at herrin.us Tue Sep 4 14:45:32 2012 From: bill at herrin.us (William Herrin) Date: Tue, 4 Sep 2012 15:45:32 -0400 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> References: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> Message-ID: On Tue, Sep 4, 2012 at 2:22 PM, Jay Ashworth wrote: > It is regularly alleged, on this mailing list, that NAT is bad *because it > violates the end-to-end principle of the Internet*, where each host is a > full-fledged host, able to connect to any other host to perform transactions. That's what firewalls *are for* Jay. They intentionally break end-to-end for communications classified by the network owner as undesirable. Whether a particular firewall employs NAT or not is largely beside the point here. Either way, the firewall is *supposed* to break some of the end to end communication paths. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From dmiller at tiggee.com Tue Sep 4 15:07:06 2012 From: dmiller at tiggee.com (David Miller) Date: Tue, 04 Sep 2012 16:07:06 -0400 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> References: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> Message-ID: <50465F6A.3090307@tiggee.com> On 9/4/2012 2:22 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Owen DeLong" > >> I am confused... I don't understand your comment. > > It is regularly alleged, on this mailing list, that NAT is bad *because it > violates the end-to-end principle of the Internet*, where each host is a > full-fledged host, able to connect to any other host to perform transactions. > > We see it now alleged that the opposite is true: that a laptop, say, like > mine, which runs Linux and postfix, and does not require a smarthost to > deliver mail to a remote server *is a bad actor* *precisely because it does > that* (in attempting to send mail directly to a domain's MX server) *from > behind a NAT router*, and possibly different ones at different times. > > I find these conflicting reports very conflicting. Either the end-to-end > principle *is* the Prime Directive... or it is *not*. > The end-to-end design principle pushes application functions to endpoints instead of placing these functions in the network itself. This principle requires that endpoints be *capable* of creating connections to each other. Network system design must support these connections being initiated by either side - which is where NAT implementations usually fail. There is no requirement that all endpoints be *permitted* to connect to and use any service of any other endpoint. The end-to-end design principle does not require a complete lack of authentication or authorization. I can refuse connections to port 25 on my endpoint (mail server) from hosts that do not conform to my requirements (e.g. those that do not have forward-confirmed reverse DNS) without violating the end-to-end design principle in any way. Thus it is a false chain of conclusions to say that: - end-to-end is violated by restricting connections to/from certain hosts [therefore] - the end-to-end design principle is not important [therefore] - NAT is good ...which I believe is the argument that was being made? ... Ref - http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf > Cheers, > -- jra > From jra at baylink.com Tue Sep 4 15:16:05 2012 From: jra at baylink.com (Jay Ashworth) Date: Tue, 4 Sep 2012 16:16:05 -0400 (EDT) Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: Message-ID: <5332825.23180.1346789765768.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "William Herrin" > That's what firewalls *are for* Jay. They intentionally break > end-to-end for communications classified by the network owner as > undesirable. Whether a particular firewall employs NAT or not is > largely beside the point here. Either way, the firewall is *supposed* > to break some of the end to end communication paths. Correct, Bill. Hopefully, everyone else here who thinks DNAT is the anti-Christ heard the "largely beside the point" part of your assertion, with which I agree. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From mike at mtcc.com Tue Sep 4 15:19:04 2012 From: mike at mtcc.com (Michael Thomas) Date: Tue, 04 Sep 2012 13:19:04 -0700 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <50465F6A.3090307@tiggee.com> References: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> <50465F6A.3090307@tiggee.com> Message-ID: <50466238.8090503@mtcc.com> On 09/04/2012 01:07 PM, David Miller wrote: > > There is no requirement that all endpoints be *permitted* to connect to > and use any service of any other endpoint. The end-to-end design > principle does not require a complete lack of authentication or > authorization. > > I can refuse connections to port 25 on my endpoint (mail server) from > hosts that do not conform to my requirements (e.g. those that do not > have forward-confirmed reverse DNS) without violating the end-to-end > design principle in any way. > > The thing that has never set well with me with ISP blanket port 25 blocking is that the fate sharing is not correct. If I have a mail server and I refuse to take incoming connects from dynamic "home" IP blocks, the fate sharing is correct: I'm only hurting myself if there's collateral damage. When ISP's have blanket port 25, the two parties of the intended conversation never get a say: things just break mysteriously as far as both parties are concerned, but the ISP isn't hurt at all. So they have no incentive to drop their false positive rate. That's not good. Mike From heather.schiller at verizon.com Tue Sep 4 15:34:59 2012 From: heather.schiller at verizon.com (Schiller, Heather A) Date: Tue, 4 Sep 2012 16:34:59 -0400 Subject: 91.201.64.0/22 hijacked? In-Reply-To: <504104A6.5070705@mompl.net> References: <504104A6.5070705@mompl.net> Message-ID: It does not sound as though the original holders of the space know/care - if they are out of business, they probably don't care. If they are actively involved in it, then it's not a hijack. If they haven't updated their company name/website, then it's not a hijack, just poor record keeping. If you suspect the address space is abandoned, or hijacked, report it to RIPE. It may not get deallocated and reassinged until a few months after the bill stops getting paid. --Heather -----Original Message----- From: Jeroen van Aart [mailto:jeroen at mompl.net] Sent: Friday, August 31, 2012 2:39 PM To: NANOG list Subject: 91.201.64.0/22 hijacked? The below email exchange may be of interest to some of you. The practical upshot is that it appears "the 91.201.64.0/22 range was hijacked and should be included into the DROP list". As an interesting aside, quoting a friend: "the original company (that performed dangerous waste utilization) may have been a shady thing in and of itself (..) what most companies calling themselves "ecoservice" (with variations) do is take money for "safe utilisation" of hazardous waste, and then dump it in some old quarry out in the remote (or not so remote) corner of a forest or other natural area (..) they always have criminal links and protection from corrupts officials (often co-owners) and security/law enforcement services" > From: Jeroen van Aart > there is > nothing but crap coming from 91.201.64.0/24. Amongst other things > attempts to spam (through) wordpress sites. > inetnum: 91.201.64.0 - 91.201.67.255 > netname: Donekoserv > descr: DonEkoService Ltd Don - name of the nearby large river. "EkoService" means ecological service. > country: RU > org: ORG-DS41-RIPE > > person: Haralevich Piotr > address: novocherkassk, ul stremyannaya d.6 > mnt-by: MNT-DONECO > phone: +74951000000 nic-hdl: HP2220-RIPE changed: admin at donecoserv.ru 20101117 The company performed dangerous waste utilization: http://donekoservis.alloy.ru/contacts/ http://www.idbo.ru/view/72321/ But domains donecoserv.ru and donekoservis.ru don't exist anymore. traceroute 91.201.64.14 ... 11 router02.spbbm18.ru.edpnet.net (212.71.11.26) 65.979 ms 65.971 ms 66.182 ms 12 77.109.110.62.static.edpnet.net (77.109.110.62) 88.868 ms 47.809 ms 47.715ms 13 195.2.240.234 (195.2.240.234) 48.235 ms 48.546 ms 48.664 ms 14 ajursrv.parohod.biz (95.215.0.206) 47.957 ms 47.752 ms 47.606 ms 15 mail.rx-helps.com (91.201.64.14) 48.206 ms 48.302 ms 48.237 ms SPb (Sankt-Peterburg) is 1500 km from Novocherkassk. parohod.biz also is in Sankt-Peterburg, they offer SEO (which I consider fraud, spamming websites and search engines). Also, see http://support.clean-mx.de/clean-mx/viruses.php?email=admin at donecoserv.ru&response= http://www.spambotsecurity.com/forum/viewtopic.php?f=7&t=795 http://unapprovedpharmacy.wordpress.com/2011/01/03/whois-www-canadianmedsshop-com/ | January 3, 2011 ... | inetnum: 91.201.64.0 91.201.67.255 | netname: Donekoserv | descr: DonEkoService Ltd | country: RU | org: ORG-DS41-RIPE ... | organisation: ORG-DS41-RIPE | org-name: DonEko Service | org-type: OTHER | address: novocherkassk, ul stremyannaya d.6 | e-mail: admin at bulletproof-web.com Note "bulletproof". Therefore, the 91.201.64.0/22 range was hijacked and should be included into the DROP list. From dtaylor at vocalabs.com Tue Sep 4 11:34:43 2012 From: dtaylor at vocalabs.com (Daniel Taylor) Date: Tue, 04 Sep 2012 11:34:43 -0500 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <29088432.23124.1346774707888.JavaMail.root@benjamin.baylink.com> References: <29088432.23124.1346774707888.JavaMail.root@benjamin.baylink.com> Message-ID: <50462DA3.1020700@vocalabs.com> If you are sending direct SMTP on behalf of your domain from essentially random locations, how are we supposed to pick you out from spammers that do the same? Use your MX or SPF senders as your outbound mail agent, especially if they are properly configured with full DNS records so we can tell they are the correct machines to be sending on your behalf, or expect that you will get more mail bounced and lost than the average user because you are being unpredictable and unverifiable. On 09/04/2012 11:05 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "John Peach" >> On Tue, 4 Sep 2012 11:57:38 -0400 (EDT) >> Jay Ashworth wrote: >>> SMTP Auth to *arbitrary remote domains' MX servers*? Am I missing >>> something, >>> or are you? >> I run an MTA on my server and auth to that from laptops and other >> clients. Relaying allowed for authorised users. > So, in other words, it's ok to rant and stomp our feet about the end-to-end > architecture and how critical it is to support in order to diss NAT, but > we're required to ignore it when discussing SMTP? > > I'm not sure I'm following, there. > > Cheers, > -- jra -- Daniel Taylor VP Operations Vocal Laboratories, Inc dtaylor at vocalabs.com 952-941-6580x203 From mike at mtcc.com Tue Sep 4 15:52:59 2012 From: mike at mtcc.com (Michael Thomas) Date: Tue, 04 Sep 2012 13:52:59 -0700 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <50462DA3.1020700@vocalabs.com> References: <29088432.23124.1346774707888.JavaMail.root@benjamin.baylink.com> <50462DA3.1020700@vocalabs.com> Message-ID: <50466A2B.3020402@mtcc.com> On 09/04/2012 09:34 AM, Daniel Taylor wrote: > If you are sending direct SMTP on behalf of your domain from essentially random locations, how are we supposed to pick you out from spammers that do the same? > Use DKIM. Mike From dwessels at verisign.com Tue Sep 4 15:56:08 2012 From: dwessels at verisign.com (Wessels, Duane) Date: Tue, 4 Sep 2012 13:56:08 -0700 Subject: Research Project: Identifying DNSSEC Validators Message-ID: <3A0DCB14-48F2-48D4-9DDB-7C13E0957FAE@verisign.com> Within Verisign Labs we have a project underway to quantify the number of DNSSEC-validating resolvers in use on the Internet. In particular, we want to identify recursive name servers which have configured the root zone trust anchor. We find this data a useful metric for DNSSEC adoption and especially helpful for informing discussions about key rollovers for the root zone. In order for our our measurements to be meaningful, we need to receive queries from a wide variety of recursive name servers. To achieve this goal we ask members of the DNS and networking communities to assist by adding the following single line of HTML code to your web pages: This HTML snippet should have no visible impact on a rendered page. Since nearly all web browsers now implement DNS prefetching, the code above results in a DNS query for the name shown and allows us to characterize the recursive name server that the query goes through. Please note that we are not interested in identifying individual users who have loaded the web page. The name above points to the localhost IP address (127.0.0.1) so even if someone does manage to "click" on it, that request does not reach us. For some preliminary results, please visit the project web page at http://validatorsearch.verisignlabs.com/ We look forward to presenting the full results at a future NANOG meeting. Duane W. From mohta at necom830.hpcl.titech.ac.jp Tue Sep 4 19:29:49 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 05 Sep 2012 09:29:49 +0900 Subject: Blocking MX query In-Reply-To: References: <12181047.23108.1346774258434.JavaMail.root@benjamin.baylink.com> Message-ID: <50469CFD.2080103@necom830.hpcl.titech.ac.jp> Suresh Ramasubramanian wrote: > Have your desktop MTA configured to relay through your smarthost with smtp > auth? Howtos for doing this on sendmail, qmail, postfix etc are over a > decade old now. What if, your home is also behind NAT or blocked port 25? Masataka Ohta From ops.lists at gmail.com Tue Sep 4 19:34:53 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 5 Sep 2012 06:04:53 +0530 Subject: Blocking MX query In-Reply-To: <50469CFD.2080103@necom830.hpcl.titech.ac.jp> References: <12181047.23108.1346774258434.JavaMail.root@benjamin.baylink.com> <50469CFD.2080103@necom830.hpcl.titech.ac.jp> Message-ID: Who cares about NAT when you say smtp auth rather than allowing relay for specific IPs? And if you mean your smarthost is a linux box in your home, it isn't impossible to get static IP broadband .. which is neither natted nor port 25 filtered. On Sep 5, 2012 6:01 AM, "Masataka Ohta" wrote: > Suresh Ramasubramanian wrote: > > > Have your desktop MTA configured to relay through your smarthost with > smtp > > auth? Howtos for doing this on sendmail, qmail, postfix etc are over a > > decade old now. > > What if, your home is also behind NAT or blocked port 25? > > Masataka Ohta > > > From mysidia at gmail.com Tue Sep 4 19:52:58 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 4 Sep 2012 19:52:58 -0500 Subject: Blocking MX query In-Reply-To: <20120904131240.GA8186@gsp.org> References: <20120904131240.GA8186@gsp.org> Message-ID: On 9/4/12, Rich Kulawiec wrote: > You're precisely correct. They've been doing this for many years, > (a) because it's efficient (b) because it evades detection by techniques > that monitor MX query volume (c) because few MX's change often (d) because > it scales beautifully across large botnets. One can begin to envision a spam avoidance scheme; where a mail server is assigned a random IP within an IPv6 prefix based on a EUI64/UUID. Two static MX records are published; each MX referencing short-lived AAAA records with a TTL of 60 seconds or less. One of those AAAA records points to the current IP address of the mail server, and one of those AAAA records point to the "next one". A mail server binds to each address both "previous" and "next" and accepts port 25 connections for mail delivery. Every 60 seconds, the "current address" AAA record is changed to the IP listed in the "next address" AAA record; a new EUI64 is generated, and the "next address" AAAA record is populated with the new randomly generated IPV6 address. A mail server for the domain binds the new IP address and starts listening; and starts tarpitting any new port 25 connections from the previous address in 90 seconds. After 600 seconds, or when the IP is no longer in the most recent 5, an6 existing SMTP connections to the old server IP (from unacceptably slow senders/deliveries) are terminated, and the server removes the old IP from its interface. -- -JH From marka at isc.org Tue Sep 4 20:08:29 2012 From: marka at isc.org (Mark Andrews) Date: Wed, 05 Sep 2012 11:08:29 +1000 Subject: Blocking MX query In-Reply-To: Your message of "Tue, 04 Sep 2012 19:52:58 EST." References: <20120904131240.GA8186@gsp.org> Message-ID: <20120905010829.7599D2479BC1@drugs.dv.isc.org> MUA's can make MX queries to validate entered addresses before SMTP/SUBMISSION is even attempted. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From valdis.kletnieks at vt.edu Tue Sep 4 20:44:17 2012 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Tue, 04 Sep 2012 21:44:17 -0400 Subject: Blocking MX query In-Reply-To: Your message of "Wed, 05 Sep 2012 09:29:49 +0900." <50469CFD.2080103@necom830.hpcl.titech.ac.jp> References: <12181047.23108.1346774258434.JavaMail.root@benjamin.baylink.com> <50469CFD.2080103@necom830.hpcl.titech.ac.jp> Message-ID: <80574.1346809457@turing-police.cc.vt.edu> On Wed, 05 Sep 2012 09:29:49 +0900, Masataka Ohta said: > Suresh Ramasubramanian wrote: > > > Have your desktop MTA configured to relay through your smarthost with smtp > > auth? Howtos for doing this on sendmail, qmail, postfix etc are over a > > decade old now. > > What if, your home is also behind NAT or blocked port 25? Weren't you the one who a few weeks ago was advocating more NAT rather than deploying IPv6? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From ops.lists at gmail.com Tue Sep 4 20:48:37 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 5 Sep 2012 07:18:37 +0530 Subject: Blocking MX query In-Reply-To: <20120905010829.7599D2479BC1@drugs.dv.isc.org> References: <20120904131240.GA8186@gsp.org> <20120905010829.7599D2479BC1@drugs.dv.isc.org> Message-ID: On Wed, Sep 5, 2012 at 6:38 AM, Mark Andrews wrote: > > MUA's can make MX queries to validate entered addresses > before SMTP/SUBMISSION is even attempted. > Sure but not on this guy's network as he's transparently proxying dns and blocking MX requests on his proxy Of course a bot can build up a rich cache of MX records from elsewhere and send from a botted 3g modem connected host on his network From marka at isc.org Tue Sep 4 21:00:33 2012 From: marka at isc.org (Mark Andrews) Date: Wed, 05 Sep 2012 12:00:33 +1000 Subject: Blocking MX query In-Reply-To: Your message of "Wed, 05 Sep 2012 07:18:37 +0530." References: <20120904131240.GA8186@gsp.org> <20120905010829.7599D2479BC1@drugs.dv.isc.org> Message-ID: <20120905020033.320D6247A6F9@drugs.dv.isc.org> In message , Suresh Ramasubramanian writes: > On Wed, Sep 5, 2012 at 6:38 AM, Mark Andrews wrote: > > > > MUA's can make MX queries to validate entered addresses > > before SMTP/SUBMISSION is even attempted. > > > > Sure but not on this guy's network as he's transparently proxying dns > and blocking MX requests on his proxy Well he was looking for software to block the queries. There is a whole mentality that homes don't need X which on closer examination just doesn't bear up to scrutany. This includes blocking SMTP or don't you think home users are entitled to have privacy when it comes to whom they email? STARTTLS from anywhere to anywhere is possible today and is not vulnerable to interception except in the MX's themselves. You can secure the MX records (and their absense) and secure the CERTs used by STARTTLS. > Of course a bot can build up a rich cache of MX records from elsewhere > and send from a botted 3g modem connected host on his network -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From ops.lists at gmail.com Tue Sep 4 21:14:54 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 5 Sep 2012 07:44:54 +0530 Subject: Blocking MX query In-Reply-To: <20120905020033.320D6247A6F9@drugs.dv.isc.org> References: <20120904131240.GA8186@gsp.org> <20120905010829.7599D2479BC1@drugs.dv.isc.org> <20120905020033.320D6247A6F9@drugs.dv.isc.org> Message-ID: This is a bit of a slippery slope. There is broad agreement that SPs need to block port 25 outbound (and inbound) on dynamic IP space. And he did say he's in a country where he's obliged by law to filter out porn (and I guess anything else his country's government doesn't like). Where do blocking MX record lookups fit in between the porn blocking and the port 25 filtering? Rather closer to port 25 filtering I'd say, but your call. This is not a user privacy issue at all. Static IP broadband is entirely available if you should decide you want to run a mailserver at your home. And for people using outlook (or postfix) on their desktop to relay through a smarthost, MX lookups don't matter one way or the other. --srs On Wed, Sep 5, 2012 at 7:30 AM, Mark Andrews wrote: > > Well he was looking for software to block the queries. There is a > whole mentality that homes don't need X which on closer examination > just doesn't bear up to scrutany. This includes blocking SMTP or > don't you think home users are entitled to have privacy when it > comes to whom they email? > > STARTTLS from anywhere to anywhere is possible today and is not > vulnerable to interception except in the MX's themselves. You can > secure the MX records (and their absense) and secure the CERTs used > by STARTTLS. -- Suresh Ramasubramanian (ops.lists at gmail.com) From george.herbert at gmail.com Tue Sep 4 21:18:44 2012 From: george.herbert at gmail.com (George Herbert) Date: Tue, 4 Sep 2012 19:18:44 -0700 Subject: Blocking MX query In-Reply-To: References: <12181047.23108.1346774258434.JavaMail.root@benjamin.baylink.com> Message-ID: On Sep 4, 2012, at 12:07 PM, William Herrin wrote: > You are. You should be doing SMTP Auth to *your* email server on which > you have an authorized account and then letting it relay your messages > to the world. This is not the thread for this conversation per se. The practicality of general ISP 25 blocking is established for antispam purposes. So are power users running home domains. Different user profiles. Different circumstances. George William Herbert Sent from my iPhone From ibrahim1 at gmail.com Tue Sep 4 21:57:32 2012 From: ibrahim1 at gmail.com (Ibrahim) Date: Wed, 5 Sep 2012 09:57:32 +0700 Subject: Blocking MX query In-Reply-To: References: <12181047.23108.1346774258434.JavaMail.root@benjamin.baylink.com> Message-ID: All, thanks for the input and comment. In summary, I will block TCP port 25. My DNS loadbalancer (F5) can filter MX query and need license to do it. But given the information the botnet use address list with pre-resolved IP addresses then blocking MX query is not the answer :-) Thanks & Regards Ibrahim On Wed, Sep 5, 2012 at 9:18 AM, George Herbert wrote: > > > > On Sep 4, 2012, at 12:07 PM, William Herrin wrote: > > > You are. You should be doing SMTP Auth to *your* email server on which > > you have an authorized account and then letting it relay your messages > > to the world. > > > This is not the thread for this conversation per se. The practicality of > general ISP 25 blocking is established for antispam purposes. So are power > users running home domains. Different user profiles. Different > circumstances. > > > George William Herbert > Sent from my iPhone > From mysidia at gmail.com Tue Sep 4 22:06:13 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 4 Sep 2012 22:06:13 -0500 Subject: Blocking MX query In-Reply-To: <20120905020033.320D6247A6F9@drugs.dv.isc.org> References: <20120904131240.GA8186@gsp.org> <20120905010829.7599D2479BC1@drugs.dv.isc.org> <20120905020033.320D6247A6F9@drugs.dv.isc.org> Message-ID: On 9/4/12, Mark Andrews wrote: > In message > , Suresh > Ramasubramanian writes: > STARTTLS from anywhere to anywhere is possible today and is not > vulnerable to interception except in the MX's themselves. You can > secure the MX records (and their absense) and secure the CERTs used > by STARTTLS. You can also use SMTPS on port 465; or STARTTLS on port 587. Most MX servers don't support TLS or SSL, so it could be privacy neutral, and many MX server operators utilize dynamic host RBLs, even if STARTTLS connections are allowed. It is possible for end user to tunnel SMTP traffic over VPN, SSL, or SSH to a private submit server on a trusted network. Blocking initial outgoing TCP SYN for port 25 completely creates a predictable failure scenario. which is to be encouraged. ISPs very commonly block outgoing initial SYNs to that port. And ISPs also commonly block 23, 135 - 139, 190, 389, 445, 1025, 1080, 1433 - 1434, 3380, 3389, 5060, 5070, 5631, 6667, 31337, 559. Some may block connections to all outgoing ports, except a small number. Those are all accepted practices, with increasing annoyance, and increasing predictable breakage, the more ports are messed with. Blocking few/no ports is desirable; and port 25 is so widely blocked, that MUAs should be set to 587 + authenticated submit in the first place. Tampering with the contents of packets, "blocking" application level traffic by creating fake application layer error messages, for example fake nxdomain/servfail response, or fake "550 rejected" SMTP response, is to be strongly discouraged, because it causes unpredictable application failures. ISP routers aren't supposed to reject/accept packets based on application layer data. The exception would be you manage the end user computers, and dictate a very precise list of applications, so you can pick ones whose vendors list it as a supported thing, or you have gone through rigorous testing procedures. (Enterprise IDS units, that analyze packets and seek to block attacks by reacting to application content, are OK, for example) >> Of course a bot can build up a rich cache of MX records from elsewhere >> and send from a botted 3g modem connected host on his network Yes. It can also "probe" randomly for servers listening on port 25 based on A record lookup instead of MX, or by using Reverse DNS to find a domain, and then guess e-mail addresses. > -- > Mark Andrews, ISC -- -JH From marka at isc.org Tue Sep 4 22:22:28 2012 From: marka at isc.org (Mark Andrews) Date: Wed, 05 Sep 2012 13:22:28 +1000 Subject: Blocking MX query In-Reply-To: Your message of "Tue, 04 Sep 2012 22:06:13 EST." References: <20120904131240.GA8186@gsp.org> <20120905010829.7599D2479BC1@drugs.dv.isc.org> <20120905020033.320D6247A6F9@drugs.dv.isc.org> Message-ID: <20120905032228.C8065247B34D@drugs.dv.isc.org> In message , Jimmy Hess writes: > On 9/4/12, Mark Andrews wrote: > > In message > > , Suresh > > Ramasubramanian writes: > > STARTTLS from anywhere to anywhere is possible today and is not > > vulnerable to interception except in the MX's themselves. You can > > secure the MX records (and their absense) and secure the CERTs used > > by STARTTLS. > > You can also use SMTPS on port 465; or STARTTLS on port 587. Most MX > servers don't support TLS or SSL, so it could be privacy neutral, and > many MX server operators utilize dynamic host RBLs, even if STARTTLS > connections are allowed. It is possible for end user to tunnel SMTP > traffic over VPN, SSL, or SSH to a private submit server on a trusted > network. You missed the point. It *is* a privacy problem if my ISP can see the "MAIL TO: ". It is *unreasonable* to expect everyone to run their own submission server to avoid this privacy problem. Most MX's don't *currently* support STARTTLS because until recently it was difficult to prevent various MiM interception attacks and you had to pay for CERTs. Both of these reasons are in the process of going away. You can prevent MiM on MX records by using DNSSEC. You can generate and publish your own CERT records using DANE. > Blocking initial outgoing TCP SYN for port 25 completely creates a > predictable failure scenario. which is to be encouraged. Only if you don't care for user privacy. There is way to much data collection already. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mohta at necom830.hpcl.titech.ac.jp Tue Sep 4 22:40:30 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 05 Sep 2012 12:40:30 +0900 Subject: Blocking MX query In-Reply-To: <80574.1346809457@turing-police.cc.vt.edu> References: <12181047.23108.1346774258434.JavaMail.root@benjamin.baylink.com> <50469CFD.2080103@necom830.hpcl.titech.ac.jp> <80574.1346809457@turing-police.cc.vt.edu> Message-ID: <5046C9AE.4090101@necom830.hpcl.titech.ac.jp> valdis.kletnieks at vt.edu wrote: >>> Have your desktop MTA configured to relay through your smarthost with smtp >>> auth? Howtos for doing this on sendmail, qmail, postfix etc are over a >>> decade old now. >> >> What if, your home is also behind NAT or blocked port 25? > > Weren't you the one who a few weeks ago was advocating more NAT rather than > deploying IPv6? NAT, here, means dumb NAT. With most, if not all, pseudo ISPs using NAT, you can't expect port forwarding services. While ISPs in the future should use not IPv6 but NAT with fixed IP addresses and sets of port numbers assigned to their customers, keeping the end to end transparency, it does not solve the problem of blocked port 25. Note that IPv6 do not solve the problem of blocked port 25, either. Masataka Ohta From ops.lists at gmail.com Tue Sep 4 22:45:12 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 5 Sep 2012 09:15:12 +0530 Subject: Blocking MX query In-Reply-To: <5046C9AE.4090101@necom830.hpcl.titech.ac.jp> References: <12181047.23108.1346774258434.JavaMail.root@benjamin.baylink.com> <50469CFD.2080103@necom830.hpcl.titech.ac.jp> <80574.1346809457@turing-police.cc.vt.edu> <5046C9AE.4090101@necom830.hpcl.titech.ac.jp> Message-ID: On Wed, Sep 5, 2012 at 9:10 AM, Masataka Ohta wrote: > While ISPs in the future should use not IPv6 but NAT with fixed > IP addresses and sets of port numbers assigned to their customers, > keeping the end to end transparency, it does not solve the > problem of blocked port 25. > > Note that IPv6 do not solve the problem of blocked port 25, either. So - now with ipv6 you're going to see "hi, my toto highly computerized toilet is trying to make outbound port 25 connections to gmail" http://www.telecoms.com/48734/vodafone-and-ibm-team-up-on-connected-home-appliances/ -- Suresh Ramasubramanian (ops.lists at gmail.com) From randy at psg.com Wed Sep 5 02:26:55 2012 From: randy at psg.com (Randy Bush) Date: Wed, 05 Sep 2012 14:26:55 +0700 Subject: Fwd: RPKI Pilot Participant Notice References: <50462945.7090000@arin.net> Message-ID: can you find the fatal flaw? [ hint: how does an isp in phnom penh validate my route? ] randy -------------- next part -------------- An embedded message was scrubbed... From: ARIN Subject: RPKI Pilot Participant Notice Date: Tue, 04 Sep 2012 12:16:05 -0400 Size: 1480 URL: From gtheo at iti.gr Wed Sep 5 05:34:24 2012 From: gtheo at iti.gr (Georgios Theodoridis) Date: Wed, 05 Sep 2012 13:34:24 +0300 Subject: 91.201.64.0/22 hijacked? In-Reply-To: References: <504104A6.5070705@mompl.net> Message-ID: <50472AB0.3000703@iti.gr> I was wondering if there is a repository with references of prefix hijack cases. We would like to use such information for a BGP anomaly detection analysis that we are carrying out in our research centre. Unfortunately, apart from the well known cases (Youtube-Pakistan case in 2008 and the China case in 2010, neither of which is an actual hijack, since they both took place due to misconfigurations and not due to malicious cyber attacks) there is lack of ground truth information that can be used for the validation of our techniques. Thank you very much in advance, George . On 4/9/2012 11:34 ??, Schiller, Heather A wrote: > It does not sound as though the original holders of the space know/care - if they are out of business, they probably don't care. If they are actively involved in it, then it's not a hijack. If they haven't updated their company name/website, then it's not a hijack, just poor record keeping. > > If you suspect the address space is abandoned, or hijacked, report it to RIPE. It may not get deallocated and reassinged until a few months after the bill stops getting paid. > > --Heather > > -----Original Message----- > From: Jeroen van Aart [mailto:jeroen at mompl.net] > Sent: Friday, August 31, 2012 2:39 PM > To: NANOG list > Subject: 91.201.64.0/22 hijacked? > > The below email exchange may be of interest to some of you. The practical upshot is that it appears "the 91.201.64.0/22 range was hijacked and should be included into the DROP list". > > As an interesting aside, quoting a friend: > > "the original company (that performed dangerous waste utilization) may have been a shady thing in and of itself (..) what most companies calling themselves "ecoservice" (with variations) do is take money for "safe utilisation" of hazardous waste, and then dump it in some old quarry out in the remote (or not so remote) corner of a forest or other natural area (..) they always have criminal links and protection from corrupts officials (often co-owners) and security/law enforcement services" > > >> From: Jeroen van Aart >> there is >> nothing but crap coming from 91.201.64.0/24. Amongst other things >> attempts to spam (through) wordpress sites. >> inetnum: 91.201.64.0 - 91.201.67.255 >> netname: Donekoserv >> descr: DonEkoService Ltd > Don - name of the nearby large river. > "EkoService" means ecological service. > >> country: RU >> org: ORG-DS41-RIPE >> >> person: Haralevich Piotr >> address: novocherkassk, ul stremyannaya d.6 >> mnt-by: MNT-DONECO >> phone: +74951000000 > nic-hdl: HP2220-RIPE > changed: admin at donecoserv.ru 20101117 > > The company performed dangerous waste utilization: > http://donekoservis.alloy.ru/contacts/ > http://www.idbo.ru/view/72321/ > But domains donecoserv.ru and donekoservis.ru don't exist anymore. > > traceroute 91.201.64.14 > ... > 11 router02.spbbm18.ru.edpnet.net (212.71.11.26) 65.979 ms 65.971 ms > 66.182 ms > 12 77.109.110.62.static.edpnet.net (77.109.110.62) 88.868 ms 47.809 ms 47.715ms > 13 195.2.240.234 (195.2.240.234) 48.235 ms 48.546 ms 48.664 ms > 14 ajursrv.parohod.biz (95.215.0.206) 47.957 ms 47.752 ms 47.606 ms > 15 mail.rx-helps.com (91.201.64.14) 48.206 ms 48.302 ms 48.237 ms > > SPb (Sankt-Peterburg) is 1500 km from Novocherkassk. > parohod.biz also is in Sankt-Peterburg, they offer SEO (which I consider fraud, spamming websites and search engines). > > Also, see > http://support.clean-mx.de/clean-mx/viruses.php?email=admin at donecoserv.ru&response= > http://www.spambotsecurity.com/forum/viewtopic.php?f=7&t=795 > > http://unapprovedpharmacy.wordpress.com/2011/01/03/whois-www-canadianmedsshop-com/ > | January 3, 2011 > ... > | inetnum: 91.201.64.0 91.201.67.255 > | netname: Donekoserv > | descr: DonEkoService Ltd > | country: RU > | org: ORG-DS41-RIPE > ... > | organisation: ORG-DS41-RIPE > | org-name: DonEko Service > | org-type: OTHER > | address: novocherkassk, ul stremyannaya d.6 > | e-mail: admin at bulletproof-web.com > > Note "bulletproof". > > Therefore, the 91.201.64.0/22 range was hijacked and should be included into the DROP list. > > From dtaylor at vocalabs.com Wed Sep 5 07:56:00 2012 From: dtaylor at vocalabs.com (Daniel Taylor) Date: Wed, 05 Sep 2012 07:56:00 -0500 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <50466A2B.3020402@mtcc.com> References: <29088432.23124.1346774707888.JavaMail.root@benjamin.baylink.com> <50462DA3.1020700@vocalabs.com> <50466A2B.3020402@mtcc.com> Message-ID: <50474BE0.4030808@vocalabs.com> On 09/04/2012 03:52 PM, Michael Thomas wrote: > On 09/04/2012 09:34 AM, Daniel Taylor wrote: >> If you are sending direct SMTP on behalf of your domain from >> essentially random locations, how are we supposed to pick you out >> from spammers that do the same? >> > > Use DKIM. You say that like it's a lower bar than setting up a fixed SMTP server and using that. Besides, doesn't DKIM break on mailing lists? -- Daniel Taylor VP Operations Vocal Laboratories, Inc dtaylor at vocalabs.com 952-941-6580x203 From thegameiam at yahoo.com Wed Sep 5 08:00:03 2012 From: thegameiam at yahoo.com (David Barak) Date: Wed, 5 Sep 2012 09:00:03 -0400 Subject: Blocking MX query In-Reply-To: References: <12181047.23108.1346774258434.JavaMail.root@benjamin.baylink.com> <50469CFD.2080103@necom830.hpcl.titech.ac.jp> <80574.1346809457@turing-police.cc.vt.edu> <5046C9AE.4090101@necom830.hpcl.titech.ac.jp> Message-ID: On Sep 4, 2012, at 11:45 PM, Suresh Ramasubramanian wrote: > > So - now with ipv6 you're going to see "hi, my toto highly > computerized toilet is trying to make outbound port 25 connections to > gmail" > > http://www.telecoms.com/48734/vodafone-and-ibm-team-up-on-connected-home-appliances/ > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) > Gives a new meaning to a sh*** connection. Or perhaps to flushing a mail queue... David Sent from a mobile device, please forgive autocorrection. From henry at hup.org Wed Sep 5 09:50:12 2012 From: henry at hup.org (Henry Stryker) Date: Wed, 05 Sep 2012 07:50:12 -0700 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <50474BE0.4030808@vocalabs.com> References: <29088432.23124.1346774707888.JavaMail.root@benjamin.baylink.com> <50462DA3.1020700@vocalabs.com> <50466A2B.3020402@mtcc.com> <50474BE0.4030808@vocalabs.com> Message-ID: <504766A4.4040800@hup.org> On 09/05/12 05:56 , Daniel Taylor wrote: >> Use DKIM. > You say that like it's a lower bar than setting up a fixed SMTP server > and using that. > Besides, doesn't DKIM break on mailing lists? Not only that, but a majority of spam I receive lately has a valid DKIM signature. They are adaptive, like cockroaches. From izaac at setec.org Wed Sep 5 10:11:27 2012 From: izaac at setec.org (Izaac) Date: Wed, 5 Sep 2012 11:11:27 -0400 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <504766A4.4040800@hup.org> References: <29088432.23124.1346774707888.JavaMail.root@benjamin.baylink.com> <50462DA3.1020700@vocalabs.com> <50466A2B.3020402@mtcc.com> <50474BE0.4030808@vocalabs.com> <504766A4.4040800@hup.org> Message-ID: <20120905T145402Z@localhost> On Wed, Sep 05, 2012 at 07:50:12AM -0700, Henry Stryker wrote: > Not only that, but a majority of spam I receive lately has a valid DKIM > signature. They are adaptive, like cockroaches. This is why tcp port 25 filtering is totally effective and will remain so forever. Definitely worth breaking basic function principles of a global communications network over which trillions of dollars of commerce occur. -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__ From mike at mtcc.com Wed Sep 5 10:19:40 2012 From: mike at mtcc.com (Michael Thomas) Date: Wed, 05 Sep 2012 08:19:40 -0700 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <50474BE0.4030808@vocalabs.com> References: <29088432.23124.1346774707888.JavaMail.root@benjamin.baylink.com> <50462DA3.1020700@vocalabs.com> <50466A2B.3020402@mtcc.com> <50474BE0.4030808@vocalabs.com> Message-ID: <50476D8C.8010409@mtcc.com> On 09/05/2012 05:56 AM, Daniel Taylor wrote: > > On 09/04/2012 03:52 PM, Michael Thomas wrote: >> On 09/04/2012 09:34 AM, Daniel Taylor wrote: >>> If you are sending direct SMTP on behalf of your domain from essentially random locations, how are we supposed to pick you out from spammers that do the same? >>> >> >> Use DKIM. > You say that like it's a lower bar than setting up a fixed SMTP server and using that. I say it like it addresses your concern. Mike From mstorck at voipgate.com Wed Sep 5 10:32:37 2012 From: mstorck at voipgate.com (Marc Storck) Date: Wed, 5 Sep 2012 15:32:37 +0000 Subject: Level 3 BGP Advertisements In-Reply-To: Message-ID: >Just for kicks, I tried using a .0.0/16 and .255.255/16 adress for stuff >in IOS (configured it as loopback and tried to establish bgp sessions >etc), that didn't work so well. I don't remember exactly what the problem >was, but I did indeed run into problems. LU-CIX uses .255 and .0 for their route servers. See [1]. And it looks like most router fabrics can now handle BGP sessions to those addresses. Regards, Marc [1] http://www.lu-cix.lu/route-servers.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6079 bytes Desc: not available URL: From os10rules at gmail.com Wed Sep 5 10:46:34 2012 From: os10rules at gmail.com (Greg Ihnen) Date: Wed, 5 Sep 2012 11:46:34 -0400 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <20120905T145402Z@localhost> References: <29088432.23124.1346774707888.JavaMail.root@benjamin.baylink.com> <50462DA3.1020700@vocalabs.com> <50466A2B.3020402@mtcc.com> <50474BE0.4030808@vocalabs.com> <504766A4.4040800@hup.org> <20120905T145402Z@localhost> Message-ID: On Wed, Sep 5, 2012 at 11:11 AM, Izaac wrote: > On Wed, Sep 05, 2012 at 07:50:12AM -0700, Henry Stryker wrote: > > Not only that, but a majority of spam I receive lately has a valid DKIM > > signature. They are adaptive, like cockroaches. > > This is why tcp port 25 filtering is totally effective and will remain so > forever. Definitely worth breaking basic function principles of a > global communications network over which trillions of dollars of commerce > occur. > > -- > . ___ ___ . . ___ > . \ / |\ |\ \ > . _\_ /__ |-\ |-\ \__ > > But as someone pointed out further back on this thread people who want to have their mail servers available to people who are on the other side of port 25 filtering just use the alternate ports. So then what does filtering port 25 accomplish? Greg From sean at seanharlow.info Wed Sep 5 10:49:02 2012 From: sean at seanharlow.info (Sean Harlow) Date: Wed, 5 Sep 2012 11:49:02 -0400 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <20120905T145402Z@localhost> References: <29088432.23124.1346774707888.JavaMail.root@benjamin.baylink.com> <50462DA3.1020700@vocalabs.com> <50466A2B.3020402@mtcc.com> <50474BE0.4030808@vocalabs.com> <504766A4.4040800@hup.org> <20120905T145402Z@localhost> Message-ID: On Sep 5, 2012, at 11:11, Izaac wrote: > This is why tcp port 25 filtering is totally effective and will remain so > forever. Definitely worth breaking basic function principles of a > global communications network over which trillions of dollars of commerce > occur. Two things to note: 1. Restricting outbound port 25 is nothing new. It's been in use since before SPF or DKIM were under development, yet it hasn't been defeated/bypassed. Henry didn't specify whether the DKIM-valid messages he received were forged or if they just came from a random spam domain. If the latter, of course that's trivial for spammers to make appear legitimate because the only goal of such systems is to verify that the sender controls or is approved by the domain the message claims to be from. 2. The reason port 25 blocks remain effective is that there really isn't a bypass. If you want to spam, at some point you must establish a TCP connection to port 25 on the destination mail server. You can either do this from your own machines (where a good hosting provider will cut you off in a hurry) or by using someone else's illegitimately. Servers tend to be located in datacenters where again a good provider will take action, so botted end-user machines are obviously a huge thing to spammers. Eliminate the ability for the majority of those bots to make said port 25 connections, you've now forced them in to a much smaller operating area where they're more likely to be found. The only "bypass" is to go back to using their own machines or compromised equipment on higher-grade connections. --- Sean Harlow sean at seanharlow.info From sean at seanharlow.info Wed Sep 5 10:51:54 2012 From: sean at seanharlow.info (Sean Harlow) Date: Wed, 5 Sep 2012 11:51:54 -0400 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: References: <29088432.23124.1346774707888.JavaMail.root@benjamin.baylink.com> <50462DA3.1020700@vocalabs.com> <50466A2B.3020402@mtcc.com> <50474BE0.4030808@vocalabs.com> <504766A4.4040800@hup.org> <20120905T145402Z@localhost> Message-ID: On Sep 5, 2012, at 11:46, Greg Ihnen wrote: > But as someone pointed out further back on this thread people who want to > have their mail servers available to people who are on the other side of > port 25 filtering just use the alternate ports. So then what does filtering > port 25 accomplish? The alternate port 587 is for users of that mail server to send mail through it, presumably authenticated, not for receipt of random mail from the internet. This allows those users to relay email through their server unaffected while behind a port 25 block. Configuring it to accept all messages on that port would defeat the purpose. --- Sean Harlow sean at seanharlow.info From mike at mtcc.com Wed Sep 5 11:13:18 2012 From: mike at mtcc.com (Michael Thomas) Date: Wed, 05 Sep 2012 09:13:18 -0700 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <504766A4.4040800@hup.org> References: <29088432.23124.1346774707888.JavaMail.root@benjamin.baylink.com> <50462DA3.1020700@vocalabs.com> <50466A2B.3020402@mtcc.com> <50474BE0.4030808@vocalabs.com> <504766A4.4040800@hup.org> Message-ID: <50477A1E.6030802@mtcc.com> On 09/05/2012 07:50 AM, Henry Stryker wrote: > Not only that, but a majority of spam I receive lately has a valid DKIM signature. They are adaptive, like cockroaches. The "I" part of DKIM is "Identified". That's all it promises. It's a feature, not a bug, that spammers use it. Mike From mike at mtcc.com Wed Sep 5 11:17:49 2012 From: mike at mtcc.com (Michael Thomas) Date: Wed, 05 Sep 2012 09:17:49 -0700 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: References: <29088432.23124.1346774707888.JavaMail.root@benjamin.baylink.com> <50462DA3.1020700@vocalabs.com> <50466A2B.3020402@mtcc.com> <50474BE0.4030808@vocalabs.com> <504766A4.4040800@hup.org> <20120905T145402Z@localhost> Message-ID: <50477B2D.50206@mtcc.com> On 09/05/2012 08:49 AM, Sean Harlow wrote: > 2. The reason port 25 blocks remain effective is that there really isn't a bypass. In the Maginot Line sense, manifestly. Mike From markk at arin.net Wed Sep 5 13:56:33 2012 From: markk at arin.net (Mark Kosters) Date: Wed, 5 Sep 2012 18:56:33 +0000 Subject: RPKI Pilot Participant Notice In-Reply-To: Message-ID: On 9/5/12 3:26 AM, "Randy Bush" wrote: >can you find the fatal flaw? > >[ hint: how does an isp in phnom penh validate my route? ] > >randy Hi Randy Your question is a bit cryptic. Could you be more specific about your concern? Thanks, Mark From morgan.miskell at caro.net Wed Sep 5 13:58:25 2012 From: morgan.miskell at caro.net (Morgan Miskell) Date: Wed, 05 Sep 2012 14:58:25 -0400 Subject: Tata Equinix Message-ID: <1346871505.18123.50.camel@cromagnon> Anyone on the list from Tata that can help address a Tata Equinix Ashburn issue? -- Morgan A. Miskell CaroNet Data Centers 704-643-8330 x206 ---------------------------------------------------------------------------- The information contained in this e-mail is confidential and is intended only for the named recipient(s). If you are not the intended recipient you must not copy, distribute, or take any action or reliance on it. If you have received this e-mail in error, please notify the sender. Any unauthorized disclosure of the information contained in this e-mail is strictly prohibited. ---------------------------------------------------------------------------- From richard.barnes at gmail.com Wed Sep 5 14:05:04 2012 From: richard.barnes at gmail.com (Richard Barnes) Date: Wed, 5 Sep 2012 15:05:04 -0400 Subject: RPKI Pilot Participant Notice In-Reply-To: References: Message-ID: I think Randy meant to imply that requiring anyone that wants to actually use the RPKI to make a legal agreement with ARIN might not be the best way to encourage deployment. On Wed, Sep 5, 2012 at 2:56 PM, Mark Kosters wrote: > On 9/5/12 3:26 AM, "Randy Bush" wrote: > >>can you find the fatal flaw? >> >>[ hint: how does an isp in phnom penh validate my route? ] >> >>randy > > Hi Randy > > Your question is a bit cryptic. Could you be more specific about your > concern? > > Thanks, > Mark > > > From henry at hup.org Wed Sep 5 14:07:22 2012 From: henry at hup.org (Henry Stryker) Date: Wed, 05 Sep 2012 12:07:22 -0700 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <50477A1E.6030802@mtcc.com> References: <29088432.23124.1346774707888.JavaMail.root@benjamin.baylink.com> <50462DA3.1020700@vocalabs.com> <50466A2B.3020402@mtcc.com> <50474BE0.4030808@vocalabs.com> <504766A4.4040800@hup.org> <50477A1E.6030802@mtcc.com> Message-ID: <5047A2EA.8010307@hup.org> On 09/05/12 09:13 , Michael Thomas wrote: > The "I" part of DKIM is "Identified". That's all it promises. It's a > feature, not a bug, that spammers use it. Which is why DKIM does not really address any concerns. The spammers have reduced its value. I am retired now, but do run my own mail server from home. It is a challenge. Not all static IP's provided by ISP's are outside of "home IP groups", so you will find some of them blocked at some large domains. SPF and DKIM do help, a bit. What I have found really makes the home MTA possible are 1. a "real" static IP 2. proper DNS (A and PTR; PTR must at least exist) 3. tuning your MTA to respect the restraints of various large ISP's Lacking 1 & 2, it is just not worth the effort attempting direct delivery, if you value actual delivery of your email. I would never even attempt such from a peripatetic laptop. From morrowc.lists at gmail.com Wed Sep 5 14:24:23 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 5 Sep 2012 15:24:23 -0400 Subject: RPKI Pilot Participant Notice In-Reply-To: References: Message-ID: On Wed, Sep 5, 2012 at 3:05 PM, Richard Barnes wrote: > I think Randy meant to imply that requiring anyone that wants to > actually use the RPKI to make a legal agreement with ARIN might not be define 'use'... o 'stick their objects into the repo' sure a contract sounds good o 'access the repo to download content' - no, that doesn't sound like it needs a contract is this a messaging problem/issue or did ARIN mean that 'to download content you must sign an agreement/contract with ARIN?' (I hope that the answer is: "of course not! that sounds silly... our messaging could be improved") a closer (by me) reading of: " In order to access the production RPKI TAL, you will first have to agree to ARIN's Relying Party Agreement before the TAL will be emailed to you. To request the TAL after the production release, follow this link: http://www.arin.net/public/rpki/tal/index.xhtml" though kinda leads me into the hole randy/richard fell into... 'to poke the TAL and figure out where things are, you have to sign an agreement'. Isn't the structure of the global system something like: "each asn has a publication point, potentially some share publication-points, everyone has to access everyone else's publication point" and 'TAL' ... seems like odd to me as an RP, don't I want the one TA from IANA (yes, eventually) or at the very least the 1 from each RIR ? (which is a simple single item to download and use in validating the content I get from all the rest of the world?) -chris > the best way to encourage deployment. > > > On Wed, Sep 5, 2012 at 2:56 PM, Mark Kosters wrote: >> On 9/5/12 3:26 AM, "Randy Bush" wrote: >> >>>can you find the fatal flaw? >>> >>>[ hint: how does an isp in phnom penh validate my route? ] >>> >>>randy >> >> Hi Randy >> >> Your question is a bit cryptic. Could you be more specific about your >> concern? >> >> Thanks, >> Mark >> >> >> > From gary.buhrmaster at gmail.com Wed Sep 5 14:32:42 2012 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Wed, 5 Sep 2012 19:32:42 +0000 Subject: RPKI Pilot Participant Notice In-Reply-To: References: Message-ID: On Wed, Sep 5, 2012 at 7:24 PM, Christopher Morrow wrote: ..... > a closer (by me) reading of: > " In order to access the > production RPKI TAL, you will first have to agree to ARIN's Relying > Party Agreement before the TAL will be emailed to you. To request the > TAL after the production release, follow this link: > http://www.arin.net/public/rpki/tal/index.xhtml" > > though kinda leads me into the hole randy/richard fell into... 'to > poke the TAL and figure out where things are, you have to sign an > agreement'. My interpretation was what Randy implied, and that ARIN wants an agreement with everyone who gets a (presumably unique to the agreement) TAL to protect ARIN. That would seem like a lot of overhead to maintain to me (since as I recall a TAL may never, ever (ok, very rarely) change), but then appropriate risk management has always been an interesting thing to watch in the (potentially litigious) ARIN region. Gary From dtaylor at vocalabs.com Wed Sep 5 14:50:34 2012 From: dtaylor at vocalabs.com (Daniel Taylor) Date: Wed, 05 Sep 2012 14:50:34 -0500 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <50476D8C.8010409@mtcc.com> References: <29088432.23124.1346774707888.JavaMail.root@benjamin.baylink.com> <50462DA3.1020700@vocalabs.com> <50466A2B.3020402@mtcc.com> <50474BE0.4030808@vocalabs.com> <50476D8C.8010409@mtcc.com> Message-ID: <5047AD0A.1060903@vocalabs.com> On 09/05/2012 10:19 AM, Michael Thomas wrote: > On 09/05/2012 05:56 AM, Daniel Taylor wrote: >> >> On 09/04/2012 03:52 PM, Michael Thomas wrote: >>> On 09/04/2012 09:34 AM, Daniel Taylor wrote: >>>> If you are sending direct SMTP on behalf of your domain from >>>> essentially random locations, how are we supposed to pick you out >>>> from spammers that do the same? >>>> >>> >>> Use DKIM. >> You say that like it's a lower bar than setting up a fixed SMTP >> server and using that. > > I say it like it addresses your concern. Well, if you've got proper forward and reverse DNS, and your portable SMTP server identifies itself properly, and you are using networks that don't filter outbound port 25, AND you have DKIM configured correctly and aren't using it for a situation for which it is inappropriate, then you'll get the same results with a portable SMTP server that you would sending through a properly configured static server. So, no, "use DKIM" does not address the delivery difficulties inherent to using a portable SMTP server. -- Daniel Taylor VP Operations Vocal Laboratories, Inc dtaylor at vocalabs.com 952-941-6580x203 From mike at mtcc.com Wed Sep 5 15:01:59 2012 From: mike at mtcc.com (Michael Thomas) Date: Wed, 05 Sep 2012 13:01:59 -0700 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <5047AD0A.1060903@vocalabs.com> References: <29088432.23124.1346774707888.JavaMail.root@benjamin.baylink.com> <50462DA3.1020700@vocalabs.com> <50466A2B.3020402@mtcc.com> <50474BE0.4030808@vocalabs.com> <50476D8C.8010409@mtcc.com> <5047AD0A.1060903@vocalabs.com> Message-ID: <5047AFB7.4060807@mtcc.com> On 09/05/2012 12:50 PM, Daniel Taylor wrote: > > On 09/05/2012 10:19 AM, Michael Thomas wrote: >> On 09/05/2012 05:56 AM, Daniel Taylor wrote: >>> >>> On 09/04/2012 03:52 PM, Michael Thomas wrote: >>>> On 09/04/2012 09:34 AM, Daniel Taylor wrote: >>>>> If you are sending direct SMTP on behalf of your domain from essentially random locations, how are we supposed to pick you out from spammers that do the same? >>>>> >>>> >>>> Use DKIM. >>> You say that like it's a lower bar than setting up a fixed SMTP server and using that. >> >> I say it like it addresses your concern. > > Well, if you've got proper forward and reverse DNS, and your portable SMTP server identifies itself properly, and you are using networks that don't filter outbound port 25, AND you have DKIM configured correctly and aren't using it for a situation for which it is inappropriate, then you'll get the same results with a portable SMTP server that you would sending through a properly configured static server. > > So, no, "use DKIM" does not address the delivery difficulties inherent to using a portable SMTP server. > My how the goalposts are moving. DKIM solves the problem of producing a stable identifier for a mail stream which is what your originally positioned goalposts was asking for. It also makes reverse dns lookups even more useless than they already are. Mike From dtaylor at vocalabs.com Wed Sep 5 15:09:38 2012 From: dtaylor at vocalabs.com (Daniel Taylor) Date: Wed, 05 Sep 2012 15:09:38 -0500 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <5047AFB7.4060807@mtcc.com> References: <29088432.23124.1346774707888.JavaMail.root@benjamin.baylink.com> <50462DA3.1020700@vocalabs.com> <50466A2B.3020402@mtcc.com> <50474BE0.4030808@vocalabs.com> <50476D8C.8010409@mtcc.com> <5047AD0A.1060903@vocalabs.com> <5047AFB7.4060807@mtcc.com> Message-ID: <5047B182.70006@vocalabs.com> On 09/05/2012 03:01 PM, Michael Thomas wrote: > On 09/05/2012 12:50 PM, Daniel Taylor wrote: >> >> On 09/05/2012 10:19 AM, Michael Thomas wrote: >>> On 09/05/2012 05:56 AM, Daniel Taylor wrote: >>>> >>>> On 09/04/2012 03:52 PM, Michael Thomas wrote: >>>>> On 09/04/2012 09:34 AM, Daniel Taylor wrote: >>>>>> If you are sending direct SMTP on behalf of your domain from >>>>>> essentially random locations, how are we supposed to pick you out >>>>>> from spammers that do the same? >>>>>> >>>>> >>>>> Use DKIM. >>>> You say that like it's a lower bar than setting up a fixed SMTP >>>> server and using that. >>> >>> I say it like it addresses your concern. >> >> Well, if you've got proper forward and reverse DNS, and your portable >> SMTP server identifies itself properly, and you are using networks >> that don't filter outbound port 25, AND you have DKIM configured >> correctly and aren't using it for a situation for which it is >> inappropriate, then you'll get the same results with a portable SMTP >> server that you would sending through a properly configured static >> server. >> >> So, no, "use DKIM" does not address the delivery difficulties >> inherent to using a portable SMTP server. >> > My how the goalposts are moving. DKIM solves the problem of producing > a stable identifier for a mail stream which is what your originally > positioned > goalposts was asking for. It also makes reverse dns lookups even more > useless than they already are. "Use your MX or SPF senders as your outbound mail agent, especially if they are properly configured with full DNS records so we can tell they are the correct machines to be sending on your behalf, or expect that you will get more mail bounced and lost than the average user because you are being unpredictable and unverifiable." That you so conveniently trimmed from the post that you replied to. Just putting the goalposts back where I left them. Proper DNS configuration is essential to reliable SMTP delivery. SPF and DKIM can help ensure you don't get mistakenly tagged as a spammer, but they are no substitute for proper technical configuration of your mail server, and you don't get proper configuration if you are using other people's networks. -- Daniel Taylor VP Operations Vocal Laboratories, Inc dtaylor at vocalabs.com 952-941-6580x203 From izaac at setec.org Wed Sep 5 16:12:07 2012 From: izaac at setec.org (Izaac) Date: Wed, 5 Sep 2012 17:12:07 -0400 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: References: <29088432.23124.1346774707888.JavaMail.root@benjamin.baylink.com> <50462DA3.1020700@vocalabs.com> <50466A2B.3020402@mtcc.com> <50474BE0.4030808@vocalabs.com> <504766A4.4040800@hup.org> <20120905T145402Z@localhost> Message-ID: <20120905T200555Z@localhost> On Wed, Sep 05, 2012 at 11:46:34AM -0400, Greg Ihnen wrote: > On Wed, Sep 5, 2012 at 11:11 AM, Izaac wrote: > > On Wed, Sep 05, 2012 at 07:50:12AM -0700, Henry Stryker wrote: > > > signature. They are adaptive, like cockroaches. > > > > This is why tcp port 25 filtering is totally effective and will remain so > > forever. Definitely worth breaking basic function principles of a > > global communications network over which trillions of dollars of commerce > > occur. > > But as someone pointed out further back on this thread people who want to > have their mail servers available to people who are on the other side of > port 25 filtering just use the alternate ports. So then what does filtering > port 25 accomplish? I suspect your ISP is also stripping tags. Let's try it out again: You can tell that tcp port 25 filtering is a highly effective spam mitigation technique because spam levels have declined in direct proportion to their level of deployment. Today, we barely see any spam on the internet due to amazing ability of these filters to prevent bad people from sending bulk email. Was that properly marked? Or this one? Since tcp25 filtering has been so successful, we should deploy filters for everything except tcp80 and tcp443 and maaaybe tcp21 -- but NAT already does so much to enhance the user experience there already. And what with ISP customers using their provided DNS and mail service exclusively, there's no reason to permit udp53, tcp110, tcp143, tcp993, tcp995 either. Really, only evil people use anything but the web. Any other traffic undoubtedly a bot from which they ought to be protected. -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__ From danny at tcb.net Wed Sep 5 16:23:55 2012 From: danny at tcb.net (Danny McPherson) Date: Wed, 5 Sep 2012 17:23:55 -0400 Subject: RPKI Pilot Participant Notice In-Reply-To: References: Message-ID: <8E6A533F-E562-4CDE-B02A-9575C208A5A1@tcb.net> On Sep 5, 2012, at 3:32 PM, Gary Buhrmaster wrote: > > My interpretation was what Randy implied, and that ARIN > wants an agreement with everyone who gets a (presumably > unique to the agreement) TAL to protect ARIN. That would > seem like a lot of overhead to maintain to me (since as I recall > a TAL may never, ever (ok, very rarely) change), but then > appropriate risk management has always been an interesting > thing to watch in the (potentially litigious) ARIN region. I'll let Randy speak for Randy (only he could do such a fine job). I do agree with Chris (and many others) that this whole thing falls apart pretty quickly without a single root (e.g., think of the browser CA problem) -- for many reasons. I'd wager what ARIN is going to do in said "Relying Party Agreement" is tell RPs (i.e., *relying* parties) that they ought not rely to much on the data for routing, and if they do and something gets hosed, ARIN's not at fault -- but I'll wait to read the actual agreement before speculating more. -danny From joe at oregon.uoregon.edu Wed Sep 5 16:15:07 2012 From: joe at oregon.uoregon.edu (Joe St Sauver) Date: Wed, 5 Sep 2012 14:15:07 -0700 (PDT) Subject: The End-To-End Internet (was Re: Blocking MX query) Message-ID: <12090514150728_530@oregon.uoregon.edu> Izaac commented: #I suspect your ISP is also stripping tags. Let's try it out #again: # # You can tell that tcp port 25 filtering is a highly effective spam # mitigation technique because spam levels have declined in direct # proportion to their level of deployment. Today, we barely see any # spam on the internet due to amazing ability of these filters to # prevent bad people from sending bulk email. # #Was that properly marked? Actually, not sure sarcasm tags are appropriate. 1) Port 25 blocks target direct-to-MX spam delivered by bots. 2) The Spamhaus CBL tracks the level of bot spam currently seen, including breaking out statistics by a number of factors. 3) Currently, the US, where port 25 filtering is routinely deployed by most large ISPs, is ranked 158th among countries when you consider botted users on a per capita basis: http://cbl.abuseat.org/countrypercapita.html 4) While that's not perfect (after all, there are still at least 133,811 listings for the US), on a PER-CAPITA basis, it's not bad -- that's just ~0.055% of US Internet users that are infected, relative to some countries where the rate of detected infection (based on spam emission) may be 4 to 5% or more. So yes, actually, port 25 blocks *DO* tend to be effective in reducing bot-delivered email spam. Does this mean that port 25 blocks are the ONLY measure that is required to control spam? No, absolutely not. But it does clearly help. Regards, Joe From izaac at setec.org Wed Sep 5 16:48:47 2012 From: izaac at setec.org (Izaac) Date: Wed, 5 Sep 2012 17:48:47 -0400 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: References: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> Message-ID: <20120905T213644Z@localhost> On Tue, Sep 04, 2012 at 03:45:32PM -0400, William Herrin wrote: > That's what firewalls *are for* Jay. They intentionally break > end-to-end for communications classified by the network owner as > undesirable. Whether a particular firewall employs NAT or not is > largely beside the point here. Either way, the firewall is *supposed* > to break some of the end to end communication paths. Which has had two basic results: First, we've raised at least two generations of programmers who cannot write a network-facing service able to stand up in so much as a stiff breeze. "Well it's behind the firewall, so no one will be able to see it." Second, we've killed -- utterly and completely -- countless promising technologies and forced the rest to somehow figure out either how to pretend to be HTTP or tunnel themselves. That's just sad. But even then, we're not talking about an end user choosing not to permit certain kinds of inbound connectivity. We're talking about carriers inspecting and selectively interfering with (and in some cases outright manipulating) communication in transit. That's just plain wrong. -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__ From randy at psg.com Wed Sep 5 17:10:33 2012 From: randy at psg.com (Randy Bush) Date: Thu, 06 Sep 2012 05:10:33 +0700 Subject: RPKI Pilot Participant Notice In-Reply-To: References: Message-ID: >> [ hint: how does an isp in phnom penh validate my route? ] > Your question is a bit cryptic. moi? :) > Could you be more specific about your concern? essentially, as the rirs have resisted iana being the root ta, the arin tal is necessary for anyone to validate anything which dependa on the arin data. effectively you are requiring every router operator in the world to sign your document. does not work. randy From james.cutler at consultant.com Wed Sep 5 17:21:09 2012 From: james.cutler at consultant.com (Cutler James R) Date: Wed, 5 Sep 2012 18:21:09 -0400 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <20120905T200555Z@localhost> References: <29088432.23124.1346774707888.JavaMail.root@benjamin.baylink.com> <50462DA3.1020700@vocalabs.com> <50466A2B.3020402@mtcc.com> <50474BE0.4030808@vocalabs.com> <504766A4.4040800@hup.org> <20120905T145402Z@localhost> <20120905T200555Z@localhost> Message-ID: On Sep 5, 2012, at 5:12 PM, Izaac wrote: > > Since tcp25 filtering has been so successful, we should deploy > filters for everything except tcp80 and tcp443 and maaaybe tcp21 -- > but NAT already does so much to enhance the user experience there > already. And what with ISP customers using their provided DNS and > mail service exclusively, there's no reason to permit udp53, tcp110, > tcp143, tcp993, tcp995 either. Really, only evil people use anything > but the web. Any other traffic undoubtedly a bot from which they > ought to be protected. Izaac, You do realize that that the NANOG mailing is archived and some helpful person will quote you to their favorite legislator? James R. Cutler james.cutler at consultant.com From kris at amy.id.au Wed Sep 5 17:54:27 2012 From: kris at amy.id.au (Kris Amy) Date: Thu, 6 Sep 2012 08:54:27 +1000 Subject: Akamai Peering Tech Message-ID: Hi All, If there is an Akamai peering tech around could they contact me off-list regarding a BGP session which has been bouncing for a while. Cheers, Kris From bill at herrin.us Wed Sep 5 17:56:36 2012 From: bill at herrin.us (William Herrin) Date: Wed, 5 Sep 2012 18:56:36 -0400 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <20120905T200555Z@localhost> References: <29088432.23124.1346774707888.JavaMail.root@benjamin.baylink.com> <50462DA3.1020700@vocalabs.com> <50466A2B.3020402@mtcc.com> <50474BE0.4030808@vocalabs.com> <504766A4.4040800@hup.org> <20120905T145402Z@localhost> <20120905T200555Z@localhost> Message-ID: On Wed, Sep 5, 2012 at 5:12 PM, Izaac wrote: > I suspect your ISP is also stripping tags. Let's try it out > again: > > You can tell that tcp port 25 filtering is a highly effective spam > mitigation technique because spam levels have declined in direct > proportion to their level of deployment. Today, we barely see any > spam on the internet due to amazing ability of these filters to > prevent bad people from sending bulk email. Thing is, spam levels *are* down a good 20% in the last couple years, that being about the time ISPs began doing this. More, 20% *is* in rough proportion the impacted customer counts on the handful of cable and DSL providers that implemented it. And if you remind me that correlation is not causation I'll have to point out the same flaw in your more sarcastic version. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From johnl at iecc.com Wed Sep 5 18:05:04 2012 From: johnl at iecc.com (John Levine) Date: 5 Sep 2012 23:05:04 -0000 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <5047A2EA.8010307@hup.org> Message-ID: <20120905230504.23900.qmail@joyce.lan> In article <5047A2EA.8010307 at hup.org> you write: >On 09/05/12 09:13 , Michael Thomas wrote: >> The "I" part of DKIM is "Identified". That's all it promises. It's a >> feature, not a bug, that spammers use it. > >Which is why DKIM does not really address any concerns. The spammers >have reduced its value. Nothing personal, but nobody who had the most rudimentary understanding of what DKIM does and how it's intended to be used would make such a statement. See the archives of the IETF DKIM list for much, much, much more detail. R's, John From johnl at iecc.com Wed Sep 5 18:07:07 2012 From: johnl at iecc.com (John Levine) Date: 5 Sep 2012 23:07:07 -0000 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <5047AD0A.1060903@vocalabs.com> Message-ID: <20120905230707.24414.qmail@joyce.lan> >Well, if you've got proper forward and reverse DNS, and your portable >SMTP server identifies itself properly, and you are using networks that >don't filter outbound port 25, AND you have DKIM configured correctly >and aren't using it for a situation for which it is inappropriate, then >you'll get the same results with a portable SMTP server that you would >sending through a properly configured static server. Not really. Large mail system like Gmail and Yahoo have a pretty good map of the IPv4 address space. If you're sending from a residential DSL or cable modem range, they'll likely reject any mail you send directly no matter what you do. R's, John From valdis.kletnieks at vt.edu Wed Sep 5 18:42:24 2012 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 05 Sep 2012 19:42:24 -0400 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: Your message of "05 Sep 2012 23:07:07 -0000." <20120905230707.24414.qmail@joyce.lan> References: <20120905230707.24414.qmail@joyce.lan> Message-ID: <29414.1346888544@turing-police.cc.vt.edu> On 05 Sep 2012 23:07:07 -0000, "John Levine" said: > Not really. Large mail system like Gmail and Yahoo have a pretty good > map of the IPv4 address space. If you're sending from a residential > DSL or cable modem range, they'll likely reject any mail you send > directly no matter what you do. Which is why I finally gave up and speak to an 800 pound gorilla on port 587, because nobody dares to mess with that gorilla's port 587 so my laptop can always get mail sent. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From mysidia at gmail.com Wed Sep 5 19:28:33 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 5 Sep 2012 19:28:33 -0500 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> References: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> Message-ID: On 9/4/12, Jay Ashworth wrote: > It is regularly alleged, on this mailing list, that NAT is bad *because it > violates the end-to-end principle of the Internet*, where each host is a > full-fledged host, able to connect to any other host to perform > transactions. Both true. and NAT inherently breaks the end-to-end principal for all the applications. Blocking port 25 traffic, also breaks the possibility of end-to-end communications on that one port. But not for the SMTP protocol. SMTP End-to-End is preserved, as long as the SMTP relay provided does not introduce further restrictions. > We see it now alleged that the opposite is true: that a laptop, say, like > mine, which runs Linux and postfix, and does not require a smarthost to > deliver mail to a remote server *is a bad actor* *precisely because it does > that* (in attempting to send mail directly to a domain's MX server) *from > behind a NAT router*, and possibly different ones at different times. Ding ding ding... behind a NAT router. The End-to-End principal is already broken. The 1:many NAT router prevents your host from being specifically identified, in order to efficiently and adequately identify, report, and curtail abuse; You can't "break" the end-to-end principal in cases where it has already been broken. And selectively breaking end-to-end in limited circumstances is OK. You choose to break it when the damage can be mitigated and the concerns that demand breaking it are strong enough. The end-to-end principal as you suggest primarily pertains to the Internet protocol; IP and TCP. I believe you are trying to apply the principal in an inappropriate way for the layer you are applying it to. At the SMTP application layer end-to-end internet connectivity means you can send e-mail to any e-mail address and receive e-mail from any e-mail address. For HTTP; that would mean you can retrieve a page from any host, and any remote HTTP client, can retrieve an page from your hosts; that doesn't necessarily imply that the transaction will be allowed, but if it is refused -- it is for an administrative reason, not due to a design flaw. NAT would fall under design flaw, because it breaks end-to-end connectivity, such that there is no longer an administrative choice that can be made to restore it (other than redesign with NAT removed). At the transport layer, end-to-end means you can establish connections on various ports to any peer on the internet, and any peer can connect to all ports on which you allow. It doesn't necessarily mean that all ports are allowed; a remote host, or a firewall under their control, deciding to block your connection is not a violation of end-to-end. At the internet layer, end-to-end means you can send any datagram to any host on the internet it will be delivered to that host; and any host can send a datagram to you. It doesn't mean that none of your packets will be discarded on the way, because some specific application or port has been banned. At the link layer, there is no end-to-end connectivity; it is at IP that the notion first arises. > I find these conflicting reports very conflicting. Either the end-to-end > principle *is* the Prime Directive... or it is *not*. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover > DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > -- -JH From sean at seanharlow.info Wed Sep 5 19:37:46 2012 From: sean at seanharlow.info (Sean Harlow) Date: Wed, 5 Sep 2012 20:37:46 -0400 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <20120905230707.24414.qmail@joyce.lan> References: <20120905230707.24414.qmail@joyce.lan> Message-ID: <12A6865F-DF59-41B2-99C2-6AAC377B18D1@seanharlow.info> On Sep 5, 2012, at 19:07, John Levine wrote: > Not really. Large mail system like Gmail and Yahoo have a pretty good > map of the IPv4 address space. If you're sending from a residential > DSL or cable modem range, they'll likely reject any mail you send > directly no matter what you do. While I've clearly been on the side of "don't expect this to work", "why do you have your laptop set up like that?", and defending the default-blocking behavior on outbound, this is not true at least for Gmail. I have a test Asterisk box which I've been really lazy about setting up properly that successfully sends status messages from my home cable modem to my Gmail-hosted personal domain every day, even getting through with a completely bogus source address. It's never even been flagged as possible spam. Maybe Gmail does more detailed analysis of some kind and sees that I'm also checking my email from the same IP that's sending these messages, I don't know, but they are not just blocking anything coming in from a random cable IP. I'll bet it raises the "spam likelihood" or whatever as it probably should, but it's not a total block. --- Sean Harlow sean at seanharlow.info From mysidia at gmail.com Wed Sep 5 21:43:11 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 5 Sep 2012 21:43:11 -0500 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <12A6865F-DF59-41B2-99C2-6AAC377B18D1@seanharlow.info> References: <20120905230707.24414.qmail@joyce.lan> <12A6865F-DF59-41B2-99C2-6AAC377B18D1@seanharlow.info> Message-ID: On 9/5/12, Sean Harlow wrote: > While I've clearly been on the side of "don't expect this to work", "why do > you have your laptop set up like that?", and defending the default-blocking > behavior on outbound, this is not true at least for Gmail. I have a test > Asterisk box which I've been really lazy about setting up properly that I would still file it under... yes, there will probably be many mail hosts you can contact that way. It will be understandable if many block it, but they don't have to. If they give you a smart host, then you should use that. End-to-End doesn't imply control of the routing in-between smtp origin and destination. It will also be understandable if the ISP blocks outbound port 25, but they don't have to. Personally I would rather they not -- blocking port 25 doesn't make the underlying problem go away; it's just a way of "hiding the problem", so the ISP isn't pestered about it. By blocking port 25; the ISP doesn't receive a spam complaint for blocked non-legit activity, so they have fewer network abuse reports to deal with. Fewer users to turn off = fewer angered users switching to other providers (Even if turning off the user in response to spam will help the user, by alerting them to their compromised computer). End user Having to use a smart relay host increases latency and introduces a point of failure (ISP mail relay can fail or perform unacceptably even when the network has no issues). If you have the intelligence on your laptop to properly contact MX hosts; the restriction can be a hinderance, and it is difficult to justify. The ISP could block port 25 on report of abuse; but I suppose... incident handlers' time reading abuse reports = $$$ Once the large ISPs do the math, it is understandable if their ISP organizations' management eventually opts to block port 25. For the ones who didn't choose to do that; presumably sufficient users complained or they feared the competition would be strengthened or charged with their unpopular choice. My idealistic preference would be the ISP allows outbound port 25, but are highly responsive to abuse complaints; that way, the problem will be corrected, instead of festering, until some day the laptop gets plugged into some network that happens to allow the port. Or spreads the infection, because of the port 25 block, the problem goes undetected and contributes to making the overall worse. Just because a compromised host can't connect on port 25; doesn't mean it is not a significant contribution to the problem. Spreading infection via other vectors; spamming via other vectors such as IM, Forum posts, HTTP contact/feedback forms... There are plenty of abusive non port-25 activities that ultimately facilitate spamming. -- -JH From mohta at necom830.hpcl.titech.ac.jp Wed Sep 5 23:08:29 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 06 Sep 2012 13:08:29 +0900 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: References: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> Message-ID: <504821BD.7010009@necom830.hpcl.titech.ac.jp> Jimmy Hess wrote: > NAT would fall under design flaw, because it breaks end-to-end > connectivity, such that there is no longer an administrative choice > that can be made to restore it (other than redesign with NAT > removed). The end to end transparency can be restored easily, if an administrator wishes so, with UPnP capable NAT and modified host transport layer. That is, the administrator assigns a set of port numbers to a host behind NAT and sets up port mapping. (global IP, global port) <-> (local IP, global port) then, if transport layer of the host is modified to perform reverse translation (information for the translation can be obtained through UPnP): (local IP, global port) <-> (global IP, global port) Now, NAT is transparent to application layer. The remaining restrictions are that only TCP and UDP are supported by UPnP (see draft-ohta-e2e-nat-00.txt for a specialized NAT box to allow more general transport layers) and that a set of port numbers available to the application layer is limited (you may not be able to run a SMTP server at port 25). The point of the end to end transparency is: The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. quoted from "End-To-End Arguments in System Design", the original paper on the end to end argument written by Saltzer et. al. Thus, The NAT function can completely and correctly be implemented with the knowledge and help of the host protocol stack. Masataka Ohta From valdis.kletnieks at vt.edu Wed Sep 5 23:15:14 2012 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 06 Sep 2012 00:15:14 -0400 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: Your message of "Thu, 06 Sep 2012 13:08:29 +0900." <504821BD.7010009@necom830.hpcl.titech.ac.jp> References: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> <504821BD.7010009@necom830.hpcl.titech.ac.jp> Message-ID: <41870.1346904914@turing-police.cc.vt.edu> On Thu, 06 Sep 2012 13:08:29 +0900, Masataka Ohta said: > The end to end transparency can be restored easily, if an > administrator wishes so, with UPnP capable NAT and modified > host transport layer. How does the *second* host behind the NAT that wants to use global port 7719 do it? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From mohta at necom830.hpcl.titech.ac.jp Wed Sep 5 23:41:26 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 06 Sep 2012 13:41:26 +0900 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <41870.1346904914@turing-police.cc.vt.edu> References: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> <504821BD.7010009@necom830.hpcl.titech.ac.jp> <41870.1346904914@turing-police.cc.vt.edu> Message-ID: <50482976.6030205@necom830.hpcl.titech.ac.jp> (2012/09/06 13:15), valdis.kletnieks at vt.edu wrote: > On Thu, 06 Sep 2012 13:08:29 +0900, Masataka Ohta said: > >> The end to end transparency can be restored easily, if an >> administrator wishes so, with UPnP capable NAT and modified >> host transport layer. > > How does the *second* host behind the NAT that wants to use > global port 7719 do it? In the previous mails, I wrote: > The remaining restrictions are that ... > and that a set of port > numbers available to the application layer is limited (you may > not be able to run a SMTP server at port 25). and Jimmy wrote: > At the transport layer, end-to-end means you can establish connections > on various ports to any peer on the internet, and any peer can connect > to all ports on which you allow. It doesn't necessarily mean that > all ports are allowed; a remote host, or a firewall under their > control, deciding to block your connection is not a violation of > end-to-end. Masataka Ohta From owen at delong.com Wed Sep 5 23:39:44 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 5 Sep 2012 21:39:44 -0700 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <504821BD.7010009@necom830.hpcl.titech.ac.jp> References: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> <504821BD.7010009@necom830.hpcl.titech.ac.jp> Message-ID: <5AFF3D96-3204-433D-8A01-A680C455B489@delong.com> On Sep 5, 2012, at 21:08 , Masataka Ohta wrote: > Jimmy Hess wrote: > >> NAT would fall under design flaw, because it breaks end-to-end >> connectivity, such that there is no longer an administrative choice >> that can be made to restore it (other than redesign with NAT >> removed). > > The end to end transparency can be restored easily, if an > administrator wishes so, with UPnP capable NAT and modified > host transport layer. > This is every bit as much BS as it was the first 6 times you pushed it. > That is, the administrator assigns a set of port numbers to a > host behind NAT and sets up port mapping. > > (global IP, global port) <-> (local IP, global port) > > then, if transport layer of the host is modified to perform > reverse translation (information for the translation can be > obtained through UPnP): > > (local IP, global port) <-> (global IP, global port) > > Now, NAT is transparent to application layer. > Never mind the fact that all the hosts trying to reach you have no way to know what port to use. http://www.foo.com fed into a browser has no way for the browser to determine that it needs to contact 192.0.200.50 on port 8099 instead of port 80. > The remaining restrictions are that only TCP and UDP are supported > by UPnP (see draft-ohta-e2e-nat-00.txt for a specialized NAT box > to allow more general transport layers) and that a set of port > numbers available to the application layer is limited (you may > not be able to run a SMTP server at port 25). > You're demanding an awful lot of changes to the entire internet to partially restore IPv4 transparency when the better solution is to deploy IPv6 and have real full transparency. > The point of the end to end transparency is: > > The function in question can completely and correctly be > implemented only with the knowledge and help of the application > standing at the end points of the communication system. > That is one purpose. A more accurate definition of the greater purpose of end-to-end transparency would be: An application can expect the datagram to arrive at the remote destination without any modifications not specified in the basic protocol requirements (e.g. TTL decrements, mac layer header rewrites, reformatting for different lower-layer media, etc.) An application should be able to expect the layer 3 and above addressing elements to be unaltered and to be able to provide "contact me on" style messages in the payload based on its own local knowledge of its addressing. > quoted from "End-To-End Arguments in System Design", the original > paper on the end to end argument written by Saltzer et. al. > > Thus, > > The NAT function can completely and correctly be > implemented with the knowledge and help of the host > protocol stack. > > Masataka Ohta > It could be argued, if one considers "contact me on" style messages to be valid, that the function cannot be completely and correctly implemented in the presence of NAT. Moreover, since NAT provides no benefit other than address compression and the kind of additional effort on NAT of which you speak would be a larger development effort than IPv6 at this point, why bother? Owen From cb.list6 at gmail.com Wed Sep 5 23:45:19 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Wed, 5 Sep 2012 21:45:19 -0700 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <5AFF3D96-3204-433D-8A01-A680C455B489@delong.com> References: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> <504821BD.7010009@necom830.hpcl.titech.ac.jp> <5AFF3D96-3204-433D-8A01-A680C455B489@delong.com> Message-ID: On Wed, Sep 5, 2012 at 9:39 PM, Owen DeLong wrote: > > On Sep 5, 2012, at 21:08 , Masataka Ohta wrote: > >> Jimmy Hess wrote: >> >>> NAT would fall under design flaw, because it breaks end-to-end >>> connectivity, such that there is no longer an administrative choice >>> that can be made to restore it (other than redesign with NAT >>> removed). >> >> The end to end transparency can be restored easily, if an >> administrator wishes so, with UPnP capable NAT and modified >> host transport layer. >> > > This is every bit as much BS as it was the first 6 times you pushed it. > Yep. From mohta at necom830.hpcl.titech.ac.jp Thu Sep 6 00:01:50 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 06 Sep 2012 14:01:50 +0900 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <5AFF3D96-3204-433D-8A01-A680C455B489@delong.com> References: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> <504821BD.7010009@necom830.hpcl.titech.ac.jp> <5AFF3D96-3204-433D-8A01-A680C455B489@delong.com> Message-ID: <50482E3E.7020309@necom830.hpcl.titech.ac.jp> Owen DeLong wrote: >> then, if transport layer of the host is modified to perform >> reverse translation (information for the translation can be >> obtained through UPnP): >> >> (local IP, global port) <-> (global IP, global port) >> >> Now, NAT is transparent to application layer. > Never mind the fact that all the hosts trying to reach you have no > way to know what port to use. Quote from A server port number different from well known ones may be specified through mechanisms to specify an address of the server, which is the case of URLs. > http://www.foo.com fed into a browser has no way for the browser > to determine that it needs to contact 192.0.200.50 on port 8099 > instead of port 80. See RFC6281 and draft-ohta-urlsrv-00.txt. But, http://www.foo.com:8099 works just fine. >> The remaining restrictions are that only TCP and UDP are supported >> by UPnP (see draft-ohta-e2e-nat-00.txt for a specialized NAT box >> to allow more general transport layers) and that a set of port >> numbers available to the application layer is limited (you may >> not be able to run a SMTP server at port 25). > You're demanding an awful lot of changes to the entire internet to All that necessary is local changes on end systems of those who want the end to end transparency. There is no changes on the Internet. > This is every bit as much BS as it was the first 6 times you pushed it. As you love BS so much, you should better read your own mails. Masataka Ohta From mansaxel at besserwisser.org Thu Sep 6 01:19:07 2012 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Thu, 6 Sep 2012 08:19:07 +0200 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: References: <29088432.23124.1346774707888.JavaMail.root@benjamin.baylink.com> <50462DA3.1020700@vocalabs.com> <50466A2B.3020402@mtcc.com> <50474BE0.4030808@vocalabs.com> <504766A4.4040800@hup.org> <20120905T145402Z@localhost> <20120905T200555Z@localhost> Message-ID: <20120906061907.GL19582@besserwisser.org> Subject: Re: The End-To-End Internet (was Re: Blocking MX query) Date: Wed, Sep 05, 2012 at 06:56:36PM -0400 Quoting William Herrin (bill at herrin.us): > Thing is, spam levels *are* down a good 20% in the last couple years, > that being about the time ISPs began doing this. More, 20% *is* in > rough proportion the impacted customer counts on the handful of cable > and DSL providers that implemented it. Not here. My experience is that it is at best static, but most likely increasing. Around here, the sad default is that it is impossible to buy tcp/25 access except in colos and over tunnels. It does not help. It just is a very bad precedent, it looks like you are doing something. Which for lawyers is just as fine as efficient action. We need to remind ourselves that this Internet thing got big simply because it let people have computers send packets directly to other peoples computers. There was this guy called Aesop who wrote a story about blocking traffic on the Internet, but since the Internet wasn't known at the time (too secret) he had to rephrase it so it became a story about a goose that lays golden eggs. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I HAVE to buy a new "DODGE MISER" and two dozen JORDACHE JEANS because my viewscreen is "USER-FRIENDLY"!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From johnl at iecc.com Thu Sep 6 03:12:29 2012 From: johnl at iecc.com (John Levine) Date: 6 Sep 2012 08:12:29 -0000 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: Message-ID: <20120906081229.8919.qmail@joyce.lan> >My idealistic preference would be the ISP allows outbound port 25, >but are highly responsive to abuse complaints; My idealistic preference is that ISPs not let their botted customers fill everyone's inbox with garbage. Why do you think that blocking port 25 precludes logging what they block, and dealing with customers whose traffic shows that they're botted? R's, John From randy at psg.com Thu Sep 6 03:56:54 2012 From: randy at psg.com (Randy Bush) Date: Thu, 06 Sep 2012 15:56:54 +0700 Subject: RPKI Pilot Participant Notice In-Reply-To: <8E6A533F-E562-4CDE-B02A-9575C208A5A1@tcb.net> References: <8E6A533F-E562-4CDE-B02A-9575C208A5A1@tcb.net> Message-ID: > I'd wager what ARIN is going to do in said "Relying Party Agreement" > is tell RPs (i.e., *relying* parties) that they ought not rely to much > on the data for routing, and if they do and something gets hosed, > ARIN's not at fault -- but I'll wait to read the actual agreement > before speculating more. that too is my *speculation*. which would be interesting, as accurate primary data is arin's primary responsibility. but anyone who has looked at any of the rirs' data seriously needed a strong stomach. randy From jcurran at arin.net Thu Sep 6 04:37:36 2012 From: jcurran at arin.net (John Curran) Date: Thu, 6 Sep 2012 09:37:36 +0000 Subject: RPKI Pilot Participant Notice In-Reply-To: References: Message-ID: On Sep 5, 2012, at 8:24 PM, Christopher Morrow wrote: > > " In order to access the > production RPKI TAL, you will first have to agree to ARIN's Relying > Party Agreement before the TAL will be emailed to you. To request the > TAL after the production release, follow this link: > http://www.arin.net/public/rpki/tal/index.xhtml" If a relying party's use of PKI infrastructure legally equated to acceptance of the relying party agreement (RPA), then having an explicit record of acceptance of the RPA would not be necessary. Alas, it does not appear possible to equate use of PKI certificates with agreement to the associated RPA (and some might argue that this is a feature, as some folks would not want to be legally bound to an agreement which they did not explicitly review and accept.) FYI, /John From olipro at 8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa Thu Sep 6 06:37:40 2012 From: olipro at 8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa (Oliver) Date: Thu, 06 Sep 2012 13:37:40 +0200 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <50482E3E.7020309@necom830.hpcl.titech.ac.jp> References: <5AFF3D96-3204-433D-8A01-A680C455B489@delong.com> <50482E3E.7020309@necom830.hpcl.titech.ac.jp> Message-ID: <1398646.nogpiQX5tj@gentoovm> On Thursday 06 September 2012 14:01:50 Masataka Ohta wrote: > All that necessary is local changes on end systems of those who > want the end to end transparency. > > There is no changes on the Internet. You're basically redefining the term "end-to-end transparency" to suit your own agenda. Globally implementing what is basically an application layer protocol in order to facilitate the functioning of an upper layer protocol (i.e. IPv4) is patent nonsense. The purpose of each layer is to facilitate the one it encapsulates, not the other way around. What you advocate is not end-to-end transparency but point-to-point opacity hinging on a morass of hacks that constitute little more than an abuse of existing technologies in an attempt to fulfil an unscalable goal. Fortunately, it is exactly that fact which makes all of your drafts and belligerent evangelising utterly pointless; you can continue to make noise and attempt to argue by redefinition all you like, the world will continue to forge ahead with the deployment of IPv6 and the *actual* meaning of the end-to-end principle will remain as it is. Regards, Oliver From bill at herrin.us Thu Sep 6 08:38:49 2012 From: bill at herrin.us (William Herrin) Date: Thu, 6 Sep 2012 09:38:49 -0400 Subject: RPKI Pilot Participant Notice In-Reply-To: References: Message-ID: On Thu, Sep 6, 2012 at 5:37 AM, John Curran wrote: > If a relying party's use of PKI infrastructure legally equated to > acceptance of the relying party agreement (RPA), then having an > explicit record of acceptance of the RPA would not be necessary. > > Alas, it does not appear possible to equate use of PKI certificates > with agreement to the associated RPA (and some might argue that this > is a feature, as some folks would not want to be legally bound to an > agreement which they did not explicitly review and accept.) John, Randy: I'm confused. Are you saying that unlike a whois lookup, I'll need a contract with ARIN to look up and validate someone else's RPKI certificate? Would you clarify which parts of RPKI I need a contract with ARIN to do and which parts I do not? Thanks, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From up at 3.am Thu Sep 6 09:55:37 2012 From: up at 3.am (up at 3.am) Date: Thu, 6 Sep 2012 10:55:37 -0400 Subject: dot1q encapsulation overhead? Message-ID: <894e6a248adafa3e3f4d6113002eabd2.squirrel@ssl.pil.net> A while back we had a customer colocated vpn router (2911) come in and we put it on our main vlan for initial set up and testing. Once that was done, I created a separate VLAN for them and a dot1q subinterface on an older, somewhat overloaded 2811. I set up the IPSec Tunnel, a /30 for each end to have an IP and all the static routes needed to make this work and it did. However, a few days later they were complaining of slow speeds...I don't recall, but maybe something like 5mbs when they needed 20 or so. We had no policing on that port. After a lot of testing, we tried putting them back on the main, native vlan and it worked fine...they got the throughput they needed. So my question is: could the dot1q encapsulation be causing throughput issues on a 2811 that's already doing a lot? I regret that I don't recall what "sh proc cpu" output was, or if I even ran it at all. It was kind of hectic just to get it fixed at the time. Well, a few months later (last week), the chicken came home to roost when their IPSec tunnel started proxy ARP puking stuff to our side that temporarily took out parts of our internal LAN. I have requested a 2911 replacement for the 2811 because I have seen the 2811 cpu load max out a few times when passing lots of traffic. I am hoping it will allow us to go back to this VLAN setup again, but I've never heard whether dot1q adds any overhead. From asullivan at dyn.com Thu Sep 6 10:14:58 2012 From: asullivan at dyn.com (Andrew Sullivan) Date: Thu, 6 Sep 2012 11:14:58 -0400 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <5AFF3D96-3204-433D-8A01-A680C455B489@delong.com> References: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> <504821BD.7010009@necom830.hpcl.titech.ac.jp> <5AFF3D96-3204-433D-8A01-A680C455B489@delong.com> Message-ID: <20120906151458.GC7079@dyn.com> On Wed, Sep 05, 2012 at 09:39:44PM -0700, Owen DeLong wrote: > > Never mind the fact that all the hosts trying to reach you have no > way to know what port to use. Despite my scepticism of the overall project, I find the above claim a little hard to accept. RFC 2052, which defined SRV in an experiment, came out in 1996. SRV was moved to the standards track in 2000. I've never heard an argument why it won't work, and we know that SRV records are sometimes in use. Why couldn't that mechanism be used more widely? Best, A -- Andrew Sullivan Dyn Labs asullivan at dyn.com From jof at thejof.com Thu Sep 6 11:11:15 2012 From: jof at thejof.com (Jonathan Lassoff) Date: Thu, 6 Sep 2012 09:11:15 -0700 Subject: dot1q encapsulation overhead? In-Reply-To: <894e6a248adafa3e3f4d6113002eabd2.squirrel@ssl.pil.net> References: <894e6a248adafa3e3f4d6113002eabd2.squirrel@ssl.pil.net> Message-ID: On Thu, Sep 6, 2012 at 7:55 AM, wrote: > A while back we had a customer colocated vpn router (2911) come in and we put it > on our main vlan for initial set up and testing. Once that was done, I created a > separate VLAN for them and a dot1q subinterface on an older, somewhat overloaded > 2811. I set up the IPSec Tunnel, a /30 for each end to have an IP and all the > static routes needed to make this work and it did. > > However, a few days later they were complaining of slow speeds...I don't recall, > but maybe something like 5mbs when they needed 20 or so. We had no policing on > that port. After a lot of testing, we tried putting them back on the main, native > vlan and it worked fine...they got the throughput they needed. > > So my question is: could the dot1q encapsulation be causing throughput issues on a > 2811 that's already doing a lot? I regret that I don't recall what "sh proc cpu" > output was, or if I even ran it at all. It was kind of hectic just to get it > fixed at the time. > > Well, a few months later (last week), the chicken came home to roost when their > IPSec tunnel started proxy ARP puking stuff to our side that temporarily took out > parts of our internal LAN. I have requested a 2911 replacement for the 2811 > because I have seen the 2811 cpu load max out a few times when passing lots of > traffic. I am hoping it will allow us to go back to this VLAN setup again, but > I've never heard whether dot1q adds any overhead. It's small, but plain 802.1Q adds in a 4-byte (32-bit) header after the normal Ethernet header and before the "actual" Ethernet payload. That tag has to go somewhere. :p Also, I'm not privy to the details of your "IPSec Tunnel", but that can introduce additional overhead as well. I'm not sure about your specific 2811/2911 and IOS combination (to know if this feature is there or not), but you might also consider setting "ip tcp adjust-mss" and "ip mtu" values on your tunnel interfaces to signal the true maximum-transportable-size of the various traffic types over the tunnel. I've also been bit by this bug before (http://networknerd.wordpress.com/2010/06/11/cisco-ipsec-mtu-bug/) that affects the MTU calculations of tunnels, for which the source address is specified by an interface, after a reboot. Worth knowing about. Cheers, jof From will at loopfree.net Thu Sep 6 11:38:12 2012 From: will at loopfree.net (Will Orton) Date: Thu, 6 Sep 2012 09:38:12 -0700 Subject: Are people still building SONET networks from scratch? Message-ID: <20120906163812.GA9934@loopfree.net> We've run into an issue with a customer that has been confounding us for a few months as we try to design what they need. The customer has a location in the relative middle of nowhere that they are trying to build a protected OC3 to. Ultimately, their traffic on it will be packet data (IP/ethernet, not channelized/voice). But they seem to be absolutely 100% set on the idea that they build with Cisco ONS boxes and that they run and control the D1-D12 bytes in order to manage protection switching on the OC3 (and have their DCC channel for management). Since this is the middle of nowhere, we are having to piece it together from a few runs of dark fiber here and there and lit services from about 3 other providers to get from the desired point A to the desired point B. The issues we seem to be hitting are: -We seem to be unable to find anyone who sells lit OC3 with D1-D12 transparency for the client. Sometimes we can get D1-D3, but that's it. -lit OC3/12/48 is ridiculously expensive comapred to 1g ethernet waves or 10g waves (choice LAN/WAN ethernet or OC192) 10g waves are cheap enough that we have entertained the idea of buying them and putting OC-192/muxponders on the ends to provide the OC-3, but even then I'm having trouble finding boxes that will do D1-D12 transparency for client OC-3. Building the whole thing on dark fiber so that we could specify the exact equipment on every hop isn't going to happen, as the "protect" path is about 1000 miles and the geography is such that we don't really have a market for all the other wasted capacity there would be on that path. Having much more experience with ethernet/packet/MPLS setups, we are trying to get the client to admit that 1g/10g waves running ethernet with QoS would be as good as or better in terms of latency, jitter, and loss for their packet data. So far they will barely listen to the arguments. And then going the next leap and showing them that we could work towards <50ms protection switching with MPLS/BFD/etc packet-based protocols is another stretch. Am I missing something here that my customer isn't, or is it the other way around? -Will From james at freedomnet.co.nz Thu Sep 6 11:47:52 2012 From: james at freedomnet.co.nz (james jones) Date: Thu, 6 Sep 2012 12:47:52 -0400 Subject: Are people still building SONET networks from scratch? In-Reply-To: <20120906163812.GA9934@loopfree.net> References: <20120906163812.GA9934@loopfree.net> Message-ID: On the surface this makes me want to cry. I could be missing something as well. On Thu, Sep 6, 2012 at 12:38 PM, Will Orton wrote: > We've run into an issue with a customer that has been confounding us for a > few > months as we try to design what they need. > > The customer has a location in the relative middle of nowhere that they are > trying to build a protected OC3 to. Ultimately, their traffic on it will be > packet data (IP/ethernet, not channelized/voice). But they seem to be > absolutely 100% set on the idea that they build with Cisco ONS boxes and > that > they run and control the D1-D12 bytes in order to manage protection > switching > on the OC3 (and have their DCC channel for management). > > Since this is the middle of nowhere, we are having to piece it together > from a > few runs of dark fiber here and there and lit services from about 3 other > providers to get from the desired point A to the desired point B. The > issues > we seem to be hitting are: > > -We seem to be unable to find anyone who sells lit OC3 with D1-D12 > transparency for the client. Sometimes we can get D1-D3, but that's it. > > -lit OC3/12/48 is ridiculously expensive comapred to 1g ethernet waves or > 10g > waves (choice LAN/WAN ethernet or OC192) > > 10g waves are cheap enough that we have entertained the idea of buying > them and > putting OC-192/muxponders on the ends to provide the OC-3, but even then > I'm > having trouble finding boxes that will do D1-D12 transparency for client > OC-3. > Building the whole thing on dark fiber so that we could specify the exact > equipment on every hop isn't going to happen, as the "protect" path is > about > 1000 miles and the geography is such that we don't really have a market > for all > the other wasted capacity there would be on that path. > > Having much more experience with ethernet/packet/MPLS setups, we are > trying to > get the client to admit that 1g/10g waves running ethernet with QoS would > be as > good as or better in terms of latency, jitter, and loss for their packet > data. > So far they will barely listen to the arguments. And then going the next > leap > and showing them that we could work towards <50ms protection switching with > MPLS/BFD/etc packet-based protocols is another stretch. > > > Am I missing something here that my customer isn't, or is it the other way > around? > > -Will > > From nick at foobar.org Thu Sep 6 12:00:37 2012 From: nick at foobar.org (Nick Hilliard) Date: Thu, 06 Sep 2012 18:00:37 +0100 Subject: Are people still building SONET networks from scratch? In-Reply-To: <20120906163812.GA9934@loopfree.net> References: <20120906163812.GA9934@loopfree.net> Message-ID: <5048D6B5.7020202@foobar.org> On 06/09/2012 17:38, Will Orton wrote: > The customer has a location in the relative middle of nowhere that they are > trying to build a protected OC3 to. Not sure if I see the problem here. Show them the bill for an OC3 service, and then show them the bill for the equivalent ethernet service. This usually works for me. If they want to pay for OC3 when there's no compelling reason to, who are you to argue? Nick From bill at herrin.us Thu Sep 6 12:49:06 2012 From: bill at herrin.us (William Herrin) Date: Thu, 6 Sep 2012 13:49:06 -0400 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <20120906151458.GC7079@dyn.com> References: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> <504821BD.7010009@necom830.hpcl.titech.ac.jp> <5AFF3D96-3204-433D-8A01-A680C455B489@delong.com> <20120906151458.GC7079@dyn.com> Message-ID: On Thu, Sep 6, 2012 at 11:14 AM, Andrew Sullivan wrote: > RFC 2052, which defined SRV in an > experiment, came out in 1996. SRV was moved to the standards track in > 2000. I've never heard an argument why it won't work, and we know > that SRV records are sometimes in use. Why couldn't that mechanism be > used more widely? Hi Andrew, Because the developer of the next killer app knows exactly squat about the DNS and won't discover anything about the DNS that can't be had via getaddrinfo() until long after its too late redefine the protocol in terms of seeking SRV records. Leaving SRV out of getaddrinfo() means that SRVs will be no more than lightly used for the duration of the current networking API. The last iteration of the API survived around 20 years of mainstream use so this one probably has another 15 to go. Also there are efficiency issues associated with seeking SRVs first and then addresses, the same kind of efficiency issues with reverse lookups that lead high volume software like web servers to not do reverse lookups. But those pale in comparison to the first problem. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From asullivan at dyn.com Thu Sep 6 12:59:13 2012 From: asullivan at dyn.com (Andrew Sullivan) Date: Thu, 6 Sep 2012 13:59:13 -0400 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: References: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> <504821BD.7010009@necom830.hpcl.titech.ac.jp> <5AFF3D96-3204-433D-8A01-A680C455B489@delong.com> <20120906151458.GC7079@dyn.com> Message-ID: <20120906175913.GM7079@dyn.com> On Thu, Sep 06, 2012 at 01:49:06PM -0400, William Herrin wrote: > the DNS and won't discover anything about the DNS that can't be had > via getaddrinfo() until long after its too late redefine the protocol > in terms of seeking SRV records. Oh, sure, I get that. One of the problems I've had with the "end to end NAT" argument is exactly that I can't see how it's any more deployable than IPv6, for exactly this reason. But the claim upthread was (I thought) that the application _can't_ know about this stuff, not that it's hard today. Because of the 20-year problem, I think now would be an excellent time to start thinking about how to make usable all those nice features we already have in the DNS. Maybe by the time I die, we'll have a useful system! Best, Andrew "living in constant, foolish, failed hope" Sullivan -- Andrew Sullivan Dyn Labs asullivan at dyn.com From morrowc.lists at gmail.com Thu Sep 6 13:02:37 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 6 Sep 2012 14:02:37 -0400 Subject: Are people still building SONET networks from scratch? In-Reply-To: <5048D6B5.7020202@foobar.org> References: <20120906163812.GA9934@loopfree.net> <5048D6B5.7020202@foobar.org> Message-ID: On Thu, Sep 6, 2012 at 1:00 PM, Nick Hilliard wrote: > On 06/09/2012 17:38, Will Orton wrote: >> The customer has a location in the relative middle of nowhere that they are >> trying to build a protected OC3 to. > > Not sure if I see the problem here. Show them the bill for an OC3 service, > and then show them the bill for the equivalent ethernet service. This > usually works for me. If they want to pay for OC3 when there's no > compelling reason to, who are you to argue? (remember, of course, to pad that bill by 8% so you profit more on the more expensive link... go telecom think!) From will at loopfree.net Thu Sep 6 13:12:29 2012 From: will at loopfree.net (Will Orton) Date: Thu, 6 Sep 2012 11:12:29 -0700 Subject: Are people still building SONET networks from scratch? In-Reply-To: <5048D6B5.7020202@foobar.org> References: <20120906163812.GA9934@loopfree.net> <5048D6B5.7020202@foobar.org> Message-ID: <20120906181229.GB9934@loopfree.net> On Thu, Sep 06, 2012 at 06:00:37PM +0100, Nick Hilliard wrote: > Not sure if I see the problem here. Show them the bill for an OC3 service, > and then show them the bill for the equivalent ethernet service. This > usually works for me. If they want to pay for OC3 when there's no > compelling reason to, who are you to argue? > > Nick > Yes, of course the response is, "figure out how to make the OC3 cheaper". :) So we're rapidly approaching a response of "you've engineered yourself into a corner, take it or leave it". I just can't see how to get OC3 D1-D12 tunneled through without doing it as a mix of OC-48 and dark fiber for the entire path and specifying lots of complicated boxes just to get those bytes through. That cost is an order of magnitude more than just buying OC3 from multiple carriers (who can't tunnel D1-D12), which is a magnitude more than buying mpls-based gig-e or gig-e wave. I wasn't around (well, I was just a T1/DS3 customer) when all the OC3/12/48 SONET networks were built 10-15 years ago. I suppose they were all built directly on the fiber (maybe with WDM but no layer1.5-2 muxing) and the provider was always the one who handled protection switching? I've considered using J's PE-4CHOC3-CE-SFP (OC3 emulated SAToP), then I could do it all with gig-e underneath. Does anyone make a cheaper OC3 circuit emulation module or box? Most likely the customer wouldn't believe such a thing is possible and we'd have to put something in the contract allowing them SLA credit if their OC3 suffers too many timing slips or something. -Will From owen at delong.com Thu Sep 6 13:27:12 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 6 Sep 2012 11:27:12 -0700 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <20120906151458.GC7079@dyn.com> References: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> <504821BD.7010009@necom830.hpcl.titech.ac.jp> <5AFF3D96-3204-433D-8A01-A680C455B489@delong.com> <20120906151458.GC7079@dyn.com> Message-ID: <1A09F1D2-F587-4C30-A06A-047351D68CBE@delong.com> On Sep 6, 2012, at 08:14 , Andrew Sullivan wrote: > On Wed, Sep 05, 2012 at 09:39:44PM -0700, Owen DeLong wrote: >> >> Never mind the fact that all the hosts trying to reach you have no >> way to know what port to use. > > Despite my scepticism of the overall project, I find the above claim a > little hard to accept. RFC 2052, which defined SRV in an > experiment, came out in 1996. SRV was moved to the standards track in > 2000. I've never heard an argument why it won't work, and we know > that SRV records are sometimes in use. Why couldn't that mechanism be > used more widely? > If browsers started implementing it, it could. I suppose the more accurate/detailed statement would be: Without modifying every client on the internet, there is no way for the clients trying to reach you to reliably be informed of this port number situation. If you're going to touch every client, it's easier to just do IPv6. Owen From tknchris at gmail.com Thu Sep 6 13:33:35 2012 From: tknchris at gmail.com (chris) Date: Thu, 6 Sep 2012 14:33:35 -0400 Subject: CLEC's in Ottawa area? Message-ID: Hello, I have a client in the ottawa ontario canada area who is looking at DSL for a secondary connection. I am pretty unfamiliar with the state of telecom industry in Canada, I googled around and found this rather lengthy list of CLEC's. http://support.crtc.gc.ca/tlcmlsts/default.aspx?indx=33&lang=e Does anyone have any good experiences with any of these carriers that service the Ottawa they could share? Also would be an added plus if they supported MLPPP as the client mentioned they were concerned with the lower speeds of DSL, so we would love to do two circuits with MLPPP if possible thanks! chris From alter3d at alter3d.ca Thu Sep 6 13:39:17 2012 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Thu, 06 Sep 2012 14:39:17 -0400 Subject: CLEC's in Ottawa area? In-Reply-To: References: Message-ID: <5048EDD5.50409@alter3d.ca> I recommend TekSavvy (www.teksavvy.com) as a DSL reseller pretty much anywhere in Ontario (and any other provinces they can get service in). Not sure why they're not on that CLEC list, but they're a pretty big (and awesome) provider up here. For bonus points, if you have to call their support line, you get someone who actually knows something about networking. We have some DSL lines through them at work, and my personal home cable connection is through them as well. - Pete On 12-09-06 02:33 PM, chris wrote: > Hello, > > I have a client in the ottawa ontario canada area who is looking at DSL for > a secondary connection. I am pretty unfamiliar with the state of telecom > industry in Canada, I googled around and found this rather lengthy list of > CLEC's. > > http://support.crtc.gc.ca/tlcmlsts/default.aspx?indx=33&lang=e > > Does anyone have any good experiences with any of these carriers that > service the Ottawa they could share? > > Also would be an added plus if they supported MLPPP as the client mentioned > they were concerned with the lower speeds of DSL, so we would love to do > two circuits with MLPPP if possible > > thanks! > chris From valdis.kletnieks at vt.edu Thu Sep 6 14:27:51 2012 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 06 Sep 2012 15:27:51 -0400 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: Your message of "Thu, 06 Sep 2012 11:14:58 -0400." <20120906151458.GC7079@dyn.com> References: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> <504821BD.7010009@necom830.hpcl.titech.ac.jp> <5AFF3D96-3204-433D-8A01-A680C455B489@delong.com> <20120906151458.GC7079@dyn.com> Message-ID: <85250.1346959671@turing-police.cc.vt.edu> On Thu, 06 Sep 2012 11:14:58 -0400, Andrew Sullivan said: > Despite my scepticism of the overall project, I find the above claim a > little hard to accept. RFC 2052, which defined SRV in an > experiment, came out in 1996. SRV was moved to the standards track in > 2000. I've never heard an argument why it won't work, and we know > that SRV records are sometimes in use. Why couldn't that mechanism be > used more widely? My PS3 may want to talk to the world, but I have no control over Comcast's DNS. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From morrowc.lists at gmail.com Thu Sep 6 14:30:00 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 6 Sep 2012 15:30:00 -0400 Subject: Are people still building SONET networks from scratch? In-Reply-To: <20120906181229.GB9934@loopfree.net> References: <20120906163812.GA9934@loopfree.net> <5048D6B5.7020202@foobar.org> <20120906181229.GB9934@loopfree.net> Message-ID: On Thu, Sep 6, 2012 at 2:12 PM, Will Orton wrote: > . I suppose they were all built > directly on the fiber (maybe with WDM but no layer1.5-2 muxing) and the > provider was always the one who handled protection switching? or protection at the optical layer isn't as predictable for all aspects as L3 'protection' is... or something. From fred at cisco.com Thu Sep 6 16:49:25 2012 From: fred at cisco.com (Fred Baker (fred)) Date: Thu, 6 Sep 2012 21:49:25 +0000 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> References: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> Message-ID: <12533C55-7B6A-42AD-8430-EEF15E0FB9DF@cisco.com> It would be really nice if people making statements about the end to end principle would talk about the end to end principle. http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf The abstract of the paper states the principle: This paper presents a design principle that helps guide placement of functions among the modules of a distributed computer system. The principle, called the end-to-end argument, suggests that functions placed at low levels of a system may be redundant or of little value when compared with the cost of providing them at that low level. Examples discussed in the paper include bit error recovery, security using encryption, duplicate message suppression, recovery from system crashes, and delivery acknowledgement. Low level mechanisms to support these functions are justified only as performance enhancements. One of the authors of the paper has since restated it in a way that is significantly less useful, which is that the only place anything intelligent should be done in a network is in the end system. If you believe that argument, then WiFi networks should not retransmit lost packets (and as a result would become far less useful) and the Internet should not use routing protocols - it should only use source routing. So, yes, I think the "Rise of the Stupid Network" is a very interesting paper and site, but needs to be handled carefully. The argument argues for simplicity and transparency; when a function at a lower layer does something an upper layer - not just the application, but any respectively higher and lower layers - it can be difficult to debug the behavior. However, it is not a hard-and-fast "the network should never do things that the end system doesn't expect"; the paper makes it clear that there is a trade-off, and if the trade-off makes sense (retransmitting at the link layer in addition to the end to end retransmission in the case of WiFi) it doesn't preclude the behavior. It merely suggests that one think about such things (retransmitting in LAPB turned out to be a bad idea way back when). Complexities of various types are unavoidable; to quote a fourteenth century logician, "a satisfactory syllogism contains no unnecessary complexity". Yes, I think that stateful network address translation violates the end to end principle. But it doesn't violate it because everyone can't talk with everyone directly; it violates it because a change is made in a packet that subverts an end system's intent and as a result randomly breaks things (for example, an ICMP packet-too-large response has to be specially handled by the NAT to make PMTU work). I would argue that a network-imposed policies like traffic filters violate the end to end principle no more than network-imposed routing (including not-routing) policies do. If you can't get somewhere or a given address isn't instantiated with a host, that's not particularly surprising. What might be surprising and difficult to diagnose would be something that sometimes allows packets through and sometimes doesn't without any clear reason. I suspect everyone on this list will agree that the KISS principle, aka end-to-end, is pretty important, and get irritated with vendors (cough) that push them towards complex solutions. A host directly sending mail to a remote MTA is not automatically a bad actor for any reason related to KISS. There are two issues, however, that you might think about. My employer tells me that they discard about 98% of email traffic headed to me; a study of my own email history says that the email from outside that passes that filter and which is what I expect to receive comes through less than 1000 immediate SMTP predecessors to the first Cisco MTA; running the same survey on my junk folder (which is only 30 days, not 18 years) has about 5000 SMTP predecessors, the 1000 and the 5000 are disjoint sets. So an SMTP connection to a remote MTA is not a bad thing automatically, but it raises security eyebrows - and should - because it is similar to how spam and other attacks are transmitted. In addition, at least historically, in many cases those MUAs directly connecting to remote MTAs try or tried to use them as open relays, and it was difficult for the relay to authenticate random systems. Having an MUA give its traffic to a first hop MTA using SSL or some other form of service authentication/authorization improves the security of the service. That can be overcome using S/MIME, of course, given a global PKI, but DKIM depends on the premise that the originator has somehow been authenticated and shown to be authorized to send email. On Sep 4, 2012, at 11:22 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Owen DeLong" > >> I am confused... I don't understand your comment. > > It is regularly alleged, on this mailing list, that NAT is bad *because it > violates the end-to-end principle of the Internet*, where each host is a > full-fledged host, able to connect to any other host to perform transactions. > > We see it now alleged that the opposite is true: that a laptop, say, like > mine, which runs Linux and postfix, and does not require a smarthost to > deliver mail to a remote server *is a bad actor* *precisely because it does > that* (in attempting to send mail directly to a domain's MX server) *from > behind a NAT router*, and possibly different ones at different times. > > I find these conflicting reports very conflicting. Either the end-to-end > principle *is* the Prime Directive... or it is *not*. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA #natog +1 727 647 1274 > ---------------------------------------------------- The ignorance of how to use new knowledge stockpiles exponentially. - Marshall McLuhan From marka at isc.org Thu Sep 6 17:30:12 2012 From: marka at isc.org (Mark Andrews) Date: Fri, 07 Sep 2012 08:30:12 +1000 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: Your message of "Thu, 06 Sep 2012 15:27:51 -0400." <85250.1346959671@turing-police.cc.vt.edu> References: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> <504821BD.7010009@necom830.hpcl.titech.ac.jp> <5AFF3D96-3204-433D-8A01-A680C455B489@delong.com> <20120906151458.GC7079@dyn.com> <85250.1346959671@turing-police.cc.vt.edu> Message-ID: <20120906223013.71B7D248740C@drugs.dv.isc.org> In message <85250.1346959671 at turing-police.cc.vt.edu>, valdis.kletnieks at vt.edu writes: > --==_Exmh_1346959671_1993P > Content-Type: text/plain; charset=us-ascii > > On Thu, 06 Sep 2012 11:14:58 -0400, Andrew Sullivan said: > > > Despite my scepticism of the overall project, I find the above claim a > > little hard to accept. RFC 2052, which defined SRV in an > > experiment, came out in 1996. SRV was moved to the standards track in > > 2000. I've never heard an argument why it won't work, and we know > > that SRV records are sometimes in use. Why couldn't that mechanism be > > used more widely? > > My PS3 may want to talk to the world, but I have no control over Comcast's DNS. What point are you trying to make? Comcast's servers support SRV as do all general purpose name servers. For HTTP at least you need to be backwards compatible so there is no reason not to add SRV support. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Exmh version 2.5 07/13/2001 > > iQIVAwUBUEj5NwdmEQWDXROgAQL/fRAAjHmAtVBMjQAybs2TWrzWMcE6e9k6A7Av > LvOXJAS1leKr0tyg0lG4+IwuMCN5bV3+V8F7+bWAfQFSBIj9aH5ymSuxdO/LJVoj > TdPRSRzTcPCL0mmIB5LbBdrDgi/PcruLdGDgOiLiLPhUkXnRJ+OmzR2WmAh4jgOz > dVLb0ugujqbmqm7tzgxeiC0yzF9EiL3RQAZwzZI9Tcbnh0rELMHWBhgGeIO5KbA9 > 4iCh79MkrPXr4uONVQrCmbNBuqcziGIekKDGCpSUqwynzbc7NK00+Xhhkz2inNOn > m7v73JFKzLd3AAjBenv3Yqz9hIwUGT4D9kW6Kof5Ah5SmzLY1ZOKpi+08M6i6SS/ > I54neNmQ7lLuO9p7EsGpRTfUN1MOMEYXo8yOFTNQI7FDWCXNhWz/MjE3wxmXQYeA > jBd8EE7m0QGuM6l/AhaS9BRXdZUXn8KK5E4N5YubJonLIuTzkTXuHmhFOB3Khlrl > rHfl84sf8TdeDuxlJZs4PLdfRJooknNjSqLYfyfH0UeK3mSjlY3rpjcAZbSZsMdy > vUDO0hU1C6FNFCXdkwRVZUtHxFX+l1sOtk76bt4s7NiWhwwGxwrykvk66qPa3YsH > nyIWS7SsX245hy7dayKMKpYIByaAO6E7uVWzhgOobRMe3omP911BE30D2KYLXFvn > wVqujobWuC4= > =o0nz > -----END PGP SIGNATURE----- > > --==_Exmh_1346959671_1993P-- > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mjl at caida.org Thu Sep 6 17:46:21 2012 From: mjl at caida.org (Matthew Luckie) Date: Thu, 06 Sep 2012 15:46:21 -0700 Subject: CAIDA's AS-rank project Message-ID: <504927BD.4090702@caida.org> Hello, We have been working on refreshing the data and algorithms behind CAIDA's as-rank project. We have published AS-relationships and AS-rankings computed for June 2012. We are currently seeking further validation of our rankings and relationship inferences. http://as-rank.caida.org/ The core of the algorithm is the inference of business relationships. Over the past two years we have received a significant amount of ground truth from operators through the corrections facility provided within AS-rank: in particular we obtained >1200 p2p relationships as a result of our previous algorithm that assigned many more customer/provider (c2p) relationships than ASes had in reality. Our intuition is that network owners are a lot more concerned when we infer a provider relationship that is actually a peer relationship, but are less motivated to validate other inferences. We have validated our algorithm against available ground truth and find our relationship inferences have a 99.1% positive predictive value (PPV) for c2p and 94.7% for p2p for the validation data we have available. Because customer cone computation depends on the accuracy of our c2p inferences, we are reasonably confident in our computed rankings. We are now soliciting further feedback in any shape and form offered. The as-rank website provides the ability for operators to submit corrections through the right-most "corrections" button on an individual ASes information page, and relationships ground-truth is solicited through that channel, if at all possible. Other feedback, on or off-list, would also be appreciated. If you are curious as to why a particular relationship was inferred, please get in contact with me. Some ASes have advised of a particular business relationship in the past, but when I drill down into the data it turns out they have a misconfiguration and are leaking routes to a peer. At a minimum, this might be a useful sanity check for some ASes who may be providing free transit without realising it. In the future, we plan to annotate each relationship with examples as to why it was inferred the way it was, but we have not yet got that far yet. Thanks, Matthew Luckie CAIDA From asullivan at dyn.com Thu Sep 6 21:00:59 2012 From: asullivan at dyn.com (Andrew Sullivan) Date: Thu, 6 Sep 2012 22:00:59 -0400 Subject: CLEC's in Ottawa area? In-Reply-To: References: Message-ID: <20120907020059.GB11731@dyn.com> On Thu, Sep 06, 2012 at 02:33:35PM -0400, chris wrote: > Also would be an added plus if they supported MLPPP as the client mentioned > they were concerned with the lower speeds of DSL, so we would love to do > two circuits with MLPPP if possible I can second the recommendation of Teksavvy (http://teksavvy.com). I've been very happy with them, even though I sometimes have periods of painful outage due to the woeful shape of the copper plant in my neighbourhood. (Bell is sure not the company I knew growing up. Bureaucratic and monopolistic still, yes, but the wires are now in terrible shape.) Also, Teksavvy will do MLPPP. Look under "add ons" on the Teksavvy site. (e.g. http://teksavvy.com/en/residential/internet/dsl/high-speed-dsl-25). Looks like it's $4.00 a month. Note that, in some areas, there's no copper, so you need to check. Bell has been known to remove the copper where they installed their fibre to the customer premises. I think this is within the bounds of the CRTC rules, but I haven't been bothered to check. Note that in some markets, Teksavvy also offers service over cable, so that might be another option. (You said that it was for redundancy, though, so the cable might be in use already.) Best, A -- Andrew Sullivan Dyn Labs asullivan at dyn.com From valdis.kletnieks at vt.edu Thu Sep 6 22:44:05 2012 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 06 Sep 2012 23:44:05 -0400 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: Your message of "Fri, 07 Sep 2012 08:30:12 +1000." <20120906223013.71B7D248740C@drugs.dv.isc.org> References: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> <504821BD.7010009@necom830.hpcl.titech.ac.jp> <5AFF3D96-3204-433D-8A01-A680C455B489@delong.com> <20120906151458.GC7079@dyn.com> <85250.1346959671@turing-police.cc.vt.edu> <20120906223013.71B7D248740C@drugs.dv.isc.org> Message-ID: <108454.1346989445@turing-police.cc.vt.edu> On Fri, 07 Sep 2012 08:30:12 +1000, Mark Andrews said: > In message <85250.1346959671 at turing-police.cc.vt.edu>, valdis.kletnieks at vt.edu writes: > > My PS3 may want to talk to the world, but I have no control over Comcast's DNS. > > What point are you trying to make? Comcast's servers support SRV as do all > general purpose name servers. For HTTP at least you need to be backwards > compatible so there is no reason not to add SRV support. Sure, Comcast's servers will happily support an SRV entry for my PS3. However, Comcast's business processes don't support a way for me to request said SRV record be listed. Heck, I don't even get a static IP with my current service package. ;) Now *I* have the technical chops to talk to the guys at dyndns.org or other providers and get an SRV entry created under some domain name pointing back at my IP address. However, Joe Sixpack doesn't really have that option. And unless you figure out a scalable and universal way for Joe Sixpack's Xbox or PS3 or whatever to request an SRV entry saying that the PS3 wants to do service "foobar" on port 34823, you can't use SRV like that. A better proposal would probably be having the NAT itself run a 'portmap' type service on a well known port like 111. Except that still doesn't do a very good job of disambiguating two instances of "foobar" behind a NAT... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From sean at seanharlow.info Fri Sep 7 00:31:51 2012 From: sean at seanharlow.info (Sean Harlow) Date: Fri, 7 Sep 2012 01:31:51 -0400 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <108454.1346989445@turing-police.cc.vt.edu> References: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> <504821BD.7010009@necom830.hpcl.titech.ac.jp> <5AFF3D96-3204-433D-8A01-A680C455B489@delong.com> <20120906151458.GC7079@dyn.com> <85250.1346959671@turing-police.cc.vt.edu> <20120906223013.71B7D248740C@drugs.dv.isc.org> <108454.1346989445@turing-police.cc.vt.edu> Message-ID: On Sep 6, 2012, at 23:44, Valdis.Kletnieks at vt.edu wrote: > However, Joe Sixpack doesn't really have that option. And > unless you figure out a scalable and universal way for Joe Sixpack's Xbox or PS3 or > whatever to request an SRV entry saying that the PS3 wants to do service > "foobar" on port 34823, you can't use SRV like that. I think you missed the point on this one. Even if your PS3 has a public IP with no limitations on ports, how exactly are others going to find it to connect to it? I see three options here: 1. You have to give them the IP address, in which case it's not exactly rocket science to give them the port as well. The same Joe Sixpack who couldn't find the port couldn't likely figure out his IP either, so the PS3 would have to be able to identify its own public-facing IP and tell him, in which case it could also tell him the port. 2. DNS, which while many don't have this ability any that do should have no problem setting a SRV record. Obviously not all clients support the use of SRV records, but that's not the subject of this particular tangent. 3. Intermediary directory server hosted at a known location. Pretty much the standard solution for actual PS3 titles as well as almost all other games since the late '90s. Rather than telling the user, the PS3 tells the central server its IP and port plus any useful metadata about the service being offered and the user just needs to give his friend a name or other identifier to find it in the list. None of these options are impacted by being behind a NAT as long as they have the ability to open a port via UPnP or equivalent, so if in an ideal world all client software understood SRV records this particular negative of NAT would be of minimal impact. Of course the real world is nowhere close to ideal and personally SIP phones and Jabber clients are the only things I've ever observed widely using SRV records, so at least for now I can't just do something like "_http._tcp.seanharlow.info 86400 IN SRV 0 5 8080 my.home.fake." and host my personal site on my home server (Mozilla has had a bug open on this for over ten years, Chrome for three, and Webkit closed their bug as WONTFIX two years ago so I don't expect this to change any time soon). At this point we're coming back around to the already raised point about if we're going to have to change a lot of things, why not just put that effort in to doing it right with IPv6 rather than trying to keep address conservation via DNAT alive? --- Sean Harlow sean at seanharlow.info From marka at isc.org Fri Sep 7 01:01:10 2012 From: marka at isc.org (Mark Andrews) Date: Fri, 07 Sep 2012 16:01:10 +1000 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: Your message of "Thu, 06 Sep 2012 23:44:05 -0400." <108454.1346989445@turing-police.cc.vt.edu> References: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> <504821BD.7010009@necom830.hpcl.titech.ac.jp> <5AFF3D96-3204-433D-8A01-A680C455B489@delong.com> <20120906151458.GC7079@dyn.com> <85250.1346959671@turing-police.cc.vt.edu> <20120906223013.71B7D248740C@drugs.dv.isc.org> <108454.1346989445@turing-police.cc.vt.edu> Message-ID: <20120907060110.69183248A76E@drugs.dv.isc.org> In message <108454.1346989445 at turing-police.cc.vt.edu>, valdis.kletnieks at vt.edu writes: > --==_Exmh_1346989445_1993P > Content-Type: text/plain; charset=us-ascii > > On Fri, 07 Sep 2012 08:30:12 +1000, Mark Andrews said: > > In message <85250.1346959671 at turing-police.cc.vt.edu>, valdis.kletnieks at vt.edu writes: > > > My PS3 may want to talk to the world, but I have no control over Comcast's DNS. > > > > What point are you trying to make? Comcast's servers support SRV as do all > > general purpose name servers. For HTTP at least you need to be backwards > > compatible so there is no reason not to add SRV support. > > Sure, Comcast's servers will happily support an SRV entry for my PS3. > > However, Comcast's business processes don't support a way for me to request > said SRV record be listed. Heck, I don't even get a static IP with my current service > package. ;) There are plenty of companies that will serve whatever you want them to serve. > Now *I* have the technical chops to talk to the guys at dyndns.org or other > providers and get an SRV entry created under some domain name pointing back at > my IP address. However, Joe Sixpack doesn't really have that option. And > unless you figure out a scalable and universal way for Joe Sixpack's Xbox or PS3 or > whatever to request an SRV entry saying that the PS3 wants to do service > "foobar" on port 34823, you can't use SRV like that. There is NOTHING stopping Sony adding code to the PS3 to perform dynamic updates to add the records. We have a well established protocol to do this securely. 100's of millions of records get updated daily using this protocol in the corporate environment. This is NOTHING Joe Sixpack can't do with a smidgen of help on behalf of product vendors. Home router vendors already have code to do this. domain name for the PS account name password account name and password form the TSIG information to secure the dynamic update. > A better proposal would probably be having the NAT itself run a 'portmap' type service > on a well known port like 111. Except that still doesn't do a very good job of > disambiguating two instances of "foobar" behind a NAT... -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mohta at necom830.hpcl.titech.ac.jp Fri Sep 7 01:23:30 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 07 Sep 2012 15:23:30 +0900 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <1398646.nogpiQX5tj@gentoovm> References: <5AFF3D96-3204-433D-8A01-A680C455B489@delong.com> <50482E3E.7020309@necom830.hpcl.titech.ac.jp> <1398646.nogpiQX5tj@gentoovm> Message-ID: <504992E2.4080305@necom830.hpcl.titech.ac.jp> Oliver wrote: >> All that necessary is local changes on end systems of those who >> want the end to end transparency. >> >> There is no changes on the Internet. > > You're basically redefining the term "end-to-end transparency" to suit your own Already in RFC3102, which restrict port number ranges, it is stated that: This document examines the general framework of Realm Specific IP (RSIP). RSIP is intended as a alternative to NAT in which the end- to-end integrity of packets is maintained. We focus on implementation issues, deployment scenarios, and interaction with other layer-three protocols. It's you who tries to change the meaning of "end to end transparency". Masataka Ohta From randy at psg.com Fri Sep 7 01:31:10 2012 From: randy at psg.com (Randy Bush) Date: Fri, 07 Sep 2012 15:31:10 +0900 Subject: RPKI Pilot Participant Notice In-Reply-To: References: Message-ID: > If a relying party's use of PKI infrastructure legally equated to > acceptance of the relying party agreement (RPA), then having an > explicit record of acceptance of the RPA would not be necessary. > > Alas, it does not appear possible to equate use of PKI certificates > with agreement to the associated RPA (and some might argue that this > is a feature, as some folks would not want to be legally bound to an > agreement which they did not explicitly review and accept.) do you have a r&d group devoted to how much you can delay, damage, warp, half-assed implement, ... rpki? look around you at the real world, the other rirs (especiall ripe/ncc), etc. the only part of it where arin seems to be doing a serious job is bs generation. thanks. randy From mohta at necom830.hpcl.titech.ac.jp Fri Sep 7 01:30:24 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 07 Sep 2012 15:30:24 +0900 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <20120906175913.GM7079@dyn.com> References: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> <504821BD.7010009@necom830.hpcl.titech.ac.jp> <5AFF3D96-3204-433D-8A01-A680C455B489@delong.com> <20120906151458.GC7079@dyn.com> <20120906175913.GM7079@dyn.com> Message-ID: <50499480.8050405@necom830.hpcl.titech.ac.jp> Andrew Sullivan wrote: >> the DNS and won't discover anything about the DNS that can't be had >> via getaddrinfo() until long after its too late redefine the protocol >> in terms of seeking SRV records. > > Oh, sure, I get that. One of the problems I've had with the "end to > end NAT" argument is exactly that I can't see how it's any more > deployable than IPv6, for exactly this reason. The easiest part of the deployment is to modify end systems. > Because of the 20-year problem, I think now > would be an excellent time to start thinking about how to make usable > all those nice features we already have in the DNS. Apple did it. See RFC6281. Masataka Ohta From owen at delong.com Fri Sep 7 01:32:10 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 6 Sep 2012 23:32:10 -0700 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: References: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> <504821BD.7010009@necom830.hpcl.titech.ac.jp> <5AFF3D96-3204-433D-8A01-A680C455B489@delong.com> <20120906151458.GC7079@dyn.com> <85250.1346959671@turing-police.cc.vt.edu> <20120906223013.71B7D248740C@drugs.dv.isc.org> <108454.1346989445@turing-police.cc.vt.edu> Message-ID: On Sep 6, 2012, at 22:31 , Sean Harlow wrote: > On Sep 6, 2012, at 23:44, Valdis.Kletnieks at vt.edu wrote: > >> However, Joe Sixpack doesn't really have that option. And >> unless you figure out a scalable and universal way for Joe Sixpack's Xbox or PS3 or >> whatever to request an SRV entry saying that the PS3 wants to do service >> "foobar" on port 34823, you can't use SRV like that. > > I think you missed the point on this one. Even if your PS3 has a public IP with no limitations on ports, how exactly are others going to find it to connect to it? > > I see three options here: > > 1. You have to give them the IP address, in which case it's not exactly rocket science to give them the port as well. The same Joe Sixpack who couldn't find the port couldn't likely figure out his IP either, so the PS3 would have to be able to identify its own public-facing IP and tell him, in which case it could also tell him the port. > 2. DNS, which while many don't have this ability any that do should have no problem setting a SRV record. Obviously not all clients support the use of SRV records, but that's not the subject of this particular tangent. Anyone can set up free DNS from a variety of providers and get a domain name for ~$10/year. I'm not sure why you think there is anyone who can't get DNS. If you can operate a web browser and come up with $10/year or so, you can have forward DNS. The inability to influence Comcast's nameservers would only affect reverse lookups (which SRV goes forward, not reverse IIRC). > 3. Intermediary directory server hosted at a known location. Pretty much the standard solution for actual PS3 titles as well as almost all other games since the late '90s. Rather than telling the user, the PS3 tells the central server its IP and port plus any useful metadata about the service being offered and the user just needs to give his friend a name or other identifier to find it in the list. Which becomes ugly and unnecessary with full transparency and useful DNS, which we get with IPv6 even without SRV records. To make SRV records meaningful, OTOH, virtually every client needs an update. > None of these options are impacted by being behind a NAT as long as they have the ability to open a port via UPnP or equivalent, so if in an ideal world all client software understood SRV records this particular negative of NAT would be of minimal impact. Of course the real world is nowhere close to ideal and personally SIP phones and Jabber clients are the only things I've ever observed widely using SRV records, so at least for now I can't just do something like "_http._tcp.seanharlow.info 86400 IN SRV 0 5 8080 my.home.fake." and host my personal site on my home server (Mozilla has had a bug open on this for over ten years, Chrome for three, and Webkit closed their bug as WONTFIX two years ago so I don't expect this to change any time soon). At this point we're coming back around to the already raised point about if we're going to have to change a lot of things, why not just put that effort in to doing it right with IPv6 rather than trying to keep address conservation via DNAT alive? +1 -- Address transparency is a good thing. Owen From owen at delong.com Fri Sep 7 01:35:24 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 6 Sep 2012 23:35:24 -0700 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <50499480.8050405@necom830.hpcl.titech.ac.jp> References: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> <504821BD.7010009@necom830.hpcl.titech.ac.jp> <5AFF3D96-3204-433D-8A01-A680C455B489@delong.com> <20120906151458.GC7079@dyn.com> <20120906175913.GM7079@dyn.com> <50499480.8050405@necom830.hpcl.titech.ac.jp> Message-ID: On Sep 6, 2012, at 23:30 , Masataka Ohta wrote: > Andrew Sullivan wrote: > >>> the DNS and won't discover anything about the DNS that can't be had >>> via getaddrinfo() until long after its too late redefine the protocol >>> in terms of seeking SRV records. >> >> Oh, sure, I get that. One of the problems I've had with the "end to >> end NAT" argument is exactly that I can't see how it's any more >> deployable than IPv6, for exactly this reason. > > The easiest part of the deployment is to modify end systems. > Then why is IPv6 deployment happening faster in the internet core than at the edge? The real world seems to defy your claims. Owen From owen at delong.com Fri Sep 7 01:34:29 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 6 Sep 2012 23:34:29 -0700 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <504992E2.4080305@necom830.hpcl.titech.ac.jp> References: <5AFF3D96-3204-433D-8A01-A680C455B489@delong.com> <50482E3E.7020309@necom830.hpcl.titech.ac.jp> <1398646.nogpiQX5tj@gentoovm> <504992E2.4080305@necom830.hpcl.titech.ac.jp> Message-ID: <8E796C8D-4450-4B73-B322-10F56D1B0E36@delong.com> This has been experimental with no forward progress since 2001. Any sane person would conclude that the experiment failed to garner any meaningful support. Is there any continuing active work on this experiment? Any running code? Didn't think so. Owen On Sep 6, 2012, at 23:23 , Masataka Ohta wrote: > Oliver wrote: > >>> All that necessary is local changes on end systems of those who >>> want the end to end transparency. >>> >>> There is no changes on the Internet. >> >> You're basically redefining the term "end-to-end transparency" to suit your own > > Already in RFC3102, which restrict port number ranges, it is > stated that: > > This document examines the general framework of Realm Specific IP > (RSIP). RSIP is intended as a alternative to NAT in which the end- > to-end integrity of packets is maintained. We focus on > implementation issues, deployment scenarios, and interaction with > other layer-three protocols. > > It's you who tries to change the meaning of "end to end transparency". > > Masataka Ohta > From jcurran at arin.net Fri Sep 7 01:45:16 2012 From: jcurran at arin.net (John Curran) Date: Fri, 7 Sep 2012 06:45:16 +0000 Subject: RPKI Pilot Participant Notice In-Reply-To: References: Message-ID: <04C6C115-620F-4DBA-A04D-2B197EABE3A1@arin.net> On Sep 7, 2012, at 7:31 AM, Randy Bush wrote: >> If a relying party's use of PKI infrastructure legally equated to >> acceptance of the relying party agreement (RPA), then having an >> explicit record of acceptance of the RPA would not be necessary. >> >> Alas, it does not appear possible to equate use of PKI certificates >> with agreement to the associated RPA (and some might argue that this >> is a feature, as some folks would not want to be legally bound to an >> agreement which they did not explicitly review and accept.) > > do you have a r&d group devoted to how much you can delay, damage, warp, > half-assed implement, ... rpki? look around you at the real world, the > other rirs (especiall ripe/ncc), etc. the only part of it where arin > seems to be doing a serious job is bs generation. thanks. Good morning Randy - Are you indicating that RPKI services should be offered without any RPA (and/or CPS) at all, or that these agreements should legally adhere without explicit agreement? There is an statement expressing that CPS or RPA might benefit from the latter treatment in section 3.4 of the Internet PKI framework (RFC 3647), but it does not actually hold legally true at the present time. If you have more insight or clarity on this matter, it would be most welcome. Thanks! /John John Curran President and CEO ARIN From mohta at necom830.hpcl.titech.ac.jp Fri Sep 7 01:50:15 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 07 Sep 2012 15:50:15 +0900 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: References: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> <504821BD.7010009@necom830.hpcl.titech.ac.jp> <5AFF3D96-3204-433D-8A01-A680C455B489@delong.com> <20120906151458.GC7079@dyn.com> <85250.1346959671@turing-police.cc.vt.edu> <20120906223013.71B7D248740C@drugs.dv.isc.org> <108454.1346989445@turing-police.cc.vt.edu> Message-ID: <50499927.2090904@necom830.hpcl.titech.ac.jp> Sean Harlow wrote: > None of these options are impacted by being behind a NAT as long > as they have the ability to open a port via UPnP or equivalent, > so if in an ideal world all client software understood SRV > records this particular negative of NAT would be of minimal impact. My point is that the impact can be minimized if 1) a set of port numbers is statically allocated to a host behind NAT without UPnP or PCP, just as allocating a static address to a host, which means there is no security concern w.r.t. dynamic assignment. Dynamic DNS update is not necessary, either. UPnP or PCP can still be used to collect information for reverse translation. 2) reverse translation can be performed by network and/or transport layer without involving applications, which makes modifications to application programs completely unnecessary. I have already confirmed that ftp PORT command work transparently. > Of course the real world is nowhere close to ideal and > personally SIP phones and Jabber clients are the only things > I've ever observed widely using SRV records, As we can explicitly specify port numbers in URLs, support for SRV is not very essential. But, SRV will be more commonly used as PCP will be deployed. Masataka Ohta From randy at psg.com Fri Sep 7 01:55:15 2012 From: randy at psg.com (Randy Bush) Date: Fri, 07 Sep 2012 15:55:15 +0900 Subject: RPKI Pilot Participant Notice In-Reply-To: <04C6C115-620F-4DBA-A04D-2B197EABE3A1@arin.net> References: <04C6C115-620F-4DBA-A04D-2B197EABE3A1@arin.net> Message-ID: > Good morning Randy - it is late afternoon > Are you indicating that RPKI services should be offered without any > RPA (and/or CPS) at all, or that these agreements should legally > adhere without explicit agreement? There is an statement expressing > that CPS or RPA might benefit from the latter treatment in section > 3.4 of the Internet PKI framework (RFC 3647), but it does not > actually hold legally true at the present time. If you have more > insight or clarity on this matter, it would be most welcome. does arin run an irr instance? how much legal bs have you wrapped around it? randy From mohta at necom830.hpcl.titech.ac.jp Fri Sep 7 01:57:23 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 07 Sep 2012 15:57:23 +0900 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: References: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> <504821BD.7010009@necom830.hpcl.titech.ac.jp> <5AFF3D96-3204-433D-8A01-A680C455B489@delong.com> <20120906151458.GC7079@dyn.com> <20120906175913.GM7079@dyn.com> <50499480.8050405@necom830.hpcl.titech.ac.jp> Message-ID: <50499AD3.3020006@necom830.hpcl.titech.ac.jp> Owen DeLong wrote: > Then why is IPv6 deployment happening faster in the internet core than > at the edge? > The real world seems to defy your claims. Which world, are you talking about? Martian? > This has been experimental with no forward progress since 2001. Obviously because it is a new protocol requiring new gateways, which is not the case with UPnP capable NAT. Moreover, it has nothing to do with the definition of the end to end transparency. Masataka Ohta From adam.vitkovsky at swan.sk Fri Sep 7 02:15:56 2012 From: adam.vitkovsky at swan.sk (Adam Vitkovsky) Date: Fri, 7 Sep 2012 09:15:56 +0200 Subject: Are people still building SONET networks from scratch? In-Reply-To: <20120906181229.GB9934@loopfree.net> References: <20120906163812.GA9934@loopfree.net> <5048D6B5.7020202@foobar.org> <20120906181229.GB9934@loopfree.net> Message-ID: <012001cd8cc8$9fc3ce90$df4b6bb0$@swan.sk> >Does anyone make a cheaper OC3 circuit emulation module or box? Maybe Cisco ME 3600X 24CX Switch or Cisco ASR 903 Router adam From jcurran at arin.net Fri Sep 7 03:10:15 2012 From: jcurran at arin.net (John Curran) Date: Fri, 7 Sep 2012 08:10:15 +0000 Subject: RPKI Pilot Participant Notice In-Reply-To: References: <04C6C115-620F-4DBA-A04D-2B197EABE3A1@arin.net> Message-ID: On Sep 7, 2012, at 7:55 AM, Randy Bush wrote: >> Good morning Randy - > > it is late afternoon Indeed... that may contribute significantly to the difference in perspective. In the US, little details such as legal structures often take on greater importance than would be otherwise warranted. >> Are you indicating that RPKI services should be offered without any >> RPA (and/or CPS) at all, or that these agreements should legally >> adhere without explicit agreement? There is an statement expressing >> that CPS or RPA might benefit from the latter treatment in section >> 3.4 of the Internet PKI framework (RFC 3647), but it does not >> actually hold legally true at the present time. If you have more >> insight or clarity on this matter, it would be most welcome. > > does arin run an irr instance? Yes. > how much legal bs have you wrapped around it? If we were establishing it today, I do not know what, if any, legal machinations would be needed. This is similar to RFCs, which were published first without any preamble but now have significant legal structure at the front. FYI, /John John Curran President and CEO ARIN From nanog at studio442.com.au Fri Sep 7 07:50:31 2012 From: nanog at studio442.com.au (Julien Goodwin) Date: Fri, 07 Sep 2012 22:50:31 +1000 Subject: Are people still building SONET networks from scratch? In-Reply-To: <20120906163812.GA9934@loopfree.net> References: <20120906163812.GA9934@loopfree.net> Message-ID: <5049ED97.2050701@studio442.com.au> On 07/09/12 02:38, Will Orton wrote: > Having much more experience with ethernet/packet/MPLS setups, we are trying to > get the client to admit that 1g/10g waves running ethernet with QoS would be as > good as or better in terms of latency, jitter, and loss for their packet data. > So far they will barely listen to the arguments. And then going the next leap > and showing them that we could work towards <50ms protection switching with > MPLS/BFD/etc packet-based protocols is another stretch. > > Am I missing something here that my customer isn't, or is it the other way > around? A few of the engineers at $DAYJOB still try and claim SONET is easier to troubleshoot, but that hasn't been my practical experience. With ethernet it's something like: - Layer 1 - light levels (DoM on nearly everything) - Layer 1 - link pulse - Layer 2 - can I send frames SONET it's, in practice: - Layer 1 - light levels (DoM on newer kit, SOL on older) - Layer 2 - Seemingly random collection of alarms - Layer 2 - Is PPP up? Sure being able tell a provider that our kit is showing a particular alarm can sometimes be helpful, but for every time that's been helpful I've seen multiple circuits down for timing, often for no explainable reason (I have atomic standards at home, and still can't explain a few of the cases I've seen). As others have said doing a "diverse 1/10g ethernet" quote and a "protected SONET" quote may be worthwhile, and adding a 20% pad to the SONET one for staff training may also be perfectly justifiable. Also other then the ONS15300 series (which I'm amazed haven't been discontinued) I can see nothing that actually offers OC3 line ports, building something new using those today seems like using a 2500 as a console server, sure for a lab or demo perhaps, but otherwise I'm staying well away from them. From valdis.kletnieks at vt.edu Fri Sep 7 09:20:12 2012 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Fri, 07 Sep 2012 10:20:12 -0400 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: Your message of "Fri, 07 Sep 2012 16:01:10 +1000." <20120907060110.69183248A76E@drugs.dv.isc.org> References: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> <504821BD.7010009@necom830.hpcl.titech.ac.jp> <5AFF3D96-3204-433D-8A01-A680C455B489@delong.com> <20120906151458.GC7079@dyn.com> <85250.1346959671@turing-police.cc.vt.edu> <20120906223013.71B7D248740C@drugs.dv.isc.org> <108454.1346989445@turing-police.cc.vt.edu> <20120907060110.69183248A76E@drugs.dv.isc.org> Message-ID: <5433.1347027612@turing-police.cc.vt.edu> On Fri, 07 Sep 2012 16:01:10 +1000, Mark Andrews said: > There is NOTHING stopping Sony adding code to the PS3 to perform > dynamic updates to add the records. We have a well established > protocol to do this securely. 100's of millions of records get > updated daily using this protocol in the corporate environment. > This is NOTHING Joe Sixpack can't do with a smidgen of help on > behalf of product vendors. Home router vendors already have > code to do this. > > domain name for the PS > account name > password > > account name and password form the TSIG information to secure the > dynamic update. And my point was merely that you can't actually use SRV for this use case until the above is actually deployed, rather than in the "nothing stopping SONY" hand-waving state. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From olipro at 8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa Fri Sep 7 12:40:18 2012 From: olipro at 8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa (Oliver) Date: Fri, 07 Sep 2012 19:40:18 +0200 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <504992E2.4080305@necom830.hpcl.titech.ac.jp> References: <1398646.nogpiQX5tj@gentoovm> <504992E2.4080305@necom830.hpcl.titech.ac.jp> Message-ID: <1375033.GM90FNPWn2@gentoovm> On Friday 07 September 2012 15:23:30 Masataka Ohta wrote: > Oliver wrote: > >> All that necessary is local changes on end systems of those who > >> want the end to end transparency. > >> > >> There is no changes on the Internet. > > > > You're basically redefining the term "end-to-end transparency" to suit > > your own > Already in RFC3102, which restrict port number ranges, it is > stated that: > > This document examines the general framework of Realm Specific IP > (RSIP). RSIP is intended as a alternative to NAT in which the end- > to-end integrity of packets is maintained. We focus on > implementation issues, deployment scenarios, and interaction with > other layer-three protocols. Just because something is documented in RFC does not automatically make it a standard, nor does it necessarily make anyone care. I refer you to RFC1149. Although, since you have such a hard-on for RFCs, you should check out RFC2460 - unlike 3102, it's standards-track and quite widely implemented. > > It's you who tries to change the meaning of "end to end transparency". > Denial: not just a river in Egypt. If the best rebuttal you can come up with is an experimental, unused RFC and a one-liner that basically amounts to "NO U", I suggest you do everyone a favour and crawl back into the hole you came from. I realise that it must be a difficult and slow process coming to the realisation that everything you've advocated for and espoused is unmitigated garbage, but whilst you deal with that internal struggle, please save the rest of us from having to waste our time deconstructing the last vestiges of your folly. Regards, Oliver From trejrco at gmail.com Fri Sep 7 12:45:50 2012 From: trejrco at gmail.com (TJ) Date: Fri, 7 Sep 2012 13:45:50 -0400 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: References: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> Message-ID: On Tue, Sep 4, 2012 at 3:45 PM, William Herrin wrote: > On Tue, Sep 4, 2012 at 2:22 PM, Jay Ashworth wrote: > > It is regularly alleged, on this mailing list, that NAT is bad *because > it > > violates the end-to-end principle of the Internet*, where each host is a > > full-fledged host, able to connect to any other host to perform > transactions. > > That's what firewalls *are for* Jay. They intentionally break > end-to-end for communications classified by the network owner as > undesirable. Whether a particular firewall employs NAT or not is > largely beside the point here. Either way, the firewall is *supposed* > to break some of the end to end communication paths. > Exactly - talking about a *(subtle?)* difference here. 1) Breaking the E2E model because your security policy (effectively) dictates it. For the record, this is fine as it is your decision for your network. 2) Being forced to break that model by deficiencies in the underlying protocol/address-family. This is, shall we say, sub-optimal. /TJ From cscora at apnic.net Fri Sep 7 13:51:56 2012 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 8 Sep 2012 04:51:56 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201209071851.q87IpuOQ027853@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, TRNOG, 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 08 Sep, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 425836 Prefixes after maximum aggregation: 178207 Deaggregation factor: 2.39 Unique aggregates announced to Internet: 207327 Total ASes present in the Internet Routing Table: 42041 Prefixes per ASN: 10.13 Origin-only ASes present in the Internet Routing Table: 33589 Origin ASes announcing only one prefix: 15753 Transit ASes present in the Internet Routing Table: 5599 Transit-only ASes present in the Internet Routing Table: 135 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 32 Max AS path prepend of ASN ( 48687) 24 Prefixes from unregistered ASNs in the Routing Table: 715 Unregistered ASNs in the Routing Table: 248 Number of 32-bit ASNs allocated by the RIRs: 3235 Number of 32-bit ASNs visible in the Routing Table: 2853 Prefixes from 32-bit ASNs in the Routing Table: 7496 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 184 Number of addresses announced to Internet: 2593144332 Equivalent to 154 /8s, 144 /16s and 62 /24s Percentage of available address space announced: 70.0 Percentage of allocated address space announced: 70.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 93.5 Total number of prefixes smaller than registry allocations: 150194 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 102226 Total APNIC prefixes after maximum aggregation: 32992 APNIC Deaggregation factor: 3.10 Prefixes being announced from the APNIC address blocks: 102840 Unique aggregates announced from the APNIC address blocks: 42607 APNIC Region origin ASes present in the Internet Routing Table: 4755 APNIC Prefixes per ASN: 21.63 APNIC Region origin ASes announcing only one prefix: 1245 APNIC Region transit ASes present in the Internet Routing Table: 763 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 27 Number of APNIC region 32-bit ASNs visible in the Routing Table: 297 Number of APNIC addresses announced to Internet: 707762048 Equivalent to 42 /8s, 47 /16s and 151 /24s Percentage of available APNIC address space announced: 82.7 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 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, 150/8, 153/8, 163/8, 171/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: 154235 Total ARIN prefixes after maximum aggregation: 77982 ARIN Deaggregation factor: 1.98 Prefixes being announced from the ARIN address blocks: 155222 Unique aggregates announced from the ARIN address blocks: 69088 ARIN Region origin ASes present in the Internet Routing Table: 15222 ARIN Prefixes per ASN: 10.20 ARIN Region origin ASes announcing only one prefix: 5736 ARIN Region transit ASes present in the Internet Routing Table: 1595 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 17 Number of ARIN addresses announced to Internet: 1083362176 Equivalent to 64 /8s, 146 /16s and 203 /24s Percentage of available ARIN address space announced: 57.3 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, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/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: 108148 Total RIPE prefixes after maximum aggregation: 56530 RIPE Deaggregation factor: 1.91 Prefixes being announced from the RIPE address blocks: 110545 Unique aggregates announced from the RIPE address blocks: 69820 RIPE Region origin ASes present in the Internet Routing Table: 16841 RIPE Prefixes per ASN: 6.56 RIPE Region origin ASes announcing only one prefix: 8164 RIPE Region transit ASes present in the Internet Routing Table: 2710 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1860 Number of RIPE addresses announced to Internet: 644425956 Equivalent to 38 /8s, 105 /16s and 40 /24s Percentage of available RIPE address space announced: 93.7 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 59392-61439, 196608-199679 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, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 43718 Total LACNIC prefixes after maximum aggregation: 8443 LACNIC Deaggregation factor: 5.18 Prefixes being announced from the LACNIC address blocks: 46692 Unique aggregates announced from the LACNIC address blocks: 22215 LACNIC Region origin ASes present in the Internet Routing Table: 1642 LACNIC Prefixes per ASN: 28.44 LACNIC Region origin ASes announcing only one prefix: 435 LACNIC Region transit ASes present in the Internet Routing Table: 320 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 673 Number of LACNIC addresses announced to Internet: 115436584 Equivalent to 6 /8s, 225 /16s and 108 /24s Percentage of available LACNIC address space announced: 68.8 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, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 9877 Total AfriNIC prefixes after maximum aggregation: 2203 AfriNIC Deaggregation factor: 4.48 Prefixes being announced from the AfriNIC address blocks: 10353 Unique aggregates announced from the AfriNIC address blocks: 3445 AfriNIC Region origin ASes present in the Internet Routing Table: 560 AfriNIC Prefixes per ASN: 18.49 AfriNIC Region origin ASes announcing only one prefix: 173 AfriNIC Region transit ASes present in the Internet Routing Table: 125 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 41688576 Equivalent to 2 /8s, 124 /16s and 30 /24s Percentage of available AfriNIC address space announced: 41.4 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2950 11125 1418 Korea Telecom (KIX) 17974 2342 702 54 PT TELEKOMUNIKASI INDONESIA 7545 1752 301 86 TPG Internet Pty Ltd 4755 1618 387 162 TATA Communications formerly 9829 1322 1101 31 BSNL National Internet Backbo 9583 1179 87 508 Sify Limited 4808 1121 2049 319 CNCGROUP IP network: China169 7552 1107 1062 11 Vietel Corporation 24560 1040 386 160 Bharti Airtel Ltd., Telemedia 9498 1002 310 73 BHARTI Airtel Ltd. 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 7029 3456 990 154 Windstream Communications Inc 6389 3334 3736 184 bellsouth.net, inc. 18566 2085 382 180 Covad Communications 1785 1912 678 127 PaeTec Communications, Inc. 22773 1888 2931 129 Cox Communications, Inc. 20115 1658 1578 614 Charter Communications 4323 1580 1026 385 Time Warner Telecom 30036 1417 279 746 Mediacom Communications Corp 7018 1260 10316 831 AT&T WorldNet Services 11492 1197 217 343 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 8402 1661 544 16 Corbina telecom 2118 1401 97 14 EUnet/RELCOM Autonomous Syste 15557 1221 2247 55 LDCOM NETWORKS 12479 830 765 82 Uni2 Autonomous System 34984 756 205 179 BILISIM TELEKOM 6830 723 2313 447 UPC Distribution Services 31148 713 37 9 FreeNet ISP 20940 711 227 549 Akamai Technologies European 13188 702 100 9 Educational Network 58113 616 69 362 LIR DATACENTER TELECOM SRL 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 28573 2141 1248 54 NET Servicos de Comunicao S.A 10620 2132 362 221 TVCABLE BOGOTA 8151 1570 3032 343 UniNet S.A. de C.V. 7303 1564 1034 199 Telecom Argentina Stet-France 6503 1535 451 69 AVANTEL, S.A. 6458 792 81 15 GUATEL 27947 721 74 94 Telconet S.A 3816 638 262 95 Empresa Nacional de Telecomun 11172 593 85 69 Servicios Alestra S.A de C.V 14420 580 83 105 CORPORACION NACIONAL DE TELEC 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 878 275 36 LINKdotNET AS number 8452 834 958 13 TEDATA 36998 776 48 3 MOBITEL 6713 517 650 19 Itissalat Al-MAGHRIB 24835 269 80 8 RAYA Telecom - Egypt 3741 262 904 223 The Internet Solution 33776 231 13 11 Starcomms Nigeria Limited 12258 194 28 66 Vodacom Internet Company 15706 193 32 6 Sudatel Internet Exchange Aut 29975 191 667 21 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 7029 3456 990 154 Windstream Communications Inc 6389 3334 3736 184 bellsouth.net, inc. 4766 2950 11125 1418 Korea Telecom (KIX) 17974 2342 702 54 PT TELEKOMUNIKASI INDONESIA 28573 2141 1248 54 NET Servicos de Comunicao S.A 10620 2132 362 221 TVCABLE BOGOTA 18566 2085 382 180 Covad Communications 1785 1912 678 127 PaeTec Communications, Inc. 22773 1888 2931 129 Cox Communications, Inc. 7545 1752 301 86 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 3334 3150 bellsouth.net, inc. 17974 2342 2288 PT TELEKOMUNIKASI INDONESIA 28573 2141 2087 NET Servicos de Comunicao S.A 10620 2132 1911 TVCABLE BOGOTA 18566 2085 1905 Covad Communications 1785 1912 1785 PaeTec Communications, Inc. 22773 1888 1759 Cox Communications, Inc. 7545 1752 1666 TPG Internet Pty Ltd 8402 1661 1645 Corbina telecom 4766 2950 1532 Korea Telecom (KIX) Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 59414 UNALLOCATED 5.102.144.0/21 15576 Nextra backbone in D 59395 UNALLOCATED 5.133.16.0/21 12658 Dexterity Networks L 59407 UNALLOCATED 5.134.16.0/21 51167 Giga-Hosting GmbH 59521 UNALLOCATED 5.134.192.0/21 29518 Labs2 59441 UNALLOCATED 5.144.128.0/21 50810 Mobin Net Communicat 59581 UNALLOCATED 5.149.8.0/21 25577 C4L main AS 59457 UNALLOCATED 5.149.64.0/24 35567 DASTO semtel d.o.o. 59457 UNALLOCATED 5.149.65.0/24 35567 DASTO semtel d.o.o. 59457 UNALLOCATED 5.149.66.0/24 35567 DASTO semtel d.o.o. 59457 UNALLOCATED 5.149.67.0/24 35567 DASTO semtel d.o.o. Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.206.240.0/20 57332 TOM-NET s.c. Dariusz Koper, R 5.226.64.0/18 12741 INTERNETIA Commercial Autonom 5.226.136.0/21 25369 4u servers 5.228.0.0/16 42610 RIPE Network Coordination Cen 14.192.0.0/22 45464 Room 201, TGU Bldg 14.192.4.0/22 45464 Room 201, TGU Bldg 14.192.8.0/22 45464 Room 201, TGU Bldg 14.192.12.0/22 45464 Room 201, TGU Bldg 14.192.16.0/22 45464 Room 201, TGU Bldg 14.192.20.0/22 45464 Room 201, TGU Bldg 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:18 /9:14 /10:29 /11:84 /12:237 /13:475 /14:841 /15:1541 /16:12381 /17:6415 /18:10842 /19:21044 /20:30202 /21:32106 /22:42325 /23:39848 /24:223276 /25:1364 /26:1592 /27:921 /28:175 /29:64 /30:18 /31:0 /32:24 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 2812 3456 Windstream Communications Inc 18566 2035 2085 Covad Communications 6389 1849 3334 bellsouth.net, inc. 8402 1384 1661 Corbina telecom 30036 1350 1417 Mediacom Communications Corp 22773 1231 1888 Cox Communications, Inc. 15557 1165 1221 LDCOM NETWORKS 11492 1160 1197 Cable One 6503 1053 1535 AVANTEL, S.A. 1785 1013 1912 PaeTec Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:581 2:783 3:1 4:13 5:428 6:3 8:455 12:2001 13:1 14:663 15:11 16:3 17:6 20:27 23:203 24:1824 27:1317 31:1015 32:56 33:2 34:2 36:7 37:759 38:828 39:2 40:132 41:3133 42:158 44:3 46:1527 47:2 49:468 50:592 52:13 54:17 55:6 56:1 57:31 58:989 59:528 60:240 61:1295 62:1002 63:2003 64:4262 65:2241 66:4494 67:2051 68:1169 69:3194 70:985 71:522 72:1870 74:2583 75:495 76:323 77:951 78:941 79:488 80:1265 81:956 82:634 83:531 84:626 85:1157 86:806 87:924 88:350 89:1789 90:303 91:5183 92:578 93:1494 94:1635 95:1271 96:416 97:318 98:893 99:39 100:23 101:260 103:1493 105:512 106:118 107:198 108:444 109:1921 110:794 111:957 112:446 113:682 114:655 115:856 116:825 117:733 118:946 119:1261 120:299 121:691 122:1646 123:1170 124:1352 125:1270 128:549 129:186 130:282 131:631 132:302 133:22 134:251 135:61 136:217 137:238 138:342 139:187 140:502 141:280 142:486 143:366 144:487 145:80 146:514 147:268 148:758 149:323 150:157 151:177 152:451 153:182 154:20 155:420 156:222 157:379 158:184 159:642 160:343 161:414 162:408 163:190 164:693 165:416 166:560 167:544 168:959 169:125 170:905 171:149 172:6 173:1721 174:628 175:445 176:575 177:1102 178:1659 180:1344 181:134 182:1043 183:230 184:597 186:2195 187:1244 188:1529 189:1586 190:6094 192:6024 193:5720 194:4560 195:3447 196:1215 197:220 198:3776 199:4975 200:5994 201:1969 202:8712 203:8698 204:4419 205:2542 206:2752 207:2875 208:4057 209:3668 210:2833 211:1536 212:2025 213:1809 214:893 215:88 216:5140 217:1553 218:548 219:316 220:1239 221:532 222:339 223:378 End of report From cidr-report at potaroo.net Fri Sep 7 17:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 7 Sep 2012 22:00:00 GMT Subject: The Cidr Report Message-ID: <201209072200.q87M00hp017893@wattle.apnic.net> This report has been generated at Fri Sep 7 21:13:05 2012 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 31-08-12 426827 246600 01-09-12 426662 246502 02-09-12 426856 246667 03-09-12 427078 246831 04-09-12 426935 245691 05-09-12 427098 246050 06-09-12 427448 246019 07-09-12 427365 246183 AS Summary 42141 Number of ASes in routing system 17590 Number of ASes announcing only one prefix 3459 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 113164512 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'). --- 07Sep12 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 428070 246197 181873 42.5% All ASes AS6389 3334 187 3147 94.4% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2141 58 2083 97.3% NET Servicos de Comunicao S.A. AS17974 2342 537 1805 77.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS22773 1888 158 1730 91.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS7029 3459 1733 1726 49.9% WINDSTREAM - Windstream Communications Inc AS18566 2085 423 1662 79.7% COVAD - Covad Communications Co. AS4766 2954 1462 1492 50.5% KIXS-AS-KR Korea Telecom AS2118 1401 14 1387 99.0% RELCOM-AS OOO "NPO Relcom" AS10620 2132 785 1347 63.2% Telmex Colombia S.A. AS4323 1582 389 1193 75.4% TWTC - tw telecom holdings, inc. AS7303 1564 451 1113 71.2% Telecom Argentina S.A. AS1785 1914 824 1090 56.9% AS-PAETEC-NET - PaeTec Communications, Inc. AS4755 1618 546 1072 66.3% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7552 1121 207 914 81.5% VIETEL-AS-AP Vietel Corporation AS8151 1570 695 875 55.7% Uninet S.A. de C.V. AS18101 941 157 784 83.3% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1121 354 767 68.4% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS6458 791 42 749 94.7% Telgua AS13977 848 121 727 85.7% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS15557 1221 556 665 54.5% LDCOMNET Societe Francaise du Radiotelephone S.A AS3356 1107 475 632 57.1% LEVEL3 Level 3 Communications AS855 682 52 630 92.4% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS36998 776 146 630 81.2% SDN-MOBITEL AS17676 711 85 626 88.0% GIGAINFRA Softbank BB Corp. AS22561 1034 428 606 58.6% DIGITAL-TELEPORT - Digital Teleport Inc. AS19262 1002 404 598 59.7% VZGNI-TRANSIT - Verizon Online LLC AS24560 1040 442 598 57.5% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS30036 1417 833 584 41.2% MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp AS7545 1752 1182 570 32.5% TPG-INTERNET-AP TPG Internet Pty Ltd AS3549 1001 438 563 56.2% GBLX Global Crossing Ltd. Total 46549 14184 32365 69.5% Top 30 total Possible Bogus Routes 5.226.64.0/18 AS12741 INTERNETIA-AS Netia SA 5.226.136.0/21 AS25369 BANDWIDTH-AS Bandwith Technologies Ltd 5.228.0.0/16 AS42610 NCNET-AS National Cable Networks 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 14.192.0.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.4.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.8.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.12.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.16.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.20.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.24.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.28.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 41.220.80.0/24 AS38925 DAC-AS G.I.T. TELECOM LIMITED 41.220.81.0/24 AS38925 DAC-AS G.I.T. TELECOM LIMITED 41.220.94.0/23 AS42235 IDC-AS Intra Data Communication 41.222.80.0/21 AS37110 moztel-as 41.223.108.0/22 AS36966 EDL_AS Edgenet AS 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.66.32.0/20 AS18864 64.187.208.0/24 AS174 COGENT Cogent/PSI 64.187.209.0/24 AS23005 SWITCH-COMMUNICATIONS - SWITCH Communications Group LLC 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 70.34.112.0/20 AS27589 MOJOHOST - MOJOHOST 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.115.124.0/23 AS46540 74.115.126.0/24 AS11260 EASTLINK-HSI - EastLink 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 109.177.0.0/16 AS5541 ADNET-TELECOM AdNet Telecom 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 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 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.254.254.0/24 AS26274 176.124.148.0/24 AS29518 BREDBAND2 Bredband2 AB 176.124.172.0/22 AS52165 PDSINET Personal Development Systems International SRL 176.124.176.0/21 AS52165 PDSINET Personal Development Systems International SRL 188.114.96.0/20 AS13335 CLOUDFLARENET - CloudFlare, Inc. 192.0.0.0/24 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 198.18.0.0/15 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 198.51.100.0/24 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.6.49.0/24 AS23148 TERREMARK Terremark 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 200.58.248.0/21 AS27849 200.75.184.0/24 AS14754 Telgua 200.75.185.0/24 AS14754 Telgua 200.75.186.0/24 AS14754 Telgua 200.75.187.0/24 AS14754 Telgua 200.75.188.0/24 AS14754 Telgua 200.75.189.0/24 AS14754 Telgua 200.75.190.0/24 AS14754 Telgua 200.75.191.0/24 AS14754 Telgua 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 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.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.151.40.0/21 AS24453 202.151.40.0/24 AS24453 202.151.41.0/24 AS24453 202.151.42.0/24 AS24453 202.151.43.0/24 AS24453 202.151.44.0/24 AS24453 202.151.45.0/24 AS24453 202.151.46.0/24 AS24453 202.151.47.0/24 AS24453 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.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.180.224.0/19 AS1221 ASN-TELSTRA Telstra Pty Ltd 202.180.236.0/24 AS38472 UCMS-AS-AP UCMS 202.180.253.0/24 AS38472 UCMS-AS-AP UCMS 202.180.255.0/24 AS38472 UCMS-AS-AP UCMS 203.0.113.0/24 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 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.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.142.219.0/24 AS45149 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.14.0.0/21 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 204.14.0.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 204.14.2.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 204.14.3.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 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.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.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.93.144.0/21 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 208.93.151.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.205.192.0/19 AS20228 209.205.224.0/20 AS20228 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.21.160.0/20 AS27876 American Data Networks 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.194.160.0/20 AS27876 American Data Networks Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org 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 Sep 7 17:00:02 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 7 Sep 2012 22:00:02 GMT Subject: BGP Update Report Message-ID: <201209072200.q87M02WV017924@wattle.apnic.net> BGP Update Report Interval: 30-Aug-12 -to- 06-Sep-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS6517 143391 6.8% 279.0 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 2 - AS30137 130915 6.2% 2146.1 -- SEA-BROADBAND - Sea Broadband, LLC 3 - AS10198 86716 4.1% 17343.2 -- CUP-AS-KR Catholic University of Pusan 4 - AS8402 43880 2.1% 30.5 -- CORBINA-AS OJSC "Vimpelcom" 5 - AS9829 36108 1.7% 29.2 -- BSNL-NIB National Internet Backbone 6 - AS22561 26219 1.2% 25.1 -- DIGITAL-TELEPORT - Digital Teleport Inc. 7 - AS24560 23941 1.1% 41.9 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 8 - AS13118 20062 1.0% 418.0 -- ASN-YARTELECOM OJSC Rostelecom 9 - AS1637 16835 0.8% 189.2 -- DNIC-AS-01637 - Headquarters, USAISC 10 - AS28238 14083 0.7% 440.1 -- 11 - AS3356 14040 0.7% 12.8 -- LEVEL3 Level 3 Communications 12 - AS25620 11921 0.6% 56.5 -- COTAS LTDA. 13 - AS27947 11885 0.6% 16.5 -- Telconet S.A 14 - AS2697 11748 0.6% 94.0 -- ERX-ERNET-AS Education and Research Network 15 - AS19361 11314 0.5% 332.8 -- Atrium Telecomunicacoes Ltda 16 - AS28573 10642 0.5% 4.9 -- NET Servicos de Comunicao S.A. 17 - AS7029 10532 0.5% 3.0 -- WINDSTREAM - Windstream Communications Inc 18 - AS21599 10127 0.5% 81.7 -- NETDIRECT S.A. 19 - AS5800 9861 0.5% 38.7 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 20 - AS38920 9159 0.4% 4579.5 -- TURKLANDBANK-TR TURKLANDBANK TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS10198 86716 4.1% 17343.2 -- CUP-AS-KR Catholic University of Pusan 2 - AS38920 9159 0.4% 4579.5 -- TURKLANDBANK-TR TURKLANDBANK 3 - AS14680 6671 0.3% 2223.7 -- REALE-6 - Auction.com 4 - AS30137 130915 6.2% 2146.1 -- SEA-BROADBAND - Sea Broadband, LLC 5 - AS44410 5228 0.2% 1742.7 -- ENTEKHAB-AS ENTEKHAB INDUSTRIAL GROUP 6 - AS38857 1596 0.1% 1596.0 -- ESOFT-TRANSIT-AS-AP e.Soft Technologies Ltd. 7 - AS36948 3143 0.1% 1571.5 -- KENIC 8 - AS6629 8923 0.4% 1274.7 -- NOAA-AS - NOAA 9 - AS13178 4286 0.2% 1071.5 -- DIGCOMM Digital communications, LTD 10 - AS41733 8324 0.4% 1040.5 -- ZTELECOM-AS JSC "Z-Telecom" 11 - AS29126 881 0.0% 881.0 -- DATIQ-AS Datiq B.V. 12 - AS46620 768 0.0% 768.0 -- WBH-ISC-RO - William Beaumont Hospital 13 - AS25715 1414 0.1% 707.0 -- UREACH-C - UREACH TECHNOLOGIES, INC. 14 - AS29398 503 0.0% 503.0 -- PETROBALTIC "Petrobaltic" S.A. 15 - AS32529 493 0.0% 493.0 -- CGI-FEDERAL-ASN-1 - CGI Federal 16 - AS56763 474 0.0% 474.0 -- INFOTELL-AS Infotell-Telecom Ltd 17 - AS28238 14083 0.7% 440.1 -- 18 - AS48696 436 0.0% 436.0 -- TEMP-AS TEMP Ltd. 19 - AS21023 432 0.0% 432.0 -- UPB-AS Joint Stock Company Ural Industrial Bank 20 - AS13118 20062 1.0% 418.0 -- ASN-YARTELECOM OJSC Rostelecom TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/19 20015 0.9% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 110.9.62.0/23 17942 0.8% AS10198 -- CUP-AS-KR Catholic University of Pusan 3 - 110.9.64.0/23 17935 0.8% AS10198 -- CUP-AS-KR Catholic University of Pusan 4 - 110.9.61.0/24 17935 0.8% AS10198 -- CUP-AS-KR Catholic University of Pusan 5 - 203.232.208.0/21 16455 0.7% AS10198 -- CUP-AS-KR Catholic University of Pusan 6 - 210.93.62.0/23 16449 0.7% AS10198 -- CUP-AS-KR Catholic University of Pusan 7 - 184.159.130.0/23 13806 0.6% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. 8 - 199.250.214.0/24 11293 0.5% AS6517 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 9 - 199.250.206.0/24 11291 0.5% AS6517 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 10 - 199.250.213.0/24 11290 0.5% AS6517 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 11 - 199.250.204.0/24 11289 0.5% AS6517 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 12 - 199.250.215.0/24 11289 0.5% AS6517 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 13 - 199.250.207.0/24 11289 0.5% AS6517 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 14 - 199.250.195.0/24 11288 0.5% AS6517 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 15 - 199.250.205.0/24 11286 0.5% AS6517 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 16 - 199.250.193.0/24 11283 0.5% AS6517 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 17 - 199.250.192.0/24 11283 0.5% AS6517 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 18 - 199.250.212.0/24 11258 0.5% AS6517 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 19 - 184.157.224.0/19 10921 0.5% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. 20 - 74.91.60.0/24 10908 0.5% AS30137 -- SEA-BROADBAND - Sea Broadband, LLC Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From richard.barnes at gmail.com Fri Sep 7 17:51:34 2012 From: richard.barnes at gmail.com (Richard Barnes) Date: Fri, 7 Sep 2012 18:51:34 -0400 Subject: CAIDA's AS-rank project In-Reply-To: <504927BD.4090702@caida.org> References: <504927BD.4090702@caida.org> Message-ID: No IPv6? On Thu, Sep 6, 2012 at 6:46 PM, Matthew Luckie wrote: > Hello, > > We have been working on refreshing the data and algorithms behind CAIDA's > as-rank project. We have published AS-relationships and AS-rankings > computed for June 2012. We are currently seeking further validation of our > rankings and relationship inferences. > > http://as-rank.caida.org/ > > The core of the algorithm is the inference of business relationships. Over > the past two years we have received a significant amount of ground truth > from operators through the corrections facility provided within AS-rank: in > particular we obtained >1200 p2p relationships as a result of our previous > algorithm that assigned many more customer/provider (c2p) relationships than > ASes had in reality. Our intuition is that network owners are a lot more > concerned when we infer a provider relationship that is actually a peer > relationship, but are less motivated to validate other inferences. > > We have validated our algorithm against available ground truth and find our > relationship inferences have a 99.1% positive predictive value (PPV) for c2p > and 94.7% for p2p for the validation data we have available. Because > customer cone computation depends on the accuracy of our c2p inferences, we > are reasonably confident in our computed rankings. > > We are now soliciting further feedback in any shape and form offered. The > as-rank website provides the ability for operators to submit corrections > through the right-most "corrections" button on an individual ASes > information page, and relationships ground-truth is solicited through that > channel, if at all possible. Other feedback, on or off-list, would also be > appreciated. > > If you are curious as to why a particular relationship was inferred, please > get in contact with me. Some ASes have advised of a particular business > relationship in the past, but when I drill down into the data it turns out > they have a misconfiguration and are leaking routes to a peer. At a > minimum, this might be a useful sanity check for some ASes who may be > providing free transit without realising it. In the future, we plan to > annotate each relationship with examples as to why it was inferred the way > it was, but we have not yet got that far yet. > > Thanks, > > Matthew Luckie > CAIDA > From basilbaby at gmail.com Fri Sep 7 19:22:29 2012 From: basilbaby at gmail.com (Basil Baby) Date: Fri, 7 Sep 2012 20:22:29 -0400 Subject: time-b.netgear.com/time-c.netgear.com dns queries Message-ID: Noticed lot of "A" record queries for time-b.netgear.com/time-c.netgear.comon dns servers. Has anyone noticed similar behavior on any of your dns servers? Anyone aware about a known issue with netgear home routers which can create bulk dns queries? -Basil From gem at rellim.com Fri Sep 7 19:30:04 2012 From: gem at rellim.com (Gary E. Miller) Date: Fri, 7 Sep 2012 17:30:04 -0700 Subject: time-b.netgear.com/time-c.netgear.com dns queries In-Reply-To: References: Message-ID: <20120907173004.31e0746d.gem@rellim.com> Yo Basil! On Fri, 7 Sep 2012 20:22:29 -0400 Basil Baby wrote: > Noticed lot of "A" record queries for > time-b.netgear.com/time-c.netgear.comon dns servers. > Has anyone noticed similar behavior on any of your dns servers? Anyone > aware about a known issue with netgear home routers which can create > bulk dns queries? https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse#NETGEAR_and_the_University_of_Wisconsin.E2.80.93Madison RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From basilbaby at gmail.com Fri Sep 7 19:44:44 2012 From: basilbaby at gmail.com (Basil Baby) Date: Fri, 7 Sep 2012 20:44:44 -0400 Subject: time-b.netgear.com/time-c.netgear.com dns queries In-Reply-To: <20120907173004.31e0746d.gem@rellim.com> References: <20120907173004.31e0746d.gem@rellim.com> Message-ID: Hmm... Even though similar issue was identified in 2003, looks like still there are devices in market with those old firmwares or similar behavior. sheesh !! :( -Basil On Fri, Sep 7, 2012 at 8:30 PM, Gary E. Miller wrote: > Yo Basil! > > On Fri, 7 Sep 2012 20:22:29 -0400 > Basil Baby wrote: > > > Noticed lot of "A" record queries for > > time-b.netgear.com/time-c.netgear.comon dns servers. > > Has anyone noticed similar behavior on any of your dns servers? Anyone > > aware about a known issue with netgear home routers which can create > > bulk dns queries? > > > https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse#NETGEAR_and_the_University_of_Wisconsin.E2.80.93Madison > > > RGDS > GARY > --------------------------------------------------------------------------- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 > gem at rellim.com Tel:+1(541)382-8588 > From ryan at u13.net Fri Sep 7 19:46:44 2012 From: ryan at u13.net (Ryan Rawdon) Date: Fri, 7 Sep 2012 19:46:44 -0500 Subject: time-b.netgear.com/time-c.netgear.com dns queries In-Reply-To: References: <20120907173004.31e0746d.gem@rellim.com> Message-ID: <66D0A293-FB60-46D2-A1F7-384A691574FA@u13.net> On Sep 7, 2012, at 7:44 PM, Basil Baby wrote: > Hmm... Even though similar issue was identified in 2003, looks like still > there are devices in market with those old firmwares or similar > behavior. sheesh !! :( > > -Basil While NETGEAR does have a history of issues like this, the UofW issue is likely not related to what you are seeing - that issue stemmed from them not using DNS and hardcoding the university's NTP server. The issue you are seeing seems to stem from their NTP code doing the Wrong Thing nonetheless... > > > On Fri, Sep 7, 2012 at 8:30 PM, Gary E. Miller wrote: > >> Yo Basil! >> >> On Fri, 7 Sep 2012 20:22:29 -0400 >> Basil Baby wrote: >> >>> Noticed lot of "A" record queries for >>> time-b.netgear.com/time-c.netgear.comon dns servers. >>> Has anyone noticed similar behavior on any of your dns servers? Anyone >>> aware about a known issue with netgear home routers which can create >>> bulk dns queries? >> >> >> https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse#NETGEAR_and_the_University_of_Wisconsin.E2.80.93Madison >> >> >> RGDS >> GARY >> --------------------------------------------------------------------------- >> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 >> gem at rellim.com Tel:+1(541)382-8588 >> From valdis.kletnieks at vt.edu Fri Sep 7 20:36:01 2012 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Fri, 07 Sep 2012 21:36:01 -0400 Subject: time-b.netgear.com/time-c.netgear.com dns queries In-Reply-To: Your message of "Fri, 07 Sep 2012 20:44:44 -0400." References: <20120907173004.31e0746d.gem@rellim.com> Message-ID: <23863.1347068161@turing-police.cc.vt.edu> On Fri, 07 Sep 2012 20:44:44 -0400, Basil Baby said: > Hmm... Even though similar issue was identified in 2003, looks like still > there are devices in market with those old firmwares or similar > behavior. sheesh !! :( A long long time ago in a network far far away, one of our campus NTP servers was a machine under my desk. That machine was shut down around 2002/06/30 22:49 and we didn't re-assign the IP address ever since *because* it kept getting hit with NTP packets.. Yes, a decade ago. A few months ago I ran a test of how many things were still using it. In the first 15 minutes, 234 different IP's tried to NTP to that address, which has been a black hole for a decade. After 3 hours, I had almost 2,000 IPs. Interestingly enough, the *hostname* is still in use (by another machine under my desk) - and it gets near zero hits. So it's all hardcoded IP addrs not hostnames. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From mloftis at wgops.com Fri Sep 7 21:00:37 2012 From: mloftis at wgops.com (Michael Loftis) Date: Fri, 7 Sep 2012 20:00:37 -0600 Subject: time-b.netgear.com/time-c.netgear.com dns queries In-Reply-To: <23863.1347068161@turing-police.cc.vt.edu> References: <20120907173004.31e0746d.gem@rellim.com> <23863.1347068161@turing-police.cc.vt.edu> Message-ID: On Fri, Sep 7, 2012 at 7:36 PM, wrote: .... > Interestingly enough, the *hostname* is still in use (by another machine under > my desk) - and it gets near zero hits. So it's all hardcoded IP addrs not > hostnames. And for NTP implementations that use DNS they also often only check DNS on startup too...and lots of people do not maintain their servers...well, except netgear, which just hammers the bugger out of everything (See OP) -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From rsk at gsp.org Sat Sep 8 06:45:45 2012 From: rsk at gsp.org (Rich Kulawiec) Date: Sat, 8 Sep 2012 07:45:45 -0400 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <12090514150728_530@oregon.uoregon.edu> References: <12090514150728_530@oregon.uoregon.edu> Message-ID: <20120908114545.GA27635@gsp.org> On Wed, Sep 05, 2012 at 02:15:07PM -0700, Joe St Sauver wrote: > 2) The Spamhaus CBL tracks the level of bot spam currently seen, > including breaking out statistics by a number of factors. > > 3) Currently, the US, where port 25 filtering is routinely deployed by > most large ISPs, is ranked 158th among countries when you consider botted > users on a per capita basis: http://cbl.abuseat.org/countrypercapita.html > > 4) While that's not perfect (after all, there are still at least 133,811 > listings for the US), on a PER-CAPITA basis, it's not bad -- that's just > ~0.055% of US Internet users that are infected, relative to some countries > where the rate of detected infection (based on spam emission) may be 4 to > 5% or more. I don't believe those numbers say that last. I *wish* those numbers said that, but I don't think they do. Here's why. A. "bot spam seen" (by whatever number of sensors are deployed) is conditional on bot spam making it out of its local network and onto some other network where is sensor exists. Clearly, port 25 blocking will dramatically curtail that. Thus, spam is still being generated by those systems: it's just not getting anywhere. B. Spam is not the only form of abuse generated by bots. Some participate in DDoS attacks, some host illicit web sites, some harvest addresses, the list is endless. Any sensor which only looks for spam arriving via SMTP on port 25 will miss all those. C. Some bots engage in secondary support activities (e.g., hosting DNS for spammer domains) which is not intrinsicly abusive, but is certainly abusive in context. Most of this will be missed by most of everything and everyone. D. Some bots do nothing -- that is, nothing overtly recognizable by external sensors of any kind at any location. They're either harvesting local data or perhaps they're simply being held in reserve, a practice our adversaries adopted quite early on. Thus we can't use anybody's numbers for observed bot-generated spam to estimate infection rates -- other than to set a lower bound on them. The upper bound can be, and like likely is, MUCH higher. Doubly so because there is abolutely no reason of any kind to think that infection rates of US-based hosts significantly differ from global norms. More broadly, the per-nation rates are interesting but probably unimportant: this is a global problem, so even if country X solved it (for a useful value of "solved") it would matter little. I think at this point any estimate of bot population under 200M should be laughed out of the room, and that (just as it has for a decade) it continues to monotonically increase. ---rsk From plosher at isc.org Sat Sep 8 17:54:10 2012 From: plosher at isc.org (Peter Losher) Date: Sat, 8 Sep 2012 15:54:10 -0700 Subject: "Circuit of the americas" aka COTA In-Reply-To: References: Message-ID: On Aug 29, 2012, at 5:00 PM, Chris McDonald wrote: > Trendy name for the new racetrack/event venue outside austin. > > Does anyone know how one might get connectivity there? I figure there > must be a few folks here prepping the place for the upcoming formula > 1. > > The place seems to be a black hole to all the usual suspects. Since AS6453 is the official connectivity/technology sponsor for FOM, I suspect they will be leasing some dark fiber to COTA for the F1 race. Some of the F1 teams have their own telecom sponsors (Vodafone McLaren, etc) which will be doing the same. Don't know who would be pulling the actual fiber though... BTW - I will be there for the race as well (went to all the USGP races at IMS) - perhaps a NANOG meetup may be in order? Best Wishes - Peter -- [ plosher at isc.org | Senior Operations Architect | ISC | PGP E8048D08 ] From mailinglists at expresswebsystems.com Sat Sep 8 18:37:43 2012 From: mailinglists at expresswebsystems.com (Tom Walsh - EWS) Date: Sat, 8 Sep 2012 18:37:43 -0500 Subject: "Circuit of the americas" aka COTA In-Reply-To: References: Message-ID: <000d01cd8e1a$f28f64b0$d7ae2e10$@com> > Since AS6453 is the official connectivity/technology sponsor for FOM, I > suspect they will be leasing some dark fiber to COTA for the F1 race. > Some of the F1 teams have their own telecom sponsors (Vodafone McLaren, > etc) which will be doing the same. Don't know who would be pulling the > actual fiber though... > >From what I was told from talking to the on-site IT guy for Caterham, all teams are provide an MPLS connection back to their respective factory. I seem to recall was an insanely small connection for what is the "pinnacle of motorsports"... something like 4mbit or so. Admittedly this was input from only one team, and a "lower tier" team at that. This was also last year (2011). I remember being distinctly surprised at the relatively low amount of bandwidth they were provided at the track. Tom Walsh From mansaxel at besserwisser.org Sat Sep 8 23:45:39 2012 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Sun, 9 Sep 2012 06:45:39 +0200 Subject: Are people still building SONET networks from scratch? In-Reply-To: <5049ED97.2050701@studio442.com.au> References: <20120906163812.GA9934@loopfree.net> <5049ED97.2050701@studio442.com.au> Message-ID: <20120909044539.GD24232@besserwisser.org> Subject: Re: Are people still building SONET networks from scratch? Date: Fri, Sep 07, 2012 at 10:50:31PM +1000 Quoting Julien Goodwin (nanog at studio442.com.au): > > A few of the engineers at $DAYJOB still try and claim SONET is easier to > troubleshoot, but that hasn't been my practical experience. > > With ethernet it's something like: > - Layer 1 - light levels (DoM on nearly everything) > - Layer 1 - link pulse > - Layer 2 - can I send frames > > SONET it's, in practice: > - Layer 1 - light levels (DoM on newer kit, SOL on older) > - Layer 2 - Seemingly random collection of alarms > - Layer 2 - Is PPP up? Just the fact that BFD had to be reinvented shows that there is ample reason to prefer the steady-train-of-frames-with-status of SONET/SDH over perhaps-nobody-sent-a-packet-or-the-line-is-dead quagmire of Ethernet -- I have run pretty large (for sweden) networks over SDH (POS linecards on top of waves, not a full SDH system) and essentially similar networks as GE over waves, and I truly prefer the failure modes and analysis tools in SDH to the guesswork and afterthought patches of alohanet.. Still, the stupid f?%&?/# that make prices for linecards made me go GE instead of OC48 for the most recent deployment. In Sweden, both vendors claim about 6 times as much, per megabit, for SDH line cards. This can't really make sense. > As others have said doing a "diverse 1/10g ethernet" quote and a > "protected SONET" quote may be worthwhile, and adding a 20% pad to the > SONET one for staff training may also be perfectly justifiable. Maybe training is more expensive (it takes some CPU to parse SLOF/SLOS and PLOP etc) but it leads to lower OPEX since the "Maybe" factor is essentially gone. Operationally it is quite worthwhile to say "I have SLOS in my far end, which means somebody pulled a patch worngly in your just terminated maintenance window." instead of "The line is dead, can you please check something?" to your circuit provider. Yeah, SDH and similar probably will die, but cheap aint good. Only. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Is this going to involve RAW human ecstasy? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From mysidia at gmail.com Sun Sep 9 01:15:35 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 9 Sep 2012 01:15:35 -0500 Subject: Are people still building SONET networks from scratch? In-Reply-To: <20120909044539.GD24232@besserwisser.org> References: <20120906163812.GA9934@loopfree.net> <5049ED97.2050701@studio442.com.au> <20120909044539.GD24232@besserwisser.org> Message-ID: On 9/8/12, M?ns Nilsson wrote: > Subject: Re: Are people still building SONET networks from scratch? Date: > Just the fact that BFD had to be reinvented shows that there is ample > reason to prefer the steady-train-of-frames-with-status of SONET/SDH over > perhaps-nobody-sent-a-packet-or-the-line-is-dead quagmire of Ethernet -- Not all Ethernet switching implementations are necessarily equal; there are 802.3ah OA&M and 802.1ag connectivity fault management / Loopback (MAC ping) / Continuity Check Protocol / Link Trace. (Which aren't much use without management software, however.) There /are/ reasons to prefer SONET for certain networks or applications; so it might (or might not) be a reasonable requirement, it just depends. Price is not one of those reasons; all the added complexity and use of less common equipment has some major costs, not to mention risks, involved if mixing many different service providers' products. SONET comes at a massive price premium per port and switching table entry on hardware modules that are much more expensive than 10g switches, and providers often charge a big premium regardless... Therefore; it is not the least bit surprising that a 10g wave would be massively less expensive in many cases than an OC3 over a long distance between point A and point B. As I see it... if you are thinking of 1000 miles of dark fiber to nowhere to support an OC3, then forget the "wasted" capacity; the cost of all that dark fiber needed just for them should get added to the customer's price quote for the OC3. Same deal if instead you need an OC48 at various hops to actually carry that OC3 and be able to end-to-end and tunnel the DCC bytes over IP or restrict equipment choices so you can achieve that D1-12 byte transparency.... -- -JH From mansaxel at besserwisser.org Sun Sep 9 01:55:15 2012 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Sun, 9 Sep 2012 08:55:15 +0200 Subject: Are people still building SONET networks from scratch? In-Reply-To: References: <20120906163812.GA9934@loopfree.net> <5049ED97.2050701@studio442.com.au> <20120909044539.GD24232@besserwisser.org> Message-ID: <20120909065515.GE24232@besserwisser.org> Subject: Re: Are people still building SONET networks from scratch? Date: Sun, Sep 09, 2012 at 01:15:35AM -0500 Quoting Jimmy Hess (mysidia at gmail.com): > On 9/8/12, M?ns Nilsson wrote: > > Subject: Re: Are people still building SONET networks from scratch? Date: > > Just the fact that BFD had to be reinvented shows that there is ample > > reason to prefer the steady-train-of-frames-with-status of SONET/SDH over > > perhaps-nobody-sent-a-packet-or-the-line-is-dead quagmire of Ethernet -- > > Not all Ethernet switching implementations are necessarily equal; > there are 802.3ah OA&M and 802.1ag connectivity fault management / > Loopback (MAC ping) / Continuity Check Protocol / Link Trace. (Which > aren't much use without management software, however.) Of course. > There /are/ reasons to prefer SONET for certain networks or > applications; so it might (or might not) be a reasonable requirement, > it just depends. Yes. > Price is not one of those reasons; all the added complexity and use > of less common equipment has some major costs, not to mention risks, > involved if mixing many different service providers' products. SONET > comes at a massive price premium per port and switching table entry on > hardware modules that are much more expensive than 10g switches, and > providers often charge a big premium regardless... Yes. The 6x difference I alluded to was a comparison of line cards for OC192 and 10GE on major league routers, like CRS or T-series. Most of the bits are the same, yet the price \delta is insane. > Therefore; it is not the least bit surprising that a 10g wave would be > massively less expensive in many cases than an OC3 over a long > distance between point A and point B. Especially since it might be possible to get it provisioneed e2e. > As I see it... if you are thinking of 1000 miles of dark fiber to > nowhere to support an OC3, then forget the "wasted" capacity; the > cost of all that dark fiber needed just for them should get added to > the customer's price quote for the OC3. Yup. > Same deal if instead you need an OC48 at various hops to actually > carry that OC3 and be able to end-to-end and tunnel the DCC bytes over > IP or restrict equipment choices so you can achieve that D1-12 byte > transparency.... I'm a simple man. I just want the bitpipe to do IP over. It so happens that the combined engineering of the telco business made for a nice set of signalling bells and whistles that tend to work well on long point-to-point circuits. If not perfectly well, then at least orders of magnitude better than a protocol that was designed to sometimes convey frames over one nautical mile of yellow coax. Then again, the yellow coax has evolved, significantly. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Didn't I buy a 1951 Packard from you last March in Cairo? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From swmike at swm.pp.se Sun Sep 9 02:31:24 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 9 Sep 2012 09:31:24 +0200 (CEST) Subject: Are people still building SONET networks from scratch? In-Reply-To: <20120909044539.GD24232@besserwisser.org> References: <20120906163812.GA9934@loopfree.net> <5049ED97.2050701@studio442.com.au> <20120909044539.GD24232@besserwisser.org> Message-ID: On Sun, 9 Sep 2012, M?ns Nilsson wrote: > Still, the stupid f?%&?/# that make prices for linecards made me go GE > instead of OC48 for the most recent deployment. In Sweden, both vendors > claim about 6 times as much, per megabit, for SDH line cards. The "once-in-a-lifetime" that happened here (took a while though) was WAN PHY for 10GE. All the benefit of SDH at Ethernet cost. When I approached the 40GE/100GE working group about getting a few of the benefits of this into that standard, I was instantly shut down by people who thought WAN PHY was a huge mistake that shouldn't be repeated. The only thing I wanted was to have frames sent all the times so one would get a basic bit error reading, plus having the PHY send some basic information such as "I am seeing light and my world looks ok", so we could get PHY based interface-down when there was a fiber cut. But that wasn't to be, so the only way to get this will be to OTN-frame the whole thing I guess. *sigh* -- Mikael Abrahamsson email: swmike at swm.pp.se From rs at seastrom.com Sun Sep 9 10:20:40 2012 From: rs at seastrom.com (Robert E. Seastrom) Date: Sun, 09 Sep 2012 11:20:40 -0400 Subject: Are people still building SONET networks from scratch? In-Reply-To: <20120906181229.GB9934@loopfree.net> (Will Orton's message of "Thu, 6 Sep 2012 11:12:29 -0700") References: <20120906163812.GA9934@loopfree.net> <5048D6B5.7020202@foobar.org> <20120906181229.GB9934@loopfree.net> Message-ID: <867gs3b4tz.fsf@seastrom.com> Will Orton writes: > I've considered using J's PE-4CHOC3-CE-SFP (OC3 emulated SAToP), then I > could do it all with gig-e underneath. Does anyone make a cheaper OC3 > circuit emulation module or box? Most likely the customer wouldn't believe > such a thing is possible and we'd have to put something in the contract > allowing them SLA credit if their OC3 suffers too many timing slips or > something. And so you find yourself at the intersection of two timeless maxims: 1) The customer is always right, but not everyone needs to be our customer. 2) Don't say no to the customer, let the customer say no thanks. Time to model the cost/benefit/profit margin of having these folks as a customer at all (I'd imagine that this circuit is not the only thing that they buy from you or you'd be running away even today). What are your engineering costs for this trick? Are you passing that on to the customer? You may find it advantageous to do a pricing model where you do circuit emulation on a hope-for-the-best basis and count on a maximum SLA payout every month (and still make money). Then if you fail to pay SLA credits from time to time, that's pure gravy. -r From danshtr at gmail.com Sun Sep 9 12:01:57 2012 From: danshtr at gmail.com (Dan Shechter) Date: Sun, 9 Sep 2012 20:01:57 +0300 Subject: Are people still building SONET networks from scratch? In-Reply-To: <867gs3b4tz.fsf@seastrom.com> References: <20120906163812.GA9934@loopfree.net> <5048D6B5.7020202@foobar.org> <20120906181229.GB9934@loopfree.net> <867gs3b4tz.fsf@seastrom.com> Message-ID: OT, what is the _expected_ latency on each hop/ADM in the SDH/SONET network? HTH, Dan #13685 (RS/Sec/SP) The CCIE troubleshooting blog: http://dans-net.com Bring order to your Private VLAN network: http://marathon-networks.com On Sun, Sep 9, 2012 at 6:20 PM, Robert E. Seastrom wrote: > > > Will Orton writes: > > > I've considered using J's PE-4CHOC3-CE-SFP (OC3 emulated SAToP), then I > > could do it all with gig-e underneath. Does anyone make a cheaper OC3 > > circuit emulation module or box? Most likely the customer wouldn't believe > > such a thing is possible and we'd have to put something in the contract > > allowing them SLA credit if their OC3 suffers too many timing slips or > > something. > > And so you find yourself at the intersection of two timeless maxims: > > 1) The customer is always right, but not everyone needs to be our customer. > > 2) Don't say no to the customer, let the customer say no thanks. > > Time to model the cost/benefit/profit margin of having these folks as > a customer at all (I'd imagine that this circuit is not the only thing > that they buy from you or you'd be running away even today). What are > your engineering costs for this trick? Are you passing that on to the > customer? > > You may find it advantageous to do a pricing model where you do > circuit emulation on a hope-for-the-best basis and count on a maximum > SLA payout every month (and still make money). Then if you fail to > pay SLA credits from time to time, that's pure gravy. > > -r > > > From mohta at necom830.hpcl.titech.ac.jp Sun Sep 9 17:24:38 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 10 Sep 2012 07:24:38 +0900 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <1375033.GM90FNPWn2@gentoovm> References: <1398646.nogpiQX5tj@gentoovm> <504992E2.4080305@necom830.hpcl.titech.ac.jp> <1375033.GM90FNPWn2@gentoovm> Message-ID: <504D1726.3090608@necom830.hpcl.titech.ac.jp> Oliver wrote: >>> You're basically redefining the term "end-to-end transparency" to suit >>> your own >> Already in RFC3102, which restrict port number ranges, it is >> stated that: >> >> This document examines the general framework of Realm Specific IP >> (RSIP). RSIP is intended as a alternative to NAT in which the end- >> to-end integrity of packets is maintained. We focus on >> implementation issues, deployment scenarios, and interaction with >> other layer-three protocols. > > Just because something is documented in RFC does not automatically make it a > standard, nor does it necessarily make anyone care. That's not a valid argument against text in the RFC proof read by the RFC editor as the evidence of established terminology of the Internet community. >> It's you who tries to change the meaning of "end to end transparency". > Denial: not just a river in Egypt. Invalid denial. Masataka Ohta From nick at foobar.org Mon Sep 10 08:14:50 2012 From: nick at foobar.org (Nick Hilliard) Date: Mon, 10 Sep 2012 14:14:50 +0100 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <504D1726.3090608@necom830.hpcl.titech.ac.jp> References: <1398646.nogpiQX5tj@gentoovm> <504992E2.4080305@necom830.hpcl.titech.ac.jp> <1375033.GM90FNPWn2@gentoovm> <504D1726.3090608@necom830.hpcl.titech.ac.jp> Message-ID: <504DE7CA.80803@foobar.org> On 09/09/2012 23:24, Masataka Ohta wrote: > Oliver wrote: >> Just because something is documented in RFC does not automatically make it a >> standard, nor does it necessarily make anyone care. > > That's not a valid argument against text in the RFC proof read by > the RFC editor as the evidence of established terminology of the > Internet community. you may want to read rfc 1796, and then retract what you said because it sounds silly. Nick From dmburgess at linktechs.net Mon Sep 10 12:14:06 2012 From: dmburgess at linktechs.net (Dennis Burgess) Date: Mon, 10 Sep 2012 12:14:06 -0500 Subject: [SPAM]BGP Issue with L3? Message-ID: <50710E9A7E64454C974049FC998EB65568153A@03-exchange.lti.local> Doing a looking glass from the locally connected BGP peer for AS 16843, they are receiving it, the top path, but showing it received-only, and they want to use the "prepended" Path. The rest of L3, outside the local peer looking glass, i.e. the rest of the planet does not even show this path ? Thoughts suggestions? Dennis Paths: (3 available, best #3) 23077 174 7843 11427 16843, (received-only) AS-path translation: { SUNCOM COGENT ADELPHIA SCRR-11427 NORTHEAST-COMNET } WIRELESS-ME.car1.Houston1 from WIRELESS-ME.car1.Houston1 (8.24.196.1) Origin IGP, localpref 100, valid, external Community: 174:21000 174:22013 3549 3491 7459 16843 16843 16843 16843 16843 16843 16843 AS-path translation: { GBLX CAIS-ASN THRIFTYCALL NORTHEAST-COMNET NORTHEAST-COMNET NORTHEAST-COMNET NORTHEAST-COMNET NORTHEAST-COMNET NORTHEAST-COMNET NORTHEAST-COMNET } edge4.Dallas3 (metric 3827) Origin IGP, metric 100000, localpref 88, valid, internal Community: North_America Lclprf_86 United_States Level3_Peer Dallas 3491:200 3549:300 3549:4292 3549:30840 Originator: edge4.Dallas3 3549 3491 7459 16843 16843 16843 16843 16843 16843 16843 AS-path translation: { GBLX CAIS-ASN THRIFTYCALL NORTHEAST-COMNET NORTHEAST-COMNET NORTHEAST-COMNET NORTHEAST-COMNET NORTHEAST-COMNET NORTHEAST-COMNET NORTHEAST-COMNET } edge4.Dallas3 (metric 3827) Origin IGP, metric 100000, localpref 88, valid, internal, best Community: North_America Lclprf_86 United_States Level3_Peer Dallas 3491:200 3549:300 3549:4292 3549:30840 Originator: edge4.Dallas3 From davidpeahi at gmail.com Mon Sep 10 12:55:26 2012 From: davidpeahi at gmail.com (david peahi) Date: Mon, 10 Sep 2012 10:55:26 -0700 Subject: Are people still building SONET networks from scratch? In-Reply-To: <20120906163812.GA9934@loopfree.net> References: <20120906163812.GA9934@loopfree.net> Message-ID: In my neck of the woods, critical locations often exist "in the middle of nowhere", resulting in underserved facilities, where best effort networks such as metro Ethernet cannot be trusted to remain available 24x7x365. Many times, during prime business hours, I will see a telco metro Ethernet spanning tree convergence which results in my traffic re-routing for 20-30 seconds over my private backup network path, then switching back to the metro Ethernet path after the telco technicians have finished their maintenance. Several times when I have called in a trouble ticket, the telco tech has asked "what is the big deal, it was only a 20 second outage?". In the Enterprise environment, a planned spanning tree convergence in the middle of business hours is one of the quickest ways for a network engineer to be relieved of their duties, but apparently the bar is considerably lower in the telco environment. Not only that, but the telco SLAs associated with metro Ethernet are totally bogus, with a best round trip SLA of 20 milliseconds, ranging up to 50 milliseconds for "bronze" service. For short distances of 100 miles or less (rule of thumb is that light travels over fiber at 0.80 x speed of light, or 1000 miles in 10 milliseconds), an SLA of 20-50 milliseconds amounts to fraud, just another way for the telcos to scam the consumer. The tone of many of the entries on this thread where the user is depicted as being unreasonable, underscores the need for a coordinated national broadband policy in the USA, based upon the Australian model in which the government is building out fiber to every residence and business, no matter where they are located. Regards, David On Thu, Sep 6, 2012 at 9:38 AM, Will Orton wrote: > We've run into an issue with a customer that has been confounding us for a > few > months as we try to design what they need. > > The customer has a location in the relative middle of nowhere that they are > trying to build a protected OC3 to. Ultimately, their traffic on it will be > packet data (IP/ethernet, not channelized/voice). But they seem to be > absolutely 100% set on the idea that they build with Cisco ONS boxes and > that > they run and control the D1-D12 bytes in order to manage protection > switching > on the OC3 (and have their DCC channel for management). > > Since this is the middle of nowhere, we are having to piece it together > from a > few runs of dark fiber here and there and lit services from about 3 other > providers to get from the desired point A to the desired point B. The > issues > we seem to be hitting are: > > -We seem to be unable to find anyone who sells lit OC3 with D1-D12 > transparency for the client. Sometimes we can get D1-D3, but that's it. > > -lit OC3/12/48 is ridiculously expensive comapred to 1g ethernet waves or > 10g > waves (choice LAN/WAN ethernet or OC192) > > 10g waves are cheap enough that we have entertained the idea of buying > them and > putting OC-192/muxponders on the ends to provide the OC-3, but even then > I'm > having trouble finding boxes that will do D1-D12 transparency for client > OC-3. > Building the whole thing on dark fiber so that we could specify the exact > equipment on every hop isn't going to happen, as the "protect" path is > about > 1000 miles and the geography is such that we don't really have a market > for all > the other wasted capacity there would be on that path. > > Having much more experience with ethernet/packet/MPLS setups, we are > trying to > get the client to admit that 1g/10g waves running ethernet with QoS would > be as > good as or better in terms of latency, jitter, and loss for their packet > data. > So far they will barely listen to the arguments. And then going the next > leap > and showing them that we could work towards <50ms protection switching with > MPLS/BFD/etc packet-based protocols is another stretch. > > > Am I missing something here that my customer isn't, or is it the other way > around? > > -Will > > From aaron at heyaaron.com Mon Sep 10 13:07:28 2012 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Mon, 10 Sep 2012 11:07:28 -0700 Subject: Heads-Up: GoDaddy Broke the Interwebs... Message-ID: For the last ~15 minutes I've been receiving complaints about DNS issues. GoDaddy DNS is apparently b0rked. I'm also seeing a lot of tweets about their hosting and VPS being down. I'm unable to access the control panel for one of my customer accounts. -A From derek at derekivey.com Mon Sep 10 13:10:01 2012 From: derek at derekivey.com (Derek Ivey) Date: Mon, 10 Sep 2012 14:10:01 -0400 Subject: Heads-Up: GoDaddy Broke the Interwebs... In-Reply-To: References: Message-ID: Wow. Their own site is even down. On Sep 10, 2012, at 2:07 PM, "Aaron C. de Bruyn" wrote: > For the last ~15 minutes I've been receiving complaints about DNS > issues. GoDaddy DNS is apparently b0rked. I'm also seeing a lot of > tweets about their hosting and VPS being down. I'm unable to access > the control panel for one of my customer accounts. > > > -A > From tknchris at gmail.com Mon Sep 10 13:12:14 2012 From: tknchris at gmail.com (chris) Date: Mon, 10 Sep 2012 14:12:14 -0400 Subject: Heads-Up: GoDaddy Broke the Interwebs... In-Reply-To: References: Message-ID: On Mon, Sep 10, 2012 at 2:07 PM, Aaron C. de Bruyn wrote: > For the last ~15 minutes I've been receiving complaints about DNS > issues. GoDaddy DNS is apparently b0rked. I'm also seeing a lot of > tweets about their hosting and VPS being down. I'm unable to access > the control panel for one of my customer accounts. > > > -A > > This is already being covered on outages list seems be very widespread From Bill.Ingrum at t-systems.com Mon Sep 10 14:13:27 2012 From: Bill.Ingrum at t-systems.com (Bill.Ingrum at t-systems.com) Date: Mon, 10 Sep 2012 15:13:27 -0400 Subject: Heads-Up: GoDaddy Broke the Interwebs... In-Reply-To: References: Message-ID: <972EE2ECC5BFF44CA991510B8EDA469C0FD8B681@S4USJVSYAIC.ts-na.t-systems.com> Looks like this may be a DDoS attack from Anonymous: http://techcrunch.com/2012/09/10/godaddy-outage-takes-down-millions-of-sites/ -----Original Message----- From: Aaron C. de Bruyn [mailto:aaron at heyaaron.com] Sent: Monday, September 10, 2012 1:07 PM To: NANOG mailing list Subject: Heads-Up: GoDaddy Broke the Interwebs... For the last ~15 minutes I've been receiving complaints about DNS issues. GoDaddy DNS is apparently b0rked. I'm also seeing a lot of tweets about their hosting and VPS being down. I'm unable to access the control panel for one of my customer accounts. -A From smeuse at mara.org Mon Sep 10 14:27:20 2012 From: smeuse at mara.org (Steve Meuse) Date: Mon, 10 Sep 2012 15:27:20 -0400 Subject: Heads-Up: GoDaddy Broke the Interwebs... In-Reply-To: <972EE2ECC5BFF44CA991510B8EDA469C0FD8B681@S4USJVSYAIC.ts-na.t-systems.com> References: <972EE2ECC5BFF44CA991510B8EDA469C0FD8B681@S4USJVSYAIC.ts-na.t-systems.com> Message-ID: Of course, it could be a case of Hanlon's Razor. -Steve On Mon, Sep 10, 2012 at 3:13 PM, wrote: > Looks like this may be a DDoS attack from Anonymous: > > > http://techcrunch.com/2012/09/10/godaddy-outage-takes-down-millions-of-sites/ > > > -----Original Message----- > From: Aaron C. de Bruyn [mailto:aaron at heyaaron.com] > Sent: Monday, September 10, 2012 1:07 PM > To: NANOG mailing list > Subject: Heads-Up: GoDaddy Broke the Interwebs... > > For the last ~15 minutes I've been receiving complaints about DNS issues. > GoDaddy DNS is apparently b0rked. I'm also seeing a lot of tweets about > their hosting and VPS being down. I'm unable to access the control panel > for one of my customer accounts. > > > -A > > From me at anuragbhatia.com Mon Sep 10 14:30:32 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Tue, 11 Sep 2012 01:00:32 +0530 Subject: Heads-Up: GoDaddy Broke the Interwebs... In-Reply-To: <972EE2ECC5BFF44CA991510B8EDA469C0FD8B681@S4USJVSYAIC.ts-na.t-systems.com> References: <972EE2ECC5BFF44CA991510B8EDA469C0FD8B681@S4USJVSYAIC.ts-na.t-systems.com> Message-ID: Yeah, I heard about downtime from couple of our clients. Seems like US West coast datacenter has issues specially with DNS. I see DNS working fine in Asia (via Singapore nodes), and in other parts of US as well. Here's a failing DNS node (checking from my Europe test server) traceroute to 216.69.185.46 (216.69.185.46), 30 hops max, 60 byte packets 1 gw.giga-dns.com (91.194.90.1) 1.141 ms 1.134 ms 1.346 ms 2 62.140.24.125 (62.140.24.125) 1.835 ms 1.830 ms 1.820 ms 3 ae-19-19.ebr1.Frankfurt1.Level3.net (4.69.153.246) 6.560 ms 6.560 ms 6.552 ms 4 ae-46-46.ebr2.Paris1.Level3.net (4.69.143.138) 15.286 ms ae-47-47.ebr2.Paris1.Level3.net (4.69.143.142) 15.270 ms ae-45-45.ebr2.Paris1.Level3.net (4.69.143.134) 15.246 ms 5 ae-42-42.ebr2.Washington1.Level3.net (4.69.137.54) 95.934 ms 95.928 ms ae-43-43.ebr2.Washington1.Level3.net (4.69.137.58) 95.820 ms 6 ae-82-82.csw3.Washington1.Level3.net (4.69.134.154) 94.157 ms ae-92-92.csw4.Washington1.Level3.net (4.69.134.158) 96.707 ms 98.696 ms 7 ae-23-70.car3.Washington1.Level3.net (4.69.149.69) 95.490 ms ae-43-90.car3.Washington1.Level3.net (4.69.149.197) 93.731 ms 96.204 ms 8 THE-GO-DADD.car3.Washington1.Level3.net (4.79.168.54) 94.708 ms 97.039 ms 95.756 ms 9 208.109.112.253 (208.109.112.253) 95.244 ms 94.401 ms 94.388 ms 10 208.109.112.253 (208.109.112.253) 94.378 ms 93.864 ms 95.172 ms 11 208.109.113.58 (208.109.113.58) 94.387 ms 94.359 ms 94.042 ms 12 * * * I am very curious to know what prevents Godaddy from withdrawling prefixes from that specific region and let other working datacenters to handle DNS? Can that cause issue on other stable nodes during DOS attack? On Tue, Sep 11, 2012 at 12:43 AM, wrote: > Looks like this may be a DDoS attack from Anonymous: > > > http://techcrunch.com/2012/09/10/godaddy-outage-takes-down-millions-of-sites/ > > > -----Original Message----- > From: Aaron C. de Bruyn [mailto:aaron at heyaaron.com] > Sent: Monday, September 10, 2012 1:07 PM > To: NANOG mailing list > Subject: Heads-Up: GoDaddy Broke the Interwebs... > > For the last ~15 minutes I've been receiving complaints about DNS issues. > GoDaddy DNS is apparently b0rked. I'm also seeing a lot of tweets about > their hosting and VPS being down. I'm unable to access the control panel > for one of my customer accounts. > > > -A > > -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter| Google+ From mpetach at netflight.com Mon Sep 10 15:43:03 2012 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 10 Sep 2012 13:43:03 -0700 Subject: Are people still building SONET networks from scratch? In-Reply-To: References: <20120906163812.GA9934@loopfree.net> Message-ID: This *was* a troll, right...? On Mon, Sep 10, 2012 at 10:55 AM, david peahi wrote: > In my neck of the woods, critical locations often exist "in the middle of > nowhere", resulting in underserved facilities, where best effort networks > such as metro Ethernet cannot be trusted to remain available 24x7x365. Many > times, during prime business hours, I will see a telco metro Ethernet > spanning tree convergence which results in my traffic re-routing for 20-30 > seconds over my private backup network path, then switching back to the > metro Ethernet path after the telco technicians have finished their > maintenance. Several times when I have called in a trouble ticket, the > telco tech has asked "what is the big deal, it was only a 20 second > outage?". In the Enterprise environment, a planned spanning tree > convergence in the middle of business hours is one of the quickest ways for > a network engineer to be relieved of their duties, but apparently the bar > is considerably lower in the telco environment. > Not only that, but the telco SLAs associated with metro Ethernet are > totally bogus, with a best round trip SLA of 20 milliseconds, ranging up to > 50 milliseconds for "bronze" service. For short distances of 100 miles or > less (rule of thumb is that light travels over fiber at 0.80 x speed of > light, or 1000 miles in 10 milliseconds), an SLA of 20-50 milliseconds > amounts to fraud, just another way for the telcos to scam the consumer. > The tone of many of the entries on this thread where the user is depicted > as being unreasonable, underscores the need for a coordinated national > broadband policy in the USA, based upon the Australian model in which the > government is building out fiber to every residence and business, no matter > where they are located. > > Regards, > > David If service is critical enough to me that 20 second hiccups make a difference, I'll find two providers to provide connectivity to the location via relatively cheap waves, and I'll run link-node protection at my layer to get fast reconvergence in the sub-second range. And I'd warrant it'll still come out cheaper than the government-built costs we see in Australia. I really, really don't think more government intervention is the right answer. Matt From mohta at necom830.hpcl.titech.ac.jp Mon Sep 10 15:51:53 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 11 Sep 2012 05:51:53 +0900 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <504DE7CA.80803@foobar.org> References: <1398646.nogpiQX5tj@gentoovm> <504992E2.4080305@necom830.hpcl.titech.ac.jp> <1375033.GM90FNPWn2@gentoovm> <504D1726.3090608@necom830.hpcl.titech.ac.jp> <504DE7CA.80803@foobar.org> Message-ID: <504E52E9.6010102@necom830.hpcl.titech.ac.jp> Nick Hilliard wrote: >>> Just because something is documented in RFC does not automatically make it a >>> standard, nor does it necessarily make anyone care. >> >> That's not a valid argument against text in the RFC proof read by >> the RFC editor as the evidence of established terminology of the >> Internet community. > > you may want to read rfc 1796, and then retract what you said because it > sounds silly. Anything written in RFC1796 should be ignored, because RFC1796, an informational, not standard track, RFC, states so. Or, is it time to retract your silliness? Masataka Ohta From jared at puck.nether.net Mon Sep 10 15:53:00 2012 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 10 Sep 2012 16:53:00 -0400 Subject: Are people still building SONET networks from scratch? In-Reply-To: References: <20120906163812.GA9934@loopfree.net> Message-ID: <9B77477F-D4C0-415F-A0F5-3DA04F2FFD36@puck.nether.net> Matthew, On Sep 10, 2012, at 4:43 PM, Matthew Petach wrote: > This *was* a troll, right?? I suspect it wasn't. There's some people who equate various types of services with others. I've been following this thread with some head-scratching going on. Some folks think "ethernet" can only be a metro solution with STP/RSTP/MSTP/VPLS in the "cloud" of another network. Others realize that saying ethernet as the encoding on the PHY is entirely different. (lan-phy, wan-phy, otu2, otu2e, etc). When it comes to talking "SONET" vs "Ethernet" it is good to be very explicit. There are a variety of ways to provide a redundant and protected service with ethernet vs sonet/sdh framing. Some of the carrier provided "ethernet" products result in weird pricing, or plain fear. I recall one ILEC that got an entire team on the phone with me for an ask about a 100m service purchase, because it was "huge" to them. Their price reflected it as well :) It was easier to stick with the city fiber network for backhaul as the pricing was sane. - Jared From repstein at hostleasing.net Mon Sep 10 15:55:24 2012 From: repstein at hostleasing.net (Randy Epstein) Date: Mon, 10 Sep 2012 16:55:24 -0400 Subject: [NANOG-announce] Upcoming NANOG mail list maintenance notification - 13-Sept-2012 Message-ID: On Thursday, September 13, 2012 beginning at 6 AM Eastern, the NANOG mail list service will be unavailable. Mailman will be upgraded and moved to a new location, and all lists will be synced, thus ensuring that no messages or archives are lost in the transition. We expect the outage to last no longer than 30 minutes. Regards, Randy Epstein NANOG CC Chair On behalf of the NANOG Communications Committee -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From nick at foobar.org Mon Sep 10 16:11:12 2012 From: nick at foobar.org (Nick Hilliard) Date: Mon, 10 Sep 2012 22:11:12 +0100 Subject: Are people still building SONET networks from scratch? In-Reply-To: References: <20120906163812.GA9934@loopfree.net> Message-ID: <504E5770.9050804@foobar.org> On 10/09/2012 21:43, Matthew Petach wrote: > If service is critical enough to me that 20 second hiccups make > a difference, I'll find two providers to provide connectivity um, what do you mean, "two providers"? > to the location via relatively cheap waves This *is* a troll, right...? just sayin' that not everywhere has functional competition... Nick From bill at herrin.us Mon Sep 10 16:14:04 2012 From: bill at herrin.us (William Herrin) Date: Mon, 10 Sep 2012 17:14:04 -0400 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <504D1726.3090608@necom830.hpcl.titech.ac.jp> References: <1398646.nogpiQX5tj@gentoovm> <504992E2.4080305@necom830.hpcl.titech.ac.jp> <1375033.GM90FNPWn2@gentoovm> <504D1726.3090608@necom830.hpcl.titech.ac.jp> Message-ID: On Sun, Sep 9, 2012 at 6:24 PM, Masataka Ohta wrote: > Oliver wrote: >>>> You're basically redefining the term "end-to-end transparency" to suit >>>> your own >>> Already in RFC3102, which restrict port number ranges, it is >>> stated that: >>> >>> This document examines the general framework of Realm Specific IP >>> (RSIP). RSIP is intended as a alternative to NAT in which the end- >>> to-end integrity of packets is maintained. We focus on >>> implementation issues, deployment scenarios, and interaction with >>> other layer-three protocols. >> >> Just because something is documented in RFC does not automatically make it a >> standard, nor does it necessarily make anyone care. > > That's not a valid argument against text in the RFC proof read by > the RFC editor as the evidence of established terminology of the > Internet community. In case Nick's comment wasn't obvious enough: RFC 1796: "Not All RFCs Are Standards It is a regrettably well spread misconception that publication as an RFC provides some level of recognition. It does not, or at least not any more than the publication in a regular journal." RFC 3102: "This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind." As to your original point that software could be constructed that restores end-to-end through a NAT device by some kind of dynamic but published assignment of incoming ports to specific hosts behind the NAT... that's not really true. End-to-end is generally described as a layer 3 phenomenon. Dinking around with ports means you're at layer 4. Which means that only specific pre-programmed transports can pass even it you would like all protocols to be able to. There is another technology, also called NAT and described in RFC 1631, which translates layer 3 addresses 1:1, exactly one address inside for one address outside. While it's possible to talk about end-to-end with that technology, we are for practical, operational purposes just shy of -never- talking about or using that kind of NAT. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From dmburgess at linktechs.net Mon Sep 10 16:16:40 2012 From: dmburgess at linktechs.net (Dennis Burgess) Date: Mon, 10 Sep 2012 16:16:40 -0500 Subject: Level3 BGP Issue Message-ID: <50710E9A7E64454C974049FC998EB655681552@03-exchange.lti.local> I have a prefix that is having an issue with BGP, its all inside of L3.... If there is someone that would be willing to assist with L3, shoot me a e-mail offlist J Dennis Burgess, From mohta at necom830.hpcl.titech.ac.jp Mon Sep 10 16:41:41 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 11 Sep 2012 06:41:41 +0900 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: References: <1398646.nogpiQX5tj@gentoovm> <504992E2.4080305@necom830.hpcl.titech.ac.jp> <1375033.GM90FNPWn2@gentoovm> <504D1726.3090608@necom830.hpcl.titech.ac.jp> Message-ID: <504E5E95.1010001@necom830.hpcl.titech.ac.jp> William Herrin wrote: > In case Nick's comment wasn't obvious enough: Anything written in RFC1796 should be ignored, because RFC1796, an informational, not standard track, RFC, states so. It's so obvious. > RFC 1796: > It is a regrettably well spread misconception that publication as an > RFC provides some level of recognition. It does not, or at least not > any more than the publication in a regular journal." Your silliness, too, is appreciated. > End-to-end is generally described as a > layer 3 phenomenon. Read the original paper on it: http://groups.csail.mit.edu/ana/Publications/PubPDFs/End-to-End%20Arguments%20in%20System%20Design.pdf to find that the major example of the paper is file transfer, an application. > we are for practical, operational > purposes just shy of -never- talking about or using that kind of NAT. For practical operational purposes, it is enough that PORT command of ftp works transparently. Masataka Ohta From mpetach at netflight.com Mon Sep 10 17:14:24 2012 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 10 Sep 2012 15:14:24 -0700 Subject: Are people still building SONET networks from scratch? In-Reply-To: <504E5770.9050804@foobar.org> References: <20120906163812.GA9934@loopfree.net> <504E5770.9050804@foobar.org> Message-ID: On Mon, Sep 10, 2012 at 2:11 PM, Nick Hilliard wrote: > On 10/09/2012 21:43, Matthew Petach wrote: >> If service is critical enough to me that 20 second hiccups make >> a difference, I'll find two providers to provide connectivity > > um, what do you mean, "two providers"? > >> to the location via relatively cheap waves > > This *is* a troll, right...? > > just sayin' that not everywhere has functional competition... > > Nick *heh* Fair enough. I guess it's really a question of what scale you're looking at. Even when building a greenfield datacenter in the middle of an empty field in an out-of-the-way corner of a state with cheap electricity, you can generally find two fiber providers that will run fiber into the location based on the premise of the long-term payback a 50MW datacenter brings with it. At smaller scales, I could see how it could become more challenging to convince a second provider it's worth their while to build out to your location. point taken--thanks! Matt From operations.tcdallas at hotmail.com Mon Sep 10 15:27:11 2012 From: operations.tcdallas at hotmail.com (Operations Dallas ) Date: Mon, 10 Sep 2012 20:27:11 +0000 Subject: Heads-Up: GoDaddy Broke the Interwebs... Message-ID: I thought I saw an article on routergod.com from Dance Patrick regarding anycast DNS...... ~oliver Sent via DynaTAC. Please forgive spelling and grammar. -----Original Message----- From: Bill.Ingrum at t-systems.com Date: Mon, 10 Sep 2012 19:13:27 To: ; Subject: RE: Heads-Up: GoDaddy Broke the Interwebs... Looks like this may be a DDoS attack from Anonymous: http://techcrunch.com/2012/09/10/godaddy-outage-takes-down-millions-of-sites/ -----Original Message----- From: Aaron C. de Bruyn [mailto:aaron at heyaaron.com] Sent: Monday, September 10, 2012 1:07 PM To: NANOG mailing list Subject: Heads-Up: GoDaddy Broke the Interwebs... For the last ~15 minutes I've been receiving complaints about DNS issues.? GoDaddy DNS is apparently b0rked.? I'm also seeing a lot of tweets about their hosting and VPS being down.? I'm unable to access the control panel for one of my customer accounts. -A From monia at cs.toronto.edu Sat Sep 8 19:23:53 2012 From: monia at cs.toronto.edu (Monia Ghobadi) Date: Sat, 8 Sep 2012 20:23:53 -0400 Subject: Traffic Burstiness Survey Message-ID: Dear Nanog members, I am a PhD student at University of Toronto and I am working on traffic burstiness in data centers. In the following I am asking two questions to raise motivation for my research. I appreciate if anyone could answer these questions to their best knowledge. *The questions are:* 1) ?Bursty? is a word with no agreed meaning. How do you define a bursty traffic? 2) If you are involved with a data center, is your data center traffic bursty? -- If yes, -- Do you think that it will be useful to supress the burstiness in your traffic? (For example by pacing the traffic into shorter bursts) -- If no: -- Are you already supressing the burstiness? How? -- Would you anticipate the traffic becoming burstier in the future? Thanks, Monia ------------------ Monia Ghobadi PhD Student University of Toronto http://www.cs.utoronto.ca/~monia/ From marka at isc.org Mon Sep 10 23:18:20 2012 From: marka at isc.org (Mark Andrews) Date: Tue, 11 Sep 2012 14:18:20 +1000 Subject: Are people still building SONET networks from scratch? In-Reply-To: Your message of "Mon, 10 Sep 2012 10:55:26 MST." References: <20120906163812.GA9934@loopfree.net> Message-ID: <20120911041821.B1A6324B1E13@drugs.dv.isc.org> In message , david peahi writes: > In my neck of the woods, critical locations often exist "in the middle of > nowhere", resulting in underserved facilities, where best effort networks > such as metro Ethernet cannot be trusted to remain available 24x7x365. Many > times, during prime business hours, I will see a telco metro Ethernet > spanning tree convergence which results in my traffic re-routing for 20-30 > seconds over my private backup network path, then switching back to the > metro Ethernet path after the telco technicians have finished their > maintenance. Several times when I have called in a trouble ticket, the > telco tech has asked "what is the big deal, it was only a 20 second > outage?". In the Enterprise environment, a planned spanning tree > convergence in the middle of business hours is one of the quickest ways for > a network engineer to be relieved of their duties, but apparently the bar > is considerably lower in the telco environment. > Not only that, but the telco SLAs associated with metro Ethernet are > totally bogus, with a best round trip SLA of 20 milliseconds, ranging up to > 50 milliseconds for "bronze" service. For short distances of 100 miles or > less (rule of thumb is that light travels over fiber at 0.80 x speed of > light, or 1000 miles in 10 milliseconds), an SLA of 20-50 milliseconds > amounts to fraud, just another way for the telcos to scam the consumer. > The tone of many of the entries on this thread where the user is depicted > as being unreasonable, underscores the need for a coordinated national > broadband policy in the USA, based upon the Australian model in which the > government is building out fiber to every residence and business, no matter > where they are located. The NBN is to be delivered over a mixture of fibre (93% of homes), wireless and satellite services[1]. [1] http://www.nbn.gov.au/about-the-nbn/what-is-the-nbn/ > Regards, > > David -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From hj1980 at gmail.com Mon Sep 10 23:40:07 2012 From: hj1980 at gmail.com (Heath Jones) Date: Tue, 11 Sep 2012 14:40:07 +1000 Subject: Traffic Burstiness Survey In-Reply-To: References: Message-ID: Hi Monia, 'Burst' is a very broad term. It would be useful to clarify to what you are referring.. I can think of a few possibilities: - Data Transmission: The length of an uninterrupted flow of information. - Traffic Engineering: The ability for traffic to temporarily exceed it's allocated (average) bandwidth share. - Internal Event: A backup (scheduled) or a server failure (adhoc) altering traffic patterns. - External Event: Marketing campaign / event coinciding with increased traffic towards say, a website. Perhaps -> Over what period of time is a 'Burst'..? Cheers, Heath On Sun, Sep 9, 2012 at 10:23 AM, Monia Ghobadi wrote: > Dear Nanog members, > > I am a PhD student at University of Toronto and I am working on traffic > burstiness in data centers. In the following I am asking two questions to > raise motivation for my research. I appreciate if anyone could answer these > questions to their best knowledge. *The questions are:* > > 1) ?Bursty? is a word with no agreed meaning. How do you define a bursty > traffic? > 2) If you are involved with a data center, is your data center traffic > bursty? > -- If yes, > -- Do you think that it will be useful to supress the burstiness > in your traffic? (For example by pacing the traffic into shorter bursts) > -- If no: > -- Are you already supressing the burstiness? How? > -- Would you anticipate the traffic becoming burstier in the > future? > > Thanks, > Monia > > ------------------ > Monia Ghobadi > PhD Student > University of Toronto > http://www.cs.utoronto.ca/~monia/ > From mysidia at gmail.com Tue Sep 11 01:05:13 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 11 Sep 2012 01:05:13 -0500 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <50482E3E.7020309@necom830.hpcl.titech.ac.jp> References: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> <504821BD.7010009@necom830.hpcl.titech.ac.jp> <5AFF3D96-3204-433D-8A01-A680C455B489@delong.com> <50482E3E.7020309@necom830.hpcl.titech.ac.jp> Message-ID: On 9/6/12, Masataka Ohta wrote: > Owen DeLong wrote: >> You're demanding an awful lot of changes to the entire internet to > All that necessary is local changes on end systems of those who > want the end to end transparency. Achieving "end to end", and breaking interoperability while introducing a level of complexity and points of failure that noone will accept, is no good. I refer you back to RFC1925 number (6). If you had to modify the implementation on endpoints that want to communicate end-to-end, then by definition you don't have transparency. The inability to communicate end-to-end with unmodified endpoints makes it non-transparent, and is itself a break of the principle. UPnP is not robust enough either for the suggested application. The RFC3102 you mention doesn't have acceptance; the concept of RSIP was not proven tenable, that it actually works or scales and can be implemented reliably with real applications on real networks in the first place. Achieving true 'end to end' with such a scheme would require alterations to many protocol standards which didn't happen, and there would be many interoperability breaks. > > There is no changes on the Internet. > Masataka Ohta -- -JH From lear at cisco.com Tue Sep 11 01:57:02 2012 From: lear at cisco.com (Eliot Lear) Date: Tue, 11 Sep 2012 08:57:02 +0200 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <1A09F1D2-F587-4C30-A06A-047351D68CBE@delong.com> References: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> <504821BD.7010009@necom830.hpcl.titech.ac.jp> <5AFF3D96-3204-433D-8A01-A680C455B489@delong.com> <20120906151458.GC7079@dyn.com> <1A09F1D2-F587-4C30-A06A-047351D68CBE@delong.com> Message-ID: <504EE0BE.5070901@cisco.com> On 9/6/12 8:27 PM, Owen DeLong wrote: > Despite my scepticism of the overall project, I find the above claim a > little hard to accept. RFC 2052, which defined SRV in an > experiment, came out in 1996. SRV was moved to the standards track in > 2000. I've never heard an argument why it won't work, and we know > that SRV records are sometimes in use. Why couldn't that mechanism be > used more widely? > > If browsers started implementing it, it could. This is currently being discussed in the httpbis working group as part of the http 2.0 discussion. Also, I'll note that at least one browser has implemented XMPP without the mandatory SRV record, and it's next to useless for XMPP (in fact it seems to only work with a handful of broken XMPP implementations), so look for SRV in at least one browser in the next year or so, I'd guess. > > I suppose the more accurate/detailed statement would be: > > Without modifying every client on the internet, there is no way for the > clients trying to reach you to reliably be informed of this port number > situation. > > If you're going to touch every client, it's easier to just do IPv6. > Well, this depends on who you think "you" is. The browser gang regularly touches many MANY (but not all) clients. Eliot From owen at delong.com Tue Sep 11 03:47:14 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 11 Sep 2012 01:47:14 -0700 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <504EE0BE.5070901@cisco.com> References: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> <504821BD.7010009@necom830.hpcl.titech.ac.jp> <5AFF3D96-3204-433D-8A01-A680C455B489@delong.com> <20120906151458.GC7079@dyn.com> <1A09F1D2-F587-4C30-A06A-047351D68CBE@delong.com> <504EE0BE.5070901@cisco.com> Message-ID: > > Well, this depends on who you think "you" is. The browser gang > regularly touches many MANY (but not all) clients. > Not everything on the internet is accessed using a browser. Is adding SRV to browsers a good thing? Yes. Is end-to-end transparent addressing a good thing? Yes. Does one have anything to do with the other? Only in the delusional mind of Masataka. Real transparent addressing will come with IPv6. IPv4 does not scale. It's time to move forward. Owen From mohta at necom830.hpcl.titech.ac.jp Tue Sep 11 06:34:19 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 11 Sep 2012 20:34:19 +0900 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <504EE0BE.5070901@cisco.com> References: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com> <504821BD.7010009@necom830.hpcl.titech.ac.jp> <5AFF3D96-3204-433D-8A01-A680C455B489@delong.com> <20120906151458.GC7079@dyn.com> <1A09F1D2-F587-4C30-A06A-047351D68CBE@delong.com> <504EE0BE.5070901@cisco.com> Message-ID: <504F21BB.4030601@necom830.hpcl.titech.ac.jp> Eliot Lear wrote: > On 9/6/12 8:27 PM, Owen DeLong wrote: >> If you're going to touch every client, it's easier to just do IPv6. > Well, this depends on who you think "you" is. The browser gang > regularly touches many MANY (but not all) clients. Though I merely stated: The easiest part of the deployment is to modify end systems. according to Owen's delusion confirmed by private communications (I can't understand why he can do it public), "client", seemingly, also means middle NAT boxes, even though they are still fine as long as they are "client"s or servers supporting UPnP. Yes, the easiest part of the deployment is to modify end systems, to modify protocol stacks and browsers of the end systems. Masataka Ohta From valdis.kletnieks at vt.edu Tue Sep 11 06:52:51 2012 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Tue, 11 Sep 2012 07:52:51 -0400 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: Your message of "Tue, 11 Sep 2012 05:51:53 +0900." <504E52E9.6010102@necom830.hpcl.titech.ac.jp> References: <1398646.nogpiQX5tj@gentoovm> <504992E2.4080305@necom830.hpcl.titech.ac.jp> <1375033.GM90FNPWn2@gentoovm> <504D1726.3090608@necom830.hpcl.titech.ac.jp> <504DE7CA.80803@foobar.org> <504E52E9.6010102@necom830.hpcl.titech.ac.jp> Message-ID: <19751.1347364371@turing-police.cc.vt.edu> On Tue, 11 Sep 2012 05:51:53 +0900, Masataka Ohta said: > Anything written in RFC1796 should be ignored, because RFC1796, an > informational, not standard track, RFC, states so. On the other hand, if you're relying on the fact that 1796 is informational in order to ignore it, then you're following its guidance even though it's not a standard. Insisting on being pedantic on its status will merely leave you wondering who shaves the barber. > Or, is it time to retract your silliness? Standard or not, we have Christian Huitema, John Postel, and Steve Crocker telling you something about RFCs and how they actually work. Which is more likely, that all 3 of them were wrong, or that you're the one that's confused? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From SNaslund at medline.com Tue Sep 11 08:52:44 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 11 Sep 2012 08:52:44 -0500 Subject: Traffic Burstiness Survey In-Reply-To: References: Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0C4C6715@MUNEXBE1.medline.com> Bursty is a very relative thing. It depends on the time frame you are considering. For example, at any given instant of time a circuit is either carrying data or it isn't. The network is always either 100% in use or 100% idle if you look at it in an instantaneous fashion. There is also a misconception that bursty is bad. In very fast networks, the systems complete their transmissions very quickly so appear bursty. In a lower bandwidth network the system may transmit almost continuously because there is always data queued for transmission. This would appear as non-bursty continuous traffic. What you are really looking at here is the value and effect of traffic shaping. You should probably repose your question and ask about traffic shaping. In my opinion, like most QoS mechanisms, traffic shaping is something you do as a compromise to get the best service in a network that does not have enough bandwidth or has high latency. The best solution is almost always more bandwidth. The idea of suppressing bursts is not something that I think would be optimal. What you are saying is really that a system has data to send but I am not going to allow it to go out as fast as possible. I am going to do some kind of traffic shaping which might be more fair to other traffic but at the end of the day, all you can do is add delay. Steven Naslund -----Original Message----- From: Monia Ghobadi [mailto:monia at cs.toronto.edu] Sent: Saturday, September 08, 2012 7:24 PM To: NANOG at nanog.org Subject: Traffic Burstiness Survey Dear Nanog members, I am a PhD student at University of Toronto and I am working on traffic burstiness in data centers. In the following I am asking two questions to raise motivation for my research. I appreciate if anyone could answer these questions to their best knowledge. *The questions are:* 1) 'Bursty' is a word with no agreed meaning. How do you define a bursty traffic? 2) If you are involved with a data center, is your data center traffic bursty? -- If yes, -- Do you think that it will be useful to supress the burstiness in your traffic? (For example by pacing the traffic into shorter bursts) -- If no: -- Are you already supressing the burstiness? How? -- Would you anticipate the traffic becoming burstier in the future? Thanks, Monia ------------------ Monia Ghobadi PhD Student University of Toronto http://www.cs.utoronto.ca/~monia/ From cjp at 0x1.net Tue Sep 11 10:54:02 2012 From: cjp at 0x1.net (Christopher J. Pilkington) Date: Tue, 11 Sep 2012 11:54:02 -0400 Subject: SAVVIS IPv6 Status Message-ID: We're in SAVVIS DC3 and wondering what the status of IPv6 is there. We submitted a request for IPv6, and we were told SAVVIS does not assign address space. Later emails we were told they will route IPv6 however. I haven't yet contacted sales... I think we lost our rep in the CenturyLink merger. I did see some blurbs from last year saying they weren't ready at that time. Was hoping this changed. We're not multihomed there, (except indirectly via through SAVVIS' own upstreams), so I don't think I can justify an ARIN assignment for that site. Replies on or off list welcome. Thanks much! -cjp From kyle.creyts at gmail.com Tue Sep 11 12:54:31 2012 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Tue, 11 Sep 2012 10:54:31 -0700 Subject: Heads-Up: GoDaddy Broke the Interwebs... In-Reply-To: References: Message-ID: http://www.godaddy.com/newscenter/release-view.aspx?news_item_id=410 On Mon, Sep 10, 2012 at 1:27 PM, Operations Dallas wrote: > I thought I saw an article on routergod.com from Dance Patrick regarding anycast DNS...... > ~oliver > > Sent via DynaTAC. Please forgive spelling and grammar. > > -----Original Message----- > From: Bill.Ingrum at t-systems.com > Date: Mon, 10 Sep 2012 19:13:27 > To: ; > Subject: RE: Heads-Up: GoDaddy Broke the Interwebs... > > > Looks like this may be a DDoS attack from Anonymous: > > http://techcrunch.com/2012/09/10/godaddy-outage-takes-down-millions-of-sites/ > > > -----Original Message----- > From: Aaron C. de Bruyn [mailto:aaron at heyaaron.com] > Sent: Monday, September 10, 2012 1:07 PM > To: NANOG mailing list > Subject: Heads-Up: GoDaddy Broke the Interwebs... > > For the last ~15 minutes I've been receiving complaints about DNS issues. GoDaddy DNS is apparently b0rked. I'm also seeing a lot of tweets about their hosting and VPS being down. I'm unable to access the control panel for one of my customer accounts. > > > -A > -- Kyle Creyts Information Assurance Professional BSidesDetroit Organizer From kyle.creyts at gmail.com Tue Sep 11 12:55:07 2012 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Tue, 11 Sep 2012 10:55:07 -0700 Subject: Heads-Up: GoDaddy Broke the Interwebs... In-Reply-To: References: Message-ID: No DDoS or Anonymous attack appears to have been involved. On Tue, Sep 11, 2012 at 10:54 AM, Kyle Creyts wrote: > http://www.godaddy.com/newscenter/release-view.aspx?news_item_id=410 > > On Mon, Sep 10, 2012 at 1:27 PM, Operations Dallas > wrote: >> I thought I saw an article on routergod.com from Dance Patrick regarding anycast DNS...... >> ~oliver >> >> Sent via DynaTAC. Please forgive spelling and grammar. >> >> -----Original Message----- >> From: Bill.Ingrum at t-systems.com >> Date: Mon, 10 Sep 2012 19:13:27 >> To: ; >> Subject: RE: Heads-Up: GoDaddy Broke the Interwebs... >> >> >> Looks like this may be a DDoS attack from Anonymous: >> >> http://techcrunch.com/2012/09/10/godaddy-outage-takes-down-millions-of-sites/ >> >> >> -----Original Message----- >> From: Aaron C. de Bruyn [mailto:aaron at heyaaron.com] >> Sent: Monday, September 10, 2012 1:07 PM >> To: NANOG mailing list >> Subject: Heads-Up: GoDaddy Broke the Interwebs... >> >> For the last ~15 minutes I've been receiving complaints about DNS issues. GoDaddy DNS is apparently b0rked. I'm also seeing a lot of tweets about their hosting and VPS being down. I'm unable to access the control panel for one of my customer accounts. >> >> >> -A >> > > > > -- > Kyle Creyts > > Information Assurance Professional > BSidesDetroit Organizer -- Kyle Creyts Information Assurance Professional BSidesDetroit Organizer From Jason_Bertoch at nwrdc.fsu.edu Tue Sep 11 13:13:06 2012 From: Jason_Bertoch at nwrdc.fsu.edu (Jason Bertoch) Date: Tue, 11 Sep 2012 14:13:06 -0400 Subject: Heads-Up: GoDaddy Broke the Interwebs... In-Reply-To: References: Message-ID: <496C438322D62B4CBCF26BBBBBE10D4BBEC321@EX.nwrdc.com> Now it's CNN /Jason -----Original Message----- From: Kyle Creyts [mailto:kyle.creyts at gmail.com] Sent: Tuesday, September 11, 2012 1:55 PM To: Operations Dallas Cc: nanog at nanog.org Subject: Re: Heads-Up: GoDaddy Broke the Interwebs... No DDoS or Anonymous attack appears to have been involved. On Tue, Sep 11, 2012 at 10:54 AM, Kyle Creyts wrote: > http://www.godaddy.com/newscenter/release-view.aspx?news_item_id=410 > > On Mon, Sep 10, 2012 at 1:27 PM, Operations Dallas > wrote: >> I thought I saw an article on routergod.com from Dance Patrick regarding anycast DNS...... >> ~oliver >> >> Sent via DynaTAC. Please forgive spelling and grammar. >> >> -----Original Message----- >> From: Bill.Ingrum at t-systems.com >> Date: Mon, 10 Sep 2012 19:13:27 >> To: ; >> Subject: RE: Heads-Up: GoDaddy Broke the Interwebs... >> >> >> Looks like this may be a DDoS attack from Anonymous: >> >> http://techcrunch.com/2012/09/10/godaddy-outage-takes-down-millions-o >> f-sites/ >> >> >> -----Original Message----- >> From: Aaron C. de Bruyn [mailto:aaron at heyaaron.com] >> Sent: Monday, September 10, 2012 1:07 PM >> To: NANOG mailing list >> Subject: Heads-Up: GoDaddy Broke the Interwebs... >> >> For the last ~15 minutes I've been receiving complaints about DNS issues. GoDaddy DNS is apparently b0rked. I'm also seeing a lot of tweets about their hosting and VPS being down. I'm unable to access the control panel for one of my customer accounts. >> >> >> -A >> > > > > -- > Kyle Creyts > > Information Assurance Professional > BSidesDetroit Organizer -- Kyle Creyts Information Assurance Professional BSidesDetroit Organizer From williams.joe at gmail.com Tue Sep 11 13:18:41 2012 From: williams.joe at gmail.com (Joe Williams) Date: Tue, 11 Sep 2012 11:18:41 -0700 Subject: above.net issues Message-ID: <869B67C442824AA4A658843848A20D69@gmail.com> Anyone experiencing packet loss on abovenet (to/from Ashburn)? We first got a round of packet loss around 8:45 PDT and then again just a few minutes ago. Thanks. -Joe -- Name: Joseph A. Williams Email: williams.joe at gmail.com From williams.joe at gmail.com Tue Sep 11 13:20:13 2012 From: williams.joe at gmail.com (Joe Williams) Date: Tue, 11 Sep 2012 11:20:13 -0700 Subject: above.net issues In-Reply-To: <869B67C442824AA4A658843848A20D69@gmail.com> References: <869B67C442824AA4A658843848A20D69@gmail.com> Message-ID: <8065924C873D4452AE0FF4A368954860@gmail.com> Oops, this was intended for the outages list but I suppose this list works too. -- Name: Joseph A. Williams Email: williams.joe at gmail.com On Tuesday, September 11, 2012 at 11:18 AM, Joe Williams wrote: > Anyone experiencing packet loss on abovenet (to/from Ashburn)? We first got a round of packet loss around 8:45 PDT and then again just a few minutes ago. > > Thanks. > > -Joe > > > -- > Name: Joseph A. Williams > Email: williams.joe at gmail.com (mailto:williams.joe at gmail.com) > From MGauvin at dryden.ca Tue Sep 11 13:36:30 2012 From: MGauvin at dryden.ca (Mark Gauvin) Date: Tue, 11 Sep 2012 13:36:30 -0500 Subject: Heads-Up: GoDaddy Broke the Interwebs... In-Reply-To: <496C438322D62B4CBCF26BBBBBE10D4BBEC321@EX.nwrdc.com> References: <496C438322D62B4CBCF26BBBBBE10D4BBEC321@EX.nwrdc.com> Message-ID: And this is bad why? Sent from my iPhone On 2012-09-11, at 1:14 PM, "Jason Bertoch" wrote: > Now it's CNN > > /Jason > > > -----Original Message----- > From: Kyle Creyts [mailto:kyle.creyts at gmail.com] > Sent: Tuesday, September 11, 2012 1:55 PM > To: Operations Dallas > Cc: nanog at nanog.org > Subject: Re: Heads-Up: GoDaddy Broke the Interwebs... > > No DDoS or Anonymous attack appears to have been involved. > > On Tue, Sep 11, 2012 at 10:54 AM, Kyle Creyts > wrote: >> http://www.godaddy.com/newscenter/release-view.aspx?news_item_id=410 >> >> On Mon, Sep 10, 2012 at 1:27 PM, Operations Dallas >> wrote: >>> I thought I saw an article on routergod.com from Dance Patrick > regarding anycast DNS...... >>> ~oliver >>> >>> Sent via DynaTAC. Please forgive spelling and grammar. >>> >>> -----Original Message----- >>> From: Bill.Ingrum at t-systems.com >>> Date: Mon, 10 Sep 2012 19:13:27 >>> To: ; >>> Subject: RE: Heads-Up: GoDaddy Broke the Interwebs... >>> >>> >>> Looks like this may be a DDoS attack from Anonymous: >>> >>> http://techcrunch.com/2012/09/10/godaddy-outage-takes-down-millions-o >>> f-sites/ >>> >>> >>> -----Original Message----- >>> From: Aaron C. de Bruyn [mailto:aaron at heyaaron.com] >>> Sent: Monday, September 10, 2012 1:07 PM >>> To: NANOG mailing list >>> Subject: Heads-Up: GoDaddy Broke the Interwebs... >>> >>> For the last ~15 minutes I've been receiving complaints about DNS > issues. GoDaddy DNS is apparently b0rked. I'm also seeing a lot of > tweets about their hosting and VPS being down. I'm unable to access the > control panel for one of my customer accounts. >>> >>> >>> -A >>> >> >> >> >> -- >> Kyle Creyts >> >> Information Assurance Professional >> BSidesDetroit Organizer > > > > -- > Kyle Creyts > > Information Assurance Professional > BSidesDetroit Organizer > > From bill at herrin.us Tue Sep 11 14:15:55 2012 From: bill at herrin.us (William Herrin) Date: Tue, 11 Sep 2012 15:15:55 -0400 Subject: Heads-Up: GoDaddy Broke the Interwebs... In-Reply-To: References: Message-ID: On Tue, Sep 11, 2012 at 1:54 PM, Kyle Creyts wrote: > http://www.godaddy.com/newscenter/release-view.aspx?news_item_id=410 "many of our customers experienced intermittent service outages" Must be that new definition of the word "intermittent." The one roughly synonymous with "total." -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mikea at mikea.ath.cx Tue Sep 11 14:19:23 2012 From: mikea at mikea.ath.cx (Mike A) Date: Tue, 11 Sep 2012 14:19:23 -0500 Subject: Heads-Up: GoDaddy Broke the Interwebs... In-Reply-To: References: Message-ID: <20120911191923.GC64017@mikea.ath.cx> On Tue, Sep 11, 2012 at 03:15:55PM -0400, William Herrin wrote: > On Tue, Sep 11, 2012 at 1:54 PM, Kyle Creyts wrote: > > http://www.godaddy.com/newscenter/release-view.aspx?news_item_id=410 > > "many of our customers experienced intermittent service outages" > > Must be that new definition of the word "intermittent." The one > roughly synonymous with "total." Yeah. Doubleplusungood. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From blake at pfankuch.me Tue Sep 11 14:25:03 2012 From: blake at pfankuch.me (Blake Pfankuch) Date: Tue, 11 Sep 2012 19:25:03 +0000 Subject: Heads-Up: GoDaddy Broke the Interwebs... In-Reply-To: References: Message-ID: As someone else nicely pointed out "network problems starting when the anon post said they would, and ending when they said they would stop.... ironic?" -----Original Message----- From: William Herrin [mailto:bill at herrin.us] Sent: Tuesday, September 11, 2012 1:16 PM To: Kyle Creyts Cc: nanog at nanog.org Subject: Re: Heads-Up: GoDaddy Broke the Interwebs... On Tue, Sep 11, 2012 at 1:54 PM, Kyle Creyts wrote: > http://www.godaddy.com/newscenter/release-view.aspx?news_item_id=410 "many of our customers experienced intermittent service outages" Must be that new definition of the word "intermittent." The one roughly synonymous with "total." -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From damian at google.com Tue Sep 11 14:47:50 2012 From: damian at google.com (Damian Menscher) Date: Tue, 11 Sep 2012 12:47:50 -0700 Subject: Heads-Up: GoDaddy Broke the Interwebs... In-Reply-To: References: Message-ID: What time did the anon first say there would be GoDaddy problems? Earliest timestamp I can find is 10:45am (pacific) and the problems had started much earlier, around 10:15. Curious if you found evidence of any anons claiming an attack or responsibility for the attack within, say, 5 minutes of it starting. Also, the time it stopped wasn't exactly tied to anything the anon said, other than his vague statements like "it can last one hour or one month" and "soon u guys can acess". And he said that latter statement at 1:59pm while the outage ended at 3:45pm. Summary: 30 minutes late on the start time, and off by well over an hour on the stop time. Damian On Tue, Sep 11, 2012 at 12:25 PM, Blake Pfankuch wrote: > As someone else nicely pointed out "network problems starting when the > anon post said they would, and ending when they said they would stop.... > ironic?" > > -----Original Message----- > From: William Herrin [mailto:bill at herrin.us] > Sent: Tuesday, September 11, 2012 1:16 PM > To: Kyle Creyts > Cc: nanog at nanog.org > Subject: Re: Heads-Up: GoDaddy Broke the Interwebs... > > On Tue, Sep 11, 2012 at 1:54 PM, Kyle Creyts > wrote: > > http://www.godaddy.com/newscenter/release-view.aspx?news_item_id=410 > > "many of our customers experienced intermittent service outages" > > Must be that new definition of the word "intermittent." The one roughly > synonymous with "total." > > -Bill > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: Falls > Church, VA 22042-3004 > > > -- Damian Menscher :: Security Reliability Engineer :: Google From morrowc.lists at gmail.com Tue Sep 11 15:04:43 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 11 Sep 2012 16:04:43 -0400 Subject: Heads-Up: GoDaddy Broke the Interwebs... In-Reply-To: References: Message-ID: On Tue, Sep 11, 2012 at 3:47 PM, Damian Menscher wrote: > > Summary: 30 minutes late on the start time, and off by well over an hour on > the stop time. even a broken clock is right 2x/day? nostrodamus was eventually right a few times? 'If you're cold, shoot until you get hot, then keep shooting!' - dick vitale folk like to look for the most complicated/spooky/crazy reason... most often it's just a simple reason for failure :( so far godaddy seems to agree with the 'it was a simple mistake on our part' (paraphrased, they probably won't say 'simple') From patrick at ianai.net Tue Sep 11 15:18:10 2012 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 11 Sep 2012 16:18:10 -0400 Subject: Heads-Up: GoDaddy Broke the Interwebs... In-Reply-To: References: Message-ID: On Sep 11, 2012, at 16:04 , Christopher Morrow wrote: > On Tue, Sep 11, 2012 at 3:47 PM, Damian Menscher wrote: >> >> Summary: 30 minutes late on the start time, and off by well over an hour on >> the stop time. > > even a broken clock is right 2x/day? > nostrodamus was eventually right a few times? > 'If you're cold, shoot until you get hot, then keep shooting!' - dick vitale > > folk like to look for the most complicated/spooky/crazy reason... most > often it's just a simple reason for failure :( > so far godaddy seems to agree with the 'it was a simple mistake on our > part' (paraphrased, they probably won't say 'simple') No large flows reported to the affected NSes, tweets were suspicious at best, other anon-ops denied the attack was them, and GoDaddy admitted internal error. I'm going to take GoDaddy at their word, and give them major kudos for owning up to the mistake - in public. -- TTFN, patrick From rubensk at gmail.com Tue Sep 11 15:53:59 2012 From: rubensk at gmail.com (Rubens Kuhl) Date: Tue, 11 Sep 2012 17:53:59 -0300 Subject: Heads-Up: GoDaddy Broke the Interwebs... In-Reply-To: References: Message-ID: > No large flows reported to the affected NSes, tweets were suspicious at best, other anon-ops denied the attack was them, and GoDaddy admitted internal error. > > I'm going to take GoDaddy at their word, and give them major kudos for owning up to the mistake - in public. That doesn't mean that their description of the internal error fits what happened. Not to say that there were an attack, just that there can be more internal failures, including processes, to be accounted for. Whether they will publish a root-cause analysis/swiss chesse model/ or not is up to them, but to tech-savvy stakeholders I think they are still in debt. Rubens From baconzombie at gmail.com Tue Sep 11 16:03:37 2012 From: baconzombie at gmail.com (Bacon Zombie) Date: Tue, 11 Sep 2012 22:03:37 +0100 Subject: Heads-Up: GoDaddy Broke the Interwebs... In-Reply-To: References: Message-ID: The blog says 99.999% uptime, but I'm guessing this "outage" lasted more them 5.49300000002 minutes and they probably had other issues during the year. On 11 September 2012 21:53, Rubens Kuhl wrote: > > > No large flows reported to the affected NSes, tweets were suspicious at best, other anon-ops denied the attack was them, and GoDaddy admitted internal error. > > > > I'm going to take GoDaddy at their word, and give them major kudos for owning up to the mistake - in public. > > That doesn't mean that their description of the internal error fits > what happened. Not to say that there were an attack, just that there > can be more internal failures, including processes, to be accounted > for. Whether they will publish a root-cause analysis/swiss chesse > model/ or not is up to them, but to > tech-savvy stakeholders I think they are still in debt. > > > Rubens > -- ???????????????????? ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ??????????????????????????????????????????????????????????????????????????????????? BaconZombie LOAD "*",8,1 From ryan.landry at gmail.com Tue Sep 11 16:04:55 2012 From: ryan.landry at gmail.com (ryanL) Date: Tue, 11 Sep 2012 14:04:55 -0700 Subject: Heads-Up: GoDaddy Broke the Interwebs... In-Reply-To: References: Message-ID: when patrick is referring to "taking their word for it", he's referring to a post on outages@ by godaddy's network engineering manager that stated "bgp, and more details to follow". i tend to align with patrick's thought. i'm also interested to see the details, which they are really under no obligation to provide. On Tue, Sep 11, 2012 at 1:53 PM, Rubens Kuhl wrote: > > No large flows reported to the affected NSes, tweets were suspicious at > best, other anon-ops denied the attack was them, and GoDaddy admitted > internal error. > > > > I'm going to take GoDaddy at their word, and give them major kudos for > owning up to the mistake - in public. > > That doesn't mean that their description of the internal error fits > what happened. Not to say that there were an attack, just that there > can be more internal failures, including processes, to be accounted > for. Whether they will publish a root-cause analysis/swiss chesse > model/ or not is up to them, but to > tech-savvy stakeholders I think they are still in debt. > > > Rubens > > From jared at puck.nether.net Tue Sep 11 16:08:08 2012 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 11 Sep 2012 17:08:08 -0400 Subject: Heads-Up: GoDaddy Broke the Interwebs... In-Reply-To: References: Message-ID: <1F10051D-B4CA-4E2E-B043-62E7F0067BE2@puck.nether.net> On Sep 11, 2012, at 4:53 PM, Rubens Kuhl wrote: > That doesn't mean that their description of the internal error fits > what happened Anytime I've seen a real RFO, it takes more than 24 hours to collect data. Sometimes you actually don't know what happened. There's a reason for this comic: http://www.dilbert.com/strips/comic/1999-08-04/ (the reboot cleared the problem). I've seen many odd behaviors of devices that nobody could explain, including the vendors.. sometimes it takes a few years to understand what happened. I recall a case where 2-3 years after a major outage someone made some minor comment about their architecture and a light came on. I welcome more information about mistakes/errors that we can all learn from. Sharing that information can be hard or uncomfortable at times, but can help others learn and not make the same mistakes again. I took the recommendation of others and have started to read "Normal Accidents". amazon link: http://tinyurl.com/9dc6x98 The whole multiple-failures problem really makes me concerned about cascading system failures when things go wrong. - Jared From patrick at ianai.net Tue Sep 11 16:34:57 2012 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 11 Sep 2012 17:34:57 -0400 Subject: Heads-Up: GoDaddy Broke the Interwebs... In-Reply-To: References: Message-ID: On Sep 11, 2012, at 17:04 , ryanL wrote: > when patrick is referring to "taking their word for it", he's referring to a post on outages@ by godaddy's network engineering manager that stated "bgp, and more details to follow". Well, mostly I'm taking GoDaddy at their word that this was not a DoS attack. I also believe it was related to BGP, and am happy to get more info. But we are discussing Anonymous vs. Self-inflicted wound here. -- TTFN, patrick > i tend to align with patrick's thought. i'm also interested to see the details, which they are really under no obligation to provide. > > On Tue, Sep 11, 2012 at 1:53 PM, Rubens Kuhl wrote: > > No large flows reported to the affected NSes, tweets were suspicious at best, other anon-ops denied the attack was them, and GoDaddy admitted internal error. > > > > I'm going to take GoDaddy at their word, and give them major kudos for owning up to the mistake - in public. > > That doesn't mean that their description of the internal error fits > what happened. Not to say that there were an attack, just that there > can be more internal failures, including processes, to be accounted > for. Whether they will publish a root-cause analysis/swiss chesse > model/ or not is up to them, but to > tech-savvy stakeholders I think they are still in debt. > > > Rubens > > From rubensk at gmail.com Tue Sep 11 16:37:44 2012 From: rubensk at gmail.com (Rubens Kuhl) Date: Tue, 11 Sep 2012 18:37:44 -0300 Subject: Heads-Up: GoDaddy Broke the Interwebs... In-Reply-To: References: Message-ID: On Tue, Sep 11, 2012 at 6:04 PM, ryanL wrote: > when patrick is referring to "taking their word for it", he's referring to a > post on outages@ by godaddy's network engineering manager that stated "bgp, > and more details to follow". "more" is the operating word here. > i tend to align with patrick's thought. i'm also interested to see the > details, which they are really under no obligation to provide. They could have said unspecified/yet-to-be-investigated internal technical failure(s). But when they quoted an specific failure, their communication(the PR, not the outages@ report) was trying to benefit from being specific, which is known to gain more trust. That comes with a responsibility to be precise and opens it to scrutiny by the technical community. Rubens From mohta at necom830.hpcl.titech.ac.jp Tue Sep 11 17:15:57 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 12 Sep 2012 07:15:57 +0900 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <19751.1347364371@turing-police.cc.vt.edu> References: <1398646.nogpiQX5tj@gentoovm> <504992E2.4080305@necom830.hpcl.titech.ac.jp> <1375033.GM90FNPWn2@gentoovm> <504D1726.3090608@necom830.hpcl.titech.ac.jp> <504DE7CA.80803@foobar.org> <504E52E9.6010102@necom830.hpcl.titech.ac.jp> <19751.1347364371@turing-police.cc.vt.edu> Message-ID: <504FB81D.2090309@necom830.hpcl.titech.ac.jp> (2012/09/11 20:52), valdis.kletnieks at vt.edu wrote: > On Tue, 11 Sep 2012 05:51:53 +0900, Masataka Ohta said: > >> Anything written in RFC1796 should be ignored, because RFC1796, an >> informational, not standard track, RFC, states so. > > On the other hand, if you're relying on the fact that 1796 is informational No, I don't. It's Jimmy, Eliot and you who are relying on a non standard track RFC to deny RFC3102 and all the non standard track RFCs, which is the silly paradox. > Standard or not, we have Christian Huitema, John Postel, and Steve > Crocker If you have some respect to them, don't involve them with your silly paradox. Masataka Ohta From mysidia at gmail.com Tue Sep 11 19:56:54 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 11 Sep 2012 19:56:54 -0500 Subject: The End-To-End Internet (was Re: Blocking MX query) In-Reply-To: <504FB81D.2090309@necom830.hpcl.titech.ac.jp> References: <1398646.nogpiQX5tj@gentoovm> <504992E2.4080305@necom830.hpcl.titech.ac.jp> <1375033.GM90FNPWn2@gentoovm> <504D1726.3090608@necom830.hpcl.titech.ac.jp> <504DE7CA.80803@foobar.org> <504E52E9.6010102@necom830.hpcl.titech.ac.jp> <19751.1347364371@turing-police.cc.vt.edu> <504FB81D.2090309@necom830.hpcl.titech.ac.jp> Message-ID: On 9/11/12, Masataka Ohta wrote: > (2012/09/11 20:52), valdis.kletnieks at vt.edu wrote: >> On Tue, 11 Sep 2012 05:51:53 +0900, Masataka Ohta said: > No, I don't. > It's Jimmy, Eliot and you who are relying on a non standard track > RFC to deny RFC3102 and all the non standard track RFCs, which is > the silly paradox. Straw man. We don't rely on a non standard track RFC to "deny" rfc3102 having significance, furthermore, we don't indicate that all non standard track RFCs are of no significance; he's just being nice about it. The rfc1796 just happens to contain a useful explanation. If you don't read 3102 selectively, ignoring the disclaimers, you can very easily see that RSIP is not considered a viable standard in its present form, but possibly someone /might/ find it suitable for experimental use. RFC3102 denies itself, and please read the IESG note at the top of the document; where fundamental problems are admitted to with regards to interoperability and transparency. "This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind." Which means that RSIP has not received technical review or acceptance like standards have. The protocol doesn't have to work for an Experimental or Informational RFC to be published. The non-standards track rfc might still contain useful information, but 3102 is a little more authoritative than someone's blog entry. There are other non-standards track RFCs that are more important, take RFC 1149 for example.... Just being a RFC alone doesn't make a document important or not, reliable or not, anymore than a news article is important or not just because it appeared on a certain bulletin board. For now, and in its current form, I will discount the relevance or usefulness of the experimental protocol described in rc3102. > >> Standard or not, we have Christian Huitema, John Postel, and Steve >> Crocker > > If you have some respect to them, don't involve them with your > silly paradox. -- -JH From naveen at lastninja.net Tue Sep 11 22:16:32 2012 From: naveen at lastninja.net (Naveen Nathan) Date: Tue, 11 Sep 2012 20:16:32 -0700 Subject: Heads-Up: GoDaddy Broke the Interwebs... In-Reply-To: References: Message-ID: <20120912031632.GD54523@armakuni.lastninja.net> > Well, mostly I'm taking GoDaddy at their word that this was not a DoS attack. > > I also believe it was related to BGP, and am happy to get more info. But we are discussing Anonymous vs. Self-inflicted wound here. I'm skeptical, BGPlay (http://bgplay.routeviews.org/) doesn't show any withdrawn routes for any of their prefixes over Sep 9-11. Infact, their BGP operation looks fairly operational during the time from what I can gather. So, it would be nice to get more info. - Naveen From morrowc.lists at gmail.com Tue Sep 11 22:43:31 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 11 Sep 2012 23:43:31 -0400 Subject: Heads-Up: GoDaddy Broke the Interwebs... In-Reply-To: <20120912031632.GD54523@armakuni.lastninja.net> References: <20120912031632.GD54523@armakuni.lastninja.net> Message-ID: On Tue, Sep 11, 2012 at 11:16 PM, Naveen Nathan wrote: >> Well, mostly I'm taking GoDaddy at their word that this was not a DoS attack. >> >> I also believe it was related to BGP, and am happy to get more info. But we are discussing Anonymous vs. Self-inflicted wound here. > > I'm skeptical, BGPlay (http://bgplay.routeviews.org/) doesn't show any withdrawn routes for any of their prefixes over Sep 9-11. Infact, their BGP operation looks fairly operational during the time from what I can gather. a bgp error doesn't HAVE to mean that they withdrew (or even re-announced!) anything to the outside world, does it? for instance: border-router -> internet redistribute your aggregate networks from statics to Null0 on the border-router accept full routes so you can send them to the other borders and make good decisions at the external edge border-router -> internal send default or some version of default via a fitler to internal datacenter routers/aggregation/distribution devices. accept from them (maybe) local subnets that are part of your aggregates now, accidently remove the filter content for the sessions between the border and internal ... oops, your internal devices bounce with 'corrupted tables' (blown tables)... you still send your aggs steadily to the interwebs, wee! -chris From kyle.creyts at gmail.com Tue Sep 11 23:18:25 2012 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Tue, 11 Sep 2012 21:18:25 -0700 Subject: Heads-Up: GoDaddy Broke the Interwebs... In-Reply-To: References: <20120912031632.GD54523@armakuni.lastninja.net> Message-ID: +1 Announcing a prefix doesn't mean that the traffic to those IPs found within shall ever arrive. On Tue, Sep 11, 2012 at 8:43 PM, Christopher Morrow wrote: > On Tue, Sep 11, 2012 at 11:16 PM, Naveen Nathan wrote: >>> Well, mostly I'm taking GoDaddy at their word that this was not a DoS attack. >>> >>> I also believe it was related to BGP, and am happy to get more info. But we are discussing Anonymous vs. Self-inflicted wound here. >> >> I'm skeptical, BGPlay (http://bgplay.routeviews.org/) doesn't show any withdrawn routes for any of their prefixes over Sep 9-11. Infact, their BGP operation looks fairly operational during the time from what I can gather. > > a bgp error doesn't HAVE to mean that they withdrew (or even > re-announced!) anything to the outside world, does it? > > for instance: > border-router -> internet > redistribute your aggregate networks from statics to Null0 on the > border-router > accept full routes so you can send them to the other borders and > make good decisions at the external edge > > border-router -> internal > send default or some version of default via a fitler to internal > datacenter routers/aggregation/distribution devices. > accept from them (maybe) local subnets that are part of your aggregates > > now, accidently remove the filter content for the sessions between the > border and internal ... oops, your internal devices bounce with > 'corrupted tables' (blown tables)... you still send your aggs steadily > to the interwebs, wee! > > -chris > -- Kyle Creyts Information Assurance Professional BSidesDetroit Organizer From kyle.creyts at gmail.com Tue Sep 11 23:19:32 2012 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Tue, 11 Sep 2012 21:19:32 -0700 Subject: Heads-Up: GoDaddy Broke the Interwebs... In-Reply-To: References: <20120912031632.GD54523@armakuni.lastninja.net> Message-ID: (Arrive at the intended destination, that is) On Tue, Sep 11, 2012 at 9:18 PM, Kyle Creyts wrote: > +1 > > Announcing a prefix doesn't mean that the traffic to those IPs found > within shall ever arrive. > > On Tue, Sep 11, 2012 at 8:43 PM, Christopher Morrow > wrote: >> On Tue, Sep 11, 2012 at 11:16 PM, Naveen Nathan wrote: >>>> Well, mostly I'm taking GoDaddy at their word that this was not a DoS attack. >>>> >>>> I also believe it was related to BGP, and am happy to get more info. But we are discussing Anonymous vs. Self-inflicted wound here. >>> >>> I'm skeptical, BGPlay (http://bgplay.routeviews.org/) doesn't show any withdrawn routes for any of their prefixes over Sep 9-11. Infact, their BGP operation looks fairly operational during the time from what I can gather. >> >> a bgp error doesn't HAVE to mean that they withdrew (or even >> re-announced!) anything to the outside world, does it? >> >> for instance: >> border-router -> internet >> redistribute your aggregate networks from statics to Null0 on the >> border-router >> accept full routes so you can send them to the other borders and >> make good decisions at the external edge >> >> border-router -> internal >> send default or some version of default via a fitler to internal >> datacenter routers/aggregation/distribution devices. >> accept from them (maybe) local subnets that are part of your aggregates >> >> now, accidently remove the filter content for the sessions between the >> border and internal ... oops, your internal devices bounce with >> 'corrupted tables' (blown tables)... you still send your aggs steadily >> to the interwebs, wee! >> >> -chris >> > > > > -- > Kyle Creyts > > Information Assurance Professional > BSidesDetroit Organizer -- Kyle Creyts Information Assurance Professional BSidesDetroit Organizer From randy at psg.com Tue Sep 11 23:27:15 2012 From: randy at psg.com (Randy Bush) Date: Wed, 12 Sep 2012 13:27:15 +0900 Subject: Heads-Up: GoDaddy Broke the Interwebs... In-Reply-To: References: Message-ID: we do not know what happened. we have an apology, not an explanation or reasonable post mortem. all else is conjecturbation. randy From naveen at lastninja.net Wed Sep 12 01:43:57 2012 From: naveen at lastninja.net (Naveen Nathan) Date: Tue, 11 Sep 2012 23:43:57 -0700 Subject: Heads-Up: GoDaddy Broke the Interwebs... In-Reply-To: References: Message-ID: <20120912064357.GF54523@armakuni.lastninja.net> > we do not know what happened. we have an apology, not an explanation or > reasonable post mortem. all else is conjecturbation. Agreed. And as Chris and Kyle pointed out, there is no indication that the problems were present in the BGP DFT, and the issues could've occured over iBGP. I completely concur with this, and do not preclude it as an explanation. But I would just like to put this out there. In the past, GoDaddy has clashed with the Internet due to their initial stance on SOPA, which resulted in a noticeable loss of customers and generated a significant amount of bad press. Now, there's a lot of conjecture as to what caused their outage. But the most harm to GoDaddy would be reporting that they had a security breach or DoS/DDoS attack which would instill fear in their customer base. The major media outlets had already picked this up and started to report foul play by Anonymous, denial of service attacks, or whatever. To save face, it would make the most sense not to mention that a security breach or DoS/DDoS attack occured. Indicating a security breach would be immediate concern for any customer. If it was a DoS/DDoS attack, they're basically admitting that they don't have an infrastructure capable of withstanding or mitigating such attacks (which competitors such as Cloudfare do claim). So the best option would be to spread disinformation if either occured, and offer /generous/ service credit to earn back customer goodwill and confidence. This is simply why I remain skeptical. And as I said earlier, it would be nice to receive more information of what actually happened, if GoDaddy, or anyone in the know with GoDaddy, would oblige. - Naveen From samba_55 at hotmail.com Wed Sep 12 02:14:54 2012 From: samba_55 at hotmail.com (flower tailor) Date: Wed, 12 Sep 2012 10:14:54 +0300 Subject: No subject Message-ID: Delete me From ffo at sesp.ch Wed Sep 12 02:24:20 2012 From: ffo at sesp.ch (Florian Forster) Date: Wed, 12 Sep 2012 07:24:20 +0000 Subject: AW: In-Reply-To: References: Message-ID: You can delete your subscription yourself Near the end:" To unsubscribe from NANOG, get a password reminder, or change your subscription options enter your subscription email address:" http://mailman.nanog.org/mailman/listinfo/nanog -----Urspr?ngliche Nachricht----- Von: flower tailor [mailto:samba_55 at hotmail.com] Gesendet: Mittwoch, 12. September 2012 09:15 An: nanog at nanog.org Betreff: Delete me -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5525 bytes Desc: not available URL: From joly at punkcast.com Wed Sep 12 03:15:08 2012 From: joly at punkcast.com (Joly MacFie) Date: Wed, 12 Sep 2012 04:15:08 -0400 Subject: In-Reply-To: References: Message-ID: Isn't that by Engelbert Humperdinck? On Wed, Sep 12, 2012 at 3:14 AM, flower tailor wrote: > Delete me > > -- --------------------------------------------------------------- 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 paul at blacknight.com Wed Sep 12 06:08:16 2012 From: paul at blacknight.com (Paul Kelly :: Blacknight) Date: Wed, 12 Sep 2012 11:08:16 +0000 Subject: Google / Gmail SSL write errors Message-ID: <2DAB8DD43DA13045A341D800A4E91C9FF640CD@bkexchmbx02.blacknight.local> Hi All, Are any of you (that use Exim as their MTA) having SSL write errors in your exim logs when delivering e-mail to Gmail or Google addresses? it seems limited to Exim as we've got a lot of other MTAs that have no issues. it also appears to be specific to emails with attachments... Anyone aware of changes G have made regarding TLS delivery? Ta, Paul Paul Kelly Technical Director Microsoft Certified Partner Blacknight Internet Solutions ltd Cloud Hosting, Colocation, Dedicated servers IP Transit Services Tel: +353(0)599183072 Lo-call: 1850 929 929 DDI: +353 (0) 59 9183091 e-mail: paul at blacknight.com web: http://www.blacknight.com Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park, Sleaty Road, Graiguecullen, Carlow, Ireland Company No.: 370845 From hhoffman at ip-solutions.net Wed Sep 12 06:20:48 2012 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Wed, 12 Sep 2012 07:20:48 -0400 Subject: Google / Gmail SSL write errors Message-ID: From dot at dotat.at Wed Sep 12 06:30:38 2012 From: dot at dotat.at (Tony Finch) Date: Wed, 12 Sep 2012 12:30:38 +0100 Subject: Google / Gmail SSL write errors In-Reply-To: <2DAB8DD43DA13045A341D800A4E91C9FF640CD@bkexchmbx02.blacknight.local> References: <2DAB8DD43DA13045A341D800A4E91C9FF640CD@bkexchmbx02.blacknight.local> Message-ID: Paul Kelly :: Blacknight wrote: > > Are any of you (that use Exim as their MTA) having SSL write errors in > your exim logs when delivering e-mail to Gmail or Google addresses? I suggest asking this question on the exim-users mailing list. Phil Pennock has done a fair amount of work on TLS recently. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From james at freedomnet.co.nz Wed Sep 12 07:32:17 2012 From: james at freedomnet.co.nz (james jones) Date: Wed, 12 Sep 2012 08:32:17 -0400 Subject: In-Reply-To: References: Message-ID: I have days like that too! On Wed, Sep 12, 2012 at 4:15 AM, Joly MacFie wrote: > Isn't that by Engelbert Humperdinck? > > On Wed, Sep 12, 2012 at 3:14 AM, flower tailor > wrote: > > > Delete me > > > > > > > -- > --------------------------------------------------------------- > 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 rs at seastrom.com Wed Sep 12 07:47:18 2012 From: rs at seastrom.com (Robert E. Seastrom) Date: Wed, 12 Sep 2012 08:47:18 -0400 Subject: Google / Gmail SSL write errors In-Reply-To: <2DAB8DD43DA13045A341D800A4E91C9FF640CD@bkexchmbx02.blacknight.local> (Paul Kelly's message of "Wed, 12 Sep 2012 11:08:16 +0000") References: <2DAB8DD43DA13045A341D800A4E91C9FF640CD@bkexchmbx02.blacknight.local> Message-ID: <86r4q7l86h.fsf@seastrom.com> "Paul Kelly :: Blacknight" writes: > Are any of you (that use Exim as their MTA) having SSL write errors > in your exim logs when delivering e-mail to Gmail or Google > addresses? Don't see anything from here. More details when you post to exim-users couldn't hurt. root at valhalla [8] # grep 1TBmIa-0004lH-UH mainlog 2012-09-12 08:44:08 1TBmIa-0004lH-UH <= rs at seastrom.com U=rs P=local S=549 id=86vcfjl8br.fsf at seastrom.com 2012-09-12 08:44:10 1TBmIa-0004lH-UH => xxxxxxx at gmail.com R=dnslookup T=remote_smtp H=gmail-smtp-in.l.google.com [2607:f8b0:400d:c01::1a] X=TLSv1:RC4-SHA:128 2012-09-12 08:44:10 1TBmIa-0004lH-UH Completed root at valhalla [9] # -r From blair.trosper at gmail.com Tue Sep 11 13:41:09 2012 From: blair.trosper at gmail.com (Blair Trosper) Date: Tue, 11 Sep 2012 13:41:09 -0500 Subject: above.net issues In-Reply-To: <8065924C873D4452AE0FF4A368954860@gmail.com> References: <869B67C442824AA4A658843848A20D69@gmail.com> <8065924C873D4452AE0FF4A368954860@gmail.com> Message-ID: I've been seeing it all day from inside AS19108...in direct connection to a (huge frustration and) disruption of service from my end to AWS/EC2. On Tue, Sep 11, 2012 at 1:20 PM, Joe Williams wrote: > Oops, this was intended for the outages list but I suppose this list works too. > > > > -- > Name: Joseph A. Williams > Email: williams.joe at gmail.com > > > On Tuesday, September 11, 2012 at 11:18 AM, Joe Williams wrote: > >> Anyone experiencing packet loss on abovenet (to/from Ashburn)? We first got a round of packet loss around 8:45 PDT and then again just a few minutes ago. >> >> Thanks. >> >> -Joe >> >> >> -- >> Name: Joseph A. Williams >> Email: williams.joe at gmail.com (mailto:williams.joe at gmail.com) >> > From repstein at hostleasing.net Wed Sep 12 14:41:36 2012 From: repstein at hostleasing.net (Randy Epstein) Date: Wed, 12 Sep 2012 15:41:36 -0400 Subject: [NANOG-announce] REMINDER: Upcoming NANOG mail list maintenance notification - 13-Sept-2012 Message-ID: Reminder of the upcoming Mail List service scheduled for Thursday, September 13, 2012 beginning at 6 am Eastern, expected to last no more than 30 minutes. Regards, Randy Epstein NANOG CC Chair On behalf of the NANOG Communications Committee -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From drew.weaver at thenap.com Wed Sep 12 15:13:15 2012 From: drew.weaver at thenap.com (Drew Weaver) Date: Wed, 12 Sep 2012 16:13:15 -0400 Subject: Heads-Up: GoDaddy Broke the Interwebs... In-Reply-To: <20120912064357.GF54523@armakuni.lastninja.net> References: <20120912064357.GF54523@armakuni.lastninja.net> Message-ID: I just wanted to make one quick point. Cloudflare is not a competitor of GoDaddy in any sense except that they are "involved in DNS" and they both have a web site. CloudFlare has also been known to "give up" and dump small to medium sized PPS attacks onto the end target without notification and there doesn't seem to be any threshold or policy in place for when they do that. Thanks, -Drew -----Original Message----- From: Naveen Nathan [mailto:naveen at lastninja.net] Sent: Wednesday, September 12, 2012 2:44 AM To: nanog at nanog.org Subject: Re: Heads-Up: GoDaddy Broke the Interwebs... > we do not know what happened. we have an apology, not an explanation > or reasonable post mortem. all else is conjecturbation. Agreed. And as Chris and Kyle pointed out, there is no indication that the problems were present in the BGP DFT, and the issues could've occured over iBGP. I completely concur with this, and do not preclude it as an explanation. But I would just like to put this out there. In the past, GoDaddy has clashed with the Internet due to their initial stance on SOPA, which resulted in a noticeable loss of customers and generated a significant amount of bad press. Now, there's a lot of conjecture as to what caused their outage. But the most harm to GoDaddy would be reporting that they had a security breach or DoS/DDoS attack which would instill fear in their customer base. The major media outlets had already picked this up and started to report foul play by Anonymous, denial of service attacks, or whatever. To save face, it would make the most sense not to mention that a security breach or DoS/DDoS attack occured. Indicating a security breach would be immediate concern for any customer. If it was a DoS/DDoS attack, they're basically admitting that they don't have an infrastructure capable of withstanding or mitigating such attacks (which competitors such as Cloudfare do claim). So the best option would be to spread disinformation if either occured, and offer /generous/ service credit to earn back customer goodwill and confidence. This is simply why I remain skeptical. And as I said earlier, it would be nice to receive more information of what actually happened, if GoDaddy, or anyone in the know with GoDaddy, would oblige. - Naveen From source_route at yahoo.com Wed Sep 12 17:23:00 2012 From: source_route at yahoo.com (Philip Lavine) Date: Wed, 12 Sep 2012 15:23:00 -0700 (PDT) Subject: Layer2 over Layer3 Message-ID: <1347488580.64588.YahooMailNeo@web121701.mail.ne1.yahoo.com> To all, ? I am trying to extend a layer2 connection over Layer 3 so I can have redundant Layer connectivity between my HQ and colo site. The reason I need this is so I can give the "appeareance" that there is one gateway and that both data centers can share the same Layer3 subnet (which I am announcing via BGP to 2 different vendors). ? I have 2 ASR's. Will EoMPLS work or is there another option? ? Philip From jeff.tantsura at ericsson.com Wed Sep 12 17:29:37 2012 From: jeff.tantsura at ericsson.com (Jeff Tantsura) Date: Wed, 12 Sep 2012 18:29:37 -0400 Subject: Layer2 over Layer3 In-Reply-To: <1347488580.64588.YahooMailNeo@web121701.mail.ne1.yahoo.com> References: <1347488580.64588.YahooMailNeo@web121701.mail.ne1.yahoo.com> Message-ID: <0DB31AE4-B188-4D32-B346-D21D9FF06A6C@ericsson.com> l2tpv3 Regards, Jeff On Sep 12, 2012, at 19:23, "Philip Lavine" wrote: > To all, > > I am trying to extend a layer2 connection over Layer 3 so I can have redundant Layer connectivity between my HQ and colo site. The reason I need this is so I can give the "appeareance" that there is one gateway and that both data centers can share the same Layer3 subnet (which I am announcing via BGP to 2 different vendors). > > I have 2 ASR's. Will EoMPLS work or is there another option? > > Philip From mohamed.abosree at gmail.com Wed Sep 12 17:33:59 2012 From: mohamed.abosree at gmail.com (mohamed Osama Saad Abo sree) Date: Thu, 13 Sep 2012 00:33:59 +0200 Subject: Layer2 over Layer3 In-Reply-To: <1347488580.64588.YahooMailNeo@web121701.mail.ne1.yahoo.com> References: <1347488580.64588.YahooMailNeo@web121701.mail.ne1.yahoo.com> Message-ID: hello philip, for ethernet over mpls you can use gre tunnel and run mpls over that tunnel or you can go directly for l2tpv3 which give you the ability to run l2vpn over l3 ip routing with no need for mpls. BR, Mohamed Abosree On 9/13/12, Philip Lavine wrote: > To all, > > I am trying to extend a layer2 connection over Layer 3 so I can have > redundant Layer connectivity between my HQ and colo site. The reason I need > this is so I can give the "appeareance" that there is one gateway and that > both data centers can share the same Layer3 subnet (which I am announcing > via BGP to 2 different vendors). > > I have 2 ASR's. Will EoMPLS work or is there another option? > > Philip > -- Live As If You Were To Die Tomorrow. Learn As If You Were To Live Forever. From pvinci at VinciConsulting.com Wed Sep 12 17:37:34 2012 From: pvinci at VinciConsulting.com (Paul Vinciguerra) Date: Wed, 12 Sep 2012 22:37:34 +0000 Subject: Layer2 over Layer3 In-Reply-To: <1347488580.64588.YahooMailNeo@web121701.mail.ne1.yahoo.com> References: <1347488580.64588.YahooMailNeo@web121701.mail.ne1.yahoo.com> Message-ID: <6E5736BD68F770449C74FBAD975F807C8FE98A09@NYDC-EXCH01.vinci-consulting-corp.local> ASR supports OTV if you can do multicast over L3. Although, you may not need L2 extensions in the end. -----Original Message----- From: Philip Lavine [mailto:source_route at yahoo.com] Sent: Wednesday, September 12, 2012 6:23 PM To: NANOG list Subject: Layer2 over Layer3 To all, ? I am trying to extend a layer2 connection over Layer 3 so I can have redundant Layer connectivity between my HQ and colo site. The reason I need this is so I can give the "appeareance" that there is one gateway and that both data centers can share the same Layer3 subnet (which I am announcing via BGP to 2 different vendors). ? I have 2 ASR's. Will EoMPLS work or is there another option? ? Philip From mfidelman at meetinghouse.net Wed Sep 12 19:18:32 2012 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Wed, 12 Sep 2012 20:18:32 -0400 Subject: APIs for domain registration and management Message-ID: <50512658.5040904@meetinghouse.net> Hi Folks, I expect folks on NANOG would know: Are there any domain registrars who provide APIs for managing domains and/or DNS records? It's kind of a pain managing large numbers of domains via klunky web interfaces. It sure would be nice to tie registry accounts into equipment inventory management systems. Thanks, Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From jeroen at unfix.org Wed Sep 12 19:35:04 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 13 Sep 2012 02:35:04 +0200 Subject: APIs for domain registration and management In-Reply-To: <50512658.5040904@meetinghouse.net> References: <50512658.5040904@meetinghouse.net> Message-ID: <50512A38.5040200@unfix.org> On 2012-09-13 02:18 , Miles Fidelman wrote: > Hi Folks, > > I expect folks on NANOG would know: Are there any domain registrars who > provide APIs for managing domains and/or DNS records? It's kind of a > pain managing large numbers of domains via klunky web interfaces. It > sure would be nice to tie registry accounts into equipment inventory > management systems. Check for a google(DNS EPP) for a lot of info on a standardized protocols, though typically a registrar will provide a custom interface. Many of the more established providers do this and it is more or less a requirement for DNSSEC to work. google(DNSSEC glue) and you get a list of providers who do DNSSEC and who likely also have an automated interface for this. As a note GPG + Joker seem to be the popular ones for this. Greets, Jeroen From sadiq at asininetech.com Wed Sep 12 19:40:14 2012 From: sadiq at asininetech.com (Sadiq Saif) Date: Wed, 12 Sep 2012 20:40:14 -0400 Subject: APIs for domain registration and management In-Reply-To: <50512658.5040904@meetinghouse.net> References: <50512658.5040904@meetinghouse.net> Message-ID: On Wed, Sep 12, 2012 at 8:18 PM, Miles Fidelman wrote: > Hi Folks, > > I expect folks on NANOG would know: Are there any domain registrars who > provide APIs for managing domains and/or DNS records? It's kind of a pain > managing large numbers of domains via klunky web interfaces. It sure would > be nice to tie registry accounts into equipment inventory management > systems. > > Thanks, > > Miles Fidelman > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > Hexonet (http://hexonet.net) has quite an extensive API as far as I can tell from their API manuals page available via the control panel. I have personally not used it but have great praises about it from other people. -- Sadiq S O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From john.yocum at fluidhosting.com Wed Sep 12 19:43:58 2012 From: john.yocum at fluidhosting.com (John T. Yocum) Date: Wed, 12 Sep 2012 17:43:58 -0700 Subject: APIs for domain registration and management In-Reply-To: <50512658.5040904@meetinghouse.net> References: <50512658.5040904@meetinghouse.net> Message-ID: <50512C4E.5070901@fluidhosting.com> On 9/12/2012 5:18 PM, Miles Fidelman wrote: > Hi Folks, > > I expect folks on NANOG would know: Are there any domain registrars who > provide APIs for managing domains and/or DNS records? It's kind of a > pain managing large numbers of domains via klunky web interfaces. It > sure would be nice to tie registry accounts into equipment inventory > management systems. > > Thanks, > > Miles Fidelman > OpenSRS and Enom both have APIs. --John From mfidelman at meetinghouse.net Wed Sep 12 19:46:20 2012 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Wed, 12 Sep 2012 20:46:20 -0400 Subject: APIs for domain registration and management - followup In-Reply-To: <50512C4E.5070901@fluidhosting.com> References: <50512658.5040904@meetinghouse.net> <50512C4E.5070901@fluidhosting.com> Message-ID: <50512CDC.2050509@meetinghouse.net> John T. Yocum wrote: >> I expect folks on NANOG would know: Are there any domain registrars who >> provide APIs for managing domains and/or DNS records? It's kind of a >> pain managing large numbers of domains via klunky web interfaces. It >> sure would be nice to tie registry accounts into equipment inventory >> management systems. >> > OpenSRS and Enom both have APIs. > It looks like NetSol does as well, but can't seem to find anything for GoDaddy (a shame, we have a lot of domains with them). Anybody know of a CMDB that integrates with OpenSRS or equivalent? Thanks again, Miles -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From david at davidswafford.com Wed Sep 12 21:46:28 2012 From: david at davidswafford.com (David Swafford) Date: Wed, 12 Sep 2012 19:46:28 -0700 Subject: Layer2 over Layer3 In-Reply-To: <6E5736BD68F770449C74FBAD975F807C8FE98A09@NYDC-EXCH01.vinci-consulting-corp.local> References: <1347488580.64588.YahooMailNeo@web121701.mail.ne1.yahoo.com> <6E5736BD68F770449C74FBAD975F807C8FE98A09@NYDC-EXCH01.vinci-consulting-corp.local> Message-ID: Hey Philip, Any Transport over MPLS will do this too. Here's a link to an example setup of two sites where just L3 connectivity exists between them: https://w.ntwk.cc/working-on-atompls/. In that setup, I have just IPSEC VPN connecting the two locations, but have an 802.1q trunk extended between both. In the example configs, Fa0/1 on both ends is a transparent L2 connection. The boxes used here were 3725s on 12.4T. David. On Wed, Sep 12, 2012 at 3:37 PM, Paul Vinciguerra wrote: > ASR supports OTV if you can do multicast over L3. Although, you may not need L2 extensions in the end. > > -----Original Message----- > From: Philip Lavine [mailto:source_route at yahoo.com] > Sent: Wednesday, September 12, 2012 6:23 PM > To: NANOG list > Subject: Layer2 over Layer3 > > To all, > > I am trying to extend a layer2 connection over Layer 3 so I can have redundant Layer connectivity between my HQ and colo site. The reason I need this is so I can give the "appeareance" that there is one gateway and that both data centers can share the same Layer3 subnet (which I am announcing via BGP to 2 different vendors). > > I have 2 ASR's. Will EoMPLS work or is there another option? > > Philip > From me at anuragbhatia.com Thu Sep 13 03:39:10 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Thu, 13 Sep 2012 14:09:10 +0530 Subject: Softlayer/Network layer partial outage in Asian region? Message-ID: Seems like Softlayer/Network layer having rouitng glitches in Asia. Their prefix 216.12.192.0/19 is not working in South East. Route goes till Singapore router and times out there. traceroute to hostgator.com (216.12.194.67), 30 hops max, 60 byte packets 1 router.local (192.168.1.1) 1.576 ms 2.025 ms 2.508 ms 2 117.212.40.1 (117.212.40.1) 26.500 ms 29.397 ms 31.717 ms 3 218.248.173.46 (218.248.173.46) 35.014 ms 36.184 ms 38.806 ms 4 115.249.245.198 (115.249.245.198) 50.224 ms 54.037 ms 56.476 ms 5 115.255.252.149 (115.255.252.149) 100.129 ms 101.235 ms 106.338 ms 6 62.216.147.249 (62.216.147.249) 115.066 ms 116.228 ms 118.407 ms 7 ge-1-0-0.0.cjr02.chn001.flagtel.com (62.216.135.226) 121.183 ms 83.215 ms so-7-0-0.0.ejr03.sin001.flagtel.com (62.216.128.73) 116.212 ms 8 so-7-1-0.0.ejr04.sin001.flagtel.com (62.216.128.153) 116.677 ms 118.551 ms 62.216.128.246 (62.216.128.246) 121.665 ms 9 p6453.sgw.equinix.com (202.79.197.19) 162.612 ms 163.006 ms 163.631 ms 10 ae12.bbr01.eq01.sng02.networklayer.com (120.29.215.102) 167.409 ms 169.761 ms 173.955 ms 11 ae6.dar02.sr03.sng01.networklayer.com (50.97.18.203) 177.675 ms 180.009 ms ae5.dar02.sr03.sng01.networklayer.com (50.97.18.199) 171.207 ms 12 po2.fcr01.sr03.sng01.networklayer.com (174.133.118.133) 180.555 ms * * 13 * * * 14 * * * I wonder what causes such issues? Clearly issue is within Softlayer's AS 36351. So is it like broken OSPF inside or iBGP? -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter| Google+ From aftab.siddiqui at gmail.com Thu Sep 13 03:55:17 2012 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Thu, 13 Sep 2012 13:55:17 +0500 Subject: Softlayer/Network layer partial outage in Asian region? In-Reply-To: References: Message-ID: No issues in other parts of the south east. But interestingly I just circled around the globe to reach the destination you mentioned as per the ptr. traceroute to 216.12.194.67 (216.12.194.67), 30 hops max, 60 byte packets 1 124.29.233.141 (124.29.233.141) 0.303 ms 0.413 ms 0.442 ms 2 ge-1-3-0-edge01-khi.cyber.net.pk (202.163.97.234) 0.426 ms 0.455 ms 0.535 ms 3 fe-0-1-0-edge2.khi.pk (61.5.158.252) 0.328 ms 0.413 ms 0.741 ms 4 khi77.pie.net.pk (221.120.205.77) 0.334 ms 0.363 ms 0.748 ms 5 rwp44.pie.net.pk (221.120.251.145) 12.567 ms 12.499 ms 12.534 ms 6 Sw275b-khi77c1.pie.net.pk (202.125.128.133) 0.736 ms 0.878 ms 1.420 ms 7 static-khi-ni01-swa.pie.net.pk (202.125.128.162) 1.725 ms 1.666 ms 1.704 ms 8 khi77.pie.net.pk (202.125.134.162) 140.570 ms 140.535 ms 140.479 ms 9 bbr01.eq01.ams01.networklayer.com (195.69.146.82) 137.135 ms 137.284 ms 136.565 ms 10 ae7.bbr02.eq01.ams02.networklayer.com (50.97.18.213) 142.482 ms 142.436 ms 142.362 ms 11 ae0.bbr02.tg01.lon01.networklayer.com (50.97.18.210) 136.787 ms 137.905 ms 137.632 ms 12 ae7.bbr01.tg01.lon01.networklayer.com (50.97.18.206) 138.000 ms 137.772 ms 137.729 ms 13 ae1.bbr02.tl01.nyc01.networklayer.com (50.97.18.204) 238.551 ms 244.034 ms 241.251 ms 14 ae1.bbr01.eq01.chi01.networklayer.com (173.192.18.132) 262.464 ms 261.560 ms 262.212 ms 15 ae7.bbr02.eq01.chi01.networklayer.com (173.192.18.171) 259.721 ms 261.217 ms 261.276 ms 16 ae1.bbr02.cs01.den01.networklayer.com (173.192.18.131) 286.070 ms 284.922 ms 284.897 ms 17 ae1.bbr01.eq01.sjc02.networklayer.com (173.192.18.148) 312.360 ms 313.124 ms 312.879 ms 18 ae7.bbr02.eq01.sjc02.networklayer.com (173.192.18.165) 311.651 ms 316.019 ms 316.875 ms 19 ae0.bbr01.eq01.tok01.networklayer.com (50.97.18.161) 409.615 ms 413.119 ms 413.175 ms 20 ae1.bbr01.eq01.sng02.networklayer.com (50.97.18.165) 273.512 ms 272.463 ms 273.586 ms 21 ae5.dar02.sr03.sng01.networklayer.com (50.97.18.199) 274.449 ms 274.857 ms ae5.dar01.sr03.sng01.networklayer.com (50.97.18.197) 274.261 ms 22 po1.fcr01.sr03.sng01.networklayer.com (174.133.118.131) 271.876 ms po2.fcr01.sr03.sng01.networklayer.com (174.133.118.133) 272.995 ms * 23 216.12.194.67-static.reverse.softlayer.com (216.12.194.67) 275.354 ms 314.130 ms 314.024 ms [kindly excuse for the noise] Regards, Aftab A. Siddiqui On Thu, Sep 13, 2012 at 1:39 PM, Anurag Bhatia wrote: > Seems like Softlayer/Network layer having rouitng glitches in Asia. > > > Their prefix 216.12.192.0/19 is not working in South East. Route goes till > Singapore router and times out there. > > > traceroute to hostgator.com (216.12.194.67), 30 hops max, 60 byte packets > 1 router.local (192.168.1.1) 1.576 ms 2.025 ms 2.508 ms > 2 117.212.40.1 (117.212.40.1) 26.500 ms 29.397 ms 31.717 ms > 3 218.248.173.46 (218.248.173.46) 35.014 ms 36.184 ms 38.806 ms > 4 115.249.245.198 (115.249.245.198) 50.224 ms 54.037 ms 56.476 ms > 5 115.255.252.149 (115.255.252.149) 100.129 ms 101.235 ms 106.338 ms > 6 62.216.147.249 (62.216.147.249) 115.066 ms 116.228 ms 118.407 ms > 7 ge-1-0-0.0.cjr02.chn001.flagtel.com (62.216.135.226) 121.183 ms > 83.215 ms so-7-0-0.0.ejr03.sin001.flagtel.com (62.216.128.73) 116.212 ms > 8 so-7-1-0.0.ejr04.sin001.flagtel.com (62.216.128.153) 116.677 ms > 118.551 ms 62.216.128.246 (62.216.128.246) 121.665 ms > 9 p6453.sgw.equinix.com (202.79.197.19) 162.612 ms 163.006 ms 163.631 > ms > 10 ae12.bbr01.eq01.sng02.networklayer.com (120.29.215.102) 167.409 ms > 169.761 ms 173.955 ms > 11 ae6.dar02.sr03.sng01.networklayer.com (50.97.18.203) 177.675 ms > 180.009 ms ae5.dar02.sr03.sng01.networklayer.com (50.97.18.199) 171.207 > ms > 12 po2.fcr01.sr03.sng01.networklayer.com (174.133.118.133) 180.555 ms * > * > 13 * * * > 14 * * * > > > > I wonder what causes such issues? Clearly issue is within Softlayer's > AS 36351. So is it like broken OSPF inside or iBGP? > > > > > > -- > > > From troy at yort.com Thu Sep 13 05:23:32 2012 From: troy at yort.com (Troy Davis) Date: Thu, 13 Sep 2012 03:23:32 -0700 Subject: APIs for domain registration and management In-Reply-To: <50512658.5040904@meetinghouse.net> References: <50512658.5040904@meetinghouse.net> Message-ID: On Wed, Sep 12, 2012 at 5:18 PM, Miles Fidelman wrote: > > I expect folks on NANOG would know: Are there any domain registrars who > provide APIs for managing domains and/or DNS records? It's kind of a pain > managing large numbers of domains I've been very happy with DNSimple, which has an incredibly complete and very RESTful API. It supports registration, DNS, SSL certificates (purchasing and signing), transfers, email forwarding, white-label/vanity nameservers, portal users and domain-level access control, and a bunch of other stuff: https://dnsimple.com/documentation/api. Scroll down to "Contents." Basically they treat the API as a first-class citizen. Their support has been a joy to interact with. It works with DitchDaddy to migrate from GoDaddy: https://github.com/jm/ditchdaddy. I've never used it. Troy -- https://papertrailapp.com/ -- logs made fun. ish. From fernando at gont.com.ar Thu Sep 13 07:21:17 2012 From: fernando at gont.com.ar (Fernando Gont) Date: Thu, 13 Sep 2012 09:21:17 -0300 Subject: ipv6mon v1.0 released! (IPv6 address monitoring daemon) Message-ID: <5051CFBD.9040608@gont.com.ar> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Folks, We are pleased to announce the release of ipv6mon v1.0! ** Description ** ipv6mon () is a tool for monitoring IPv6 address usage on a local network. It is meant to be particularly useful in networks that employ IPv6 Stateless Address Auto-Configuration (as opposed to DHCPv6), where address assignment is decentralized and there is no central server that records which IPv6 addresses have been assigned to which nodes during which period of time. ipv6mon employs active probing to discover IPv6 addresses in use, and determine whether such addresses remain active. ** Latest release ** The latest release of ipv6mon is v1.0, and is available at: ** Documentation ** PDF versions of the ipv6mon manuals are available on-line at: ** GIT repository ** The GIT repository for the ipv6mon is: ** IPv6 security trainings ** Development of ipv6mon is partially supported through our IPv6 security trainings. Please consider attending one of our upcoming trainings Follow us on twitter: @SI6Networks Best regards, - -- Fernando Gont SI6 Networks e-mail: fgont at si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 - -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJQUc+lAAoJEJbuqe/Qdv/xHc0IAJ8rTfjwisnAKxDrlXiQpNjZ 3yJbWE3LPEj5wTkoqHgOkd0p6h+hEkz9yaxlSyoZTJAP/N2IOvmdWdmXpV5umTen cVRxn5HopYRL4kEDRu5rc7DiwWXPXiuAZD8uvyyc/u/TiLHJXePjK1Cicp1W/iIZ cSBAKcjMGpaYX0i/Vj2rN36gytrjW0jRlF8e3+64FHss1+poEG58TBLcZyckZkTZ TqE1G184gkAPAa8DryT8U1k68ZWWO/2gWMsLR/nTxjUmSZHamPrZHN2IHlhdC5vu ABBK/M13MIepNfnFlXfBMCTMy0CQU87kRwo5OF+1M7NAeshovmgjtOp+idAsZec= =a76/ -----END PGP SIGNATURE----- From jeroen at unfix.org Thu Sep 13 07:31:00 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 13 Sep 2012 14:31:00 +0200 Subject: ipv6mon v1.0 released! (IPv6 address monitoring daemon) In-Reply-To: <5051CFBD.9040608@gont.com.ar> References: <5051CFBD.9040608@gont.com.ar> Message-ID: <5051D204.7070806@unfix.org> On 2012-09-13 14:21 , Fernando Gont wrote: > Folks, > > We are pleased to announce the release of ipv6mon v1.0! > > ** Description ** > > ipv6mon () is a tool for > monitoring IPv6 address usage on a local network. It is meant to be > particularly useful in networks that employ IPv6 Stateless Address > Auto-Configuration (as opposed to DHCPv6), where address assignment is > decentralized and there is no central server that records which IPv6 > addresses have been assigned to which nodes during which period of time. > > ipv6mon employs active probing to discover IPv6 addresses in use, and > determine whether such addresses remain active. You mean, like what NDPMon has been delivering for several years already: >From http://ndpmon.sourceforge.net/ -- The Neighbor Discovery Protocol Monitor (NDPMon) is a diagnostic software application used by Internet Protocol version 6 network administrators for monitoring ICMPv6 packets. NDPMon observes the local network for anomalies in the function of nodes using Neighbor Discovery Protocol (NDP) messages, especially during the Stateless Address Autoconfiguration. When an NDP message is flagged, it notifies the administrator by writing to the syslog or by sending an email report. It may also execute a user-defined script. For IPv6, NDPMon is an equivalent of Arpwatch for IPv4, and has similar basic features with added attacks detection. NDPMon runs on Linux distributions (available in Debian repositories and in Ubuntu 12.10 and later), Mac OS X, FreeBSD (available as port), NetBSD and OpenBSD. It uses a configuration file containing the expected and valid behavior for nodes and routers on the link. This includes the routers addresses (MAC and IP) and the prefixes, flags and parameters announced. NDPMon also maintains up-to-date a list of neighbors on the link and watches all advertisements and changes. It permits to track the usage of cryptographically generated interface identifiers or temporary global addresses when Privacy extensions are enabled (default behavior in Ubuntu and Windows for example), or Cryptographically Generated Addresses are in use. -- arpwatch + ndpmon are kind of a requirement in a network where you are not sure who can plug-in to it (especially when not using 802.1x on links or when having a 'weak'/known password for the wireless), are they not? :) Greets, Jeroen From fernando at gont.com.ar Thu Sep 13 07:41:39 2012 From: fernando at gont.com.ar (Fernando Gont) Date: Thu, 13 Sep 2012 09:41:39 -0300 Subject: ipv6mon v1.0 released! (IPv6 address monitoring daemon) In-Reply-To: <5051D204.7070806@unfix.org> References: <5051CFBD.9040608@gont.com.ar> <5051D204.7070806@unfix.org> Message-ID: <5051D483.3080806@gont.com.ar> On 09/13/2012 09:31 AM, Jeroen Massar wrote: >> ipv6mon employs active probing to discover IPv6 addresses in use, and >> determine whether such addresses remain active. > > You mean, like what NDPMon has been delivering for several years already: Does NDPMon do active probing? If it doesn't, it's not "like what NDPMon has been delivering for several years already". For instance, ipv6mon is not meant to be analogous to arpwatch, and is *not* meant to detect ND attacks. Thanks, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From smeuse at mara.org Thu Sep 13 07:46:39 2012 From: smeuse at mara.org (Steve Meuse) Date: Thu, 13 Sep 2012 08:46:39 -0400 Subject: ipv6mon v1.0 released! (IPv6 address monitoring daemon) In-Reply-To: <5051D204.7070806@unfix.org> References: <5051CFBD.9040608@gont.com.ar> <5051D204.7070806@unfix.org> Message-ID: On Thu, Sep 13, 2012 at 8:31 AM, Jeroen Massar wrote: > > You mean, like what NDPMon has been delivering for several years already: > > Having a choice is never a bad thing(tm). -Steve From paul at blacknight.com Thu Sep 13 07:56:28 2012 From: paul at blacknight.com (Paul Kelly :: Blacknight) Date: Thu, 13 Sep 2012 12:56:28 +0000 Subject: ipv6mon v1.0 released! (IPv6 address monitoring daemon) In-Reply-To: <20120913124713.EACA633C100@merlin.blacknight.ie> References: <5051CFBD.9040608@gont.com.ar> <5051D204.7070806@unfix.org> <20120913124713.EACA633C100@merlin.blacknight.ie> Message-ID: <2DAB8DD43DA13045A341D800A4E91C9FF8C279@bkexchmbx01.blacknight.local> > > > > You mean, like what NDPMon has been delivering for several years > already: > > > > > Having a choice is never a bad thing(tm). > +1 From jtk at cymru.com Thu Sep 13 08:22:57 2012 From: jtk at cymru.com (John Kristoff) Date: Thu, 13 Sep 2012 08:22:57 -0500 Subject: Real ops talking to future ops Message-ID: <20120913082257.3bfcd845@localhost> Hello friends, I've made this call once before and the response was very positive so I thought I'd do it again. As some of you know, I occasionally teach networking classes at DePaul University in Chicago. What has gone over extremely well in the past is when I've had a real op come talk to the students, even if its just about what they do on a daily basis. If any of you are in or around the Loop in Chicago area on a Tuesday night between September and November of this year and wouldn't mind sharing what you know and/or what you do, I would be forever grateful if you do so with my class. Dinner and drinks before and/or after are on me. I'm not asking for anything polished. If you've presented something recently that you think a computer science undergrad should be able to grasp or even if just have enable, your future ops want you to tell them about it. ...and yes, often times other instructors, and unfortunately the required book, spend an inordinate amount of time talking about classful addressing. So you'll be doing the world a favor and maybe even me, by saying some things I'm not the only one saying to them before they hit the interview circuit. Here's the course home page with links to previous versions of it: Thank you, John From jra at baylink.com Thu Sep 13 09:29:05 2012 From: jra at baylink.com (Jay Ashworth) Date: Thu, 13 Sep 2012 10:29:05 -0400 (EDT) Subject: Big Temporary Networks In-Reply-To: <33083487.24450.1347546188561.JavaMail.root@benjamin.baylink.com> Message-ID: <11570158.24452.1347546545009.JavaMail.root@benjamin.baylink.com> My best friend just got back from Chicon 7 last week, this year's World Science Fiction Convention. He tells me that the networking at the con hotel, the Chicago Hyatt, was miserable, whether wired or wireless... and that Sprint 4G wasn't much better. I'm talking to the people who will probably be, in 2015, running the first Worldcon I can practically drive to, in Orlando, at -- I think -- the Disney World Resort. I've told them how critical the issue is for this market; they, predictably, replied "We look forward to your patch". :-} I know without a doubt that this is a problem NANOG PCs deal with 3 times a year; is there any collected wisdom on the web already about how this has been dealt with, that I can pore over? Pointers to good archive threads? If not, do any of the people who've already done have 5 minutes to chime in on what they did and what they learned? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jeroen at unfix.org Thu Sep 13 09:37:30 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 13 Sep 2012 16:37:30 +0200 Subject: Big Temporary Networks In-Reply-To: <11570158.24452.1347546545009.JavaMail.root@benjamin.baylink.com> References: <11570158.24452.1347546545009.JavaMail.root@benjamin.baylink.com> Message-ID: <5051EFAA.8080005@unfix.org> On 2012-09-13 16:29 , Jay Ashworth wrote: [..] > If not, do any of the people who've already done have 5 minutes to chime in > on what they did and what they learned? You might want to go through the network presentations given for IETF, NANOG/ARIN and last but definitely not least: CCC congress + camps. eg: http://events.ccc.de/camp/2007/Fahrplan/events/2043.en.html Typically though it requires people who have done it before with proper equipment to get a network up and running properly ;) Greets, Jeroen From tlyons at ivenue.com Thu Sep 13 09:44:01 2012 From: tlyons at ivenue.com (Todd Lyons) Date: Thu, 13 Sep 2012 07:44:01 -0700 Subject: APIs for domain registration and management In-Reply-To: <50512658.5040904@meetinghouse.net> References: <50512658.5040904@meetinghouse.net> Message-ID: On Wed, Sep 12, 2012 at 5:18 PM, Miles Fidelman wrote: > > I expect folks on NANOG would know: Are there any domain registrars who > provide APIs for managing domains and/or DNS records? It's kind of a pain Melbourne IT has a thorough POST API for all of the above and more. ...Todd -- The total budget at all receivers for solving senders' problems is $0. If you want them to accept your mail and manage it the way you want, send it the way the spec says to. --John Levine From mike.lyon at gmail.com Thu Sep 13 10:15:23 2012 From: mike.lyon at gmail.com (Mike Lyon) Date: Thu, 13 Sep 2012 08:15:23 -0700 Subject: Big Temporary Networks In-Reply-To: <5051EFAA.8080005@unfix.org> References: <11570158.24452.1347546545009.JavaMail.root@benjamin.baylink.com> <5051EFAA.8080005@unfix.org> Message-ID: <-6883397688863045482@unknownmsgid> I did a hack a thon a few months back in Palo Alto a few blocks down from PAIX. I used 6 of the Xirrius high density access points. About a 1000 attendees scattered over about 1/2 city block. 6 access points was overkill. Doing the same for a film festival here in a couple of weeks as well. -mike Sent from my iPhone On Sep 13, 2012, at 7:38, Jeroen Massar wrote: > On 2012-09-13 16:29 , Jay Ashworth wrote: > [..] >> If not, do any of the people who've already done have 5 minutes to chime in >> on what they did and what they learned? > > You might want to go through the network presentations given for IETF, > NANOG/ARIN and last but definitely not least: CCC congress + camps. > > eg: > http://events.ccc.de/camp/2007/Fahrplan/events/2043.en.html > > Typically though it requires people who have done it before with proper > equipment to get a network up and running properly ;) > > Greets, > Jeroen > > > From george.herbert at gmail.com Thu Sep 13 10:20:43 2012 From: george.herbert at gmail.com (George Herbert) Date: Thu, 13 Sep 2012 08:20:43 -0700 Subject: Big Temporary Networks In-Reply-To: <5051EFAA.8080005@unfix.org> References: <11570158.24452.1347546545009.JavaMail.root@benjamin.baylink.com> <5051EFAA.8080005@unfix.org> Message-ID: <6C9C6373-744E-4CF9-B03A-CAB01AD5C37F@gmail.com> On Sep 13, 2012, at 7:37 AM, Jeroen Massar wrote: > On 2012-09-13 16:29 , Jay Ashworth wrote: > [..] >> If not, do any of the people who've already done have 5 minutes to chime in >> on what they did and what they learned? > > You might want to go through the network presentations given for IETF, > NANOG/ARIN and last but definitely not least: CCC congress + camps. > > eg: > http://events.ccc.de/camp/2007/Fahrplan/events/2043.en.html > > Typically though it requires people who have done it before with proper > equipment to get a network up and running properly ;) > > Greets, > Jeroen > > > I know someone who did Interop's networking for a number of years and does it for various non-Worldcon conventions. His short summary was to stage and label and debug and test extensively beforehand, even if the reassembly might introduce more bugs in the field. George William Herbert Sent from my iPhone From matt.newsom at RACKSPACE.COM Thu Sep 13 10:23:10 2012 From: matt.newsom at RACKSPACE.COM (Matt Newsom) Date: Thu, 13 Sep 2012 15:23:10 +0000 Subject: Layer2 over Layer3 In-Reply-To: <1347488580.64588.YahooMailNeo@web121701.mail.ne1.yahoo.com> References: <1347488580.64588.YahooMailNeo@web121701.mail.ne1.yahoo.com> Message-ID: <93717E08238F7B4392FAD1F82A87FBD3778FCBB1@ORD1EXD04.RACKSPACE.CORP> There are lots of options but beware of the MTU. -----Original Message----- From: Philip Lavine [mailto:source_route at yahoo.com] Sent: Wednesday, September 12, 2012 5:23 PM To: NANOG list Subject: Layer2 over Layer3 To all, ? I am trying to extend a layer2 connection over Layer 3 so I can have redundant Layer connectivity between my HQ and colo site. The reason I need this is so I can give the "appeareance" that there is one gateway and that both data centers can share the same Layer3 subnet (which I am announcing via BGP to 2 different vendors). ? I have 2 ASR's. Will EoMPLS work or is there another option? ? Philip From cboyd at gizmopartners.com Thu Sep 13 10:37:04 2012 From: cboyd at gizmopartners.com (Chris Boyd) Date: Thu, 13 Sep 2012 10:37:04 -0500 Subject: Big Temporary Networks In-Reply-To: <11570158.24452.1347546545009.JavaMail.root@benjamin.baylink.com> References: <11570158.24452.1347546545009.JavaMail.root@benjamin.baylink.com> Message-ID: On Sep 13, 2012, at 9:29 AM, Jay Ashworth wrote: > If not, do any of the people who've already done have 5 minutes to chime in > on what they did and what they learned? I have not done any that size/duration but I have done some where the scale is 1000s of attendees over a long weekend event, with small budgets. You'll need a beefy NAT box. Linux with Xeon CPU and 4GB RAM minimum. Run your DNS resolver and DHCP here, unless you have hardware to spare. Set your DCHP lease time to 1 hour so you don't have an address tied up for someone who stopped in for 15 minutes three days ago. If you don't have any sort of WiFi controller, name the APs differently. People are really pretty good about picking the AP with the best signal strength. Configure and test your equipment before you get to the venue because you will be running around tryiong to find the electrician to turn on the breakers you need, and they forgot about. Change the default passwords on the APs. I did a lot of these for maker/hacker crowds, and there's great fun to be had in advertising rude SSID names. Bandwidth. Lots of Bandwidth. --Chris From jra at baylink.com Thu Sep 13 10:44:00 2012 From: jra at baylink.com (Jay Ashworth) Date: Thu, 13 Sep 2012 11:44:00 -0400 (EDT) Subject: Big Temporary Networks In-Reply-To: <6C9C6373-744E-4CF9-B03A-CAB01AD5C37F@gmail.com> Message-ID: <18374244.24538.1347551040232.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "George Herbert" > I know someone who did Interop's networking for a number of years and > does it for various non-Worldcon conventions. His short summary was to > stage and label and debug and test extensively beforehand, even if the > reassembly might introduce more bugs in the field. Excellent advice. But how do you load a wireless network and an uplink with 12-14k attachments for testing purposes? I can see how to test the uplink, but testing the WLAN seems ... well, next to impossible, to me, which is why I'm querying the list. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From rekoil at semihuman.com Wed Sep 12 21:23:05 2012 From: rekoil at semihuman.com (Chris Woodfield) Date: Wed, 12 Sep 2012 19:23:05 -0700 Subject: APIs for domain registration and management In-Reply-To: <50512658.5040904@meetinghouse.net> References: <50512658.5040904@meetinghouse.net> Message-ID: Dynect has a RESTful API as well. They even host a number of sample scripts at GitHub: http://dyn.com/managed-dns-dynect-5-api-access-load-balancing-geo-traffic-management/ https://github.com/dyninc -C On Sep 12, 2012, at 5:18 PM, Miles Fidelman wrote: > Hi Folks, > > I expect folks on NANOG would know: Are there any domain registrars who provide APIs for managing domains and/or DNS records? It's kind of a pain managing large numbers of domains via klunky web interfaces. It sure would be nice to tie registry accounts into equipment inventory management systems. > > Thanks, > > Miles Fidelman > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > From tony at lavanauts.org Thu Sep 13 11:00:21 2012 From: tony at lavanauts.org (Antonio Querubin) Date: Thu, 13 Sep 2012 06:00:21 -1000 (HST) Subject: ipv6mon v1.0 released! (IPv6 address monitoring daemon) In-Reply-To: References: <5051CFBD.9040608@gont.com.ar> <5051D204.7070806@unfix.org> Message-ID: On Thu, 13 Sep 2012, Steve Meuse wrote: > On Thu, Sep 13, 2012 at 8:31 AM, Jeroen Massar wrote: > >> >> You mean, like what NDPMon has been delivering for several years already: >> >> > Having a choice is never a bad thing(tm). Indeed! +1 Antonio Querubin e-mail: tony at lavanauts.org xmpp: antonioquerubin at gmail.com From dylan at corp.power1.com Thu Sep 13 11:05:41 2012 From: dylan at corp.power1.com (Dylan Bouterse) Date: Thu, 13 Sep 2012 16:05:41 +0000 Subject: Big Temporary Networks In-Reply-To: <18374244.24538.1347551040232.JavaMail.root@benjamin.baylink.com> References: <6C9C6373-744E-4CF9-B03A-CAB01AD5C37F@gmail.com> <18374244.24538.1347551040232.JavaMail.root@benjamin.baylink.com> Message-ID: <218AB54691EB49439829EFD136F473CF27CD8375@exchange2k10.corp.power1.com> -----Original Message----- From: Jay Ashworth [mailto:jra at baylink.com] Sent: Thursday, September 13, 2012 11:44 AM To: NANOG Subject: Re: Big Temporary Networks ----- Original Message ----- > From: "George Herbert" > I know someone who did Interop's networking for a number of years and > does it for various non-Worldcon conventions. His short summary was to > stage and label and debug and test extensively beforehand, even if the > reassembly might introduce more bugs in the field. Excellent advice. But how do you load a wireless network and an uplink with 12-14k attachments for testing purposes? I can see how to test the uplink, but testing the WLAN seems ... well, next to impossible, to me, which is why I'm querying the list. :-) Cheers, -- jra I'm not sure if this is obvious for this list or not, but with your WiFi nodes, a good practice for that kind of density is more nodes, lower power. Keep the client connection load per AP as low as possible to improve overall performance. Jacking up the power in a small area like that will just step on the adjacent APs and cause issues. Dylan From johnl at iecc.com Thu Sep 13 11:14:37 2012 From: johnl at iecc.com (John Levine) Date: 13 Sep 2012 16:14:37 -0000 Subject: APIs for domain registration and management In-Reply-To: <50512C4E.5070901@fluidhosting.com> Message-ID: <20120913161437.30356.qmail@joyce.lan> >OpenSRS and Enom both have APIs. I've ben using OpenSRS's for ages. It's reasonably well documented and works. They do nearly all their business with resellers who typically host their own web sites and use the API to fill the orders, so the API is critical infrastructure for them. R's, John From repstein at hostleasing.net Thu Sep 13 11:17:35 2012 From: repstein at hostleasing.net (Randy Epstein) Date: Thu, 13 Sep 2012 12:17:35 -0400 Subject: [NANOG-announce] RESCHEDULE NOTIFICATION for NANOG mail list maintenance - Tuesday, September 18th, 2012 Message-ID: Colleagues: The NANOG mailman list upgrade and transition was not completed this morning. The maintenance has been rescheduled for Tuesday, September 18, 2012 at 6 am Eastern time. Regards, Randy Epstein NANOG CC Chair On behalf of the NANOG Communications Committee -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From shrdlu at deaddrop.org Thu Sep 13 11:32:39 2012 From: shrdlu at deaddrop.org (Lynda) Date: Thu, 13 Sep 2012 09:32:39 -0700 Subject: Big Temporary Networks In-Reply-To: <11570158.24452.1347546545009.JavaMail.root@benjamin.baylink.com> References: <11570158.24452.1347546545009.JavaMail.root@benjamin.baylink.com> Message-ID: <50520AA7.5030803@deaddrop.org> On 9/13/2012 7:29 AM, Jay Ashworth wrote: > I know without a doubt that this is a problem NANOG PCs deal with 3 times a > year; is there any collected wisdom on the web already about how this has > been dealt with, that I can pore over? Pointers to good archive threads? I'm surprised (well, perhaps I'm not) that no one's chimed in about the defcon network, and the effort they go to each year. Here's some basic information: http://www.defconnetworking.org/ Defcon is often described as the world's most hostile network, and it does have some interesting problems, including extra efforts to keep the wireless side up, and useful. Considering the foolishness that goes on in the background, it's very stable. I do wish that they had more immediately useful information in that site up above, but it's still got some interesting data points. -- You may want to read RFC 1796, and then retract what you said because it sounds silly. Nick Hilliard (http://tools.ietf.org/rfc/rfc1796.txt) From tim at pelican.org Thu Sep 13 11:32:50 2012 From: tim at pelican.org (Tim Franklin) Date: Thu, 13 Sep 2012 17:32:50 +0100 (BST) Subject: Big Temporary Networks In-Reply-To: Message-ID: <37133210-d431-4d7e-b829-9ef4af151579@mail.pelican.org> > You'll need a beefy NAT box. Linux with Xeon CPU and 4GB RAM minimum. Or not. The CCC presentation is showing *real* Internet for everyone, unless I'm very much mistaken... Regards, Tim. From Matthew.Black at csulb.edu Thu Sep 13 11:34:52 2012 From: Matthew.Black at csulb.edu (Matthew Black) Date: Thu, 13 Sep 2012 16:34:52 +0000 Subject: HXXP browser protocol Message-ID: Checking if anyone else has heard of this protocol. It seems to be a method of bypassing security filtering software. The reason I ask is that we received a security alert with a link hxxp://pastebin.com/###. Seems very suspicious and want to know if anyone can shed light. Is this a new phishing/malware methodology? matthew black california state university, long beach From sean at seanharlow.info Thu Sep 13 11:38:19 2012 From: sean at seanharlow.info (Sean Harlow) Date: Thu, 13 Sep 2012 12:38:19 -0400 Subject: HXXP browser protocol In-Reply-To: References: Message-ID: On Sep 13, 2012, at 12:34, Matthew Black wrote: > Checking if anyone else has heard of this protocol. It seems to be a method of bypassing security filtering software. > > The reason I ask is that we received a security alert with a link hxxp://pastebin.com/###. > > Seems very suspicious and want to know if anyone can shed light. Is this a new phishing/malware methodology? Using "hxxp" is a common method to prevent auto-linking by various email/IM clients and/or forum software to then require the user to actively copy/paste the URL to get the content. In the case of a security alert, I could see it being used if the destination is in fact an example of an attack site to prevent someone from inadvertently clicking the link and getting infected. --- Sean Harlow sean at seanharlow.info From jeroen at unfix.org Thu Sep 13 11:42:01 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 13 Sep 2012 18:42:01 +0200 Subject: Big Temporary Networks In-Reply-To: <37133210-d431-4d7e-b829-9ef4af151579@mail.pelican.org> References: <37133210-d431-4d7e-b829-9ef4af151579@mail.pelican.org> Message-ID: <50520CD9.7030402@unfix.org> On 2012-09-13 18:32 , Tim Franklin wrote: >> You'll need a beefy NAT box. Linux with Xeon CPU and 4GB RAM >> minimum. > > Or not. The CCC presentation is showing *real* Internet for > everyone, unless I'm very much mistaken... No NAT was involved there indeed. Typically conferences can get a temporary prefix from their local RIR for conference-alike setups. Of course that does require one to arrange uplinks who will announce that prefix, a friendly LIR etc etc etc. Thus this all boils down on how large your setup will be and how good your want your network to perform. Greets, Jeroen From mfidelman at meetinghouse.net Thu Sep 13 14:50:30 2012 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Thu, 13 Sep 2012 15:50:30 -0400 Subject: APIs for domain registration and management In-Reply-To: <201209130109.q8D19LSJ099961@mail.r-bonomi.com> References: <201209130109.q8D19LSJ099961@mail.r-bonomi.com> Message-ID: <50523906.9030403@meetinghouse.net> Thanks everyone for your responses. -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From d3e3e3 at gmail.com Thu Sep 13 14:55:07 2012 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Thu, 13 Sep 2012 15:55:07 -0400 Subject: Big Temporary Networks In-Reply-To: <11570158.24452.1347546545009.JavaMail.root@benjamin.baylink.com> References: <33083487.24450.1347546188561.JavaMail.root@benjamin.baylink.com> <11570158.24452.1347546545009.JavaMail.root@benjamin.baylink.com> Message-ID: The 2015 WorldCon site selection is contested. There is a group seeking selection for the Disney Coronado Spring Resort in Florida but also competing groups seeking Spokane, Washington, and Helsinki, Finland. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3 at gmail.com On Thu, Sep 13, 2012 at 10:29 AM, Jay Ashworth wrote: > My best friend just got back from Chicon 7 last week, this year's World > Science Fiction Convention. He tells me that the networking at the con hotel, > the Chicago Hyatt, was miserable, whether wired or wireless... and that Sprint > 4G wasn't much better. > > I'm talking to the people who will probably be, in 2015, running the first > Worldcon I can practically drive to, in Orlando, at -- I think -- the Disney > World Resort. I've told them how critical the issue is for this market; they, > predictably, replied "We look forward to your patch". :-} > > I know without a doubt that this is a problem NANOG PCs deal with 3 times a > year; is there any collected wisdom on the web already about how this has > been dealt with, that I can pore over? Pointers to good archive threads? > > If not, do any of the people who've already done have 5 minutes to chime in > on what they did and what they learned? > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA #natog +1 727 647 1274 > From cboyd at gizmopartners.com Thu Sep 13 15:03:51 2012 From: cboyd at gizmopartners.com (Chris Boyd) Date: Thu, 13 Sep 2012 15:03:51 -0500 Subject: Big Temporary Networks In-Reply-To: <37133210-d431-4d7e-b829-9ef4af151579@mail.pelican.org> References: <37133210-d431-4d7e-b829-9ef4af151579@mail.pelican.org> Message-ID: <26628B8A-5EE9-4B6F-939E-12B81B1BAC4D@gizmopartners.com> On Sep 13, 2012, at 11:32 AM, Tim Franklin wrote: Chris Scribbled: >> You'll need a beefy NAT box. Linux with Xeon CPU and 4GB RAM minimum. > > Or not. The CCC presentation is showing *real* Internet for everyone, unless I'm very much mistaken... If you know of an ISP in Central Texas that can deploy a 10Mbit plus connection along with a /22 of v4 address space for a 1 day event, please let me know. TWCable has been pretty easy to work with for special events, but I'd be really surprised to see them be able to do that. --Chris From joshbaird at gmail.com Thu Sep 13 15:03:26 2012 From: joshbaird at gmail.com (Josh Baird) Date: Thu, 13 Sep 2012 16:03:26 -0400 Subject: Big Temporary Networks In-Reply-To: References: <33083487.24450.1347546188561.JavaMail.root@benjamin.baylink.com> <11570158.24452.1347546545009.JavaMail.root@benjamin.baylink.com> Message-ID: We have been using Unifi (a Ubiquiti WIFI product) for local conventions and festivals. The product is fairly cheap, robust, and their access points have very good range. We have deployed it at several commercial businesses as well with great success. The deployment is very easy. We run the controller on a VM at our NOC, but you can also run it locally at the event as well. Besides this, we have a fairly beefy box that handles DNS and DHCP and basic firewalling. Josh On Thu, Sep 13, 2012 at 3:55 PM, Donald Eastlake wrote: > The 2015 WorldCon site selection is contested. There is a group > seeking selection for the Disney Coronado Spring Resort in Florida but > also competing groups seeking Spokane, Washington, and Helsinki, > Finland. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3 at gmail.com > > > On Thu, Sep 13, 2012 at 10:29 AM, Jay Ashworth wrote: > > My best friend just got back from Chicon 7 last week, this year's World > > Science Fiction Convention. He tells me that the networking at the con > hotel, > > the Chicago Hyatt, was miserable, whether wired or wireless... and that > Sprint > > 4G wasn't much better. > > > > I'm talking to the people who will probably be, in 2015, running the > first > > Worldcon I can practically drive to, in Orlando, at -- I think -- the > Disney > > World Resort. I've told them how critical the issue is for this market; > they, > > predictably, replied "We look forward to your patch". :-} > > > > I know without a doubt that this is a problem NANOG PCs deal with 3 > times a > > year; is there any collected wisdom on the web already about how this has > > been dealt with, that I can pore over? Pointers to good archive threads? > > > > If not, do any of the people who've already done have 5 minutes to chime > in > > on what they did and what they learned? > > > > Cheers, > > -- jra > > -- > > Jay R. Ashworth Baylink > jra at baylink.com > > Designer The Things I Think > RFC 2100 > > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > > St Petersburg FL USA #natog +1 727 > 647 1274 > > > > From dylan at corp.power1.com Thu Sep 13 15:19:38 2012 From: dylan at corp.power1.com (Dylan Bouterse) Date: Thu, 13 Sep 2012 20:19:38 +0000 Subject: Big Temporary Networks In-Reply-To: References: <33083487.24450.1347546188561.JavaMail.root@benjamin.baylink.com> <11570158.24452.1347546545009.JavaMail.root@benjamin.baylink.com> Message-ID: <218AB54691EB49439829EFD136F473CF27CDD571@exchange2k10.corp.power1.com> -----Original Message----- From: Josh Baird [mailto:joshbaird at gmail.com] Sent: Thursday, September 13, 2012 4:03 PM To: Donald Eastlake Cc: NANOG Subject: Re: Big Temporary Networks We have been using Unifi (a Ubiquiti WIFI product) for local conventions and festivals. The product is fairly cheap, robust, and their access points have very good range. We have deployed it at several commercial businesses as well with great success. The deployment is very easy. We run the controller on a VM at our NOC, but you can also run it locally at the event as well. Besides this, we have a fairly beefy box that handles DNS and DHCP and basic firewalling. Josh The UniFi line is hard to beat for the price. The controller software is free and the base access points are <$100, in fact you can get a 3-pack for <$200. Deployment of the APs would be 95% of the work. Configuration via the software would take minutes. Dylan From alexb at ripe.net Thu Sep 13 15:21:57 2012 From: alexb at ripe.net (Alex Band) Date: Thu, 13 Sep 2012 22:21:57 +0200 Subject: APIs galore: All RIPE NCC Developer Docs Message-ID: I wanted to let you know we've created a dedicated page for all developer documentation about our different APIs. Apart from the best known one for the RIPE Database REST API, there is also documentation for the RIPE NCC LIR Portal API, giving you access to access to all your (private) resource information, such as ASNs, IPv4 and IPv6 allocations, Assignment Window history, PI assignments, Legacy space, etc. In addition, there is also an IP Analyser API give you access to all the assignments you've made, what available free space you have in your allocations and an overview of all invalid assignments that require your attention. Lastly, there are APIs for RIPE Stat and RIPE Atlas data, giving you access to a wealth of Internet measurements, data analysis and statistics. Have a look at http://ripe.net/developers Cheers, Alex Band Product Manager RIPE NCC From mansaxel at besserwisser.org Thu Sep 13 15:32:30 2012 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Thu, 13 Sep 2012 22:32:30 +0200 Subject: Big Temporary Networks In-Reply-To: <218AB54691EB49439829EFD136F473CF27CD8375@exchange2k10.corp.power1.com> References: <6C9C6373-744E-4CF9-B03A-CAB01AD5C37F@gmail.com> <18374244.24538.1347551040232.JavaMail.root@benjamin.baylink.com> <218AB54691EB49439829EFD136F473CF27CD8375@exchange2k10.corp.power1.com> Message-ID: <20120913203229.GR24232@besserwisser.org> Subject: RE: Big Temporary Networks Date: Thu, Sep 13, 2012 at 04:05:41PM +0000 Quoting Dylan Bouterse (dylan at corp.power1.com): > I'm not sure if this is obvious for this list or not, but with your WiFi nodes, a good practice for that kind of density is more nodes, lower power. Keep the client connection load per AP as low as possible to improve overall performance. Jacking up the power in a small area like that will just step on the adjacent APs and cause issues. ++; An enterprisey AP flock that perhaps even can talk to eachother about power levels is a must. At all possible cost, avoid login or encryption for the wireless. Captive portals suck, especially if they try to be clever and keep an eye on the link-state to each client. Tablets and smartphones turn their radios off to conserve battery, and that means having to login all the time. While things have become much better, doing 802.1x on conference wireless probably is a bit daring. OTOH eduroam does it all over Europe. Get lots of IP addresses. A /16 probably still can be borrowed for this kind of event. I know RIPE had rules and addresses for this kind of use a couple years ago, at least. And get v6. Do not NAT. When all those people want to do social networking to the same furry BBS while also frequenting three social app sites simultaneously you are going to get Issues if you NAT. So don't. (Keep in mind that the 5-tuple for each TCP connection more often will become a 3-tuple if the demographic of the user base is skewed towards a focus group and NAT is in use. ) Lots of IP adresses will also enable you to set sensible DHCP lease times on the failover-connected (because they are, right?) DHCP servers. Nothing is so detrimental to connectivity experience as lost leases from either crashed DHCP servers or short lease times. Be very thorough and careful in setting DHCP up. It'll pay off. Have DNS resolvers locally. Unbound is good. As is BIND. It might be a good idea to have reverse DNS delegation set up, perhaps via the BIND $GENERATE directive; just something like wireless-node-47-11.world.con will do. Make sure that the whois contacts for the address block are proper. Try setting some monitoring up; it is good to be able to keep an eye on client count per AP etc. This is also much easier if the wireless solution is enterprisey. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 The entire CHINESE WOMEN'S VOLLEYBALL TEAM all share ONE personality -- and have since BIRTH!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From mike at mikejones.in Thu Sep 13 15:32:35 2012 From: mike at mikejones.in (Mike Jones) Date: Thu, 13 Sep 2012 21:32:35 +0100 Subject: Layer2 over Layer3 In-Reply-To: <1347488580.64588.YahooMailNeo@web121701.mail.ne1.yahoo.com> References: <1347488580.64588.YahooMailNeo@web121701.mail.ne1.yahoo.com> Message-ID: On 12 September 2012 23:23, Philip Lavine wrote: > To all, > > I am trying to extend a layer2 connection over Layer 3 so I can have redundant Layer connectivity between my HQ and colo site. The reason I need this is so I can give the "appeareance" that there is one gateway and that both data centers can share the same Layer3 subnet (which I am announcing via BGP to 2 different vendors). > > I have 2 ASR's. Will EoMPLS work or is there another option? > > Philip Depending on your specific requirements, if you simply want to be able to address hosts out of the same subnet and don't need actual layer 2 connectivity you might also want to consider proxy ARP(+NDP). This trades some issues for others, for example you don't need to worry about MTU issues, but it won't forward broadcast packets (this could be either an advantage or disadvantage) or non-IP packets, it also requires you to configure the routers so they know which addresses are at the other site. Lots of disadvantages but there are situations where it might be an option. - Mike From jra at baylink.com Thu Sep 13 16:12:26 2012 From: jra at baylink.com (Jay Ashworth) Date: Thu, 13 Sep 2012 17:12:26 -0400 (EDT) Subject: Big Temporary Networks In-Reply-To: Message-ID: <8209184.24576.1347570746175.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Donald Eastlake" > The 2015 WorldCon site selection is contested. There is a group > seeking selection for the Disney Coronado Spring Resort in Florida but > also competing groups seeking Spokane, Washington, and Helsinki, > Finland. I knew about Spokane; I wasn't aware of Helsinki. Thanks, though, for clarifying *which* Disney resort it is; I wasn't at Chicon, and don't have the bid details in front of me. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Thu Sep 13 16:13:56 2012 From: jra at baylink.com (Jay Ashworth) Date: Thu, 13 Sep 2012 17:13:56 -0400 (EDT) Subject: Big Temporary Networks In-Reply-To: Message-ID: <1102047.24578.1347570836477.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Josh Baird" > We have been using Unifi (a Ubiquiti WIFI product) for local conventions > and festivals. The product is fairly cheap, robust, and their access > points have very good range. We have deployed it at several commercial > businesses as well with great success. The deployment is very easy. We > run the controller on a VM at our NOC, but you can also run it locally > at the event as well. > > Besides this, we have a fairly beefy box that handles DNS and DHCP and > basic firewalling. Have you had to/been able to haul in your own bandwidth to feed it? What class? (Real DS3/OC1/OC3, FiOS/HFC, something else?) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jfbeam at gmail.com Thu Sep 13 16:15:28 2012 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 13 Sep 2012 17:15:28 -0400 Subject: HXXP browser protocol In-Reply-To: References: Message-ID: > The reason I ask is that we received a security alert with a link > hxxp://pastebin.com/###. hxxp has been around for a long time. It's a lame hack that was never widely accepted by browsers. The purpose was to have a clickable link that didn't send a referer. (i.e. copy-n-paste) There was a firefox plugin for one-click handling. From lstewart at superb.net Thu Sep 13 16:21:22 2012 From: lstewart at superb.net (Landon Stewart) Date: Thu, 13 Sep 2012 14:21:22 -0700 Subject: HXXP browser protocol In-Reply-To: References: Message-ID: On 13 September 2012 09:38, Sean Harlow wrote: > Using "hxxp" is a common method to prevent auto-linking by various > email/IM clients and/or forum software to then require the user to actively > copy/paste the URL to get the content. > > In the case of a security alert, I could see it being used if the > destination is in fact an example of an attack site to prevent someone from > inadvertently clicking the link and getting infected. > All true and commonly used but it's worth mentioning that putting a space before the *dot TLD* is a better way to prevent auto linking in email/IM clients since most of them detect the formation URLs by other means rather than rely on the exitence of http://. -- Landon Stewart Sr. Administrator Systems Engineering Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead of the Rest": http://www.superbhosting.net From sean at seanharlow.info Thu Sep 13 16:25:16 2012 From: sean at seanharlow.info (Sean Harlow) Date: Thu, 13 Sep 2012 17:25:16 -0400 Subject: HXXP browser protocol In-Reply-To: References: Message-ID: <184AA0A4-5D1A-4B21-B50E-A1DB4A479442@seanharlow.info> On Sep 13, 2012, at 17:21, Landon Stewart wrote: > All true and commonly used but it's worth mentioning that putting a space before the dot TLD is a better way to prevent auto linking in email/IM clients since most of them detect the formation URLs by other means rather than rely on the exitence of http://. Certainly true, the machine I'm currently responding on runs Apple Mail 5.2 and does turn it in to a link, but since hxxp is an invalid protocol it doesn't do anything useful with it. Clicking the link just gives a "no associated application" error, so the practical result is the same. --- Sean Harlow sean at seanharlow.info From sean at seanharlow.info Thu Sep 13 16:27:37 2012 From: sean at seanharlow.info (Sean Harlow) Date: Thu, 13 Sep 2012 17:27:37 -0400 Subject: HXXP browser protocol In-Reply-To: References: Message-ID: Fur further reference, wiki gives the following reasons for hxxp or other similar methods of URL obfuscation: Some of the uses of this method include: * to avoid passing the HTTP referrer header which would reveal the referring web site to the target. * avoiding automated web crawlers from following the links. While effective, legitimate web crawlers can be avoided through the use of a robots exclusion standard on the target web site. To avoid advancing the search engine rank of the target web site, nofollow attributes can be used instead. * to bypass overzealous link spam protection in, for example, blog comments. * for making sure that a user doesn't accidentally click on a potentially harmful link, in applications that automatically recognize links in plain text. Examples of this include "not safe for work" links. * to avoid an application from downloading unwanted files, like advertisements or a malware. The method is directly change all 'http' to 'hxxp' in specific uncompressed .exe or .swf files with a hex editor. --- Sean Harlow sean at seanharlow.info From joshbaird at gmail.com Thu Sep 13 16:28:30 2012 From: joshbaird at gmail.com (Josh Baird) Date: Thu, 13 Sep 2012 17:28:30 -0400 Subject: Big Temporary Networks In-Reply-To: <1102047.24578.1347570836477.JavaMail.root@benjamin.baylink.com> References: <1102047.24578.1347570836477.JavaMail.root@benjamin.baylink.com> Message-ID: Yes, we backhaul our own bandwidth to it; either using Cambium or Ubiquiti unlicensed 5Ghz backhauls. Depending on the distance and type of backhaul, we can get 50-150mbps to the event. Josh On Thu, Sep 13, 2012 at 5:13 PM, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Josh Baird" > > > We have been using Unifi (a Ubiquiti WIFI product) for local conventions > > and festivals. The product is fairly cheap, robust, and their access > > points have very good range. We have deployed it at several commercial > > businesses as well with great success. The deployment is very easy. We > > run the controller on a VM at our NOC, but you can also run it locally > > at the event as well. > > > > Besides this, we have a fairly beefy box that handles DNS and DHCP and > > basic firewalling. > > Have you had to/been able to haul in your own bandwidth to feed it? What > class? (Real DS3/OC1/OC3, FiOS/HFC, something else?) > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > From lists at l8r.net Thu Sep 13 16:40:01 2012 From: lists at l8r.net (Brad Barnett) Date: Thu, 13 Sep 2012 17:40:01 -0400 Subject: anyone from spamhaus hanging around? In-Reply-To: <20120913111744.769403db@be.back.L8R.net> References: <20120913111744.769403db@be.back.L8R.net> Message-ID: <20120913174001.23a7ebc5@be.back.L8R.net> On Thu, 13 Sep 2012 11:17:44 -0400 Brad Barnett wrote: > > We've been running a clean operation for years, but recently, one of our > clients spammed then entire universe (using external mail servers, but > linking to some internal URLs). > > We've since terminated them, and such things are against our terms of > use. However, we seem to have massive issues getting any response from > Spamhaus. We're worried that perhaps we're just blackholed, or someone > is on vacation, or something to that effect. > > Right now, we're essentially crippled -- and at the same time, we > resolved the direct complaint a week ago. > > Does anyone have any idea as to how to contact someone at Spamhaus via > IM, phone, etc? IRC channel? > > Church? ;) > > NOTE: we're not perfect, but again -- we don't allow spamming. We force > unsubscribe footers on all outgoing mail clients send, we don't allow > SPAM as per terms of use, and we insist that clients use a list of > known-contacts if they do mailings. > > EG: people they've have contact with in the past. > > From jra at baylink.com Thu Sep 13 16:45:55 2012 From: jra at baylink.com (Jay Ashworth) Date: Thu, 13 Sep 2012 17:45:55 -0400 (EDT) Subject: Big Temporary Networks In-Reply-To: <20120913203229.GR24232@besserwisser.org> Message-ID: <9737131.24604.1347572755433.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "M?ns Nilsson" > 04:05:41PM +0000 Quoting Dylan Bouterse (dylan at corp.power1.com): > > I'm not sure if this is obvious for this list or not, but with your > > WiFi nodes, a good practice for that kind of density is more nodes, > > lower power. Keep the client connection load per AP as low as > > possible to improve overall performance. Jacking up the power in a > > small area like that will just step on the adjacent APs and cause > > issues. It was. :-) Of course, the propery may (read: probably does) have its own conference areas and residential floors wifi, and those may or may not be V-WLAN capable. > An enterprisey AP flock that perhaps even can talk to eachother about > power levels is a must. > > At all possible cost, avoid login or encryption for the wireless. Yes, and no. > Captive portals suck, especially if they try to be clever and keep an eye on > the link-state to each client. Tablets and smartphones turn their radios > off to conserve battery, and that means having to login all the time. My plan is to have 3 VWLANs: worldcon-guests, which will have one-time captive portal; I want the controller to remember the MAC address everywhere, all week worldcon-dealers, no captive portal (for credit card and other embedded machines), and worldcon-staff, which may have some relaxed outbound security compared to the other networks. (For example, I have no problems blocking outbound port 25 and redirecting recursive DNS -- though I do want a system that permits me to whitelist MACs on request. But I would do those on the guest and dealer nets, and not on the staff one.) > While things have become much better, doing 802.1x on conference > wireless probably is a bit daring. OTOH eduroam does it all over Europe. If I did try to do that, it would probably only be on the staff network; it's a much more contrained environment. > Get lots of IP addresses. A /16 probably still can be borrowed for > this kind of event. I know RIPE had rules and addresses for this kind of > use a couple years ago, at least. Indeed? I did not see that coming. Hell, perhaps Interop could be talked into loaning me a /16. :-) > And get v6. Yeah, I assumed that, though it will be interesting to see how much play it actually gets; these are SF geeks, not networking geeks. > Do not NAT. When all those people want to do social networking to the > same > furry BBS while also frequenting three social app sites simultaneously > you are going to get Issues if you NAT. So don't. (Keep in mind that > the > 5-tuple for each TCP connection more often will become a 3-tuple if > the > demographic of the user base is skewed towards a focus group and NAT > is > in use. ) This, right here, is the kind of gritty advice that brought me to ask this question in the first place. You're right; NAT is Right Out; forget what I said earlier. :-) > Lots of IP adresses will also enable you to set sensible DHCP lease > times on the failover-connected (because they are, right?) DHCP > servers. Nothing is so detrimental to connectivity experience as lost > leases from either crashed DHCP servers or short lease times. > Be very thorough and careful in setting DHCP up. It'll pay off. Oh yeah. I'm fond of leases as short as 30 minutes, though if I have a /16, I won't care as much. > Have DNS resolvers locally. Unbound is good. As is BIND. Yep, with lots of RAM on the boxes. > It might be a good idea to have reverse DNS delegation set up, > perhaps via the BIND $GENERATE directive; just something like > wireless-node-47-11.world.con will do. Hmmm. > Make sure that the whois contacts for the address block are proper. Well, I do have 3 years to plan. :-) > Try setting some monitoring up; it is good to be able to keep an eye > on client count per AP etc. This is also much easier if the wireless > solution is enterprisey. I was planning on having a NOC, yes, albeit small. Very nice, M?ns; thanks. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From nat at nuqe.net Thu Sep 13 18:17:44 2012 From: nat at nuqe.net (Nat Morris) Date: Fri, 14 Sep 2012 00:17:44 +0100 Subject: Big Temporary Networks In-Reply-To: <1102047.24578.1347570836477.JavaMail.root@benjamin.baylink.com> References: <1102047.24578.1347570836477.JavaMail.root@benjamin.baylink.com> Message-ID: On 13 September 2012 22:13, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Josh Baird" >> Besides this, we have a fairly beefy box that handles DNS and DHCP and >> basic firewalling. > > Have you had to/been able to haul in your own bandwidth to feed it? What > class? (Real DS3/OC1/OC3, FiOS/HFC, something else?) Two weekends ago EMFCamp took place north of London in Milton Keynes, the UK?s first maker weekend long festival, ran along the same lines as CCC / HAR2009 etc. A small team of us designed the infrastructure for it, we started at the end of May, 3 months in advance. The CCC noc team in Germany were kind enough to lend us their event /19 + /48 + ASN, we built a temporary network spanning from Telehouse East in London Docklands up to a local data centre (Pulsant) in Milton Keynes. Pulsant sponsored us with a 1gb/s L2 circuit from Telehouse to Milton Keynes, we placed a router (c7202+npe-g2) in each decenter. We took on transit in both sites and had temporary membership to LONAP in Telehouse where we connected to their route server for v4,v6 peering and even multicast. Biggest cost was the 2 mile link from the dc back to the festival site, we rented 2 portable 30m trailer mounted masts. A microwave company loaned us some DragonWave kit which ran on 18ghz at 385mb full duplex, this was our primary link and they applied for a UK OFCOM temp telco license for this on our behalf. We also bought a pair of Ubiquiti Nanobridge M5?s for backup, running at about 100mb. We didn?t firewall anything, users were made aware what they were connecting to, there were no passwords on the SSID?s, we had no agenda to monitor traffic. We published abuse email addresses and a number that people could call if required and we would act on it (the RIR contacts for the address space were updated too) Our NOC: http://www.flickr.com/photos/nottinghack/7929611918/ https://dl.dropbox.com/u/74717/2012-08-30%2017.40.26.jpg http://www.flickr.com/photos/russss/7909193016/ http://www.flickr.com/photos/nottinghack/7929909834/ Onsite core and servers http://www.flickr.com/photos/nottinghack/7929611592/ http://www.flickr.com/photos/andy_d/7902260210/ For wireless we deployed a pair of Cisco wireless controllers, all the APs were lightweight and RF allocation was easily managed centrally. https://twitter.com/emfnoc/status/241944863887749121/photo/1 Just like CCC + HAR we deployed portaloo?s / datenklo around the campsite and campers connected up to them for power and Ethernet: http://www.flickr.com/photos/ne0hack3r/7924490940/ http://www.flickr.com/photos/je4d/7924689482/ Sort out kit configuration out well in advance, really glad we did as we spent far longer getting the mast and microwave kit aligned that we thought. Switches, servers were all configured before arriving so we just unloaded and connected things up according to the plan. Avoid NAT?ing anything, speak to a friendly ISP and borrow some address space. We split DNS resolvers, DHCP, monitoring VMs across 3 separate VM hosts just in case one had a hardware failure, don't rely on a single server box. Do it properly and attendees will be happy: https://twitter.com/Ash_Force/status/242067006537474048 https://twitter.com/markphelan/status/241896897290309633 https://twitter.com/je4d/status/242386884276396032 Our slides are here (warning 50mb)? http://www.natmorris.co.uk/camp_network.pdf Get a team on board to help out, ours rocked! -- Nat http://natmorris.co.uk http://twitter.com/natmorris From matthieu at nxdomain.fr Thu Sep 13 10:48:47 2012 From: matthieu at nxdomain.fr (Matthieu MICHAUD) Date: Thu, 13 Sep 2012 17:48:47 +0200 Subject: APIs for domain registration and management In-Reply-To: <50512658.5040904@meetinghouse.net> References: <50512658.5040904@meetinghouse.net> Message-ID: http://wiki.gandi.net/en/xml-api On Thu, Sep 13, 2012 at 2:18 AM, Miles Fidelman wrote: > Hi Folks, > > I expect folks on NANOG would know: Are there any domain registrars who > provide APIs for managing domains and/or DNS records? It's kind of a pain > managing large numbers of domains via klunky web interfaces. It sure would > be nice to tie registry accounts into equipment inventory management > systems. > > Thanks, > > Miles Fidelman > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > > -- Matthieu MICHAUD From knife at toaster.net Thu Sep 13 12:36:49 2012 From: knife at toaster.net (Sean Lazar) Date: Thu, 13 Sep 2012 10:36:49 -0700 Subject: Big Temporary Networks In-Reply-To: <18374244.24538.1347551040232.JavaMail.root@benjamin.baylink.com> References: <18374244.24538.1347551040232.JavaMail.root@benjamin.baylink.com> Message-ID: <505219B1.2020104@toaster.net> WLAN in large conferences certainly is a challenge. You basically want to get as many people on 5GHz as possible due to more available channels. 2.4GHz becomes quite noisy. Also, configuring your access points for high density helps. This means disabling the lowest data rates. You also don't want to run full Tx power. Basically this will ensure high data rates and quicker handoff to a nearer AP when roaming. You don't want a client that is far away from an AP connecting to it at a 1 Megabit data rate tying up the radio. This also is key in high density seating open floorplan office situations. Sean Lazar On 9/13/12 8:44 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "George Herbert" >> I know someone who did Interop's networking for a number of years and >> does it for various non-Worldcon conventions. His short summary was to >> stage and label and debug and test extensively beforehand, even if the >> reassembly might introduce more bugs in the field. > Excellent advice. > > But how do you load a wireless network and an uplink with 12-14k attachments > for testing purposes? I can see how to test the uplink, but testing the WLAN > seems ... well, next to impossible, to me, which is why I'm querying the list. > > :-) > > Cheers, > -- jra From derek at derekivey.com Thu Sep 13 18:51:11 2012 From: derek at derekivey.com (Derek Ivey) Date: Thu, 13 Sep 2012 19:51:11 -0400 Subject: Big Temporary Networks In-Reply-To: References: <1102047.24578.1347570836477.JavaMail.root@benjamin.baylink.com> Message-ID: <113025372639513923@unknownmsgid> Thanks for sharing that. I just got my CCNA and find this stuff interesting. Derek On Sep 13, 2012, at 7:18 PM, Nat Morris wrote: > On 13 September 2012 22:13, Jay Ashworth wrote: >> ----- Original Message ----- >>> From: "Josh Baird" >>> Besides this, we have a fairly beefy box that handles DNS and DHCP and >>> basic firewalling. >> >> Have you had to/been able to haul in your own bandwidth to feed it? What >> class? (Real DS3/OC1/OC3, FiOS/HFC, something else?) > > Two weekends ago EMFCamp took place north of London in Milton Keynes, > the UK?s first maker weekend long festival, ran along the same lines > as CCC / HAR2009 etc. > > A small team of us designed the infrastructure for it, we started at > the end of May, 3 months in advance. The CCC noc team in Germany were > kind enough to lend us their event /19 + /48 + ASN, we built a > temporary network spanning from Telehouse East in London Docklands up > to a local data centre (Pulsant) in Milton Keynes. > > Pulsant sponsored us with a 1gb/s L2 circuit from Telehouse to Milton > Keynes, we placed a router (c7202+npe-g2) in each decenter. We took on > transit in both sites and had temporary membership to LONAP in > Telehouse where we connected to their route server for v4,v6 peering > and even multicast. > > Biggest cost was the 2 mile link from the dc back to the festival > site, we rented 2 portable 30m trailer mounted masts. A microwave > company loaned us some DragonWave kit which ran on 18ghz at 385mb full > duplex, this was our primary link and they applied for a UK OFCOM temp > telco license for this on our behalf. We also bought a pair of > Ubiquiti Nanobridge M5?s for backup, running at about 100mb. > > We didn?t firewall anything, users were made aware what they were > connecting to, there were no passwords on the SSID?s, we had no agenda > to monitor traffic. We published abuse email addresses and a number > that people could call if required and we would act on it (the RIR > contacts for the address space were updated too) > > Our NOC: > http://www.flickr.com/photos/nottinghack/7929611918/ > https://dl.dropbox.com/u/74717/2012-08-30%2017.40.26.jpg > http://www.flickr.com/photos/russss/7909193016/ > http://www.flickr.com/photos/nottinghack/7929909834/ > > Onsite core and servers > http://www.flickr.com/photos/nottinghack/7929611592/ > http://www.flickr.com/photos/andy_d/7902260210/ > > For wireless we deployed a pair of Cisco wireless controllers, all the > APs were lightweight and RF allocation was easily managed centrally. > https://twitter.com/emfnoc/status/241944863887749121/photo/1 > > Just like CCC + HAR we deployed portaloo?s / datenklo around the > campsite and campers connected up to them for power and Ethernet: > http://www.flickr.com/photos/ne0hack3r/7924490940/ > http://www.flickr.com/photos/je4d/7924689482/ > > Sort out kit configuration out well in advance, really glad we did as > we spent far longer getting the mast and microwave kit aligned that we > thought. Switches, servers were all configured before arriving so we > just unloaded and connected things up according to the plan. Avoid > NAT?ing anything, speak to a friendly ISP and borrow some address > space. We split DNS resolvers, DHCP, monitoring VMs across 3 separate > VM hosts just in case one had a hardware failure, don't rely on a > single server box. > > Do it properly and attendees will be happy: > https://twitter.com/Ash_Force/status/242067006537474048 > https://twitter.com/markphelan/status/241896897290309633 > https://twitter.com/je4d/status/242386884276396032 > > Our slides are here (warning 50mb)? http://www.natmorris.co.uk/camp_network.pdf > > Get a team on board to help out, ours rocked! > > -- > Nat > > http://natmorris.co.uk > http://twitter.com/natmorris > From csinghaus at hopone.net Thu Sep 13 20:38:00 2012 From: csinghaus at hopone.net (Christopher Singhaus) Date: Thu, 13 Sep 2012 21:38:00 -0400 Subject: anyone from spamhaus hanging around? In-Reply-To: <20120913174001.23a7ebc5@be.back.L8R.net> References: <20120913111744.769403db@be.back.L8R.net> <20120913174001.23a7ebc5@be.back.L8R.net> Message-ID: <50528A78.6020803@hopone.net> Brad, I in no way represent Spamhaus, but as someone who has had lots of experience with them, I can assure you that you are not blackholed. You resolved the complaint how? Did you respond to the SBL? Did you get an auto-acknowledgement when you did respond to the SBL? Post up your SBL links here. Let's see what they have to say in them. You will have a hard time trying to connect with them in any other way aside for responding via email to the complaint. On 9/13/2012 5:40 PM, Brad Barnett wrote: > > > > On Thu, 13 Sep 2012 11:17:44 -0400 > Brad Barnett wrote: > >> >> We've been running a clean operation for years, but recently, one of our >> clients spammed then entire universe (using external mail servers, but >> linking to some internal URLs). >> >> We've since terminated them, and such things are against our terms of >> use. However, we seem to have massive issues getting any response from >> Spamhaus. We're worried that perhaps we're just blackholed, or someone >> is on vacation, or something to that effect. >> >> Right now, we're essentially crippled -- and at the same time, we >> resolved the direct complaint a week ago. >> >> Does anyone have any idea as to how to contact someone at Spamhaus via >> IM, phone, etc? IRC channel? >> >> Church? ;) >> >> NOTE: we're not perfect, but again -- we don't allow spamming. We force >> unsubscribe footers on all outgoing mail clients send, we don't allow >> SPAM as per terms of use, and we insist that clients use a list of >> known-contacts if they do mailings. >> >> EG: people they've have contact with in the past. >> >> > -- Christopher Singhaus, Systems Administrator / Abuse Dept csinghaus at hopone.net *** 703-564-5400 HopOne Internet Corp. - AS 14361 - www.hopone.net "Yesterday's weirdness is tomorrow's reason why." -Hunter S Thompson From jlewis at lewis.org Thu Sep 13 21:20:34 2012 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 13 Sep 2012 22:20:34 -0400 (EDT) Subject: anyone from spamhaus hanging around? In-Reply-To: <20120913174001.23a7ebc5@be.back.L8R.net> References: <20120913111744.769403db@be.back.L8R.net> <20120913174001.23a7ebc5@be.back.L8R.net> Message-ID: On Thu, 13 Sep 2012, Brad Barnett wrote: >> We've been running a clean operation for years, but recently, one of our >> clients spammed then entire universe (using external mail servers, but >> linking to some internal URLs). >> >> We've since terminated them, and such things are against our terms of >> use. However, we seem to have massive issues getting any response from >> Spamhaus. We're worried that perhaps we're just blackholed, or someone >> is on vacation, or something to that effect. >> >> Right now, we're essentially crippled -- and at the same time, we >> resolved the direct complaint a week ago. I'm fairly sure there are some Spamhaus people on the list, but nanog is not sbl-removals at spamhaus.org. If you're having problems with SBL listings, you need to contact Spamhaus via the link provided on the page(s) for your listing(s), preserving the subject so that your message gets routed appropriately. IME, if you're having trouble getting SBLs removed, you either haven't contacted Spamhaus properly or haven't convinced them that you've dealt appropriately with the issue. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From kauto at huopio.fi Thu Sep 13 21:36:44 2012 From: kauto at huopio.fi (Kauto Huopio) Date: Fri, 14 Sep 2012 05:36:44 +0300 Subject: Big Temporary Networks In-Reply-To: References: <33083487.24450.1347546188561.JavaMail.root@benjamin.baylink.com> <11570158.24452.1347546545009.JavaMail.root@benjamin.baylink.com> Message-ID: On Thu, Sep 13, 2012 at 10:55 PM, Donald Eastlake wrote: > The 2015 WorldCon site selection is contested. There is a group > seeking selection for the Disney Coronado Spring Resort in Florida but > also competing groups seeking Spokane, Washington, and Helsinki, > Finland. Finland..we have one (1/2 hobbyist) group here that does Big Event Networking: NetCrew. They build the network needed for The Assembly series of events every year. (http://www.assembly.org) Typical event spec: 1-2*10G uplink, appr. 3000 100-1000baseT connections, WLAN, NOC with cool tracking tools to pinpoint a system behaving badly on a BIG switch network, switch configuration bulders etc. They have most of the distribution gear on store and rent out equipment (especially switch gear) between events. Surprise surprise, the core group of the team consists of networking veterans with 10-15+ year experience on the field. Netcrew is a cool way of being able to build some funky designs and test stuff on a very hostile environment compared to their $dayjob. --Kauto FICORA/CERT-FI (kauto.huopio at ficora.fi) -- Kauto Huopio - kauto at huopio.fi From tvhawaii at shaka.com Thu Sep 13 22:55:42 2012 From: tvhawaii at shaka.com (Michael Painter) Date: Thu, 13 Sep 2012 17:55:42 -1000 Subject: Big Temporary Networks References: <11570158.24452.1347546545009.JavaMail.root@benjamin.baylink.com> Message-ID: <22CE791054104E89BBF694A685195FCA@owner59e1f1502> Jay Ashworth wrote: is there any collected wisdom on the web already about how this has > been dealt with, that I can pore over? Pointers to good archive threads? > > If not, do any of the people who've already done have 5 minutes to chime in > on what they did and what they learned? > > Cheers, > -- jra Jay...the WISP folks may have some thoughts. http://lists.wispa.org/mailman/listinfo/wireless From carlos at race.com Fri Sep 14 00:25:29 2012 From: carlos at race.com (Carlos Alcantar) Date: Fri, 14 Sep 2012 05:25:29 +0000 Subject: Layer2 over Layer3 In-Reply-To: <1347488580.64588.YahooMailNeo@web121701.mail.ne1.yahoo.com> Message-ID: +1 on the l2tpv3 but watch out for your mtu's Carlos Alcantar Race Communications / Race Team Member 1325 Howard Ave. #604, Burlingame, CA. 94010 Phone: +1 415 376 3314 / carlos(@)race.com / http://www.race.com -----Original Message----- From: Philip Lavine Reply-To: Philip Lavine Date: Wednesday, September 12, 2012 3:23 PM To: "nanog at nanog.org" Subject: Layer2 over Layer3 To all, I am trying to extend a layer2 connection over Layer 3 so I can have redundant Layer connectivity between my HQ and colo site. The reason I need this is so I can give the "appeareance" that there is one gateway and that both data centers can share the same Layer3 subnet (which I am announcing via BGP to 2 different vendors). I have 2 ASR's. Will EoMPLS work or is there another option? Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5571 bytes Desc: not available URL: From alvarezp at alvarezp.ods.org Fri Sep 14 02:20:33 2012 From: alvarezp at alvarezp.ods.org (Octavio Alvarez) Date: Fri, 14 Sep 2012 00:20:33 -0700 Subject: Big Temporary Networks In-Reply-To: <9737131.24604.1347572755433.JavaMail.root@benjamin.baylink.com> References: <9737131.24604.1347572755433.JavaMail.root@benjamin.baylink.com> Message-ID: On Thu, 13 Sep 2012 14:45:55 -0700, Jay Ashworth wrote: > ----- Original Message ----- >> From: "M?ns Nilsson" > >> 04:05:41PM +0000 Quoting Dylan Bouterse (dylan at corp.power1.com): >> > I'm not sure if this is obvious for this list or not, but with your >> > WiFi nodes, a good practice for that kind of density is more nodes, >> > lower power. Keep the client connection load per AP as low as >> > possible to improve overall performance. Jacking up the power in a >> > small area like that will just step on the adjacent APs and cause >> > issues. I'd have expected someone to have QoS mentioned already, mainly to put FTP and P2P traffic on the least important queues and don't hog up the net. -- Octavio. Twitter: @alvarezp2000 -- Identi.ca: @alvarezp From mansaxel at besserwisser.org Fri Sep 14 02:34:35 2012 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Fri, 14 Sep 2012 09:34:35 +0200 Subject: Big Temporary Networks In-Reply-To: <9737131.24604.1347572755433.JavaMail.root@benjamin.baylink.com> References: <20120913203229.GR24232@besserwisser.org> <9737131.24604.1347572755433.JavaMail.root@benjamin.baylink.com> Message-ID: <20120914073435.GS24232@besserwisser.org> Subject: Re: Big Temporary Networks Date: Thu, Sep 13, 2012 at 05:45:55PM -0400 Quoting Jay Ashworth (jra at baylink.com): > ----- Original Message ----- > > At all possible cost, avoid login or encryption for the wireless. > > Yes, and no. Just keep in mind that every action you make the visitors have to perform to get Internet connectivity is a support workload. > (For example, I have no problems blocking outbound port 25 and redirecting > recursive DNS -- though I do want a system that permits me to whitelist > MACs on request. But I would do those on the guest and dealer nets, and > not on the staff one.) Remember that DNSSEC breaks quite easily if you redirect DNS and since this is three years in the future, the uptake on DNSSEC may well have hit the point where there is visual feedback on validation in client UI. > > While things have become much better, doing 802.1x on conference > > wireless probably is a bit daring. OTOH eduroam does it all over Europe. > > If I did try to do that, it would probably only be on the staff network; > it's a much more contrained environment. It'll work much better there, and FWIW, will be a little yet perhaps effective speedbump for intruders. > > And get v6. > > Yeah, I assumed that, though it will be interesting to see how much play > it actually gets; these are SF geeks, not networking geeks. Again, even in North America, the uptake may well have accelerated enough that it is To Be Expected. Besides, IME, SF geeks are computer savvy more than others. > Oh yeah. I'm fond of leases as short as 30 minutes, though if I have > a /16, I won't care as much. A couple hours will get the user over a lunch break if not overnight, which means that long TCP sessions survive on Proper Computers (that don't tear down TCP on link loss. I'm looking at you, Microsoft!). This is Really Nice. Open up computer from sleep and press enter in xterm and ssh session is up. (my personal record is for telnet, an untouched connection survived two taxi trips, one night, some NATed wlan at the hotel and when i got back to the right network I just plugged the cable in and continued in the same session. But I cheated and had fixed addresses.) > Very nice, M?ns; thanks. My pleasure. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 He is the MELBA-BEING ... the ANGEL CAKE ... XEROX him ... XEROX him -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From mansaxel at besserwisser.org Fri Sep 14 02:35:42 2012 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Fri, 14 Sep 2012 09:35:42 +0200 Subject: Big Temporary Networks In-Reply-To: References: <9737131.24604.1347572755433.JavaMail.root@benjamin.baylink.com> Message-ID: <20120914073542.GT24232@besserwisser.org> Subject: Re: Big Temporary Networks Date: Fri, Sep 14, 2012 at 12:20:33AM -0700 Quoting Octavio Alvarez (alvarezp at alvarezp.ods.org): > I'd have expected someone to have QoS mentioned already, mainly to put > FTP and P2P traffic on the least important queues and don't hog up the > net. As long as there is no multicast entering the wlan this is best solved by getting more bandwidth. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 ... the HIGHWAY is made out of LIME JELLO and my HONDA is a barbequeued OYSTER! Yum! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From jeroen at unfix.org Fri Sep 14 03:01:38 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 14 Sep 2012 10:01:38 +0200 Subject: Big Temporary Networks In-Reply-To: <20120914073435.GS24232@besserwisser.org> References: <20120913203229.GR24232@besserwisser.org> <9737131.24604.1347572755433.JavaMail.root@benjamin.baylink.com> <20120914073435.GS24232@besserwisser.org> Message-ID: <5052E462.5080109@unfix.org> To all folks running NOC's at events like CCC/Assembly/DEFCON/etc: hats off, and enjoy the fun ;) On 2012-09-14 09:34 , M?ns Nilsson wrote: [..] > A couple hours will get the user over a lunch break if not overnight, > which means that long TCP sessions survive on Proper Computers (that > don't tear down TCP on link loss. I'm looking at you, Microsoft!). While that is a default, one can actually disable the Media Sensing: One of the first google hits on disable media sense: http://www.windowsnetworking.com/articles_tutorials/Disable-Media-Sense-TCPIP-Windows-XP.html And voila, your connections keep open even if you change from wired to wireless, as long as you get the same IP on both or if you unplug the cable and plug it in a bit later etc. Now if that works over sleep that is something I am not sure of, I rarely let computers go into sleep mode (long live "NoSleep" on OSX). Typically people who require that though will settle for the use of mosh (http://mosh.mit.edu/) apparently. Greets, Jeroen From bross at pobox.com Fri Sep 14 04:55:21 2012 From: bross at pobox.com (Brandon Ross) Date: Fri, 14 Sep 2012 05:55:21 -0400 (EDT) Subject: Big Temporary Networks In-Reply-To: <9737131.24604.1347572755433.JavaMail.root@benjamin.baylink.com> References: <9737131.24604.1347572755433.JavaMail.root@benjamin.baylink.com> Message-ID: On Thu, 13 Sep 2012, Jay Ashworth wrote: >> Get lots of IP addresses. A /16 probably still can be borrowed for >> this kind of event. I know RIPE had rules and addresses for this kind of >> use a couple years ago, at least. > > Indeed? I did not see that coming. Hell, perhaps Interop could be talked > into loaning me a /16. :-) You might think you are joking, but if it doesn't overlap with an existing commitment, we can probably make that happen. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://tungle.me/bross Skype: brandonross From nick at foobar.org Fri Sep 14 05:16:55 2012 From: nick at foobar.org (Nick Hilliard) Date: Fri, 14 Sep 2012 11:16:55 +0100 Subject: Big Temporary Networks In-Reply-To: <20120913203229.GR24232@besserwisser.org> References: <6C9C6373-744E-4CF9-B03A-CAB01AD5C37F@gmail.com> <18374244.24538.1347551040232.JavaMail.root@benjamin.baylink.com> <218AB54691EB49439829EFD136F473CF27CD8375@exchange2k10.corp.power1.com> <20120913203229.GR24232@besserwisser.org> Message-ID: <50530417.10506@foobar.org> On 13/09/2012 21:32, M?ns Nilsson wrote: > Get lots of IP addresses. A /16 probably still can be borrowed for this > kind of event. I know RIPE had rules and addresses for this kind of use > a couple years ago, at least. yes, you can get a bunch of IP addresses from the ripe ncc if you only need them on a temporary basis: http://www.ripe.net/ripe/docs/ripe-526 They've allocated a /14 for this purpose, so this would be well more than enough to cope with most large conferences. Nick From swmike at swm.pp.se Fri Sep 14 05:17:44 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 14 Sep 2012 12:17:44 +0200 (CEST) Subject: Big Temporary Networks In-Reply-To: References: <9737131.24604.1347572755433.JavaMail.root@benjamin.baylink.com> Message-ID: On Fri, 14 Sep 2012, Brandon Ross wrote: > On Thu, 13 Sep 2012, Jay Ashworth wrote: > >>> Get lots of IP addresses. A /16 probably still can be borrowed for >>> this kind of event. I know RIPE had rules and addresses for this kind of >>> use a couple years ago, at least. >> >> Indeed? I did not see that coming. Hell, perhaps Interop could be talked >> into loaning me a /16. :-) > > You might think you are joking, but if it doesn't overlap > with an existing commitment, we can probably make that happen. I don't know about last /8 policy and how that will change this, but so far I have seen little problem getting a temporary /16 or alike for events from RIPE. -- Mikael Abrahamsson email: swmike at swm.pp.se From nat at nuqe.net Fri Sep 14 05:50:21 2012 From: nat at nuqe.net (Nat Morris) Date: Fri, 14 Sep 2012 11:50:21 +0100 Subject: Big Temporary Networks In-Reply-To: <50530417.10506@foobar.org> References: <6C9C6373-744E-4CF9-B03A-CAB01AD5C37F@gmail.com> <18374244.24538.1347551040232.JavaMail.root@benjamin.baylink.com> <218AB54691EB49439829EFD136F473CF27CD8375@exchange2k10.corp.power1.com> <20120913203229.GR24232@besserwisser.org> <50530417.10506@foobar.org> Message-ID: On 14 September 2012 11:16, Nick Hilliard wrote: > On 13/09/2012 21:32, M?ns Nilsson wrote: >> Get lots of IP addresses. A /16 probably still can be borrowed for this >> kind of event. I know RIPE had rules and addresses for this kind of use >> a couple years ago, at least. > > yes, you can get a bunch of IP addresses from the ripe ncc if you only need > them on a temporary basis: > > http://www.ripe.net/ripe/docs/ripe-526 We tried to apply using this policy to get address space for EMFCamp, no good in reality. The RIPE hostmaster would only allocate us address space 7 days before the event started, needed longer than this to begin building out the network which span multiple data centres. Especially with time, access and change freeze constraints due to the Olympics this year. They didn't seem to want to budge on this, easier in my opinion to borrow some off a friendly organisation or ISP than jump hoops with RIPE. Only other option would be to build your infra out in an existing spare /24 you can get hold of - put router loopbacks, point to points etc in there. Then a week before the event attempt to get the larger /19 assignment from RIPE to put your clients in. I wouldn't be happy doing that though, as in my opinion it doesn't leave enough time for any reachability testing / debugging. -- Nat http://natmorris.co.uk http://twitter.com/natmorris From nick at foobar.org Fri Sep 14 05:54:19 2012 From: nick at foobar.org (Nick Hilliard) Date: Fri, 14 Sep 2012 11:54:19 +0100 Subject: Big Temporary Networks In-Reply-To: References: <6C9C6373-744E-4CF9-B03A-CAB01AD5C37F@gmail.com> <18374244.24538.1347551040232.JavaMail.root@benjamin.baylink.com> <218AB54691EB49439829EFD136F473CF27CD8375@exchange2k10.corp.power1.com> <20120913203229.GR24232@besserwisser.org> <50530417.10506@foobar.org> Message-ID: <50530CDB.8020705@foobar.org> On 14/09/2012 11:50, Nat Morris wrote: > The RIPE hostmaster would only allocate us address space 7 days before > the event started, needed longer than this to begin building out the > network which span multiple data centres. Especially with time, access > and change freeze constraints due to the Olympics this year. They > didn't seem to want to budge on this, easier in my opinion to borrow > some off a friendly organisation or ISP than jump hoops with RIPE. I'm in the process of trying to get this changed. To be completely fair on the RIPE NCC, they don't have flexibility on this issue - the original policy was broken. Nick From nat at nuqe.net Fri Sep 14 05:55:24 2012 From: nat at nuqe.net (Nat Morris) Date: Fri, 14 Sep 2012 11:55:24 +0100 Subject: Big Temporary Networks In-Reply-To: <50530CDB.8020705@foobar.org> References: <6C9C6373-744E-4CF9-B03A-CAB01AD5C37F@gmail.com> <18374244.24538.1347551040232.JavaMail.root@benjamin.baylink.com> <218AB54691EB49439829EFD136F473CF27CD8375@exchange2k10.corp.power1.com> <20120913203229.GR24232@besserwisser.org> <50530417.10506@foobar.org> <50530CDB.8020705@foobar.org> Message-ID: On 14 September 2012 11:54, Nick Hilliard wrote: > On 14/09/2012 11:50, Nat Morris wrote: >> The RIPE hostmaster would only allocate us address space 7 days before >> the event started, needed longer than this to begin building out the >> network which span multiple data centres. Especially with time, access >> and change freeze constraints due to the Olympics this year. They >> didn't seem to want to budge on this, easier in my opinion to borrow >> some off a friendly organisation or ISP than jump hoops with RIPE. > > I'm in the process of trying to get this changed. To be completely fair on > the RIPE NCC, they don't have flexibility on this issue - the original > policy was broken. This is good news Nick :) I have spoken to others in the past few weeks who were hoping to raise it at the next RIPE meeting. I am happy to share our ticket details with you off list if it'll help. -- Nat http://natmorris.co.uk http://twitter.com/natmorris From tore.anderson at redpill-linpro.com Fri Sep 14 05:57:56 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Fri, 14 Sep 2012 12:57:56 +0200 Subject: Big Temporary Networks In-Reply-To: <50530417.10506@foobar.org> References: <6C9C6373-744E-4CF9-B03A-CAB01AD5C37F@gmail.com> <18374244.24538.1347551040232.JavaMail.root@benjamin.baylink.com> <218AB54691EB49439829EFD136F473CF27CD8375@exchange2k10.corp.power1.com> <20120913203229.GR24232@besserwisser.org> <50530417.10506@foobar.org> Message-ID: <50530DB4.4090702@redpill-linpro.com> * Nick Hilliard > They've allocated a /14 for this purpose, so this would be well more > than enough to cope with most large conferences. It's actually a /13 (151.216.0.0/13). -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From swmike at swm.pp.se Fri Sep 14 06:11:26 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 14 Sep 2012 13:11:26 +0200 (CEST) Subject: Big Temporary Networks In-Reply-To: <50530DB4.4090702@redpill-linpro.com> References: <6C9C6373-744E-4CF9-B03A-CAB01AD5C37F@gmail.com> <18374244.24538.1347551040232.JavaMail.root@benjamin.baylink.com> <218AB54691EB49439829EFD136F473CF27CD8375@exchange2k10.corp.power1.com> <20120913203229.GR24232@besserwisser.org> <50530417.10506@foobar.org> <50530DB4.4090702@redpill-linpro.com> Message-ID: On Fri, 14 Sep 2012, Tore Anderson wrote: > It's actually a /13 (151.216.0.0/13). It used to be in another place (I don't remember exactly, this was 5-8 years ago). Nice that they have a /13 nowadays anyway, I'd imagine there are more temporary events nowadays. I've used it a couple of times and then a week was sufficient (start rigging on monday, everything done by thursday morning where 5000 people show up with their computers (this was mainly 10/100 ports, people brought their own cables), teardown and turning off the network, and then returning the space to RIPE on monday. -- Mikael Abrahamsson email: swmike at swm.pp.se From nick at foobar.org Fri Sep 14 06:19:09 2012 From: nick at foobar.org (Nick Hilliard) Date: Fri, 14 Sep 2012 12:19:09 +0100 Subject: Big Temporary Networks In-Reply-To: References: <6C9C6373-744E-4CF9-B03A-CAB01AD5C37F@gmail.com> <18374244.24538.1347551040232.JavaMail.root@benjamin.baylink.com> <218AB54691EB49439829EFD136F473CF27CD8375@exchange2k10.corp.power1.com> <20120913203229.GR24232@besserwisser.org> <50530417.10506@foobar.org> <50530DB4.4090702@redpill-linpro.com> Message-ID: <505312AD.9050003@foobar.org> On 14/09/2012 12:11, Mikael Abrahamsson wrote: > I've used it a couple of times and then a week was sufficient (start > rigging on monday, everything done by thursday morning where 5000 people > show up with their computers (this was mainly 10/100 ports, people brought > their own cables), teardown and turning off the network, and then returning > the space to RIPE on monday. Realistically, the timescales specified in the policy are too short. As there is no ability for the RIPE NCC to pre-assign the space (i.e. let you know in advance what address range you'll be getting, but not give you the go-ahead to use it), it can make it extremely difficult for conference organisers to work within the specified timescales. Also, 1 week is not suitable for debogonisation. I will be talking about this at the address policy working group session at RIPE65. It shouldn't be too difficult to fix the problem, so long as it's clear what people actually need from these temporary addresses. Nick From swmike at swm.pp.se Fri Sep 14 06:24:36 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 14 Sep 2012 13:24:36 +0200 (CEST) Subject: Big Temporary Networks In-Reply-To: <505312AD.9050003@foobar.org> References: <6C9C6373-744E-4CF9-B03A-CAB01AD5C37F@gmail.com> <18374244.24538.1347551040232.JavaMail.root@benjamin.baylink.com> <218AB54691EB49439829EFD136F473CF27CD8375@exchange2k10.corp.power1.com> <20120913203229.GR24232@besserwisser.org> <50530417.10506@foobar.org> <50530DB4.4090702@redpill-linpro.com> <505312AD.9050003@foobar.org> Message-ID: On Fri, 14 Sep 2012, Nick Hilliard wrote: > Also, 1 week is not suitable for debogonisation. Could you please elaborate on this aspect? Who would be treating this space as a bogon, and why? -- Mikael Abrahamsson email: swmike at swm.pp.se From prt at prt.org Fri Sep 14 06:38:24 2012 From: prt at prt.org (Paul Thornton) Date: Fri, 14 Sep 2012 12:38:24 +0100 Subject: Big Temporary Networks In-Reply-To: <505312AD.9050003@foobar.org> References: <6C9C6373-744E-4CF9-B03A-CAB01AD5C37F@gmail.com> <18374244.24538.1347551040232.JavaMail.root@benjamin.baylink.com> <218AB54691EB49439829EFD136F473CF27CD8375@exchange2k10.corp.power1.com> <20120913203229.GR24232@besserwisser.org> <50530417.10506@foobar.org> <50530DB4.4090702@redpill-linpro.com> <505312AD.9050003@foobar.org> Message-ID: <50531730.1040103@prt.org> On 14/09/2012 12:19, Nick Hilliard wrote: > On 14/09/2012 12:11, Mikael Abrahamsson wrote: >> I've used it a couple of times and then a week was sufficient (start >> rigging on monday, everything done by thursday morning where 5000 people >> show up with their computers (this was mainly 10/100 ports, people brought >> their own cables), teardown and turning off the network, and then returning >> the space to RIPE on monday. > > I will be talking about this at the address policy working group session at > RIPE65. It shouldn't be too difficult to fix the problem, so long as it's > clear what people actually need from these temporary addresses. Veering slightly off-topic for NANOG, but is this worth taking onto the address policy mailing list ahead of RIPE65 to ensure people who aren't in the WG session are aware of the issue - and can therefore support (or question) any proposed changes? Paul. -- Paul Thornton From mohta at necom830.hpcl.titech.ac.jp Fri Sep 14 07:22:01 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 14 Sep 2012 21:22:01 +0900 Subject: Big Temporary Networks In-Reply-To: <20120913203229.GR24232@besserwisser.org> References: <6C9C6373-744E-4CF9-B03A-CAB01AD5C37F@gmail.com> <18374244.24538.1347551040232.JavaMail.root@benjamin.baylink.com> <218AB54691EB49439829EFD136F473CF27CD8375@exchange2k10.corp.power1.com> <20120913203229.GR24232@besserwisser.org> Message-ID: <50532169.7070909@necom830.hpcl.titech.ac.jp> M?ns Nilsson wrote: > And get v6. > > Do not NAT. When all those people want to do social networking to the same > furry BBS while also frequenting three social app sites simultaneously > you are going to get Issues if you NAT. So don't. Don't? Considering that, ten years ago, some computers were still often shared by thousands of people distinguished by their port numbers and that, today, pseudo ISPs are using NAT, it is not only wrong but also impossible to identify a user only by his IP address without port numbers. Masataka Ohta From mansaxel at besserwisser.org Fri Sep 14 07:46:07 2012 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Fri, 14 Sep 2012 14:46:07 +0200 Subject: Big Temporary Networks In-Reply-To: <50532169.7070909@necom830.hpcl.titech.ac.jp> References: <6C9C6373-744E-4CF9-B03A-CAB01AD5C37F@gmail.com> <18374244.24538.1347551040232.JavaMail.root@benjamin.baylink.com> <218AB54691EB49439829EFD136F473CF27CD8375@exchange2k10.corp.power1.com> <20120913203229.GR24232@besserwisser.org> <50532169.7070909@necom830.hpcl.titech.ac.jp> Message-ID: <20120914124607.GU24232@besserwisser.org> Subject: Re: Big Temporary Networks Date: Fri, Sep 14, 2012 at 09:22:01PM +0900 Quoting Masataka Ohta (mohta at necom830.hpcl.titech.ac.jp): > M?ns Nilsson wrote: > > >And get v6. > > > >Do not NAT. When all those people want to do social networking to the same > >furry BBS while also frequenting three social app sites simultaneously > >you are going to get Issues if you NAT. So don't. > > Don't? > > Considering that, ten years ago, some computers were still often > shared by thousands of people distinguished by their port numbers > and that, today, pseudo ISPs are using NAT, it is not only wrong > but also impossible to identify a user only by his IP address > without port numbers. Ohta-san, I am not suggesting that. I'm just trying to point out that there might be a bunch of assumptions that aren't as true anymore when a lot of client connections share both source and destination address, and perhaps also destination port. If this happens simultaneously when a large amount of other tcp connections are NATed through the same box, resource starvation will occur. If public address space is available, it is better to use that. Also, no NAT means there will be no session timers for things like long lived low bandwidth tcp sessions. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I think my career is ruined! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From jra at baylink.com Fri Sep 14 08:32:19 2012 From: jra at baylink.com (Jay Ashworth) Date: Fri, 14 Sep 2012 09:32:19 -0400 (EDT) Subject: Big Temporary Networks In-Reply-To: <505219B1.2020104@toaster.net> Message-ID: <13034091.24686.1347629539112.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Sean Lazar" > WLAN in large conferences certainly is a challenge. You basically want > to get as many people on 5GHz as possible due to more available > channels. 2.4GHz becomes quite noisy. And here you raise an interesting question: do dual band wifi clients *show which band a network is on*? Will they prefer the A band AP automatically in any way? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Fri Sep 14 08:38:17 2012 From: jra at baylink.com (Jay Ashworth) Date: Fri, 14 Sep 2012 09:38:17 -0400 (EDT) Subject: Big Temporary Networks In-Reply-To: <20120914073435.GS24232@besserwisser.org> Message-ID: <846029.24690.1347629897789.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "M?ns Nilsson" > 05:45:55PM -0400 Quoting Jay Ashworth (jra at baylink.com): > > ----- Original Message ----- > > > At all possible cost, avoid login or encryption for the wireless. > > > > Yes, and no. > > > > Just keep in mind that every action you make the visitors have to > perform to get Internet connectivity is a support workload. I understand entirely. That was the reason for my "remember each MAC address for the entire event" approach to captive portal. I forsee the guests entering a code from their event badge the first time they use each device. Unlike most events, I also forsee a single page "How to use our Internet connectivity" sheet that actually tells you what you need to know. :-) > > (For example, I have no problems blocking outbound port 25 and > > redirecting > > recursive DNS -- though I do want a system that permits me to > > whitelist > > MACs on request. But I would do those on the guest and dealer nets, > > and > > not on the staff one.) > > Remember that DNSSEC breaks quite easily if you redirect DNS and since > this is three years in the future, the uptake on DNSSEC may well have > hit the point where there is visual feedback on validation in client > UI. Good point. > > > While things have become much better, doing 802.1x on conference > > > wireless probably is a bit daring. OTOH eduroam does it all over > > > Europe. > > > > If I did try to do that, it would probably only be on the staff > > network; it's a much more contrained environment. > > It'll work much better there, and FWIW, will be a little yet perhaps > effective speedbump for intruders. Was my plan, yes. This isn't, really, defcon. :-) > > > And get v6. > > > > Yeah, I assumed that, though it will be interesting to see how much > > play it actually gets; these are SF geeks, not networking geeks. > > Again, even in North America, the uptake may well have accelerated > enough that it is To Be Expected. Besides, IME, SF geeks are computer > savvy more than others. I've heard that asserted. I'm not certain to what extent it's actually true. > > Oh yeah. I'm fond of leases as short as 30 minutes, though if I have > > a /16, I won't care as much. > > A couple hours will get the user over a lunch break if not overnight, > which means that long TCP sessions survive on Proper Computers (that > don't tear down TCP on link loss. I'm looking at you, Microsoft!). Well, I'm a firm believer in Least Recently Used, so as long as my DHCP block is larger than my userbase, everyone will have the same address all weekend anyway. > This > is Really Nice. Open up computer from sleep and press enter in xterm > and ssh session is up. (my personal record is for telnet, an untouched > connection survived two taxi trips, one night, some NATed wlan at the > hotel and when i got back to the right network I just plugged the > cable in > and continued in the same session. But I cheated and had fixed > addresses.) Nice. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Fri Sep 14 08:40:02 2012 From: jra at baylink.com (Jay Ashworth) Date: Fri, 14 Sep 2012 09:40:02 -0400 (EDT) Subject: Big Temporary Networks In-Reply-To: <20120914073542.GT24232@besserwisser.org> Message-ID: <858752.24692.1347630002607.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "M?ns Nilsson" > 12:20:33AM -0700 Quoting Octavio Alvarez (alvarezp at alvarezp.ods.org): > > > I'd have expected someone to have QoS mentioned already, mainly to put > > FTP and P2P traffic on the least important queues and don't hog up the > > net. > > As long as there is no multicast entering the wlan this is best solved > by getting more bandwidth. Well, we'll be on the *sending* end of the Hugo's, but... ;-) It would still be nice to multicast them inside our network (and out to whomever wants to watch), but what the heck's the consumer-level client side of multicast video streaming look like these days? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From cmadams at hiwaay.net Fri Sep 14 08:51:48 2012 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 14 Sep 2012 08:51:48 -0500 Subject: Big Temporary Networks In-Reply-To: <858752.24692.1347630002607.JavaMail.root@benjamin.baylink.com> References: <20120914073542.GT24232@besserwisser.org> <858752.24692.1347630002607.JavaMail.root@benjamin.baylink.com> Message-ID: <20120914135148.GB440@hiwaay.net> Once upon a time, Jay Ashworth said: > Well, we'll be on the *sending* end of the Hugo's, but... ;-) You might want to talk to whoever did this year's WorldCon networking. I'm a Dragon*Con volunteer, and I know there was a some type of direct connection between Chicago (WorldCon) and Atlanta (Dragon*Con) so that we could show things like the Hugo ceremony (and I think we fed some video the other way as well, like the D*C Parade). I don't know how they did the "regular" Internet stream (except that it went through Ustream, who shut down the Hugo feed because of a DMCA complaint). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jra at baylink.com Fri Sep 14 09:14:52 2012 From: jra at baylink.com (Jay Ashworth) Date: Fri, 14 Sep 2012 10:14:52 -0400 (EDT) Subject: Big Temporary Networks In-Reply-To: <20120914135148.GB440@hiwaay.net> Message-ID: <25054726.24862.1347632092406.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Chris Adams" > Once upon a time, Jay Ashworth said: > > Well, we'll be on the *sending* end of the Hugo's, but... ;-) > > You might want to talk to whoever did this year's WorldCon networking. > I'm a Dragon*Con volunteer, and I know there was a some type of direct > connection between Chicago (WorldCon) and Atlanta (Dragon*Con) so that > we could show things like the Hugo ceremony (and I think we fed some > video the other way as well, like the D*C Parade). I know some of that went on, yes, and certainly if I'm more formally involved, I'll be querying the SMOFlist to see who ran things at the last 5 or so. My bet is that none of them *had* a formal CTO/Ops person full time. (Though of course, now that I've said that, those people will pop up here, saying "you talkin' to *me*??" :-) > I don't know how they did the "regular" Internet stream (except that > it went through Ustream, who shut down the Hugo feed because of a DMCA > complaint). My understanding was that Dragon *took its main feed* for the Hugos via Ustream, and the entire room got left standing; no? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From apishdadi at gmail.com Fri Sep 14 09:29:33 2012 From: apishdadi at gmail.com (A. Pishdadi) Date: Fri, 14 Sep 2012 09:29:33 -0500 Subject: Transport Fee's (Taxes and random telecom fee's) Message-ID: Hello Everyone, We purchase 10Gig waves for transport out of our datacenter and are trying to figure out why the taxes on the circuits are so much. We are paying around 60% additional in taxes and fee's on top of the cost of the circuit. Ofcourse when we were negotiating pricing , it seemed like a great price until we got our first bill, they forgot to mention that we would be paying such fees. It seems like these taxes would be for companies who would be using transport services for voice, but we are all data. Is there any way to get a tax exempt status? How come the same fee's do not apply to dark fiber? We are in process of getting dark fiber to replace the transport circuits but its going to take quite some time as we have a few more years on some of the contracts. The dark fiber we do have there is no taxes at all. Can anyone shed any light on this? From cmadams at hiwaay.net Fri Sep 14 09:43:28 2012 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 14 Sep 2012 09:43:28 -0500 Subject: Big Temporary Networks In-Reply-To: <25054726.24862.1347632092406.JavaMail.root@benjamin.baylink.com> References: <20120914135148.GB440@hiwaay.net> <25054726.24862.1347632092406.JavaMail.root@benjamin.baylink.com> Message-ID: <20120914144328.GE440@hiwaay.net> Once upon a time, Jay Ashworth said: > My understanding was that Dragon *took its main feed* for the Hugos via > Ustream, and the entire room got left standing; no? I don't know; I wasn't in there, and I didn't find out about the Ustream cut until I was home. I would think I would have heard if the feed was cut though (I wasn't involved, but I work Techops and know the people involved). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From millnert at gmail.com Fri Sep 14 10:00:59 2012 From: millnert at gmail.com (Martin Millnert) Date: Fri, 14 Sep 2012 17:00:59 +0200 Subject: RIPE in final /8 of IPv4 Message-ID: <1347634859.4301.82.camel@galileo.millnert.se> Hi list, in the interest of really running down also the final /8 of RIPE, which was entered today, let me point out that the cost to setup a new LIR is a meager application + application fee (2000 EUR) + ~1500 EUR or so for the first year. You can obviously transfer the resource as long as the requirement for the minimum allocation remains the same (which is a couple of web servers or so :) ), and then discontinue the LIR if you feel so inclined. This stands in contrast with the cost of fixing your documentation to justify 80% used space of the current allocations. Also, each LIR can just get 1 /22 from the final /8 pool. So if you're getting space for customers, the new-LIR approach with option to transfer back in is pretty reasonable. Happy Friday! Best, Martin (IPv6, where are you?) - http://www.ripe.net/ripe/mail/archives/ncc-announce/2012-September/000615.html - https://www.ripe.net/internet-coordination/news/ripe-ncc-begins-to-allocate-ipv4-address-space-from-the-last-8 From faisal at snappydsl.net Fri Sep 14 10:15:10 2012 From: faisal at snappydsl.net (Faisal Imtiaz) Date: Fri, 14 Sep 2012 11:15:10 -0400 Subject: Transport Fee's (Taxes and random telecom fee's) In-Reply-To: References: Message-ID: <505349FE.8010008@snappydsl.net> All Communication Circuits are subject to Communication Taxes, as per Tax laws of that State. Having said that... if this communication circuit is carrying Internet Traffic, you can contact the Carrier and Ask them to provide you the forms so that you can Claim "ITFA / ITNA Exemption" ...(if you are not in a grandfathered state) Google for "Internet Tax Freedom Act" and review the Wikipedia article for more details and history. In regards to Dark Fiber..... Active Circuits = i.e. circuits where signaling is provided by the Carrier are considered to be Communication Circuits and are subject to Communication taxes, as per the State Laws. Dark Fiber is considered to be an asset purchase .. i.e. like leasing Office Space/ Automobile / or Machinery... and as such the Lease Payments are subject to Sales Taxes only (again, details may vary from State to State). Regards. Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, Fl 33155 Tel: 305 663 5518 x 232 Helpdesk: 305 663 5518 option 2 Email: Support at Snappydsl.net On 9/14/2012 10:29 AM, A. Pishdadi wrote: > Hello Everyone, > > We purchase 10Gig waves for transport out of our datacenter and are trying > to figure out why the taxes on the circuits are so much. We are paying > around 60% additional in taxes and fee's on top of the cost of the circuit. > Ofcourse when we were negotiating pricing , it seemed like a great price > until we got our first bill, they forgot to mention that we would be paying > such fees. > It seems like these taxes would be for companies who would be using > transport services for voice, but we are all data. Is there any way to get > a tax exempt status? How come the same fee's do not apply to dark fiber? We > are in process of getting dark fiber to replace the transport circuits but > its going to take quite some time as we have a few more years on some of the > contracts. The dark fiber we do have there is no taxes at all. Can anyone > shed any light on this? > From jra at baylink.com Fri Sep 14 10:49:52 2012 From: jra at baylink.com (Jay Ashworth) Date: Fri, 14 Sep 2012 11:49:52 -0400 (EDT) Subject: Big Temporary Networks In-Reply-To: <20120914144328.GE440@hiwaay.net> Message-ID: <26667960.24864.1347637792079.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Chris Adams" > Subject: Re: Big Temporary Networks > Once upon a time, Jay Ashworth said: > > My understanding was that Dragon *took its main feed* for the Hugos > > via Ustream, and the entire room got left standing; no? > > I don't know; I wasn't in there, and I didn't find out about the Ustream > cut until I was home. I would think I would have heard if the feed was > cut though (I wasn't involved, but I work Techops and know the people > involved). Noted. How big is that crew for Dragon; you were, what, 30k attendees? -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Fri Sep 14 10:53:01 2012 From: jra at baylink.com (Jay Ashworth) Date: Fri, 14 Sep 2012 11:53:01 -0400 (EDT) Subject: Big Temporary Networks In-Reply-To: <1F2CDA99-7081-4445-A3A2-66387BC16C47@snap-interactive.com> Message-ID: <31256570.24866.1347637981269.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Matthew Barr" > and as I was working the Hugo's: > > On Sep 14, 2012, at 10:14 AM, Jay Ashworth wrote: > > ----- Original Message ----- > >> From: "Chris Adams" > > > > I know some of that went on, yes, and certainly if I'm more formally > > involved, I'll be querying the SMOFlist to see who ran things at the > > last 5 or so. > > > > My bet is that none of them *had* a formal CTO/Ops person full time. > > Tech had a person managing the feed to DragonCon from the dedicated > room w/ the polycomm video conference system, for panels, in addition > to the actual union operator of the camera & such. The camera ops had to be union? Hmmm. Ah, Chicago. Yes. > There was an IT head, but he was responsible for the laptops / staff > network, printers, etc. Got it. > The hotel itself had the conference wireless, instead of it being > brought in. Yes, and I'm told by my best friend who did attend (I didn't make it this year) that the hotel wired/wifi was essentially unusable, every time he tried. Hence my interest in the issue. > > My understanding was that Dragon *took its main feed* for the Hugos > > via Ustream, and the entire room got left standing; no? > > Dragon took it's feed for the hugo's through Ustream, as did the > *overflow* rooms onsite. It was easier to go to the internet & back, > than to get a direct cable. Ok, then I was correctly informed; thanks. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From cmadams at hiwaay.net Fri Sep 14 10:58:57 2012 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 14 Sep 2012 10:58:57 -0500 Subject: Big Temporary Networks In-Reply-To: <26667960.24864.1347637792079.JavaMail.root@benjamin.baylink.com> References: <20120914144328.GE440@hiwaay.net> <26667960.24864.1347637792079.JavaMail.root@benjamin.baylink.com> Message-ID: <20120914155857.GH440@hiwaay.net> Once upon a time, Jay Ashworth said: > Noted. How big is that crew for Dragon; you were, what, 30k attendees? The estimate I heard was 52,000-55,000 paid attendees this year (plus another 3,000+ for volunteers, guests+spouse/agent/etc., press, etc.). Our Techops staff was around 240-250 this year. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From bicknell at ufp.org Fri Sep 14 11:08:30 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 14 Sep 2012 09:08:30 -0700 Subject: Big Temporary Networks In-Reply-To: <31256570.24866.1347637981269.JavaMail.root@benjamin.baylink.com> References: <1F2CDA99-7081-4445-A3A2-66387BC16C47@snap-interactive.com> <31256570.24866.1347637981269.JavaMail.root@benjamin.baylink.com> Message-ID: <20120914160830.GA69921@ussenterprise.ufp.org> In a message written on Fri, Sep 14, 2012 at 11:53:01AM -0400, Jay Ashworth wrote: > Yes, and I'm told by my best friend who did attend (I didn't make it > this year) that the hotel wired/wifi was essentially unusable, every > time he tried. Hence my interest in the issue. I find more and more hotel networks are essentially unusable for parts of the day, conference or no. Of course, bring in any geek contingent with multiple devices and heavy usage patterns and the problems get worse. What I find most interesting is more often than not the problem appears to be an overloaded / undersized NAT/Captive portal/DNS Resolver system. Behaviors like existing connections working fine, but no new ones can be created (out of ports on the NAT?). While bandwidth is occasionally an issue, I've found an ssh tunnel out to some other end point solves the issues in 9 out of 10 cases. I wonder how many hotels upgrade their bandwidth but not the gateway, get a report that their DS-3/OC-3/Metro-E is only 25% used, and think all is well. Mean while half their clients can't connect to anything due to the gateway device. -- 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 eugen at leitl.org Fri Sep 14 11:12:39 2012 From: eugen at leitl.org (Eugen Leitl) Date: Fri, 14 Sep 2012 18:12:39 +0200 Subject: RIPE NCC now allocating IPv4 address space from the last /8 netblock Message-ID: <20120914161239.GH9750@leitl.org> http://arstechnica.com/information-technology/2012/09/europe-officially-runs-out-of-ipv4-addresses/ Europe officially runs out of IPv4 addresses RIPE NCC now allocating IPv4 address space from the last /8 netblock by Iljitsch van Beijnum - Sep 14, 2012 3:20 pm UTC Earlier today, the RIPE NCC (R?seaux IP Europ?ens Network Coordination Centre) announced it is down to its last "/8" worth of IPv4 addresses. This means that it is no longer possible to obtain new IPv4 addresses in Europe, the former USSR, or the Middle East, with one small exception: every network operator that is a "RIPE member" or "local Internet registry" (LIR) can obtain one final block of 1024 IPv4 addresses. To fulfill these requests, the RIPE NCC is keeping that last /8, which contains 16.8 million addresses, in reserve. RIPE NCC None of this comes as a surprise given that the global pool of free IPv4 addresses was emptied in February 2011. APNIC, which distributes IP addresses in the Asia-Pacific region, ran out of IPv4 addresses in May 2011; it has been working under the "final /8" regime ever since. The remaining three Regional Internet Registries are AfriNIC (Africa), LACNIC (Latin America and the Caribbean), and ARIN (North America), which all have enough IPv4 addresses to last at least two more years. Since the depletion of IPv4 address space in the APNIC region, little information has surfaced about how network operators in the region have managed the situation. However, the lack of IPv4 addresses only impacts organizations and consumers who need additional addresses, or who need addresses for the first time. Existing IPv4 users remain unaffected, and so the immediate impact is limited. Also, large network operators get large address blocks from the RIRs and they typically have a pool of unused addresses of their own, so few will be experiencing immediate problems. However, every year for the past five years, some 200 million new IPv4 addresses have been put into use. Without a steady supply of fresh addresses, many Internet-related activities are going to become problematic in the years to come. Fortunately, 20 years ago the Internet Engineering Task Force (IETF) foresaw that the 3.7 billion addresses afforded by the 32-bit IPv4 address space would become a problem, and started working on a replacement: IPv6. But the IPv4 depletion didn't happen as fast as the IETF originally predicted, and IPv6 adoption has languished. But recently, IPv6 adoption got a big push in the form of World IPv6 Launch. Eventually, IPv6 will replace IPv4, but the transition won't be pretty. Reader comments 19 Iljitsch van Beijnum / Iljitsch is a contributing writer at Ars Technica, where he contributes articles about network protocols as well as Apple topics. He is currently finishing his Ph.D work at the telematics department at Universidad Carlos III de Madrid (UC3M) in Spain. @iljitsch From mark at viviotech.net Fri Sep 14 11:53:12 2012 From: mark at viviotech.net (Mark Keymer) Date: Fri, 14 Sep 2012 09:53:12 -0700 Subject: Transport Fee's (Taxes and random telecom fee's) In-Reply-To: <505349FE.8010008@snappydsl.net> References: <505349FE.8010008@snappydsl.net> Message-ID: <505360F8.7070007@viviotech.net> I had to deal with this with an upstream once that was taxing me. Finally got it all worked out after sending in copies of the law and getting the CEO involved. However a year or two later I started to get taxed again when the company was bought out. Had to resend copies of the law (Fed and State) over to them again. I also had the full conversation with the previous CEO so I sent that over as well as he was now a VP under the new company. Do to how much of a hassle I had to go through, I am guessing they still keep charging tax on other clients that probably should not have been! Sincerely, Mark Keymer On 9/14/2012 8:15 AM, Faisal Imtiaz wrote: > > All Communication Circuits are subject to Communication Taxes, as per > Tax laws of that State. > > Having said that... if this communication circuit is carrying Internet > Traffic, you can contact the Carrier and Ask them to provide you the > forms so that you can > Claim "ITFA / ITNA Exemption" ...(if you are not in a grandfathered > state) Google for "Internet Tax Freedom Act" and review the Wikipedia > article for more details and history. > > In regards to Dark Fiber..... > Active Circuits = i.e. circuits where signaling is provided by the > Carrier are considered to be Communication Circuits and are subject > to Communication taxes, as per the State Laws. > > Dark Fiber is considered to be an asset purchase .. i.e. like leasing > Office Space/ Automobile / or Machinery... and as such the Lease > Payments are subject to Sales Taxes only (again, details may vary from > State to State). > > Regards. > > Faisal Imtiaz > Snappy Internet & Telecom > 7266 SW 48 Street > Miami, Fl 33155 > Tel: 305 663 5518 x 232 > Helpdesk: 305 663 5518 option 2 Email: Support at Snappydsl.net > > On 9/14/2012 10:29 AM, A. Pishdadi wrote: >> Hello Everyone, >> >> We purchase 10Gig waves for transport out of our datacenter and are >> trying >> to figure out why the taxes on the circuits are so much. We are paying >> around 60% additional in taxes and fee's on top of the cost of the >> circuit. >> Ofcourse when we were negotiating pricing , it seemed like a great price >> until we got our first bill, they forgot to mention that we would be >> paying >> such fees. >> It seems like these taxes would be for companies who would be using >> transport services for voice, but we are all data. Is there any way >> to get >> a tax exempt status? How come the same fee's do not apply to dark >> fiber? We >> are in process of getting dark fiber to replace the transport >> circuits but >> its going to take quite some time as we have a few more years on some >> of the >> contracts. The dark fiber we do have there is no taxes at all. Can >> anyone >> shed any light on this? >> > > > From cscora at apnic.net Fri Sep 14 13:50:04 2012 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 15 Sep 2012 04:50:04 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201209141850.q8EIo4fj015769@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, TRNOG, 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 15 Sep, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 426606 Prefixes after maximum aggregation: 177882 Deaggregation factor: 2.40 Unique aggregates announced to Internet: 207475 Total ASes present in the Internet Routing Table: 42113 Prefixes per ASN: 10.13 Origin-only ASes present in the Internet Routing Table: 33613 Origin ASes announcing only one prefix: 15760 Transit ASes present in the Internet Routing Table: 5611 Transit-only ASes present in the Internet Routing Table: 135 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 32 Max AS path prepend of ASN ( 48687) 24 Prefixes from unregistered ASNs in the Routing Table: 716 Unregistered ASNs in the Routing Table: 253 Number of 32-bit ASNs allocated by the RIRs: 3277 Number of 32-bit ASNs visible in the Routing Table: 2889 Prefixes from 32-bit ASNs in the Routing Table: 7687 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 177 Number of addresses announced to Internet: 2595714508 Equivalent to 154 /8s, 183 /16s and 117 /24s Percentage of available address space announced: 70.1 Percentage of allocated address space announced: 70.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 93.6 Total number of prefixes smaller than registry allocations: 150375 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 102576 Total APNIC prefixes after maximum aggregation: 32472 APNIC Deaggregation factor: 3.16 Prefixes being announced from the APNIC address blocks: 103203 Unique aggregates announced from the APNIC address blocks: 42696 APNIC Region origin ASes present in the Internet Routing Table: 4756 APNIC Prefixes per ASN: 21.70 APNIC Region origin ASes announcing only one prefix: 1234 APNIC Region transit ASes present in the Internet Routing Table: 768 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 309 Number of APNIC addresses announced to Internet: 707879232 Equivalent to 42 /8s, 49 /16s and 97 /24s Percentage of available APNIC address space announced: 82.7 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 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, 150/8, 153/8, 163/8, 171/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: 154269 Total ARIN prefixes after maximum aggregation: 78053 ARIN Deaggregation factor: 1.98 Prefixes being announced from the ARIN address blocks: 155263 Unique aggregates announced from the ARIN address blocks: 69144 ARIN Region origin ASes present in the Internet Routing Table: 15238 ARIN Prefixes per ASN: 10.19 ARIN Region origin ASes announcing only one prefix: 5745 ARIN Region transit ASes present in the Internet Routing Table: 1599 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 17 Number of ARIN addresses announced to Internet: 1084171392 Equivalent to 64 /8s, 159 /16s and 36 /24s Percentage of available ARIN address space announced: 57.4 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, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/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: 108355 Total RIPE prefixes after maximum aggregation: 56640 RIPE Deaggregation factor: 1.91 Prefixes being announced from the RIPE address blocks: 110819 Unique aggregates announced from the RIPE address blocks: 70085 RIPE Region origin ASes present in the Internet Routing Table: 16853 RIPE Prefixes per ASN: 6.58 RIPE Region origin ASes announcing only one prefix: 8165 RIPE Region transit ASes present in the Internet Routing Table: 2711 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1876 Number of RIPE addresses announced to Internet: 645372900 Equivalent to 38 /8s, 119 /16s and 155 /24s Percentage of available RIPE address space announced: 93.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 59392-61439, 196608-199679 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, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 43765 Total LACNIC prefixes after maximum aggregation: 8447 LACNIC Deaggregation factor: 5.18 Prefixes being announced from the LACNIC address blocks: 46833 Unique aggregates announced from the LACNIC address blocks: 21932 LACNIC Region origin ASes present in the Internet Routing Table: 1647 LACNIC Prefixes per ASN: 28.44 LACNIC Region origin ASes announcing only one prefix: 442 LACNIC Region transit ASes present in the Internet Routing Table: 324 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 681 Number of LACNIC addresses announced to Internet: 116179240 Equivalent to 6 /8s, 236 /16s and 193 /24s Percentage of available LACNIC address space announced: 69.2 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, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 9832 Total AfriNIC prefixes after maximum aggregation: 2213 AfriNIC Deaggregation factor: 4.44 Prefixes being announced from the AfriNIC address blocks: 10311 Unique aggregates announced from the AfriNIC address blocks: 3470 AfriNIC Region origin ASes present in the Internet Routing Table: 562 AfriNIC Prefixes per ASN: 18.35 AfriNIC Region origin ASes announcing only one prefix: 174 AfriNIC Region transit ASes present in the Internet Routing Table: 128 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 41805056 Equivalent to 2 /8s, 125 /16s and 229 /24s Percentage of available AfriNIC address space announced: 41.5 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2979 11429 904 Korea Telecom (KIX) 17974 2339 702 54 PT TELEKOMUNIKASI INDONESIA 7545 1757 301 86 TPG Internet Pty Ltd 4755 1617 387 162 TATA Communications formerly 9829 1333 1106 41 BSNL National Internet Backbo 9583 1177 87 513 Sify Limited 7552 1129 1062 11 Vietel Corporation 4808 1126 2050 320 CNCGROUP IP network: China169 24560 1040 385 159 Bharti Airtel Ltd., Telemedia 9498 1009 310 73 BHARTI Airtel Ltd. 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 3331 3735 185 bellsouth.net, inc. 7029 3154 990 161 Windstream Communications Inc 18566 2085 382 180 Covad Communications 1785 1911 678 128 PaeTec Communications, Inc. 22773 1886 2931 129 Cox Communications, Inc. 20115 1659 1580 615 Charter Communications 4323 1577 1154 387 Time Warner Telecom 30036 1388 273 744 Mediacom Communications Corp 7018 1241 10316 827 AT&T WorldNet Services 7011 1204 329 698 Citizens Utilities 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 8402 1654 544 16 Corbina telecom 2118 1401 97 14 EUnet/RELCOM Autonomous Syste 15557 1226 2247 55 LDCOM NETWORKS 12479 846 773 79 Uni2 Autonomous System 34984 766 205 179 BILISIM TELEKOM 6830 723 2313 447 UPC Distribution Services 20940 720 230 552 Akamai Technologies European 31148 709 37 9 FreeNet ISP 13188 668 100 9 Educational Network 58113 616 69 362 LIR DATACENTER TELECOM SRL 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 2155 368 223 TVCABLE BOGOTA 28573 2145 1248 54 NET Servicos de Comunicao S.A 8151 1580 3034 348 UniNet S.A. de C.V. 7303 1565 1034 199 Telecom Argentina Stet-France 6503 1535 451 69 AVANTEL, S.A. 6458 751 81 15 GUATEL 27947 722 74 94 Telconet S.A 3816 643 310 30 Empresa Nacional de Telecomun 11172 593 85 69 Servicios Alestra S.A de C.V 14420 581 83 100 CORPORACION NACIONAL DE TELEC 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 879 275 36 LINKdotNET AS number 8452 812 958 13 TEDATA 36998 772 48 3 MOBITEL 6713 517 650 19 Itissalat Al-MAGHRIB 24835 269 80 8 RAYA Telecom - Egypt 3741 263 904 223 The Internet Solution 33776 207 12 12 Starcomms Nigeria Limited 12258 194 28 66 Vodacom Internet Company 15706 193 32 6 Sudatel Internet Exchange Aut 29975 191 667 21 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 3331 3735 185 bellsouth.net, inc. 7029 3154 990 161 Windstream Communications Inc 4766 2979 11429 904 Korea Telecom (KIX) 17974 2339 702 54 PT TELEKOMUNIKASI INDONESIA 10620 2155 368 223 TVCABLE BOGOTA 28573 2145 1248 54 NET Servicos de Comunicao S.A 18566 2085 382 180 Covad Communications 1785 1911 678 128 PaeTec Communications, Inc. 22773 1886 2931 129 Cox Communications, Inc. 7545 1757 301 86 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7029 3154 2993 Windstream Communications Inc 17974 2339 2285 PT TELEKOMUNIKASI INDONESIA 28573 2145 2091 NET Servicos de Comunicao S.A 4766 2979 2075 Korea Telecom (KIX) 10620 2155 1932 TVCABLE BOGOTA 18566 2085 1905 Covad Communications 1785 1911 1783 PaeTec Communications, Inc. 22773 1886 1757 Cox Communications, Inc. 7545 1757 1671 TPG Internet Pty Ltd 8402 1654 1638 Corbina telecom Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 59505 UNALLOCATED 5.2.65.0/24 50673 Serverius AS 59505 UNALLOCATED 5.2.66.0/24 50673 Serverius AS 59414 UNALLOCATED 5.102.144.0/21 15576 Nextra backbone in D 59395 UNALLOCATED 5.133.16.0/21 12658 Dexterity Networks L 59407 UNALLOCATED 5.134.16.0/21 51167 Giga-Hosting GmbH 59521 UNALLOCATED 5.134.192.0/21 29518 Labs2 59441 UNALLOCATED 5.144.128.0/21 50810 Mobin Net Communicat 59581 UNALLOCATED 5.149.8.0/21 25577 C4L main AS 59457 UNALLOCATED 5.149.64.0/24 35567 DASTO semtel d.o.o. 59457 UNALLOCATED 5.149.64.0/19 35567 DASTO semtel d.o.o. Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.249.176.0/20 58056 IKT, d.o.o. 5.249.192.0/19 42277 RIPE Network Coordination Cen 5.254.128.0/24 42708 RIPE Network Coordination Cen 14.192.0.0/22 45464 Room 201, TGU Bldg 14.192.4.0/22 45464 Room 201, TGU Bldg 14.192.8.0/22 45464 Room 201, TGU Bldg 14.192.12.0/22 45464 Room 201, TGU Bldg 14.192.16.0/22 45464 Room 201, TGU Bldg 14.192.20.0/22 45464 Room 201, TGU Bldg 14.192.24.0/22 45464 Room 201, TGU Bldg 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:18 /9:14 /10:29 /11:84 /12:237 /13:476 /14:843 /15:1543 /16:12393 /17:6441 /18:10838 /19:21093 /20:30253 /21:32163 /22:42398 /23:39918 /24:223596 /25:1402 /26:1664 /27:924 /28:175 /29:62 /30:18 /31:0 /32:24 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 2641 3154 Windstream Communications Inc 18566 2035 2085 Covad Communications 6389 1851 3331 bellsouth.net, inc. 8402 1377 1654 Corbina telecom 30036 1323 1388 Mediacom Communications Corp 22773 1227 1886 Cox Communications, Inc. 15557 1170 1226 LDCOM NETWORKS 11492 1161 1198 Cable One 6503 1053 1535 AVANTEL, S.A. 1785 1013 1911 PaeTec Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:604 2:600 3:1 4:13 5:485 6:3 8:457 12:2000 13:1 14:664 15:11 16:3 17:6 20:27 23:206 24:1789 27:1358 31:1022 32:56 33:2 34:2 36:7 37:737 38:829 39:2 40:133 41:3072 42:158 44:3 46:1587 47:2 49:476 50:595 52:13 54:18 55:9 56:1 57:31 58:986 59:531 60:241 61:1292 62:950 63:1995 64:4266 65:2240 66:4500 67:2040 68:1170 69:3202 70:987 71:509 72:1871 74:2599 75:483 76:313 77:949 78:960 79:488 80:1264 81:957 82:628 83:532 84:615 85:1159 86:810 87:923 88:363 89:1805 90:302 91:5206 92:579 93:1546 94:1604 95:1167 96:416 97:319 98:994 99:39 100:23 101:261 103:1533 105:512 106:118 107:198 108:455 109:1935 110:797 111:964 112:450 113:704 114:657 115:813 116:891 117:729 118:935 119:1266 120:309 121:688 122:1645 123:1161 124:1345 125:1284 128:549 129:184 130:282 131:633 132:301 133:22 134:250 135:61 136:217 137:239 138:340 139:171 140:500 141:282 142:487 143:370 144:497 145:80 146:515 147:257 148:757 149:324 150:157 151:170 152:450 153:183 154:20 155:419 156:222 157:381 158:186 159:647 160:343 161:414 162:359 163:190 164:693 165:420 166:530 167:550 168:964 169:125 170:908 171:150 172:7 173:1688 174:612 175:440 176:799 177:1166 178:1645 180:1361 181:136 182:1052 183:295 184:605 186:2242 187:1248 188:1501 189:1578 190:6026 192:6030 193:5725 194:4554 195:3455 196:1200 197:220 198:3784 199:4996 200:5967 201:1957 202:8714 203:8726 204:4431 205:2548 206:2780 207:2874 208:4069 209:3656 210:2837 211:1533 212:2034 213:1814 214:883 215:87 216:5135 217:1550 218:569 219:315 220:1242 221:536 222:334 223:385 End of report From lists at mtin.net Fri Sep 14 14:22:39 2012 From: lists at mtin.net (Justin Wilson) Date: Fri, 14 Sep 2012 15:22:39 -0400 Subject: Layer2 over Layer3 In-Reply-To: Message-ID: Mikrotik supports a proprietary format called an EOIP (ethernet over IP) tunnel. Justin -- Justin Wilson Aol & Yahoo IM: j2sw http://www.mtin.net/blog ? xISP News http://www.twitter.com/j2sw ? Follow me on Twitter http://www.thebrotherswisp.com -----Original Message----- From: mohamed Osama Saad Abo sree Date: Wednesday, September 12, 2012 6:33 PM To: Philip Lavine Cc: NANOG list Subject: Re: Layer2 over Layer3 >hello philip, >for ethernet over mpls you can use gre tunnel and run mpls over that >tunnel or you can go directly for l2tpv3 which give you the ability to >run l2vpn over l3 ip routing with no need for mpls. > >BR, >Mohamed Abosree > >On 9/13/12, Philip Lavine wrote: >> To all, >> >> I am trying to extend a layer2 connection over Layer 3 so I can have >> redundant Layer connectivity between my HQ and colo site. The reason I >>need >> this is so I can give the "appeareance" that there is one gateway and >>that >> both data centers can share the same Layer3 subnet (which I am >>announcing >> via BGP to 2 different vendors). >> >> I have 2 ASR's. Will EoMPLS work or is there another option? >> >> Philip >> > > >-- >Live As If You Were To Die Tomorrow. Learn As If You Were To Live Forever. > From jra at baylink.com Fri Sep 14 15:55:01 2012 From: jra at baylink.com (Jay Ashworth) Date: Fri, 14 Sep 2012 16:55:01 -0400 (EDT) Subject: Big Temporary Networks In-Reply-To: <20120914160830.GA69921@ussenterprise.ufp.org> Message-ID: <10203926.24928.1347656101231.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Leo Bicknell" > I find more and more hotel networks are essentially unusable for > parts of the day, conference or no. Of course, bring in any geek > contingent with multiple devices and heavy usage patterns and the > problems get worse. > > What I find most interesting is more often than not the problem > appears to be an overloaded / undersized NAT/Captive portal/DNS > Resolver system. Behaviors like existing connections working fine, > but no new ones can be created (out of ports on the NAT?). While > bandwidth is occasionally an issue, I've found an ssh tunnel out > to some other end point solves the issues in 9 out of 10 cases. Neither part of that surprises me. :-} I'm *almost* convinced not to NAT IPv4, so far. > I wonder how many hotels upgrade their bandwidth but not the gateway, > get a report that their DS-3/OC-3/Metro-E is only 25% used, and think > all is well. Mean while half their clients can't connect to anything > due to the gateway device. That's an interesting question indeed. The optimal solution here, of course, would be for Worldcons -- which are planned 3-4 years in advance -- to get the right technical people in the loop with the property to see when in the next 2 years (after a bid is confirmed) they plan to upgrade the networking they have now... and make sure it will tolerate a "real" worst case. The business case for the property, of course, is that they're more salable to large technical conferences -- which makes them more money. Question is, is it enough. Or do I just overlay for the event. Cheers ,-- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From carlos at race.com Fri Sep 14 16:23:47 2012 From: carlos at race.com (Carlos Alcantar) Date: Fri, 14 Sep 2012 21:23:47 +0000 Subject: Transport Fee's (Taxes and random telecom fee's) In-Reply-To: <505360F8.7070007@viviotech.net> Message-ID: Typically you have to file once a year with the companies to let them know you are tax exempt. As your company status may change. Carlos Alcantar Race Communications / Race Team Member 1325 Howard Ave. #604, Burlingame, CA. 94010 Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com -----Original Message----- From: Mark Keymer Date: Friday, September 14, 2012 9:53 AM To: "nanog at nanog.org" Subject: Re: Transport Fee's (Taxes and random telecom fee's) I had to deal with this with an upstream once that was taxing me. Finally got it all worked out after sending in copies of the law and getting the CEO involved. However a year or two later I started to get taxed again when the company was bought out. Had to resend copies of the law (Fed and State) over to them again. I also had the full conversation with the previous CEO so I sent that over as well as he was now a VP under the new company. Do to how much of a hassle I had to go through, I am guessing they still keep charging tax on other clients that probably should not have been! Sincerely, Mark Keymer On 9/14/2012 8:15 AM, Faisal Imtiaz wrote: > > All Communication Circuits are subject to Communication Taxes, as per > Tax laws of that State. > > Having said that... if this communication circuit is carrying Internet > Traffic, you can contact the Carrier and Ask them to provide you the > forms so that you can > Claim "ITFA / ITNA Exemption" ...(if you are not in a grandfathered > state) Google for "Internet Tax Freedom Act" and review the Wikipedia > article for more details and history. > > In regards to Dark Fiber..... > Active Circuits = i.e. circuits where signaling is provided by the > Carrier are considered to be Communication Circuits and are subject > to Communication taxes, as per the State Laws. > > Dark Fiber is considered to be an asset purchase .. i.e. like leasing > Office Space/ Automobile / or Machinery... and as such the Lease > Payments are subject to Sales Taxes only (again, details may vary from > State to State). > > Regards. > > Faisal Imtiaz > Snappy Internet & Telecom > 7266 SW 48 Street > Miami, Fl 33155 > Tel: 305 663 5518 x 232 > Helpdesk: 305 663 5518 option 2 Email: Support at Snappydsl.net > > On 9/14/2012 10:29 AM, A. Pishdadi wrote: >> Hello Everyone, >> >> We purchase 10Gig waves for transport out of our datacenter and are >> trying >> to figure out why the taxes on the circuits are so much. We are paying >> around 60% additional in taxes and fee's on top of the cost of the >> circuit. >> Ofcourse when we were negotiating pricing , it seemed like a great price >> until we got our first bill, they forgot to mention that we would be >> paying >> such fees. >> It seems like these taxes would be for companies who would be using >> transport services for voice, but we are all data. Is there any way >> to get >> a tax exempt status? How come the same fee's do not apply to dark >> fiber? We >> are in process of getting dark fiber to replace the transport >> circuits but >> its going to take quite some time as we have a few more years on some >> of the >> contracts. The dark fiber we do have there is no taxes at all. Can >> anyone >> shed any light on this? >> > > > From source_route at yahoo.com Fri Sep 14 16:58:04 2012 From: source_route at yahoo.com (Philip Lavine) Date: Fri, 14 Sep 2012 14:58:04 -0700 (PDT) Subject: Layer2 over Layer3 In-Reply-To: References: <1347488580.64588.YahooMailNeo@web121701.mail.ne1.yahoo.com> <6E5736BD68F770449C74FBAD975F807C8FE98A09@NYDC-EXCH01.vinci-consulting-corp.local> Message-ID: <1347659884.55493.YahooMailNeo@web121706.mail.ne1.yahoo.com> If the psuedowire is setup to allow a vlan to be exteneded,?but?the vlan is already extended over a dedicated link, how will spanning tree behave? Right now I have it setup and I dont see the psuedowire trunk in a blocking state. Will the switch that has both the pseudowire trunk on it and the dedicated link know how to forward the frames if either goes away? ? ________________________________ From: David Swafford To: Paul Vinciguerra Cc: Philip Lavine ; NANOG list Sent: Wednesday, September 12, 2012 7:46 PM Subject: Re: Layer2 over Layer3 Hey Philip, Any Transport over MPLS will do this too.? Here's a link to an example setup of two sites where just L3 connectivity exists between them: https://w.ntwk.cc/working-on-atompls/.? In that setup, I have just IPSEC VPN connecting the two locations, but have an 802.1q trunk extended between both.? In the example configs, Fa0/1 on both ends is a transparent L2 connection.? The boxes used here were 3725s on 12.4T. David. On Wed, Sep 12, 2012 at 3:37 PM, Paul Vinciguerra wrote: > ASR supports OTV if you can do multicast over L3.? Although, you may not need L2 extensions in the end. > > -----Original Message----- > From: Philip Lavine [mailto:source_route at yahoo.com] > Sent: Wednesday, September 12, 2012 6:23 PM > To: NANOG list > Subject: Layer2 over Layer3 > > To all, > > I am trying to extend a layer2 connection over Layer 3 so I can have redundant Layer connectivity between my HQ and colo site. The reason I need this is so I can give the "appeareance" that there is one gateway and that both data centers can share the same Layer3 subnet (which I am announcing via BGP to 2 different vendors). > > I have 2 ASR's. Will EoMPLS work or is there another option? > > Philip > From cidr-report at potaroo.net Fri Sep 14 17:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 14 Sep 2012 22:00:00 GMT Subject: The Cidr Report Message-ID: <201209142200.q8EM00d5088324@wattle.apnic.net> This report has been generated at Fri Sep 14 21:13:03 2012 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 07-09-12 427365 246274 08-09-12 428107 246515 09-09-12 428524 246572 10-09-12 428665 246586 11-09-12 428741 246649 12-09-12 429120 246892 13-09-12 428900 246353 14-09-12 429020 246568 AS Summary 42211 Number of ASes in routing system 17607 Number of ASes announcing only one prefix 3329 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 113311968 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'). --- 14Sep12 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 429249 246442 182807 42.6% All ASes AS6389 3329 188 3141 94.4% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2144 58 2086 97.3% NET Servicos de Comunicao S.A. AS4766 2981 941 2040 68.4% KIXS-AS-KR Korea Telecom AS22773 1884 161 1723 91.5% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS17974 2339 618 1721 73.6% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS7029 3154 1480 1674 53.1% WINDSTREAM - Windstream Communications Inc AS18566 2085 423 1662 79.7% COVAD - Covad Communications Co. AS2118 1401 14 1387 99.0% RELCOM-AS OOO "NPO Relcom" AS10620 2117 784 1333 63.0% Telmex Colombia S.A. AS4323 1582 392 1190 75.2% TWTC - tw telecom holdings, inc. AS7303 1565 451 1114 71.2% Telecom Argentina S.A. AS1785 1915 821 1094 57.1% AS-PAETEC-NET - PaeTec Communications, Inc. AS4755 1617 545 1072 66.3% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7552 1129 210 919 81.4% VIETEL-AS-AP Vietel Corporation AS8151 1583 708 875 55.3% Uninet S.A. de C.V. AS18101 941 158 783 83.2% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1126 355 771 68.5% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS13977 857 119 738 86.1% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS6458 749 42 707 94.4% Telgua AS15557 1226 560 666 54.3% LDCOMNET Societe Francaise du Radiotelephone S.A AS36998 772 124 648 83.9% SDN-MOBITEL AS855 683 52 631 92.4% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS3356 1105 474 631 57.1% LEVEL3 Level 3 Communications AS17676 710 85 625 88.0% GIGAINFRA Softbank BB Corp. AS22561 1027 428 599 58.3% DIGITAL-TELEPORT - Digital Teleport Inc. AS19262 1002 404 598 59.7% VZGNI-TRANSIT - Verizon Online LLC AS24560 1041 443 598 57.4% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7545 1758 1184 574 32.7% TPG-INTERNET-AP TPG Internet Pty Ltd AS3549 1008 435 573 56.8% GBLX Global Crossing Ltd. AS30036 1388 824 564 40.6% MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp Total 46218 13481 32737 70.8% Top 30 total Possible Bogus Routes 5.254.128.0/24 AS42708 PORTLANE Portlane Networks AB 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 14.192.0.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.4.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.8.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.12.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.16.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.20.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.24.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.28.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 41.220.80.0/24 AS38925 DAC-AS G.I.T. TELECOM LIMITED 41.220.81.0/24 AS38925 DAC-AS G.I.T. TELECOM LIMITED 41.220.94.0/23 AS42235 IDC-AS Intra Data Communication 41.222.80.0/21 AS37110 moztel-as 41.223.108.0/22 AS36966 EDL_AS Edgenet AS 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.66.32.0/20 AS18864 64.187.208.0/24 AS174 COGENT Cogent/PSI 64.187.209.0/24 AS23005 SWITCH-COMMUNICATIONS - SWITCH Communications Group LLC 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 70.34.112.0/20 AS27589 MOJOHOST - MOJOHOST 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.115.124.0/23 AS46540 74.115.126.0/24 AS11260 EASTLINK-HSI - EastLink 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 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 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.254.254.0/24 AS26274 187.252.0.0/24 AS28557 Cablemas Telecomunicaciones SA de CV 187.252.1.0/24 AS28557 Cablemas Telecomunicaciones SA de CV 192.0.0.0/24 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 194.0.58.0/24 AS49962 ZERO zero.net.uk Ltd 198.18.0.0/15 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 198.51.100.0/24 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.6.49.0/24 AS23148 TERREMARK Terremark 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 200.58.248.0/21 AS27849 200.75.184.0/24 AS14754 Telgua 200.75.185.0/24 AS14754 Telgua 200.75.186.0/24 AS14754 Telgua 200.75.187.0/24 AS14754 Telgua 200.75.188.0/24 AS14754 Telgua 200.75.189.0/24 AS14754 Telgua 200.75.190.0/24 AS14754 Telgua 200.75.191.0/24 AS14754 Telgua 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 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.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 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.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.0.113.0/24 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 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.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.142.219.0/24 AS45149 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.14.0.0/21 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 204.14.0.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 204.14.2.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 204.14.3.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 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.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.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.93.144.0/21 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 208.93.151.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.21.160.0/20 AS27876 American Data Networks 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.194.160.0/20 AS27876 American Data Networks Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org 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 Sep 14 17:00:02 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 14 Sep 2012 22:00:02 GMT Subject: BGP Update Report Message-ID: <201209142200.q8EM020d088346@wattle.apnic.net> BGP Update Report Interval: 06-Sep-12 -to- 13-Sep-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS30137 94685 5.1% 1552.2 -- SEA-BROADBAND - Sea Broadband, LLC 2 - AS6517 54436 3.0% 273.5 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 3 - AS9829 53829 2.9% 42.3 -- BSNL-NIB National Internet Backbone 4 - AS8402 47127 2.5% 27.0 -- CORBINA-AS OJSC "Vimpelcom" 5 - AS22561 25881 1.4% 184.9 -- DIGITAL-TELEPORT - Digital Teleport Inc. 6 - AS1637 21255 1.1% 590.4 -- DNIC-AS-01637 - Headquarters, USAISC 7 - AS24560 19948 1.1% 21.3 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 8 - AS13118 19913 1.1% 19913.0 -- ASN-YARTELECOM OJSC Rostelecom 9 - AS5800 14966 0.8% 58.7 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 10 - AS28573 13156 0.7% 7.8 -- NET Servicos de Comunicao S.A. 11 - AS21599 12839 0.7% 118.9 -- NETDIRECT S.A. 12 - AS2697 11828 0.6% 87.0 -- ERX-ERNET-AS Education and Research Network 13 - AS10198 11675 0.6% 2335.0 -- CUP-AS-KR Catholic University of Pusan 14 - AS14420 10070 0.5% 18.9 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 15 - AS6629 10017 0.5% 5008.5 -- NOAA-AS - NOAA 16 - AS2118 9684 0.5% 6.9 -- RELCOM-AS OOO "NPO Relcom" 17 - AS36998 9397 0.5% 18.4 -- SDN-MOBITEL 18 - AS38547 9282 0.5% 21.5 -- WITRIBE-AS-AP WITRIBE PAKISTAN LIMITED 19 - AS27947 8993 0.5% 26.8 -- Telconet S.A 20 - AS25620 8573 0.5% 59.1 -- COTAS LTDA. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS13118 19913 1.1% 19913.0 -- ASN-YARTELECOM OJSC Rostelecom 2 - AS6629 10017 0.5% 5008.5 -- NOAA-AS - NOAA 3 - AS38920 7067 0.4% 3533.5 -- TURKLANDBANK-TR TURKLANDBANK 4 - AS14680 7017 0.4% 2339.0 -- REALE-6 - Auction.com 5 - AS10198 11675 0.6% 2335.0 -- CUP-AS-KR Catholic University of Pusan 6 - AS44410 6789 0.4% 2263.0 -- ENTEKHAB-AS ENTEKHAB INDUSTRIAL GROUP 7 - AS6197 2182 0.1% 2182.0 -- BATI-ATL - BellSouth Network Solutions, Inc 8 - AS30137 94685 5.1% 1552.2 -- SEA-BROADBAND - Sea Broadband, LLC 9 - AS22753 3074 0.2% 1537.0 -- REDHAT-STUTTGART REDHAT Stuttgart 10 - AS36948 3069 0.2% 1534.5 -- KENIC 11 - AS25911 1402 0.1% 1402.0 -- TALISMAN-CH3 - TALISMAN ENERGY INC. 12 - AS36529 2564 0.1% 1282.0 -- AXXA-RACKCO - Rackco.com 13 - AS41733 7682 0.4% 1097.4 -- ZTELECOM-AS JSC "Z-Telecom" 14 - AS48696 1006 0.1% 1006.0 -- TEMP-AS TEMP Ltd. 15 - AS56763 1002 0.1% 1002.0 -- INFOTELL-AS Infotell-Telecom Ltd 16 - AS29126 940 0.1% 940.0 -- DATIQ-AS Datiq B.V. 17 - AS38857 1713 0.1% 856.5 -- ESOFT-TRANSIT-AS-AP e.Soft Technologies Ltd. 18 - AS29524 806 0.0% 806.0 -- GUILBERT GUILBERT AS NUMBER 19 - AS26260 783 0.0% 783.0 -- WAUSAU-BENEFITS-INC - Wausau Benefits, Inc 20 - AS32244 730 0.0% 730.0 -- LIQUID-WEB-INC - Liquid Web, Inc. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/19 19913 1.0% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 184.159.130.0/23 13098 0.7% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. 3 - 184.157.224.0/19 10762 0.6% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. 4 - 200.46.0.0/19 10122 0.5% AS21599 -- NETDIRECT S.A. 5 - 199.250.214.0/24 8213 0.4% AS6517 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 6 - 199.250.205.0/24 8209 0.4% AS6517 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 7 - 199.250.193.0/24 8208 0.4% AS6517 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 8 - 199.250.192.0/24 8208 0.4% AS6517 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 9 - 202.41.70.0/24 7879 0.4% AS2697 -- ERX-ERNET-AS Education and Research Network 10 - 74.91.52.0/24 7877 0.4% AS30137 -- SEA-BROADBAND - Sea Broadband, LLC 11 - 74.91.59.0/24 7877 0.4% AS30137 -- SEA-BROADBAND - Sea Broadband, LLC 12 - 74.91.56.0/24 7877 0.4% AS30137 -- SEA-BROADBAND - Sea Broadband, LLC 13 - 74.91.61.0/24 7877 0.4% AS30137 -- SEA-BROADBAND - Sea Broadband, LLC 14 - 74.91.57.0/24 7877 0.4% AS30137 -- SEA-BROADBAND - Sea Broadband, LLC 15 - 74.91.58.0/24 7877 0.4% AS30137 -- SEA-BROADBAND - Sea Broadband, LLC 16 - 74.91.63.0/24 7877 0.4% AS30137 -- SEA-BROADBAND - Sea Broadband, LLC 17 - 74.91.54.0/24 7877 0.4% AS30137 -- SEA-BROADBAND - Sea Broadband, LLC 18 - 74.91.60.0/24 7877 0.4% AS30137 -- SEA-BROADBAND - Sea Broadband, LLC 19 - 74.91.53.0/24 7877 0.4% AS30137 -- SEA-BROADBAND - Sea Broadband, LLC 20 - 74.91.62.0/24 7877 0.4% AS30137 -- SEA-BROADBAND - Sea Broadband, LLC Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From source_route at yahoo.com Fri Sep 14 17:05:53 2012 From: source_route at yahoo.com (Philip Lavine) Date: Fri, 14 Sep 2012 15:05:53 -0700 (PDT) Subject: Layer2 over Layer3 References: <1347488580.64588.YahooMailNeo@web121701.mail.ne1.yahoo.com> <6E5736BD68F770449C74FBAD975F807C8FE98A09@NYDC-EXCH01.vinci-consulting-corp.local> Message-ID: <1347660353.52370.YahooMailNeo@web121702.mail.ne1.yahoo.com> If the psuedowire is setup to allow a vlan to be exteneded,?but?the vlan is already extended over a dedicated link, how will spanning tree behave? Right now I have it setup and I dont see the psuedowire trunk in a blocking state. Will the switch that has both the pseudowire trunk on it and the dedicated link know how to forward the frames if either goes away? ? ________________________________ From: David Swafford To: Paul Vinciguerra Cc: Philip Lavine ; NANOG list Sent: Wednesday, September 12, 2012 7:46 PM Subject: Re: Layer2 over Layer3 Hey Philip, Any Transport over MPLS will do this too.? Here's a link to an example setup of two sites where just L3 connectivity exists between them: https://w.ntwk.cc/working-on-atompls/.? In that setup, I have just IPSEC VPN connecting the two locations, but have an 802.1q trunk extended between both.? In the example configs, Fa0/1 on both ends is a transparent L2 connection.? The boxes used here were 3725s on 12.4T. David. On Wed, Sep 12, 2012 at 3:37 PM, Paul Vinciguerra wrote: > ASR supports OTV if you can do multicast over L3.? Although, you may not need L2 extensions in the end. > > -----Original Message----- > From: Philip Lavine [mailto:source_route at yahoo.com] > Sent: Wednesday, September 12, 2012 6:23 PM > To: NANOG list > Subject: Layer2 over Layer3 > > To all, > > I am trying to extend a layer2 connection over Layer 3 so I can have redundant Layer connectivity between my HQ and colo site. The reason I need this is so I can give the "appeareance" that there is one gateway and that both data centers can share the same Layer3 subnet (which I am announcing via BGP to 2 different vendors). > > I have 2 ASR's. Will EoMPLS work or is there another option? > > Philip > From pvinci at VinciConsulting.com Fri Sep 14 17:08:29 2012 From: pvinci at VinciConsulting.com (Paul Vinciguerra) Date: Fri, 14 Sep 2012 22:08:29 +0000 Subject: Layer2 over Layer3 In-Reply-To: <1347660353.52370.YahooMailNeo@web121702.mail.ne1.yahoo.com> References: <1347488580.64588.YahooMailNeo@web121701.mail.ne1.yahoo.com> <6E5736BD68F770449C74FBAD975F807C8FE98A09@NYDC-EXCH01.vinci-consulting-corp.local> <1347660353.52370.YahooMailNeo@web121702.mail.ne1.yahoo.com> Message-ID: <6E5736BD68F770449C74FBAD975F807C8FE9A617@NYDC-EXCH01.vinci-consulting-corp.local> Philip, Here is the best reference I know of to address your issue. http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper_c11_493718.html#wp9000281 From: Philip Lavine [mailto:source_route at yahoo.com] Sent: Friday, September 14, 2012 6:06 PM To: David Swafford; Paul Vinciguerra Cc: NANOG list Subject: Re: Layer2 over Layer3 If the psuedowire is setup to allow a vlan to be exteneded, but the vlan is already extended over a dedicated link, how will spanning tree behave? Right now I have it setup and I dont see the psuedowire trunk in a blocking state. Will the switch that has both the pseudowire trunk on it and the dedicated link know how to forward the frames if either goes away? From: David Swafford > To: Paul Vinciguerra > Cc: Philip Lavine >; NANOG list > Sent: Wednesday, September 12, 2012 7:46 PM Subject: Re: Layer2 over Layer3 Hey Philip, Any Transport over MPLS will do this too. Here's a link to an example setup of two sites where just L3 connectivity exists between them: https://w.ntwk.cc/working-on-atompls/. In that setup, I have just IPSEC VPN connecting the two locations, but have an 802.1q trunk extended between both. In the example configs, Fa0/1 on both ends is a transparent L2 connection. The boxes used here were 3725s on 12.4T. David. On Wed, Sep 12, 2012 at 3:37 PM, Paul Vinciguerra > wrote: > ASR supports OTV if you can do multicast over L3. Although, you may not need L2 extensions in the end. > > -----Original Message----- > From: Philip Lavine [mailto:source_route at yahoo.com] > Sent: Wednesday, September 12, 2012 6:23 PM > To: NANOG list > Subject: Layer2 over Layer3 > > To all, > > I am trying to extend a layer2 connection over Layer 3 so I can have redundant Layer connectivity between my HQ and colo site. The reason I need this is so I can give the "appeareance" that there is one gateway and that both data centers can share the same Layer3 subnet (which I am announcing via BGP to 2 different vendors). > > I have 2 ASR's. Will EoMPLS work or is there another option? > > Philip > From apishdadi at gmail.com Fri Sep 14 18:25:47 2012 From: apishdadi at gmail.com (A. Pishdadi) Date: Fri, 14 Sep 2012 18:25:47 -0500 Subject: Transport Fee's (Taxes and random telecom fee's) In-Reply-To: References: <505360F8.7070007@viviotech.net> Message-ID: How do we get tax-exempt status though, with ""ITFA / ITNA Exemption" like faisel said? On Fri, Sep 14, 2012 at 4:23 PM, Carlos Alcantar wrote: > Typically you have to file once a year with the companies to let them know > you are tax exempt. As your company status may change. > > Carlos Alcantar > Race Communications / Race Team Member > 1325 Howard Ave. #604, Burlingame, CA. 94010 > Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com > > > > > > -----Original Message----- > From: Mark Keymer > Date: Friday, September 14, 2012 9:53 AM > To: "nanog at nanog.org" > Subject: Re: Transport Fee's (Taxes and random telecom fee's) > > I had to deal with this with an upstream once that was taxing me. > Finally got it all worked out after sending in copies of the law and > getting the CEO involved. However a year or two later I started to get > taxed again when the company was bought out. Had to resend copies of the > law (Fed and State) over to them again. I also had the full conversation > with the previous CEO so I sent that over as well as he was now a VP > under the new company. > > Do to how much of a hassle I had to go through, I am guessing they still > keep charging tax on other clients that probably should not have been! > > Sincerely, > > Mark Keymer > > On 9/14/2012 8:15 AM, Faisal Imtiaz wrote: > > > > All Communication Circuits are subject to Communication Taxes, as per > > Tax laws of that State. > > > > Having said that... if this communication circuit is carrying Internet > > Traffic, you can contact the Carrier and Ask them to provide you the > > forms so that you can > > Claim "ITFA / ITNA Exemption" ...(if you are not in a grandfathered > > state) Google for "Internet Tax Freedom Act" and review the Wikipedia > > article for more details and history. > > > > In regards to Dark Fiber..... > > Active Circuits = i.e. circuits where signaling is provided by the > > Carrier are considered to be Communication Circuits and are subject > > to Communication taxes, as per the State Laws. > > > > Dark Fiber is considered to be an asset purchase .. i.e. like leasing > > Office Space/ Automobile / or Machinery... and as such the Lease > > Payments are subject to Sales Taxes only (again, details may vary from > > State to State). > > > > Regards. > > > > Faisal Imtiaz > > Snappy Internet & Telecom > > 7266 SW 48 Street > > Miami, Fl 33155 > > Tel: 305 663 5518 x 232 > > Helpdesk: 305 663 5518 option 2 Email: Support at Snappydsl.net > > > > On 9/14/2012 10:29 AM, A. Pishdadi wrote: > >> Hello Everyone, > >> > >> We purchase 10Gig waves for transport out of our datacenter and are > >> trying > >> to figure out why the taxes on the circuits are so much. We are paying > >> around 60% additional in taxes and fee's on top of the cost of the > >> circuit. > >> Ofcourse when we were negotiating pricing , it seemed like a great price > >> until we got our first bill, they forgot to mention that we would be > >> paying > >> such fees. > >> It seems like these taxes would be for companies who would be using > >> transport services for voice, but we are all data. Is there any way > >> to get > >> a tax exempt status? How come the same fee's do not apply to dark > >> fiber? We > >> are in process of getting dark fiber to replace the transport > >> circuits but > >> its going to take quite some time as we have a few more years on some > >> of the > >> contracts. The dark fiber we do have there is no taxes at all. Can > >> anyone > >> shed any light on this? > >> > > > > > > > > > > > > From faisal at snappydsl.net Fri Sep 14 18:36:03 2012 From: faisal at snappydsl.net (Faisal Imtiaz) Date: Fri, 14 Sep 2012 19:36:03 -0400 Subject: Transport Fee's (Taxes and random telecom fee's) In-Reply-To: References: <505360F8.7070007@viviotech.net> Message-ID: <5053BF63.40301@snappydsl.net> There is no 'Certification' required for it.. All it requires is a 'declaration'.... 1st Step.... Contact the Tax Dept. of your Carrier and ask them for the ITFA/ITNA exemption form. You might get a hard time from the Front line.. but get to a Supervisor... once you have the form, all you need to to is fill it out and sign it. Regards. Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, Fl 33155 Tel: 305 663 5518 x 232 Helpdesk: 305 663 5518 option 2 Email: Support at Snappydsl.net On 9/14/2012 7:25 PM, A. Pishdadi wrote: > How do we get tax-exempt status though, with ""ITFA / ITNA Exemption" like > faisel said? > > On Fri, Sep 14, 2012 at 4:23 PM, Carlos Alcantar wrote: > >> Typically you have to file once a year with the companies to let them know >> you are tax exempt. As your company status may change. >> >> Carlos Alcantar >> Race Communications / Race Team Member >> 1325 Howard Ave. #604, Burlingame, CA. 94010 >> Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com >> >> >> >> >> >> -----Original Message----- >> From: Mark Keymer >> Date: Friday, September 14, 2012 9:53 AM >> To: "nanog at nanog.org" >> Subject: Re: Transport Fee's (Taxes and random telecom fee's) >> >> I had to deal with this with an upstream once that was taxing me. >> Finally got it all worked out after sending in copies of the law and >> getting the CEO involved. However a year or two later I started to get >> taxed again when the company was bought out. Had to resend copies of the >> law (Fed and State) over to them again. I also had the full conversation >> with the previous CEO so I sent that over as well as he was now a VP >> under the new company. >> >> Do to how much of a hassle I had to go through, I am guessing they still >> keep charging tax on other clients that probably should not have been! >> >> Sincerely, >> >> Mark Keymer >> >> On 9/14/2012 8:15 AM, Faisal Imtiaz wrote: >>> All Communication Circuits are subject to Communication Taxes, as per >>> Tax laws of that State. >>> >>> Having said that... if this communication circuit is carrying Internet >>> Traffic, you can contact the Carrier and Ask them to provide you the >>> forms so that you can >>> Claim "ITFA / ITNA Exemption" ...(if you are not in a grandfathered >>> state) Google for "Internet Tax Freedom Act" and review the Wikipedia >>> article for more details and history. >>> >>> In regards to Dark Fiber..... >>> Active Circuits = i.e. circuits where signaling is provided by the >>> Carrier are considered to be Communication Circuits and are subject >>> to Communication taxes, as per the State Laws. >>> >>> Dark Fiber is considered to be an asset purchase .. i.e. like leasing >>> Office Space/ Automobile / or Machinery... and as such the Lease >>> Payments are subject to Sales Taxes only (again, details may vary from >>> State to State). >>> >>> Regards. >>> >>> Faisal Imtiaz >>> Snappy Internet & Telecom >>> 7266 SW 48 Street >>> Miami, Fl 33155 >>> Tel: 305 663 5518 x 232 >>> Helpdesk: 305 663 5518 option 2 Email: Support at Snappydsl.net >>> >>> On 9/14/2012 10:29 AM, A. Pishdadi wrote: >>>> Hello Everyone, >>>> >>>> We purchase 10Gig waves for transport out of our datacenter and are >>>> trying >>>> to figure out why the taxes on the circuits are so much. We are paying >>>> around 60% additional in taxes and fee's on top of the cost of the >>>> circuit. >>>> Ofcourse when we were negotiating pricing , it seemed like a great price >>>> until we got our first bill, they forgot to mention that we would be >>>> paying >>>> such fees. >>>> It seems like these taxes would be for companies who would be using >>>> transport services for voice, but we are all data. Is there any way >>>> to get >>>> a tax exempt status? How come the same fee's do not apply to dark >>>> fiber? We >>>> are in process of getting dark fiber to replace the transport >>>> circuits but >>>> its going to take quite some time as we have a few more years on some >>>> of the >>>> contracts. The dark fiber we do have there is no taxes at all. Can >>>> anyone >>>> shed any light on this? >>>> >>> >>> >> >> >> >> >> From frnkblk at iname.com Fri Sep 14 23:07:51 2012 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 14 Sep 2012 23:07:51 -0500 Subject: Transport Fee's (Taxes and random telecom fee's) In-Reply-To: References: Message-ID: <000f01cd92f7$ad018db0$0704a910$@iname.com> I believe you don't need to pay FUSC charges if you're not the end-user of the circuit. Frank -----Original Message----- From: A. Pishdadi [mailto:apishdadi at gmail.com] Sent: Friday, September 14, 2012 9:30 AM To: NANOG Subject: Transport Fee's (Taxes and random telecom fee's) Hello Everyone, We purchase 10Gig waves for transport out of our datacenter and are trying to figure out why the taxes on the circuits are so much. We are paying around 60% additional in taxes and fee's on top of the cost of the circuit. Ofcourse when we were negotiating pricing , it seemed like a great price until we got our first bill, they forgot to mention that we would be paying such fees. It seems like these taxes would be for companies who would be using transport services for voice, but we are all data. Is there any way to get a tax exempt status? How come the same fee's do not apply to dark fiber? We are in process of getting dark fiber to replace the transport circuits but its going to take quite some time as we have a few more years on some of the contracts. The dark fiber we do have there is no taxes at all. Can anyone shed any light on this? From carlos at race.com Fri Sep 14 23:46:58 2012 From: carlos at race.com (Carlos Alcantar) Date: Sat, 15 Sep 2012 04:46:58 +0000 Subject: Transport Fee's (Taxes and random telecom fee's) In-Reply-To: <000f01cd92f7$ad018db0$0704a910$@iname.com> Message-ID: 499 from the fcc for federal as well as any local certs as that is state to state. Note once you get your 499 you are required to file with them, and pay the taxes. At the end of it you need to start charging your end users tax's and filing them. Carlos Alcantar Race Communications / Race Team Member 1325 Howard Ave. #604, Burlingame, CA. 94010 Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com -----Original Message----- From: Frank Bulk Date: Friday, September 14, 2012 9:07 PM To: "'A. Pishdadi'" , "nanog at nanog.org" Subject: RE: Transport Fee's (Taxes and random telecom fee's) I believe you don't need to pay FUSC charges if you're not the end-user of the circuit. Frank -----Original Message----- From: A. Pishdadi [mailto:apishdadi at gmail.com] Sent: Friday, September 14, 2012 9:30 AM To: NANOG Subject: Transport Fee's (Taxes and random telecom fee's) Hello Everyone, We purchase 10Gig waves for transport out of our datacenter and are trying to figure out why the taxes on the circuits are so much. We are paying around 60% additional in taxes and fee's on top of the cost of the circuit. Ofcourse when we were negotiating pricing , it seemed like a great price until we got our first bill, they forgot to mention that we would be paying such fees. It seems like these taxes would be for companies who would be using transport services for voice, but we are all data. Is there any way to get a tax exempt status? How come the same fee's do not apply to dark fiber? We are in process of getting dark fiber to replace the transport circuits but its going to take quite some time as we have a few more years on some of the contracts. The dark fiber we do have there is no taxes at all. Can anyone shed any light on this? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5571 bytes Desc: not available URL: From mansaxel at besserwisser.org Sat Sep 15 02:23:40 2012 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Sat, 15 Sep 2012 09:23:40 +0200 Subject: Big Temporary Networks In-Reply-To: <858752.24692.1347630002607.JavaMail.root@benjamin.baylink.com> References: <20120914073542.GT24232@besserwisser.org> <858752.24692.1347630002607.JavaMail.root@benjamin.baylink.com> Message-ID: <20120915072340.GX24232@besserwisser.org> Subject: Re: Big Temporary Networks Date: Fri, Sep 14, 2012 at 09:40:02AM -0400 Quoting Jay Ashworth (jra at baylink.com): > ----- Original Message ----- > > From: "M?ns Nilsson" > > > 12:20:33AM -0700 Quoting Octavio Alvarez (alvarezp at alvarezp.ods.org): > > > > > I'd have expected someone to have QoS mentioned already, mainly to put > > > FTP and P2P traffic on the least important queues and don't hog up the > > > net. > > > > As long as there is no multicast entering the wlan this is best solved > > by getting more bandwidth. > > Well, we'll be on the *sending* end of the Hugo's, but... ;-) > > It would still be nice to multicast them inside our network (and out to > whomever wants to watch), but what the heck's the consumer-level client side > of multicast video streaming look like these days? IIRC a number of IETF meetings were badly maimed in the wireless side until people remembered that the WLAN was no place for multicast video. VLC does mcast really nice. We're testing it for replacing antenna distribution systems and DVB-T receivers at work. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Mr and Mrs PED, can I borrow 26.7% of the RAYON TEXTILE production of the INDONESIAN archipelago? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From will at harg.net Sat Sep 15 04:31:24 2012 From: will at harg.net (Will Hargrave) Date: Sat, 15 Sep 2012 10:31:24 +0100 Subject: Big Temporary Networks In-Reply-To: <26628B8A-5EE9-4B6F-939E-12B81B1BAC4D@gizmopartners.com> References: <37133210-d431-4d7e-b829-9ef4af151579@mail.pelican.org> <26628B8A-5EE9-4B6F-939E-12B81B1BAC4D@gizmopartners.com> Message-ID: <6C7D029E-1A86-4028-859E-01706C715DCE@harg.net> On 13 Sep 2012, at 17:32, Tim Franklin wrote: >> You'll need a beefy NAT box. Linux with Xeon CPU and 4GB RAM minimum. > Or not. The CCC presentation is showing *real* Internet for everyone, unless I'm very much mistaken? Absolutely. NAT is too fragile/expensive/non-performant for these setups. CGN boxes are too new to be economically borrowed/rented, maybe one day it will be possible, but for now we can still get the address space required (Timespan issues notwithstanding) On 13 Sep 2012, at 21:03, Chris Boyd wrote: > If you know of an ISP in Central Texas that can deploy a 10Mbit plus connection along with a /22 of v4 address space for a 1 day event, please let me know. TWCable has been pretty easy to work with for special events, but I'd be really surprised to see them be able to do that. I suggest either getting a L2 circuit or else IPIP/GRE tunnel to somewhere with a functioning internet market. It is far preferable to tunnel than it is to have session state in the network. I've been part of the team deploying networking to various leafy parts of the Netherlands (e.g. HAR2009), ex-soviet airbases (CCC Camp), a park in Milton Keynes, UK (EMF2012). With some thought and creative planning it is possible to bring in a useful uplink in the 300M-10G+ range. [I'm not sure I remember those DS3s and OC3s that other posters are talking about, something these days used only in developing countries i thought ;-)] As a network engineer, these events are a great way to meet people with different experience, talk to eager young folk, do things in a different way and generally have a reset on your professional life. You might even get some sun too :-) From mohta at necom830.hpcl.titech.ac.jp Sat Sep 15 05:37:51 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 15 Sep 2012 19:37:51 +0900 Subject: Big Temporary Networks In-Reply-To: <20120914124607.GU24232@besserwisser.org> References: <6C9C6373-744E-4CF9-B03A-CAB01AD5C37F@gmail.com> <18374244.24538.1347551040232.JavaMail.root@benjamin.baylink.com> <218AB54691EB49439829EFD136F473CF27CD8375@exchange2k10.corp.power1.com> <20120913203229.GR24232@besserwisser.org> <50532169.7070909@necom830.hpcl.titech.ac.jp> <20120914124607.GU24232@besserwisser.org> Message-ID: <50545A7F.6060809@necom830.hpcl.titech.ac.jp> Mans Nilsson wrote: >>> Do not NAT. When all those people want to do social networking to the same >>> furry BBS while also frequenting three social app sites simultaneously >>> you are going to get Issues if you NAT. So don't. > I am not suggesting that. I'm just trying to point out that there > might be a bunch of assumptions that aren't as true anymore when a > lot of client connections share both source and destination address, > and perhaps also destination port. If this happens simultaneously when > a large amount of other tcp connections are NATed through the same box, > resource starvation will occur. Then, an advise better than yours is Chris's: : with small budgets. : You'll need a beefy NAT box. Linux with Xeon CPU and 4GB RAM : minimum. Run your DNS resolver and DHCP here, unless you have : hardware to spare. : Bandwidth. Lots of Bandwidth. posted before yours. > If public address space is available, > it is better to use that. It depends on budgets and other factors. > Also, no NAT means there will be no session > timers for things like long lived low bandwidth tcp sessions. Assuming no NAT firewalls without very large connection tables, not necessarily. Masataka Ohta From mysidia at gmail.com Sat Sep 15 13:11:54 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 15 Sep 2012 13:11:54 -0500 Subject: Big Temporary Networks In-Reply-To: <50545A7F.6060809@necom830.hpcl.titech.ac.jp> References: <6C9C6373-744E-4CF9-B03A-CAB01AD5C37F@gmail.com> <18374244.24538.1347551040232.JavaMail.root@benjamin.baylink.com> <218AB54691EB49439829EFD136F473CF27CD8375@exchange2k10.corp.power1.com> <20120913203229.GR24232@besserwisser.org> <50532169.7070909@necom830.hpcl.titech.ac.jp> <20120914124607.GU24232@besserwisser.org> <50545A7F.6060809@necom830.hpcl.titech.ac.jp> Message-ID: On 9/15/12, Masataka Ohta wrote: > Mans Nilsson wrote: >> I am not suggesting that. I'm just trying to point out that there >> might be a bunch of assumptions that aren't as true anymore when a >> lot of client connections share both source and destination address, >> and perhaps also destination port. If this happens simultaneously when >> a large amount of other tcp connections are NATed through the same box, >> resource starvation will occur. Assumptions that are already broken in Enterprise networks where 100+ users may share an IP What you can use is an edge device with a large NAT table, 30000 entries at least; setup a policy that limits each private IP address to 50 simultaneous TCP connections, to protect NAT device against malware-infected laptops, You might also use a wireless AP and Ethernet switches with PVLAN (or protected port bridging) and DHCP snooping functionality, then configure to restrict attached devices from sending or receiving any kind of IP or Ethernet broadcast traffic with other hosts on the LAN, And ensure the NAT/Firewall device will not route traffic from the Inside interface back to the Inside interface, so the NAT device and DHCP server are the only units that attached nodes may communicate with. Use a short NAT timeout period for UDP (30 seconds), so there is a certain number of users that your NAT device can service, depending on its CPU power and NAT table size. You can calculate an upper bound for required NAT table capacity, based on number of users, and number of allowed connections per user. Then take your total number of users, Divide by say 20, and build a NAT pool with that many public IP addresses, For example: one /24 of public IP addresses per 5000 users. to accomplish on average 20 users per public IP, providing you pick a NAT/Firewall device balances internal private to public IP usage fairly evenly. -- -JH From jra at baylink.com Sat Sep 15 20:18:19 2012 From: jra at baylink.com (Jay Ashworth) Date: Sat, 15 Sep 2012 21:18:19 -0400 (EDT) Subject: Big Temporary Networks In-Reply-To: <20120915072340.GX24232@besserwisser.org> Message-ID: <29035924.25034.1347758299003.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "M?ns Nilsson" > > It would still be nice to multicast them inside our network (and out > > to whomever wants to watch), but what the heck's the consumer-level > > client side of multicast video streaming look like these days? > > IIRC a number of IETF meetings were badly maimed in the wireless > side until people remembered that the WLAN was no place for multicast > video. VLC does mcast really nice. We're testing it for replacing > antenna distribution systems and DVB-T receivers at work. Then you want to know that the HD HomeRun people, Silicon Dust, have versions of their tuners that will generate multicast, I would suspect. You're saying that *receiving* multicast streams over WLAN works poorly? Can you expand on that? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From bill at herrin.us Sat Sep 15 20:52:47 2012 From: bill at herrin.us (William Herrin) Date: Sat, 15 Sep 2012 21:52:47 -0400 Subject: Big Temporary Networks In-Reply-To: <29035924.25034.1347758299003.JavaMail.root@benjamin.baylink.com> References: <20120915072340.GX24232@besserwisser.org> <29035924.25034.1347758299003.JavaMail.root@benjamin.baylink.com> Message-ID: On Sat, Sep 15, 2012 at 9:18 PM, Jay Ashworth wrote: > You're saying that *receiving* multicast streams over WLAN works poorly? I don't have any experience with it, but here's what Google told me: http://www.wireless-nets.com/resources/tutorials/802.11_multicasting.html "When any single wireless client associated with an access point has 802.11 power-save mode enabled, the access point buffers all multicast frames and sends them only after the next DTIM (Delivery Traffic Indication Message) beacon, which may be every one, two, or three beacons (referred to as the ?DTIM interval?). [...] default 100 millisecond beacon interval" http://www.wi-fiplanet.com/tutorials/article.php/3433451 "all it takes is one wireless client using 802.11 power saving to cause the access point to buffer multicast frames for all clients, and you may not be able to control whether or not users switch on power save mode." Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jra at baylink.com Sat Sep 15 20:55:41 2012 From: jra at baylink.com (Jay Ashworth) Date: Sat, 15 Sep 2012 21:55:41 -0400 (EDT) Subject: Big Temporary Networks In-Reply-To: Message-ID: <27907269.25160.1347760541234.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "William Herrin" > On Sat, Sep 15, 2012 at 9:18 PM, Jay Ashworth wrote: > > You're saying that *receiving* multicast streams over WLAN works > > poorly? > > I don't have any experience with it, but here's what Google told me: > > http://www.wireless-nets.com/resources/tutorials/802.11_multicasting.html > > "When any single wireless client associated with an access point has > 802.11 power-save mode enabled, the access point buffers all multicast > frames and sends them only after the next DTIM (Delivery Traffic > Indication Message) beacon, which may be every one, two, or three > beacons (referred to as the ?DTIM interval?). [...] default 100 > millisecond beacon interval" Thanks for doing my googling for me, Bill. :-) I'll do some more; I would sort've expect that might be something the firmware in enterprise-class APs would handle better (where by better, I mean "not permitting one client to manhandle the entire network" :-). Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From mohta at necom830.hpcl.titech.ac.jp Sat Sep 15 21:42:40 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sun, 16 Sep 2012 11:42:40 +0900 Subject: Big Temporary Networks In-Reply-To: <29035924.25034.1347758299003.JavaMail.root@benjamin.baylink.com> References: <29035924.25034.1347758299003.JavaMail.root@benjamin.baylink.com> Message-ID: <50553CA0.3080300@necom830.hpcl.titech.ac.jp> Jay Ashworth wrote: > You're saying that *receiving* multicast streams over WLAN works poorly? Multicast/broadcast over congested WLAN works poorly, because there can be no ACK. That is, multicast/broadcast packets lost by collisions are never sent again. Masataka Ohta From mansaxel at besserwisser.org Sun Sep 16 07:19:28 2012 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Sun, 16 Sep 2012 14:19:28 +0200 Subject: Big Temporary Networks In-Reply-To: References: <6C9C6373-744E-4CF9-B03A-CAB01AD5C37F@gmail.com> <18374244.24538.1347551040232.JavaMail.root@benjamin.baylink.com> <218AB54691EB49439829EFD136F473CF27CD8375@exchange2k10.corp.power1.com> <20120913203229.GR24232@besserwisser.org> <50532169.7070909@necom830.hpcl.titech.ac.jp> <20120914124607.GU24232@besserwisser.org> <50545A7F.6060809@necom830.hpcl.titech.ac.jp> Message-ID: <20120916121928.GB24232@besserwisser.org> Subject: Re: Big Temporary Networks Date: Sat, Sep 15, 2012 at 01:11:54PM -0500 Quoting Jimmy Hess (mysidia at gmail.com): > On 9/15/12, Masataka Ohta wrote: > > Mans Nilsson wrote: > > >> I am not suggesting that. I'm just trying to point out that there > >> might be a bunch of assumptions that aren't as true anymore when a > >> lot of client connections share both source and destination address, > >> and perhaps also destination port. If this happens simultaneously when > >> a large amount of other tcp connections are NATed through the same box, > >> resource starvation will occur. > > Assumptions that are already broken in Enterprise networks where 100+ > users may share an IP Warum einfach, wenn es auch kompliziert geht? -- 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 ... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From mansaxel at besserwisser.org Sun Sep 16 07:30:45 2012 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Sun, 16 Sep 2012 14:30:45 +0200 Subject: Big Temporary Networks In-Reply-To: References: <20120914073542.GT24232@besserwisser.org> <858752.24692.1347630002607.JavaMail.root@benjamin.baylink.com> <20120915072340.GX24232@besserwisser.org> Message-ID: <20120916123045.GC24232@besserwisser.org> Subject: Re: Big Temporary Networks Date: Sat, Sep 15, 2012 at 10:15:26PM -0400 Quoting Eric Adler (eaptech at gmail.com): > Are you working with locally originated video or video that originates as > DVB-T? > > I'm looking at a similar project to replace NTSC distribution around the > facility where I work (locally originated, DVB-S[2] receive, ATSC receive, > and even NTSC receive) with an IP multicast system. > > I'd be interested in discussing options, caveats, and nuance further with > all of those interested but I fear we're drifting off-topic for this list > (and this thread). The only real problem is rights. The tech is easy. Get a last years PC, install as much tuners as you need, and install the right software. First google hit, more or less: http://wiki.arts.usyd.edu.au/meta/index.php/Building_a_DVB_streaming_server -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Should I start with the time I SWITCHED personalities with a BEATNIK hair stylist or my failure to refer five TEENAGERS to a good OCULIST? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From jra at baylink.com Sun Sep 16 11:22:57 2012 From: jra at baylink.com (Jay Ashworth) Date: Sun, 16 Sep 2012 12:22:57 -0400 (EDT) Subject: Big Temporary Networks In-Reply-To: <50553CA0.3080300@necom830.hpcl.titech.ac.jp> Message-ID: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Masataka Ohta" > Jay Ashworth wrote: > > You're saying that *receiving* multicast streams over WLAN works > > poorly? > > Multicast/broadcast over congested WLAN works poorly, because > there can be no ACK. > > That is, multicast/broadcast packets lost by collisions are > never sent again. Well, yes, but that wasn't what Bill was talking about. He was talking about AP's being "nice" to associated clients who are in powersave mode, at the expensive of all the other connected clients, by buffering multicast packets until one or more DTIM frames are sent. We expect live streams to drop a packet here and there; that's what buffering is for... and why television proper still exists. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Sun Sep 16 11:24:19 2012 From: jra at baylink.com (Jay Ashworth) Date: Sun, 16 Sep 2012 12:24:19 -0400 (EDT) Subject: Big Temporary Networks In-Reply-To: <505554EF.6050704@lahai.com> Message-ID: <14744137.25172.1347812659174.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Gaurab Raj Upadhaya" > > So you're *REALLY* motivated on this "reduce the coverage" thing, > > then. > > you could say yes :), reduce the coverage per-AP. Most APs I have seen > will start failing with about ~100 associations and not to forget > about the max GE uplink they have. that's about 40-50 people at most > (being optimist). Really? 100 associations? On enterprise/carrier grade gear? Seriously? > >> g) we have a /32 and /20 (v6 and v4 respectively) address space > >> assigned by APNIC for this and other events in Asia (including > >> the APNIC meeting itself) so we use that. We used to have a v4 > >> /16 though before runout. > > > > I'm talking to someone from the Interop team; they have a dedicated > > /8. > > They gave that 45/8 back and kept 2 x /16 for themselves. I did not know that. Good on 'em. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From joelja at bogus.com Sun Sep 16 11:42:27 2012 From: joelja at bogus.com (joel jaeggli) Date: Sun, 16 Sep 2012 09:42:27 -0700 Subject: Big Temporary Networks In-Reply-To: <14744137.25172.1347812659174.JavaMail.root@benjamin.baylink.com> References: <14744137.25172.1347812659174.JavaMail.root@benjamin.baylink.com> Message-ID: <50560173.5030309@bogus.com> On 9/16/12 9:24 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Gaurab Raj Upadhaya" >>> So you're *REALLY* motivated on this "reduce the coverage" thing, >>> then. >> you could say yes :), reduce the coverage per-AP. Most APs I have seen >> will start failing with about ~100 associations and not to forget >> about the max GE uplink they have. that's about 40-50 people at most >> (being optimist). > Really? 100 associations? On enterprise/carrier grade gear? > > Seriously? We tend to engineer for a maximum of around 50 associations per radio (not AP). beyond that performance really starts to suck which can be measured along a multitude of dimensions. The most visible one to the client(s) being latency due to loss and subsequent retransmission. Reduction in coverage is done on a couple of dimensions. that ap with the 3-5dBi gain dipoles probably shouldn't be 100mW. but the noise floor is in a different place when the room is full of clients so it can't be to low either. Dropping the low speed rates backward compatibility with 802.11b and setting the multicast rate to something higher will force clients in marginal coverage situations to roam more quickly, hog the air less and allow for higher throughput. >>>> g) we have a /32 and /20 (v6 and v4 respectively) address space >>>> assigned by APNIC for this and other events in Asia (including >>>> the APNIC meeting itself) so we use that. We used to have a v4 >>>> /16 though before runout. >>> I'm talking to someone from the Interop team; they have a dedicated >>> /8. >> They gave that 45/8 back and kept 2 x /16 for themselves. > I did not know that. Good on 'em. > > Cheers, > -- jra From sethm at rollernet.us Sun Sep 16 11:55:00 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 16 Sep 2012 09:55:00 -0700 Subject: IPv6 Ignorance Message-ID: <50560464.8020906@rollernet.us> I came across these threads today; the blind ignorance towards IPv6 from some of the posters is kind of shocking. It's also pretty disappointing if these are the people providing internet access to end users. We focus our worries on the big guys like AT&T going IPv6 (which I'm sure but they're slow), but these small operators are a much bigger problem. http://forum.ubnt.com/showthread.php?p=355722 http://forum.ubnt.com/showthread.php?t=53779 ~Seth From john.yocum at fluidhosting.com Sun Sep 16 12:06:43 2012 From: john.yocum at fluidhosting.com (John T. Yocum) Date: Sun, 16 Sep 2012 10:06:43 -0700 Subject: IPv6 Ignorance In-Reply-To: <50560464.8020906@rollernet.us> References: <50560464.8020906@rollernet.us> Message-ID: <50560723.2020802@fluidhosting.com> On 9/16/2012 9:55 AM, Seth Mattinen wrote: > I came across these threads today; the blind ignorance towards IPv6 from > some of the posters is kind of shocking. It's also pretty disappointing > if these are the people providing internet access to end users. We focus > our worries on the big guys like AT&T going IPv6 (which I'm sure but > they're slow), but these small operators are a much bigger problem. > > http://forum.ubnt.com/showthread.php?p=355722 > > http://forum.ubnt.com/showthread.php?t=53779 > > ~Seth > Wow... my brain hurts after reading that. The saddest part is, there are folks with IPv6 allocations that simply refuse to implement dual stack. --John From sethm at rollernet.us Sun Sep 16 12:09:37 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 16 Sep 2012 10:09:37 -0700 Subject: IPv6 Ignorance In-Reply-To: <50560723.2020802@fluidhosting.com> References: <50560464.8020906@rollernet.us> <50560723.2020802@fluidhosting.com> Message-ID: <505607D1.8090808@rollernet.us> On 9/16/12 10:06 AM, John T. Yocum wrote: > > > On 9/16/2012 9:55 AM, Seth Mattinen wrote: >> I came across these threads today; the blind ignorance towards IPv6 from >> some of the posters is kind of shocking. It's also pretty disappointing >> if these are the people providing internet access to end users. We focus >> our worries on the big guys like AT&T going IPv6 (which I'm sure but >> they're slow), but these small operators are a much bigger problem. >> >> http://forum.ubnt.com/showthread.php?p=355722 >> >> http://forum.ubnt.com/showthread.php?t=53779 >> >> ~Seth >> > > > Wow... my brain hurts after reading that. The saddest part is, there are > folks with IPv6 allocations that simply refuse to implement dual stack. > I think Owen's head may explode if he reads it. ~Seth From streiner at cluebyfour.org Sun Sep 16 12:11:34 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sun, 16 Sep 2012 13:11:34 -0400 (EDT) Subject: IPv6 Ignorance In-Reply-To: <50560723.2020802@fluidhosting.com> References: <50560464.8020906@rollernet.us> <50560723.2020802@fluidhosting.com> Message-ID: On Sun, 16 Sep 2012, John T. Yocum wrote: > Wow... my brain hurts after reading that. The saddest part is, there are > folks with IPv6 allocations that simply refuse to implement dual stack. Agreed. I'm dual-stacked at work, and things work just fine. The only gripe I heard when dual-stack was turned on was that some sites were a bit slower to respond, because some OSs were trying to resolve DNS requests serially. Beyond that, smooth sailing... jms From mitch at illuminati.org Sun Sep 16 12:12:15 2012 From: mitch at illuminati.org (John Mitchell) Date: Sun, 16 Sep 2012 18:12:15 +0100 Subject: IPv6 Ignorance In-Reply-To: <50560464.8020906@rollernet.us> References: <50560464.8020906@rollernet.us> Message-ID: <5056086F.1000105@illuminati.org> There are some pretty impressive quotes there to take away .. >"We are totally convinced that the factors that made IPv4 run out of addresses will remanifest >themselves once again and likely sooner than a lot of us might expect given the "Reccomendations" for >"Best Practice" deployment." If I am understanding this quote correctly the author is worried IPv6 will run out of addresses so won't make the switch... Granted only 1/8th of the IPv6 space has been allocated for internet use but that number is still so mind-boggling _huge_.. But what does worry me is a lot of peoples inability to future proof themselves, it seems a lot of people would rather wait until its too late or things are falling apart and react rather than protectively getting a migration or even support package in place in-case v4 just "stops working". And by "stops working" I mean some big service provider decides to shoot itself in the foot and just switch off IPv4 support for their services, not likely to happen any-time in the near future but still a possibility. -- mitch On 16/09/12 17:55, Seth Mattinen wrote: > I came across these threads today; the blind ignorance towards IPv6 from > some of the posters is kind of shocking. It's also pretty disappointing > if these are the people providing internet access to end users. We focus > our worries on the big guys like AT&T going IPv6 (which I'm sure but > they're slow), but these small operators are a much bigger problem. > > http://forum.ubnt.com/showthread.php?p=355722 > > http://forum.ubnt.com/showthread.php?t=53779 > > ~Seth From otis at ocosa.com Sun Sep 16 12:28:02 2012 From: otis at ocosa.com (Otis L. Surratt, Jr.) Date: Sun, 16 Sep 2012 12:28:02 -0500 Subject: IPv6 Ignorance In-Reply-To: <50560464.8020906@rollernet.us> References: <50560464.8020906@rollernet.us> Message-ID: <5FE1FB6D43B8A647BBC821840C1AEA8B017DA8@ocsbs.ocosa.com> You will always have someone who doesn't understand. But every network operator should have a sense of responsibility to learn IPv6 and implement dual stacking. To be honest, in 2004/2005 I decided not to dive into IPv6 heavily but everyone has a "wake up" call. All we can do is keep stressing the urgency to implement IPv6 period. Not all UBNT users have a want to implement IPv4. Considering, that its easy, simple, affordable wireless gear. The result, pretty much anyone wanting to start a WISP and make money with none to little network experience, let alone the responsibility period to implement BCPs or follow RFCs. Further, most o f the users that use UBNT gear, IMHO mostly have space from their upstreams and not PI. Although, is probably a small point but it still adds to the IPv4 table end of day. I'd have to say there are moderators and users pushing IPv6 on the forum. It was a good move for UBNT on the latest release of firmware. So, I guess that's the "wake up" call those operators using UBNT (not IPv6 already) needed. But then again you will have those that say "if it ain't broke, don't fix it". Otis -----Original Message----- From: Seth Mattinen [mailto:sethm at rollernet.us] Sent: Sunday, September 16, 2012 11:55 AM To: nanog at nanog.org Subject: IPv6 Ignorance I came across these threads today; the blind ignorance towards IPv6 from some of the posters is kind of shocking. It's also pretty disappointing if these are the people providing internet access to end users. We focus our worries on the big guys like AT&T going IPv6 (which I'm sure but they're slow), but these small operators are a much bigger problem. http://forum.ubnt.com/showthread.php?p=355722 http://forum.ubnt.com/showthread.php?t=53779 ~Seth From sethm at rollernet.us Sun Sep 16 12:43:29 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 16 Sep 2012 10:43:29 -0700 Subject: IPv6 Ignorance In-Reply-To: <50560464.8020906@rollernet.us> References: <50560464.8020906@rollernet.us> Message-ID: <50560FC1.606@rollernet.us> On 9/16/12 9:55 AM, Seth Mattinen wrote: > I came across these threads today; the blind ignorance towards IPv6 from > some of the posters is kind of shocking. It's also pretty disappointing > if these are the people providing internet access to end users. We focus > our worries on the big guys like AT&T going IPv6 (which I'm sure but > they're slow), but these small operators are a much bigger problem. > > http://forum.ubnt.com/showthread.php?p=355722 > > http://forum.ubnt.com/showthread.php?t=53779 > It was brought to my attention that the second link isn't open to the public, sorry about that, I forgot to check them in a separate browser. The attitudes are the same though. ~Seth From mohta at necom830.hpcl.titech.ac.jp Sun Sep 16 12:49:10 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 17 Sep 2012 02:49:10 +0900 Subject: IPv6 Ignorance In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8B017DA8@ocsbs.ocosa.com> References: <50560464.8020906@rollernet.us> <5FE1FB6D43B8A647BBC821840C1AEA8B017DA8@ocsbs.ocosa.com> Message-ID: <50561116.7070405@necom830.hpcl.titech.ac.jp> We should support dual stack, as someone may stop supporting IPv4 in addition to IPv6, because dual stack costs so much. :-) Masataka Ohta From nick at foobar.org Sun Sep 16 13:26:05 2012 From: nick at foobar.org (Nick Hilliard) Date: Sun, 16 Sep 2012 19:26:05 +0100 Subject: Big Temporary Networks In-Reply-To: <50531730.1040103@prt.org> References: <6C9C6373-744E-4CF9-B03A-CAB01AD5C37F@gmail.com> <18374244.24538.1347551040232.JavaMail.root@benjamin.baylink.com> <218AB54691EB49439829EFD136F473CF27CD8375@exchange2k10.corp.power1.com> <20120913203229.GR24232@besserwisser.org> <50530417.10506@foobar.org> <50530DB4.4090702@redpill-linpro.com> <505312AD.9050003@foobar.org> <50531730.1040103@prt.org> Message-ID: <505619BD.5040007@foobar.org> On 14/09/2012 12:38, Paul Thornton wrote: > Veering slightly off-topic for NANOG, but is this worth taking onto the > address policy mailing list ahead of RIPE65 to ensure people who aren't in > the WG session are aware of the issue - and can therefore support (or > question) any proposed changes? I just posted to ap-wg about this: > http://www.ripe.net/ripe/mail/archives/address-policy-wg/2012-September/007183.html Nick From faisal at snappydsl.net Sun Sep 16 13:29:22 2012 From: faisal at snappydsl.net (Faisal Imtiaz) Date: Sun, 16 Sep 2012 14:29:22 -0400 Subject: IPv6 Ignorance In-Reply-To: <50560FC1.606@rollernet.us> References: <50560464.8020906@rollernet.us> <50560FC1.606@rollernet.us> Message-ID: <50561A82.2040300@snappydsl.net> Let me shed some light here..... (Being familiar with both communities... Nanog and WISP's ) WISP's are a very special breed of folks. There are a few common attributes that one has to recognize about them. 1. Most WISP's are not Technical Folks. (Most of them are Farmers or from other totally non-technical fields). 2. Most of them became operators not because they wanted to or it made business sense. but simply because there was not Service available in that area. 3. They are very hardworking, innovative group, but at the same time they are also a bit on the 'eccentric' side when comes to technology, and understanding technology. 4. Most of them have outsourced folks managing their networks. (these folks are very qualified and familiar with networking) So, in contrast, while NANOG community is full of folks who develop / write RFC's for Global networks, WISP community is mostly Rural folks who were forced to 'piece a network' together because no-one would serve them.... Don't be alarmed by the discussion on UBNT list or any other WISP list.....Most WISP's are typically very small network operators (sub 500 subscribers, there are some large ones too but their opinions and technical understanding is very different.) and tend to setup their network the 'Easy way'.... You will find them to be about the very last folks to adapt IPv6...(to make my case and point .... A lot of them are still running Bridge Networks, and just starting to convert to Routed Networks). They are not known for Leading Edge network operators with the exception of when it comes to 'Wireless Radios'. A lot of them are very comfortable with using Private IP's and NAT to provide service to their customers. Worry about them .... No need. Need for Education on IPv6 ... Absolutely Yes.... We all can use as much as we can get. And, we all are also hampered by IPv6 support / or lack of it, from the equipment mfg. that we are using in our networks. Hope this makes sense. Faisal Imtiaz Snappy Internet & Telecom On 9/16/2012 1:43 PM, Seth Mattinen wrote: > On 9/16/12 9:55 AM, Seth Mattinen wrote: >> I came across these threads today; the blind ignorance towards IPv6 from >> some of the posters is kind of shocking. It's also pretty disappointing >> if these are the people providing internet access to end users. We focus >> our worries on the big guys like AT&T going IPv6 (which I'm sure but >> they're slow), but these small operators are a much bigger problem. >> >> http://forum.ubnt.com/showthread.php?p=355722 >> >> http://forum.ubnt.com/showthread.php?t=53779 >> > It was brought to my attention that the second link isn't open to the > public, sorry about that, I forgot to check them in a separate browser. > The attitudes are the same though. > > ~Seth > > From mohta at necom830.hpcl.titech.ac.jp Sun Sep 16 13:30:53 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 17 Sep 2012 03:30:53 +0900 Subject: Big Temporary Networks In-Reply-To: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> References: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> Message-ID: <50561ADD.2040404@necom830.hpcl.titech.ac.jp> Jay Ashworth wrote: > Well, yes, but that wasn't what Bill was talking about. He was talking about > AP's being "nice" to associated clients who are in powersave mode, at the > expensive of all the other connected clients, by buffering multicast packets > until one or more DTIM frames are sent. I know. But, there are other reasons why multicast over WLAN behaves poorly. Thus, protocols heavily depending on broadcast/multicast, such as ND, will suffer. Masataka Ohta From lists at mtin.net Sun Sep 16 14:19:03 2012 From: lists at mtin.net (Justin Wilson) Date: Sun, 16 Sep 2012 15:19:03 -0400 Subject: IPv6 Ignorance In-Reply-To: <50561A82.2040300@snappydsl.net> Message-ID: Very good points. Having been in the WISP industry for more than 10 years now. I know WISPs who have thousands of customers and only 1 or 2 class C addresses. The need for public routable IP addresses is not that much of a concern for them. Plus, a good majority of WISP equipment does not support IPV6. Sure a WISP is technically an ISP but, like Faisal says, its a much different business. Justin -----Original Message----- From: Faisal Imtiaz Reply-To: Date: Sunday, September 16, 2012 2:29 PM To: Subject: Re: IPv6 Ignorance >Let me shed some light here..... (Being familiar with both >communities... Nanog and WISP's ) > >WISP's are a very special breed of folks. There are a few common >attributes that one has to recognize about them. >1. Most WISP's are not Technical Folks. (Most of them are Farmers or >from other totally non-technical fields). >2. Most of them became operators not because they wanted to or it made >business sense. but simply because there was not Service available in >that area. >3. They are very hardworking, innovative group, but at the same time >they are also a bit on the 'eccentric' side when comes to technology, >and understanding technology. >4. Most of them have outsourced folks managing their networks. (these >folks are very qualified and familiar with networking) > >So, in contrast, while NANOG community is full of folks who develop / >write RFC's for Global networks, WISP community is mostly Rural folks >who were forced to 'piece a network' together because no-one would serve >them.... > >Don't be alarmed by the discussion on UBNT list or any other WISP >list.....Most WISP's are typically very small network operators (sub 500 >subscribers, there are some large ones too but their opinions and >technical understanding is very different.) and tend to setup their >network the 'Easy way'.... You will find them to be about the very last >folks to adapt IPv6...(to make my case and point .... A lot of them are >still running Bridge Networks, and just starting to convert to Routed >Networks). They are not known for Leading Edge network operators with >the exception of when it comes to 'Wireless Radios'. > >A lot of them are very comfortable with using Private IP's and NAT to >provide service to their customers. > >Worry about them .... No need. >Need for Education on IPv6 ... Absolutely Yes.... We all can use as much >as we can get. >And, we all are also hampered by IPv6 support / or lack of it, from the >equipment mfg. that we are using in our networks. > >Hope this makes sense. > >Faisal Imtiaz >Snappy Internet & Telecom > >On 9/16/2012 1:43 PM, Seth Mattinen wrote: >> On 9/16/12 9:55 AM, Seth Mattinen wrote: >>> I came across these threads today; the blind ignorance towards IPv6 >>>from >>> some of the posters is kind of shocking. It's also pretty disappointing >>> if these are the people providing internet access to end users. We >>>focus >>> our worries on the big guys like AT&T going IPv6 (which I'm sure but >>> they're slow), but these small operators are a much bigger problem. >>> >>> http://forum.ubnt.com/showthread.php?p=355722 >>> >>> http://forum.ubnt.com/showthread.php?t=53779 >>> >> It was brought to my attention that the second link isn't open to the >> public, sorry about that, I forgot to check them in a separate browser. >> The attitudes are the same though. >> >> ~Seth >> >> > > > From nick at foobar.org Sun Sep 16 14:21:06 2012 From: nick at foobar.org (Nick Hilliard) Date: Sun, 16 Sep 2012 20:21:06 +0100 Subject: Big Temporary Networks In-Reply-To: <50561ADD.2040404@necom830.hpcl.titech.ac.jp> References: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> <50561ADD.2040404@necom830.hpcl.titech.ac.jp> Message-ID: <505626A2.1090700@foobar.org> On 16/09/2012 19:30, Masataka Ohta wrote: > Thus, protocols heavily depending on broadcast/multicast, such > as ND, will suffer. ok, you've trolled me enough to ask why ND is worse than ARP on a wavelan network - in your humble opinion? Nick From mysidia at gmail.com Sun Sep 16 14:57:57 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 16 Sep 2012 14:57:57 -0500 Subject: IPv6 Ignorance In-Reply-To: <5056086F.1000105@illuminati.org> References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> Message-ID: On 9/16/12, John Mitchell wrote: > If I am understanding this quote correctly the author is worried IPv6 > will run out of addresses so won't make the switch... Granted only 1/8th > of the IPv6 space has been allocated for internet use but that number is > still so mind-boggling _huge_.. I would suggest it's irrational thinking resulting from negative experience with IPv4. The rate of IPv6 exhaustion depends on how the resource is managed, and the method of resource management can change, if the rate of consumption is higher than expected. There is not a coherent credible mathematical argument for exhaustion risk of IPv6 that has been made, you would have to make assumptions about what resource management policy and demands will be now and in the future, and there are no published models of IPv6 consumption i've seen. Anyways, if it becomes a problem in the future, there would be plenty of time to create a new protocol, or using an existing protocol using NSAP addresses. Right now, IPV6 is the coherent option we've got. It's not reasonable to infer IPv6 suffers the same address shortage problem within 100 years, until there is a coherent model. We have not even heard about 48-bit MAC addresses being on the verge of exhaustion yet, obviously because there is no apparent danger for the forseeable future, and IPv6 has 64 bits available for network identification and 128 bits available for host identification..... -- -JH From johnl at iecc.com Sun Sep 16 16:40:16 2012 From: johnl at iecc.com (John Levine) Date: 16 Sep 2012 21:40:16 -0000 Subject: IPv6 Ignorance In-Reply-To: Message-ID: <20120916214016.7682.qmail@joyce.lan> >> If I am understanding this quote correctly the author is worried IPv6 >> will run out of addresses so won't make the switch... Granted only 1/8th >> of the IPv6 space has been allocated for internet use but that number is >> still so mind-boggling _huge_.. > >I would suggest it's irrational thinking resulting from negative >experience with IPv4. IPv6 has its problems, but running out of addresses is not one of them. For those of us worried about abuse management, the problem is the opposite, even the current tiny sliver of addresses is so huge that techniques from IPv4 to map who's doing what where don't scale. R's, John PS: For anyone planning to suggest that we just ignore the low 64 bits, that doesn't help. From mysidia at gmail.com Sun Sep 16 17:20:17 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 16 Sep 2012 17:20:17 -0500 Subject: IPv6 Ignorance In-Reply-To: <20120916214016.7682.qmail@joyce.lan> References: <20120916214016.7682.qmail@joyce.lan> Message-ID: On 9/16/12, John Levine wrote: > IPv6 has its problems, but running out of addresses is not one of them. > For those of us worried about abuse management, the problem is the > opposite, even the current tiny sliver of addresses is so huge that > techniques from IPv4 to map who's doing what where don't scale. Well, in IPv4... NAT broke it, because networks implementing 1:many NAT could no longer easily identify what host was responsible for abuse. What do you mean by suggesting IPv4 abuse management techniques to map whose doing what, where do not scale to IPv6's larger address space? There's no reason you can't provide accurate WHOIS information with the larger address space.. > R's, > John -- -JH From mohta at necom830.hpcl.titech.ac.jp Sun Sep 16 18:42:22 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 17 Sep 2012 08:42:22 +0900 Subject: Big Temporary Networks In-Reply-To: <505626A2.1090700@foobar.org> References: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> <50561ADD.2040404@necom830.hpcl.titech.ac.jp> <505626A2.1090700@foobar.org> Message-ID: <505663DE.7000309@necom830.hpcl.titech.ac.jp> Nick Hilliard wrote: >> Thus, protocols heavily depending on broadcast/multicast, such >> as ND, will suffer. > > ok, you've trolled me enough to ask why ND is worse than ARP on a wavelan > network - in your humble opinion? Because, with IPv4: 1) broadcast/multicast from a STA attacked to an AP is actually unicast to the AP and reliably received by the AP (and relayed unreliably to other STAs). That is, a broadcast ARP request from the STA to the AP is reliably received by the AP. 2) the AP knows MAC and IP addresses of STAs 3) ARP and DHCP replies are usually unicast ARP and DHCP usually work. For an unusual case of ARP for other STAs, collisions do increase initial latencies, but as refreshes are attempted several times, there will be no latter latencies. OTOH, IPv6 requires many multicast received by STAs: RA and NS for DAD, for example. Worse, minimum intervals of ND messages are often very large, which means a lot of delay occurs when a message is lost. Masataka Ohta From johnl at iecc.com Sun Sep 16 18:58:15 2012 From: johnl at iecc.com (John R. Levine) Date: 16 Sep 2012 19:58:15 -0400 Subject: IPv6 Ignorance In-Reply-To: References: <20120916214016.7682.qmail@joyce.lan> Message-ID: >> IPv6 has its problems, but running out of addresses is not one of them. >> For those of us worried about abuse management, the problem is the >> opposite, even the current tiny sliver of addresses is so huge that >> techniques from IPv4 to map who's doing what where don't scale. > > Well, in IPv4... NAT broke it, because networks implementing 1:many > NAT could no longer easily identify what host was responsible for abuse. I realize that's a problem in theory, in practice it's not because it's still rare to have interestingly different hosts behind a single NAT. > What do you mean by suggesting IPv4 abuse management techniques to map > whose doing what, where do not scale to IPv6's larger address space? Large networks keep separate reputation for every address in the IPv4 address space based on the traffic they send. You can't do that in IPv6, particularly since hostile bots can easily hop around within a /64, which is bad news if that /64 also has some legit hosts. 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 mysidia at gmail.com Sun Sep 16 19:24:35 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 16 Sep 2012 19:24:35 -0500 Subject: IPv6 Ignorance In-Reply-To: References: <20120916214016.7682.qmail@joyce.lan> Message-ID: On 9/16/12, John R. Levine wrote: > Large networks keep separate reputation for every address in the IPv4 > address space based on the traffic they send. You can't do that in IPv6, That's true, but not an intended system for identifying and reporting abuse, and the same idea occurs with IPv4 -- bots can just grab other IP addresses in the subnet, if there are not local protections in place to ensure a host cannot ARP an IP that is not assigned to it... So keep track of reputation of legitimate hosts instead of "non-legitimate" hosts. Maintain negative reputation at a /64 or shorter prefix level, and favorable reputation at a /128 level. If you have abuse detected on a /64, then treat the entire /64 as having a damaged reputation, except for the /128s on the /64 that have a prior positive reputation. The identical thing cannot be done with IPv6, but reputation systems are still possible. > 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 -- -JH From tmorizot at gmail.com Sun Sep 16 19:26:22 2012 From: tmorizot at gmail.com (Timothy Morizot) Date: Sun, 16 Sep 2012 19:26:22 -0500 Subject: IPv6 Ignorance In-Reply-To: References: <20120916214016.7682.qmail@joyce.lan> Message-ID: On Sep 16, 2012 6:58 PM, "John R. Levine" wrote: >>> >>> IPv6 has its problems, but running out of addresses is not one of them. >>> For those of us worried about abuse management, the problem is the >>> opposite, even the current tiny sliver of addresses is so huge that >>> techniques from IPv4 to map who's doing what where don't scale. >> >> >> Well, in IPv4... NAT broke it, because networks implementing 1:many >> NAT could no longer easily identify what host was responsible for abuse. > > > I realize that's a problem in theory, in practice it's not because it's still rare to have interestingly different hosts behind a single NAT. > > >> What do you mean by suggesting IPv4 abuse management techniques to map whose doing what, where do not scale to IPv6's larger address space? > > > Large networks keep separate reputation for every address in the IPv4 address space based on the traffic they send. You can't do that in IPv6, particularly since hostile bots can easily hop around within a /64, which is bad news if that /64 also has some legit hosts. Of course, as soon as CGN (or LSN or NAT444) is added to IPv4 the same problem exists in practice as well as theory. So old practices will have to be improved and replaced regardless. From masatoshi-e at is.naist.jp Sun Sep 16 20:03:29 2012 From: masatoshi-e at is.naist.jp (Masatoshi Enomoto) Date: Mon, 17 Sep 2012 10:03:29 +0900 Subject: Big Temporary Networks Message-ID: Masataka Ohta : >Nick Hilliard wrote: > >>> Thus, protocols heavily depending on broadcast/multicast, such >>> as ND, will suffer. >> >> ok, you've trolled me enough to ask why ND is worse than ARP on a wavelan >> network - in your humble opinion? > >Because, with IPv4: > > 1) broadcast/multicast from a STA attacked to an AP is > actually unicast to the AP and reliably received by the > AP (and relayed unreliably to other STAs). That is, a > broadcast ARP request from the STA to the AP is reliably > received by the AP. > > 2) the AP knows MAC and IP addresses of STAs > > 3) ARP and DHCP replies are usually unicast > >ARP and DHCP usually work. > >For an unusual case of ARP for other STAs, collisions do >increase initial latencies, but as refreshes are attempted >several times, there will be no latter latencies. > >OTOH, IPv6 requires many multicast received by STAs: RA and NS >for DAD, for example. > >Worse, minimum intervals of ND messages are often very large, >which means a lot of delay occurs when a message is lost. > > Masataka Ohta > From randy at psg.com Sun Sep 16 22:23:39 2012 From: randy at psg.com (Randy Bush) Date: Mon, 17 Sep 2012 12:23:39 +0900 Subject: IPv6 Ignorance In-Reply-To: <5056086F.1000105@illuminati.org> References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> Message-ID: [ yes, there are a lot of idiots out there. this is not new. but ] > "We are totally convinced that the factors that made IPv4 run out of > addresses will remanifest themselves once again and likely sooner than > a lot of us might expect given the "Reccomendations" for "Best > Practice" deployment." while i am not "totally convinced," i am certainly concerned. we are doing many of the same things all over again. remember when rip forced a homogenous, often classful, mask length in a network and we chewed through /24s? think /64 in ipv6, except it's half the bits not 1/4 of them. remember when we gave out As and Bs willy nilly? look at the giant swaths of v6 we give out today in the hopes that someone will deploy it. and don't bs me with how humongous the v6 address space is. we once though 32 bits was humongous. randy From mike at mtcc.com Sun Sep 16 22:55:49 2012 From: mike at mtcc.com (Michael Thomas) Date: Sun, 16 Sep 2012 20:55:49 -0700 Subject: IPv6 Ignorance In-Reply-To: References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> Message-ID: <50569F45.4030700@mtcc.com> On 09/16/2012 08:23 PM, Randy Bush wrote: > and don't bs me with how humongous the v6 address space is. we once though 32 bits was humongous. randy No we didn't . Mike From mysidia at gmail.com Sun Sep 16 23:12:26 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 16 Sep 2012 23:12:26 -0500 Subject: IPv6 Ignorance In-Reply-To: References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> Message-ID: On 9/16/12, Randy Bush wrote: > and don't bs me with how humongous the v6 address space is. we once > though 32 bits was humongous. [snip] When you consider that IPv6 is a 64-bit address space, that is 64 bits are for addressing subnetworks, the "/64 spend" for addressing hosts within a network as compared to v4 is 0%, not 50%. And there are twice as many IPv6 bits for addressing such /64s, as the entire IPv4 address space. 2^64 minus 2^32 is a humongous number indeed, and we know numerically just how humongous it is. The RIRs can collectively hand out 450 /32s a day or one /24 and one /25's worth a day, for the next 100 years, before a single /8 would be exhausted. And if IPv6 addressing resources last 100 years, I would say, that the objective was more than met. > randy -- -JH From swmike at swm.pp.se Sun Sep 16 23:22:21 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 17 Sep 2012 06:22:21 +0200 (CEST) Subject: IPv6 Ignorance In-Reply-To: References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> Message-ID: On Mon, 17 Sep 2012, Randy Bush wrote: > and don't bs me with how humongous the v6 address space is. we once > though 32 bits was humongous. Giving out a /48 to every person on earth uses approximately 2^33 networks, meaning we could cram it into a /15. So even if we have 10 /48s at home from different providers, we're still only using a small fraction of the first /3. If we get this wrong, we have several more /3s to get it right in. You already know this, and I can't really believe that people sat down in the 70ties and 80ties and said "there is never going to be more than 128 large corporations that need a /8 in IPv4" ? I start to get worried when people want to map 32 bits into IPv6 in several places, for instance telling all ISPs that they can have a /24 so that we can produce IPv4 mapped /56 to end customer, and make this space permanent. Temporary is fine, permanent is not. So I agree with you that there is still a risk that this is going to get screwed up, but I don't feel too gloomy yet. -- Mikael Abrahamsson email: swmike at swm.pp.se From randy at psg.com Sun Sep 16 23:26:10 2012 From: randy at psg.com (Randy Bush) Date: Mon, 17 Sep 2012 13:26:10 +0900 Subject: IPv6 Ignorance In-Reply-To: References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> Message-ID: > So I agree with you that there is still a risk that this is going to > get screwed up, but I don't feel too gloomy yet. yep. but we dis some wisp hacker for saying so. not cool. randy From swmike at swm.pp.se Mon Sep 17 00:41:16 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 17 Sep 2012 07:41:16 +0200 (CEST) Subject: IPv6 Ignorance In-Reply-To: References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> Message-ID: On Mon, 17 Sep 2012, Randy Bush wrote: >> So I agree with you that there is still a risk that this is going to >> get screwed up, but I don't feel too gloomy yet. > > yep. but we dis some wisp hacker for saying so. not cool. I have to admit I never read the forum text so I don't know exactly what was said. I don't see IPv6 getting screwed up the next 50-100 years (even humanity as it is can't be THAT wreckless?), so not adopting IPv6 and clinging to IPv4 for that reason is hard to understand from my point of view. We know IPv4 isn't enough for our needs, IPv6 might not be the "forever" solution, but it surely scales a lot better than IPv4. Otoh if I ran a low-cost operations on a shoestring budget I probably wouldn't be adopting IPv6 right now anyway, but for other reasons than IPv6 being "not scalable". -- Mikael Abrahamsson email: swmike at swm.pp.se From joelja at bogus.com Mon Sep 17 02:04:01 2012 From: joelja at bogus.com (joel jaeggli) Date: Mon, 17 Sep 2012 00:04:01 -0700 Subject: IPv6 Ignorance In-Reply-To: References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> Message-ID: <5056CB61.1070009@bogus.com> On 9/16/12 9:22 PM, Mikael Abrahamsson wrote: > On Mon, 17 Sep 2012, Randy Bush wrote: > >> and don't bs me with how humongous the v6 address space is. we once >> though 32 bits was humongous. > > Giving out a /48 to every person on earth uses approximately 2^33 > networks, meaning we could cram it into a /15. So even if we have 10 > /48s at home from different providers, we're still only using a small > fraction of the first /3. If we get this wrong, we have several more > /3s to get it right in. People aren't going to be the big consumers of address space relative to machines . > You already know this, and I can't really believe that people sat down > in the 70ties and 80ties and said "there is never going to be more > than 128 large corporations that need a /8 in IPv4" ? Emergent phenomena were not (and generaly are not) predicted. 32 bits was a lot more than 8 which was the previous go around.. > I start to get worried when people want to map 32 bits into IPv6 in > several places, for instance telling all ISPs that they can have a /24 > so that we can produce IPv4 mapped /56 to end customer, and make this > space permanent. Temporary is fine, permanent is not. or the application of semantic meaning to intermediate bits. and yeah the IPv6 bit field looks a lot smaller when you start carving off it in 24 bit or shorter chunks. > So I agree with you that there is still a risk that this is going to > get screwed up, but I don't feel too gloomy yet. > From tal at whatexit.org Mon Sep 17 07:04:31 2012 From: tal at whatexit.org (Tom Limoncelli) Date: Mon, 17 Sep 2012 08:04:31 -0400 Subject: IPv6 Ignorance In-Reply-To: <50560464.8020906@rollernet.us> References: <50560464.8020906@rollernet.us> Message-ID: My biggest fear is that statements like this will take on a life of their own: " I can dual stack, then I am not out of IPv4 addresses, and thus I have no need for IPv6. If I'm out of IPv4 then I need IPv6 and I can't dual stack." http://forum.ubnt.com/showthread.php?p=355722 Not true but it certainly sounds logical to the average person. What creates this impression is that there is no "deadline". The IPv4 -> Dual Stack -> pure IPv6 transition is complex so everyone focuses on "IPv4 -> Dual Stack" forgetting that it is a transition step. The final step seems so far off that people ignore it, and therefore the justification for the first step fades. (the remainder of this post is brainstorming; apply a grain of salt) There are ways to fix this. For example there was a deadline for when Dual Stack was to go away, a "Dual Stack 10 year count-down" would drive the point home. However nothing like this exists. This thread is making me think that I should change how I talk about IPv6 publicly. I need to put more emphasis on DS as being a temporary thing. It is in my mind but perhaps not in how I speak. The problem with picking a 10-year or 5-year "campaign" is that underestimating the amount of time makes us look like "the sky is falling" and too long gives people a reason to procrastinate. Then again... I believe what will make the biggest # of people adopt IPv6 will be if they see everyone else adopting it. That's why it is so important for IPv6 to be offered by default to all new ISP customers, that tech-savy enterprises need to deploy it, and so on. It is all about building a critical mass. Tom -- Speaking at MacTech Conference 2012. http://mactech.com/conference" http://EverythingSysadmin.com -- my blog http://www.TomOnTime.com -- my videos From mitch at illuminati.org Mon Sep 17 07:28:09 2012 From: mitch at illuminati.org (John Mitchell) Date: Mon, 17 Sep 2012 13:28:09 +0100 Subject: IPv6 Ignorance In-Reply-To: References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> Message-ID: <50571759.5050704@illuminati.org> I think people forget how humongous the v6 space is... Remember that the address space is 2^128 (or 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses) to put the in perspective (and a great sample that explained to me how large it was, you will still get 667 quadrillion address per square millimetre of the Earth?s Surface. There's a great article on the myths and debunks of the address space at http://rednectar.net/2012/05/24/just-how-many-ipv6-addresses-are-there-really/ one of the things it talks about is the /64 and /48 allocation. > Given that the first 3 bits of a public IPv6 address are always 001, giving /48 allocations to customers means that service providers will only have 2^(48-3) or 2^45 allocations of /48 to hand out > to a population of approximately 6 billion people. 2^33 is over 8 billion, so assuming a population of 2^33, there will be enough IPv6 /48 allocations to cater for 2^(45-33) or 2^12 or 4096 IPv6 > address allocations per user in the world." - Mitch - On 17/09/12 04:23, Randy Bush wrote: > [ yes, there are a lot of idiots out there. this is not new. but ] > >> "We are totally convinced that the factors that made IPv4 run out of >> addresses will remanifest themselves once again and likely sooner than >> a lot of us might expect given the "Reccomendations" for "Best >> Practice" deployment." > while i am not "totally convinced," i am certainly concerned. we are > doing many of the same things all over again. remember when rip forced > a homogenous, often classful, mask length in a network and we chewed > through /24s? think /64 in ipv6, except it's half the bits not 1/4 of > them. remember when we gave out As and Bs willy nilly? look at the > giant swaths of v6 we give out today in the hopes that someone will > deploy it. > > and don't bs me with how humongous the v6 address space is. we once > though 32 bits was humongous. > > randy From ops.lists at gmail.com Mon Sep 17 07:38:19 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 17 Sep 2012 18:08:19 +0530 Subject: IPv6 Ignorance In-Reply-To: <50571759.5050704@illuminati.org> References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <50571759.5050704@illuminati.org> Message-ID: With current use cases at least, yes. What do we know of what's going to happen in a decade or two? --srs (htc one x) On Sep 17, 2012 5:58 PM, "John Mitchell" wrote: > I think people forget how humongous the v6 space is... > > Remember that the address space is 2^128 (or 340,282,366,920,938,463,463,* > *374,607,431,768,211,456 addresses) to put the in perspective (and a > great sample that explained to me how large it was, you will still get 667 > quadrillion address per square millimetre of the Earth?s Surface. > > There's a great article on the myths and debunks of the address space at > http://rednectar.net/2012/05/**24/just-how-many-ipv6-** > addresses-are-there-really/one of the things it talks about is the /64 and /48 allocation. > > > > Given that the first 3 bits of a public IPv6 address are always 001, > giving /48 allocations to customers means that service providers will only > have 2^(48-3) or 2^45 allocations of /48 to hand out > to a population of > approximately 6 billion people. 2^33 is over 8 billion, so assuming a > population of 2^33, there will be enough IPv6 /48 allocations to cater for > 2^(45-33) or 2^12 or 4096 IPv6 > address allocations per user in the world." > > > - Mitch - > > > On 17/09/12 04:23, Randy Bush wrote: > >> [ yes, there are a lot of idiots out there. this is not new. but ] >> >> "We are totally convinced that the factors that made IPv4 run out of >>> addresses will remanifest themselves once again and likely sooner than >>> a lot of us might expect given the "Reccomendations" for "Best >>> Practice" deployment." >>> >> while i am not "totally convinced," i am certainly concerned. we are >> doing many of the same things all over again. remember when rip forced >> a homogenous, often classful, mask length in a network and we chewed >> through /24s? think /64 in ipv6, except it's half the bits not 1/4 of >> them. remember when we gave out As and Bs willy nilly? look at the >> giant swaths of v6 we give out today in the hopes that someone will >> deploy it. >> >> and don't bs me with how humongous the v6 address space is. we once >> though 32 bits was humongous. >> >> randy >> > > > From leschnik at gmail.com Mon Sep 17 08:08:28 2012 From: leschnik at gmail.com (Jason Leschnik) Date: Mon, 17 Sep 2012 23:08:28 +1000 Subject: IPv6 Ignorance In-Reply-To: References: <50560464.8020906@rollernet.us> Message-ID: Has said forum guy never heard of a phased implementation? Or would he rather a "big bang" cut over, i'm sure that will work swell. The best way to summarise the feeling for IPv6 was expressed in the Packet Pushers Podcast and that is Network Administrators and System Administrators have forgotten what it means to run a multiple stack Network. I also think many people are seeing IPv6 as a unnecessary evil due to the way it has come around and that comes back to the whole "your doomed theory" and "we are only upgrading because there is a depletion", This comes back to a lack of understanding and lack of interest in change. I cannot remember where i heard it, but someone said that it will take a killer IPv6 application that cannot occur on v4 to get people to jump. I'm sure if Facebook/Google decided they were sick of v4 for a week you would see I.T. departments agenda change quite rapidly (obviously this isn't sustainable) Education seems to be the key here... Rusty gears is the problem, people haven't had to worry about addressing for such a long time now. Feel kinda sorry for the guys who have to readdress IPv6 though *mwaha* On Mon, Sep 17, 2012 at 10:04 PM, Tom Limoncelli wrote: > My biggest fear is that statements like this will take on a life of their > own: > > " I can dual stack, then I am not out of IPv4 addresses, and thus I > have no need for IPv6. If I'm out of IPv4 then I need IPv6 and I can't > dual stack." http://forum.ubnt.com/showthread.php?p=355722 > > Not true but it certainly sounds logical to the average person. > > What creates this impression is that there is no "deadline". The IPv4 > -> Dual Stack -> pure IPv6 transition is complex so everyone focuses > on "IPv4 -> Dual Stack" forgetting that it is a transition step. The > final step seems so far off that people ignore it, and therefore the > justification for the first step fades. > > (the remainder of this post is brainstorming; apply a grain of salt) > > There are ways to fix this. For example there was a deadline for when > Dual Stack was to go away, a "Dual Stack 10 year count-down" would > drive the point home. However nothing like this exists. > > This thread is making me think that I should change how I talk about > IPv6 publicly. I need to put more emphasis on DS as being a temporary > thing. It is in my mind but perhaps not in how I speak. > > The problem with picking a 10-year or 5-year "campaign" is that > underestimating the amount of time makes us look like "the sky is > falling" and too long gives people a reason to procrastinate. > > Then again... I believe what will make the biggest # of people adopt > IPv6 will be if they see everyone else adopting it. That's why it is > so important for IPv6 to be offered by default to all new ISP > customers, that tech-savy enterprises need to deploy it, and so on. > It is all about building a critical mass. > > Tom > > -- > Speaking at MacTech Conference 2012. http://mactech.com/conference" > http://EverythingSysadmin.com -- my blog > http://www.TomOnTime.com -- my videos > > -- Regards, Jason Leschnik. [m] 0432 35 4224 [w@] jason dot leschnik ansto dot gov dot au [U@] jml974 at uow.edu.au From takashi at cpqd.com.br Mon Sep 17 08:23:43 2012 From: takashi at cpqd.com.br (Takashi Tome) Date: Mon, 17 Sep 2012 10:23:43 -0300 Subject: GoDaddy down again? Message-ID: Hi All, Does anyone knows whether GoDaddy is having problems again? (I'm not able to reach some sites). Thanks Takashi Tome From bortzmeyer at nic.fr Mon Sep 17 08:28:01 2012 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 17 Sep 2012 15:28:01 +0200 Subject: GoDaddy down again? In-Reply-To: References: Message-ID: <20120917132801.GA22653@nic.fr> On Mon, Sep 17, 2012 at 10:23:43AM -0300, Takashi Tome wrote a message of 8 lines which said: > Does anyone knows whether GoDaddy is having problems again? Post *details*! dig, traceroute, etc Unlike the last outage, their name servers appear to work fine. From aid at logic.org.uk Mon Sep 17 08:37:44 2012 From: aid at logic.org.uk (Adrian Bool) Date: Mon, 17 Sep 2012 14:37:44 +0100 Subject: IPv6 Ignorance In-Reply-To: <50571759.5050704@illuminati.org> References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <50571759.5050704@illuminati.org> Message-ID: On 17 Sep 2012, at 13:28, John Mitchell wrote: > > > Given that the first 3 bits of a public IPv6 address are always 001, giving /48 allocations to customers means that service providers will only have 2^(48-3) or 2^45 allocations of /48 to hand out > to a population of approximately 6 billion people. 2^33 is over 8 billion, so assuming a population of 2^33, there will be enough IPv6 /48 allocations to cater for 2^(45-33) or 2^12 or 4096 IPv6 > address allocations per user in the world." > It seems a tad unfair that the bottom 80 bits are squandered away with a utilisation rate of something closely approximating zero; yet the upper 48 bits are assumed to have zero wastage... Regards, aid From mitch at illuminati.org Mon Sep 17 08:46:47 2012 From: mitch at illuminati.org (John Mitchell) Date: Mon, 17 Sep 2012 14:46:47 +0100 Subject: IPv6 Ignorance In-Reply-To: References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <50571759.5050704@illuminati.org> Message-ID: <505729C7.3030605@illuminati.org> That is a very fair point, however one would hope (and this is a big hope) that the upper bits are more regulated to stricter standards than the lower bits. In any system there is room for human error or oversight that is always going to be a concern, but standards, good practises and policies can help mitigate this risk, which is something the upper blocks normally adhere too.. but with the lower blocks its in the hands of the smaller companies and consumers who don't *always* have the same rigorous standards. On 17/09/12 14:37, Adrian Bool wrote: > On 17 Sep 2012, at 13:28, John Mitchell wrote: > >> >>> Given that the first 3 bits of a public IPv6 address are always 001, giving /48 allocations to customers means that service providers will only have 2^(48-3) or 2^45 allocations of /48 to hand out > to a population of approximately 6 billion people. 2^33 is over 8 billion, so assuming a population of 2^33, there will be enough IPv6 /48 allocations to cater for 2^(45-33) or 2^12 or 4096 IPv6 > address allocations per user in the world." >> > It seems a tad unfair that the bottom 80 bits are squandered away with a utilisation rate of something closely approximating zero; yet the upper 48 bits are assumed to have zero wastage... > > Regards, > > aid > From cb.list6 at gmail.com Mon Sep 17 09:02:07 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Mon, 17 Sep 2012 07:02:07 -0700 Subject: IPv6 Ignorance In-Reply-To: References: <50560464.8020906@rollernet.us> Message-ID: On Sep 17, 2012 5:04 AM, "Tom Limoncelli" wrote: > > My biggest fear is that statements like this will take on a life of their own: > > " I can dual stack, then I am not out of IPv4 addresses, and thus I > have no need for IPv6. If I'm out of IPv4 then I need IPv6 and I can't > dual stack." http://forum.ubnt.com/showthread.php?p=355722 > > Not true but it certainly sounds logical to the average person. > > What creates this impression is that there is no "deadline". The IPv4 > -> Dual Stack -> pure IPv6 transition is complex so everyone focuses > on "IPv4 -> Dual Stack" forgetting that it is a transition step. The > final step seems so far off that people ignore it, and therefore the > justification for the first step fades. > > (the remainder of this post is brainstorming; apply a grain of salt) > > There are ways to fix this. For example there was a deadline for when > Dual Stack was to go away, a "Dual Stack 10 year count-down" would > drive the point home. However nothing like this exists. > > This thread is making me think that I should change how I talk about > IPv6 publicly. I need to put more emphasis on DS as being a temporary > thing. It is in my mind but perhaps not in how I speak. > I tell folks that if ipv4 run-out is the problem in eyeball networks, then DS cannot be the solution since it has the same problematic reliance on a scarce ipv4 resource. I spent a lot of time focusing on ipv6-only networking for mobile and in many cases, thanks to world v6 launch and ipv6-only based access network transition schemes (ds-lite, MAP, 464xlat) they can provide a solution for eyeball networks that is one step away from ipv6-only. .... Instead of DS, which is just one step beyond ipv4-only with a foggy road to getting off scarce / expensive / broken ipv4 Content networks are a different beast that must be dual-stack to reach all the eyeballs CB > The problem with picking a 10-year or 5-year "campaign" is that > underestimating the amount of time makes us look like "the sky is > falling" and too long gives people a reason to procrastinate. > > Then again... I believe what will make the biggest # of people adopt > IPv6 will be if they see everyone else adopting it. That's why it is > so important for IPv6 to be offered by default to all new ISP > customers, that tech-savy enterprises need to deploy it, and so on. > It is all about building a critical mass. > > Tom > > -- > Speaking at MacTech Conference 2012. http://mactech.com/conference" > http://EverythingSysadmin.com -- my blog > http://www.TomOnTime.com -- my videos > From nick at foobar.org Mon Sep 17 09:02:31 2012 From: nick at foobar.org (Nick Hilliard) Date: Mon, 17 Sep 2012 15:02:31 +0100 Subject: IPv6 Ignorance In-Reply-To: References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <50571759.5050704@illuminati.org> Message-ID: <50572D77.9090207@foobar.org> On 17/09/2012 14:37, Adrian Bool wrote: > It seems a tad unfair that the bottom 80 bits are squandered away with a > utilisation rate of something closely approximating zero You are thinking in ipv4 mode. In ipv6 mode, the consideration is not how many hosts you have, but how many subnets you are dealing with. Instead of thinking of 128 bits of addressing space, we talk about 64 bits of subnet space. So your statement comes down to: "it seems a tad unfair that the bottom 16 bits are squandered away". This is a more difficult argument to make. Nick From aid at logic.org.uk Mon Sep 17 09:55:15 2012 From: aid at logic.org.uk (Adrian Bool) Date: Mon, 17 Sep 2012 15:55:15 +0100 Subject: IPv6 Ignorance In-Reply-To: <50572D77.9090207@foobar.org> References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <50571759.5050704@illuminati.org> <50572D77.9090207@foobar.org> Message-ID: <76417C56-97C0-4DAE-9DF5-E8DEA7F0F2C9@logic.org.uk> Hi, On 17 Sep 2012, at 15:02, Nick Hilliard wrote: > On 17/09/2012 14:37, Adrian Bool wrote: >> It seems a tad unfair that the bottom 80 bits are squandered away with a >> utilisation rate of something closely approximating zero > > You are thinking in ipv4 mode. In ipv6 mode, the consideration is not how > many hosts you have, but how many subnets you are dealing with. Instead of > thinking of 128 bits of addressing space, we talk about 64 bits of subnet > space. So your statement comes down to: "it seems a tad unfair that the > bottom 16 bits are squandered away". This is a more difficult argument to > make. I don't really agree with the "IPv6 think" concept - but let's put that aside for now... The default allocation size from an RIR* to an LIR is a /32. For an LIR providing /48 site allocations to their customers, they therefore have 16-bits of address space available to them to address their customers. So, even in "IPv6 think", homes that typically have one subnet have an equal number of bits to address their single subnet as an LIR has to address all of their customers. It seems illogical to me that we've got an 128-bit address space, featuring numbers far larger than any human can comprehend, yet the default allocation to an LIR allows them to address such a feeble number as 65,536 customers - a number far smaller than the number of customers for medium to large ISPs. The default LIR allocation should be a several orders of magnitude greater than the typical customer base - not a smaller default allocation. Regards, Adrian * At least for RIPE. From mike.simkins at sungard.com Mon Sep 17 10:04:45 2012 From: mike.simkins at sungard.com (Mike Simkins) Date: Mon, 17 Sep 2012 16:04:45 +0100 Subject: IPv6 Ignorance In-Reply-To: <76417C56-97C0-4DAE-9DF5-E8DEA7F0F2C9@logic.org.uk> References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <50571759.5050704@illuminati.org> <50572D77.9090207@foobar.org> <76417C56-97C0-4DAE-9DF5-E8DEA7F0F2C9@logic.org.uk> Message-ID: <983a8fe30c5d07c11a5a52ce2cb8f4e8@mail.gmail.com> RIPE 552 (I think), allows you to request up to a /29 without additional justification if needed. Mike -----Original Message----- From: Adrian Bool [mailto:aid at logic.org.uk] Sent: 17 September 2012 15:55 To: nanog at nanog.org Subject: Re: IPv6 Ignorance Hi, On 17 Sep 2012, at 15:02, Nick Hilliard wrote: > On 17/09/2012 14:37, Adrian Bool wrote: >> It seems a tad unfair that the bottom 80 bits are squandered away >> with a utilisation rate of something closely approximating zero > > You are thinking in ipv4 mode. In ipv6 mode, the consideration is not > how > many hosts you have, but how many subnets you are dealing with. > Instead of thinking of 128 bits of addressing space, we talk about 64 > bits of subnet space. So your statement comes down to: "it seems a > tad unfair that the bottom 16 bits are squandered away". This is a > more difficult argument to make. I don't really agree with the "IPv6 think" concept - but let's put that aside for now... The default allocation size from an RIR* to an LIR is a /32. For an LIR providing /48 site allocations to their customers, they therefore have 16-bits of address space available to them to address their customers. So, even in "IPv6 think", homes that typically have one subnet have an equal number of bits to address their single subnet as an LIR has to address all of their customers. It seems illogical to me that we've got an 128-bit address space, featuring numbers far larger than any human can comprehend, yet the default allocation to an LIR allows them to address such a feeble number as 65,536 customers - a number far smaller than the number of customers for medium to large ISPs. The default LIR allocation should be a several orders of magnitude greater than the typical customer base - not a smaller default allocation. Regards, Adrian * At least for RIPE. From ikiris at gmail.com Mon Sep 17 10:14:11 2012 From: ikiris at gmail.com (Blake Dunlap) Date: Mon, 17 Sep 2012 10:14:11 -0500 Subject: IPv6 Ignorance In-Reply-To: <76417C56-97C0-4DAE-9DF5-E8DEA7F0F2C9@logic.org.uk> References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <50571759.5050704@illuminati.org> <50572D77.9090207@foobar.org> <76417C56-97C0-4DAE-9DF5-E8DEA7F0F2C9@logic.org.uk> Message-ID: On Mon, Sep 17, 2012 at 9:55 AM, Adrian Bool wrote: > > I don't really agree with the "IPv6 think" concept - but let's put that > aside for now... > > The default allocation size from an RIR* to an LIR is a /32. For an LIR > providing /48 site allocations to their customers, they therefore have > 16-bits of address space available to them to address their customers. > > So, even in "IPv6 think", homes that typically have one subnet have an > equal number of bits to address their single subnet as an LIR has to > address all of their customers. > > It seems illogical to me that we've got an 128-bit address space, > featuring numbers far larger than any human can comprehend, yet the default > allocation to an LIR allows them to address such a feeble number as 65,536 > customers - a number far smaller than the number of customers for medium to > large ISPs. > > The default LIR allocation should be a several orders of magnitude greater > than the typical customer base - not a smaller default allocation. > > Regards, > > Adrian > > > > * At least for RIPE. > Note you say default, as in beginning point, not maximum. -Blake From mark at exonetric.com Mon Sep 17 10:16:14 2012 From: mark at exonetric.com (Mark Blackman) Date: Mon, 17 Sep 2012 16:16:14 +0100 Subject: IPv6 Ignorance In-Reply-To: <76417C56-97C0-4DAE-9DF5-E8DEA7F0F2C9@logic.org.uk> References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <50571759.5050704@illuminati.org> <50572D77.9090207@foobar.org> <76417C56-97C0-4DAE-9DF5-E8DEA7F0F2C9@logic.org.uk> Message-ID: On 17 Sep 2012, at 15:55, Adrian Bool wrote: > > Hi, > > On 17 Sep 2012, at 15:02, Nick Hilliard wrote: >> On 17/09/2012 14:37, Adrian Bool wrote: >>> It seems a tad unfair that the bottom 80 bits are squandered away with a >>> utilisation rate of something closely approximating zero >> >> You are thinking in ipv4 mode. In ipv6 mode, the consideration is not how > >> many hosts you have, but how many subnets you are dealing with. Instead of >> thinking of 128 bits of addressing space, we talk about 64 bits of subnet >> space. So your statement comes down to: "it seems a tad unfair that the >> bottom 16 bits are squandered away". This is a more difficult argument to >> make. > > I don't really agree with the "IPv6 think" concept - but let's put that aside for now... > > The default allocation size from an RIR* to an LIR is a /32. For an LIR providing /48 site allocations to their customers, they therefore have 16-bits of address space available to them to address their customers. > > So, even in "IPv6 think", homes that typically have one subnet have an equal number of bits to address their single subnet as an LIR has to address all of their customers. > > It seems illogical to me that we've got an 128-bit address space, featuring numbers far larger than any human can comprehend, yet the default allocation to an LIR allows them to address such a feeble number as 65,536 customers - a number far smaller than the number of customers for medium to large ISPs. > > The default LIR allocation should be a several orders of magnitude greater than the typical customer base - not a smaller default allocation. Amen, brother! I was doing that particular computation about six months ago when we had our first request and arrived at the same conclusion. I've concluded that /48 for businesses and /56 for residential sites is the more reasonable approach until we start getting /24 IPv6 allocations for LIRs and I think many others have concluded the same. - Mark From matthew at matthew.at Mon Sep 17 10:18:52 2012 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 17 Sep 2012 08:18:52 -0700 Subject: IPv6 Ignorance In-Reply-To: <50571759.5050704@illuminati.org> References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <50571759.5050704@illuminati.org> Message-ID: <50573F5C.5090509@matthew.at> On 9/17/2012 5:28 AM, John Mitchell wrote: > I think people forget how humongous the v6 space is... > > Remember that the address space is 2^128 (or > 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses) to put > the in perspective (and a great sample that explained to me how large > it was, you will still get 667 quadrillion address per square > millimetre of the Earth?s Surface. Yes. But figure an average subnet has, what, maybe 5 hosts on it? (Sure, there's some bigger ones, but a whole lot of "my router, my PC, and maybe my printer" networks too. So even if you could use all the top bits (which you can't, as many combinations are reserved), that's more like 92,233,720,368,547,758,080. And if you lop off the top three bits and just count the space currently assigned to Global Unicast, that's 11,529,215,046,068,469,760. Which is 0.02 per square mm of the earth's surface. Or just over 2 per square centimeter. Powers of two get big fast... but they get small fast too. Matthew Kaufman From aid at logic.org.uk Mon Sep 17 10:23:18 2012 From: aid at logic.org.uk (Adrian Bool) Date: Mon, 17 Sep 2012 16:23:18 +0100 Subject: IPv6 Ignorance In-Reply-To: <983a8fe30c5d07c11a5a52ce2cb8f4e8@mail.gmail.com> References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <50571759.5050704@illuminati.org> <50572D77.9090207@foobar.org> <76417C56-97C0-4DAE-9DF5-E8DEA7F0F2C9@logic.org.uk> <983a8fe30c5d07c11a5a52ce2cb8f4e8@mail.gmail.com> Message-ID: Hi Mike, On 17 Sep 2012, at 16:04, Mike Simkins wrote: > RIPE 552 (I think), allows you to request up to a /29 without additional > justification if needed. Sure, but you're just tinkering at the edges here. 32-bits would be a more sensible allocation size to LIRs, allowing them construct their addressing plan in a logical, hierarchal manner whilst allowing for growth - and most importantly ensuring they only advertise a single route into the global routing table. Kind regards, Adrian From joelja at bogus.com Mon Sep 17 10:37:57 2012 From: joelja at bogus.com (joel jaeggli) Date: Mon, 17 Sep 2012 08:37:57 -0700 Subject: IPv6 Ignorance In-Reply-To: References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <50571759.5050704@illuminati.org> <50572D77.9090207@foobar.org> <76417C56-97C0-4DAE-9DF5-E8DEA7F0F2C9@logic.org.uk> <983a8fe30c5d07c11a5a52ce2cb8f4e8@mail.gmail.com> Message-ID: <505743D5.2070207@bogus.com> On 9/17/12 8:23 AM, Adrian Bool wrote: > Hi Mike, > > On 17 Sep 2012, at 16:04, Mike Simkins wrote: >> RIPE 552 (I think), allows you to request up to a /29 without additional >> justification if needed. > Sure, but you're just tinkering at the edges here. > > 32-bits would be a more sensible allocation size to LIRs, allowing them construct their addressing plan in a logical, hierarchal manner whilst allowing for growth - and most importantly ensuring they only advertise a single route into the global routing table. Which fine except we have assignment practices that have the result requiring the allocation of much shorter prefixes. Just handing out /32s fails the objective reality test. Regarding the single route, no they don't. and nobody that I know is filtering on /32 or longer. > Kind regards, > > Adrian > > > > > > > From nick at foobar.org Mon Sep 17 10:47:13 2012 From: nick at foobar.org (Nick Hilliard) Date: Mon, 17 Sep 2012 16:47:13 +0100 Subject: Big Temporary Networks In-Reply-To: <505663DE.7000309@necom830.hpcl.titech.ac.jp> References: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> <50561ADD.2040404@necom830.hpcl.titech.ac.jp> <505626A2.1090700@foobar.org> <505663DE.7000309@necom830.hpcl.titech.ac.jp> Message-ID: <50574601.5020803@foobar.org> On 17/09/2012 00:42, Masataka Ohta wrote: > OTOH, IPv6 requires many multicast received by STAs: RA and NS > for DAD, for example. > > Worse, minimum intervals of ND messages are often very large, > which means a lot of delay occurs when a message is lost. So, what you're saying here is that a wifi network with lots of packet loss will cause connectivity problems with ipv6? Nick From markk at arin.net Mon Sep 17 10:51:16 2012 From: markk at arin.net (Mark Kosters) Date: Mon, 17 Sep 2012 15:51:16 +0000 Subject: FW: [arin-announce] Resource Public Key Infrastructure (RPKI) Now Available to ARIN Customers In-Reply-To: <50572CCF.4090503@arin.net> Message-ID: Hi This announcement may be of interest to many of you. Regards, Mark From: INFO > Date: Monday, September 17, 2012 9:59 AM To: "arin-announce at arin.net" > Subject: [arin-announce] Resource Public Key Infrastructure (RPKI) Now Available to ARIN Customers ARIN is proud to announce that ARIN resource holders with either a signed RSA or LRSA may now participate in RPKI through ARIN Online. Additionally, those wishing to validate RPKI information may do so after requesting a Trust Anchor Locator (TAL). ARIN?s TAL is required to validate information from ARIN?s RPKI repository. RPKI is a free, opt-in service that allows users to certify their Internet number resources to help secure Internet routing. This initiative has been developed within the IETF's SIDR Working Group, with involvement from Regional Internet Registries (RIRs), and numerous Internet Service Providers (ISPs). ARIN encourages members of the Internet community to certify their resources through RPKI. Internet routing today is vulnerable to hijacking and the provisioning/use of certificates is one of steps required to make routing more secure. Widespread RPKI adoption will help simplify IP address holder verification and routing decision-making on the Internet. ARIN plans to continually review and improve RPKI based upon user feedback. Users are encouraged to report any issues via the arin-tech-discuss mailing list. For more information about this crucial step in securing Internet routing as well as future enhancement plans, visit ARIN?s RPKI Home Page at https://www.arin.net/resources/rpki/index.html. Regards, Mark Kosters Chief Technical Officer (CTO) American Registry for Internet Numbers (ARIN) From richard.e.brown at dartware.com Mon Sep 17 12:48:49 2012 From: richard.e.brown at dartware.com (Richard Brown) Date: Mon, 17 Sep 2012 17:48:49 +0000 Subject: IPv6 Burgers (was: IPv6 Ignorance) In-Reply-To: References: Message-ID: <6738D7C4-2837-45D6-9DF9-76DF2DA2A554@intermapper.com> Another measure of the size of the IPv6 address space... Back on World IPv6 Day in June 2011, Dartware had a barbecue. (Why? Because the burgers had 128 (bacon) bits and we served IP(A) to drink :-) You can see some photos at: http://www.networkworld.com/community/blog/scenes-ipv6-day-barbecue But we came up with another interesting measure for the vastness of the IPv6 address space: If an IPv4 hamburger patty has 2^32 (4.2 billion) unique addresses in its 1/4 inch thickness, how thick would an IPv6 hamburger be (with 2^128 unique addresses)? The answer is... 53 billion light-years. It's straightforward unit conversions. There are 2^96 IPv4 Hamburgers at a quarter-inch apiece. That's 2^96 inches/4 (2^94 inches). Switching to decimal units, 1.98x10^32 inches; 1.65x10^27 feet; 3.13x10^23 miles; and then continuing to convert to light-years. A good tool for this kind of wacky unit conversion is Frink (http://futureboy.us/fsp/frink.fsp?fromVal=2%5E94+inches&toVal=lightyears), which can do this in one shot. Simply enter: From: 2^94 inches To: lightyears and you'll see the answer! Rich Brown richard.e.brown at dartware.com Dartware, LLC http://www.intermapper.com 66-7 Benning Street Telephone: 603-643-9600 West Lebanon, NH 03784-3407 Fax: 603-643-2289 From owen at delong.com Mon Sep 17 13:13:59 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 17 Sep 2012 11:13:59 -0700 Subject: IPv6 Ignorance In-Reply-To: References: <20120916214016.7682.qmail@joyce.lan> Message-ID: <8C0CE1DF-27DC-4533-B49E-9986A0D21A55@delong.com> On Sep 16, 2012, at 16:58 , John R. Levine wrote: >>> IPv6 has its problems, but running out of addresses is not one of them. >>> For those of us worried about abuse management, the problem is the >>> opposite, even the current tiny sliver of addresses is so huge that >>> techniques from IPv4 to map who's doing what where don't scale. >> >> Well, in IPv4... NAT broke it, because networks implementing 1:many >> NAT could no longer easily identify what host was responsible for abuse. > > I realize that's a problem in theory, in practice it's not because it's still rare to have interestingly different hosts behind a single NAT. > CGN should solve that and convert theory to practice quite effectively. Owen From owen at delong.com Mon Sep 17 13:16:03 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 17 Sep 2012 11:16:03 -0700 Subject: IPv6 Ignorance In-Reply-To: References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> Message-ID: <5EF5A548-4A61-4F94-9BD5-C271C2D7347C@delong.com> On Sep 16, 2012, at 20:23 , Randy Bush wrote: > [ yes, there are a lot of idiots out there. this is not new. but ] > >> "We are totally convinced that the factors that made IPv4 run out of >> addresses will remanifest themselves once again and likely sooner than >> a lot of us might expect given the "Reccomendations" for "Best >> Practice" deployment." > > while i am not "totally convinced," i am certainly concerned. we are > doing many of the same things all over again. remember when rip forced > a homogenous, often classful, mask length in a network and we chewed > through /24s? think /64 in ipv6, except it's half the bits not 1/4 of > them. remember when we gave out As and Bs willy nilly? look at the > giant swaths of v6 we give out today in the hopes that someone will > deploy it. > > and don't bs me with how humongous the v6 address space is. we once > though 32 bits was humongous. > > randy We thought 32 bits was humongous in the context of a research project that would connect universities, research institutions and some military installations. In that context, 32 bits would still be humongous. Our estimation of humongous didn't change, the usage of the network changed dramatically. The experiment escaped from the laboratory and took on a life of its own. Once that happened, the realization that 32 bits wasn't enough was very nearly immediate. The IPv6 address space offers 61 bits of network numbers each of which holds up to 64 bits worth of hosts. Obviously you never want to fill one of those subnets (nor could you with any available hardware), but it means that you don't have to waste time thinking about rightsizing network assignments. I won't say we will never run out of IPv6 address space, but I will say that I'll be surprised if IPv6 doesn't hit a different limit first. Guess what... If it turns out that our current behavior with respect to IPv6 addresses is ill-advised, then, we have 6+ more copies of the current IPv6 address space where we can try different allocation strategies. Rather than fretting about the perils of using the protocol as intended, let's deploy it, get a working end-to-end internet and see where we stand. Owen From owen at delong.com Mon Sep 17 13:22:01 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 17 Sep 2012 11:22:01 -0700 Subject: IPv6 Ignorance In-Reply-To: <505729C7.3030605@illuminati.org> References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <50571759.5050704@illuminati.org> <505729C7.3030605@illuminati.org> Message-ID: Actually, as documented below, the assumption is merely that the waste will be less than 4095/4096ths of the address space. ;-) Owen On Sep 17, 2012, at 06:46 , John Mitchell wrote: > That is a very fair point, however one would hope (and this is a big hope) that the upper bits are more regulated to stricter standards than the lower bits. In any system there is room for human error or oversight that is always going to be a concern, but standards, good practises and policies can help mitigate this risk, which is something the upper blocks normally adhere too.. but with the lower blocks its in the hands of the smaller companies and consumers who don't *always* have the same rigorous standards. > > > On 17/09/12 14:37, Adrian Bool wrote: >> On 17 Sep 2012, at 13:28, John Mitchell wrote: >> >>> >>>> Given that the first 3 bits of a public IPv6 address are always 001, giving /48 allocations to customers means that service providers will only have 2^(48-3) or 2^45 allocations of /48 to hand out > to a population of approximately 6 billion people. 2^33 is over 8 billion, so assuming a population of 2^33, there will be enough IPv6 /48 allocations to cater for 2^(45-33) or 2^12 or 4096 IPv6 > address allocations per user in the world." >>> >> It seems a tad unfair that the bottom 80 bits are squandered away with a utilisation rate of something closely approximating zero; yet the upper 48 bits are assumed to have zero wastage... >> >> Regards, >> >> aid >> > From owen at delong.com Mon Sep 17 13:25:30 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 17 Sep 2012 11:25:30 -0700 Subject: IPv6 Ignorance In-Reply-To: <76417C56-97C0-4DAE-9DF5-E8DEA7F0F2C9@logic.org.uk> References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <50571759.5050704@illuminati.org> <50572D77.9090207@foobar.org> <76417C56-97C0-4DAE-9DF5-E8DEA7F0F2C9@logic.org.uk> Message-ID: <5A98F123-478C-4AC8-80C7-DA81289AFFD9@delong.com> On Sep 17, 2012, at 07:55 , Adrian Bool wrote: > > Hi, > > On 17 Sep 2012, at 15:02, Nick Hilliard wrote: >> On 17/09/2012 14:37, Adrian Bool wrote: >>> It seems a tad unfair that the bottom 80 bits are squandered away with a >>> utilisation rate of something closely approximating zero >> >> You are thinking in ipv4 mode. In ipv6 mode, the consideration is not how > >> many hosts you have, but how many subnets you are dealing with. Instead of >> thinking of 128 bits of addressing space, we talk about 64 bits of subnet >> space. So your statement comes down to: "it seems a tad unfair that the >> bottom 16 bits are squandered away". This is a more difficult argument to >> make. > > I don't really agree with the "IPv6 think" concept - but let's put that aside for now... > > The default allocation size from an RIR* to an LIR is a /32. For an LIR providing /48 site allocations to their customers, they therefore have 16-bits of address space available to them to address their customers. > > So, even in "IPv6 think", homes that typically have one subnet have an equal number of bits to address their single subnet as an LIR has to address all of their customers. > > It seems illogical to me that we've got an 128-bit address space, featuring numbers far larger than any human can comprehend, yet the default allocation to an LIR allows them to address such a feeble number as 65,536 customers - a number far smaller than the number of customers for medium to large ISPs. > > The default LIR allocation should be a several orders of magnitude greater than the typical customer base - not a smaller default allocation. > Don't think of it as the default allocation, think of it as the minimum allocation. You can very easily get a much larger allocation if you have more than 30,000 customers. Owen From owen at delong.com Mon Sep 17 13:27:04 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 17 Sep 2012 11:27:04 -0700 Subject: IPv6 Ignorance In-Reply-To: <50573F5C.5090509@matthew.at> References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <50571759.5050704@illuminati.org> <50573F5C.5090509@matthew.at> Message-ID: <82596E95-9C32-46BB-8B27-CB18290392C0@delong.com> On Sep 17, 2012, at 08:18 , Matthew Kaufman wrote: > On 9/17/2012 5:28 AM, John Mitchell wrote: >> I think people forget how humongous the v6 space is... >> >> Remember that the address space is 2^128 (or 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses) to put the in perspective (and a great sample that explained to me how large it was, you will still get 667 quadrillion address per square millimetre of the Earth?s Surface. > > Yes. But figure an average subnet has, what, maybe 5 hosts on it? (Sure, there's some bigger ones, but a whole lot of "my router, my PC, and maybe my printer" networks too. > > So even if you could use all the top bits (which you can't, as many combinations are reserved), that's more like 92,233,720,368,547,758,080. And if you lop off the top three bits and just count the space currently assigned to Global Unicast, that's 11,529,215,046,068,469,760. Which is 0.02 per square mm of the earth's surface. Or just over 2 per square centimeter. > > Powers of two get big fast... but they get small fast too. > > Matthew Kaufman What technology are you planning to deploy that will consume more than 2 addresses per square cm? Owen From owen at delong.com Mon Sep 17 13:28:56 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 17 Sep 2012 11:28:56 -0700 Subject: IPv6 Ignorance In-Reply-To: References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <50571759.5050704@illuminati.org> <50572D77.9090207@foobar.org> <76417C56-97C0-4DAE-9DF5-E8DEA7F0F2C9@logic.org.uk> Message-ID: <4338E8BB-D607-4DA3-A4AC-089E70F110F0@delong.com> On Sep 17, 2012, at 08:16 , Mark Blackman wrote: > > On 17 Sep 2012, at 15:55, Adrian Bool wrote: > >> >> Hi, >> >> On 17 Sep 2012, at 15:02, Nick Hilliard wrote: >>> On 17/09/2012 14:37, Adrian Bool wrote: >>>> It seems a tad unfair that the bottom 80 bits are squandered away with a >>>> utilisation rate of something closely approximating zero >>> >>> You are thinking in ipv4 mode. In ipv6 mode, the consideration is not how >> >>> many hosts you have, but how many subnets you are dealing with. Instead of >>> thinking of 128 bits of addressing space, we talk about 64 bits of subnet >>> space. So your statement comes down to: "it seems a tad unfair that the >>> bottom 16 bits are squandered away". This is a more difficult argument to >>> make. >> >> I don't really agree with the "IPv6 think" concept - but let's put that aside for now... >> >> The default allocation size from an RIR* to an LIR is a /32. For an LIR providing /48 site allocations to their customers, they therefore have 16-bits of address space available to them to address their customers. >> >> So, even in "IPv6 think", homes that typically have one subnet have an equal number of bits to address their single subnet as an LIR has to address all of their customers. >> >> It seems illogical to me that we've got an 128-bit address space, featuring numbers far larger than any human can comprehend, yet the default allocation to an LIR allows them to address such a feeble number as 65,536 customers - a number far smaller than the number of customers for medium to large ISPs. >> >> The default LIR allocation should be a several orders of magnitude greater than the typical customer base - not a smaller default allocation. > > Amen, brother! I was doing that particular computation about six months ago when we had > our first request and arrived at the same conclusion. I've concluded that /48 for businesses > and /56 for residential sites is the more reasonable approach until we start getting /24 IPv6 > allocations for LIRs and I think many others have concluded the same. > > - Mark > LIRs which need /24s can get /24s. /32 was never a maximum, it was merely the minimum and as such is a reasonable starting point. The vast majority of ISPs in operation today can give all their customers /48s out of a /28 and still have lots of room to spare. For larger providers, they should have no trouble justifying a much larger block. I know from experience that it is possible to get /24s in the ARIN region with reasonable justification, for example. Owen From repstein at hostleasing.net Mon Sep 17 13:49:52 2012 From: repstein at hostleasing.net (Randy Epstein) Date: Mon, 17 Sep 2012 14:49:52 -0400 Subject: [NANOG-announce] REMINDER: Upcoming NANOG mail list maintenance notification - 18-Sept-2012 Message-ID: Reminder of the upcoming Mail List service scheduled for Tuesday, September 18, 2012 beginning at 6 am Eastern, expected to last no more than 30 minutes. Regards, Randy Epstein NANOG CC Chair On behalf of the NANOG Communications Committee -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From eugen at leitl.org Mon Sep 17 14:54:33 2012 From: eugen at leitl.org (Eugen Leitl) Date: Mon, 17 Sep 2012 21:54:33 +0200 Subject: IPv6 Ignorance In-Reply-To: <82596E95-9C32-46BB-8B27-CB18290392C0@delong.com> References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <50571759.5050704@illuminati.org> <50573F5C.5090509@matthew.at> <82596E95-9C32-46BB-8B27-CB18290392C0@delong.com> Message-ID: <20120917195433.GM9750@leitl.org> On Mon, Sep 17, 2012 at 11:27:04AM -0700, Owen DeLong wrote: > What technology are you planning to deploy that will consume more than 2 addresses per square cm? Easy. Think volume (as in: orbit), and think um^3 for a functional computers ;) From Davis.Beeman at integratelecom.com Mon Sep 17 14:57:16 2012 From: Davis.Beeman at integratelecom.com (Beeman, Davis) Date: Mon, 17 Sep 2012 19:57:16 +0000 Subject: IPv6 Ignorance In-Reply-To: <82596E95-9C32-46BB-8B27-CB18290392C0@delong.com> References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <50571759.5050704@illuminati.org> <50573F5C.5090509@matthew.at> <82596E95-9C32-46BB-8B27-CB18290392C0@delong.com> Message-ID: <2AF841AB78217140A2A394B2BB6D39C501117EA7@IDCPRDMBX1.ads.integratelecom.com> On Sep 17, 2012, at 08:18 , Matthew Kaufman wrote: > On 9/17/2012 5:28 AM, John Mitchell wrote: >> I think people forget how humongous the v6 space is... >> >> Remember that the address space is 2^128 (or 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses) to put the in perspective (and a great sample that explained to me how large it was, you will still get 667 quadrillion address per square millimetre of the Earth's Surface. > > Yes. But figure an average subnet has, what, maybe 5 hosts on it? (Sure, there's some bigger ones, but a whole lot of "my router, my PC, and maybe my printer" networks too. > > So even if you could use all the top bits (which you can't, as many combinations are reserved), that's more like 92,233,720,368,547,758,080. And if you lop off the top three bits and just count the space currently assigned to Global Unicast, that's 11,529,215,046,068,469,760. Which is 0.02 per square mm of the earth's surface. Or just over 2 per square centimeter. > > Powers of two get big fast... but they get small fast too. > > Matthew Kaufman >What technology are you planning to deploy that will consume more than 2 addresses per square cm? >Owen http://xkcd.com/865/ -Davis From blake at pfankuch.me Mon Sep 17 16:04:13 2012 From: blake at pfankuch.me (Blake Pfankuch) Date: Mon, 17 Sep 2012 21:04:13 +0000 Subject: IPv6 Ignorance In-Reply-To: <20120917195433.GM9750@leitl.org> References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <50571759.5050704@illuminati.org> <50573F5C.5090509@matthew.at> <82596E95-9C32-46BB-8B27-CB18290392C0@delong.com> <20120917195433.GM9750@leitl.org> Message-ID: VMware vSphere on quad processor 1u servers with 768gb of RAM :) that should yield 80-140 VM's per host :) that gets you close on density. -----Original Message----- From: Eugen Leitl [mailto:eugen at leitl.org] Sent: Monday, September 17, 2012 1:55 PM To: nanog at nanog.org Subject: Re: IPv6 Ignorance On Mon, Sep 17, 2012 at 11:27:04AM -0700, Owen DeLong wrote: > What technology are you planning to deploy that will consume more than 2 addresses per square cm? Easy. Think volume (as in: orbit), and think um^3 for a functional computers ;) From marka at isc.org Mon Sep 17 16:28:00 2012 From: marka at isc.org (Mark Andrews) Date: Tue, 18 Sep 2012 07:28:00 +1000 Subject: IPv6 Ignorance In-Reply-To: Your message of "Mon, 17 Sep 2012 07:02:07 MST." References: <50560464.8020906@rollernet.us> Message-ID: <20120917212801.4875525417FA@drugs.dv.isc.org> In message , Cameron Byrne writes: > On Sep 17, 2012 5:04 AM, "Tom Limoncelli" wrote: > > > > My biggest fear is that statements like this will take on a life of their > own: > > > > " I can dual stack, then I am not out of IPv4 addresses, and thus I > > have no need for IPv6. If I'm out of IPv4 then I need IPv6 and I can't > > dual stack." http://forum.ubnt.com/showthread.php?p=355722 > > > > Not true but it certainly sounds logical to the average person. > > > > What creates this impression is that there is no "deadline". The IPv4 > > -> Dual Stack -> pure IPv6 transition is complex so everyone focuses > > on "IPv4 -> Dual Stack" forgetting that it is a transition step. The > > final step seems so far off that people ignore it, and therefore the > > justification for the first step fades. > > > > (the remainder of this post is brainstorming; apply a grain of salt) > > > > There are ways to fix this. For example there was a deadline for when > > Dual Stack was to go away, a "Dual Stack 10 year count-down" would > > drive the point home. However nothing like this exists. > > > > This thread is making me think that I should change how I talk about > > IPv6 publicly. I need to put more emphasis on DS as being a temporary > > thing. It is in my mind but perhaps not in how I speak. s > > > I tell folks that if ipv4 run-out is the problem in eyeball networks, then > DS cannot be the solution since it has the same problematic reliance on a > scarce ipv4 resource. You can go dual stack today and introduce CGN / DS-lite .... tomorrow. The point is to light up IPv6 *now* and the simplest way to do that is DS. No one ever said DS was a long term solution. It was always only the first step along the path. > I spent a lot of time focusing on ipv6-only networking for mobile and in > many cases, thanks to world v6 launch and ipv6-only based access network > transition schemes (ds-lite, MAP, 464xlat) they can provide a solution for > eyeball networks that is one step away from ipv6-only. .... Instead of DS, > which is just one step beyond ipv4-only with a foggy road to getting off > scarce / expensive / broken ipv4 And look at the extra hacks that are needed to tether with the current mobile solution of going IPv6 only and not supporting PD from day one. Mobile networks also have the advantage of tech refresh happening as you go from 2G -> 3G -> 4G. Most eyeball networks are different to mobile networks. You have a large base of IPv4 based networks connected to your network which contain some IPv4 equipement that cannot be upgraded. > Content networks are a different beast that must be dual-stack to reach all > the eyeballs > > CB > > > The problem with picking a 10-year or 5-year "campaign" is that > > underestimating the amount of time makes us look like "the sky is > > falling" and too long gives people a reason to procrastinate. > > > > Then again... I believe what will make the biggest # of people adopt > > IPv6 will be if they see everyone else adopting it. That's why it is > > so important for IPv6 to be offered by default to all new ISP > > customers, that tech-savy enterprises need to deploy it, and so on. > > It is all about building a critical mass. > > > > Tom > > > > -- > > Speaking at MacTech Conference 2012. http://mactech.com/conference" > > http://EverythingSysadmin.com -- my blog > > http://www.TomOnTime.com -- my videos > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From johnl at iecc.com Mon Sep 17 18:32:10 2012 From: johnl at iecc.com (John Levine) Date: 17 Sep 2012 23:32:10 -0000 Subject: IPv6 Ignorance In-Reply-To: Message-ID: <20120917233210.61755.qmail@joyce.lan> In article you write: >With current use cases at least, yes. What do we know of what's going to >happen in a decade or two? In technology, not much. But I'd be pretty surprised if the laws of arithmetic were to change, or if we were to find it useful to assign IP addresses to objects smaller than a single atom. My current example of how bit IPv6 addresses are: my home LAN has a tunneled IPv6 network, and the web server on my laptop has an IPv6 address. Even though some of the stuff on the laptop is somewhat confidential, I haven't bothered to use any passwords. Why? Because guessing the random low 64 bits assigned to the web server (which are not the auto generated address from the LAN card) is at least as hard as any password scheme. R's, John From mohta at necom830.hpcl.titech.ac.jp Mon Sep 17 18:39:55 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 18 Sep 2012 08:39:55 +0900 Subject: Big Temporary Networks In-Reply-To: <50574601.5020803@foobar.org> References: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> <50561ADD.2040404@necom830.hpcl.titech.ac.jp> <505626A2.1090700@foobar.org> <505663DE.7000309@necom830.hpcl.titech.ac.jp> <50574601.5020803@foobar.org> Message-ID: <5057B4CB.3020302@necom830.hpcl.titech.ac.jp> Nick Hilliard wrote: >> OTOH, IPv6 requires many multicast received by STAs: RA and NS >> for DAD, for example. >> >> Worse, minimum intervals of ND messages are often very large, >> which means a lot of delay occurs when a message is lost. > > So, what you're saying here is that a wifi network with lots of packet loss You don't understand CSMA/CA at all. There aren't so much packet losses except for broadcast/multicast packets. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Mon Sep 17 18:41:35 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 18 Sep 2012 08:41:35 +0900 Subject: IPv6 Ignorance In-Reply-To: <50571759.5050704@illuminati.org> References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <50571759.5050704@illuminati.org> Message-ID: <5057B52F.6070603@necom830.hpcl.titech.ac.jp> John Mitchell wrote: > I think people forget how humongous the v6 space is... They don't. Instead, they suffer from it. > Remember that the address space is 2^128 (or > 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses) That is one of a major design flaw of IPv6 as a result of failed attempt to have SLAAC, which resulted in so stateful and time wasting mechanism. As it is virtually impossible to remember IPv6 addresses, IPv6 operation is a lot harder than necessary. Masataka Ohta From matthew at matthew.at Mon Sep 17 18:53:49 2012 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 17 Sep 2012 16:53:49 -0700 Subject: IPv6 Ignorance In-Reply-To: <20120917233210.61755.qmail@joyce.lan> References: <20120917233210.61755.qmail@joyce.lan> Message-ID: <5057B80D.2000905@matthew.at> On 9/17/2012 4:32 PM, John Levine wrote: > In article you write: >> With current use cases at least, yes. What do we know of what's going to >> happen in a decade or two? > In technology, not much. But I'd be pretty surprised if the laws of > arithmetic were to change, or if we were to find it useful to assign > IP addresses to objects smaller than a single atom. > > My current example of how bit IPv6 addresses are: my home LAN has a > tunneled IPv6 network, and the web server on my laptop has an IPv6 > address. Even though some of the stuff on the laptop is somewhat > confidential, I haven't bothered to use any passwords. Why? Because > guessing the random low 64 bits assigned to the web server (which are > not the auto generated address from the LAN card) is at least as hard > as any password scheme. > And so you never visit any websites from that laptop that might keep access logs either? You do know that lists of "active" IPv6 addresses are already not that hard to come by, and that'll just get more and more true over time, yes? Matthew Kaufman From joseph.snyder at gmail.com Mon Sep 17 19:37:30 2012 From: joseph.snyder at gmail.com (joseph.snyder at gmail.com) Date: Mon, 17 Sep 2012 20:37:30 -0400 Subject: IPv6 Ignorance In-Reply-To: <5EF5A548-4A61-4F94-9BD5-C271C2D7347C@delong.com> References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <5EF5A548-4A61-4F94-9BD5-C271C2D7347C@delong.com> Message-ID: <34a9d615-0eb8-4b50-920d-e663b5a0fcb4@email.android.com> I agree with the way you are looking at it. I know it sounds impressive to talk about hosts, but in ipv6 all that matters is how many subnets do I have and how clean are my aggregation levels to avoid large wastes of subnets. Host addressing is not an issue or concern. So to talk about 128 bits instead of the reality of the 64 is silly. Owen DeLong wrote: > >On Sep 16, 2012, at 20:23 , Randy Bush wrote: > >> [ yes, there are a lot of idiots out there. this is not new. but ] >> >>> "We are totally convinced that the factors that made IPv4 run out of >>> addresses will remanifest themselves once again and likely sooner >than >>> a lot of us might expect given the "Reccomendations" for "Best >>> Practice" deployment." >> >> while i am not "totally convinced," i am certainly concerned. we are >> doing many of the same things all over again. remember when rip >forced >> a homogenous, often classful, mask length in a network and we chewed >> through /24s? think /64 in ipv6, except it's half the bits not 1/4 >of >> them. remember when we gave out As and Bs willy nilly? look at the >> giant swaths of v6 we give out today in the hopes that someone will >> deploy it. >> >> and don't bs me with how humongous the v6 address space is. we once >> though 32 bits was humongous. >> >> randy > >We thought 32 bits was humongous in the context of a research project >that would connect universities, research institutions and some >military >installations. > >In that context, 32 bits would still be humongous. > >Our estimation of humongous didn't change, the usage of the network >changed dramatically. The experiment escaped from the laboratory >and took on a life of its own. Once that happened, the realization that >32 bits wasn't enough was very nearly immediate. > >The IPv6 address space offers 61 bits of network numbers each of which >holds up to 64 bits worth of hosts. Obviously you never want to fill >one >of those subnets (nor could you with any available hardware), but it >means >that you don't have to waste time thinking about rightsizing network >assignments. > >I won't say we will never run out of IPv6 address space, but I will say >that I'll be surprised if IPv6 doesn't hit a different limit first. > >Guess what... If it turns out that our current behavior with respect to >IPv6 >addresses is ill-advised, then, we have 6+ more copies of the current >IPv6 address space where we can try different allocation strategies. > >Rather than fretting about the perils of using the protocol as >intended, >let's deploy it, get a working end-to-end internet and see where we >stand. > >Owen -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From niels=nanog at bakker.net Mon Sep 17 19:52:46 2012 From: niels=nanog at bakker.net (Niels Bakker) Date: Tue, 18 Sep 2012 02:52:46 +0200 Subject: Big Temporary Networks In-Reply-To: <50560173.5030309@bogus.com> References: <14744137.25172.1347812659174.JavaMail.root@benjamin.baylink.com> <50560173.5030309@bogus.com> Message-ID: <20120918005246.GX11613@burnout.tpb.net> * joelja at bogus.com (joel jaeggli) [Sun 16 Sep 2012, 18:42 CEST]: >We tend to engineer for a maximum of around 50 associations per radio >(not AP). beyond that performance really starts to suck which can be >measured along a multitude of dimensions. The most visible one to the >client(s) being latency due to loss and subsequent retransmission. > >Reduction in coverage is done on a couple of dimensions. that ap with >the 3-5dBi gain dipoles probably shouldn't be 100mW. but the noise >floor is in a different place when the room is full of clients so it >can't be to low either. Dropping the low speed rates backward >compatibility with 802.11b and setting the multicast rate to something >higher will force clients in marginal coverage situations to roam more >quickly, hog the air less and allow for higher throughput. This is all good advice that you should implement. The difficulty with high user density deployments is getting stations to associate to the nearest access point on the optimal band. When presented with the same SSID for 2.4 and 5 GHz, clients usually prefer te 2.4 GHz one because its S:N ratio usually seems better (inherent to the lower frequency). However, in practice this isn't always the case as there usually are many more clients on 2.4. Various vendors of lighweight access points use tricks to get clients to associate on the 5 GHz band: e.g. Cisco, I think, will reject an initial association request at 2.4 GHz in the hope that the client will retry at 5 GHz before retrying at 2.4, which will both be accepted. -- Niels. From owen at delong.com Mon Sep 17 22:14:20 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 17 Sep 2012 20:14:20 -0700 Subject: IPv6 Ignorance In-Reply-To: <20120917195433.GM9750@leitl.org> References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <50571759.5050704@illuminati.org> <50573F5C.5090509@matthew.at> <82596E95-9C32-46BB-8B27-CB18290392C0@delong.com> <20120917195433.GM9750@leitl.org> Message-ID: <548DEE97-B1C4-440B-B3CA-8812428067B8@delong.com> On Sep 17, 2012, at 12:54 , Eugen Leitl wrote: > On Mon, Sep 17, 2012 at 11:27:04AM -0700, Owen DeLong wrote: > >> What technology are you planning to deploy that will consume more than 2 addresses per square cm? > > Easy. Think volume (as in: orbit), and think um^3 for a functional computers ;) I meant real-world application. Orbits are limited due to the required combination of speed and altitude. There are a limited number of achievable altitudes and collision avoidance also creates interesting problems in time-slotting for orbits which are not geostationary. Geostationary orbits are currently limited to one object per degree of earth surface, and even at 4x that, you could give every satellite a /48 and still not burn through a /32. Owen From owen at delong.com Mon Sep 17 22:16:01 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 17 Sep 2012 20:16:01 -0700 Subject: IPv6 Ignorance In-Reply-To: References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <50571759.5050704@illuminati.org> <50573F5C.5090509@matthew.at> <82596E95-9C32-46BB-8B27-CB18290392C0@delong.com> <20120917195433.GM9750@leitl.org> Message-ID: <0E51395C-787D-4F01-AD1D-243948C06905@delong.com> True, but at a price that means this won't occur on very many of earth's many CM and even if it did, when you subtract the space required for cooling them and the space required to produce the power to drive them (and the cooling plants) and the space required to produce the fuels for the power plants and... you still come up short. Indeed, as you make the hosts more dense, you may come up even shorter due to the overhead of supporting them. Owen On Sep 17, 2012, at 14:04 , Blake Pfankuch wrote: > VMware vSphere on quad processor 1u servers with 768gb of RAM :) that should yield 80-140 VM's per host :) that gets you close on density. > > -----Original Message----- > From: Eugen Leitl [mailto:eugen at leitl.org] > Sent: Monday, September 17, 2012 1:55 PM > To: nanog at nanog.org > Subject: Re: IPv6 Ignorance > > On Mon, Sep 17, 2012 at 11:27:04AM -0700, Owen DeLong wrote: > >> What technology are you planning to deploy that will consume more than 2 addresses per square cm? > > Easy. Think volume (as in: orbit), and think um^3 for a functional computers ;) > From owen at delong.com Mon Sep 17 22:19:23 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 17 Sep 2012 20:19:23 -0700 Subject: IPv6 Ignorance In-Reply-To: <5057B52F.6070603@necom830.hpcl.titech.ac.jp> References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <50571759.5050704@illuminati.org> <5057B52F.6070603@necom830.hpcl.titech.ac.jp> Message-ID: <648E8275-6834-4E41-A736-DCA9A2F76425@delong.com> On Sep 17, 2012, at 16:41 , Masataka Ohta wrote: > John Mitchell wrote: > >> I think people forget how humongous the v6 space is... > > They don't. Instead, they suffer from it. > I find it quite useful, actually. I would not say I suffer from it at all. >> Remember that the address space is 2^128 (or >> 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses) > > That is one of a major design flaw of IPv6 as a result of failed > attempt to have SLAAC, which resulted in so stateful and time > wasting mechanism. > > As it is virtually impossible to remember IPv6 addresses, IPv6 > operation is a lot harder than necessary. > > Masataka Ohta > Hmmm... I find SLAAC quite useful so I'm not sure why you would call it time-wasting. I also have no more difficulty remembering IPv6 addresses in general than I had with IPv4. I can generally remember the prefixes I care about and the suffixes unless machine-generated are almost always easier to remember in IPv6 because there are enough bits to make them usefully meaningful instead of dense-packed meaningless numbers. YMMV. Owen From randy at psg.com Mon Sep 17 22:30:21 2012 From: randy at psg.com (Randy Bush) Date: Tue, 18 Sep 2012 12:30:21 +0900 Subject: IPv6 Ignorance In-Reply-To: <20120917233210.61755.qmail@joyce.lan> References: <20120917233210.61755.qmail@joyce.lan> Message-ID: > In technology, not much. But I'd be pretty surprised if the laws of > arithmetic were to change, or if we were to find it useful to assign > IP addresses to objects smaller than a single atom. we assign them /64s From mohta at necom830.hpcl.titech.ac.jp Mon Sep 17 23:00:14 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 18 Sep 2012 13:00:14 +0900 Subject: IPv6 Ignorance In-Reply-To: <648E8275-6834-4E41-A736-DCA9A2F76425@delong.com> References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <50571759.5050704@illuminati.org> <5057B52F.6070603@necom830.hpcl.titech.ac.jp> <648E8275-6834-4E41-A736-DCA9A2F76425@delong.com> Message-ID: <5057F1CE.6060206@necom830.hpcl.titech.ac.jp> Owen DeLong wrote: > I also have no more difficulty remembering IPv6 addresses in general > than I had with IPv4. I can generally remember You have already demonstrated your ability to remember things wrongly so many times in this ML, your statement is very convincing. > the prefixes I care about and the suffixes unless machine-generated > are almost always easier to remember in IPv6 because I'm afraid you forget to have stated: > Hmmm... I find SLAAC quite useful > YMMV. Your memory may vary. Masataka Ohta From bill at herrin.us Mon Sep 17 23:11:35 2012 From: bill at herrin.us (William Herrin) Date: Tue, 18 Sep 2012 00:11:35 -0400 Subject: Big Temporary Networks In-Reply-To: <505663DE.7000309@necom830.hpcl.titech.ac.jp> References: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> <50561ADD.2040404@necom830.hpcl.titech.ac.jp> <505626A2.1090700@foobar.org> <505663DE.7000309@necom830.hpcl.titech.ac.jp> Message-ID: On Sun, Sep 16, 2012 at 7:42 PM, Masataka Ohta wrote: > ARP and DHCP usually work. > > For an unusual case of ARP for other STAs, collisions do > increase initial latencies, but as refreshes are attempted > several times, there will be no latter latencies. > > OTOH, IPv6 requires many multicast received by STAs: RA and NS > for DAD, for example. > > Worse, minimum intervals of ND messages are often very large, > which means a lot of delay occurs when a message is lost. Hi Masataka, Where do things go wrong? As I understand it from your description, we're mostly talking about data between a wifi station and remote servers somewhere off the wired side of the network. Wifi station to station communications comprises a relatively minor portion of wifi's use so we don't burn a lot of worry on them in the general analysis. In the wifi to remote wired case, all IPv4 traveling the wifi network is subject to layer-2 error recovery except for the ARP packet from the default gateway to the station, requesting the station's MAC address. This works out OK because the default gateway is somewhat noisy about resending that arp request until it gets a response from the station and then it caches the response for a long time. In IPv6, the station sends an ICMPv6 router solicitation instead of an ARP for the default gateway. This is a multicast message but since it's from the station to the AP it's subject to layer 2 error recovery by the 802.11 protocol. The default gateway sends back a router advertisement (unicast since its responding to a solicitation) with prefix info, its MAC, its IP address, etc. Unicast = layer 2 error recovery. It then configures its address and sends packets to the default gateway. In the reverse direction, the gateway sends a neighbor solicitation via multicast looking for the MAC association with the station's IP. Like the ARP broadcast this is not subject to layer-2 error recovery. When the station eventually receives one of the repeated solicitations, it responds with a neighbor advertisement to the default gateway (station to AP, error recovered) which the default gateway caches for a while. In terms of the number and nature of packets sent without wifi's layer 2 error recovery, they look the same, at least in theory. What did I miss? Where does IPv6 take the bad turn that IPv4 avoided? Thanks, Bill Herrin -- 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 Tue Sep 18 00:25:16 2012 From: joelja at bogus.com (joel jaeggli) Date: Mon, 17 Sep 2012 22:25:16 -0700 Subject: IPv6 Ignorance In-Reply-To: <0E51395C-787D-4F01-AD1D-243948C06905@delong.com> References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <50571759.5050704@illuminati.org> <50573F5C.5090509@matthew.at> <82596E95-9C32-46BB-8B27-CB18290392C0@delong.com> <20120917195433.GM9750@leitl.org> <0E51395C-787D-4F01-AD1D-243948C06905@delong.com> Message-ID: <505805BC.2060202@bogus.com> http://www.antipope.org/charlie/blog-static/2012/08/how-low-power-can-you-go.html On 9/17/12 8:16 PM, Owen DeLong wrote: > True, but at a price that means this won't occur on very many of earth's many CM and even if it did, when you subtract the space required for cooling them and the space required to produce the power to drive them (and the cooling plants) and the space required to produce the fuels for the power plants and... you still come up short. Indeed, as you make the hosts more dense, you may come up even shorter due to the overhead of supporting them. > > Owen > > On Sep 17, 2012, at 14:04 , Blake Pfankuch wrote: > >> VMware vSphere on quad processor 1u servers with 768gb of RAM :) that should yield 80-140 VM's per host :) that gets you close on density. >> >> -----Original Message----- >> From: Eugen Leitl [mailto:eugen at leitl.org] >> Sent: Monday, September 17, 2012 1:55 PM >> To: nanog at nanog.org >> Subject: Re: IPv6 Ignorance >> >> On Mon, Sep 17, 2012 at 11:27:04AM -0700, Owen DeLong wrote: >> >>> What technology are you planning to deploy that will consume more than 2 addresses per square cm? >> Easy. Think volume (as in: orbit), and think um^3 for a functional computers ;) >> > > From bill at herrin.us Tue Sep 18 01:35:43 2012 From: bill at herrin.us (William Herrin) Date: Tue, 18 Sep 2012 02:35:43 -0400 Subject: IPv6 Ignorance In-Reply-To: <5EF5A548-4A61-4F94-9BD5-C271C2D7347C@delong.com> References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <5EF5A548-4A61-4F94-9BD5-C271C2D7347C@delong.com> Message-ID: On Mon, Sep 17, 2012 at 2:16 PM, Owen DeLong wrote: > We thought 32 bits was humongous in the context of a research project > that would connect universities, research institutions and some military > installations. > > In that context, 32 bits would still be humongous. > > Our estimation of humongous didn't change, the usage of the network > changed dramatically. The experiment escaped from the laboratory > and took on a life of its own. Once that happened, the realization that > 32 bits wasn't enough was very nearly immediate. > > The IPv6 address space offers 61 bits of network numbers each of which > holds up to 64 bits worth of hosts. Obviously you never want to fill one > of those subnets (nor could you with any available hardware), but it means > that you don't have to waste time thinking about rightsizing network > assignments. Hi Owen, We think 64 bits is humongous on an IPv4 Internet where autoconfiguration is rarely bordering never larger than a single LAN. But, we want the fridge to get a /64 from the home automation controller for its internal sensor network. Which means the home automation controller will be holding something around a /58 or so in order to accommodate the various smart devices in the house. Which means the the cable router will be holding a /54 or more to accommodate the server lan, the home automation delegation, the PC lan, the VM delegation, the wifi lan, etc. And at a customer boundary we'll only break at a nibble boundary, so that brings us to /52. Which is inconvenient since we often have larger users so we'll just break at /48 for everybody. Then we need 32 bits to overlay the customer's IPv4 address for convenience within our 6RD network. So that leaves us 16 bits. But we don't want the native network to overlay the 6RD network because we want a real simple /16 route into the nearest 6rd encapsulator. And we don't want to advertise multiple BGP prefixes either. So we claim another bit and allocate our native infrastructure from the /16 that doesn't overlap the 6rd setup. 3 bits are held in reserve at the top; only 2000::/3 is available for public Internet use. So that drops us from 15 to 12 bits. Now we want to organize the BGP backbone and we've 12 bits left to work with. That's 4 bits less than the number of autonomous systems participating in BGP on Internet today. Of course this is in many ways a straw man. And I'm picking on you Owen because in the past you've advocated both /48's for end users and 6rd justifying 32 bits of allocation above that from the registry. But really, with the right (or maybe I mean wrong) hierarchic network auto-configuration technologies it's not hard to imagine how the IPv6 address space could be exhausted in 20 years. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From alexb at ripe.net Tue Sep 18 02:32:12 2012 From: alexb at ripe.net (Alex Band) Date: Tue, 18 Sep 2012 09:32:12 +0200 Subject: [arin-announce] Resource Public Key Infrastructure (RPKI) Now Available to ARIN Customers In-Reply-To: References: Message-ID: <0C8926A8-0EC8-4964-8769-E212FD18532B@ripe.net> The first ROAs created in the ARIN system are starting to appear: https://dl.dropbox.com/u/26242517/ARIN_ROAs_20120918.png Check the progress in our public RPKI Validator testbed (hosted by EuroTransit and connected to a Juniper running 12.2 with BGP Origin Validation support): http://rpki01.fra2.de.euro-transit.net:8080 Public testbed info at the bottom of this page: http://www.ripe.net/certification/tools-and-resources -Alex On 17 Sep 2012, at 17:51, Mark Kosters wrote: > Hi > > This announcement may be of interest to many of you. > > Regards, > Mark > > From: INFO > > Date: Monday, September 17, 2012 9:59 AM > To: "arin-announce at arin.net" > > Subject: [arin-announce] Resource Public Key Infrastructure (RPKI) Now Available to ARIN Customers > > ARIN is proud to announce that ARIN resource holders with either a signed RSA or LRSA may now participate in RPKI through ARIN Online. Additionally, those wishing to validate RPKI information may do so after requesting a Trust Anchor Locator (TAL). ARIN?s TAL is required to validate information from ARIN?s RPKI repository. > > RPKI is a free, opt-in service that allows users to certify their Internet number resources to help secure Internet routing. This initiative has been developed within the IETF's SIDR Working Group, with involvement from Regional Internet Registries (RIRs), and numerous Internet Service Providers (ISPs). > > ARIN encourages members of the Internet community to certify their resources through RPKI. Internet routing today is vulnerable to hijacking and the provisioning/use of certificates is one of steps required to make routing more secure. Widespread RPKI adoption will help simplify IP address holder verification and routing decision-making on the Internet. > > ARIN plans to continually review and improve RPKI based upon user feedback. Users are encouraged to report any issues via the arin-tech-discuss mailing list. > > For more information about this crucial step in securing Internet routing as well as future enhancement plans, visit ARIN?s RPKI Home Page at https://www.arin.net/resources/rpki/index.html. > > Regards, > > Mark Kosters > Chief Technical Officer (CTO) > American Registry for Internet Numbers (ARIN) > From o.calvano at gmail.com Tue Sep 18 04:16:23 2012 From: o.calvano at gmail.com (Olivier CALVANO) Date: Tue, 18 Sep 2012 11:16:23 +0200 Subject: China Contact Message-ID: Hi I am search a supplier for Ethernet Link from Bejing to Singapore and changzhou to singapore Anyone have a contact for this ? (SingTel ? China Telecom ?) Thanks Olivier From mohta at necom830.hpcl.titech.ac.jp Tue Sep 18 12:16:32 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 18 Sep 2012 21:16:32 +0900 Subject: Big Temporary Networks In-Reply-To: References: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> <50561ADD.2040404@necom830.hpcl.titech.ac.jp> <505626A2.1090700@foobar.org> <505663DE.7000309@necom830.hpcl.titech.ac.jp> Message-ID: <50586620.6080702@necom830.hpcl.titech.ac.jp> William Herrin wrote: >> OTOH, IPv6 requires many multicast received by STAs: RA and NS >> for DAD, for example. >> >> Worse, minimum intervals of ND messages are often very large, >> which means a lot of delay occurs when a message is lost. > > Hi Masataka, > > Where do things go wrong? >> OTOH, IPv6 requires many multicast received by STAs: RA and NS >> for DAD, for example. > Wifi station to station communications comprises > a relatively minor portion of wifi's use so we don't burn a lot of > worry on them in the general analysis. >> OTOH, IPv6 requires many multicast received by STAs: RA and NS >> for DAD, for example. > In IPv6, the station sends an ICMPv6 router solicitation instead of an > ARP for the default gateway. This is a multicast message but since > it's from the station to the AP it's subject to layer 2 error recovery > by the 802.11 protocol. The default gateway sends back a router > advertisement (unicast since its responding to a solicitation) Unicast since its responding to a solicitation? RFC4861 states: A router MAY choose to unicast the response directly to the soliciting host's address (if the solicitation's source address is not the unspecified address), but the usual case is to multicast the response to the all-nodes group. and a comment in rtadvd on the solicited advertisement: /* * unicast advertisements * XXX commented out. reason: though spec does not forbit it, unicast * advert does not really help > In the reverse direction, Poor SLAAC with a lot of configured states is unnecessarily a lot more complex than simply bidirectional ARP, because it must involve all the distributed states of all the hosts on the link. > What did I > miss? Where does IPv6 take the bad turn that IPv4 avoided? If you still want to defend IPv6, you must say multicast RA and DAD are unnecessary features of IPv6, which means the current IPv6 is broken. Masataka Ohta From rs at seastrom.com Tue Sep 18 13:21:46 2012 From: rs at seastrom.com (Robert E. Seastrom) Date: Tue, 18 Sep 2012 09:21:46 -0400 Subject: IPv6 Ignorance In-Reply-To: <50560464.8020906@rollernet.us> (Seth Mattinen's message of "Sun, 16 Sep 2012 09:55:00 -0700") References: <50560464.8020906@rollernet.us> Message-ID: <86lig7cvpw.fsf@seastrom.com> Seth Mattinen writes: > I came across these threads today; the blind ignorance towards IPv6 from > some of the posters is kind of shocking. There are actually a few good points mixed in there, like the guy who observes that dual stacking is of limited utility if there are no v4 addresses to be had. I keep performing this vendor monologue. It goes something like: What do I mean when I say "it must support IPv6"? I mean two things. First, full feature parity with IPv4. Everything that works under IPv4 must work under IPv6. If you have exceptions, you'd better document them and have a remediation plan (or work-around if it is a deficiency baked into the standard; there are a few of which I'm aware). Second, the device must function perfectly in an IPv6-only environment, with not a hint of IPv4 addressing around. Dual-stack capability is nice, but should be an easy thing to provide if you can handle the first two requirements. Furious scribbling in the 'ol Moleskine invariably ensues. I am not sure what it is about this set of requirements (which seems so plain to see that I felt as if I was belaboring the obvious the first time I brought it up) that seems like a revelation to people in the vendor space, but apparently it does. Are *you* doing *your* part? Taken your shoe off and banged it on the conference room table Khrushchev-style lately? -r From owen at delong.com Tue Sep 18 14:01:13 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 18 Sep 2012 07:01:13 -0700 Subject: IPv6 Ignorance In-Reply-To: References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <5EF5A548-4A61-4F94-9BD5-C271C2D7347C@delong.com> Message-ID: On Sep 17, 2012, at 23:35 , William Herrin wrote: > On Mon, Sep 17, 2012 at 2:16 PM, Owen DeLong wrote: >> We thought 32 bits was humongous in the context of a research project >> that would connect universities, research institutions and some military >> installations. >> >> In that context, 32 bits would still be humongous. >> >> Our estimation of humongous didn't change, the usage of the network >> changed dramatically. The experiment escaped from the laboratory >> and took on a life of its own. Once that happened, the realization that >> 32 bits wasn't enough was very nearly immediate. >> >> The IPv6 address space offers 61 bits of network numbers each of which >> holds up to 64 bits worth of hosts. Obviously you never want to fill one >> of those subnets (nor could you with any available hardware), but it means >> that you don't have to waste time thinking about rightsizing network >> assignments. > > Hi Owen, > > We think 64 bits is humongous on an IPv4 Internet where > autoconfiguration is rarely bordering never larger than a single LAN. > > But, we want the fridge to get a /64 from the home automation > controller for its internal sensor network. Which means the home > automation controller will be holding something around a /58 or so in > order to accommodate the various smart devices in the house. Which > means the the cable router will be holding a /54 or more to > accommodate the server lan, the home automation delegation, the PC > lan, the VM delegation, the wifi lan, etc. And at a customer boundary > we'll only break at a nibble boundary, so that brings us to /52. Which > is inconvenient since we often have larger users so we'll just break > at /48 for everybody. > Correct. > Then we need 32 bits to overlay the customer's IPv4 address for > convenience within our 6RD network. So that leaves us 16 bits. But we > don't want the native network to overlay the 6RD network because we > want a real simple /16 route into the nearest 6rd encapsulator. And we > don't want to advertise multiple BGP prefixes either. So we claim > another bit and allocate our native infrastructure from the /16 that > doesn't overlap the 6rd setup. > No, you really don't. This absurdity (and the ridiculous design of 6RD) are so problematic in this area that I cannot begin to describe what a terrible idea it is. > 3 bits are held in reserve at the top; only 2000::/3 is available for > public Internet use. So that drops us from 15 to 12 bits. Now we want > to organize the BGP backbone and we've 12 bits left to work with. > That's 4 bits less than the number of autonomous systems participating > in BGP on Internet today. Again, if you take the 6RD mess out of the equation and don't saddle IPv6 with this IPv4 baggage, this is a non-issue. > Of course this is in many ways a straw man. And I'm picking on you > Owen because in the past you've advocated both /48's for end users and > 6rd justifying 32 bits of allocation above that from the registry. But > really, with the right (or maybe I mean wrong) hierarchic network > auto-configuration technologies it's not hard to imagine how the IPv6 > address space could be exhausted in 20 years. > I still advocate /48s and I have never advocated 6RD as a permanent solution, nor have I advocated giving ISPs /16s in support of 6RD. I have supported policy to allow for temporary allocations in support of 6RD giving customers more limited (/56) prefixes due to the constraints of 6RD, however, I have consistently referred to this as a degraded form of IPv6. Owen From eugen at leitl.org Tue Sep 18 14:07:12 2012 From: eugen at leitl.org (Eugen Leitl) Date: Tue, 18 Sep 2012 16:07:12 +0200 Subject: The Department of Work and Pensions, UK has an entire /8 Message-ID: <20120918140712.GF9750@leitl.org> http://paritynews.com/network/item/325-department-of-work-and-pensions-uk-in-possession-of-169-million-unused-ipv4-addresses Department of Work and Pensions UK in Possession of 16.9 Million Unused IPv4 Addresses Written by Ravi Mandalia Department of Work and Pensions UK in Possession of 16.9 Million Unused IPv4 Addresses The Department of Work and Pensions, UK has an entire block of '/8' IPv4 addresses that is unused and an e-petition has been filed in this regards asking the DWP to sell it off thus easing off the RIPE IPv4 address space scarcity a little. John Graham-Cumming, who found this unused block, wrote in a blog post that the DWP was in possession of 51.0.0.0/8 IPv4 addresses. According to Cumming, these 16.9 million IP addresses are unused at the moment and he derived this conclusion by doing a check in the ASN database. ?A check of the ASN database will show that there are no networks for that block of addresses,? he wrote. An e-petition has been filed in this regards. ?It has recently come to light that the Department for Work and Pensions has its own allocated block of 16,777,216 addresses (commonly referred to as a /8), covering 51.0.0.0 to 51.255.255.255?, reads the petition. The UK government, if it sells off this /8 block, could end up getting ?1 billion mark. ??1 billion of low-effort extra cash would be a very nice thing to throw at our deficit,? read the petition. Cumming ends his post with the remark, ?So, Mr. Cameron, I'll accept a 10% finder's fee if you dispose of this asset :-)?. From jeroen at unfix.org Tue Sep 18 14:16:48 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 18 Sep 2012 16:16:48 +0200 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <20120918140712.GF9750@leitl.org> References: <20120918140712.GF9750@leitl.org> Message-ID: <50588250.6070802@unfix.org> On 2012-09-18 16:07 , Eugen Leitl wrote: [..] > John Graham-Cumming, who found this unused block, wrote in a blog post that > the DWP was in possession of 51.0.0.0/8 IPv4 addresses. According to Cumming, > these 16.9 million IP addresses are unused at the moment and he derived this > conclusion by doing a check in the ASN database. ?A check of the ASN database > will show that there are no networks for that block of addresses,? he wrote. Some people have to learn that not every address is only used on the Internet. According to the above there will be large swaths of IPv4 left at various large organizations who have /8's as "they are not announced" or as the article states it "as there is no ASN". Please keep this nonsense off of NANOG... Greets, Jeroen From prt at prt.org Tue Sep 18 14:17:45 2012 From: prt at prt.org (Paul Thornton) Date: Tue, 18 Sep 2012 15:17:45 +0100 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <20120918140712.GF9750@leitl.org> References: <20120918140712.GF9750@leitl.org> Message-ID: <50588289.4090904@prt.org> On 18/09/2012 15:07, Eugen Leitl wrote: > > http://paritynews.com/network/item/325-department-of-work-and-pensions-uk-in-possession-of-169-million-unused-ipv4-addresses > > Department of Work and Pensions UK in Possession of 16.9 Million Unused IPv4 > Addresses The only slight snag in his argument is that the addresses are not unused. Not announced != Not used. Paul. From nick at foobar.org Tue Sep 18 14:32:47 2012 From: nick at foobar.org (Nick Hilliard) Date: Tue, 18 Sep 2012 15:32:47 +0100 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <20120918140712.GF9750@leitl.org> References: <20120918140712.GF9750@leitl.org> Message-ID: <5058860F.6050203@foobar.org> On 18/09/2012 15:07, Eugen Leitl wrote: > Department of Work and Pensions UK in Possession of 16.9 Million Unused IPv4 > Addresses "unused"? sez who? Oh, it said it on the internet so it must be true. Other than that, I'm totally failing to see what's newsworthy about who or what happens to hold a legacy /8. Could someone explain? Nick From eugen at leitl.org Tue Sep 18 14:37:12 2012 From: eugen at leitl.org (Eugen Leitl) Date: Tue, 18 Sep 2012 16:37:12 +0200 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <5058860F.6050203@foobar.org> References: <20120918140712.GF9750@leitl.org> <5058860F.6050203@foobar.org> Message-ID: <20120918143712.GI9750@leitl.org> On Tue, Sep 18, 2012 at 03:32:47PM +0100, Nick Hilliard wrote: > On 18/09/2012 15:07, Eugen Leitl wrote: > > Department of Work and Pensions UK in Possession of 16.9 Million Unused IPv4 > > Addresses > > "unused"? sez who? Oh, it said it on the internet so it must be true. > > Other than that, I'm totally failing to see what's newsworthy about who or > what happens to hold a legacy /8. Could someone explain? Sorry about the noise. Won't happen again. From tjc at ecs.soton.ac.uk Tue Sep 18 14:39:37 2012 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Tue, 18 Sep 2012 15:39:37 +0100 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <5058860F.6050203@foobar.org> References: <20120918140712.GF9750@leitl.org> <5058860F.6050203@foobar.org> <35B2AF55-EF36-45AA-AC35-D3D2E448EC32@ecs.soton.ac.uk> Message-ID: On 18 Sep 2012, at 15:32, Nick Hilliard wrote: > On 18/09/2012 15:07, Eugen Leitl wrote: >> Department of Work and Pensions UK in Possession of 16.9 Million Unused IPv4 >> Addresses > > "unused"? sez who? Oh, it said it on the internet so it must be true. > > Other than that, I'm totally failing to see what's newsworthy about who or > what happens to hold a legacy /8. Could someone explain? Pssst! Want a nice unused /4? Yours cheap! Tim From repstein at hostleasing.net Tue Sep 18 14:45:43 2012 From: repstein at hostleasing.net (Randy Epstein) Date: Tue, 18 Sep 2012 10:45:43 -0400 Subject: [NANOG-announce] NANOG mail list maintenance completed Message-ID: NANOG Community: The mail list upgrade went well. NANOG mail lists are now operating on NANOG owned machines and under the management of the Communications Committee. Regards, Randy Epstein NANOG CC Chair On behalf of the NANOG Communications Committee -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From smeuse at mara.org Tue Sep 18 14:58:40 2012 From: smeuse at mara.org (Steve Meuse) Date: Tue, 18 Sep 2012 10:58:40 -0400 Subject: IPv6 Ignorance In-Reply-To: <86lig7cvpw.fsf@seastrom.com> References: <50560464.8020906@rollernet.us> <86lig7cvpw.fsf@seastrom.com> Message-ID: On Tue, Sep 18, 2012 at 9:21 AM, Robert E. Seastrom wrote: > > > What do I mean when I say "it must support IPv6"? I mean two things. > First, full feature parity with IPv4. Everything that works under > IPv4 must work under IPv6. If you have exceptions, you'd better > document them and have a remediation plan (or work-around if it is a > deficiency baked into the standard; there are a few of which I'm > aware). Second, the device must function perfectly in an IPv6-only > environment, with not a hint of IPv4 addressing around. Dual-stack > capability is nice, but should be an easy thing to provide if you can > handle the first two requirements. Well spoken RS, I'm cutting and pasting this one to my account team(s). Far too many discussions about this with them recently. (really, you're just *now* getting v6 to work on bundled interfaces?) -Steve From askoorb+nanog at gmail.com Tue Sep 18 15:06:02 2012 From: askoorb+nanog at gmail.com (Alex Brooks) Date: Tue, 18 Sep 2012 16:06:02 +0100 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <50588289.4090904@prt.org> References: <20120918140712.GF9750@leitl.org> <50588289.4090904@prt.org> Message-ID: On Tue, Sep 18, 2012 at 3:17 PM, Paul Thornton wrote: > > On 18/09/2012 15:07, Eugen Leitl wrote: >> >> >> >> http://paritynews.com/network/item/325-department-of-work-and-pensions-uk-in-possession-of-169-million-unused-ipv4-addresses >> >> Department of Work and Pensions UK in Possession of 16.9 Million Unused >> IPv4 >> Addresses > > > The only slight snag in his argument is that the addresses are not unused. > Not announced != Not used. > See http://en.wikipedia.org/wiki/Government_Secure_Intranet for details on HM Government's Intranet, if you are so inclined. It is currently being transformed into the "Public Services Network": http://www.cabinetoffice.gov.uk/content/public-services-network. Alex From jared at puck.nether.net Tue Sep 18 15:08:27 2012 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 18 Sep 2012 11:08:27 -0400 Subject: IPv6 Ignorance In-Reply-To: References: <50560464.8020906@rollernet.us> <86lig7cvpw.fsf@seastrom.com> Message-ID: <33069FF2-AEF4-49AD-BAD7-0E462606550C@puck.nether.net> On Sep 18, 2012, at 10:58 AM, Steve Meuse wrote: > On Tue, Sep 18, 2012 at 9:21 AM, Robert E. Seastrom wrote: > >> >> >> What do I mean when I say "it must support IPv6"? I mean two things. >> First, full feature parity with IPv4. Everything that works under >> IPv4 must work under IPv6. If you have exceptions, you'd better >> document them and have a remediation plan (or work-around if it is a >> deficiency baked into the standard; there are a few of which I'm >> aware). Second, the device must function perfectly in an IPv6-only >> environment, with not a hint of IPv4 addressing around. Dual-stack >> capability is nice, but should be an easy thing to provide if you can >> handle the first two requirements. > > > Well spoken RS, I'm cutting and pasting this one to my account team(s). Far > too many discussions about this with them recently. (really, you're just > *now* getting v6 to work on bundled interfaces?) We've been doing this for years on both Juniper & IOS/IOS-XR devices. Must be someone else. We do run into this whole feature parity thing often. The vendors seem to be challenged in this space. I suspect a significant part of it is they don't actually *use* IPv6 internally or in their lab. We have been operating our network with IPv6 for many years now. I believe in most cases our connection to the management plane go IPv6 only as well. It's been fun to see the few SSH over IPv6 defects and other elements arise as time has passed, but those days are over. It's just tiring now and no longer amusing. (hey you kids, get off my lawn?). - Jared From smeuse at mara.org Tue Sep 18 15:24:44 2012 From: smeuse at mara.org (Steve Meuse) Date: Tue, 18 Sep 2012 11:24:44 -0400 Subject: IPv6 Ignorance In-Reply-To: <33069FF2-AEF4-49AD-BAD7-0E462606550C@puck.nether.net> References: <50560464.8020906@rollernet.us> <86lig7cvpw.fsf@seastrom.com> <33069FF2-AEF4-49AD-BAD7-0E462606550C@puck.nether.net> Message-ID: On Tue, Sep 18, 2012 at 11:08 AM, Jared Mauch wrote: > > > We've been doing this for years on both Juniper & IOS/IOS-XR devices. > Must be someone else. > I may be wrong, but IOS-XR on A9K only supported v6 on bundle-ether interfaces as of 4.1.2-ish. That, of course, leads to the conversation of keeping function parity between same software revs but different hardware platforms. I understand the issues there, but doesn't make deploying a feature any easier.... -Steve From jared at puck.nether.net Tue Sep 18 15:31:07 2012 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 18 Sep 2012 11:31:07 -0400 Subject: IPv6 Ignorance In-Reply-To: References: <50560464.8020906@rollernet.us> <86lig7cvpw.fsf@seastrom.com> <33069FF2-AEF4-49AD-BAD7-0E462606550C@puck.nether.net> Message-ID: <157B1B6F-2111-4F55-995B-501004E9D0FD@puck.nether.net> It was supported before there. We were using it prior to that release. You needed a smu though. I can perhaps find details if they are that important for you. Jared Mauch On Sep 18, 2012, at 11:24 AM, Steve Meuse wrote: > > > On Tue, Sep 18, 2012 at 11:08 AM, Jared Mauch wrote: >> >> >> We've been doing this for years on both Juniper & IOS/IOS-XR devices. Must be someone else. > > I may be wrong, but IOS-XR on A9K only supported v6 on bundle-ether interfaces as of 4.1.2-ish. > > That, of course, leads to the conversation of keeping function parity between same software revs but different hardware platforms. I understand the issues there, but doesn't make deploying a feature any easier.... > > -Steve > From johnl at iecc.com Tue Sep 18 15:36:12 2012 From: johnl at iecc.com (John Levine) Date: 18 Sep 2012 15:36:12 -0000 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <20120918140712.GF9750@leitl.org> Message-ID: <20120918153612.17528.qmail@joyce.lan> >John Graham-Cumming, who found this unused block, wrote in a blog post that >the DWP was in possession of 51.0.0.0/8 IPv4 addresses. Please, don't anyone tell him about 25/8. From Valdis.Kletnieks at vt.edu Tue Sep 18 15:39:38 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 18 Sep 2012 11:39:38 -0400 Subject: IPv6 Ignorance In-Reply-To: Your message of "Tue, 18 Sep 2012 02:35:43 -0400." References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <5EF5A548-4A61-4F94-9BD5-C271C2D7347C@delong.com> Message-ID: <10390.1347982778@turing-police.cc.vt.edu> On Tue, 18 Sep 2012 02:35:43 -0400, William Herrin said: > Then we need 32 bits to overlay the customer's IPv4 address for > convenience within our 6RD network. Well yeah. You blow 32 bits for silly reasons, you run out of bits. Film at 11. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From mike at mtcc.com Tue Sep 18 15:52:30 2012 From: mike at mtcc.com (Michael Thomas) Date: Tue, 18 Sep 2012 08:52:30 -0700 Subject: IPv6 Ignorance In-Reply-To: <33069FF2-AEF4-49AD-BAD7-0E462606550C@puck.nether.net> References: <50560464.8020906@rollernet.us> <86lig7cvpw.fsf@seastrom.com> <33069FF2-AEF4-49AD-BAD7-0E462606550C@puck.nether.net> Message-ID: <505898BE.30704@mtcc.com> On 09/18/2012 08:08 AM, Jared Mauch wrote: > > We've been doing this for years on both Juniper & IOS/IOS-XR devices. Must be someone else. > > We do run into this whole feature parity thing often. The vendors seem to be challenged in this space. I suspect a significant part of it is they don't actually *use* IPv6 internally or in their lab. We have been operating our network with IPv6 for many years now. I believe in most cases our connection to the management plane go IPv6 only as well. > > It's been fun to see the few SSH over IPv6 defects and other elements arise as time has passed, but those days are over. It's just tiring now and no longer amusing. (hey you kids, get off my lawn?). > Of course they're challenged. There's a finite amount of dev they can do at any one time, and they go for what is going to make revenue. If you tell them that the way to your wallet is to implement some new feature in v4 and you're not emphatic that it be v6 also, they are going to do the utterly predictable thing. If you really want to make progress instead of bellyache, list off the features you need to run your network. Better yet, deploy v6 instead of saying that you'll only do it when it's perfect. That just tells your account critter that v6 isn't important to you. I'll bet you'll find features that you want that are v6 specific that you'd open your wallet for *way* before features that don't interest you that you're requiring in the name of parity. Mike From Davis.Beeman at integratelecom.com Tue Sep 18 16:01:14 2012 From: Davis.Beeman at integratelecom.com (Beeman, Davis) Date: Tue, 18 Sep 2012 16:01:14 +0000 Subject: IPv6 Ignorance In-Reply-To: <548DEE97-B1C4-440B-B3CA-8812428067B8@delong.com> References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <50571759.5050704@illuminati.org> <50573F5C.5090509@matthew.at> <82596E95-9C32-46BB-8B27-CB18290392C0@delong.com> <20120917195433.GM9750@leitl.org> <548DEE97-B1C4-440B-B3CA-8812428067B8@delong.com> Message-ID: <2AF841AB78217140A2A394B2BB6D39C501128733@IDCPRDMBX1.ads.integratelecom.com> Orbits may not be important to this calculation, but just doing some quick head math, I believe large skyscrapers could already have close to this concentration of addresses, if you reduce them down to flat earth surface area. The point here is that breaking out the math based on the surface area of the earth is silly, as we do not utilize the surface of the earth in a flat manner... Davis Beeman > On Mon, Sep 17, 2012 at 11:27:04AM -0700, Owen DeLong wrote: > >> What technology are you planning to deploy that will consume more than 2 addresses per square cm? > > Easy. Think volume (as in: orbit), and think um^3 for a functional > computers ;) I meant real-world application. Orbits are limited due to the required combination of speed and altitude. There are a limited number of achievable altitudes and collision avoidance also creates interesting problems in time-slotting for orbits which are not geostationary. Geostationary orbits are currently limited to one object per degree of earth surface, and even at 4x that, you could give every satellite a /48 and still not burn through a /32. Owen From dwood at vaul-tec.net Tue Sep 18 16:18:50 2012 From: dwood at vaul-tec.net (Dan Wood) Date: Tue, 18 Sep 2012 11:18:50 -0500 Subject: IPv6 Ignorance In-Reply-To: <2AF841AB78217140A2A394B2BB6D39C501128733@IDCPRDMBX1.ads.integratelecom.com> References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <50571759.5050704@illuminati.org> <50573F5C.5090509@matthew.at> <82596E95-9C32-46BB-8B27-CB18290392C0@delong.com> <20120917195433.GM9750@leitl.org> <548DEE97-B1C4-440B-B3CA-8812428067B8@delong.com> <2AF841AB78217140A2A394B2BB6D39C501128733@IDCPRDMBX1.ads.integratelecom.com> Message-ID: H On Sep 18, 2012, at 11:01 AM, "Beeman, Davis" wrote: > Orbits may not be important to this calculation, but just doing some quick head math, I believe large skyscrapers could already have close to this concentration of addresses, if you reduce them down to flat earth surface area. The point here is that breaking out the math based on the surface area of the earth is silly, as we do not utilize the surface of the earth in a flat manner... > > Davis Beeman > > >> On Mon, Sep 17, 2012 at 11:27:04AM -0700, Owen DeLong wrote: >> >>> What technology are you planning to deploy that will consume more than 2 addresses per square cm? >> >> Easy. Think volume (as in: orbit), and think um^3 for a functional >> computers ;) > > I meant real-world application. > > Orbits are limited due to the required combination of speed and altitude. There are a limited number of achievable altitudes and collision avoidance also creates interesting problems in time-slotting for orbits which are not geostationary. > > Geostationary orbits are currently limited to one object per degree of earth surface, and even at 4x that, you could give every satellite a /48 and still not burn through a /32. > > Owen I wonder if the medical applications of addressing each cell isn't too far off. One could individually group each organ and system in a separate /48 and potentially get a /32... Just imagine the fun of that OID tree. -- Dan Wood From jason at thebaughers.com Tue Sep 18 16:38:07 2012 From: jason at thebaughers.com (Jason Baugher) Date: Tue, 18 Sep 2012 11:38:07 -0500 Subject: IPv6 Ignorance In-Reply-To: <2AF841AB78217140A2A394B2BB6D39C501128733@IDCPRDMBX1.ads.integratelecom.com> References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <50571759.5050704@illuminati.org> <50573F5C.5090509@matthew.at> <82596E95-9C32-46BB-8B27-CB18290392C0@delong.com> <20120917195433.GM9750@leitl.org> <548DEE97-B1C4-440B-B3CA-8812428067B8@delong.com> <2AF841AB78217140A2A394B2BB6D39C501128733@IDCPRDMBX1.ads.integratelecom.com> Message-ID: <5058A36F.1090102@thebaughers.com> On 9/18/2012 11:01 AM, Beeman, Davis wrote: > Orbits may not be important to this calculation, but just doing some quick head math, I believe large skyscrapers could already have close to this concentration of addresses, if you reduce them down to flat earth surface area. The point here is that breaking out the math based on the surface area of the earth is silly, as we do not utilize the surface of the earth in a flat manner... > > Davis Beeman > > >> On Mon, Sep 17, 2012 at 11:27:04AM -0700, Owen DeLong wrote: >> >>> What technology are you planning to deploy that will consume more than 2 addresses per square cm? >> Easy. Think volume (as in: orbit), and think um^3 for a functional >> computers ;) > I meant real-world application. > > Orbits are limited due to the required combination of speed and altitude. There are a limited number of achievable altitudes and collision avoidance also creates interesting problems in time-slotting for orbits which are not geostationary. > > Geostationary orbits are currently limited to one object per degree of earth surface, and even at 4x that, you could give every satellite a /48 and still not burn through a /32. > > Owen > > > What about network-based objects outside of our orbit? If we're talking about IPv6 in the long-term, I think we have to assume we'll have networked devices on the moon or at other locations in space. Jason From george.herbert at gmail.com Tue Sep 18 16:39:53 2012 From: george.herbert at gmail.com (George Herbert) Date: Tue, 18 Sep 2012 09:39:53 -0700 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <20120918153612.17528.qmail@joyce.lan> References: <20120918153612.17528.qmail@joyce.lan> Message-ID: <302CC3C2-400A-49FD-9231-575271D86266@gmail.com> I'm having problems finding any announcements for this net 10/8, too. Can someone talk to these "IANA" folks about reclaiming it, too? They have a bunch of other space in 172.x they should be able to use... George William Herbert Sent from my iPhone On Sep 18, 2012, at 8:36 AM, "John Levine" wrote: >> John Graham-Cumming, who found this unused block, wrote in a blog post that >> the DWP was in possession of 51.0.0.0/8 IPv4 addresses. > > > Please, don't anyone tell him about 25/8. > > From james.cutler at consultant.com Tue Sep 18 16:47:38 2012 From: james.cutler at consultant.com (Cutler James R) Date: Tue, 18 Sep 2012 12:47:38 -0400 Subject: IPv6 Ignorance In-Reply-To: <5058A36F.1090102@thebaughers.com> References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <50571759.5050704@illuminati.org> <50573F5C.5090509@matthew.at> <82596E95-9C32-46BB-8B27-CB18290392C0@delong.com> <20120917195433.GM9750@leitl.org> <548DEE97-B1C4-440B-B3CA-8812428067B8@delong.com> <2AF841AB78217140A2A394B2BB6D39C501128733@IDCPRDMBX1.ads.integratelecom.com> <5058A36F.1090102@thebaughers.com> Message-ID: <1FEE9485-B405-463E-8CBB-31396B21A51D@consultant.com> On Sep 18, 2012, at 12:38 PM, Jason Baugher wrote: > > What about network-based objects outside of our orbit? If we're talking about IPv6 in the long-term, I think we have to assume we'll have networked devices on the moon or at other locations in space. > > Jason Practical considerations (mostly latency issues) tend to minimize real-time point-to-point connections in these scenarios. I would expect that messaging/relay gateways would play a significant role in Really-Wide Area Networking. This would move inter-networking largely to an application layer, not the network layer. Thus, worrying about Layer 3 addressing limits is probably moot and just a fun waste of NANOG list bandwidth. James R. Cutler james.cutler at consultant.com From seth.mos at dds.nl Tue Sep 18 16:47:44 2012 From: seth.mos at dds.nl (Seth Mos) Date: Tue, 18 Sep 2012 18:47:44 +0200 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <302CC3C2-400A-49FD-9231-575271D86266@gmail.com> References: <20120918153612.17528.qmail@joyce.lan> <302CC3C2-400A-49FD-9231-575271D86266@gmail.com> Message-ID: <0680AA4D-B818-495E-A888-B3833DDE2AD9@dds.nl> Op 18 sep 2012, om 18:39 heeft George Herbert het volgende geschreven: > > I'm having problems finding any announcements for this net 10/8, too. Can someone talk to these "IANA" folks about reclaiming it, too? They have a bunch of other space in 172.x they should be able to use... Don't worry, they'll give in and assign us some more. Seth ;-) > > > George William Herbert > Sent from my iPhone > > On Sep 18, 2012, at 8:36 AM, "John Levine" wrote: > >>> John Graham-Cumming, who found this unused block, wrote in a blog post that >>> the DWP was in possession of 51.0.0.0/8 IPv4 addresses. >> >> >> Please, don't anyone tell him about 25/8. >> >> > From baconzombie at gmail.com Tue Sep 18 16:51:31 2012 From: baconzombie at gmail.com (Bacon Zombie) Date: Tue, 18 Sep 2012 17:51:31 +0100 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <302CC3C2-400A-49FD-9231-575271D86266@gmail.com> References: <20120918153612.17528.qmail@joyce.lan> <302CC3C2-400A-49FD-9231-575271D86266@gmail.com> Message-ID: Well 172.0.0.0 to 172.15.255.255 is now owned by AT&T and they have live systems on some of them already. On 18 September 2012 17:39, George Herbert wrote: > > I'm having problems finding any announcements for this net 10/8, too. Can someone talk to these "IANA" folks about reclaiming it, too? They have a bunch of other space in 172.x they should be able to use... > > > George William Herbert > Sent from my iPhone > > On Sep 18, 2012, at 8:36 AM, "John Levine" wrote: > >>> John Graham-Cumming, who found this unused block, wrote in a blog post that >>> the DWP was in possession of 51.0.0.0/8 IPv4 addresses. >> >> >> Please, don't anyone tell him about 25/8. >> >> > -- ???????????????????? ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ??????????????????????????????????????????????????????????????????????????????????? BaconZombie LOAD "*",8,1 From jason at thebaughers.com Tue Sep 18 16:57:34 2012 From: jason at thebaughers.com (Jason Baugher) Date: Tue, 18 Sep 2012 11:57:34 -0500 Subject: IPv6 Ignorance In-Reply-To: <1FEE9485-B405-463E-8CBB-31396B21A51D@consultant.com> References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <50571759.5050704@illuminati.org> <50573F5C.5090509@matthew.at> <82596E95-9C32-46BB-8B27-CB18290392C0@delong.com> <20120917195433.GM9750@leitl.org> <548DEE97-B1C4-440B-B3CA-8812428067B8@delong.com> <2AF841AB78217140A2A394B2BB6D39C501128733@IDCPRDMBX1.ads.integratelecom.com> <5058A36F.1090102@thebaughers.com> <1FEE9485-B405-463E-8CBB-31396B21A51D@consultant.com> Message-ID: <5058A7FE.2070107@thebaughers.com> On 9/18/2012 11:47 AM, Cutler James R wrote: > On Sep 18, 2012, at 12:38 PM, Jason Baugher wrote: >> What about network-based objects outside of our orbit? If we're talking about IPv6 in the long-term, I think we have to assume we'll have networked devices on the moon or at other locations in space. >> >> Jason > Practical considerations (mostly latency issues) tend to minimize real-time point-to-point connections in these scenarios. I would expect that messaging/relay gateways would play a significant role in Really-Wide Area Networking. This would move inter-networking largely to an application layer, not the network layer. Thus, worrying about Layer 3 addressing limits is probably moot and just a fun waste of NANOG list bandwidth. > > > James R. Cutler > james.cutler at consultant.com > Considering the rather extensive discussion on this list of using quantum entanglement as a possible future communications medium that would nearly eliminate latency, I don't see how my comment is moot or a waste. Jason From james.cutler at consultant.com Tue Sep 18 17:07:15 2012 From: james.cutler at consultant.com (Cutler James R) Date: Tue, 18 Sep 2012 13:07:15 -0400 Subject: IPv6 Ignorance In-Reply-To: <5058A7FE.2070107@thebaughers.com> References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <50571759.5050704@illuminati.org> <50573F5C.5090509@matthew.at> <82596E95-9C32-46BB-8B27-CB18290392C0@delong.com> <20120917195433.GM9750@leitl.org> <548DEE97-B1C4-440B-B3CA-8812428067B8@delong.com> <2AF841AB78217140A2A394B2BB6D39C501128733@IDCPRDMBX1.ads.integratelecom.com> <5058A36F.1090102@thebaughers.com> <1FEE9485-B405-463E-8CBB-31396B21A51D@consultant.com> <5058A7FE.2070107@thebaughers.com> Message-ID: <466915B8-AD52-4DAD-A6FC-6EE0F1375ACE@consultant.com> On Sep 18, 2012, at 12:57 PM, Jason Baugher wrote: > On 9/18/2012 11:47 AM, Cutler James R wrote: >> On Sep 18, 2012, at 12:38 PM, Jason Baugher wrote: >>> What about network-based objects outside of our orbit? If we're talking about IPv6 in the long-term, I think we have to assume we'll have networked devices on the moon or at other locations in space. >>> >>> Jason >> Practical considerations (mostly latency issues) tend to minimize real-time point-to-point connections in these scenarios. I would expect that messaging/relay gateways would play a significant role in Really-Wide Area Networking. This would move inter-networking largely to an application layer, not the network layer. Thus, worrying about Layer 3 addressing limits is probably moot and just a fun waste of NANOG list bandwidth. >> >> >> James R. Cutler >> james.cutler at consultant.com >> > Considering the rather extensive discussion on this list of using quantum entanglement as a possible future communications medium that would nearly eliminate latency, I don't see how my comment is moot or a waste. > > Jason Recent work (http://www.quantum.at/quest) has not yet established success over interplanetary distances. Other recent results from aircraft (http://www.extremetech.com/extreme/136312-first-air-to-ground-quantum-network-created-transmits-quantum-crypto-keys) show throughput results in relatively small bits per second. I'll reserve retraction for another year or so. From jason at thebaughers.com Tue Sep 18 17:21:19 2012 From: jason at thebaughers.com (Jason Baugher) Date: Tue, 18 Sep 2012 12:21:19 -0500 Subject: IPv6 Ignorance In-Reply-To: <466915B8-AD52-4DAD-A6FC-6EE0F1375ACE@consultant.com> References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <50571759.5050704@illuminati.org> <50573F5C.5090509@matthew.at> <82596E95-9C32-46BB-8B27-CB18290392C0@delong.com> <20120917195433.GM9750@leitl.org> <548DEE97-B1C4-440B-B3CA-8812428067B8@delong.com> <2AF841AB78217140A2A394B2BB6D39C501128733@IDCPRDMBX1.ads.integratelecom.com> <5058A36F.1090102@thebaughers.com> <1FEE9485-B405-463E-8CBB-31396B21A51D@consultant.com> <5058A7FE.2070107@thebaughers.com> <466915B8-AD52-4DAD-A6FC-6EE0F1375ACE@consultant.com> Message-ID: <5058AD8F.5080508@thebaughers.com> On 9/18/2012 12:07 PM, Cutler James R wrote: > On Sep 18, 2012, at 12:57 PM, Jason Baugher wrote: >> On 9/18/2012 11:47 AM, Cutler James R wrote: >>> On Sep 18, 2012, at 12:38 PM, Jason Baugher wrote: >>>> What about network-based objects outside of our orbit? If we're talking about IPv6 in the long-term, I think we have to assume we'll have networked devices on the moon or at other locations in space. >>>> >>>> Jason >>> Practical considerations (mostly latency issues) tend to minimize real-time point-to-point connections in these scenarios. I would expect that messaging/relay gateways would play a significant role in Really-Wide Area Networking. This would move inter-networking largely to an application layer, not the network layer. Thus, worrying about Layer 3 addressing limits is probably moot and just a fun waste of NANOG list bandwidth. >>> >>> >>> James R. Cutler >>> james.cutler at consultant.com >>> >> Considering the rather extensive discussion on this list of using quantum entanglement as a possible future communications medium that would nearly eliminate latency, I don't see how my comment is moot or a waste. >> >> Jason > Recent work (http://www.quantum.at/quest) has not yet established success over interplanetary distances. Other recent results from aircraft (http://www.extremetech.com/extreme/136312-first-air-to-ground-quantum-network-created-transmits-quantum-crypto-keys) show throughput results in relatively small bits per second. I'll reserve retraction for another year or so. > And last time I checked, IPv6 wasn't supposed to be designed to last for just another year or so. If we're expecting any kind of longevity out of IPv6, we need to expect that technology will solve these problems and plan for it. I'd rather not be sitting here 10 years from now wondering why I'm dual-stacking IPv7 on top of IPv6 because we didn't plan far enough ahead. Jason From joe at nethead.com Tue Sep 18 17:55:10 2012 From: joe at nethead.com (Joe Hamelin) Date: Tue, 18 Sep 2012 10:55:10 -0700 Subject: IPv6 Ignorance In-Reply-To: <1FEE9485-B405-463E-8CBB-31396B21A51D@consultant.com> References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <50571759.5050704@illuminati.org> <50573F5C.5090509@matthew.at> <82596E95-9C32-46BB-8B27-CB18290392C0@delong.com> <20120917195433.GM9750@leitl.org> <548DEE97-B1C4-440B-B3CA-8812428067B8@delong.com> <2AF841AB78217140A2A394B2BB6D39C501128733@IDCPRDMBX1.ads.integratelecom.com> <5058A36F.1090102@thebaughers.com> <1FEE9485-B405-463E-8CBB-31396B21A51D@consultant.com> Message-ID: >On Tue, Sep 18, 2012 at 9:47 AM, Cutler James R wrote: > ...waste of NANOG list bandwidth. I sure get a chuckle when I read this on a list for people that swing around 10Gb/s pipes all day. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > > From james.cutler at consultant.com Tue Sep 18 18:15:36 2012 From: james.cutler at consultant.com (Cutler James R) Date: Tue, 18 Sep 2012 14:15:36 -0400 Subject: IPv6 Ignorance In-Reply-To: References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <50571759.5050704@illuminati.org> <50573F5C.5090509@matthew.at> <82596E95-9C32-46BB-8B27-CB18290392C0@delong.com> <20120917195433.GM9750@leitl.org> <548DEE97-B1C4-440B-B3CA-8812428067B8@delong.com> <2AF841AB78217140A2A394B2BB6D39C501128733@IDCPRDMBX1.ads.integratelecom.com> <5058A36F.1090102@thebaughers.com> <1FEE9485-B405-463E-8CBB-31396B21A51D@consultant.com> Message-ID: <286287CB-2B79-4B79-B31E-77DF64E8AF3E@consultant.com> On Sep 18, 2012, at 1:55 PM, Joe Hamelin wrote: > >On Tue, Sep 18, 2012 at 9:47 AM, Cutler James R wrote: > > ...waste of NANOG list bandwidth. > > I sure get a chuckle when I read this on a list for people that swing around 10Gb/s pipes all day. That's why I included a word you omitted from the quote -- ?fun waste of NANOG list bandwidth. Works for me. Works for you. James R. Cutler james.cutler at consultant.com From eugen at leitl.org Tue Sep 18 19:02:58 2012 From: eugen at leitl.org (Eugen Leitl) Date: Tue, 18 Sep 2012 21:02:58 +0200 Subject: IPv6 Ignorance In-Reply-To: <5058A7FE.2070107@thebaughers.com> References: <50571759.5050704@illuminati.org> <50573F5C.5090509@matthew.at> <82596E95-9C32-46BB-8B27-CB18290392C0@delong.com> <20120917195433.GM9750@leitl.org> <548DEE97-B1C4-440B-B3CA-8812428067B8@delong.com> <2AF841AB78217140A2A394B2BB6D39C501128733@IDCPRDMBX1.ads.integratelecom.com> <5058A36F.1090102@thebaughers.com> <1FEE9485-B405-463E-8CBB-31396B21A51D@consultant.com> <5058A7FE.2070107@thebaughers.com> Message-ID: <20120918190258.GD9750@leitl.org> On Tue, Sep 18, 2012 at 11:57:34AM -0500, Jason Baugher wrote: > Considering the rather extensive discussion on this list of using > quantum entanglement as a possible future communications medium that > would nearly eliminate latency, I don't see how my comment is moot or a > waste. You need a relativistic channel to be able to tell quantum signal from randomness. From askoorb+nanog at gmail.com Tue Sep 18 19:28:06 2012 From: askoorb+nanog at gmail.com (Alex Brooks) Date: Tue, 18 Sep 2012 20:28:06 +0100 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <50588289.4090904@prt.org> References: <20120918140712.GF9750@leitl.org> <50588289.4090904@prt.org> Message-ID: On Tue, Sep 18, 2012 at 3:17 PM, Paul Thornton wrote: > On 18/09/2012 15:07, Eugen Leitl wrote: >> >> >> >> http://paritynews.com/network/item/325-department-of-work-and-pensions-uk-in-possession-of-169-million-unused-ipv4-addresses >> >> Department of Work and Pensions UK in Possession of 16.9 Million Unused >> IPv4 >> Addresses > > > The only slight snag in his argument is that the addresses are not unused. > Not announced != Not used. And for the definitive answer on this block, the official response is: http://www.whatdotheyknow.com/request/internet_protocol_ipv4_address_a and http://www.whatdotheyknow.com/request/internet_protocol_ipv4_address_a_2 >1. We can confirm that the address block is assigned to the DWP. > >2. In principle, none of the address space is exposed to the public Internet. >There may be a very small number of addresses that have been exposed for >specific purposes, but certainly no significant block of addresses is visible >from the public Internet. > >3. The address space is already shared across government. We have used or >allocated approximately 80% of the address space, and have earmarked the >remaining space for use within the proposed Public Services Network (PSN). >The PSN is building an Internet for government, and the DWP address space >is a key building block for delivery of this. > >4. DWP have no plans to release any of the address space for use on the public >Internet. The cost and complexity of re-addressing the existing government >estate is too high to make this a viable proposition. DWP are aware that the >worldwide IPv4 address space is almost exhausted, but knows that in the >short to medium term there are mechanisms available to ISPs that will allow >continued expansion of the Internet, and believes that in the long term a >transition to IPv6 will resolve address exhaustion. Note that even if DWP were >able to release their address space, this would only delay IPv4 address >exhaustion by a number of months. And for 25.0.0.0 to 25.255.255.255 the response from the Ministry of Defense is: >I can confirm that the IPv4 address block about which you enquire is assigned to and >owned by the MOD; however, I should point out that within this block, none of the >addresses or address ranges are in use on the public internet for departmental IT, >communications or other functions. To date, we estimate that around 60% of the IPv4 >address block has been allocated for internal use. As I am sure you will appreciate, the >volume and complexity of the Information Systems used by the Armed Forces supporting >military operations and for training continues to develop and grow. We are aware that the >allocation of IPv4 addresses are becoming exhausted, and the issue has been recognised >within the Department as a potential future IS risk. >In summary, therefore, we are unable to consider releasing parts of the address block that >has been allocated to the UKMOD for reassignment to non-UK Government organisations. From jrhett at netconsonance.com Tue Sep 18 20:03:00 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 18 Sep 2012 13:03:00 -0700 Subject: Big Temporary Networks In-Reply-To: <11570158.24452.1347546545009.JavaMail.root@benjamin.baylink.com> References: <11570158.24452.1347546545009.JavaMail.root@benjamin.baylink.com> Message-ID: <2244FE60-F7D6-42B5-8AAB-AA9F569DA169@netconsonance.com> On Sep 13, 2012, at 7:29 AM, Jay Ashworth wrote: > I'm talking to the people who will probably be, in 2015, running the first > Worldcon I can practically drive to, in Orlando, at -- I think -- the Disney > World Resort. I've told them how critical the issue is for this market; they, > predictably, replied "We look forward to your patch". :-} So I just want to point out that this is an utterly irrelevant topic. Worldcon is full to the brim with really smart people who can build good networks, but in every place large enough to host a Worldcon the owners of the building make money selling Internet access and don't want competition. The very best we've been able to do was create an Internet Lounge with good connectivity, and even that isn't acceptable at most locations. So this really is an irrelevant topic, unless you want to create an LTE network with good connectivity near the location and sell bandwidth via that. (Phones and tablets outnumber laptop computers by a facter of 20:1 at scifi conventions) Off-topic: FWIW Hellsinki is a hell of a lot more likely. Remember that the membership votes on where to go, and Orlando really doesn't top anyone's list. Especially since Orlando keeps blowing off the very legitimate concerns that other people have raised about the location, including that Disney takes a dim view of anyone except their own paid actors wearing costumes, and more importantly the lack of inexpensive food options. If for some reason Hellsinki's bid falls apart, Spokane has better facilities and good LTE network support. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. From alex at corp.nac.net Tue Sep 18 20:11:36 2012 From: alex at corp.nac.net (Alex Rubenstein) Date: Tue, 18 Sep 2012 16:11:36 -0400 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: References: <20120918140712.GF9750@leitl.org> <50588289.4090904@prt.org> Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB81A9017B5EC@EXCHMBX.hq.nac.net> > The only slight snag in his argument is that the addresses are not unused. > Not announced != Not used. And for the definitive answer on this block, the official response is: http://www.whatdotheyknow.com/request/internet_protocol_ipv4_address_a and http://www.whatdotheyknow.com/request/internet_protocol_ipv4_address_a_2 This is astounding. Are we really to believe that the UK Defense folks are using 60% of a /8 - about 10,066,000 addresses? Even if every sub-allocation within that 60% were only 50% utilized, that would be over 5,000,000 addresses. Internally Allocated != used And someone should further alert him that they do not "own" these addresses. From jrhett at netconsonance.com Tue Sep 18 20:11:40 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 18 Sep 2012 13:11:40 -0700 Subject: Big Temporary Networks In-Reply-To: <31256570.24866.1347637981269.JavaMail.root@benjamin.baylink.com> References: <31256570.24866.1347637981269.JavaMail.root@benjamin.baylink.com> Message-ID: <1B673D9D-0BE1-4210-92E7-A5907A43C67D@netconsonance.com> On Sep 14, 2012, at 8:53 AM, Jay Ashworth wrote: >> Tech had a person managing the feed to DragonCon from the dedicated >> room w/ the polycomm video conference system, for panels, in addition >> to the actual union operator of the camera & such. > > The camera ops had to be union? Hmmm. Ah, Chicago. Yes. That has been true everywhere that Worldcon has been for a number of years, excluding Japan. Hotel union contracts generally forbid activity being done by any non-union people, even if they are the guests. > Yes, and I'm told by my best friend who did attend (I didn't make it > this year) that the hotel wired/wifi was essentially unusable, every > time he tried. Hence my interest in the issue. Always is. Those networks are not built for that many devices attaching. They never are. But they don't want the competition either. If you NEED connectivity at the convention, you must bring your own LTE MIFI and take care of yourself. This is simply not solvable in the convention hotel contracts level. I've got many SMOF friends and I've been trying for years, and it only worked for a small gap of years before hotels starting seeing Internet as a profit vector. Unfortunately, the size requirements of things the size of Worldcon limit the choices enough that this simply can't be a bargaining point. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. From jrhett at netconsonance.com Tue Sep 18 20:19:00 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 18 Sep 2012 13:19:00 -0700 Subject: Big Temporary Networks In-Reply-To: <10203926.24928.1347656101231.JavaMail.root@benjamin.baylink.com> References: <10203926.24928.1347656101231.JavaMail.root@benjamin.baylink.com> Message-ID: On Sep 14, 2012, at 1:55 PM, Jay Ashworth wrote: > That's an interesting question indeed. The optimal solution here, of > course, would be for Worldcons -- which are planned 3-4 years in advance -- > to get the right technical people in the loop with the property to see > when in the next 2 years (after a bid is confirmed) they plan to upgrade > the networking they have now... and make sure it will tolerate a "real" > worst case. The business case for the property, of course, is that > they're more salable to large technical conferences -- which makes them > more money. Question is, is it enough. Those people are already in the loop. Hi. Nice to see you again, Jay :) Unfortunately, as I've said in the previous two messages, it simply isn't something that can be changed. If you are running a small convention that can fit into a dozen hotels in the city, you can make them compete on multiple levels including network. Since there are less than 4 cities in the world who could host a worldcon in more than one facility, there's zero competition. * And frankly, the hotel contracts people have bigger problems to solve--namely, getting to use metric tons of convention floor space without paying much, if any money. Worldcon memberships are $150 each unless you wait until the last minute. This is a problem that large technical conferences with thousand dollar memberships can solve. They have money to throw at the hotel. Not fan-run conventions whose entire budget is less than the spare capital that Usenix keeps in their account. (I've seen both and can state this as a positive fact.) * The one place that competition can occur is in the bidding process. Part of what we all ask bid committees is about the network access at the location. And we vote based on what we can find out. However, the number of us who vote that way are fairly small, as most attendees have other priorities like inexpensive food options, cheaper hotel options, etc. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. From bill at herrin.us Tue Sep 18 20:24:22 2012 From: bill at herrin.us (William Herrin) Date: Tue, 18 Sep 2012 16:24:22 -0400 Subject: Big Temporary Networks In-Reply-To: <50586620.6080702@necom830.hpcl.titech.ac.jp> References: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> <50561ADD.2040404@necom830.hpcl.titech.ac.jp> <505626A2.1090700@foobar.org> <505663DE.7000309@necom830.hpcl.titech.ac.jp> <50586620.6080702@necom830.hpcl.titech.ac.jp> Message-ID: On Tue, Sep 18, 2012 at 8:16 AM, Masataka Ohta wrote: > William Herrin wrote: >> In IPv6, the station sends an ICMPv6 router solicitation instead of an >> ARP for the default gateway. This is a multicast message but since >> it's from the station to the AP it's subject to layer 2 error recovery >> by the 802.11 protocol. The default gateway sends back a router >> advertisement (unicast since its responding to a solicitation) > > Unicast since its responding to a solicitation? > > RFC4861 states: > > A router MAY choose to unicast the > response directly to the soliciting host's address (if the > solicitation's source address is not the unspecified address), but > the usual case is to multicast the response to the all-nodes group. Ah, okay. So the IPv6 router usually responds to router discovery with multicast where arp would have responded with unicast. This multicast message is not subject to 802.11's layer 2 error recovery so as previously discussed it has a high probability of being lost during some relatively ordinary wifi usage scenarios. But correct me if I'm wrong: the router advertisement daemon could be altered to reply with unicast without changing the standard, right? What do the radvd and rtadvd developers say about this when confronted with the 802.11 multicast problem? Are there any Internet drafts active in the IETF to replace that "MAY" with a "SHOULD," noting that replying with multicast can defeat layer 2 error recovery needed for the successful use of some layer 1 media? >> What did I >> miss? Where does IPv6 take the bad turn that IPv4 avoided? > > If you still want to defend IPv6, you must say multicast RA and > DAD are unnecessary features of IPv6, which means the current > IPv6 is broken. I have no interest in defending IPv6. We're network operators here. You just told us (and offered convincing reasoning) that when selecting a router vendor for use with an IPv6 wifi network, one of our evaluation check boxes should should be, "Responds to ICMPv6 router solicitation with a unicast message? Yes or Fail." And when we provide the list of deficiencies to our vendor and wave the wad of cash around, one of them should be, "Responds to ICMPv6 router solicitations with a multicast packet - unreliable in a wifi environment." That's strikes me as something valuable to know. Far more valuable than, "Dood, IPv6 has problems on wifi networks." So, let's keep going. IPv6 falls down compared to IPv4 on wifi networks when it responds to a router solicitation with a multicast (instead of unicast) router advertisement. Where else does it fall down compared to the equivalent behavior in an IPv4 wifi network? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From nick at foobar.org Tue Sep 18 20:31:15 2012 From: nick at foobar.org (Nick Hilliard) Date: Tue, 18 Sep 2012 21:31:15 +0100 Subject: Big Temporary Networks In-Reply-To: References: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> <50561ADD.2040404@necom830.hpcl.titech.ac.jp> <505626A2.1090700@foobar.org> <505663DE.7000309@necom830.hpcl.titech.ac.jp> <50586620.6080702@necom830.hpcl.titech.ac.jp> Message-ID: <5058DA13.90000@foobar.org> On 18/09/2012 21:24, William Herrin wrote: > IPv6 falls down compared to IPv4 on wifi networks when it responds to a > router solicitation with a multicast (instead of unicast) router > advertisement. You mean it has one extra potential failure mode in situations where radio retransmission doesn't deal with the packet loss - which will cause RA to retry. "Fall down" is a slight overstatement. Nick From bill at herrin.us Tue Sep 18 20:47:34 2012 From: bill at herrin.us (William Herrin) Date: Tue, 18 Sep 2012 16:47:34 -0400 Subject: Big Temporary Networks In-Reply-To: <1B673D9D-0BE1-4210-92E7-A5907A43C67D@netconsonance.com> References: <31256570.24866.1347637981269.JavaMail.root@benjamin.baylink.com> <1B673D9D-0BE1-4210-92E7-A5907A43C67D@netconsonance.com> Message-ID: On Tue, Sep 18, 2012 at 4:11 PM, Jo Rhett wrote: > On Sep 14, 2012, at 8:53 AM, Jay Ashworth wrote: >>> Tech had a person managing the feed to DragonCon from the dedicated >>> room w/ the polycomm video conference system, for panels, in addition >>> to the actual union operator of the camera & such. >> >> The camera ops had to be union? Hmmm. Ah, Chicago. Yes. > > That has been true everywhere that Worldcon has been for a > number of years, excluding Japan. Hotel union contracts > generally forbid activity being done by any non-union people, > even if they are the guests. http://en.wikipedia.org/wiki/Right-to-work_law ''A "right-to-work" law is a statute that prohibits union security agreements, or agreements between labor unions and employers that govern the extent to which an established union can require employees' membership [...] as a condition of employment. Right-to-work laws exist in twenty-three U.S. states,'' Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Tue Sep 18 20:50:53 2012 From: bill at herrin.us (William Herrin) Date: Tue, 18 Sep 2012 16:50:53 -0400 Subject: Big Temporary Networks In-Reply-To: <5058DA13.90000@foobar.org> References: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> <50561ADD.2040404@necom830.hpcl.titech.ac.jp> <505626A2.1090700@foobar.org> <505663DE.7000309@necom830.hpcl.titech.ac.jp> <50586620.6080702@necom830.hpcl.titech.ac.jp> <5058DA13.90000@foobar.org> Message-ID: On Tue, Sep 18, 2012 at 4:31 PM, Nick Hilliard wrote: > On 18/09/2012 21:24, William Herrin wrote: >> IPv6 falls down compared to IPv4 on wifi networks when it responds to a >> router solicitation with a multicast (instead of unicast) router >> advertisement. > > You mean it has one extra potential failure mode in situations where radio > retransmission doesn't deal with the packet loss - which will cause RA to > retry. "Fall down" is a slight overstatement. Potayto, potahto. Like I said, I have no interest in defending IPv6. But I'm very interested in how to implement an IPv6 network that's as or more reliable than the equivalent IPv4 network. That makes me interested in the faults which get in the way. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From johnl at iecc.com Tue Sep 18 21:10:14 2012 From: johnl at iecc.com (John Levine) Date: 18 Sep 2012 21:10:14 -0000 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <2D0AF14BA6FB334988BC1F5D4FC38CB81A9017B5EC@EXCHMBX.hq.nac.net> Message-ID: <20120918211014.29054.qmail@joyce.lan> >And someone should further alert him that they do not "own" these addresses. MIT is probably using less of their /8 than MOD is, and as far as I know, MIT has neither commando forces nor nuclear weapons. You might want to pick, so to speak, your battles more carefully. R's, John From SNaslund at medline.com Tue Sep 18 21:12:39 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 18 Sep 2012 16:12:39 -0500 Subject: Big Temporary Networks In-Reply-To: References: <31256570.24866.1347637981269.JavaMail.root@benjamin.baylink.com> <1B673D9D-0BE1-4210-92E7-A5907A43C67D@netconsonance.com> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0C695DB2@MUNEXBE1.medline.com> The trick is that there is no "right to work" if you are a guest at the hotel. You have no right to work on their property without their consent. In reality, the hotels do not want union headaches so that is the way it goes. Right to work only is in effect if an employer hires me and I do not want to join the union. Steven Naslund -----Original Message----- From: William Herrin [mailto:bill at herrin.us] Sent: Tuesday, September 18, 2012 3:48 PM To: Jo Rhett Cc: NANOG Subject: Re: Big Temporary Networks On Tue, Sep 18, 2012 at 4:11 PM, Jo Rhett wrote: > On Sep 14, 2012, at 8:53 AM, Jay Ashworth wrote: >>> Tech had a person managing the feed to DragonCon from the dedicated >>> room w/ the polycomm video conference system, for panels, in >>> addition to the actual union operator of the camera & such. >> >> The camera ops had to be union? Hmmm. Ah, Chicago. Yes. > > That has been true everywhere that Worldcon has been for a number of > years, excluding Japan. Hotel union contracts generally forbid > activity being done by any non-union people, even if they are the > guests. http://en.wikipedia.org/wiki/Right-to-work_law ''A "right-to-work" law is a statute that prohibits union security agreements, or agreements between labor unions and employers that govern the extent to which an established union can require employees' membership [...] as a condition of employment. Right-to-work laws exist in twenty-three U.S. states,'' Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Tue Sep 18 21:38:57 2012 From: bill at herrin.us (William Herrin) Date: Tue, 18 Sep 2012 17:38:57 -0400 Subject: Big Temporary Networks In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0C695DB2@MUNEXBE1.medline.com> References: <31256570.24866.1347637981269.JavaMail.root@benjamin.baylink.com> <1B673D9D-0BE1-4210-92E7-A5907A43C67D@netconsonance.com> <2A76E400AC84B845AAC35AA19F8E7A5D0C695DB2@MUNEXBE1.medline.com> Message-ID: On Tue, Sep 18, 2012 at 5:12 PM, Naslund, Steve wrote: > The trick is that there is no "right to work" if you are a guest at the > hotel. You have no right to work on their property without their > consent. In reality, the hotels do not want union headaches so that is > the way it goes. IIRC when the Democatic National Convention was held in Denver in 2008, they had to strike a special deal with the venue to bring in union labor instead of the normal workers because they couldn't find a suitable place that was already union. Conversely, when I went to IETF in Minneapolis a few years ago the networking folks simply took over the hotel network for the week. IETF attendee or not, you got wired Internet in your room courtesy of the conference. As I understand it, they convinced the hotel with the simple expedient of paying what they would ordinarily earn from a week's Internet charges. My point is that blaming union contracts or union anything for being unable to find a place to hold a convention where you can implement the network you want to implement is nonsense. NANOG, ARIN and IETF conferences have all somehow managed to implement their own effective networks. Even in union towns. If Worldcon's site selection committee can't find a suitable host, that's their deficiency. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From scg at newnog.org Tue Sep 18 21:59:02 2012 From: scg at newnog.org (Steve Gibbard) Date: Tue, 18 Sep 2012 14:59:02 -0700 Subject: [NANOG-announce] Update on NANOG board and committee nomination process Message-ID: <27073B6C-83A5-4665-B7E6-9E1154330A30@newnog.org> I would like to remind everyone about some important dates that are coming up for the NANOG governance process: * September 17, 2012: The nomination process for NANOG Program Committee Candidates begins. * October 1, 2012 the nomination process for the NANOG Board of Directors closes. The NANOG Program Committee is a group of sixteen individuals from the NANOG community who together are responsible for the solicitation and selection of material for NANOG meeting programs. Per the NANOG bylaws, eligible candidates each will serve a two-year term. To be eligible to be appointed as a member of the Program Committee, an individual must have attended one NANOG conference within the prior calendar year (12 months) and be a member in good standing. Candidates should have a broad technical knowledge of Internet operations and be familiar with NANOG meetings. Having constructive opinions and ideas about how NANOG meetings might be improved is of high value. A willingness to recruit presentations for each meeting is required. Please send nominations to nominations at nanog.org. If you are nominating another person, please provide that person's name and email address. If you are nominating yourself, please provide a Statement of Intent and a Biography, each with a suggested limit of 150 words. For samples, please see the 2011 candidate lists (http://www.nanog.org/governance/elections/2011elections/). The NANOG Board of Directors is a group of six elected members and NANOG's Executive Director. The Board of Directors is responsible for and works closely with the Committee Chairs to promote, support, and improve NANOG. The Board is responsible for the selection of the Program Committee, the Communications Committee, and the Development Committee. The Board is responsible to the members ensuring that the NANOG organization remains, open, relevant, useful, and financially sound. Please read the Board Member Responsibilities (http://www.nanog.org/governance/BOD_Responsibilities.pdf) and NANOG bylaws (https://newnog.org/docs/newnog-bylaws-20110104.pdf) for a complete understanding of the expectations placed on Board Members. To ensure continuity on the Board, three seats out of six become open each year due to the expiration of 2-year terms. The Board members whose terms are expiring in October are: * Patrick Gilmore * Daniel Golding * Michael K. Smith Patrick has served two 2-year terms and cannot be considered for re-election until October 2013 (one year leave). Daniel is completing the term vacated in June 2012 and he can stand for re-election. Michael is completing the term vacated in August 2011 and he can stand for re-election. How do you Nominate? You can self-nominate. If you care about NANOG?s governance and want to take a turn at volunteering your time and expertise to help make it better: 1. Make sure you are a NANOG member in good standing 2. Submit your Declaration of Candidacy to elections at nanog.org. You can nominate others. 1. Send their contact information to elections at nanog.org 2. If they accept the nomination, they will be asked to become a NANOG member in good standing 3. They will have to submit their Declaration of Candidacy to elections at nanog.org. As always, if you have a questions, please email nominations at nanog.org. Thank you for your support, and your participation in the community. Thanks, Steve Gibbard for the NANOG Board _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From marka at isc.org Tue Sep 18 22:09:42 2012 From: marka at isc.org (Mark Andrews) Date: Wed, 19 Sep 2012 08:09:42 +1000 Subject: IPv6 Ignorance In-Reply-To: Your message of "Tue, 18 Sep 2012 09:21:46 -0400." <86lig7cvpw.fsf@seastrom.com> References: <50560464.8020906@rollernet.us> <86lig7cvpw.fsf@seastrom.com> Message-ID: <20120918220942.BB16825619C6@drugs.dv.isc.org> In message <86lig7cvpw.fsf at seastrom.com>, "Robert E. Seastrom" writes: > > Seth Mattinen writes: > > > I came across these threads today; the blind ignorance towards IPv6 from > > some of the posters is kind of shocking. > > There are actually a few good points mixed in there, like the guy who > observes that dual stacking is of limited utility if there are no v4 > addresses to be had. Dual stack w/ CGN for IPv4. That can be supplied a number of ways and it has more limitations for IPv4 that conventional CPE based NAT. Turning on dual stack, even at this late stage, lights up IPv6, moves most of the traffic to IPv6 so that CGN's don't need to be so beefy, and doesn't mean that you have to have perfect IPv6 everywhere when you turn on IPv6. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jrhett at netconsonance.com Tue Sep 18 22:14:37 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 18 Sep 2012 15:14:37 -0700 Subject: Big Temporary Networks In-Reply-To: References: <31256570.24866.1347637981269.JavaMail.root@benjamin.baylink.com> <1B673D9D-0BE1-4210-92E7-A5907A43C67D@netconsonance.com> Message-ID: <056EE50C-1EBF-4C7B-820A-5FC15BB1319C@netconsonance.com> NOTE: None of the following content can be typed into your router. It holds information only slightly relevant to networking. On Sep 18, 2012, at 1:47 PM, William Herrin wrote: >> That has been true everywhere that Worldcon has been for a >> number of years, excluding Japan. Hotel union contracts >> generally forbid activity being done by any non-union people, >> even if they are the guests. > > http://en.wikipedia.org/wiki/Right-to-work_law > > ''A "right-to-work" law is a statute that prohibits union security > agreements, or agreements between labor unions and employers that > govern the extent to which an established union can require employees' > membership [...] as a condition of employment. Right-to-work laws > exist in twenty-three U.S. states,'' Well, Bill, this starts the legal dance equivalent of "patches accepted", that being "you are welcome to sue against this with your own money". Not being aware of which states have this law, it's entirely possible that the intersection between states that have this law and states which have enough scifi fans willing to get together to host a worldcon is negligible. I can only recall ~9 states which have hosted a worldcon in the last 30 years. Checking the easily found references pages seems to confirm this although I didn't bother checking extensively. I'm closely associated and personal friends with people who have done the hotel negotiations for four of the recent worldcons, and on a first name basis with most of the others, and this union requirement has been a major problem with most if not all of them. Just getting a waiver to allow people to serve drinks in their own hotel rooms has been hard enough to break many bids. It is currently impossible in San Francisco due to hotel contracts, and part of why Worldcon will never return to San Francisco unless very unlikely changes happen. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. From morrowc.lists at gmail.com Tue Sep 18 22:17:48 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 18 Sep 2012 18:17:48 -0400 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <20120918211014.29054.qmail@joyce.lan> References: <2D0AF14BA6FB334988BC1F5D4FC38CB81A9017B5EC@EXCHMBX.hq.nac.net> <20120918211014.29054.qmail@joyce.lan> Message-ID: On Tue, Sep 18, 2012 at 5:10 PM, John Levine wrote: >>And someone should further alert him that they do not "own" these addresses. > > MIT is probably using less of their /8 than MOD is, and as far as I > know, MIT has neither commando forces nor nuclear weapons. > > You might want to pick, so to speak, your battles more carefully. more over, who cares? a /8 is less than 2 months rundown globally... and, once upon a time I constructed on this list a usecase for apple's /8 ... it's really not THAT hard to use a /8, it's well within the capabilities of a gov't to do so... especially given they PROBABLY have: o unclassified networks o secret networks o top secret networks o other networks I'm sure there's plenty of ways they could use the space in question. From bill at herrin.us Tue Sep 18 22:18:28 2012 From: bill at herrin.us (William Herrin) Date: Tue, 18 Sep 2012 18:18:28 -0400 Subject: IPv6 Ignorance In-Reply-To: <10390.1347982778@turing-police.cc.vt.edu> References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <5EF5A548-4A61-4F94-9BD5-C271C2D7347C@delong.com> <10390.1347982778@turing-police.cc.vt.edu> Message-ID: On Tue, Sep 18, 2012 at 11:39 AM, wrote: > On Tue, 18 Sep 2012 02:35:43 -0400, William Herrin said: > >> Then we need 32 bits to overlay the customer's IPv4 address for >> convenience within our 6RD network. > > Well yeah. You blow 32 bits for silly reasons, you run out of bits. Film at 11. Silly reason? Hardly! 6RD lets you deploy IPv6 immediately to all customers. It's a stateless tunnel. Direct the packets into an encapsulator and any customer who wants them need only catch them on their IPv4 address. Without you having to change out anything else in your network. Hitch is: if you have a whole lot of discontiguous IPv4 prefixes, sorting which maps to where in a compact IPv6 prefix is challenging. Much easier to just map the entire IPv4 space and be done with it. Poor plan. But much easier. On Tue, Sep 18, 2012 at 10:01 AM, Owen DeLong wrote: >> Then we need 32 bits to overlay the customer's IPv4 address for >> convenience within our 6RD network. So that leaves us 16 bits. But we >> don't want the native network to overlay the 6RD network because we >> want a real simple /16 route into the nearest 6rd encapsulator. And we >> don't want to advertise multiple BGP prefixes either. So we claim >> another bit and allocate our native infrastructure from the /16 that >> doesn't overlap the 6rd setup. > > No, you really don't. This absurdity (and the ridiculous design of 6RD) > are so problematic in this area that I cannot begin to describe what a > terrible idea it is. In http://lists.arin.net/pipermail/arin-ppml/2010-September/018180.html I complained about mapping the full 32-bits of IPv4 address into an IPv6 prefix. You responded, "You say that like it's somehow a bad thing," and "I'm simply not seeing a problem." Have you come around to my way of thinking that using 6RD with a full 32-bit IPv4 mapping is not such a hot idea? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bonomi at mail.r-bonomi.com Tue Sep 18 22:22:51 2012 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Tue, 18 Sep 2012 17:22:51 -0500 (CDT) Subject: Big Temporary Networks In-Reply-To: Message-ID: <201209182222.q8IMMptr045570@mail.r-bonomi.com> > From: William Herrin > Date: Tue, 18 Sep 2012 16:47:34 -0400 > Subject: Re: Big Temporary Networks > > On Tue, Sep 18, 2012 at 4:11 PM, Jo Rhett wrote: > > On Sep 14, 2012, at 8:53 AM, Jay Ashworth wrote: > >>> Tech had a person managing the feed to DragonCon from the dedicated > >>> room w/ the polycomm video conference system, for panels, in addition > >>> to the actual union operator of the camera & such. > >> > >> The camera ops had to be union? Hmmm. Ah, Chicago. Yes. > > > > That has been true everywhere that Worldcon has been for a > > number of years, excluding Japan. Hotel union contracts > > generally forbid activity being done by any non-union people, > > even if they are the guests. > > http://en.wikipedia.org/wiki/Right-to-work_law > > ''A "right-to-work" law is a statute that prohibits union security > agreements, or agreements between labor unions and employers that > govern the extent to which an established union can require employees' > membership [...] as a condition of employment. Right-to-work laws > exist in twenty-three U.S. states,'' 'Right to work', as defined by section 14 B of the Taft-Hartley Act, only prevents a union contract that requiures union membership as a PRE-REQUISITE for being hired. What is called 'closed shop' -- where employment is closed to those who are not union members. It does -not- prevent a 'union ship' -- where employees are required to join the union within a reasonable period =after= being hired. Right-to-work also does not prevent an organization from requiring, by contractual agreement, that third parties performing work ON THE 0ORGANIZATION'S PREMISES, employ "union labor" for _that_ work. It cannot specify _what_ union (or local) however. bTW, I'm a card-carrying member, and official, of the (independant) "Amalgamated Tinkerers and Gadgeteers", anyone interested in setting up their own local is invited to contact me. *GRIN* From jrhett at netconsonance.com Tue Sep 18 22:44:08 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 18 Sep 2012 15:44:08 -0700 Subject: Big Temporary Networks In-Reply-To: References: <31256570.24866.1347637981269.JavaMail.root@benjamin.baylink.com> <1B673D9D-0BE1-4210-92E7-A5907A43C67D@netconsonance.com> <2A76E400AC84B845AAC35AA19F8E7A5D0C695DB2@MUNEXBE1.medline.com> Message-ID: On Sep 18, 2012, at 2:38 PM, William Herrin wrote: > IIRC when the Democatic National Convention was held in Denver in > 2008, they had to strike a special deal with the venue to bring in > union labor instead of the normal workers because they couldn't find a > suitable place that was already union. I can provide people who can refute that, but I don't have (or care about) the details enough to bother quoting them. I can say that Worldcon was in Denver the proceeding week, and we could only get one hotel about a half mile from the convention center to allow us to serve drinks in our own rooms without a union person there to serve them. So I have personal experience to doubt your story. > Conversely, when I went to IETF in Minneapolis a few years ago the > networking folks simply took over the hotel network for the week. IETF > attendee or not, you got wired Internet in your room courtesy of the > conference. As I understand it, they convinced the hotel with the > simple expedient of paying what they would ordinarily earn from a > week's Internet charges. IETF is considerably smaller event that Worldcon, and as such can play ball with smaller hotels. Worldcons haven't fit into hotels in more than 20 years*, and must negotiate with the convention centers -- and are not able to leverage room nights in the balance. * They tried with the large Hyatt in Chicago this year and got the worst of both worlds. The rooms were overfull far beyond standing room only, and they still couldn't get a hotel contract with good internet, accessibility or issue handling. > My point is that blaming union contracts or union anything for being > unable to find a place to hold a convention where you can implement > the network you want to implement is nonsense. NANOG, ARIN and IETF > conferences have all somehow managed to implement their own effective > networks. Even in union towns. If Worldcon's site selection committee > can't find a suitable host, that's their deficiency. Money speaks here. The budgets for NANOG conferences are posted, as are some of the worldcon committee budgets. RTFM. And again, even though Worldcons have significantly less money, the largest Nanog ever was still smaller than the smallest worldcon in the last 20 years. Smaller == more choices of hotels == negotiating ability. Please stop trying to be a smartass about something you could research, but haven't bothered to do so. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. From bill at herrin.us Tue Sep 18 23:03:08 2012 From: bill at herrin.us (William Herrin) Date: Tue, 18 Sep 2012 19:03:08 -0400 Subject: Big Temporary Networks In-Reply-To: <056EE50C-1EBF-4C7B-820A-5FC15BB1319C@netconsonance.com> References: <31256570.24866.1347637981269.JavaMail.root@benjamin.baylink.com> <1B673D9D-0BE1-4210-92E7-A5907A43C67D@netconsonance.com> <056EE50C-1EBF-4C7B-820A-5FC15BB1319C@netconsonance.com> Message-ID: On Tue, Sep 18, 2012 at 6:14 PM, Jo Rhett wrote: > Not being aware of which states have this law, it's entirely possible that > the intersection between states that have this law and states which have > enough scifi fans willing to get together to host a worldcon is negligible. There were enough fans among the 600,000 folks in the Baltimore area but not enough an hour away among the 5,600,000 in the National Capital Region to justify hosting a Worldcon a couple miles inside the Virginia border where no unions would get in your way? Really? > I'm closely associated and personal friends with people who have done the > hotel negotiations for four of the recent worldcons, and on a first name > basis with most of the others, and this union requirement has been a major > problem with most if not all of them. Tell 'em to look in a right to work state. Like Florida. http://www.nrtw.org/rtws.htm > Just getting a waiver to allow people > to serve drinks in their own hotel rooms has been hard enough to break many > bids. It is currently impossible in San Francisco due to hotel contracts, > and part of why Worldcon will never return to San Francisco unless very > unlikely changes happen. California. NOT a right to work state. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Tue Sep 18 23:04:22 2012 From: bill at herrin.us (William Herrin) Date: Tue, 18 Sep 2012 19:04:22 -0400 Subject: Big Temporary Networks In-Reply-To: <201209182222.q8IMMptr045570@mail.r-bonomi.com> References: <201209182222.q8IMMptr045570@mail.r-bonomi.com> Message-ID: On Tue, Sep 18, 2012 at 6:22 PM, Robert Bonomi wrote: > 'Right to work', as defined by section 14 B of the Taft-Hartley Act, only > prevents a union contract that requiures union membership as a PRE-REQUISITE > for being hired. What is called 'closed shop' -- where employment is > closed to those who are not union members. > It does -not- prevent a 'union ship' -- where employees are required to > join the union within a reasonable period =after= being hired. The Taft-Hartley Act outlawed closed shops nationwide. It further authorized individual states to outlaw union shops and/or agency shops. 23 states, including my fine home state of Virginia, have done so. > Right-to-work also does not prevent an organization from requiring, by > contractual agreement, that third parties performing work ON THE > 0ORGANIZATION'S PREMISES, employ "union labor" for _that_ work. It > cannot specify _what_ union (or local) however. In Illinois, which has not enacted a state right-to-work law, that's correct. In Virginia, which has, there was just recently a big hullabaloo where the airports authority tried (and spectacularly failed) to place a union preference rule in their contracting process where bids from union shops would have a 10% preference versus bids from non union shops. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Valdis.Kletnieks at vt.edu Tue Sep 18 23:06:49 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 18 Sep 2012 19:06:49 -0400 Subject: IPv6 Ignorance In-Reply-To: Your message of "Tue, 18 Sep 2012 18:18:28 -0400." References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <5EF5A548-4A61-4F94-9BD5-C271C2D7347C@delong.com> <10390.1347982778@turing-police.cc.vt.edu> Message-ID: <34689.1348009609@turing-police.cc.vt.edu> On Tue, 18 Sep 2012 18:18:28 -0400, William Herrin said: > In http://lists.arin.net/pipermail/arin-ppml/2010-September/018180.html > I complained about mapping the full 32-bits of IPv4 address into an > IPv6 prefix. You responded, "You say that like it's somehow a bad > thing," and "I'm simply not seeing a problem." > > Have you come around to my way of thinking that using 6RD with a full > 32-bit IPv4 mapping is not such a hot idea? They're not in contradiction - you want a /28 so you can do 6RD, ARIN should let you do that. You want a /28 so you can do a non-6RD network plan, you should be allowed to do that too. But you don't get to deploy 6RD, and then complain that you don't have enough bits left when you try to do a non-6RD design. Or you could be a bit smarter and realize that you probably only actually *need* to use 16 or 20 bits of address for 6RD mapping and leave yourself 16 or 12 for other uses. AS1312 has 2 /16s, so we only need to map 16 bits of address and one more to indicate which /16 it was and the rest can be implicit. Which of course still loses if you have more than a /8 or so, or if you have 1,495 little prefixes that are scattered all over the /0.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From bill at herrin.us Tue Sep 18 23:09:52 2012 From: bill at herrin.us (William Herrin) Date: Tue, 18 Sep 2012 19:09:52 -0400 Subject: Big Temporary Networks In-Reply-To: References: <31256570.24866.1347637981269.JavaMail.root@benjamin.baylink.com> <1B673D9D-0BE1-4210-92E7-A5907A43C67D@netconsonance.com> <2A76E400AC84B845AAC35AA19F8E7A5D0C695DB2@MUNEXBE1.medline.com> Message-ID: On Tue, Sep 18, 2012 at 6:44 PM, Jo Rhett wrote: > On Sep 18, 2012, at 2:38 PM, William Herrin wrote: >> IIRC when the Democatic National Convention was held in Denver in >> 2008, they had to strike a special deal with the venue to bring in >> union labor instead of the normal workers because they couldn't find a >> suitable place that was already union. > > I can provide people who can refute that, but I don't have (or care about) > the details enough to bother quoting them. Well you would know, you were working for the Democratic National Committee back when they selected Denver and started working the logistics. No, wait, that was actually me. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From james at freedomnet.co.nz Tue Sep 18 23:23:44 2012 From: james at freedomnet.co.nz (james jones) Date: Tue, 18 Sep 2012 19:23:44 -0400 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: References: <2D0AF14BA6FB334988BC1F5D4FC38CB81A9017B5EC@EXCHMBX.hq.nac.net> <20120918211014.29054.qmail@joyce.lan> Message-ID: Are we still talking about this? I setup a lan at home once at that used 6/8 :) On Tue, Sep 18, 2012 at 6:17 PM, Christopher Morrow wrote: > On Tue, Sep 18, 2012 at 5:10 PM, John Levine wrote: > >>And someone should further alert him that they do not "own" these > addresses. > > > > MIT is probably using less of their /8 than MOD is, and as far as I > > know, MIT has neither commando forces nor nuclear weapons. > > > > You might want to pick, so to speak, your battles more carefully. > > more over, who cares? a /8 is less than 2 months rundown globally... > and, once upon a time I constructed on this list a usecase for apple's > /8 ... it's really not THAT hard to use a /8, it's well within the > capabilities of a gov't to do so... especially given they PROBABLY > have: > o unclassified networks > o secret networks > o top secret networks > o other networks > > I'm sure there's plenty of ways they could use the space in question. > > From johnl at iecc.com Tue Sep 18 23:29:24 2012 From: johnl at iecc.com (John R. Levine) Date: 18 Sep 2012 19:29:24 -0400 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: References: <2D0AF14BA6FB334988BC1F5D4FC38CB81A9017B5EC@EXCHMBX.hq.nac.net> <20120918211014.29054.qmail@joyce.lan> Message-ID: On Tue, 18 Sep 2012, james jones wrote: > Are we still talking about this? I setup a lan at home once at that used > 6/8 :) They have nuclear weapons, too. Just saying. R's, John > On Tue, Sep 18, 2012 at 6:17 PM, Christopher Morrow > wrote: > >> On Tue, Sep 18, 2012 at 5:10 PM, John Levine wrote: >>>> And someone should further alert him that they do not "own" these >> addresses. >>> >>> MIT is probably using less of their /8 than MOD is, and as far as I >>> know, MIT has neither commando forces nor nuclear weapons. >>> >>> You might want to pick, so to speak, your battles more carefully. >> >> more over, who cares? a /8 is less than 2 months rundown globally... >> and, once upon a time I constructed on this list a usecase for apple's >> /8 ... it's really not THAT hard to use a /8, it's well within the >> capabilities of a gov't to do so... especially given they PROBABLY >> have: >> o unclassified networks >> o secret networks >> o top secret networks >> o other networks >> >> I'm sure there's plenty of ways they could use the space in question. From malayter at gmail.com Tue Sep 18 23:31:31 2012 From: malayter at gmail.com (Ryan Malayter) Date: Tue, 18 Sep 2012 18:31:31 -0500 Subject: Big Temporary Networks (Dreamforce) Message-ID: Anyone from nanog currently at the wheel of the conference network at Dreamforce in San Francisco (nearly 70000 attendees)? It appears that all of the suggestions posted to this nanog thread so far were thoroughly ignored. Conference WiFi is effectively unusable, despite the very visible, expensive-looking enterprisey APs on temporary stands sprinkled throughout the conference. As far as I can tell, they're doing NAT, using a /16 per AP (which could amount to 5,000 or more devices in one broadcast domain depending on the location!), and are using what appear to be omnidirectional antennas at full blast power instead of zoning with tight directionals. Wifi is nearly unusable; even Sprint's crappy 3G coverage is faster and more reliable inside the conference halls.. -- RPM From george.herbert at gmail.com Tue Sep 18 23:49:45 2012 From: george.herbert at gmail.com (George Herbert) Date: Tue, 18 Sep 2012 16:49:45 -0700 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: References: <2D0AF14BA6FB334988BC1F5D4FC38CB81A9017B5EC@EXCHMBX.hq.nac.net> <20120918211014.29054.qmail@joyce.lan> Message-ID: On Tue, Sep 18, 2012 at 4:29 PM, John R. Levine wrote: > On Tue, 18 Sep 2012, james jones wrote: > >> Are we still talking about this? I setup a lan at home once at that used >> 6/8 :) > > > They have nuclear weapons, too. Just saying. Which, the Army? I don't believe that's true anymore. I think all the Army nuclear weapons have been disassembled or retired. (Quick check... B61, W76, W78, W80, B83, W84, W87, W88... The W84 was in the GLCM, and B61-10 used to be W85s in the Pershing II missiles, but those delivery vehicles are all chopped up). Or is 6/8 used by more of .mil than just the Army? -- -george william herbert george.herbert at gmail.com From jrhett at netconsonance.com Tue Sep 18 23:54:51 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 18 Sep 2012 16:54:51 -0700 Subject: Big Temporary Networks In-Reply-To: References: <31256570.24866.1347637981269.JavaMail.root@benjamin.baylink.com> <1B673D9D-0BE1-4210-92E7-A5907A43C67D@netconsonance.com> <056EE50C-1EBF-4C7B-820A-5FC15BB1319C@netconsonance.com> Message-ID: <1E591CA8-F6EB-4166-991C-4F28A57657A5@netconsonance.com> > There were enough fans among the 600,000 folks in the Baltimore area > but not enough an hour away among the 5,600,000 in the National > Capital Region to justify hosting a Worldcon a couple miles inside the > Virginia border where no unions would get in your way? Really? Having grown up and started my career in Virginia, and much of my family still lives there, I can assure that that there isn't a single facility in Virginia capable of hosting a Worldcon. I think DC has another common problem, where it's either not big enough, or too big for something with only 7k attendees. AND, Virginia has the exact same problem with hotel contracts. I was part of the convention running teams there in the late 80s and early 90s too. Same problems, same discussions. Same negotiations. At this point I think at this point your "right to work" wishful thinking has been thoroughly debunked by others. Let's drop this topic. To bring it back on topic, even if we didn't have unions to deal with, there's no law that can force a hotel or convention center to provide access to the facilities necessary for providing wifi or LTE access to the guests. You can only do that when you have negotiating power, and then you get back to "there's usually only one possible choice and they know it" -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. From jrhett at netconsonance.com Tue Sep 18 23:59:39 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 18 Sep 2012 16:59:39 -0700 Subject: Big Temporary Networks In-Reply-To: References: <31256570.24866.1347637981269.JavaMail.root@benjamin.baylink.com> <1B673D9D-0BE1-4210-92E7-A5907A43C67D@netconsonance.com> <2A76E400AC84B845AAC35AA19F8E7A5D0C695DB2@MUNEXBE1.medline.com> Message-ID: > On Tue, Sep 18, 2012 at 6:44 PM, Jo Rhett wrote: >> On Sep 18, 2012, at 2:38 PM, William Herrin wrote: >>> IIRC when the Democatic National Convention was held in Denver in >>> 2008, they had to strike a special deal with the venue to bring in >>> union labor instead of the normal workers because they couldn't find a >>> suitable place that was already union. >> >> I can provide people who can refute that, but I don't have (or care about) >> the details enough to bother quoting them. > > Well you would know, you were working for the Democratic National > Committee back when they selected Denver and started working the > logistics. No, wait, that was actually me. Ah, then you shouldn't have said IIRC now should you? That expressly indicates you may or may not recall something you read/heard/etc. But since you do know the details of that, then pray tell which hotels they brought in union workers at? Because I'd love to see how that played out. Or were you talking about some other type of facility that we weren't discussing? -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. From bonomi at mail.r-bonomi.com Wed Sep 19 00:18:34 2012 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Tue, 18 Sep 2012 19:18:34 -0500 (CDT) Subject: Big Temporary Networks In-Reply-To: Message-ID: <201209190018.q8J0IYjn046151@mail.r-bonomi.com> > From: William Herrin > Date: Tue, 18 Sep 2012 19:04:22 -0400 > Subject: Re: Big Temporary Networks > > On Tue, Sep 18, 2012 at 6:22 PM, Robert Bonomi > wrote: > > 'Right to work', as defined by section 14 B of the Taft-Hartley Act, > > only prevents a union contract that requiures union membership as a > > PRE-REQUISITE for being hired. What is called 'closed shop' -- where > > employment is closed to those who are not union members. It does -not- > > prevent a 'union ship' -- where employees are required to join the > > union within a reasonable period =after= being hired. > > The Taft-Hartley Act outlawed closed shops nationwide. It further > authorized individual states to outlaw union shops and/or agency shops. > 23 states, including my fine home state of Virginia, have done so. "False to fact" on the last point. Many of the right-to-work states do -not- proscribe union shops. Thoe that do, almost invariably allow for an automatic/involuntary payroll deduction from non-union members covered by a collective bargaining agreement, payable to the union involved, which was a pro rata share of the direct costs of negotiting the collective agreement. > > Right-to-work also does not prevent an organization from requiring, by > > contractual agreement, that third parties performing work ON THE > > 0ORGANIZATION'S PREMISES, employ "union labor" for _that_ work. It > > cannot specify _what_ union (or local) however. > > In Illinois, which has not enacted a state right-to-work law, that's > correct. Illinois, not having right-to-work, is irrelevant. In IOWA, where I grew up, and which has one of the strongest right-to-work laws in the country, "union shops" _are_ legal. As are 'on-site' union labor requirements. The family business (PR consulting) was heavily involved with the state Manufacturers Association (and the national org), and several other associations of large employers. I had access to *LOTS* of detailed info on the state of right-to-work, and collective- bargaining practices nation-wide. My remarks apply to the vast majority of right-to-work states. > In Virginia, which has, there was just recently a big hullabaloo > where the airports authority tried (and spectacularly failed) to place a > union preference rule in their contracting process where bids from union > shops would have a 10% preference versus bids from non union shops. Government entities run into all sorts of difficulties with _any_ such 'preference' biases in the bidding/contracting process -- there are statutory requirements to accept the lowest-price 'qualified' bid, with lots of supporting case law on 'fiduciary responsibility' of public monies -- _unless_ there is a demonstrable _compelling_ public policy reason to include scuh a preference. *VERY* few such survive a court challenge -- a 'set-aside' of a portion of the contracts for the 'preferred' group tends to have an equivalent effect and is much less expensive to implement. (a few percentage points on, say, 10-15% of the contracts is *far* less wasteful than circa 10% on _all_ contracts) I don't know of _any_ such bidding/contract 'preference' that has -not- been challenged in the courts. By a 'discrimminated against' vendor, in the case of government enditie, or by shareholders, in the case of private entities. I don't _think_ anybody has challenged hiring preferences for U.S. armed forces veterans, but I wouldn't be surprised if it _had_ been. From george.herbert at gmail.com Wed Sep 19 01:05:13 2012 From: george.herbert at gmail.com (George Herbert) Date: Tue, 18 Sep 2012 18:05:13 -0700 Subject: Big Temporary Networks In-Reply-To: <201209190018.q8J0IYjn046151@mail.r-bonomi.com> References: <201209190018.q8J0IYjn046151@mail.r-bonomi.com> Message-ID: Ok, as exciting as this all has been, it's grossly off topic now. Please retire the conversation to direct emails if you all want to keep arguing over it, m'kay? Thanks... -george On Tue, Sep 18, 2012 at 5:18 PM, Robert Bonomi wrote: > > >> From: William Herrin >> Date: Tue, 18 Sep 2012 19:04:22 -0400 >> Subject: Re: Big Temporary Networks >> >> On Tue, Sep 18, 2012 at 6:22 PM, Robert Bonomi >> wrote: >> > 'Right to work', as defined by section 14 B of the Taft-Hartley Act, >> > only prevents a union contract that requiures union membership as a >> > PRE-REQUISITE for being hired. What is called 'closed shop' -- where >> > employment is closed to those who are not union members. It does -not- >> > prevent a 'union ship' -- where employees are required to join the >> > union within a reasonable period =after= being hired. >> >> The Taft-Hartley Act outlawed closed shops nationwide. It further >> authorized individual states to outlaw union shops and/or agency shops. >> 23 states, including my fine home state of Virginia, have done so. > > "False to fact" on the last point. Many of the right-to-work states do > -not- proscribe union shops. Thoe that do, almost invariably allow for > an automatic/involuntary payroll deduction from non-union members covered > by a collective bargaining agreement, payable to the union involved, which > was a pro rata share of the direct costs of negotiting the collective > agreement. > >> > Right-to-work also does not prevent an organization from requiring, by >> > contractual agreement, that third parties performing work ON THE >> > 0ORGANIZATION'S PREMISES, employ "union labor" for _that_ work. It >> > cannot specify _what_ union (or local) however. >> >> In Illinois, which has not enacted a state right-to-work law, that's >> correct. > > Illinois, not having right-to-work, is irrelevant. > > In IOWA, where I grew up, and which has one of the strongest right-to-work > laws in the country, "union shops" _are_ legal. As are 'on-site' union > labor requirements. The family business (PR consulting) was heavily > involved with the state Manufacturers Association (and the national org), > and several other associations of large employers. I had access to > *LOTS* of detailed info on the state of right-to-work, and collective- > bargaining practices nation-wide. My remarks apply to the vast majority > of right-to-work states. > >> In Virginia, which has, there was just recently a big hullabaloo >> where the airports authority tried (and spectacularly failed) to place a >> union preference rule in their contracting process where bids from union >> shops would have a 10% preference versus bids from non union shops. > > Government entities run into all sorts of difficulties with _any_ such > 'preference' biases in the bidding/contracting process -- there are > statutory requirements to accept the lowest-price 'qualified' bid, with > lots of supporting case law on 'fiduciary responsibility' of public > monies -- _unless_ there is a demonstrable _compelling_ public policy > reason to include scuh a preference. *VERY* few such survive a court > challenge -- a 'set-aside' of a portion of the contracts for the > 'preferred' group tends to have an equivalent effect and is much less > expensive to implement. (a few percentage points on, say, 10-15% of > the contracts is *far* less wasteful than circa 10% on _all_ contracts) > > I don't know of _any_ such bidding/contract 'preference' that has -not- > been challenged in the courts. By a 'discrimminated against' vendor, > in the case of government enditie, or by shareholders, in the case of > private entities. > > I don't _think_ anybody has challenged hiring preferences for U.S. armed > forces veterans, but I wouldn't be surprised if it _had_ been. > > > > -- -george william herbert george.herbert at gmail.com From randy at psg.com Wed Sep 19 02:28:35 2012 From: randy at psg.com (Randy Bush) Date: Wed, 19 Sep 2012 11:28:35 +0900 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: References: <2D0AF14BA6FB334988BC1F5D4FC38CB81A9017B5EC@EXCHMBX.hq.nac.net> <20120918211014.29054.qmail@joyce.lan> Message-ID: > more over, who cares? a /8 is less than 2 months rundown globally... > and, once upon a time I constructed on this list a usecase for apple's > /8 ... it's really not THAT hard to use a /8, it's well within the > capabilities of a gov't to do so... especially given they PROBABLY > have: > o unclassified networks > o secret networks > o top secret networks > o other networks > > I'm sure there's plenty of ways they could use the space in question. but we are sooooo expert at minding other people's business randy From randy at psg.com Wed Sep 19 02:30:39 2012 From: randy at psg.com (Randy Bush) Date: Wed, 19 Sep 2012 11:30:39 +0900 Subject: Big Temporary Networks In-Reply-To: <2244FE60-F7D6-42B5-8AAB-AA9F569DA169@netconsonance.com> References: <11570158.24452.1347546545009.JavaMail.root@benjamin.baylink.com> <2244FE60-F7D6-42B5-8AAB-AA9F569DA169@netconsonance.com> Message-ID: > So I just want to point out that this is an utterly irrelevant > topic. Worldcon is full to the brim with really smart people who can > build good networks, but in every place large enough to host a > Worldcon the owners of the building make money selling Internet access > and don't want competition. The very best we've been able to do was > create an Internet Lounge with good connectivity, and even that isn't > acceptable at most locations. when you borrow $5,000 from the bank, they own you. when you borrow $5,000,000, you own them. large conferences throw more weight and usually can do their own network. ymmv, of course. randy From mysidia at gmail.com Wed Sep 19 03:13:29 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 18 Sep 2012 22:13:29 -0500 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <50588250.6070802@unfix.org> References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> Message-ID: On 9/18/12, Jeroen Massar wrote: > Some people have to learn that not every address is only used on the > Internet. According to the above there will be large swaths of IPv4 left > at various large organizations who have /8's as "they are not announced" > or as the article states it "as there is no ASN". When IPv4 exhaustion pain reaches a sufficiently high level of pain; there is a significant chance people who will be convinced that any use of IPv4 which does not involve announcing and routing the address space on the internet is a "Non-Use" of IPv4 addresses, and that that particular point of view will prevail over the concept and convenience of being allowed to maintain unique registration for non-connected usage. And perception that those addresses are up for grabs, either for using on RFC1918 networks for NAT, or for insisting that internet registry allocations be recalled and those resources put towards use by connected networks...... If you do have such an unconnected network, it may be prudent to have a connected network as well, and announce all your space anyways (just not route the addresses) > Greets, > Jeroen -- -JH From randy at psg.com Wed Sep 19 03:27:38 2012 From: randy at psg.com (Randy Bush) Date: Wed, 19 Sep 2012 12:27:38 +0900 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> Message-ID: > When IPv4 exhaustion pain reaches a sufficiently high level of pain; > there is a significant chance people who will be convinced that any > use of IPv4 which does not involve announcing and routing the address > space on the internet is a "Non-Use" of IPv4 addresses, > > and that that particular point of view will prevail over the concept > and convenience of being allowed to maintain unique registration for > non-connected usage. > > And perception that those addresses are up for grabs, either for using > on RFC1918 networks for NAT, or for insisting that internet registry > allocations be recalled and those resources put towards use by > connected networks...... > > If you do have such an unconnected network, it may be prudent to have > a connected network as well, and announce all your space anyways (just > not route the addresses) this is the arin vigilante cultural view of the world. luckily, the disease does not propagate sufficiently to cross oceans. randy From mksmith at mac.com Wed Sep 19 03:32:52 2012 From: mksmith at mac.com (Michael Smith) Date: Tue, 18 Sep 2012 20:32:52 -0700 Subject: China Contact In-Reply-To: References: Message-ID: I would check China Unicom. Griffin Dao is a good contact. griffin Dao Mike On Sep 18, 2012, at 2:16 AM, Olivier CALVANO wrote: > Hi > > I am search a supplier for Ethernet Link from Bejing to Singapore and > changzhou to singapore > > Anyone have a contact for this ? (SingTel ? China Telecom ?) > > Thanks > Olivier > From marka at isc.org Wed Sep 19 03:43:42 2012 From: marka at isc.org (Mark Andrews) Date: Wed, 19 Sep 2012 13:43:42 +1000 Subject: IPv6 Ignorance In-Reply-To: Your message of "Tue, 18 Sep 2012 19:06:49 -0400." <34689.1348009609@turing-police.cc.vt.edu> References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <5EF5A548-4A61-4F94-9BD5-C271C2D7347C@delong.com> <10390.1347982778@turing-police.cc.vt.edu> <34689.1348009609@turing-police.cc.vt.edu> Message-ID: <20120919034342.1A26E256352D@drugs.dv.isc.org> In message <34689.1348009609 at turing-police.cc.vt.edu>, Valdis.Kletnieks at vt.edu wri tes: > --==_Exmh_1348009609_2143P > Content-Type: text/plain; charset=us-ascii > > On Tue, 18 Sep 2012 18:18:28 -0400, William Herrin said: > > > In http://lists.arin.net/pipermail/arin-ppml/2010-September/018180.html > > I complained about mapping the full 32-bits of IPv4 address into an > > IPv6 prefix. You responded, "You say that like it's somehow a bad > > thing," and "I'm simply not seeing a problem." > > > > Have you come around to my way of thinking that using 6RD with a full > > 32-bit IPv4 mapping is not such a hot idea? > > They're not in contradiction - you want a /28 so you can do 6RD, ARIN should > let you do that. You want a /28 so you can do a non-6RD network plan, you > should be allowed to do that too. > > But you don't get to deploy 6RD, and then complain that you don't have enough > bits left when you try to do a non-6RD design. > > Or you could be a bit smarter and realize that you probably only actually *need* > to use 16 or 20 bits of address for 6RD mapping and leave yourself 16 or 12 > for other uses. AS1312 has 2 /16s, so we only need to map 16 bits of address > and one more to indicate which /16 it was and the rest can be implicit. Which o > f > course still loses if you have more than a /8 or so, or if you have 1,495 little > prefixes that are scattered all over the /0.... But given that 6rd is DHCP this is all fixed with a little bit of programming. It's not like it's new stuff anyway. It also only has to be done once for each address block. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From blair.trosper at gmail.com Wed Sep 19 04:05:32 2012 From: blair.trosper at gmail.com (Blair Trosper) Date: Tue, 18 Sep 2012 23:05:32 -0500 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> Message-ID: Not to mention Ford Motor Company has 19.0.0.0/8, and there are no announcements for it whatsoever. There are other /8s like it...lots of them early allocations. Why ARIN doesn't revoke them is frankly baffling to me. On Tue, Sep 18, 2012 at 10:27 PM, Randy Bush wrote: > > When IPv4 exhaustion pain reaches a sufficiently high level of pain; > > there is a significant chance people who will be convinced that any > > use of IPv4 which does not involve announcing and routing the address > > space on the internet is a "Non-Use" of IPv4 addresses, > > > > and that that particular point of view will prevail over the concept > > and convenience of being allowed to maintain unique registration for > > non-connected usage. > > > > And perception that those addresses are up for grabs, either for using > > on RFC1918 networks for NAT, or for insisting that internet registry > > allocations be recalled and those resources put towards use by > > connected networks...... > > > > If you do have such an unconnected network, it may be prudent to have > > a connected network as well, and announce all your space anyways (just > > not route the addresses) > > this is the arin vigilante cultural view of the world. luckily, the > disease does not propagate sufficiently to cross oceans. > > randy > > From matthew at matthew.at Wed Sep 19 04:09:28 2012 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 18 Sep 2012 21:09:28 -0700 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> Message-ID: <50594578.4090508@matthew.at> On 9/18/2012 9:05 PM, Blair Trosper wrote: > Not to mention Ford Motor Company has 19.0.0.0/8, and there are no > announcements for it whatsoever. > > There are other /8s like it...lots of them early allocations. > > Why ARIN doesn't revoke them is frankly baffling to me. ARIN didn't assign them, so why (and on what grounds) would they be revoking them exactly? Matthew Kaufman From eyeronic.design at gmail.com Wed Sep 19 04:11:50 2012 From: eyeronic.design at gmail.com (Mike Hale) Date: Tue, 18 Sep 2012 21:11:50 -0700 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> Message-ID: "this is the arin vigilante cultural view of the world. luckily, the disease does not propagate sufficiently to cross oceans." I'd love to hear the reasoning for this. Why would it be bad policy to force companies to use the resources they are assigned or give them back to the general pool? On Tue, Sep 18, 2012 at 8:27 PM, Randy Bush wrote: >> When IPv4 exhaustion pain reaches a sufficiently high level of pain; >> there is a significant chance people who will be convinced that any >> use of IPv4 which does not involve announcing and routing the address >> space on the internet is a "Non-Use" of IPv4 addresses, >> >> and that that particular point of view will prevail over the concept >> and convenience of being allowed to maintain unique registration for >> non-connected usage. >> >> And perception that those addresses are up for grabs, either for using >> on RFC1918 networks for NAT, or for insisting that internet registry >> allocations be recalled and those resources put towards use by >> connected networks...... >> >> If you do have such an unconnected network, it may be prudent to have >> a connected network as well, and announce all your space anyways (just >> not route the addresses) > > this is the arin vigilante cultural view of the world. luckily, the > disease does not propagate sufficiently to cross oceans. > > randy > -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From matthew at matthew.at Wed Sep 19 04:16:49 2012 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 18 Sep 2012 21:16:49 -0700 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> Message-ID: <50594731.6080809@matthew.at> On 9/18/2012 9:11 PM, Mike Hale wrote: > "this is the arin vigilante cultural view of the world. luckily, the > disease does not propagate sufficiently to cross oceans." > > I'd love to hear the reasoning for this. Why would it be bad policy > to force companies to use the resources they are assigned or give them > back to the general pool? Haven't these two (UK) agencies already said that they *are* using the resources that are assigned? They just don't happen to be advertised to the Internet *you* are connected to, apparently. Matthew Kaufman From ops.lists at gmail.com Wed Sep 19 04:21:27 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 19 Sep 2012 09:51:27 +0530 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> Message-ID: On Wednesday, September 19, 2012, Mike Hale wrote: > "this is the arin vigilante cultural view of the world. luckily, the > disease does not propagate sufficiently to cross oceans." > > I'd love to hear the reasoning for this. Why would it be bad policy > to force companies to use the resources they are assigned or give them > back to the general pool? > > Er, just because it isn't announced in the global routing tables doesn't mean it isn't used. I work for a company that has one of those early allocation /8s. It is densely packed with hosts of one kind or the other - but you can't reach (and there is no business need for anybody at all to reach) them except at an office location or having vpn'd in to the company intranet. I rather suspect that this is the case with most such early class A / B / C allocations that aren't currently routed .. if the corporation isn't defunct you can safely assume that especially the /8s are heavily used. It makes all kinds of sense to seek out and reclaim allocations from defunct corporations because if the individual RIRs don't, then various spammers and botmasters will, as we've seen time and again in the past few years. --srs -- Suresh Ramasubramanian (ops.lists at gmail.com) From jrhett at netconsonance.com Wed Sep 19 04:25:56 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 18 Sep 2012 21:25:56 -0700 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> Message-ID: On Sep 18, 2012, at 9:11 PM, Mike Hale wrote: > I'd love to hear the reasoning for this. Why would it be bad policy > to force companies to use the resources they are assigned or give them > back to the general pool? Here's one: there's little to no legal basis for such reclamation so any such attempt would end up in the legal system. Take a gander at how long that might take. Now go look at the consumption rates for IPv4, and recognize that the relevance of reclaiming that space isn't likely to extend to even the first hearing for said court case. It's not worth the effort, for something that will eventually become valueless. And actually, not reclaiming the space will make it valueless even faster as IPv6 migration takes off. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. From marka at isc.org Wed Sep 19 04:46:02 2012 From: marka at isc.org (Mark Andrews) Date: Wed, 19 Sep 2012 14:46:02 +1000 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: Your message of "Tue, 18 Sep 2012 21:11:50 MST." References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> Message-ID: <20120919044603.1F64925671AD@drugs.dv.isc.org> In message , M ike Hale writes: > "this is the arin vigilante cultural view of the world. luckily, the > disease does not propagate sufficiently to cross oceans." > > I'd love to hear the reasoning for this. Why would it be bad policy > to force companies to use the resources they are assigned or give them > back to the general pool? Go back and re-read the entire thread. No one is arguing that unused resources shouldn't be returned. The problem is that people, including the person that started the petition that triggered this thread, have no idea about legitimate use that isn't visible on the publically visible routing tables. Routed => in use Not routed =/> not in use Mark > On Tue, Sep 18, 2012 at 8:27 PM, Randy Bush wrote: > >> When IPv4 exhaustion pain reaches a sufficiently high level of pain; > >> there is a significant chance people who will be convinced that any > >> use of IPv4 which does not involve announcing and routing the address > >> space on the internet is a "Non-Use" of IPv4 addresses, > >> > >> and that that particular point of view will prevail over the concept > >> and convenience of being allowed to maintain unique registration for > >> non-connected usage. > >> > >> And perception that those addresses are up for grabs, either for using > >> on RFC1918 networks for NAT, or for insisting that internet registry > >> allocations be recalled and those resources put towards use by > >> connected networks...... > >> > >> If you do have such an unconnected network, it may be prudent to have > >> a connected network as well, and announce all your space anyways (just > >> not route the addresses) > > > > this is the arin vigilante cultural view of the world. luckily, the > > disease does not propagate sufficiently to cross oceans. > > > > randy > > > > > > -- > 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From eyeronic.design at gmail.com Wed Sep 19 04:49:37 2012 From: eyeronic.design at gmail.com (Mike Hale) Date: Tue, 18 Sep 2012 21:49:37 -0700 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <20120919044603.1F64925671AD@drugs.dv.isc.org> References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> Message-ID: So...why do you need publicly routable IP addresses if they aren't publicly routable? Maybe I'm being dense here, but I'm truly puzzled by this (other than the "this is how our network works and we're not changing it" argument). I can accept the legal argument (and I'm assuming that, in the original contracts for IP space, there wasn't a clause that allowed Internic or its successor to reclaim space). On Tue, Sep 18, 2012 at 9:46 PM, Mark Andrews wrote: > > In message , M > ike Hale writes: >> "this is the arin vigilante cultural view of the world. luckily, the >> disease does not propagate sufficiently to cross oceans." >> >> I'd love to hear the reasoning for this. Why would it be bad policy >> to force companies to use the resources they are assigned or give them >> back to the general pool? > > Go back and re-read the entire thread. No one is arguing that > unused resources shouldn't be returned. The problem is that people, > including the person that started the petition that triggered this > thread, have no idea about legitimate use that isn't visible on the > publically visible routing tables. > > Routed => in use > Not routed =/> not in use > > Mark > >> On Tue, Sep 18, 2012 at 8:27 PM, Randy Bush wrote: >> >> When IPv4 exhaustion pain reaches a sufficiently high level of pain; >> >> there is a significant chance people who will be convinced that any >> >> use of IPv4 which does not involve announcing and routing the address >> >> space on the internet is a "Non-Use" of IPv4 addresses, >> >> >> >> and that that particular point of view will prevail over the concept >> >> and convenience of being allowed to maintain unique registration for >> >> non-connected usage. >> >> >> >> And perception that those addresses are up for grabs, either for using >> >> on RFC1918 networks for NAT, or for insisting that internet registry >> >> allocations be recalled and those resources put towards use by >> >> connected networks...... >> >> >> >> If you do have such an unconnected network, it may be prudent to have >> >> a connected network as well, and announce all your space anyways (just >> >> not route the addresses) >> > >> > this is the arin vigilante cultural view of the world. luckily, the >> > disease does not propagate sufficiently to cross oceans. >> > >> > randy >> > >> >> >> >> -- >> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 >> > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From marka at isc.org Wed Sep 19 05:04:17 2012 From: marka at isc.org (Mark Andrews) Date: Wed, 19 Sep 2012 15:04:17 +1000 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: Your message of "Tue, 18 Sep 2012 21:49:37 MST." References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> Message-ID: <20120919050417.CFB962567514@drugs.dv.isc.org> In message , M ike Hale writes: > So...why do you need publicly routable IP addresses if they aren't > publicly routable? Route announcements can be scoped. See NO-EXPORT. Just because _you_ can't see the announcement doesn't mean others can't see the announcement along with the rest of the publically announced networks. > Maybe I'm being dense here, but I'm truly puzzled by this (other than > the "this is how our network works and we're not changing it" > argument). IP addresses are not just assigned so that one can connect to the public internet. There are lots of other valid reasons for addresses to be assigned. Go look them up. They are documented in RFC's and at the RIR's. Mark > I can accept the legal argument (and I'm assuming that, in the > original contracts for IP space, there wasn't a clause that allowed > Internic or its successor to reclaim space). > > On Tue, Sep 18, 2012 at 9:46 PM, Mark Andrews wrote: > > > > In message >, M > > ike Hale writes: > >> "this is the arin vigilante cultural view of the world. luckily, the > >> disease does not propagate sufficiently to cross oceans." > >> > >> I'd love to hear the reasoning for this. Why would it be bad policy > >> to force companies to use the resources they are assigned or give them > >> back to the general pool? > > > > Go back and re-read the entire thread. No one is arguing that > > unused resources shouldn't be returned. The problem is that people, > > including the person that started the petition that triggered this > > thread, have no idea about legitimate use that isn't visible on the > > publically visible routing tables. > > > > Routed => in use > > Not routed =/> not in use > > > > Mark > > > >> On Tue, Sep 18, 2012 at 8:27 PM, Randy Bush wrote: > >> >> When IPv4 exhaustion pain reaches a sufficiently high level of pain; > >> >> there is a significant chance people who will be convinced that any > >> >> use of IPv4 which does not involve announcing and routing the address > >> >> space on the internet is a "Non-Use" of IPv4 addresses, > >> >> > >> >> and that that particular point of view will prevail over the concept > >> >> and convenience of being allowed to maintain unique registration for > >> >> non-connected usage. > >> >> > >> >> And perception that those addresses are up for grabs, either for using > >> >> on RFC1918 networks for NAT, or for insisting that internet registry > >> >> allocations be recalled and those resources put towards use by > >> >> connected networks...... > >> >> > >> >> If you do have such an unconnected network, it may be prudent to have > >> >> a connected network as well, and announce all your space anyways (just > >> >> not route the addresses) > >> > > >> > this is the arin vigilante cultural view of the world. luckily, the > >> > disease does not propagate sufficiently to cross oceans. > >> > > >> > randy > >> > > >> > >> > >> > >> -- > >> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 > >> > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > > > -- > 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 -- 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 Wed Sep 19 05:05:02 2012 From: randy at psg.com (Randy Bush) Date: Wed, 19 Sep 2012 14:05:02 +0900 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> Message-ID: > "this is the arin vigilante cultural view of the world. luckily, the > disease does not propagate sufficiently to cross oceans." > > I'd love to hear the reasoning for this. Why would it be bad policy > to force companies to use the resources they are assigned or give them > back to the general pool? QED the ipv4 pool is about gone, move to ipv6 nat sucks bigtime, big nats suck even bigger global bgp never converges all devices fail, often two or more at once 'private' routing announcements will leak unless there is an air gap get over it and get back to work moving packets randy From jrhett at netconsonance.com Wed Sep 19 05:06:49 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 18 Sep 2012 22:06:49 -0700 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> Message-ID: <1B8D50D6-52C7-4D10-9C0D-ED092FB48052@netconsonance.com> On Sep 18, 2012, at 9:49 PM, Mike Hale wrote: > So...why do you need publicly routable IP addresses if they aren't > publicly routable? Because you have private connectivity with other companies and you need guaranteed unique IP space. No, really, you can't implement NAT for every possible scenario and even if you could you'd need publicy routable space to NAT it to, or you run into the same collisions. I have worked at companies that have in excess of 4k private interconnections with their clients. Unique IP space is the only way to make this work. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. From mysidia at gmail.com Wed Sep 19 05:07:33 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 19 Sep 2012 00:07:33 -0500 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> Message-ID: On 9/18/12, Mike Hale wrote: > I can accept the legal argument (and I'm assuming that, in the > original contracts for IP space, there wasn't a clause that allowed > Internic or its successor to reclaim space). Assume you have a public IPv4 assignment, and someone else starts routing your assignment... "legitimately" or not, RIR allocation transferred to them, or not. There might be a record created in a database, and/or internet routing tables regarding someone else using the same range for a connected network. But your unconnected network, is unaffected. You are going to have a hard time getting a court to take your case, if the loss/damages to your operation are $0, because your network is unconnected, and its operation is not impaired by someone else's use, and the address ranges' appearance in the global tables. -- -JH From owen at delong.com Wed Sep 19 05:15:33 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 18 Sep 2012 22:15:33 -0700 Subject: IPv6 Ignorance In-Reply-To: <5058A36F.1090102@thebaughers.com> References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <50571759.5050704@illuminati.org> <50573F5C.5090509@matthew.at> <82596E95-9C32-46BB-8B27-CB18290392C0@delong.com> <20120917195433.GM9750@leitl.org> <548DEE97-B1C4-440B-B3CA-8812428067B8@delong.com> <2AF841AB78217140A2A394B2BB6D39C501128733@IDCPRDMBX1.ads.integratelecom.com> <5058A36F.1090102@thebaughers.com> Message-ID: On Sep 18, 2012, at 09:38 , Jason Baugher wrote: > On 9/18/2012 11:01 AM, Beeman, Davis wrote: >> Orbits may not be important to this calculation, but just doing some quick head math, I believe large skyscrapers could already have close to this concentration of addresses, if you reduce them down to flat earth surface area. The point here is that breaking out the math based on the surface area of the earth is silly, as we do not utilize the surface of the earth in a flat manner... >> >> Davis Beeman >> >> >>> On Mon, Sep 17, 2012 at 11:27:04AM -0700, Owen DeLong wrote: >>> >>>> What technology are you planning to deploy that will consume more than 2 addresses per square cm? >>> Easy. Think volume (as in: orbit), and think um^3 for a functional >>> computers ;) >> I meant real-world application. >> >> Orbits are limited due to the required combination of speed and altitude. There are a limited number of achievable altitudes and collision avoidance also creates interesting problems in time-slotting for orbits which are not geostationary. >> >> Geostationary orbits are currently limited to one object per degree of earth surface, and even at 4x that, you could give every satellite a /48 and still not burn through a /32. >> >> Owen >> >> >> > What about network-based objects outside of our orbit? If we're talking about IPv6 in the long-term, I think we have to assume we'll have networked devices on the moon or at other locations in space. > > Jason The IP protocol is not well suited to space travel. As such, I think there would be a non-address based scaling limit in IPv6 for that application and a new protocol would be needed. Owen From owen at delong.com Wed Sep 19 05:13:59 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 18 Sep 2012 22:13:59 -0700 Subject: IPv6 Ignorance In-Reply-To: <2AF841AB78217140A2A394B2BB6D39C501128733@IDCPRDMBX1.ads.integratelecom.com> References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <50571759.5050704@illuminati.org> <50573F5C.5090509@matthew.at> <82596E95-9C32-46BB-8B27-CB18290392C0@delong.com> <20120917195433.GM9750@leitl.org> <548DEE97-B1C4-440B-B3CA-8812428067B8@delong.com> <2AF841AB78217140A2A394B2BB6D39C501128733@IDCPRDMBX1.ads.integratelecom.com> Message-ID: <33004C35-B345-45E0-AEA6-CD8768F8BEB1@delong.com> I won't dispute that, but let's look at some of the densest uses of it, factoring in the vertical aspects as well... Let's assume an 88 story sky scraper 1 city block square (based on an average of 17 city block/mile). That's 96,465 sq. feet (8,961,918 sq. cm.) total building foot print. Subtract roughly 1,000,000 sq. cm. for walls, power, elevators, risers, etc leaves us with 7,961,918 sq. cm. per floor. Figure in a building that large, you probably need 5 floors for generators, 8 floors for chiller plants, and another 2 floors or more for other mechanical gives us a total of 73 datacenter floors max. (Which I would argue is still unrealistic, but what the heck). Subtract 1/3rds of the datacenter area for PDUs and CRAC units puts us at 5,307,945 sq. cm. per floor. FIguring a typical cabinet occupancy area + aisles of 2'x6' (small on the aisles, actually) gives us 12 sq. ft per cabinet = 11,148 sq. cm. per cabinet so we get roughly 715 cabinets per floor (max) and let's assume each 1U server holds 1000 virtual hosts at 42 servers per cabinet, that's 30,030 addresses per cabinet. Multiplied by 75 floors, that's a building total of 2,252,250 total addresses needed. We haven't even blown out a single /64 (and that's without allowing for the lower address density on routers, core switches, etc.). Let's assume we want to give a /64 to each server full of virtual hosts, we're still only taliking about 53,625 /64s, so the whole building can still be addressed within a /48 pretty easily (unless you think you have more than 12,000 additional point-to-point/other administrative/infrastructure links within the building in which case, you might need as much as a /47.) In terms of total addresses per cm, 2,252,250 addresses spread over the building footprint of 8,961,918 sq. cm. is still only 0.25 addresses per sq. cm. so it falls well short of the proposed 2 addresses per sq. cm. To even achieve the suggested 2 addresses per sq. cm, you would need to make the building 704 stories tall and still dense-pack every possible sq. foot of the building with datacenter and you'd have to put these kinds of buildings EVERYWHERE on earth, including over the oceans. I'm willing to say that based on that math, there are more than enough addresses for virtually any rational addressing scheme. Owen On Sep 18, 2012, at 09:01 , "Beeman, Davis" wrote: > Orbits may not be important to this calculation, but just doing some quick head math, I believe large skyscrapers could already have close to this concentration of addresses, if you reduce them down to flat earth surface area. The point here is that breaking out the math based on the surface area of the earth is silly, as we do not utilize the surface of the earth in a flat manner... > > Davis Beeman > > >> On Mon, Sep 17, 2012 at 11:27:04AM -0700, Owen DeLong wrote: >> >>> What technology are you planning to deploy that will consume more than 2 addresses per square cm? >> >> Easy. Think volume (as in: orbit), and think um^3 for a functional >> computers ;) > > I meant real-world application. > > Orbits are limited due to the required combination of speed and altitude. There are a limited number of achievable altitudes and collision avoidance also creates interesting problems in time-slotting for orbits which are not geostationary. > > Geostationary orbits are currently limited to one object per degree of earth surface, and even at 4x that, you could give every satellite a /48 and still not burn through a /32. > > Owen > From eyeronic.design at gmail.com Wed Sep 19 05:27:13 2012 From: eyeronic.design at gmail.com (Mike Hale) Date: Tue, 18 Sep 2012 22:27:13 -0700 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> Message-ID: You know what sucks worse than NAT? Memorizing an IPv6 address. ;) To everyone: Thanks for the clarifications. I don't necessarily agree with some of the arguments...but since I'm not fortunate enough to be in possession of a /8, that agreement (or lack thereof) is worth the electrons this email is sent with (less so, even). The assumption behind my original question is that the IP space simply isn't used anywhere near as efficiently as it could be. While reclaiming even a fraction of those /8s won't put off the eventual depletion, it'll make it slightly more painless over the next year or two. Is that worth the effort required in getting them back? *shrug* Probably not? At any rate, thanks for taking the time to respond. I'll stop derailing the thread now. On Tue, Sep 18, 2012 at 10:05 PM, Randy Bush wrote: >> "this is the arin vigilante cultural view of the world. luckily, the >> disease does not propagate sufficiently to cross oceans." >> >> I'd love to hear the reasoning for this. Why would it be bad policy >> to force companies to use the resources they are assigned or give them >> back to the general pool? > > QED > > the ipv4 pool is about gone, move to ipv6 > nat sucks bigtime, big nats suck even bigger > global bgp never converges > all devices fail, often two or more at once > 'private' routing announcements will leak unless there is an air gap > > get over it and get back to work moving packets > > randy -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From owen at delong.com Wed Sep 19 05:27:29 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 18 Sep 2012 22:27:29 -0700 Subject: IPv6 Ignorance In-Reply-To: References: <50560464.8020906@rollernet.us> <5056086F.1000105@illuminati.org> <5EF5A548-4A61-4F94-9BD5-C271C2D7347C@delong.com> <10390.1347982778@turing-police.cc.vt.edu> Message-ID: 6rd itself isn't inherently silly. Mapping your customers onto an entire /32 is. You're much better off taking the size of your largest prefix and assigning a number of bis for the number of prefixes you have. For example, if you have /14, /14, /15, /16, /16, /16, /18, /19, /20, /22, /22, /22, /22, /23 and need to deploy 6rd, you could easily fit that into a 48-18=30 (round up to 28) - 4 (14 prefixes) = /24. Let's say your /24 is 2001:db00::/24. Your /14s would map to 2001:db00::/28 and 2001:db10::/28. Your 15 would map to 2001:db20::/28 Your 16s would map to 2001:db30::/28, 2001:db40::/28, 2001:db50::/28. The 18, 19, and 20 would get 2001:db60:::/28 - 2001:db80::/28. The 22s would get 2001:db90::/28 - 2001:dbc0::/28. The /23 would get 2001:dbd0::/28 and you'd still have 2001:dbe0 through 2001:dbff available. (2 extra /28s). Note, that's with the assumption of mapping 6rd onto /48s. If you want to map 32 bits, then, you need to degrade your customers 6rd experience and give them smaller blocks until you can give them real IPv6 service. I do not support address policy to make poor planning easier. Owen On Sep 18, 2012, at 15:18 , William Herrin wrote: > On Tue, Sep 18, 2012 at 11:39 AM, wrote: >> On Tue, 18 Sep 2012 02:35:43 -0400, William Herrin said: >> >>> Then we need 32 bits to overlay the customer's IPv4 address for >>> convenience within our 6RD network. >> >> Well yeah. You blow 32 bits for silly reasons, you run out of bits. Film at 11. > > Silly reason? Hardly! 6RD lets you deploy IPv6 immediately to all > customers. It's a stateless tunnel. Direct the packets into an > encapsulator and any customer who wants them need only catch them on > their IPv4 address. Without you having to change out anything else in > your network. Hitch is: if you have a whole lot of discontiguous IPv4 > prefixes, sorting which maps to where in a compact IPv6 prefix is > challenging. Much easier to just map the entire IPv4 space and be done > with it. > > Poor plan. But much easier. > > > On Tue, Sep 18, 2012 at 10:01 AM, Owen DeLong wrote: >>> Then we need 32 bits to overlay the customer's IPv4 address for >>> convenience within our 6RD network. So that leaves us 16 bits. But we >>> don't want the native network to overlay the 6RD network because we >>> want a real simple /16 route into the nearest 6rd encapsulator. And we >>> don't want to advertise multiple BGP prefixes either. So we claim >>> another bit and allocate our native infrastructure from the /16 that >>> doesn't overlap the 6rd setup. >> >> No, you really don't. This absurdity (and the ridiculous design of 6RD) >> are so problematic in this area that I cannot begin to describe what a >> terrible idea it is. > > In http://lists.arin.net/pipermail/arin-ppml/2010-September/018180.html > I complained about mapping the full 32-bits of IPv4 address into an > IPv6 prefix. You responded, "You say that like it's somehow a bad > thing," and "I'm simply not seeing a problem." > > Have you come around to my way of thinking that using 6RD with a full > 32-bit IPv4 mapping is not such a hot idea? > > Regards, > Bill Herrin > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 From feldman at twincreeks.net Wed Sep 19 06:24:41 2012 From: feldman at twincreeks.net (Steve Feldman) Date: Tue, 18 Sep 2012 23:24:41 -0700 Subject: [NANOG-announce] Proposed NANOG bylaws amendments Message-ID: <5CD8304C-C2FB-4F4E-83BA-220CC20F08DD@twincreeks.net> Please review and comment on the proposed amendments to the NANOG bylaws at: https://sites.google.com/a/newnog.org/bylaws-2012/ It has become apparent that cleaning up and simplifying our bylaws will be a long-term project, more than can be accomplished in a single election cycle. These proposed amendments are intended as the first in a series to accomplish those goals, to fix a few outstanding issues and to provide a framework for future improvement. Please direct discussion to the members at nanog.org or nanog-futures at nanog.org list as appropriate. The board will be voting on final ballot language early in October based on these recommendations and your input. Note that there is also a procedure for members to directly place amendments ballot by petition, as described in section 14 of the bylaws. Thanks, Steve _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From owen at delong.com Wed Sep 19 06:31:27 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 18 Sep 2012 23:31:27 -0700 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> Message-ID: <1A05B0E5-0269-4C14-9B30-5E424B990237@delong.com> On Sep 18, 2012, at 21:11 , Mike Hale wrote: > "this is the arin vigilante cultural view of the world. luckily, the > disease does not propagate sufficiently to cross oceans." > > I'd love to hear the reasoning for this. Why would it be bad policy > to force companies to use the resources they are assigned or give them > back to the general pool? > Many of them _ARE_ using them, just not using them directly on the public internet. There is nothing wrong with that. As others have said... !announced != !used. Owen > On Tue, Sep 18, 2012 at 8:27 PM, Randy Bush wrote: >>> When IPv4 exhaustion pain reaches a sufficiently high level of pain; >>> there is a significant chance people who will be convinced that any >>> use of IPv4 which does not involve announcing and routing the address >>> space on the internet is a "Non-Use" of IPv4 addresses, >>> >>> and that that particular point of view will prevail over the concept >>> and convenience of being allowed to maintain unique registration for >>> non-connected usage. >>> >>> And perception that those addresses are up for grabs, either for using >>> on RFC1918 networks for NAT, or for insisting that internet registry >>> allocations be recalled and those resources put towards use by >>> connected networks...... >>> >>> If you do have such an unconnected network, it may be prudent to have >>> a connected network as well, and announce all your space anyways (just >>> not route the addresses) >> >> this is the arin vigilante cultural view of the world. luckily, the >> disease does not propagate sufficiently to cross oceans. >> >> randy >> > > > > -- > 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From goemon at anime.net Wed Sep 19 06:40:32 2012 From: goemon at anime.net (goemon at anime.net) Date: Tue, 18 Sep 2012 23:40:32 -0700 (PDT) Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <1A05B0E5-0269-4C14-9B30-5E424B990237@delong.com> References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <1A05B0E5-0269-4C14-9B30-5E424B990237@delong.com> Message-ID: On Tue, 18 Sep 2012, Owen DeLong wrote: > On Sep 18, 2012, at 21:11 , Mike Hale wrote: >> "this is the arin vigilante cultural view of the world. luckily, the >> disease does not propagate sufficiently to cross oceans." >> >> I'd love to hear the reasoning for this. Why would it be bad policy >> to force companies to use the resources they are assigned or give them >> back to the general pool? > Many of them _ARE_ using them, just not using them directly on the public > internet. There is nothing wrong with that. > > As others have said... !announced != !used. Is they are not using them directly on the public internet, then there's no reason we can't use them. Problem solved! -Dan From jrhett at netconsonance.com Wed Sep 19 06:56:16 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 18 Sep 2012 23:56:16 -0700 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <1A05B0E5-0269-4C14-9B30-5E424B990237@delong.com> Message-ID: <92DBC616-37C5-4B48-9761-2D429C1ED3DE@netconsonance.com> On Sep 18, 2012, at 11:40 PM, goemon at anime.net wrote: > Is they are not using them directly on the public internet, then there's no reason we can't use them. > > Problem solved! Dude, seriously. Just because they aren't in *YOUR* routing table doesn't mean that they aren't in hundreds of other routing tables. Look, more than half of Milnet isn't publicly advertised on the Internet. This doesn't mean that it's okay to advertise Milnet routes to locations which might be closer to you (bgp-wise) than the actual owners of the addresses. You are totally missing the point of unique assignment. This is like claiming that we should reuse the phone numbers of people who block their number when they call you. Yes, really, it makes just as much sense. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. From marka at isc.org Wed Sep 19 06:59:58 2012 From: marka at isc.org (Mark Andrews) Date: Wed, 19 Sep 2012 16:59:58 +1000 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: Your message of "Tue, 18 Sep 2012 23:40:32 MST." References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <1A05B0E5-0269-4C14-9B30-5E424B990237@delong.com> Message-ID: <20120919065959.AFD332568362@drugs.dv.isc.org> In message , goemon at anime.ne t writes: > On Tue, 18 Sep 2012, Owen DeLong wrote: > > On Sep 18, 2012, at 21:11 , Mike Hale wrote: > >> "this is the arin vigilante cultural view of the world. luckily, the > >> disease does not propagate sufficiently to cross oceans." > >> > >> I'd love to hear the reasoning for this. Why would it be bad policy > >> to force companies to use the resources they are assigned or give them > >> back to the general pool? > > Many of them _ARE_ using them, just not using them directly on the public > > internet. There is nothing wrong with that. > > > > As others have said... !announced != !used. > > Is they are not using them directly on the public internet, then there's > no reason we can't use them. > > Problem solved! > > -Dan !announced whole world != !announced. There is a simple rule. DO NOT USE ADDRESSES THAT YOU HAVE NOT BEEN ALLOCATED. Anything else has the potential to cause operational problems. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From goemon at anime.net Wed Sep 19 07:04:18 2012 From: goemon at anime.net (goemon at anime.net) Date: Wed, 19 Sep 2012 00:04:18 -0700 (PDT) Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <20120919065959.AFD332568362@drugs.dv.isc.org> References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <1A05B0E5-0269-4C14-9B30-5E424B990237@delong.com> <20120919065959.AFD332568362@drugs.dv.isc.org> Message-ID: On Wed, 19 Sep 2012, Mark Andrews wrote: > In message , goemon at anime.ne > t writes: >> On Tue, 18 Sep 2012, Owen DeLong wrote: >>> On Sep 18, 2012, at 21:11 , Mike Hale wrote: >>>> "this is the arin vigilante cultural view of the world. luckily, the >>>> disease does not propagate sufficiently to cross oceans." >>>> >>>> I'd love to hear the reasoning for this. Why would it be bad policy >>>> to force companies to use the resources they are assigned or give them >>>> back to the general pool? >>> Many of them _ARE_ using them, just not using them directly on the public >>> internet. There is nothing wrong with that. >>> >>> As others have said... !announced != !used. >> >> Is they are not using them directly on the public internet, then there's >> no reason we can't use them. >> >> Problem solved! > !announced whole world != !announced. > > There is a simple rule. i guess my sarcasm was missed. > DO NOT USE ADDRESSES THAT YOU HAVE NOT BEEN ALLOCATED. > > Anything else has the potential to cause operational problems. Tell that to the providers who keep routing hijacked blocks for spammers :) -Dan From seth.mos at dds.nl Wed Sep 19 07:24:53 2012 From: seth.mos at dds.nl (Seth Mos) Date: Wed, 19 Sep 2012 09:24:53 +0200 Subject: Big Temporary Networks In-Reply-To: References: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> <50561ADD.2040404@necom830.hpcl.titech.ac.jp> <505626A2.1090700@foobar.org> <505663DE.7000309@necom830.hpcl.titech.ac.jp> <50586620.6080702@necom830.hpcl.titech.ac.jp> <5058DA13.90000@foobar.org> Message-ID: <50597345.1080204@dds.nl> Op 18-9-2012 22:50, William Herrin schreef: > On Tue, Sep 18, 2012 at 4:31 PM, Nick Hilliard wrote: >> On 18/09/2012 21:24, William Herrin wrote: >>> IPv6 falls down compared to IPv4 on wifi networks when it responds to a >>> router solicitation with a multicast (instead of unicast) router >>> advertisement. >> You mean it has one extra potential failure mode in situations where radio >> retransmission doesn't deal with the packet loss - which will cause RA to >> retry. "Fall down" is a slight overstatement. > Potayto, potahto. Like I said, I have no interest in defending IPv6. > But I'm very interested in how to implement an IPv6 network that's as > or more reliable than the equivalent IPv4 network. That makes me > interested in the faults which get in the way. > > Regards, > Bill Herrin > Yes, radvd has a configuration option to send unicast packets. But I think the effects are slightly overstated. Unless someone fudged the lifetime counters on the ra config nobody will ever notice a RA getting lost. Once every few seconds a RA message will be sent and it will be valid for atleast a couple of minutes. Within that time there will be multiple RA announcements, and unless you missed 5 minutes of RA advertisements everything is fine. And if you do miss 5 minutes of RA multicast traffic, really, you have bigger problems. I see network stacks springing to life in the space of 3 seconds on the 1st message I send out. That's pretty stellar, and faster then some clients perform the DHCPv4 request. Also note that some wifi networks eat DHCPv4 broadcasts too, which is pretty much the same deal as what you are referring to above. They will retry the DHCPv4 request, and so do client that perform router sollicitation requests. No different. And if the wifi network is so bad that you have icmp and udp dropping like mad, I doubt anybody would want to use it. You are more likely that they will disable wifi altogether and use 3g. The 2.4Ghz wifi band is so crowded now that this has become the effective standard. Unless you are a happy camper that actually has a wifi card that supports the 5Ghz band. Which is far too uncommon in phones and tablets. boo. Cheers, Seth From mohta at necom830.hpcl.titech.ac.jp Wed Sep 19 07:26:28 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 19 Sep 2012 16:26:28 +0900 Subject: Big Temporary Networks In-Reply-To: References: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> <50561ADD.2040404@necom830.hpcl.titech.ac.jp> <505626A2.1090700@foobar.org> <505663DE.7000309@necom830.hpcl.titech.ac.jp> <50586620.6080702@necom830.hpcl.titech.ac.jp> Message-ID: <505973A4.90705@necom830.hpcl.titech.ac.jp> William Herrin wrote: >> Unicast since its responding to a solicitation? >> >> RFC4861 states: >> >> A router MAY choose to unicast the >> response directly to the soliciting host's address (if the >> solicitation's source address is not the unspecified address), but >> the usual case is to multicast the response to the all-nodes group. > > Ah, okay. So the IPv6 router usually responds to router discovery with Don't ignore how is the implementations in the real world: : and a comment in rtadvd on the solicited advertisement: : : /* : * unicast advertisements : * XXX commented out. reason: though spec does not forbit it, unicast : * advert does not really help > But correct me if I'm wrong: the router advertisement daemon could be > altered to reply with unicast without changing the standard, right? See above. > What do the radvd and rtadvd developers say about this when confronted > with the 802.11 multicast problem? I reported the problem to IPv6 (or IPng?) WG more than 10 years ago (before rtadvd was developed) and Christian Huitema acknowledged that the problem does exist. Since then, nothing happened. > Are there any Internet drafts > active in the IETF to replace that "MAY" with a "SHOULD," noting that > replying with multicast can defeat layer 2 error recovery needed for > the successful use of some layer 1 media? Didn't you say "without changing the standard"? >>> What did I >>> miss? Where does IPv6 take the bad turn that IPv4 avoided? You still miss DAD. DupAddrDetectTransmits should be 3, 5 or maybe 10 (depending on level of congestion), which means even more time is wasted. Worse, increasing DupAddrDetectTransmits increases level of congestion, which means congestion collapse occurs with use case senario of IEEE802.11ai. > I have no interest in defending IPv6. We're network operators here. > You just told us (and offered convincing reasoning) that when > selecting a router vendor for use with an IPv6 wifi network, one of > our evaluation check boxes should should be, "Responds to ICMPv6 > router solicitation with a unicast message? Yes or Fail." And when we > provide the list of deficiencies to our vendor and wave the wad of > cash around, one of them should be, "Responds to ICMPv6 router > solicitations with a multicast packet - unreliable in a wifi > environment." > That's strikes me as something valuable to know. Far more valuable > than, "Dood, IPv6 has problems on wifi networks." The only thing operators have to know about IPv6 is that IPv6, as is currently specified, is not operational. Then, let IETF bother. Masataka Ohta From elmi at 4ever.de Wed Sep 19 07:37:07 2012 From: elmi at 4ever.de (Elmar K. Bins) Date: Wed, 19 Sep 2012 09:37:07 +0200 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> Message-ID: <20120919073707.GX18204@h.detebe.org> eyeronic.design at gmail.com (Mike Hale) wrote: > You know what sucks worse than NAT? > Memorizing an IPv6 address. ;) I agree. But we'll have to live with it until something better comes along. > The assumption behind my original question is that the IP space simply > isn't used anywhere near as efficiently as it could be. While > reclaiming even a fraction of those /8s won't put off the eventual > depletion, it'll make it slightly more painless over the next year or > two. I don't see how this would help. We all - and the world - have known for at least three years when the allocatable IPv4 pool would/will run out. Have we done something (at large)? No. Instead, people are whimpering about others having v4 addresses they are "obviously" not using and couldn't we pull those and redistribute so everyone's happier. Honestly - you'd only push the current situation two months back. Now everybody start using v6 and quit whining. (Or like Randy said - get back to pushing packets) Elmar. From mansaxel at besserwisser.org Wed Sep 19 07:56:32 2012 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Wed, 19 Sep 2012 09:56:32 +0200 Subject: Big Temporary Networks In-Reply-To: <2244FE60-F7D6-42B5-8AAB-AA9F569DA169@netconsonance.com> References: <11570158.24452.1347546545009.JavaMail.root@benjamin.baylink.com> <2244FE60-F7D6-42B5-8AAB-AA9F569DA169@netconsonance.com> Message-ID: <20120919075631.GK24232@besserwisser.org> Subject: Re: Big Temporary Networks Date: Tue, Sep 18, 2012 at 01:03:00PM -0700 Quoting Jo Rhett (jrhett at netconsonance.com): > On Sep 13, 2012, at 7:29 AM, Jay Ashworth wrote: > > I'm talking to the people who will probably be, in 2015, running the first > > Worldcon I can practically drive to, in Orlando, at -- I think -- the Disney > > World Resort. I've told them how critical the issue is for this market; they, > > predictably, replied "We look forward to your patch". :-} > > So I just want to point out that this is an utterly irrelevant topic. Worldcon is full to the brim with really smart people who can build good networks, but in every place large enough to host a Worldcon the owners of the building make money selling Internet access and don't want competition. The very best we've been able to do was create an Internet Lounge with good connectivity, and even that isn't acceptable at most locations. All the IETF and RIPE meetings I've been to have had excellent custom networks. How come? -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 How do you explain Wayne Newton's POWER over millions? It's th' MOUSTACHE ... Have you ever noticed th' way it radiates SINCERITY, HONESTY & WARMTH? It's a MOUSTACHE you want to take HOME and introduce to NANCY SINATRA! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From mohta at necom830.hpcl.titech.ac.jp Wed Sep 19 08:25:33 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 19 Sep 2012 17:25:33 +0900 Subject: Big Temporary Networks In-Reply-To: <50597345.1080204@dds.nl> References: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> <50561ADD.2040404@necom830.hpcl.titech.ac.jp> <505626A2.1090700@foobar.org> <505663DE.7000309@necom830.hpcl.titech.ac.jp> <50586620.6080702@necom830.hpcl.titech.ac.jp> <5058DA13.90000@foobar.org> <50597345.1080204@dds.nl> Message-ID: <5059817D.8090405@necom830.hpcl.titech.ac.jp> Seth Mos wrote: > Yes, radvd has a configuration option to send unicast packets. But I > think the effects are slightly overstated. A senario considered by IEEE11ai is that a very crowded train arrives at a station and all the smart phones of passengers try to connect to APs. Then, it is essential to reduce the number of control packet exchanges. > Also note that some wifi networks eat DHCPv4 broadcasts too, As I already stated, DHCP discover/request from STA to AP is unicast. > And if the wifi network is so bad that you have icmp and udp dropping I'm afraid you don't understand CSMA/CA at all. Masataka Ohta From a.harrowell at gmail.com Wed Sep 19 08:46:28 2012 From: a.harrowell at gmail.com (Alex Harrowell) Date: Wed, 19 Sep 2012 09:46:28 +0100 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <1A05B0E5-0269-4C14-9B30-5E424B990237@delong.com> <20120919065959.AFD332568362@drugs.dv.isc.org> Message-ID: <50598664.9020302@gmail.com> On 19/09/12 08:04, goemon at anime.net wrote: > On Wed, 19 Sep 2012, Mark Andrews wrote: >> In message , >> goemon at anime.ne >> t writes: >>> On Tue, 18 Sep 2012, Owen DeLong wrote: >>>> On Sep 18, 2012, at 21:11 , Mike Hale >>>> wrote: >>>>> "this is the arin vigilante cultural view of the world. luckily, the >>>>> disease does not propagate sufficiently to cross oceans." >>>>> >>>>> I'd love to hear the reasoning for this. Why would it be bad policy >>>>> to force companies to use the resources they are assigned or give >>>>> them >>>>> back to the general pool? >>>> Many of them _ARE_ using them, just not using them directly on the >>>> public >>>> internet. There is nothing wrong with that. >>>> >>>> As others have said... !announced != !used. >>> >>> Is they are not using them directly on the public internet, then >>> there's >>> no reason we can't use them. >>> >>> Problem solved! >> !announced whole world != !announced. >> >> There is a simple rule. > > i guess my sarcasm was missed. > >> DO NOT USE ADDRESSES THAT YOU HAVE NOT BEEN ALLOCATED. >> >> Anything else has the potential to cause operational problems. > > Tell that to the providers who keep routing hijacked blocks for > spammers :) > > -Dan On the other hand, the scarcity is of *globally unique routable* addresses. You can make a case that private use of (non-RFC1918) IPv4 resources is wasteful in itself at the moment. To be provocative, what on earth is their excuse for not using IPv6 internally? By definition, an internal network that isn't announced to the public Internet doesn't have to worry about happy eyeballs, broken carrier NAT, and the like because it doesn't have to be connected to them if it doesn't want to be. A lot of the transition issues are much less problematic if you're not on the public Internet. Perhaps the military have a lot of weird equipment that is IPv4 only - in fact it's a racing certainty - but DWP is a gigantic enterprise data processing organisation. They also have some big Web sites, but obviously those aren't on the private network. (If they had enough workstations to need the whole /8, we wouldn't need DWP as the unemployment problem would have been definitively solved:-)) From tim at pelican.org Wed Sep 19 09:01:40 2012 From: tim at pelican.org (Tim Franklin) Date: Wed, 19 Sep 2012 10:01:40 +0100 (BST) Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: Message-ID: <4bd0179a-8e3b-4e1d-b43d-b828bce9117c@mail.pelican.org> > So...why do you need publicly routable IP addresses if they aren't > publicly routable? Because the RIRs aren't in the business of handing out publicly routable address space. They're in the business of handing out globally unique address space - *one* of the reasons for which may be connection to the "public Internet", whatever that is at any given point in time and space. RIPE are really good about making the distinction and using the latter phrase rather than the former. I'm not familiar enough with the corresponding ARIN documents to comment on the language used there. Regards, Tim. From jpmuga at tespok.co.ke Wed Sep 19 12:05:09 2012 From: jpmuga at tespok.co.ke (Joseph M. Owino ) Date: Wed, 19 Sep 2012 15:05:09 +0300 (EAT) Subject: IMPLEMENTING A SOFTWARE BASED ROUTE SERVER In-Reply-To: <9be1f04b-6f4d-4d68-b11b-800519832f77@MX-IX-NBO> Message-ID: <122ed7f9-a760-4aea-9abe-da7572de9385@MX-IX-NBO> Hi, Hope you are all well. I work at an exchange point and was seeking any assistance on how to implement a software based route server as currently we are using a Cisco Router for that purpose. Any form of assistance will be highly appreciated. regards Muga From jeroen at unfix.org Wed Sep 19 12:26:15 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 19 Sep 2012 14:26:15 +0200 Subject: IMPLEMENTING A SOFTWARE BASED ROUTE SERVER In-Reply-To: <122ed7f9-a760-4aea-9abe-da7572de9385@MX-IX-NBO> References: <122ed7f9-a760-4aea-9abe-da7572de9385@MX-IX-NBO> Message-ID: <5059B9E7.5030201@unfix.org> On 2012-09-19 14:05 , Joseph M. Owino wrote: > Hi, > > Hope you are all well. I work at an exchange point and was seeking > any assistance on how to implement a software based route server as > currently we are using a Cisco Router for that purpose. Any form of > assistance will be highly appreciated. The IX's seem to be going from software based ones to Cisco's ;) See also amongst others: http://ripe60.ripe.net/presentations/Hilliard-euro-ix-quaggadev.pdf http://conference.apnic.net/__data/assets/pdf_file/0020/50771/osr_apnic34_1346132140.pdf http://www.uknof.org.uk/uknof22/Sanghani-Euro-IX.pdf http://www.uknof.org.uk/uknof13/Hughes-IXP_routeservers.pdf And recently on this very NANOG list: http://www.gossamer-threads.com/lists/nanog/users/155853 Greets, Jeroen From regnauld at nsrc.org Wed Sep 19 12:29:52 2012 From: regnauld at nsrc.org (Phil Regnauld) Date: Wed, 19 Sep 2012 14:29:52 +0200 Subject: IMPLEMENTING A SOFTWARE BASED ROUTE SERVER In-Reply-To: <122ed7f9-a760-4aea-9abe-da7572de9385@MX-IX-NBO> References: <9be1f04b-6f4d-4d68-b11b-800519832f77@MX-IX-NBO> <122ed7f9-a760-4aea-9abe-da7572de9385@MX-IX-NBO> Message-ID: <20120919122952.GT90817@macbook.bluepipe.net> Joseph M. Owino (jpmuga) writes: > Hi, > > Hope you are all well. I work at an exchange point and was seeking any assistance on how to implement a software based route server as currently we are using a Cisco Router for that purpose. Any form of assistance will be highly appreciated. Hello Joseph, You could do this in a number of ways, running Quagga or BIRD (or even BGPD) on a Linux or BSD server. Quagga documentation even has a chapter on this: http://www.nongnu.org/quagga/docs/quagga.html#SEC115 I'm sure several people on this list have experience with this and will contribute. Also, it might be send this inquiry to the AfNOG list as well (afnog.org). Finally (plug) we have some resources that may be of interest to you here: https://nsrc.org/route-bgp-ixp.html Cheers, Phil From bicknell at ufp.org Wed Sep 19 12:35:22 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 19 Sep 2012 05:35:22 -0700 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> Message-ID: <20120919123522.GA96213@ussenterprise.ufp.org> In a message written on Tue, Sep 18, 2012 at 09:11:50PM -0700, Mike Hale wrote: > I'd love to hear the reasoning for this. Why would it be bad policy > to force companies to use the resources they are assigned or give them > back to the general pool? While I personally think ARIN should do more to flush out addresses that are actually _not in use at all_, the danger here is very clear. Forcing the return of address space that is in use but not in the "global default free routing table" is making a value judgement about the use of that address space. Basically it is the community saying that using public address space for private, but possibly interconnected networks is not a worthy use of the space. For a few years the community tried to force name based virtual hosting on the hosting industry, rather than burning one IP address per host. That also was a value judegment that turned out to not be so practical, as people use more than plain HTTP in the hosting world. The sippery slope argument is where does this hunt for "underutilized" space stop? Disconnected networks are bad? Name based hosting is required? Carrier grade NAT is required for end user networks? More importantly are the RIR's set up to make these value judgements about the usage as they get more and more subjective? There's also a ROI problem. People smarter than I have done the math, and figured out that if X% of the address space can be reclaimed via these efforts, that gains Y years of address space. Turns out Y is pretty darn small no matter how agressive the search for underutilized space. Basically the RIR's would have to spin up more staff and, well, harass pretty much every IP holder for a couple of years just to delay the transition to IPv6 by a couple of years. In the short term moving the date a couple of years may seem like a win, but in the long term its really insignificant. It's also important to note that RIR's are paid for by the users, the ramp up in staff and legal costs of such and effort falls back on the community. Is delaying IPv6 adoption worth having RIR fees double? If the policy to get companies to look at and return such resources had been investigated 10-15 years ago it might have been something that could have been done in a reasonable way with some positive results. It wasn't though, and rushing that effort now just doesn't make a meaningful difference in the IPv4->IPv6 transition, particularly given the pain of a rushed implementation. -- 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 josmon at rigozsaurus.com Wed Sep 19 13:24:16 2012 From: josmon at rigozsaurus.com (John Osmon) Date: Wed, 19 Sep 2012 07:24:16 -0600 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> Message-ID: <20120919132416.GA28155@jeeves.rigozsaurus.com> On Wed, Sep 19, 2012 at 12:07:33AM -0500, Jimmy Hess wrote: > Assume you have a public IPv4 assignment, and someone else > starts routing your assignment... "legitimately" or not, RIR allocation > transferred to them, or not. > > There might be a record created in a database, and/or internet routing > tables regarding someone else using the same range for a connected network. > > But your unconnected network, is unaffected. Ahh... But the network may not be unconnected. Just because *you* don't have a path to it doesn't mean others are similarly disconnected. All of those "others" would be affected. > You are going to have a hard time getting a court to take your case, > if the loss/damages to your operation are $0, because your network is > unconnected, and its operation is not impaired by someone else's use, > and the address ranges' appearance in the global tables. Think about a company that has thousands of private interconnects with other companies. Unique address space would remove the chance of RFC1918 space clash, and any of the bad effects of NAT. (e.g The network *works* as it was originally designed.) Such a network would not have $0 in loss/damage when the partners can't reach it due to a rogue announcement. The Internet is not the same from all viewpoints. From trejrco at gmail.com Wed Sep 19 13:49:51 2012 From: trejrco at gmail.com (TJ) Date: Wed, 19 Sep 2012 09:49:51 -0400 Subject: Big Temporary Networks In-Reply-To: <505973A4.90705@necom830.hpcl.titech.ac.jp> References: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> <50561ADD.2040404@necom830.hpcl.titech.ac.jp> <505626A2.1090700@foobar.org> <505663DE.7000309@necom830.hpcl.titech.ac.jp> <50586620.6080702@necom830.hpcl.titech.ac.jp> <505973A4.90705@necom830.hpcl.titech.ac.jp> Message-ID: > The only thing operators have to know about IPv6 is that IPv6, as is > currently specified, is not operational. > I think it is safe to say that this is provably false. Are there opportunities for increased efficiency, perhaps ... however: I get native IPv6 at home via my standard residential cable connection using off the shelf CPE gear and standard OSes. I get native IPv6 via my standard LTE devices, again - off the shelf - no customization required. *(Repeated emphasis on the use of standard, off the shelf components here ... no end-user hacking/tweaking, nor custom firmware loads, nor special requests to the provider ... "it just works".)* * * Both of these have been properly functioning since being lit up. Clearly, atleast the two *rather large* operators involved *(Comcast & Verizon Wireless, if it matters) *have deployed IPv6 in an operational fashion. I bet Hurricane Electric would *strongly* disagree as well. *... Not to mention the enterprise networks and hosting facilities that have also implemented IPv6 rather successfully, all of which are relying on some carrier(s) to provide them connectivity.* /TJ From seth.mos at dds.nl Wed Sep 19 13:51:24 2012 From: seth.mos at dds.nl (Seth Mos) Date: Wed, 19 Sep 2012 15:51:24 +0200 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <20120919123522.GA96213@ussenterprise.ufp.org> References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919123522.GA96213@ussenterprise.ufp.org> Message-ID: <5059CDDC.3040306@dds.nl> Op 19-9-2012 14:35, Leo Bicknell schreef: > In a message written on Tue, Sep 18, 2012 at 09:11:50PM -0700, Mike Hale wrote: >> I'd love to hear the reasoning for this. Why would it be bad policy >> to force companies to use the resources they are assigned or give them >> back to the general pool? > There's also a ROI problem. People smarter than I have done the > math, and figured out that if X% of the address space can be reclaimed > via these efforts, that gains Y years of address space. Turns out > Y is pretty darn small no matter how agressive the search for > underutilized space. Basically the RIR's would have to spin up > more staff and, well, harass pretty much every IP holder for a > couple of years just to delay the transition to IPv6 by a couple > of years. In the short term moving the date a couple of years may > seem like a win, but in the long term its really insignificant. > It's also important to note that RIR's are paid for by the users, > the ramp up in staff and legal costs of such and effort falls back > on the community. Is delaying IPv6 adoption worth having RIR fees > double? Forcing a government organization to renumber their (large!) network to 10/8 just to give it back it to ARIN would be a massive undertaking. There are considerable drawbacks: 1. The renumbering of a government organization is payed for by the UK taxpayers. I'm sure the UK can use the funds somewhere else right now. 2. The time taken to complete this operation would likely run into years, see 1. 3. Even if the renumbering completes by 2015 it would be far too late, since we need it now rather then later. 4. The actual value of the "sale" of the /8 could either be huge in 2015, or insignificant in 2015. So the irony is that the taxpayer lobbying for return wants to have the /8 returned to or sell it. But there is a significant non-zero cost and he would be paying for it himself. I also like the idea of public services to be reachable in the future. Just because it is not in use now, I'll see them using it in the future. Regards, Seth From james.cutler at consultant.com Wed Sep 19 14:07:52 2012 From: james.cutler at consultant.com (Cutler James R) Date: Wed, 19 Sep 2012 10:07:52 -0400 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <20120919132416.GA28155@jeeves.rigozsaurus.com> References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> <20120919132416.GA28155@jeeves.rigozsaurus.com> Message-ID: <061B51E2-DED9-431E-BD3A-D8EBBD51B21E@consultant.com> On Sep 19, 2012, at 9:24 AM, John Osmon wrote: > On Wed, Sep 19, 2012 at 12:07:33AM -0500, Jimmy Hess wrote: >> Assume you have a public IPv4 assignment, and someone else >> starts routing your assignment... "legitimately" or not, RIR allocation >> transferred to them, or not. >> >> There might be a record created in a database, and/or internet routing >> tables regarding someone else using the same range for a connected network. >> >> But your unconnected network, is unaffected. > > Ahh... But the network may not be unconnected. Just because *you* > don't have a path to it doesn't mean others are similarly disconnected. > All of those "others" would be affected. > >> You are going to have a hard time getting a court to take your case, >> if the loss/damages to your operation are $0, because your network is >> unconnected, and its operation is not impaired by someone else's use, >> and the address ranges' appearance in the global tables. > > Think about a company that has thousands of private interconnects with > other companies. Unique address space would remove the chance of > RFC1918 space clash, and any of the bad effects of NAT. (e.g The network > *works* as it was originally designed.) > > Such a network would not have $0 in loss/damage when the partners can't > reach it due to a rogue announcement. > > The Internet is not the same from all viewpoints. > This discussion is repeating ones heard hear in the mid 1990s. Having a block of IP addresses not seen in YOUR IP routing tables is NOT evidence of unused addresses. For example, an inter-network SMTP relay correctly forwards messages via MX DNS entries only if unique IP address exist on both sides of the relay. This is just one example of application level gateways used to isolate networks at Layer 3 that has been in use for decades. As noted above, there are many instances of private interconnects which rely on assigned integers to tag destinations in a globally unique fashion. In the case of IP addressing, IANA and the various registries provide this globally unique assignment service. Use of these unique integers for packet routing is left as an exercise for the Network Engineer. IANA and the registries are not in the business of directly policing the use of any assigned integers. Those of us who have been involved in interconnecting private networks with overlapping IP address assignments are well aware of the pitfalls, hazards, and costs of using non-unique addressing. An entity which uses its ignorance of how addresses are used internally by another entity as an excuse to ignore proper IP address assignment is deliberately contributing to network chaos and to the culture of ignoring rules "because we can". The bottom line is that "Connected" does not mean "Routable via IPv4/IPv6". This is in addition to "Hidden" does not mean "Unused" as pointed out by others. From arturo.servin at gmail.com Wed Sep 19 14:45:04 2012 From: arturo.servin at gmail.com (Arturo Servin) Date: Wed, 19 Sep 2012 11:45:04 -0300 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> Message-ID: <2FBA73F3-7482-4E10-AAC6-3FA05696E105@gmail.com> There is something that I think they call DNS. It may help. :) .as On 19 Sep 2012, at 02:27, Mike Hale wrote: > You know what sucks worse than NAT? > > Memorizing an IPv6 address. ;) From blake at pfankuch.me Wed Sep 19 15:02:50 2012 From: blake at pfankuch.me (Blake Pfankuch) Date: Wed, 19 Sep 2012 15:02:50 +0000 Subject: Recommended Generator Service in Northern Colorado Message-ID: Looking for some recommendations on a company to do regularly scheduled maintenance work on our Generac Generator in Northern Colorado. The company who did the installation is out of business, and the company who most recently did work does not believe in answering the phone... Any suggestions welcome. --Blake From sean at seanharlow.info Wed Sep 19 15:33:39 2012 From: sean at seanharlow.info (Sean Harlow) Date: Wed, 19 Sep 2012 11:33:39 -0400 Subject: Big Temporary Networks In-Reply-To: <5059817D.8090405@necom830.hpcl.titech.ac.jp> References: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> <50561ADD.2040404@necom830.hpcl.titech.ac.jp> <505626A2.1090700@foobar.org> <505663DE.7000309@necom830.hpcl.titech.ac.jp> <50586620.6080702@necom830.hpcl.titech.ac.jp> <5058DA13.90000@foobar.org> <50597345.1080204@dds.nl> <5059817D.8090405@necom830.hpcl.titech.ac.jp> Message-ID: On Sep 19, 2012, at 04:25, Masataka Ohta wrote: > As I already stated, DHCP discover/request from STA to AP is > unicast. This didn't sound right, so I decided to test. With the three clients available to me (laptop running OS X 10.7.4, phone running Android 4.0, and iPod running iOS 4.1.2) all client->server DHCP was broadcast, as well as server->client NACKs. Server->client offers and ACKs were unicast. --- Sean Harlow sean at seanharlow.info From jrhett at netconsonance.com Wed Sep 19 17:42:30 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed, 19 Sep 2012 10:42:30 -0700 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <50598664.9020302@gmail.com> References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <1A05B0E5-0269-4C14-9B30-5E424B990237@delong.com> <20120919065959.AFD332568362@drugs.dv.isc.org> <50598664.9020302@gmail.com> Message-ID: <4F38CD88-0188-4B0F-9F94-7F088644EEB6@netconsonance.com> On Sep 19, 2012, at 1:46 AM, Alex Harrowell wrote: > To be provocative, what on earth is their excuse for not using IPv6 internally? By definition, an internal network that isn't announced to the public Internet doesn't have to worry about happy eyeballs, broken carrier NAT, and the like because it doesn't have to be connected to them if it doesn't want to be. A lot of the transition issues are much less problematic if you're not on the public Internet. Because next to zero of the common office equipment supports v6, or supports it well. And honestly it's a cost facter that nobody has any incentive to pay. Every enterprise I have spoken with has the exact same intention: IPv4 inside forever to avoid cost they don't need to pay. NAT to v6 externally if necessary. Obviously when IPv6 has a larger footprint and their staff has the experience this will change, but asking the enterprise to pick up this ball and run with it is wasting your time. And second, have you ever worked on a private intranet that wasn't connected to the internet through a firewall? Skipping oob networks for equipment management, neither have I. > Perhaps the military have a lot of weird equipment that is IPv4 only - in fact it's a racing certainty - but DWP is a gigantic enterprise data processing organisation. They also have some big Web sites, but obviously those aren't on the private network. (If they had enough workstations to need the whole /8, we wouldn't need DWP as the unemployment problem would have been definitively solved:-)) As a giant enterprise data processing center that works today, what possible motivation do they have for disrupting that? You've got to shake this silliness out of your head. I started my career when there were dozens of networking protocols. The industry eventually shook out by 1992 around IPv4, however many businesses were running some of the obsolete, dead, unsupported protocols well up and past 2000, long long long after IPv4 had become the one true protocol. Even if we flip the entire Internet over to IPv6 next week, enterprises will be running IPv4 internally well into the 2020s. Because they have no gain in paying the cost to change, and massive risk in making the change. Obviously some businesses will need to upgrade and will have the motivation. But don't expect people who don't need to upgrade, don't need to change, to undertake a massive infrastructure upgrade so that you can get more IPv4 addresses. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. From joelja at bogus.com Wed Sep 19 17:52:24 2012 From: joelja at bogus.com (joel jaeggli) Date: Wed, 19 Sep 2012 10:52:24 -0700 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <4F38CD88-0188-4B0F-9F94-7F088644EEB6@netconsonance.com> References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <1A05B0E5-0269-4C14-9B30-5E424B990237@delong.com> <20120919065959.AFD332568362@drugs.dv.isc.org> <50598664.9020302@gmail.com> <4F38CD88-0188-4B0F-9F94-7F088644EEB6@netconsonance.com> Message-ID: <505A0658.2000508@bogus.com> On 9/19/12 10:42 AM, Jo Rhett wrote: > And second, have you ever worked on a private intranet that wasn't > connected to the internet through a firewall? Skipping oob networks > for equipment management, neither have I. Plenty of people on this list have worked on private internet(s) with real AS numbers, public IP space and no direct internet connectivity. From james.cutler at consultant.com Wed Sep 19 18:01:09 2012 From: james.cutler at consultant.com (Cutler James R) Date: Wed, 19 Sep 2012 14:01:09 -0400 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <4F38CD88-0188-4B0F-9F94-7F088644EEB6@netconsonance.com> References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <1A05B0E5-0269-4C14-9B30-5E424B990237@delong.com> <20120919065959.AFD332568362@drugs.dv.isc.org> <50598664.9020302@gmail.com> <4F38CD88-0188-4B0F-9F94-7F088644EEB6@netconsonance.com> Message-ID: On Sep 19, 2012, at 1:42 PM, Jo Rhett wrote: > > And second, have you ever worked on a private intranet that wasn't connected to the internet through a firewall? Skipping oob networks for equipment management, neither have I. Yes, for many years. External connections only via Application Level Gateways for SMTP, HTTP and Virtual Network connections. And, using assigned IPv4 addresses. And, no one willing to pay for IPv6. From scott at doc.net.au Wed Sep 19 18:02:18 2012 From: scott at doc.net.au (Scott Howard) Date: Wed, 19 Sep 2012 11:02:18 -0700 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> Message-ID: On Tue, Sep 18, 2012 at 9:49 PM, Mike Hale wrote: > So...why do you need publicly routable IP addresses if they aren't > publicly routable? > Because doing anything else is Harmful! There's even an RFC that says so! http://tools.ietf.org/html/rfc1627 - Network 10 Considered Harmful Ford's /8 was allocated in 1988, a full 6 years before RFC1597 (the precursor to RFC1918) was released. Scott. From jrhett at netconsonance.com Wed Sep 19 18:14:58 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed, 19 Sep 2012 11:14:58 -0700 Subject: They aren't on *MY* Internet, so I should get their space! In-Reply-To: References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <1A05B0E5-0269-4C14-9B30-5E424B990237@delong.com> <20120919065959.AFD332568362@drugs.dv.isc.org> <50598664.9020302@gmail.com> <4F38CD88-0188-4B0F-9F94-7F088644EEB6@netconsonance.com> Message-ID: <1E1B7784-91A2-43BE-9297-A24765C08B8F@netconsonance.com> I'm renaming the thread to what the argument really is. On Sep 19, 2012, at 11:01 AM, Cutler James R wrote: > On Sep 19, 2012, at 1:42 PM, Jo Rhett wrote: >> >> And second, have you ever worked on a private intranet that wasn't connected to the internet through a firewall? Skipping oob networks for equipment management, neither have I. > > Yes, for many years. External connections only via Application Level Gateways for SMTP, HTTP and Virtual Network connections. And, using assigned IPv4 addresses. And, no one willing to pay for IPv6. You are making my point for me. Does your internet deal with duplication of IP space inside and outside the gateways? Is that easy to deal with? Thus my point is made. Just because you don't have direct connectivity to *every* point on the Internet does not mean that you don't need unique space. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. From drc at virtualized.org Wed Sep 19 18:17:12 2012 From: drc at virtualized.org (David Conrad) Date: Wed, 19 Sep 2012 11:17:12 -0700 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> Message-ID: <231483E9-5129-4722-87DE-635FEC3AC422@virtualized.org> On Sep 19, 2012, at 11:02 AM, Scott Howard wrote: > On Tue, Sep 18, 2012 at 9:49 PM, Mike Hale wrote: >> So...why do you need publicly routable IP addresses if they aren't publicly routable? >> > Because doing anything else is Harmful! There's even an RFC that says so! > http://tools.ietf.org/html/rfc1627 - Network 10 Considered Harmful Actually, the reference you probably want is http://tools.ietf.org/rfc/rfc1814.txt - Unique Numbers are Good. That RFC caused a bit of consternation with the RIRs at the time as some of us (at least) were trying to suggest that given IPv4 was a limited (albeit not scarce at that time) resource, if you didn't plan on connecting to the Internet, RFC 1597 space was to be encouraged. Regards, -drc From gbonser at seven.com Wed Sep 19 18:56:21 2012 From: gbonser at seven.com (George Bonser) Date: Wed, 19 Sep 2012 18:56:21 +0000 Subject: Comcast mail admin contact? Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09EDFBEB@RWC-MBX1.corp.seven.com> We are having trouble that seems to look like we are being throttled from one of our production nets to Comcast's pop3 service (mail.comcast.net). Service appears to work fine from other addresses in our network, just transactions from one of our more active production source IPs seems to progress like molasses or sometimes connections time out completely though we are not experiencing any packet loss so it looks like throttling of some sort. If there's someone from Comcast or someone else on the list who could point me to the proper contact for admin of that service, I'd be much obliged. It is having significant impact on some of their users who reach them via our services. G From shrdlu at deaddrop.org Wed Sep 19 19:00:25 2012 From: shrdlu at deaddrop.org (Lynda) Date: Wed, 19 Sep 2012 12:00:25 -0700 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <505A0658.2000508@bogus.com> References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <1A05B0E5-0269-4C14-9B30-5E424B990237@delong.com> <20120919065959.AFD332568362@drugs.dv.isc.org> <50598664.9020302@gmail.com> <4F38CD88-0188-4B0F-9F94-7F088644EEB6@netconsonance.com> <505A0658.2000508@bogus.com> Message-ID: <505A1649.5040005@deaddrop.org> On 9/19/2012 10:52 AM, joel jaeggli wrote: > On 9/19/12 10:42 AM, Jo Rhett wrote: >> And second, have you ever worked on a private intranet that wasn't >> connected to the internet through a firewall? Skipping oob networks >> for equipment management, neither have I. > Plenty of people on this list have worked on private internet(s) with > real AS numbers, public IP space and no direct internet connectivity. *cough* 33/8 *cough* (among others) Can we now let this die a well-deserved death? Pretty please? -- You may want to read RFC 1796, and then retract what you said because it sounds silly. Nick Hilliard (http://tools.ietf.org/rfc/rfc1796.txt) From davidpeahi at gmail.com Wed Sep 19 19:07:12 2012 From: davidpeahi at gmail.com (david peahi) Date: Wed, 19 Sep 2012 12:07:12 -0700 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <20120918140712.GF9750@leitl.org> References: <20120918140712.GF9750@leitl.org> Message-ID: Those who argue that IPv4 addresses must be reclaimed seem to have forgotten that even for small organizations, converting IPv4 address space to RFC1918 addresses, or IPv6, is a huge task given the fixed IP addresses of many devices (printers, copy machines, etc.), and even worse, the many key business application programs that use hard-coded IP addresses instead of DNS resolution. Many of these application programs were written many years ago, and are poorly supported, such that making code changes places a company's business success on the line. Of course, unused /8 prefixes appear to be an abuse, but as some have noted in this thread, many large organizations were assigned /8s decades ago, and have used them for IP addressing for key business functions. David On Tue, Sep 18, 2012 at 7:07 AM, Eugen Leitl wrote: > > > http://paritynews.com/network/item/325-department-of-work-and-pensions-uk-in-possession-of-169-million-unused-ipv4-addresses > > Department of Work and Pensions UK in Possession of 16.9 Million Unused > IPv4 > Addresses > > Written by Ravi Mandalia > > Department of Work and Pensions UK in Possession of 16.9 Million Unused > IPv4 > Addresses > > The Department of Work and Pensions, UK has an entire block of '/8' IPv4 > addresses that is unused and an e-petition has been filed in this regards > asking the DWP to sell it off thus easing off the RIPE IPv4 address space > scarcity a little. > > John Graham-Cumming, who found this unused block, wrote in a blog post that > the DWP was in possession of 51.0.0.0/8 IPv4 addresses. According to > Cumming, > these 16.9 million IP addresses are unused at the moment and he derived > this > conclusion by doing a check in the ASN database. ?A check of the ASN > database > will show that there are no networks for that block of addresses,? he > wrote. > > An e-petition has been filed in this regards. ?It has recently come to > light > that the Department for Work and Pensions has its own allocated block of > 16,777,216 addresses (commonly referred to as a /8), covering 51.0.0.0 to > 51.255.255.255?, reads the petition. > > The UK government, if it sells off this /8 block, could end up getting ?1 > billion mark. ??1 billion of low-effort extra cash would be a very nice > thing > to throw at our deficit,? read the petition. > > Cumming ends his post with the remark, ?So, Mr. Cameron, I'll accept a 10% > finder's fee if you dispose of this asset :-)?. > > > From rguerra at privaterra.org Wed Sep 19 20:35:13 2012 From: rguerra at privaterra.org (Robert Guerra) Date: Wed, 19 Sep 2012 16:35:13 -0400 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <20120918140712.GF9750@leitl.org> References: <20120918140712.GF9750@leitl.org> Message-ID: <450916D8-FA1D-4D43-BE8F-451D50DD6088@privaterra.org> Am I correct in assuming that the unused IP block would not be sold as is mentioned in the article, but instead be returned to RIPE to be reallocated? Robert On 18 Sep 2012, at 10:07, Eugen Leitl wrote: > http://paritynews.com/network/item/325-department-of-work-and-pensions-uk-in-possession-of-169-million-unused-ipv4-addresses > > Department of Work and Pensions UK in Possession of 16.9 Million > Unused IPv4 > Addresses > > Written by Ravi Mandalia > > Department of Work and Pensions UK in Possession of 16.9 Million > Unused IPv4 > Addresses > > The Department of Work and Pensions, UK has an entire block of '/8' > IPv4 > addresses that is unused and an e-petition has been filed in this > regards > asking the DWP to sell it off thus easing off the RIPE IPv4 address > space > scarcity a little. > > John Graham-Cumming, who found this unused block, wrote in a blog post > that > the DWP was in possession of 51.0.0.0/8 IPv4 addresses. According to > Cumming, > these 16.9 million IP addresses are unused at the moment and he > derived this > conclusion by doing a check in the ASN database. ?A check of the ASN > database > will show that there are no networks for that block of addresses,? > he wrote. > > An e-petition has been filed in this regards. ?It has recently come > to light > that the Department for Work and Pensions has its own allocated block > of > 16,777,216 addresses (commonly referred to as a /8), covering 51.0.0.0 > to > 51.255.255.255?, reads the petition. > > The UK government, if it sells off this /8 block, could end up getting > ?1 > billion mark. ??1 billion of low-effort extra cash would be a very > nice thing > to throw at our deficit,? read the petition. > > Cumming ends his post with the remark, ?So, Mr. Cameron, I'll accept > a 10% > finder's fee if you dispose of this asset :-)?. From george.herbert at gmail.com Wed Sep 19 20:46:57 2012 From: george.herbert at gmail.com (George Herbert) Date: Wed, 19 Sep 2012 13:46:57 -0700 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <450916D8-FA1D-4D43-BE8F-451D50DD6088@privaterra.org> References: <20120918140712.GF9750@leitl.org> <450916D8-FA1D-4D43-BE8F-451D50DD6088@privaterra.org> Message-ID: <6778C282-C035-4091-9195-1CC4EEC7E6AF@gmail.com> As the subsequent discussion here shows, "unused" is a press inaccuracy. The nets are in active use; much of that use is not publicly advertised, but it's still in use. George William Herbert Sent from my iPhone On Sep 19, 2012, at 1:35 PM, "Robert Guerra" wrote: > Am I correct in assuming that the unused IP block would not be sold as is mentioned in the article, but instead be returned to RIPE to be reallocated? > > Robert > > > On 18 Sep 2012, at 10:07, Eugen Leitl wrote: > >> http://paritynews.com/network/item/325-department-of-work-and-pensions-uk-in-possession-of-169-million-unused-ipv4-addresses >> >> Department of Work and Pensions UK in Possession of 16.9 Million Unused IPv4 >> Addresses >> >> Written by Ravi Mandalia >> >> Department of Work and Pensions UK in Possession of 16.9 Million Unused IPv4 >> Addresses >> >> The Department of Work and Pensions, UK has an entire block of '/8' IPv4 >> addresses that is unused and an e-petition has been filed in this regards >> asking the DWP to sell it off thus easing off the RIPE IPv4 address space >> scarcity a little. >> >> John Graham-Cumming, who found this unused block, wrote in a blog post that >> the DWP was in possession of 51.0.0.0/8 IPv4 addresses. According to Cumming, >> these 16.9 million IP addresses are unused at the moment and he derived this >> conclusion by doing a check in the ASN database. ?A check of the ASN database >> will show that there are no networks for that block of addresses,? he wrote. >> >> An e-petition has been filed in this regards. ?It has recently come to light >> that the Department for Work and Pensions has its own allocated block of >> 16,777,216 addresses (commonly referred to as a /8), covering 51.0.0.0 to >> 51.255.255.255?, reads the petition. >> >> The UK government, if it sells off this /8 block, could end up getting ?1 >> billion mark. ??1 billion of low-effort extra cash would be a very nice thing >> to throw at our deficit,? read the petition. >> >> Cumming ends his post with the remark, ?So, Mr. Cameron, I'll accept a 10% >> finder's fee if you dispose of this asset :-)?. > From blake at pfankuch.me Wed Sep 19 20:58:24 2012 From: blake at pfankuch.me (Blake Pfankuch) Date: Wed, 19 Sep 2012 20:58:24 +0000 Subject: Recommended Generator Service in Northern Colorado (from nanog) In-Reply-To: <20120919205734.A2C3C800037@ip-64-139-1-69.sjc.megapath.net> References: <20120919205734.A2C3C800037@ip-64-139-1-69.sjc.megapath.net> Message-ID: Since I have gotten many off list responses.. I have a submitted an "Information Request" they sent me back the list which is on their website of 24 shops within 75 miles. Looking for a little bit more information/history, as two of them I called this morning I went to their voicemail. Of course they were the ones with reviews on the Generac website as well so no more real world feedback. Thanks --Blake -----Original Message----- From: Hal Murray [mailto:hmurray at megapathdsl.net] Sent: Wednesday, September 19, 2012 2:58 PM To: Blake Pfankuch Cc: Hal Murray Subject: Re: Recommended Generator Service in Northern Colorado (from nanog) > Looking for some recommendations on a company to do regularly > scheduled maintenance work on our Generac Generator in Northern > Colorado. The company who did the installation is out of business, > and the company who most recently did work does not believe in answering the phone... Have you called the manufacturer? They have a serious interest in making sure that somebody will service their gear. If they don't actually now of a service company, they might know of other customers in your area. -- These are my opinions. I hate spam. From drc at virtualized.org Wed Sep 19 21:02:30 2012 From: drc at virtualized.org (David Conrad) Date: Wed, 19 Sep 2012 14:02:30 -0700 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <450916D8-FA1D-4D43-BE8F-451D50DD6088@privaterra.org> References: <20120918140712.GF9750@leitl.org> <450916D8-FA1D-4D43-BE8F-451D50DD6088@privaterra.org> Message-ID: <228E92AD-DD79-470A-AB5F-3A21A88B756F@virtualized.org> Robert, On Sep 19, 2012, at 1:35 PM, Robert Guerra wrote: > Am I correct in assuming that the unused IP block would not be sold as is mentioned in the article, but instead be returned to RIPE to be reallocated? Assuming for the sake of argument that the 51/8 is actually unused (which it apparently isn't), the UK gov't would be under no contractual obligation to return the address space to IANA (which is (arguably) the allocating registry, not RIPE) -- I believe that "class A" was allocated prior to the existence of the RIRs and registration service agreements. Regards, -drc From nick at foobar.org Wed Sep 19 21:42:59 2012 From: nick at foobar.org (Nick Hilliard) Date: Wed, 19 Sep 2012 22:42:59 +0100 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <228E92AD-DD79-470A-AB5F-3A21A88B756F@virtualized.org> References: <20120918140712.GF9750@leitl.org> <450916D8-FA1D-4D43-BE8F-451D50DD6088@privaterra.org> <228E92AD-DD79-470A-AB5F-3A21A88B756F@virtualized.org> Message-ID: <505A3C63.7090302@foobar.org> On 19/09/2012 22:02, David Conrad wrote: > Assuming for the sake of argument that the 51/8 is actually unused > (which it apparently isn't), the UK gov't would be under no contractual > obligation to return the address space to IANA (which is (arguably) the > allocating registry, not RIPE) -- I believe that "class A" was allocated > prior to the existence of the RIRs and registration service agreements. the ripe ncc has short-circuited this particular argument by committing to hand back to IANA any legacy address space which is handed back to it. I.e. makes no difference - it ends up at IANA anyway. Nick From johnl at iecc.com Wed Sep 19 21:49:24 2012 From: johnl at iecc.com (John Levine) Date: 19 Sep 2012 21:49:24 -0000 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <450916D8-FA1D-4D43-BE8F-451D50DD6088@privaterra.org> Message-ID: <20120919214924.78033.qmail@joyce.lan> In article <450916D8-FA1D-4D43-BE8F-451D50DD6088 at privaterra.org> you write: >Am I correct in assuming that the unused IP block would not be sold as >is mentioned in the article, but instead be returned to RIPE to be >reallocated? Since there is no chance of either one happening, no. R's, John From mohta at necom830.hpcl.titech.ac.jp Wed Sep 19 21:54:35 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 20 Sep 2012 06:54:35 +0900 Subject: Big Temporary Networks In-Reply-To: References: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> <50561ADD.2040404@necom830.hpcl.titech.ac.jp> <505626A2.1090700@foobar.org> <505663DE.7000309@necom830.hpcl.titech.ac.jp> <50586620.6080702@necom830.hpcl.titech.ac.jp> <5058DA13.90000@foobar.org> <50597345.1080204@dds.nl> <5059817D.8090405@necom830.hpcl.titech.ac.jp> Message-ID: <505A3F1B.50603@necom830.hpcl.titech.ac.jp> Sean Harlow wrote: >> As I already stated, DHCP discover/request from STA to AP is >> unicast. > > This didn't sound right, so I decided to test. Your test is invalid. > With the three > clients available to me (laptop running OS X 10.7.4, phone > running Android 4.0, and iPod running iOS 4.1.2) all > client->server DHCP was broadcast Of course. However, at WiFi L2, it is first unicast to AP and then broadcast by the AP. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Wed Sep 19 22:01:49 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 20 Sep 2012 07:01:49 +0900 Subject: Big Temporary Networks In-Reply-To: References: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> <50561ADD.2040404@necom830.hpcl.titech.ac.jp> <505626A2.1090700@foobar.org> <505663DE.7000309@necom830.hpcl.titech.ac.jp> <50586620.6080702@necom830.hpcl.titech.ac.jp> <505973A4.90705@necom830.hpcl.titech.ac.jp> Message-ID: <505A40CD.8030701@necom830.hpcl.titech.ac.jp> TJ wrote: >> The only thing operators have to know about IPv6 is that IPv6, as is >> currently specified, is not operational. > I think it is safe to say that this is provably false. You failed to do so. > Are there opportunities for increased efficiency, perhaps ... however: Congestion collapse is not a matter of mere efficiency. > I get native IPv6 at home via my standard residential cable connection > using off the shelf CPE gear and standard OSes. > I get native IPv6 via my standard LTE devices, again - off the shelf - no > customization required. That IPv6 works fine sometimes in some environment is not a valid proof that IPv6 is operational. Purposelessly bloated specification of IPv6 cause problems in some environment, against which removal of features is the only cure. It's like not using IP options, even though they are defined in RFC791. Masataka Ohta From dougb at dougbarton.us Wed Sep 19 22:15:41 2012 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 19 Sep 2012 15:15:41 -0700 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <231483E9-5129-4722-87DE-635FEC3AC422@virtualized.org> References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> <231483E9-5129-4722-87DE-635FEC3AC422@virtualized.org> Message-ID: <505A440D.5080701@dougbarton.us> Imagine that you are the DWP. You're given a block of addresses, told that they will be yours forever, plan your network accordingly, and implement your plan. Now, decades later, people are telling you that "forever" is over, and you have to totally re-address your network because you have something that other people want. To make the request that much more interesting, the reason that they want your block is because they failed to implement the actual solution to the problem, IPv6. We were already looking at the IPv4 runout problems when I was at IANA in 2004. We already knew (in large part thanks to folks like Tony Hain and Geoff Huston) that we'd run out in the 2010-2012 time frame, and a lot of us pushed a lot of rocks up a lot of hills to get our part of the IPv6 infrastructure rollout done well in advance of that date. We (and by we here I am explicitly including the RIRs) also heavily discussed every single option for every single block ... holders of legacy blocks were quietly approached and asked about the potential of returning them, and some of them actually did. We scoured ERX space, re-thought a lot of long held assumptions (e.g., we could never allocate 1/8); and squeezed every drop of blood we could from the IPv4 turnip. Of course, this good work was continued long after I left ICANN, and the Internet community should be grateful to those who have spent many thankless hours dealing with this problem. ... and now, we're done. IPv4 is what it is. There are no new solutions, there is no magic bullet, and no quantity of pixie dust is going to cause new space to appear out of thin air. You can spend more time flogging long-concluded arguments, or you can spend your time productively by implementing IPv6. Doug From Valdis.Kletnieks at vt.edu Wed Sep 19 22:32:12 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 19 Sep 2012 18:32:12 -0400 Subject: Big Temporary Networks In-Reply-To: Your message of "Thu, 20 Sep 2012 06:54:35 +0900." <505A3F1B.50603@necom830.hpcl.titech.ac.jp> References: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> <50561ADD.2040404@necom830.hpcl.titech.ac.jp> <505626A2.1090700@foobar.org> <505663DE.7000309@necom830.hpcl.titech.ac.jp> <50586620.6080702@necom830.hpcl.titech.ac.jp> <5058DA13.90000@foobar.org> <50597345.1080204@dds.nl> <5059817D.8090405@necom830.hpcl.titech.ac.jp> <505A3F1B.50603@necom830.hpcl.titech.ac.jp> Message-ID: <32950.1348093932@turing-police.cc.vt.edu> On Thu, 20 Sep 2012 06:54:35 +0900, Masataka Ohta said: > Sean Harlow wrote: > > >> As I already stated, DHCP discover/request from STA to AP is > >> unicast. > > > > This didn't sound right, so I decided to test. > > Your test is invalid. You forgot to include a .jpg of Darth Vader playing bagpipes on a unicycle or similar. http://knowyourmeme.com/memes/your-argument-is-invalid -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From jmaimon at ttec.com Wed Sep 19 22:36:08 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Wed, 19 Sep 2012 18:36:08 -0400 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <505A440D.5080701@dougbarton.us> References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> <231483E9-5129-4722-87DE-635FEC3AC422@virtualized.org> <505A440D.5080701@dougbarton.us> Message-ID: <505A48D8.4040800@ttec.com> Doug Barton wrote: > > We were already looking at the IPv4 runout problems when I was at IANA > in 2004. We already knew (in large part thanks to folks like Tony Hain > and Geoff Huston) that we'd run out in the 2010-2012 time frame, and a > lot of us pushed a lot of rocks up a lot of hills to get our part of the > IPv6 infrastructure rollout done well in advance of that date. > So 6-8 years to try and rehabilitate 240/4 was not even enough to try? > ... and now, we're done. IPv4 is what it is. There are no new solutions, > there is no magic bullet, Just old ones that nobody liked at that time, that will continue to be re-examined until nobody needs IPv4 anymore. > and no quantity of pixie dust is going to > cause new space to appear out of thin air. For the right price the amount of effort required to increase efficiency of the space we already have will become worthwhile. With a decreased burn rate, efforts to retrieve and rehabilitate space become more useful. > You can spend more time > flogging long-concluded arguments, or you can spend your time > productively by implementing IPv6. > > Doug You know we will be doing both for quite some more time. Joe From bill at herrin.us Wed Sep 19 22:36:39 2012 From: bill at herrin.us (William Herrin) Date: Wed, 19 Sep 2012 18:36:39 -0400 Subject: Big Temporary Networks In-Reply-To: <505A40CD.8030701@necom830.hpcl.titech.ac.jp> References: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> <50561ADD.2040404@necom830.hpcl.titech.ac.jp> <505626A2.1090700@foobar.org> <505663DE.7000309@necom830.hpcl.titech.ac.jp> <50586620.6080702@necom830.hpcl.titech.ac.jp> <505973A4.90705@necom830.hpcl.titech.ac.jp> <505A40CD.8030701@necom830.hpcl.titech.ac.jp> Message-ID: On Wed, Sep 19, 2012 at 11:33 AM, Sean Harlow wrote: > On Sep 19, 2012, at 04:25, Masataka Ohta wrote: > >> As I already stated, DHCP discover/request from STA to AP is >> unicast. > > This didn't sound right, so I decided to test. With the three clients >available to me (laptop running OS X 10.7.4, phone running >Android 4.0, and iPod running iOS 4.1.2) all client->server >DHCP was broadcast, as well as server->client NACKs. >Server->client offers and ACKs were unicast. I think Masataka meant to say (and said previously) that the DHCP request from the wifi station is, like all packets from the wifi station to the AP, subject to wifi's layer 2 error recovery. It's not unicast but its subject to error recovery anyway. In the return direction (AP to station) broadcast and multicast packets are not subject to error recovery while unicast packets are. Hence the the DHCPv4 server->client unicast offers and acks pass reliably while IPv6's equivalent multicast ICMPv6 router advertisements do not. On Wed, Sep 19, 2012 at 5:54 PM, Masataka Ohta wrote: > However, at WiFi L2, it is first unicast to AP and then broadcast > by the AP. Your use of nomenclature is incorrect. It'd be like saying my ethernet card unicasts a packet to the switch and then the switch broadcasts it out all ports. Or like saying that a packet with an explicit MAC destination is a broadcast packet because the switch doesn't have the address in its MAC table. The packet is flooded out all ports but its not a broadcast packet. A layer 2 packet was unicast, multicast or broadcast moment I attached the appropriate destination MAC. The exact handling on a particular segment of the layer 2 network, while important in other contexts, is irrelevant to the designation unicast, multicast or broadcast. On Wed, Sep 19, 2012 at 3:26 AM, Masataka Ohta wrote: > The only thing operators have to know about IPv6 is that IPv6, as > is currently specified, is not operational. No offense, but it is not for you or I or Owen Delong to declare that IPv6 is or isn't operational. Operators of individual networks can and will decide for themselves whether and when IPv6 is sufficiently operational for their use. Your observation about IPv6's equivalent of an ARP reply using multicast so that it misses wifi's layer 2 error recorvery (and thus performs poorly compared to IPv4) was of value. Got any more or are we ready to move on? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Valdis.Kletnieks at vt.edu Wed Sep 19 23:51:50 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 19 Sep 2012 19:51:50 -0400 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: Your message of "Wed, 19 Sep 2012 18:36:08 -0400." <505A48D8.4040800@ttec.com> References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> <231483E9-5129-4722-87DE-635FEC3AC422@virtualized.org> <505A440D.5080701@dougbarton.us> <505A48D8.4040800@ttec.com> Message-ID: <36217.1348098710@turing-police.cc.vt.edu> On Wed, 19 Sep 2012 18:36:08 -0400, Joe Maimon said: > So 6-8 years to try and rehabilitate 240/4 was not even enough to try? 6 years of work to accomplish something that would only buy us 16 /8s, which would be maybe 2 year's supply, instead of actually deploying IPv6. And at the end of the 2 years, you'll *still* have to do the work of deploying IPv6 That sort of trade-off only makes sense for somebody in *serious* denial. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From jmaimon at ttec.com Thu Sep 20 00:50:12 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Wed, 19 Sep 2012 20:50:12 -0400 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <36217.1348098710@turing-police.cc.vt.edu> References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> <231483E9-5129-4722-87DE-635FEC3AC422@virtualized.org> <505A440D.5080701@dougbarton.us> <505A48D8.4040800@ttec.com> <36217.1348098710@turing-police.cc.vt.edu> Message-ID: <505A6844.9050703@ttec.com> Valdis.Kletnieks at vt.edu wrote: > On Wed, 19 Sep 2012 18:36:08 -0400, Joe Maimon said: > >> So 6-8 years to try and rehabilitate 240/4 was not even enough to try? > > 6 years of work What I said is that they knew they would have had at least 6 years or _more_ to rehabilitate it, had they made a serious effort at the time. In fact, we still do not know how much "more" is, because the upper bound of more is when IPv4 need actually tapers off and is replaced with IPv6 consumption. When you say you did all you could for IPv4, that is an opinion and hardly an objective one at that. Expect the debates to continue. > to accomplish something that would only buy us 16 /8s, which > would be maybe 2 year's supply, As supply tightens, consumption slows. Lets see how long the last /8 last RIPE. You have no way of knowing what the consumption rate will be in the final days of IPv4 and how much of an impact 16 /8 would make at that point. We are not there yet. > instead of actually deploying IPv6. Right, because it was an either or. > And at the > end of the 2 years, you'll *still* have to do the work of deploying IPv6 That > sort of trade-off only makes sense for somebody in *serious* denial. > Turns out it was a neither. Joe From bonomi at mail.r-bonomi.com Thu Sep 20 00:59:35 2012 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Wed, 19 Sep 2012 19:59:35 -0500 (CDT) Subject: The Department of Work and Pensions, UK has an entire /8 nanog@nanog.org In-Reply-To: <4F38CD88-0188-4B0F-9F94-7F088644EEB6@netconsonance.com> Message-ID: <201209200059.q8K0xZ4f060923@mail.r-bonomi.com> > From: Jo Rhett > Date: Wed, 19 Sep 2012 10:42:30 -0700 > Subject: Re: The Department of Work and Pensions, UK has an entire /8 [[ sneck ]] > > And second, have you ever worked on a private intranet that wasn't > connected to the internet through a firewall? Skipping oob networks for > equipment management, neither have I. Yes, in fact, I have. In the financial and/or brokerage communities, there are internal networks with enough 'high value'/sensitive information to justify "air gap" isolation from the outide world. Also, in those industries, there are 'semi-isolated' networks where all external commnications are mediated through dual-homed _application- layer_ gateways. No packet-level communications between 'inside' and 'outside'. The 'inside' apps onl know how to talk to the gateway; server- side talks only to specific (pre-determined) trusted hosts for the specific request being processed. NO 'transparent pass-through' in either direction. From mohta at necom830.hpcl.titech.ac.jp Thu Sep 20 01:24:03 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 20 Sep 2012 10:24:03 +0900 Subject: Big Temporary Networks In-Reply-To: References: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> <50561ADD.2040404@necom830.hpcl.titech.ac.jp> <505626A2.1090700@foobar.org> <505663DE.7000309@necom830.hpcl.titech.ac.jp> <50586620.6080702@necom830.hpcl.titech.ac.jp> <505973A4.90705@necom830.hpcl.titech.ac.jp> <505A40CD.8030701@necom830.hpcl.titech.ac.jp> Message-ID: <505A7033.6040807@necom830.hpcl.titech.ac.jp> William Herrin wrote: > I think Masataka meant to say (and said previously) that the DHCP > request from the wifi station is, like all packets from the wifi > station to the AP, subject to wifi's layer 2 error recovery. It's not > unicast but its subject to error recovery anyway. Mostly correct. But, as I already wrote: 1) broadcast/multicast from a STA attacked to an AP is actually unicast to the AP and reliably received by the AP (and relayed unreliably to other STAs). That is, a broadcast ARP request from the STA to the AP is reliably received by the AP. Because of hidden terminals, L2 broadcast/multicast is transmitted only from AP. >> However, at WiFi L2, it is first unicast to AP and then broadcast >> by the AP. > > Your use of nomenclature is incorrect. It'd be like saying my ethernet Ethernet? > card unicasts a packet to the switch and then the switch broadcasts it > out all ports. Or like saying that a packet with an explicit MAC > destination Do you know MAC header of 802.11 contains four, not just source and destination, MAC addresses? Because of hidden terminals and because of impossibility of collision detection, WLAN is a little more complex than your guess. > No offense, but it is not for you or I or Owen Delong to declare that > IPv6 is or isn't operational. A single counter example is enough to deny IPv6 operational. > whether and when IPv6 is sufficiently > operational for their use. The scope is not "their use" but "as a protocol for the entire Internet". Masataka Ohta From jrhett at netconsonance.com Thu Sep 20 01:46:54 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed, 19 Sep 2012 18:46:54 -0700 Subject: The Department of Work and Pensions, UK has an entire /8 nanog@nanog.org In-Reply-To: <201209200059.q8K0xZ4f060923@mail.r-bonomi.com> References: <201209200059.q8K0xZ4f060923@mail.r-bonomi.com> Message-ID: <2645353A-AE47-4EB6-8ED7-A4FFBFCDC40F@netconsonance.com> On Sep 19, 2012, at 5:59 PM, Robert Bonomi wrote: > In the financial and/or brokerage communities, there are internal networks > with enough 'high value'/sensitive information to justify "air gap" > isolation from the outide world. > > Also, in those industries, there are 'semi-isolated' networks where > all external commnications are mediated through dual-homed _application- > layer_ gateways. No packet-level communications between 'inside' and > 'outside'. The 'inside' apps onl know how to talk to the gateway; server- > side talks only to specific (pre-determined) trusted hosts for the > specific request being processed. NO 'transparent pass-through' in > either direction. You're all missing the point in grand style. If you would stop trying to brag about something that nearly everyone has done in their career and pay attention to the topic you'd realize what my point was. This is the last time I'm going to say this. Not only do I know well those networks, I was the admin responsible for the largest commercial one (56k routes) in existence that I'm aware of. I was at one point cooperatively responsible for a very large one in SEANet as well. (120k routes, 22k offices) I get what you are talking about. That's not what I am saying. For these networks to have gateways which connect to the outside, you have to have an understanding of which IP networks are inside, and which IP networks are outside. Your proxy client then forwards connections to "outside" networks to the gateway. You can't use the same networks inside and outside of the gateway. It doesn't work. The gateway and the proxy clients need to know which way to route those packets. THUS: you can't have your own IP space re-used by another company on the Internet without breaking routing. Duh. RFC1918 is a cooperative venture in doing exactly this, but you simply can't use RFC1918 space if you also connect to a diverse set of other businesses/units/partners/etc. AND there is no requirement in any IP allocation document that you must use RFC1918 space. So acquiring unique space and using it internally has always been legal and permitted. Now let's avoid deliberately misunderstanding me again, alright? -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. From trejrco at gmail.com Thu Sep 20 01:59:19 2012 From: trejrco at gmail.com (TJ) Date: Wed, 19 Sep 2012 21:59:19 -0400 Subject: Big Temporary Networks In-Reply-To: <505A7033.6040807@necom830.hpcl.titech.ac.jp> References: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> <50561ADD.2040404@necom830.hpcl.titech.ac.jp> <505626A2.1090700@foobar.org> <505663DE.7000309@necom830.hpcl.titech.ac.jp> <50586620.6080702@necom830.hpcl.titech.ac.jp> <505973A4.90705@necom830.hpcl.titech.ac.jp> <505A40CD.8030701@necom830.hpcl.titech.ac.jp> <505A7033.6040807@necom830.hpcl.titech.ac.jp> Message-ID: On Wed, Sep 19, 2012 at 9:24 PM, Masataka Ohta < mohta at necom830.hpcl.titech.ac.jp> wrote: > > A single counter example is enough to deny IPv6 operational. > > Really? If that is really your opinion, the entire conversation is a rather moot point as I believe you and "pretty much the rest of the world" (again, including all those who helped develop and have deployed / are deploying IPv6) are not in agreement. *Not saying popularity equals correctness, just that there is a sizable counter-point to your statement. * Yes, the goal should be to minimize the "special cases" but there will always some of those. That is what the ~"IPv6 over Foo" series of documents is all about, accommodating those needs ... A "single counter example" is *only *enough to say that IPv6 does not *currently/ideally* fit *that* deployment scenario and that, just perhaps, *that deployment* needs some special consideration(s) on the part of IPv6. It does not, in any way, invalidate the protocol as a whole. Let me ask, in your opinion: Is the "better and easier" answer here to start from scratch, or to identify the problem(s) and simply fix it(them) if warranted? /TJ From Valdis.Kletnieks at vt.edu Thu Sep 20 01:59:56 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 19 Sep 2012 21:59:56 -0400 Subject: The Department of Work and Pensions, UK has an entire /8 nanog@nanog.org In-Reply-To: Your message of "Wed, 19 Sep 2012 18:46:54 -0700." <2645353A-AE47-4EB6-8ED7-A4FFBFCDC40F@netconsonance.com> References: <201209200059.q8K0xZ4f060923@mail.r-bonomi.com> <2645353A-AE47-4EB6-8ED7-A4FFBFCDC40F@netconsonance.com> Message-ID: <42099.1348106396@turing-police.cc.vt.edu> On Wed, 19 Sep 2012 18:46:54 -0700, Jo Rhett said: > You're all missing the point in grand style. Given that the entire thread is based on somebody who missed the point in totally grand style and managed to get press coverage of said missing the point, I am starting to suspect that several people in the thread are doing so intentionally to see how hard they can troll the NANOG list without anybody catching on. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From rbf+nanog at panix.com Thu Sep 20 02:09:20 2012 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Wed, 19 Sep 2012 21:09:20 -0500 Subject: The Department of Work and Pensions, UK has an entire /8 nanog@nanog.org In-Reply-To: <2645353A-AE47-4EB6-8ED7-A4FFBFCDC40F@netconsonance.com> References: <201209200059.q8K0xZ4f060923@mail.r-bonomi.com> <2645353A-AE47-4EB6-8ED7-A4FFBFCDC40F@netconsonance.com> Message-ID: <20120920020920.GA16558@panix.com> On Wed, Sep 19, 2012 at 06:46:54PM -0700, Jo Rhett wrote: > > For these networks to have gateways which connect to the outside, you > have to have an understanding of which IP networks are inside, and > which IP networks are outside. Your proxy client then forwards > connections to "outside" networks to the gateway. You can't use the > same networks inside and outside of the gateway. It doesn't work. The > gateway and the proxy clients need to know which way to route those > packets. It works fine if the gateway has multiple routing tables (VRF or equivalent) and application software that is multiple-routing-table aware. Not disagreeing at all with the point many are making that "not on the Internet" doesn't mean "not in use". Many people for good reason decide to use globally unique space on networks that are not connected to the Internet. But the idea that you *can't* tie two networks togethor with an application gateway unless the address space is unique is an overstatement. It's just harder. -- Brett From mysidia at gmail.com Thu Sep 20 02:32:00 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 19 Sep 2012 21:32:00 -0500 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <20120919132416.GA28155@jeeves.rigozsaurus.com> References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> <20120919132416.GA28155@jeeves.rigozsaurus.com> Message-ID: On 9/19/12, John Osmon wrote: > On Wed, Sep 19, 2012 at 12:07:33AM -0500, Jimmy Hess wrote: >> But your unconnected network, is unaffected. > Ahh... But the network may not be unconnected. Just because *you* > don't have a path to it doesn't mean others are similarly disconnected. I'm aware of the existence of networks that are only connected to limited number of networks. The fact that they exist, doesn't particularly diminish the danger, that their "apparently unused" addressing will become a target for someone. It would be wrong and broken, but that doesn't mean it is not going to happen. > Such a network would not have $0 in loss/damage when the partners can't > reach it due to a rogue announcement. If they wanted to make a case about it, they would likely need to find evidence that outweighs even their own negligence in the matter. There's no accepted practice that says accept inter-domain announcements for your own prefixes that aren't supposed to be announced outside your network.... The announcement also wouldn't be rogue, if the announcer had persuaded the RIR under whatever policy was in effect at the time, to assign the addresses. There's a fork there, between two different sorts of risks.... * (Non-legitimate) Example: Some networks run by massive Tier 1 providers that for whatever reason decides to stop accepting the whole concept of "unconnected networks", an example of this would be Bell Canada, Level3, ATT, or Verizon just decides to pick some random /8 they see as "unconnected", claim that /8 and start announcing it, and starts renumbering massive numbers of CPEs into the space. Within a couple weeks, each of the other Tier 1s, "grabs" one of those "unconnected" /8s; or the Tier1's work out a deal to share it, totally outside the RIR process. A second similar, but totally unrelated risk, for the operator of the unconnected network, is their RIR policies are adjusted, and revokation of the " perceived unconnected" /8 becomes imminent. > The Internet is not the same from all viewpoints. That works, until there is a sufficient scarcity of resources to make major players desparate. Ultimately it will be the management of networks with the largest numbers of eyeballs, that decide which viewpoint is "correct". -- -JH From leo.vegoda at icann.org Thu Sep 20 02:52:42 2012 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 19 Sep 2012 19:52:42 -0700 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <505A6844.9050703@ttec.com> References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> <231483E9-5129-4722-87DE-635FEC3AC422@virtualized.org> <505A440D.5080701@dougbarton.us> <505A48D8.4040800@ttec.com> <36217.1348098710@turing-police.cc.vt.edu> <505A6844.9050703@ttec.com> Message-ID: On Sep 19, 2012, at 5:50 pm, Joe Maimon wrote: [?] >>> So 6-8 years to try and rehabilitate 240/4 was not even enough to try? >> >> 6 years of work > > What I said is that they knew they would have had at least 6 years or > _more_ to rehabilitate it, had they made a serious effort at the time. Remind me, who is "they"? I remember this: http://tools.ietf.org/html/draft-fuller-240space-02 and this: http://tools.ietf.org/html/draft-wilson-class-e-02 There was even a dedicated mailing list. But the drafts never made it beyond drafts, which suggests there was not a consensus in favour of an extra 18 months of IPv4 space with dubious utility value because of issues with deploy-and-forget equipment out in the wild. The consensus seems to have been in favour of skipping 240/4 and just getting on with deploying IPv6, which everyone would have to do anyway no matter what. Is that so terrible? Regards, Leo -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4359 bytes Desc: not available URL: From dougb at dougbarton.us Thu Sep 20 03:06:16 2012 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 19 Sep 2012 20:06:16 -0700 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <505A48D8.4040800@ttec.com> References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> <231483E9-5129-4722-87DE-635FEC3AC422@virtualized.org> <505A440D.5080701@dougbarton.us> <505A48D8.4040800@ttec.com> Message-ID: <505A8828.9040105@dougbarton.us> On 09/19/2012 15:36, Joe Maimon wrote: > So 6-8 years to try and rehabilitate 240/4 was not even enough to try? All the experts I consulted with told me that the effort to make this workable on the big-I Internet, not to mention older private networks; would be equivalent if not greater than the effort to deploy v6 ... and obviously with much less long-term benefit. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From marka at isc.org Thu Sep 20 03:24:09 2012 From: marka at isc.org (Mark Andrews) Date: Thu, 20 Sep 2012 13:24:09 +1000 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: Your message of "Wed, 19 Sep 2012 20:06:16 MST." <505A8828.9040105@dougbarton.us> References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> <231483E9-5129-4722-87DE-635FEC3AC422@virtualized.org> <505A440D.5080701@dougbarton.us> <505A48D8.4040800@ttec.com> <505A8828.9040105@dougbarton.us> Message-ID: <20120920032409.6ADF82572F18@drugs.dv.isc.org> In message <505A8828.9040105 at dougbarton.us>, Doug Barton writes: > On 09/19/2012 15:36, Joe Maimon wrote: > > So 6-8 years to try and rehabilitate 240/4 was not even enough to try? > > All the experts I consulted with told me that the effort to make this > workable on the big-I Internet, not to mention older private networks; > would be equivalent if not greater than the effort to deploy v6 ... and > obviously with much less long-term benefit. > > Doug And for those cases I would agree with you and the experts. However it would have been possible to use 240/4 between CPE and a 6rd BR and CGN with CPE signaling that it can use 240/4 address it is assigned one. This could be done incrementally and would have been better than the /10 that was eventually allocated for that purpose. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mohta at necom830.hpcl.titech.ac.jp Thu Sep 20 03:33:10 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 20 Sep 2012 12:33:10 +0900 Subject: Big Temporary Networks In-Reply-To: References: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> <50561ADD.2040404@necom830.hpcl.titech.ac.jp> <505626A2.1090700@foobar.org> <505663DE.7000309@necom830.hpcl.titech.ac.jp> <50586620.6080702@necom830.hpcl.titech.ac.jp> <505973A4.90705@necom830.hpcl.titech.ac.jp> <505A40CD.8030701@necom830.hpcl.titech.ac.jp> <505A7033.6040807@necom830.hpcl.titech.ac.jp> Message-ID: <505A8E76.3030800@necom830.hpcl.titech.ac.jp> TJ wrote: >> A single counter example is enough to deny IPv6 operational. > Really? With the Internet wide scope, yes, of course. In general, as IPv6 was designed to make "ND uber Alles", not "IP uber Alles", and ND was designed by a committee with only ATM, Ethernet and PPP in mind, ND can not be an adaptation mechanism to run IP over various link with link specific properties. Thus, even though people only using Ethernet and PPP might think ND is good enough, a single example of a link is enough to deny "ND uber Alles". Though you wrote: > I think it is safe to say that this is provably false. it is impossible because it is "probatio diabolica". Instead, a single counter example is enough to totally deny "probatio diabolica". Or, if you need another example on how poorly ND behaves under some environment, it's timing constraints are specified mostly in units of "second", not "millisecond", because the IPv6 committee silently assumed that hosts are immobile. Thus, latency imposed by ND is often too large for links with quickly moving objects. Never claim IPv6 operational with your narrowly scoped experiences, because what you are attempting to do is "probatio diabolica". > That is what the ~"IPv6 over Foo" series of > documents is all about, accommodating those needs ... Because "ND uber Alles" is impossible, "IPv6 over Foo" series specifying ND parameters are not helpful. Masataka Ohta From jmaimon at ttec.com Thu Sep 20 04:21:45 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Thu, 20 Sep 2012 00:21:45 -0400 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> <231483E9-5129-4722-87DE-635FEC3AC422@virtualized.org> <505A440D.5080701@dougbarton.us> <505A48D8.4040800@ttec.com> <36217.1348098710@turing-police.cc.vt.edu> <505A6844.9050703@ttec.com> Message-ID: <505A99D9.6010109@ttec.com> Leo Vegoda wrote: > > There was even a dedicated mailing list. But the drafts never made it beyond drafts, which suggests there was not a consensus in favour of an extra 18 months of IPv4 space with dubious utility value because of issues with deploy-and-forget equipment out in the wild. > > The consensus seems to have been in favour of skipping 240/4 and just getting on with deploying IPv6, which everyone would have to do anyway no matter what. Is that so terrible? > > Regards, > > Leo > Thats one suggestion. There are others. I cant determine which is more prevalent, the IPv4 hate or the IPv6 victim mentality. How does hindsight slow-mo replay this call of consensus? Why is this cast as a boolean choice? And how has the getting on with IPv6 deployment been working out? That the discussion continues is in and of itself a verdict. Joe From dmiller at tiggee.com Thu Sep 20 04:38:32 2012 From: dmiller at tiggee.com (David Miller) Date: Thu, 20 Sep 2012 00:38:32 -0400 Subject: Big Temporary Networks In-Reply-To: <505A8E76.3030800@necom830.hpcl.titech.ac.jp> References: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> <50561ADD.2040404@necom830.hpcl.titech.ac.jp> <505626A2.1090700@foobar.org> <505663DE.7000309@necom830.hpcl.titech.ac.jp> <50586620.6080702@necom830.hpcl.titech.ac.jp> <505973A4.90705@necom830.hpcl.titech.ac.jp> <505A40CD.8030701@necom830.hpcl.titech.ac.jp> <505A7033.6040807@necom830.hpcl.titech.ac.jp> <505A8E76.3030800@necom830.hpcl.titech.ac.jp> Message-ID: <505A9DC8.2040508@tiggee.com> On 9/19/2012 11:33 PM, Masataka Ohta wrote: > TJ wrote: > >>> >> A single counter example is enough to deny IPv6 operational. >> > Really? > With the Internet wide scope, yes, of course. So, a single example of IPv4 behaving in a suboptimal manner would be enough to declare IPv4 not operational? Reductio ad absurdum -DMM From mysidia at gmail.com Thu Sep 20 04:58:21 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 19 Sep 2012 23:58:21 -0500 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <505A99D9.6010109@ttec.com> References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> <231483E9-5129-4722-87DE-635FEC3AC422@virtualized.org> <505A440D.5080701@dougbarton.us> <505A48D8.4040800@ttec.com> <36217.1348098710@turing-police.cc.vt.edu> <505A6844.9050703@ttec.com> <505A99D9.6010109@ttec.com> Message-ID: On 9/19/12, Joe Maimon wrote: > Why is this cast as a boolean choice? And how has the getting on with > IPv6 deployment been working out? "getting a single extra /4" is considered, not enough of a return to make the change. I don't accept that, but as far as rehabilitating 240/4, that lot was already cast, I think, and the above was the likely reason, there have been plenty of objections which all amounted to "too much trouble to lift the pen" and change it..... So if you want some address space rehabilitated, by a change of standard, it apparently needs to be more than a /4. There is still no technical reason that 240/4 cannot be rehabilitated, other than continued immaterial objections to doing anything at all with 240/4, and given the rate of IPv6 adoption thus far, if not for those, it could possibly be reopened as unicast IPv4, and be well-supported by new equipment, before the percentage of IPv6-enabled network activity reaches a double digit percentage... > That the discussion continues is in and of itself a verdict. > Joe -- -JH From johnl at iecc.com Thu Sep 20 05:18:16 2012 From: johnl at iecc.com (John Levine) Date: 20 Sep 2012 05:18:16 -0000 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <505A48D8.4040800@ttec.com> Message-ID: <20120920051816.90377.qmail@joyce.lan> >So 6-8 years to try and rehabilitate 240/4 was not even enough to try? Since it would require upgrading the IP stack on every host on the internet, uh, no. If you're planning to do that, you might as well make the upgrade handle IPv6. >> and no quantity of pixie dust is going to >> cause new space to appear out of thin air. No, but money can work wonders, once the IP address space market comes out of the shadows. R's, John From kyhwana at gmail.com Thu Sep 20 05:20:04 2012 From: kyhwana at gmail.com (Daniel Richards) Date: Thu, 20 Sep 2012 17:20:04 +1200 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> <231483E9-5129-4722-87DE-635FEC3AC422@virtualized.org> <505A440D.5080701@dougbarton.us> <505A48D8.4040800@ttec.com> <36217.1348098710@turing-police.cc.vt.edu> <505A6844.9050703@ttec.com> <505A99D9.6010109@ttec.com> Message-ID: > > There is still no technical reason that 240/4 cannot be > rehabilitated, other than continued immaterial objections to doing > anything at all with 240/4, and given the rate of IPv6 adoption thus > far, if not for those, it could possibly be reopened as unicast IPv4, > and be well-supported by new equipment, before the percentage of > IPv6-enabled network activity reaches a double digit percentage... Don't most IP stacks (still) consider 240/8 and above "illegal addresses" and won't deal with packets to/from those addresses? If that's still the case, it'd be another good 10-20 years before 240/8 and above could be released for general use, as nothing would work with them. In that case, you might as well start rolling out IPv6 and any new hardware/software changes ready for v6. From marka at isc.org Thu Sep 20 05:34:23 2012 From: marka at isc.org (Mark Andrews) Date: Thu, 20 Sep 2012 15:34:23 +1000 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: Your message of "Wed, 19 Sep 2012 23:58:21 EST." References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> <231483E9-5129-4722-87DE-635FEC3AC422@virtualized.org> <505A440D.5080701@dougbarton.us> <505A48D8.4040800@ttec.com> <36217.1348098710@turing-police.cc.vt.edu> <505A6844.9050703@ttec.com> <505A99D9.6010109@ttec.com> Message-ID: <20120920053424.83A482575D2E@drugs.dv.isc.org> In message , Jimmy Hess writes: > On 9/19/12, Joe Maimon wrote: > > > Why is this cast as a boolean choice? And how has the getting on with > > IPv6 deployment been working out? > > "getting a single extra /4" is considered, not enough of a return > to make the change. > > I don't accept that, but as far as rehabilitating 240/4, that lot > was already cast, I think, and the above was the likely reason, there > have been plenty of objections which all amounted to "too much > trouble to lift the pen" and change it..... > > So if you want some address space rehabilitated, by a change of > standard, it apparently needs to be more than a /4. > > > There is still no technical reason that 240/4 cannot be > rehabilitated, other than continued immaterial objections to doing > anything at all with 240/4, and given the rate of IPv6 adoption thus > far, if not for those, it could possibly be reopened as unicast IPv4, > and be well-supported by new equipment, before the percentage of > IPv6-enabled network activity reaches a double digit percentage... The work to fix this on most OS is minimal. The work to ensure that it could be used safely over the big I Internet is enormous. It's not so much about making sure new equipment can support it than getting servers that don't support it upgraded as well as every box in between. > > That the discussion continues is in and of itself a verdict. > > Joe > -- > -JH > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From seth.mos at dds.nl Thu Sep 20 05:49:47 2012 From: seth.mos at dds.nl (Seth Mos) Date: Thu, 20 Sep 2012 07:49:47 +0200 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <20120920053424.83A482575D2E@drugs.dv.isc.org> References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> <231483E9-5129-4722-87DE-635FEC3AC422@virtualized.org> <505A440D.5080701@dougbarton.us> <505A48D8.4040800@ttec.com> <36217.1348098710@turing-police.cc.vt.edu> <505A6844.9050703@ttec.com> <505A99D9.6010109@ttec.com> <20120920053424.83A482575D2E@drugs.dv.isc.org> Message-ID: Op 20 sep 2012, om 07:34 heeft Mark Andrews het volgende geschreven: > > In message > , Jimmy Hess writes: > > The work to fix this on most OS is minimal. The work to ensure > that it could be used safely over the big I Internet is enormous. > It's not so much about making sure new equipment can support it > than getting servers that don't support it upgraded as well as every > box in between. I'm only afraid it may operate worse then 1/8. Not sure how happy you would be as an ISP or a customer in that range. Cheers, Seth From mohta at necom830.hpcl.titech.ac.jp Thu Sep 20 06:21:21 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 20 Sep 2012 15:21:21 +0900 Subject: Big Temporary Networks In-Reply-To: <505A9DC8.2040508@tiggee.com> References: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> <50561ADD.2040404@necom830.hpcl.titech.ac.jp> <505626A2.1090700@foobar.org> <505663DE.7000309@necom830.hpcl.titech.ac.jp> <50586620.6080702@necom830.hpcl.titech.ac.jp> <505973A4.90705@necom830.hpcl.titech.ac.jp> <505A40CD.8030701@necom830.hpcl.titech.ac.jp> <505A7033.6040807@necom830.hpcl.titech.ac.jp> <505A8E76.3030800@necom830.hpcl.titech.ac.jp> <505A9DC8.2040508@tiggee.com> Message-ID: <505AB5E1.7080204@necom830.hpcl.titech.ac.jp> David Miller wrote: > So, a single example of IPv4 behaving in a suboptimal manner would be > enough to declare IPv4 not operational? For example? Masataka Ohta From george.herbert at gmail.com Thu Sep 20 07:09:50 2012 From: george.herbert at gmail.com (George Herbert) Date: Thu, 20 Sep 2012 00:09:50 -0700 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> <231483E9-5129-4722-87DE-635FEC3AC422@virtualized.org> <505A440D.5080701@dougbarton.us> <505A48D8.4040800@ttec.com> <36217.1348098710@turing-police.cc.vt.edu> <505A6844.9050703@ttec.com> <505A99D9.6010109@ttec.com> Message-ID: On Sep 19, 2012, at 9:58 PM, Jimmy Hess wrote: > There is still no technical reason that 240/4 cannot be > rehabilitated, other than continued immaterial objections to doing > anything at all with 240/4, and given the rate of IPv6 adoption thus > far, if not for those, it could possibly be reopened as unicast IPv4, > and be well-supported by new equipment, before the percentage of > IPv6-enabled network activity reaches a double digit percentage... Excellent idea. Now build a time machine, go back to 2005, and start work. It will be somewhat less relevant of a solution by 2019, which is about when you finish if you start today... The market window is closed. George William Herbert Sent from my iPhone From joelja at bogus.com Thu Sep 20 07:21:28 2012 From: joelja at bogus.com (joel jaeggli) Date: Thu, 20 Sep 2012 00:21:28 -0700 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> <231483E9-5129-4722-87DE-635FEC3AC422@virtualized.org> <505A440D.5080701@dougbarton.us> <505A48D8.4040800@ttec.com> <36217.1348098710@turing-police.cc.vt.edu> <505A6844.9050703@ttec.com> <505A99D9.6010109@ttec.com> Message-ID: <505AC3F8.9060905@bogus.com> On 9/20/12 12:09 AM, George Herbert wrote: > > On Sep 19, 2012, at 9:58 PM, Jimmy Hess wrote: > >> There is still no technical reason that 240/4 cannot be >> rehabilitated, other than continued immaterial objections to doing >> anything at all with 240/4, and given the rate of IPv6 adoption thus >> far, if not for those, it could possibly be reopened as unicast IPv4, >> and be well-supported by new equipment, before the percentage of >> IPv6-enabled network activity reaches a double digit percentage... > > Excellent idea. Now build a time machine, go back to 2005, and start work. Sorry it was a bad idea then, it's still a bad idea. > > The market window is closed. yes > > George William Herbert > Sent from my iPhone > > > > From bonomi at mail.r-bonomi.com Thu Sep 20 07:31:54 2012 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Thu, 20 Sep 2012 02:31:54 -0500 (CDT) Subject: The Department of Work and Pensions, UK has an entire /8 nanog@nanog.org In-Reply-To: <2645353A-AE47-4EB6-8ED7-A4FFBFCDC40F@netconsonance.com> Message-ID: <201209200731.q8K7Vs12062627@mail.r-bonomi.com> > From jrhett at netconsonance.com Wed Sep 19 20:47:44 2012 > Subject: Re: The Department of Work and Pensions, UK has an entire /8 nanog at nanog.org > From: Jo Rhett > Date: Wed, 19 Sep 2012 18:46:54 -0700 > Cc: nanog at nanog.org > To: Robert Bonomi > > > --Apple-Mail=_C592EED8-365E-43DB-A1B1-35875736F2F8 > Content-Transfer-Encoding: quoted-printable > Content-Type: text/plain; > charset=us-ascii > > On Sep 19, 2012, at 5:59 PM, Robert Bonomi wrote: > > In the financial and/or brokerage communities, there are internal = > networks > > with enough 'high value'/sensitive information to justify "air gap" > > isolation from the outide world.=20 > >=20 > > Also, in those industries, there are 'semi-isolated' networks where > > all external commnications are mediated through dual-homed = > _application- > > layer_ gateways. No packet-level communications between 'inside' and > > 'outside'. The 'inside' apps onl know how to talk to the gateway; = > server- > > side talks only to specific (pre-determined) trusted hosts for the > > specific request being processed. NO 'transparent pass-through' in > > either direction. > > > You're all missing the point in grand style. If you would stop trying = > to brag about something that nearly everyone has done in their career = > and pay attention to the topic you'd realize what my point was. This is = > the last time I'm going to say this.=20 > > Not only do I know well those networks, I was the admin responsible for = > the largest commercial one (56k routes) in existence that I'm aware of. = > I was at one point cooperatively responsible for a very large one in = > SEANet as well. (120k routes, 22k offices) I get what you are talking = > about. That's not what I am saying. > > For these networks to have gateways which connect to the outside, you = > have to have an understanding of which IP networks are inside, and which = > IP networks are outside. Your proxy client then forwards connections to = > "outside" networks to the gateway. You can't use the same networks = > inside and outside of the gateway. It doesn't work. The gateway and the = > proxy clients need to know which way to route those packets.=20 > > THUS: you can't have your own IP space re-used by another company on the = > Internet without breaking routing. Duh. > > RFC1918 is a cooperative venture in doing exactly this, but you simply = > can't use RFC1918 space if you also connect to a diverse set of other = > businesses/units/partners/etc. AND there is no requirement in any IP = > allocation document that you must use RFC1918 space. So acquiring unique = > space and using it internally has always been legal and permitted. > > Now let's avoid deliberately misunderstanding me again, alright? > > --=20 > Jo Rhett > Net Consonance : net philanthropy to improve open source and internet = > projects. > > > > > --Apple-Mail=_C592EED8-365E-43DB-A1B1-35875736F2F8 > Content-Transfer-Encoding: quoted-printable > Content-Type: text/html; > charset=us-ascii > > -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = > ">
On Sep 19, 2012, at 5:59 PM, Robert Bonomi = > wrote:
In the financial and/or = > brokerage communities, there are internal networks
with enough 'high = > value'/sensitive information to justify "air gap"
isolation from the = > outide world.

Also, in those industries, there are = > 'semi-isolated' networks where
all external commnications are = > mediated through dual-homed _application-
layer_ gateways. No = > packet-level communications between 'inside' and
'outside'.  The = > 'inside' apps onl know how to talk to the gateway; server-
side talks = > only to specific (pre-determined) trusted hosts for the
specific = > request being processed.  NO 'transparent pass-through' = > in
either = > direction.

You're all missing = > the point in grand style.  If you would stop trying to brag about = > something that nearly everyone has done in their career and pay = > attention to the topic you'd realize what my point was. This is the last = > time I'm going to say this. 

Not only do I know = > well those networks, I was the admin responsible for the largest = > commercial one (56k routes) in existence that I'm aware of. I was at one = > point cooperatively responsible for a very large one in SEANet as well. = > (120k routes, 22k offices) I get what you are talking about. That's not = > what I am saying.

For these networks to have = > gateways which connect to the outside, you have to have an understanding = > of which IP networks are inside, and which IP networks are outside. Your = > proxy client then forwards connections to "outside" networks to the = > gateway. You can't use the same networks inside and outside of the = > gateway. It doesn't work. The gateway and the proxy clients need to know = > which way to route those packets. 

THUS: = > you can't have your own IP space re-used by another company on the = > Internet without breaking routing. Duh.

RFC1918 = > is a cooperative venture in doing exactly this, but you simply can't use = > RFC1918 space if you also connect to a diverse set of other = > businesses/units/partners/etc. AND there is no requirement in any = > IP allocation document that you must use RFC1918 space. So acquiring = > unique space and using it internally has always been legal and = > permitted.

Now let's avoid deliberately = > misunderstanding me again, alright?

> color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; = > font-variant: normal; font-weight: normal; letter-spacing: normal; = > line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: = > 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: = > 0px; -webkit-border-horizontal-spacing: 0px; = > -webkit-border-vertical-spacing: 0px; = > -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = > auto; -webkit-text-stroke-width: 0px; font-size: medium; "> class=3D"Apple-style-span" style=3D"font-size: 12px; ">
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = > margin-left: 0px; "> normal normal normal 12px/normal Helvetica; ">-- 
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = > margin-left: 0px; "> normal normal normal 12px/normal Helvetica; ">Jo = > Rhett
 style=3D"font-size: 12px; ">Net Consonance :  class=3D"Apple-style-span" style=3D"font-size: 12px; ">net philanthropy = > to improve open source and internet projects.
class=3D"Apple-style-span" style=3D"border-collapse: separate; color: = > rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: = > normal; font-variant: normal; font-weight: normal; letter-spacing: = > normal; line-height: normal; orphans: 2; text-indent: 0px; = > text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; = > -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = > 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = > auto; -webkit-text-stroke-width: 0px; ">
break-word; -webkit-nbsp-mode: space; -webkit-line-break: = > after-white-space; ">
style=3D"font-size: 12px; ">
0px; margin-bottom: 0px; margin-left: 0px; = > ">

class=3D"Apple-interchange-newline"> >
>
= > > --Apple-Mail=_C592EED8-365E-43DB-A1B1-35875736F2F8-- > From kemp at network-services.uoregon.edu Thu Sep 20 07:34:43 2012 From: kemp at network-services.uoregon.edu (John Kemp) Date: Thu, 20 Sep 2012 00:34:43 -0700 Subject: IMPLEMENTING A SOFTWARE BASED ROUTE SERVER In-Reply-To: <20120919122952.GT90817@macbook.bluepipe.net> References: <9be1f04b-6f4d-4d68-b11b-800519832f77@MX-IX-NBO> <122ed7f9-a760-4aea-9abe-da7572de9385@MX-IX-NBO> <20120919122952.GT90817@macbook.bluepipe.net> Message-ID: <505AC713.5050004@network-services.uoregon.edu> On 9/19/12 5:29 AM, Phil Regnauld wrote: > Joseph M. Owino (jpmuga) writes: >> Hi, >> >> Hope you are all well. I work at an exchange point and was seeking any assistance on how to implement a software based route server as currently we are using a Cisco Router for that purpose. Any form of assistance will be highly appreciated. > Hello Joseph, > > You could do this in a number of ways, running Quagga or BIRD (or even > BGPD) on a Linux or BSD server. > > Quagga documentation even has a chapter on this: > > http://www.nongnu.org/quagga/docs/quagga.html#SEC115 > > > I'm sure several people on this list have experience with this and will > contribute. Also, it might be send this inquiry to the AfNOG list as well > (afnog.org). > > Finally (plug) we have some resources that may be of interest to you here: > > https://nsrc.org/route-bgp-ixp.html > > Cheers, > Phil > Thought I would add some more links (Bird related...). Seems like the genesis has been from a single-rib on the RS to RIBs-per-client. And more recently to using the IRRs for additional filtering options. AMS-IX for example: https://www.ams-ix.net/technical/specifications-descriptions/ams-ix-route-servers Here's that BIRD stuff... http://www.peering-forum.eu/epf3/presentations/day1/inex-epf-dublin-2008-09-15-01.pdf https://git.nic.cz/redmine/projects/bird/wiki/Route_server_with_community_based_filtering http://www.mail-archive.com/bird-users at atrey.karlin.mff.cuni.cz/msg00505.html John Kemp (kemp at routeviews.org) From george.herbert at gmail.com Thu Sep 20 08:18:18 2012 From: george.herbert at gmail.com (George Herbert) Date: Thu, 20 Sep 2012 01:18:18 -0700 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <505AC3F8.9060905@bogus.com> References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> <231483E9-5129-4722-87DE-635FEC3AC422@virtualized.org> <505A440D.5080701@dougbarton.us> <505A48D8.4040800@ttec.com> <36217.1348098710@turing-police.cc.vt.edu> <505A6844.9050703@ttec.com> <505A99D9.6010109@ttec.com> <505AC3F8.9060905@bogus.com> Message-ID: <8270A4D4-5B82-45B6-BD78-FD3586545D6F@gmail.com> On Sep 20, 2012, at 12:21 AM, joel jaeggli wrote: > On 9/20/12 12:09 AM, George Herbert wrote: >> >> On Sep 19, 2012, at 9:58 PM, Jimmy Hess wrote: >> >>> There is still no technical reason that 240/4 cannot be >>> rehabilitated, other than continued immaterial objections to doing >>> anything at all with 240/4, and given the rate of IPv6 adoption thus >>> far, if not for those, it could possibly be reopened as unicast IPv4, >>> and be well-supported by new equipment, before the percentage of >>> IPv6-enabled network activity reaches a double digit percentage... >> >> Excellent idea. Now build a time machine, go back to 2005, and start work. > > Sorry it was a bad idea then, it's still a bad idea. Bad Idea or not, stopgap or not, it was and remains technically, programmatically, and politically feasible. The critical failure is that starting RIGHT NOW would deliver five years-ish too late, which renders it a moot point. In two or three years we may well regret not having done it in 2005; in seven years we will have had to have solved and deployed IPv6 successfully anyways. We could have started it at a more opportune time in the past. We could also have done other things like a straight IPv4-48 or IPv4-64, without the other protocol suite foo that's delayed IPv6 rollout. Operators could have either used larger baseball bats or more participating numbers to make some IPv6 protocol design go the other way. IETF could have realized they were in Epic Fail by Too Clever territory. All of these things are water under the bridge now. We have what we have. It being amusing to grouse about mistakes of the past does not magically change the present. We have rapidly vanishing IPv4 and no 240/4, IPv6, and no time. That is reality. Pining for 240/4 fjords is not a time machine to change the past. George William Herbert Sent from my iPhone From trejrco at gmail.com Thu Sep 20 13:59:39 2012 From: trejrco at gmail.com (TJ) Date: Thu, 20 Sep 2012 09:59:39 -0400 Subject: Big Temporary Networks In-Reply-To: <505AB5E1.7080204@necom830.hpcl.titech.ac.jp> References: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> <50561ADD.2040404@necom830.hpcl.titech.ac.jp> <505626A2.1090700@foobar.org> <505663DE.7000309@necom830.hpcl.titech.ac.jp> <50586620.6080702@necom830.hpcl.titech.ac.jp> <505973A4.90705@necom830.hpcl.titech.ac.jp> <505A40CD.8030701@necom830.hpcl.titech.ac.jp> <505A7033.6040807@necom830.hpcl.titech.ac.jp> <505A8E76.3030800@necom830.hpcl.titech.ac.jp> <505A9DC8.2040508@tiggee.com> <505AB5E1.7080204@necom830.hpcl.titech.ac.jp> Message-ID: On Thu, Sep 20, 2012 at 2:21 AM, Masataka Ohta < mohta at necom830.hpcl.titech.ac.jp> wrote: > David Miller wrote: > > > So, a single example of IPv4 behaving in a suboptimal manner would be > > enough to declare IPv4 not operational? > > For example? > "Heavy reliance on broadcast for a wide range of instances where the traffic is really only destined for a single node" would seem to be rather sub-optimal. /TJ From jcurran at arin.net Thu Sep 20 14:01:53 2012 From: jcurran at arin.net (John Curran) Date: Thu, 20 Sep 2012 14:01:53 +0000 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <4bd0179a-8e3b-4e1d-b43d-b828bce9117c@mail.pelican.org> References: <4bd0179a-8e3b-4e1d-b43d-b828bce9117c@mail.pelican.org> Message-ID: <9B9685A4-CD22-41E9-957A-23103D2C8F33@corp.arin.net> On Sep 19, 2012, at 5:01 AM, Tim Franklin wrote: >> So...why do you need publicly routable IP addresses if they aren't >> publicly routable? > > Because the RIRs aren't in the business of handing out publicly routable address space. They're in the business of handing out globally unique address space - *one* of the reasons for which may be connection to the "public Internet", whatever that is at any given point in time and space. > > RIPE are really good about making the distinction and using the latter phrase rather than the former. I'm not familiar enough with the corresponding ARIN documents to comment on the language used there. It's very clear in the ARIN region as well. From the ARIN Number Resource Policy Manual (NRPM), - "4.1. General Principles 4.1.1. Routability Provider independent (portable) addresses issued directly from ARIN or other Regional Registries are not guaranteed to be globally routable." FYI, /John John Curran President and CEO ARIN From jeroen at unfix.org Thu Sep 20 14:10:08 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 20 Sep 2012 16:10:08 +0200 Subject: RIRs give out unique addresses (Was: something has a /8! ...) In-Reply-To: <9B9685A4-CD22-41E9-957A-23103D2C8F33@corp.arin.net> References: <4bd0179a-8e3b-4e1d-b43d-b828bce9117c@mail.pelican.org> <9B9685A4-CD22-41E9-957A-23103D2C8F33@corp.arin.net> Message-ID: <505B23C0.4010102@unfix.org> On 2012-09-20 16:01 , John Curran wrote: > On Sep 19, 2012, at 5:01 AM, Tim Franklin wrote: > >>> So...why do you need publicly routable IP addresses if they >>> aren't publicly routable? >> >> Because the RIRs aren't in the business of handing out publicly >> routable address space. They're in the business of handing out >> globally unique address space - *one* of the reasons for which may >> be connection to the "public Internet", whatever that is at any >> given point in time and space. >> >> RIPE are really good about making the distinction and using the >> latter phrase rather than the former. I'm not familiar enough with >> the corresponding ARIN documents to comment on the language used >> there. > > It's very clear in the ARIN region as well. From the ARIN Number > Resource Policy Manual (NRPM), > - > > "4.1. General Principles 4.1.1. Routability Provider independent > (portable) addresses issued directly from ARIN or other Regional > Registries are not guaranteed to be globally routable." While close, that is not the same. The RIPE variant solely guarantees uniqueness of the addresses. The ARIN variant states "we don't guarantee that you can route it everywhere", which is on top of the uniqueness portion. This is quite not what is meant with using it completely off-grid, thus not showing up in the global "Internet" BGP routes anywhere. Greets, Jeroen From jmaimon at ttec.com Thu Sep 20 14:10:40 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Thu, 20 Sep 2012 10:10:40 -0400 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <8270A4D4-5B82-45B6-BD78-FD3586545D6F@gmail.com> References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> <231483E9-5129-4722-87DE-635FEC3AC422@virtualized.org> <505A440D.5080701@dougbarton.us> <505A48D8.4040800@ttec.com> <36217.1348098710@turing-police.cc.vt.edu> <505A6844.9050703@ttec.com> <505A99D9.6010109@ttec.com> <505AC3F8.9060905@bogus.com> <8270A4D4-5B82-45B6-BD78-FD3586545D6F@gmail.com> Message-ID: <505B23E0.4030906@ttec.com> George Herbert wrote: > We could have started it at a more opportune time in the past. We could also have done other things like a straight IPv4-48 or IPv4-64, without the other protocol suite foo that's delayed IPv6 rollout. Operators could have either used larger baseball bats or more participating numbers to make some IPv6 protocol design go the other way. IETF could have realized they were in Epic Fail by Too Clever territory. > > All of these things are water under the bridge now. We have what we have. It being amusing to grouse about mistakes of the past does not magically change the present. We have rapidly vanishing IPv4 and no 240/4, IPv6, and no time. That is reality. > > Pining for 240/4 fjords is not a time machine to change the past. > > > George William Herbert > Sent from my iPhone > What is not amusing is continued evidence that the lessons from this debacle have not been learned. Baking in bogonity is bad. Predicting the (f)utility of starting multi-year efforts in the present for future benefit is self-fulfilling. Let us spin this another way. If you cannot even expect mild change such as 240/4 to become prevalent enough to be useful, on what do you base your optimism that the much larger changes IPv6 requires will? Joe From trejrco at gmail.com Thu Sep 20 14:22:27 2012 From: trejrco at gmail.com (TJ) Date: Thu, 20 Sep 2012 10:22:27 -0400 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <505B23E0.4030906@ttec.com> References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> <231483E9-5129-4722-87DE-635FEC3AC422@virtualized.org> <505A440D.5080701@dougbarton.us> <505A48D8.4040800@ttec.com> <36217.1348098710@turing-police.cc.vt.edu> <505A6844.9050703@ttec.com> <505A99D9.6010109@ttec.com> <505AC3F8.9060905@bogus.com> <8270A4D4-5B82-45B6-BD78-FD3586545D6F@gmail.com> <505B23E0.4030906@ttec.com> Message-ID: > Let us spin this another way. If you cannot even expect mild change such > as 240/4 to become prevalent enough to be useful, on what do you base your > optimism that the much larger changes IPv6 requires will? > > Joe > > Easy - Greater return on the investment; i.e. - instead of getting an IPv4 /4 out of the effort you get an IPv6 Global Unicast Space of 2000::/3 (just for starters, counting neither the rest of the unicast nor multicast, etc. spaces.). Also, the impact of the "changes required" is close to the same in that every node needs to be touched - that is the hard part, getting updates deployed. *(Unless you want 240/4 to be a special/limited use case - in which case the effort is smaller, but so is the reward ...)* /TJ From jcurran at arin.net Thu Sep 20 14:39:35 2012 From: jcurran at arin.net (John Curran) Date: Thu, 20 Sep 2012 14:39:35 +0000 Subject: RIRs give out unique addresses (Was: something has a /8! ...) In-Reply-To: <505B23C0.4010102@unfix.org> References: <4bd0179a-8e3b-4e1d-b43d-b828bce9117c@mail.pelican.org> <9B9685A4-CD22-41E9-957A-23103D2C8F33@corp.arin.net> <505B23C0.4010102@unfix.org> Message-ID: On Sep 20, 2012, at 10:10 AM, Jeroen Massar wrote: > On 2012-09-20 16:01 , John Curran wrote: >> >> It's very clear in the ARIN region as well. From the ARIN Number >> Resource Policy Manual (NRPM), >> - >> >> "4.1. General Principles 4.1.1. Routability Provider independent >> (portable) addresses issued directly from ARIN or other Regional >> Registries are not guaranteed to be globally routable." > > While close, that is not the same. > > The RIPE variant solely guarantees uniqueness of the addresses. > > The ARIN variant states "we don't guarantee that you can route it > everywhere", which is on top of the uniqueness portion. Agreed - I called it out because ARIN, like RIPE, does not assert that the address blocks issued are "publicly routable address space" (i.e. which was Tim Franklin's original statement, but he did not have on hand the comparable ARIN reference for that point.) FYI, /John From jmaimon at ttec.com Thu Sep 20 14:46:17 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Thu, 20 Sep 2012 10:46:17 -0400 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> <231483E9-5129-4722-87DE-635FEC3AC422@virtualized.org> <505A440D.5080701@dougbarton.us> <505A48D8.4040800@ttec.com> <36217.1348098710@turing-police.cc.vt.edu> <505A6844.9050703@ttec.com> <505A99D9.6010109@ttec.com> <505AC3F8.9060905@bogus.com> <8270A4D4-5B82-45B6-BD78-FD3586545D6F@gmail.com> <505B23E0.4030906@ttec.com> Message-ID: <505B2C39.2000601@ttec.com> TJ wrote: >> Let us spin this another way. If you cannot even expect mild change such >> as 240/4 to become prevalent enough to be useful, on what do you base your >> optimism that the much larger changes IPv6 requires will? >> >> Joe >> >> > Easy - Greater return on the investment; i.e. - instead of getting an IPv4 > /4 out of the effort you get an IPv6 Global Unicast Space of 2000::/3 (just > for starters, counting neither the rest of the unicast nor multicast, etc. > spaces.). ::/3 /48 /64 Do you think we may ever come to regret baking that in? And use that regret to torpedo any attempts at change? As far as roi is concerned, we can make all the calculation we want. What we cannot do is force everyone else to come up with the same numbers we did. > Also, the impact of the "changes required" is close to the same in that > every node needs to be touched - that is the hard part, getting updates > deployed. *(Unless you want 240/4 to be a special/limited use case - in > which case the effort is smaller, but so is the reward ...)* > > > /TJ > The scope of the change is far far different, no matter the use case. Never more than a simple update. Joe From SNaslund at medline.com Thu Sep 20 14:56:17 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 20 Sep 2012 09:56:17 -0500 Subject: RIRs give out unique addresses (Was: something has a /8! ...) In-Reply-To: References: <4bd0179a-8e3b-4e1d-b43d-b828bce9117c@mail.pelican.org> <9B9685A4-CD22-41E9-957A-23103D2C8F33@corp.arin.net> <505B23C0.4010102@unfix.org> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0C6FF97D@MUNEXBE1.medline.com> I suppose that ARIN would say that they do not guarantee routability because they do not have operational control of Internet routers. However, Wouldn't you say that there is a very real expectation that when you request address space through ARIN or RIPE that it would be routable? I would think that what ARIN and RIPE are really saying is that they issue unique addresses and you need to get your service provider to route them. FWIW, the discussion of the military having addresses pulled back is pretty much a non-starter unless they want to give them back. When the management of IP address space was moved from the US DoD, there were memorandums of understanding that the military controlled their assigned address space and nothing would change that. I know this for a fact because I was around this discussion in the US Air Force. Steven Naslund -----Original Message----- From: John Curran [mailto:jcurran at arin.net] Sent: Thursday, September 20, 2012 9:40 AM To: Jeroen Massar Cc: NANOG list Subject: Re: RIRs give out unique addresses (Was: something has a /8! ...) On Sep 20, 2012, at 10:10 AM, Jeroen Massar wrote: > On 2012-09-20 16:01 , John Curran wrote: >> >> It's very clear in the ARIN region as well. From the ARIN Number >> Resource Policy Manual (NRPM), >> - >> >> "4.1. General Principles 4.1.1. Routability Provider independent >> (portable) addresses issued directly from ARIN or other Regional >> Registries are not guaranteed to be globally routable." > > While close, that is not the same. > > The RIPE variant solely guarantees uniqueness of the addresses. > > The ARIN variant states "we don't guarantee that you can route it > everywhere", which is on top of the uniqueness portion. Agreed - I called it out because ARIN, like RIPE, does not assert that the address blocks issued are "publicly routable address space" (i.e. which was Tim Franklin's original statement, but he did not have on hand the comparable ARIN reference for that point.) FYI, /John From trejrco at gmail.com Thu Sep 20 14:59:24 2012 From: trejrco at gmail.com (TJ) Date: Thu, 20 Sep 2012 10:59:24 -0400 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <505B2C39.2000601@ttec.com> References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> <231483E9-5129-4722-87DE-635FEC3AC422@virtualized.org> <505A440D.5080701@dougbarton.us> <505A48D8.4040800@ttec.com> <36217.1348098710@turing-police.cc.vt.edu> <505A6844.9050703@ttec.com> <505A99D9.6010109@ttec.com> <505AC3F8.9060905@bogus.com> <8270A4D4-5B82-45B6-BD78-FD3586545D6F@gmail.com> <505B23E0.4030906@ttec.com> <505B2C39.2000601@ttec.com> Message-ID: > > Let us spin this another way. If you cannot even expect mild change such >>> as 240/4 to become prevalent enough to be useful, on what do you base >>> your >>> optimism that the much larger changes IPv6 requires will? >>> >>> Joe >>> >>> >>> Easy - Greater return on the investment; i.e. - instead of getting an >> IPv4 >> /4 out of the effort you get an IPv6 Global Unicast Space of 2000::/3 >> (just >> for starters, counting neither the rest of the unicast nor multicast, etc. >> spaces.). >> > > > ::/3 > /48 > /64 > > Do you think we may ever come to regret baking that in? And use that > regret to torpedo any attempts at change? > If we do ever grow to regret the /48 and /64 splits, I guess it is a good thing we have 5 more /3s to deal with it ... > As far as roi is concerned, we can make all the calculation we want. > What we cannot do is force everyone else to come up with the same numbers > we did. > We also cannot make everyone happy all of the time. We can only do the best we can, and make it work as good as we can. Such is life. > Also, the impact of the "changes required" is close to the same in that >> every node needs to be touched - that is the hard part, getting updates >> deployed. *(Unless you want 240/4 to be a special/limited use case - in >> which case the effort is smaller, but so is the reward ...)* >> >> The scope of the change is far far different, no matter the use case. > Never more than a simple update. Yes, but making a change (regardless of size) on a given platform is often dwarfed by the effort of getting the update pushed out, to every possible instance of said platform. Multiply that by the number of platforms ... With IPv6, it is a bigger single change (in code terms), but the hard part (deployment) is roughly the same order of magnitude in deployment. It is also easier to know if your platform is in an area that now has IPv6, vs a router discovering whether or not the hosts understand the new /4. That is, dual-stack (IPv4 + IPv6) create fewer problems than the coexistence of nodes supporting 240/4 and not supporting 240/4. And again, an additional IPv4 /4 is *just a bit smaller* than what IPv6 brings to the table ... /TJ *... all IMHO / IME, of course.* From heather.schiller at verizon.com Thu Sep 20 15:10:17 2012 From: heather.schiller at verizon.com (Schiller, Heather A) Date: Thu, 20 Sep 2012 11:10:17 -0400 Subject: RIRs give out unique addresses (Was: something has a /8! ...) In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0C6FF97D@MUNEXBE1.medline.com> References: <4bd0179a-8e3b-4e1d-b43d-b828bce9117c@mail.pelican.org> <9B9685A4-CD22-41E9-957A-23103D2C8F33@corp.arin.net> <505B23C0.4010102@unfix.org> <2A76E400AC84B845AAC35AA19F8E7A5D0C6FF97D@MUNEXBE1.medline.com> Message-ID: There is no such thing as "Internet routers" there are my routers, your routers, and that guy over there's routers. Even if you get your ISP to route it for you - that does not guarantee that any other network anywhere else on the internet will accept the route. Getting your ISP to accept your prefix is arguably, only a small part of being reachable/routable. --Heather -----Original Message----- From: Naslund, Steve [mailto:SNaslund at medline.com] Sent: Thursday, September 20, 2012 10:56 AM To: nanog at nanog.org Subject: RE: RIRs give out unique addresses (Was: something has a /8! ...) I suppose that ARIN would say that they do not guarantee routability because they do not have operational control of Internet routers. However, Wouldn't you say that there is a very real expectation that when you request address space through ARIN or RIPE that it would be routable? I would think that what ARIN and RIPE are really saying is that they issue unique addresses and you need to get your service provider to route them. FWIW, the discussion of the military having addresses pulled back is pretty much a non-starter unless they want to give them back. When the management of IP address space was moved from the US DoD, there were memorandums of understanding that the military controlled their assigned address space and nothing would change that. I know this for a fact because I was around this discussion in the US Air Force. Steven Naslund -----Original Message----- From: John Curran [mailto:jcurran at arin.net] Sent: Thursday, September 20, 2012 9:40 AM To: Jeroen Massar Cc: NANOG list Subject: Re: RIRs give out unique addresses (Was: something has a /8! ...) On Sep 20, 2012, at 10:10 AM, Jeroen Massar wrote: > On 2012-09-20 16:01 , John Curran wrote: >> >> It's very clear in the ARIN region as well. From the ARIN Number >> Resource Policy Manual (NRPM), >> - >> >> "4.1. General Principles 4.1.1. Routability Provider independent >> (portable) addresses issued directly from ARIN or other Regional >> Registries are not guaranteed to be globally routable." > > While close, that is not the same. > > The RIPE variant solely guarantees uniqueness of the addresses. > > The ARIN variant states "we don't guarantee that you can route it > everywhere", which is on top of the uniqueness portion. Agreed - I called it out because ARIN, like RIPE, does not assert that the address blocks issued are "publicly routable address space" (i.e. which was Tim Franklin's original statement, but he did not have on hand the comparable ARIN reference for that point.) FYI, /John From james.cutler at consultant.com Thu Sep 20 15:35:32 2012 From: james.cutler at consultant.com (Cutler James R) Date: Thu, 20 Sep 2012 11:35:32 -0400 Subject: RIRs give out unique addresses (Was: something has a /8! ...) In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0C6FF97D@MUNEXBE1.medline.com> References: <4bd0179a-8e3b-4e1d-b43d-b828bce9117c@mail.pelican.org> <9B9685A4-CD22-41E9-957A-23103D2C8F33@corp.arin.net> <505B23C0.4010102@unfix.org> <2A76E400AC84B845AAC35AA19F8E7A5D0C6FF97D@MUNEXBE1.medline.com> Message-ID: On Sep 20, 2012, at 10:56 AM, "Naslund, Steve" wrote: > > Wouldn't you say that there is a very real expectation that > when you request address space through ARIN or RIPE that it would be > routable? I certainly would not say that. I would say that I get addresses from the RIRs to avoid address collisions with other network operators using the same approach. And, please note this well, address collisions affect more than Layer three routing. See all the previous mentions of application gateways. James R. Cutler james.cutler at consultant.com From SNaslund at medline.com Thu Sep 20 15:55:27 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 20 Sep 2012 10:55:27 -0500 Subject: RIRs give out unique addresses (Was: something has a /8! ...) In-Reply-To: References: <4bd0179a-8e3b-4e1d-b43d-b828bce9117c@mail.pelican.org> <9B9685A4-CD22-41E9-957A-23103D2C8F33@corp.arin.net> <505B23C0.4010102@unfix.org> <2A76E400AC84B845AAC35AA19F8E7A5D0C6FF97D@MUNEXBE1.medline.com> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0C6FFA48@MUNEXBE1.medline.com> >From a practical point of view as a service provider, I would assume my customer would not be pleased to be assigned an address that prevented them from communicating with anyone on the Internet that wants to communicate with them. We can debate the details of who does what but every network operator will have to deal with their own customer. If they have an address block assigned to them, they will most likely want me to route it as well as work with any other service provider to ensure that they can get where they need to go. For example, if one of my customers cannot get to anyone on AT&T or Comcast they will expect me to solve the issue for them. As the customer's single point of contact with the Internet we effectively have to deal with all of their issues even if they are caused by another service provider. All the ISPs raise your hand, if you were assigned a block of address space by ARIN or RIPE and you could not globally route it, would you be upset? Of course there are times I want a globally unique address space and do not want to route it but the whole point of being globally unique is that I would like the option to route it if I wanted to. The requirement for globally unique but non-routable space is most definitely an edge case, not the norm. Steven Naslund -----Original Message----- From: Cutler James R [mailto:james.cutler at consultant.com] Sent: Thursday, September 20, 2012 10:36 AM To: nanog at nanog.org Subject: Re: RIRs give out unique addresses (Was: something has a /8! ...) On Sep 20, 2012, at 10:56 AM, "Naslund, Steve" wrote: > > Wouldn't you say that there is a very real expectation that > when you request address space through ARIN or RIPE that it would be > routable? I certainly would not say that. I would say that I get addresses from the RIRs to avoid address collisions with other network operators using the same approach. And, please note this well, address collisions affect more than Layer three routing. See all the previous mentions of application gateways. James R. Cutler james.cutler at consultant.com From jra at baylink.com Thu Sep 20 16:34:06 2012 From: jra at baylink.com (Jay Ashworth) Date: Thu, 20 Sep 2012 12:34:06 -0400 (EDT) Subject: Big Temporary Networks In-Reply-To: Message-ID: <3875009.25570.1348158846006.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "William Herrin" > My point is that blaming union contracts or union anything for being > unable to find a place to hold a convention where you can implement > the network you want to implement is nonsense. NANOG, ARIN and IETF > conferences have all somehow managed to implement their own effective > networks. Even in union towns. If Worldcon's site selection committee > can't find a suitable host, that's their deficiency. That's as may be, Bill, but it is definitively outside *my* personal scope, here. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From Ed.Lewis at neustar.biz Thu Sep 20 16:48:00 2012 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 20 Sep 2012 12:48:00 -0400 Subject: RIRs give out unique addresses (Was: something has a /8! ...) In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0C6FF97D@MUNEXBE1.medline.com> References: <4bd0179a-8e3b-4e1d-b43d-b828bce9117c@mail.pelican.org> <9B9685A4-CD22-41E9-957A-23103D2C8F33@corp.arin.net> <505B23C0.4010102@unfix.org> <2A76E400AC84B845AAC35AA19F8E7A5D0C6FF97D@MUNEXBE1.medline.com> Message-ID: At 9:56 -0500 9/20/12, Naslund, Steve wrote: >I suppose that ARIN would say that they do not guarantee routability >because they do not have operational control of Internet routers. ARIN does not provide transit - how could they guarantee or even just provide best-effort routability? >However, Wouldn't you say that there is a very real expectation that >when you request address space through ARIN or RIPE that it would be >routable? Perhaps, but that is misguided. ARIN, et.al. don't get involved in peering or block lists or firewall configuration guides or hurricane forecasting or ... anything else that bars reachability. If I decide to unilaterally block traffic from your address range, ARIN, et.al., can't do anything about it. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From jra at baylink.com Thu Sep 20 16:52:46 2012 From: jra at baylink.com (Jay Ashworth) Date: Thu, 20 Sep 2012 12:52:46 -0400 (EDT) Subject: Big Temporary Networks In-Reply-To: Message-ID: <32613517.25574.1348159966261.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Rick Alfvin" > Verilan is the exclusive network services provider for NANOG, IEEE > 802, IETF, ICANN, ZigBee Alliance, MAAWG, OIF, GENIVI, Tizen and many > other technical organizations. We deploy large temporary networks to > provide high density WI-Fi for meetings, events and conferences all > over the world where Internet connectivity is mission critical to the > success of the event. I'm quite certain I have a good idea of the magnitude of what you'd charge for professional services for such work, and I would expect it to be 2-3 orders of magnitude larger than what a Worldcon Concom could afford to pay. :-) I would also be very surprised -- having been on NANOG for over a decade now and never having heard your name -- to find out that you were the Exclusive Network Services Provider for NANOG... And I expect they'd be surprised too. Hey! Let's ask them! :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From peter.phaal at gmail.com Thu Sep 20 16:59:24 2012 From: peter.phaal at gmail.com (Peter Phaal) Date: Thu, 20 Sep 2012 09:59:24 -0700 Subject: Real world sflow vs netflow? In-Reply-To: <50012E21.4060802@bromirski.net> References: <50012E21.4060802@bromirski.net> Message-ID: On Sat, Jul 14, 2012 at 1:30 AM, ?ukasz Bromirski wrote: > sFlow is really sPacket, as it doesn't deal with flows. > > NetFlow, jFlow, IPFIX deal with flows. I am a puzzled by the orthodoxy that seems to prevail around the value "flows" as a measure of network traffic in packet switched networks. The following article contains some thoughts on flow oriented and packet oriented measurements. Apologies to NANOG readers for the simplistic analogies used to describe packet switching, the article is also intended for server administrators and application developers who often don't really know what happens when they write some bytes to a TCP socket. http://blog.sflow.com/2012/09/packets-and-flows.html The article positions flows as a useful abstraction for characterizing host and application performance, but as a poor fit for understanding packet traffic and measuring the performance of packet switches and routers. This isn't really an issue of sFlow vs. NetFlow/IPFIX etc. Either protocol can be used to export both types of measurements; the question is what types of measurement should be exported. What do people think? Peter From DStaal at usa.net Thu Sep 20 17:01:10 2012 From: DStaal at usa.net (Daniel Staal) Date: Thu, 20 Sep 2012 13:01:10 -0400 Subject: IPv6 Burgers (was: IPv6 Ignorance) In-Reply-To: <6738D7C4-2837-45D6-9DF9-76DF2DA2A554@intermapper.com> References: <6738D7C4-2837-45D6-9DF9-76DF2DA2A554@intermapper.com> Message-ID: <66ab7645499f13671396fc222a37a8b9@mail.magehandbook.com> On 2012-09-17 13:48, Richard Brown wrote: > Another measure of the size of the IPv6 address space... Back on > World IPv6 Day in June 2011, Dartware had a barbecue. (Why? Because > the burgers had 128 (bacon) bits and we served IP(A) to drink :-) You > can see some photos at: > http://www.networkworld.com/community/blog/scenes-ipv6-day-barbecue > > But we came up with another interesting measure for the vastness of > the IPv6 address space: > > If an IPv4 hamburger patty has 2^32 (4.2 billion) unique addresses in > its 1/4 inch thickness, how thick would an IPv6 hamburger be (with > 2^128 unique addresses)? > > The answer is... 53 billion light-years. Just got to playing with this today, trying to put it in some sort of perspective. First off, lets bring that down to human-sized numbers, using standard units used in astronomy: 2^94 inches = 16 gigaparsecs + 304 megaparsecs + 322 kiloparsecs + 752 parsecs + 2 lightyears + 57101 au + 23233 earthradius (Gigaparsecs isn't very common, but that's because it's a bit big.) So... How big is that? What can we compare it to? Well, let's start at the top: does this thing actually fit in our universe? The size of the observable universe is set by the Hubble Constant and lightspeed: The Hubble Constant is the rate of growth of expansion in the universe - the redshift phenomena. The further away you look, the faster things are moving away from us. At a certain point, they are moving away from us faster than light, meaning that light coming from them would never reach us. That's about 14 gigaparsecs away. (Adjusting for such things as how much they will have moved since you measured them. There's a whole rabbit hole to go down for this, on Wikipedia alone.) Which means the observable universe is about 28 gigaprsecs across. (Now you can see why gigaparsecs isn't a common unit.) So our hamburger patty would fit inside it - but you wouldn't be able to see one end from the other. Ever. In fact, while someone at the center could reach either end, once they got there they'd never be able to reach the other. They wouldn't even be able to get back to where they started. Which of course means that even if you ate at lightspeed, you'd never be able to eat it. (Oh, and if it still has a radius of 3 inches - standard 1/4 pound burger at 1/4 inch thick - it's got a volume around that of 11,000 Earths, and a mass of about 1,400 Earths, about 4.6 times the mass of Jupiter.) > It's straightforward unit conversions. There are 2^96 IPv4 Hamburgers > at a quarter-inch apiece. That's 2^96 inches/4 (2^94 inches). > Switching to decimal units, 1.98x10^32 inches; 1.65x10^27 feet; > 3.13x10^23 miles; and then continuing to convert to light-years. > > A good tool for this kind of wacky unit conversion is Frink > > (http://futureboy.us/fsp/frink.fsp?fromVal=2%5E94+inches&toVal=lightyears), > which can do this in one shot. Simply enter: I prefer the 'units' program, which is usually a standard utility on Unix-like boxes. (If not in your distro of choice, finding the GNU or BSD versions is left as an exercise for the reader. ;) ) Daniel T. Staal --------------------------------------------------------------- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. --------------------------------------------------------------- From joelja at bogus.com Thu Sep 20 17:19:24 2012 From: joelja at bogus.com (joel jaeggli) Date: Thu, 20 Sep 2012 10:19:24 -0700 Subject: Big Temporary Networks In-Reply-To: <32613517.25574.1348159966261.JavaMail.root@benjamin.baylink.com> References: <32613517.25574.1348159966261.JavaMail.root@benjamin.baylink.com> Message-ID: <505B501C.8060502@bogus.com> On 9/20/12 9:52 AM, Jay Ashworth wrote: > I'm quite certain I have a good idea of the magnitude of what you'd > charge for professional services for such work, and I would expect it > to be 2-3 orders of magnitude larger than what a Worldcon Concom could > afford to pay. :-) I would also be very surprised -- having been on > NANOG for over a decade now and never having heard your name -- to > find out that you were the Exclusive Network Services Provider for > NANOG... And I expect they'd be surprised too. Hey! Let's ask them! > :-) Cheers, -- jra That's funny, my mailing archive says you had a conversation with the network contractor on this list during NANOG 53. From jra at baylink.com Thu Sep 20 17:27:32 2012 From: jra at baylink.com (Jay Ashworth) Date: Thu, 20 Sep 2012 13:27:32 -0400 (EDT) Subject: Apologies to the Verilan guy Message-ID: <4924220.25578.1348162052881.JavaMail.root@benjamin.baylink.com> I've had it pointed out to me that I talked to those folks on the list, during NANOG 53 or its runup. Um, "oops". Sorry. :-) I still don't think we can afford you, though. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From nick at foobar.org Thu Sep 20 18:10:39 2012 From: nick at foobar.org (Nick Hilliard) Date: Thu, 20 Sep 2012 19:10:39 +0100 Subject: Real world sflow vs netflow? In-Reply-To: References: <50012E21.4060802@bromirski.net> Message-ID: <505B5C1F.7020406@foobar.org> On 20/09/2012 17:59, Peter Phaal wrote: > What do people think? Flows are good for measuring some things; raw packet sampling is good for measuring others. Decide on what you're trying to measure, then pick the best tool for the job. Nick From swmike at swm.pp.se Thu Sep 20 18:21:46 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 20 Sep 2012 20:21:46 +0200 (CEST) Subject: Real world sflow vs netflow? In-Reply-To: References: <50012E21.4060802@bromirski.net> Message-ID: On Thu, 20 Sep 2012, Peter Phaal wrote: > I am a puzzled by the orthodoxy that seems to prevail around the value > "flows" as a measure of network traffic in packet switched networks. What platforms actually do real unsampled netflow today, and do it well for multi-10gigabit worth of typical Internet traffic? Most of the platforms I know of do sampled netflow at 1:100-1:1000 or so, and then I don't really see the fundamental difference in doing the flow analysis on the router itself (classic netflow) or doing the same but at the sFlow collector. -- Mikael Abrahamsson email: swmike at swm.pp.se From Valdis.Kletnieks at vt.edu Thu Sep 20 18:33:23 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 20 Sep 2012 14:33:23 -0400 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: Your message of "Thu, 20 Sep 2012 00:21:45 -0400." <505A99D9.6010109@ttec.com> References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> <231483E9-5129-4722-87DE-635FEC3AC422@virtualized.org> <505A440D.5080701@dougbarton.us> <505A48D8.4040800@ttec.com> <36217.1348098710@turing-police.cc.vt.edu> <505A6844.9050703@ttec.com> <505A99D9.6010109@ttec.com> Message-ID: <20809.1348166003@turing-police.cc.vt.edu> On Thu, 20 Sep 2012 00:21:45 -0400, Joe Maimon said: > Why is this cast as a boolean choice? And how has the getting on with > IPv6 deployment been working out? 60% of our traffic is IPv6 now. Working out pretty good for us. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From alh-ietf at tndh.net Thu Sep 20 18:38:52 2012 From: alh-ietf at tndh.net (Tony Hain) Date: Thu, 20 Sep 2012 11:38:52 -0700 Subject: Big Temporary Networks In-Reply-To: <505AB5E1.7080204@necom830.hpcl.titech.ac.jp> References: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> <50561ADD.2040404@necom830.hpcl.titech.ac.jp> <505626A2.1090700@foobar.org> <505663DE.7000309@necom830.hpcl.titech.ac.jp> <50586620.6080702@necom830.hpcl.titech.ac.jp> <505973A4.90705@necom830.hpcl.titech.ac.jp> <505A40CD.8030701@necom830.hpcl.titech.ac.jp> <505A7033.6040807@necom830.hpcl.titech.ac.jp> <505A8E76.3030800@necom830.hpcl.titech.ac.jp> <505A9DC8.2040508@tiggee.com> <505AB5E1.7080204@necom830.hpcl.titech.ac.jp> Message-ID: <00b301cd975f$2ee354b0$8ca9fe10$@tndh.net> > -----Original Message----- > From: Masataka Ohta [mailto:mohta at necom830.hpcl.titech.ac.jp] > Sent: Wednesday, September 19, 2012 11:21 PM > To: David Miller > Cc: nanog at nanog.org > Subject: Re: Big Temporary Networks > > David Miller wrote: > > > So, a single example of IPv4 behaving in a suboptimal manner would be > > enough to declare IPv4 not operational? > > For example? Your own example --- > -----Original Message----- > From: Masataka Ohta [mailto:mohta at necom830.hpcl.titech.ac.jp] > Sent: Wednesday, September 19, 2012 1:26 AM > To: nanog at nanog.org > Subject: Re: Big Temporary Networks > > ... that a very crowded train arrives at a station and all the smart phones of passengers try to connect to APs ... IPv4 has a train load of devices unicasting and retransmitting all the dropped packets, where an IPv6 multicast RA allows all the devices to configure based on reception of a single packet. Therefore IPv4 is "suboptimal" in its abuse of the air link which could have been used for real application traffic instead of being wasted on device configuration. Thus by extension using your logic it is not operational. Just because you personally want IPv6 to be nothing more than IPv4 in every aspect is no reason to troll the nanog list and create confusion that causes others to delay their IPv6 deployment. Your complaints about IPv6 behavior on wifi ignore the point that IPv6 ND behavior was defined before or in parallel as wifi was defined by a different committee. There will always be newer L2 technologies that arrive after an L3 protocol is defined, and the behavior of the L3 will be 'suboptimal' for the new L2. When the issue is serious enough to warrant documentation, addendum documents are issued. When it is simply a matter of personal preference, it is hard to get enough support to get those documents published. Tony From jrhett at netconsonance.com Thu Sep 20 19:03:24 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 20 Sep 2012 12:03:24 -0700 Subject: the economies of scale of a Worldcon, and how to make this topic relevant to Nanog In-Reply-To: <32613517.25574.1348159966261.JavaMail.root@benjamin.baylink.com> References: <32613517.25574.1348159966261.JavaMail.root@benjamin.baylink.com> Message-ID: In a message Jay had apparently forwarded from offlist (or I missed the original) Rick said: > From: "Rick Alfvin" > Verilan is the exclusive network services provider for NANOG, IEEE > 802, IETF, ICANN, ZigBee Alliance, MAAWG, OIF, GENIVI, Tizen and many > other technical organizations. We deploy large temporary networks to > provide high density WI-Fi for meetings, events and conferences all > over the world where Internet connectivity is mission critical to the > success of the event. This points out another significant facter to why network isn't part of what's negotiated here. Internet is *not* considered mission critical by most attendees. Cheaper hotel rooms, adequate facilities, and inexpensive food nearby are the top three items Worldcon attendees complain about. So it's not going to be on the top of things to focus on. (and why this topic as it is being discussed is not relevant to this list) Those of us who feel Internet access is mission critical carry LTE network devices or make other arrangements. Obviously the growth of smartphones and tablets is starting to change that equation, but at the moment none of the Worldcons have done a very good job of providing useful online interaction so there's no actual use for onsite data related to the conference itself. Obviously I would love to see this change. For those who care about the economics of Worldcons, the following post is from a person deeply involved in the organization which holds the rights and trademarks for Worldcon. (Think Olympic Site Selection Committee, except they don't select the locations -- the members do) He covers a lot of the topics about why Worldcons are so very, very different from any of the conferences listed above, and why the economics of scale these conventions have don't work: http://kevin-standlee.livejournal.com/1166167.html Now, if we want to make this topic relevant to Nanog, the operative question is the feasability of a data provider putting good wireless gear near these facilities and selling data access to attendees. For a useful comparison, the 2010 Worldcon in Melbourne had an expensive wifi service in the building that kept falling over. A cell provider across the street put up banners advertising cheap data service, and put people on the sidewalk in from of the convention selling pay as you go SIM cards with data service. They made brisk business. *THIS* is where us network operators can provide good networking service to a large facility, and pretty much kill the expensive data plans operated by the facility. Instead of building up and tearing down a network for each convention, put an LTE tower near the facility and sell to every group that uses the convention center. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. From jrhett at netconsonance.com Thu Sep 20 19:09:46 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 20 Sep 2012 12:09:46 -0700 Subject: The Department of Work and Pensions, UK has an entire /8 nanog@nanog.org In-Reply-To: <20120920020920.GA16558@panix.com> References: <201209200059.q8K0xZ4f060923@mail.r-bonomi.com> <2645353A-AE47-4EB6-8ED7-A4FFBFCDC40F@netconsonance.com> <20120920020920.GA16558@panix.com> Message-ID: On Sep 19, 2012, at 7:09 PM, Brett Frankenberger wrote: > It works fine if the gateway has multiple routing tables (VRF or > equivalent) and application software that is multiple-routing-table > aware. If you are arguing that it is technically possible to build an environment in which every piece of software is aware at an application level whether or not a given service is inside the network or outside the network and thus eliminate issues with routing overlaps? uh, sure. I agree that you can do this in a very customized environment. Now if you want to suggest that most businesses with a diversity of applications and access methods should be doing this, in order to allow overlapping IP usage on the internet, I'm going to have to point and giggle. I really love how everyone keeps advancing these "businesses should rebuild their entire infrastructure, at their cost, and with no benefit to themselves, so that I can use their IP space!" arguments. Ya huh. Right. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. From alh-ietf at tndh.net Thu Sep 20 19:14:59 2012 From: alh-ietf at tndh.net (Tony Hain) Date: Thu, 20 Sep 2012 12:14:59 -0700 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <505B23E0.4030906@ttec.com> References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> <231483E9-5129-4722-87DE-635FEC3AC422@virtualized.org> <505A440D.5080701@dougbarton.us> <505A48D8.4040800@ttec.com> <36217.1348098710@turing-police.cc.vt.edu> <505A6844.9050703@ttec.com> <505A99D9.6010109@ttec.com> <505AC3F8.9060905@bogus.com> <8270A4D4-5B82-45B6-BD78-FD3586545D6F@gmail.com> <505B23E0.4030906@ttec.com> Message-ID: <00bc01cd9764$3aa38090$afea81b0$@tndh.net> > -----Original Message----- > From: Joe Maimon [mailto:jmaimon at ttec.com] > Sent: Thursday, September 20, 2012 7:11 AM > To: George Herbert > Cc: nanog at nanog.org > Subject: Re: The Department of Work and Pensions, UK has an entire /8 > > ... > > Baking in bogonity is bad. Really ??? If stack vendors had not taken the statement about 'future use' at face value and had built the stacks assuming the 240/4 was just like all the other unicast space; then someone came up with a clever idea that was incompatible with the deployed assumption such that the vast deployed base would be confused by any attempt to deploy the new clever idea, wouldn't your argument be that 'the stack vendors broke what I want by not believing the text that said future use'? Undefined means undefined, so there is no reasonable way to test the behavior being consistent with some future definition. The only thing a stack vendor can do is make sure the space is unused until it is defined. At that point they can fix future products, but there is no practical fix for the deployed base. > > Predicting the (f)utility of starting multi-year efforts in the present for future > benefit is self-fulfilling. To some degree yes. In this particular case, why don't you personally go out and tell all those people globally (that have what they consider to be perfectly working machines) that they need to pay for an upgrade to a yet to be shipped version of software so you can make use of a handful of addresses and buy yourself a couple of years delay of the inevitable. If you can accomplish that I am sure the list would bow down to your claims that there was not enough effort put into reclamation. > > Let us spin this another way. If you cannot even expect mild change such as > 240/4 to become prevalent enough to be useful, on what do you base your > optimism that the much larger changes IPv6 requires will? 240/4 is only 'mild' to someone that doesn't have to pay for the changes. IPv6 does require more change, but in exchange it provides longevity that 240/4 can't. Denial is a hard thing to get over, but it is only the first stage in process of grieving. IPv4 is dead, and while the corpse is still wandering about, it will collapse soon enough. No amount of bargaining or negotiation will prevent that. Just look back to the claims in the '90s about SNA-Forever and 'Serious Business doesn't operate on research protocols' to see what is ahead. Once the shift starts it will only take 5 years or so before people start asking what all the IPv4 fuss was about. IPv6 will happen with or without the ISPs, just like IPv4 happened despite telco efforts to constrain it. The edges need functionality, and they will get it by tunneling over the ISPs if necessary, just like the original Internet deployed as a tunnel over the voice network. You can choose to be a roadblock, or choose to be part of the solution. History shows that those choosing to be part of the solution win out in the end. Tony > > Joe From stephen at sprunk.org Thu Sep 20 19:23:39 2012 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 20 Sep 2012 14:23:39 -0500 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <00bc01cd9764$3aa38090$afea81b0$@tndh.net> References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> <231483E9-5129-4722-87DE-635FEC3AC422@virtualized.org> <505A440D.5080701@dougbarton.us> <505A48D8.4040800@ttec.com> <36217.1348098710@turing-police.cc.vt.edu> <505A6844.9050703@ttec.com> <505A99D9.6010109@ttec.com> <505AC3F8.9060905@bogus.com> <8270A4D4-5B82-45B6-BD78-FD3586545D6F@gmail.com> <505B23E0.4030906@ttec.com> <00bc01cd9764$3aa38090$afea81b0$@tndh.net> Message-ID: <505B6D3B.7060505@sprunk.org> On 20-Sep-12 14:14, Tony Hain wrote: >> Predicting the (f)utility of starting multi-year efforts in the present for future benefit is self-fulfilling. > To some degree yes. In this particular case, why don't you personally go out and tell all those people globally (that have what they consider to be perfectly working machines) that they need to pay for an upgrade to a yet to be shipped version of software ... In many cases, particularly embedded devices, the vendor may have gone out of business or ceased offering software updates for that product, in which case customers would have to pay to /replace/ the products, not just upgrade them--for no benefit to themselves. Good luck with that. That's why the 240/3 idea was abandoned years ago, and nothing has changed since then. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2312 bytes Desc: S/MIME Cryptographic Signature URL: From george.herbert at gmail.com Thu Sep 20 20:18:58 2012 From: george.herbert at gmail.com (George Herbert) Date: Thu, 20 Sep 2012 13:18:58 -0700 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <505B23E0.4030906@ttec.com> References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> <231483E9-5129-4722-87DE-635FEC3AC422@virtualized.org> <505A440D.5080701@dougbarton.us> <505A48D8.4040800@ttec.com> <36217.1348098710@turing-police.cc.vt.edu> <505A6844.9050703@ttec.com> <505A99D9.6010109@ttec.com> <505AC3F8.9060905@bogus.com> <8270A4D4-5B82-45B6-BD78-FD3586545D6F@gmail.com> <505B23E0.4030906@ttec.com> Message-ID: On Thu, Sep 20, 2012 at 7:10 AM, Joe Maimon wrote: > > > George Herbert wrote: > >> We could have started it at a more opportune time in the past. We could >> also have done other things like a straight IPv4-48 or IPv4-64, without the >> other protocol suite foo that's delayed IPv6 rollout. Operators could have >> either used larger baseball bats or more participating numbers to make some >> IPv6 protocol design go the other way. IETF could have realized they were >> in Epic Fail by Too Clever territory. >> >> All of these things are water under the bridge now. We have what we have. >> It being amusing to grouse about mistakes of the past does not magically >> change the present. We have rapidly vanishing IPv4 and no 240/4, IPv6, and >> no time. That is reality. >> >> Pining for 240/4 fjords is not a time machine to change the past. > > What is not amusing is continued evidence that the lessons from this debacle > have not been learned. Or that other past lessons are being forgotten. > Baking in bogonity is bad. Ok, but the bogonity is baked in in two areas already; both 240/4 and IPv6. 240/4 is baked in (or out) of IPv4 on a large quantity of deployed firmware and devices, and larger quantity of local OS IPv4 stacks. The local OSes are, as a rule, upgraded on 2-3 year timelines and patched in many cases something like annually or every few months. Firmware, less so. As someone else pointed out, a lot of those devices are not under support anymore or from now defunct vendors, so a hardware replace is the fix. IPv6 was also baked out of a large quantity of deployed firmware and devices, and OS stacks. This has largely already been remedied, and people are largely aware that device firmware that's not upgradable needs replacement, so the fix is mostly in and already most of the way through happening. In both cases, a roughly 7-10 year total process in practice; in one case, we're already 5-6 years of serious effort in to it. Do you understand the difference between starting a 7, 8, 10 year process fresh from zero right now versus continuing one we're nearly done with? > Predicting the (f)utility of starting multi-year efforts in the present for > future benefit is self-fulfilling. No. This is a classic techie-makes-business-failure problem. You are not creating products for today's customers. You're creating products for customers who will be there when the product is ready. You're not creating a product to compete with today's products; you're competing with the products that will be out when it's done and shipping, and that come out subsequently. This is what "market window" is all about. > Let us spin this another way. If you cannot even expect mild change such as > 240/4 to become prevalent enough to be useful, on what do you base your > optimism that the much larger changes IPv6 requires will? We're somewhere around 2/3 of the way through on the IPv6 changes. We haven't started a 240/4 activation project yet. We have found while doing the IPv6 that there are some glitches; a very few of them at protocol level, with so-far tolerable workarounds or adjustments in expectations. A lot of them at operational process and usage levels. A lot more of them at business / user levels. There's a difference between "IPv6 doesn't work" and "IPv6 is not perfect". IPv6 is deployed, running nationally, represents 0.6-1.0% of active IP traffic right now to big websites depending on who you talk to (Google was 0.6% I think, Wikipedia reporting 0.8% on an internal list a couple of weeks ago, etc). It's obviously not "doesn't work" as it's showing functional IPv6 traffic levels that approximate those of the whole Internet 15 years ago. It's obviously not perfect. It's asserted that the operational problems are big for a number of sites, but others are making it work. We'll have to see on that. In any case, it's not 7-10 years away from working. Even if we have to respin a support protocol (DHCPv6.1, anyone?) the core protocol and most of the stacks and the routers and devices probably wouldn't need replacement. Someone who objects to current operational issues is likely to eventually (soon) just write code rather than wait for arguments to settle and the protocol wizards to pronounce. Running code trumps theory and argument. If you think you can accomplish a full 240/4 support rollout across the world's devices and infrastructure faster than we can get IPv6 running, I would suggest that you reconsider. It's an easier fix at one level only - the code in the stacks that needs changing is relatively minor. Even if the protocol and code changes were completely done tomorrow by magic, the deployment phase, all 5+ years of it, is starting at zero. IPv6 is deployed; not universally, but most of the way through. We're shaving operational issues with the protocol and support protocols off now, and dealing with deployments into slow-adopters. IPv6 is able to be operational for many people now; 240/4 would not be operational for anyone in a safe sense until 2017-2020. This is a classic market window failure. It's not just engineering. Timing is ultimately just as important. -- -george william herbert george.herbert at gmail.com From bill at herrin.us Thu Sep 20 20:29:22 2012 From: bill at herrin.us (William Herrin) Date: Thu, 20 Sep 2012 16:29:22 -0400 Subject: IPv6 Burgers (was: IPv6 Ignorance) In-Reply-To: <6738D7C4-2837-45D6-9DF9-76DF2DA2A554@intermapper.com> References: <6738D7C4-2837-45D6-9DF9-76DF2DA2A554@intermapper.com> Message-ID: On Mon, Sep 17, 2012 at 1:48 PM, Richard Brown wrote: > Another measure of the size of the IPv6 address space... Back on World IPv6 Day in June 2011, Dartware had a barbecue. (Why? Because the burgers had 128 (bacon) bits and we served IP(A) to drink :-) You can see some photos at: http://www.networkworld.com/community/blog/scenes-ipv6-day-barbecue > > But we came up with another interesting measure for the vastness of the IPv6 address space: > > If an IPv4 hamburger patty has 2^32 (4.2 billion) unique addresses in its 1/4 inch thickness, how thick would an IPv6 hamburger be (with 2^128 unique addresses)? > > The answer is... 53 billion light-years. Interesting. If a teeny dot of gristle at the edge of the patty is an IPv4 /28 LAN and the same LAN is /64 in IPv6, how big is IPv6 now? The 1/4 inch patty holds all the IPv4 LANs whose IPv4 capacity I'm calling 2^28. IPv6's in principle has 2^64 LANs, so an increase of 2^36 LANs. Patty was 1/4 inch, so our IPv6 patty is 2^32 inches or about 10 billionths of a lightyear. 68,000 miles, a little over a quarter of the distance to the moon. That's a big burger. But not so big as you thought. By 17 orders of magnitude. In point of fact, a mere 150,000 people put together will eat all that beef in their lifetimes. But for the distribution problem, the world population could chew through it in half a day. Worse, that's if we were managing IPv6 delegations the way we manage IPv4 delegations. We're not. We're using sparse allocation. And 6RD. And default customer allocations of 65,000 LANs. And other interesting stuff that drastically increases the consumption characteristics. Nice burger. Om nom nom nom. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From marka at isc.org Thu Sep 20 20:59:49 2012 From: marka at isc.org (Mark Andrews) Date: Fri, 21 Sep 2012 06:59:49 +1000 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: Your message of "Thu, 20 Sep 2012 14:01:53 GMT." <9B9685A4-CD22-41E9-957A-23103D2C8F33@corp.arin.net> References: <4bd0179a-8e3b-4e1d-b43d-b828bce9117c@mail.pelican.org> <9B9685A4-CD22-41E9-957A-23103D2C8F33@corp.arin.net> Message-ID: <20120920205949.7F948257A701@drugs.dv.isc.org> In message <9B9685A4-CD22-41E9-957A-23103D2C8F33 at corp.arin.net>, John Curran wr ites: > On Sep 19, 2012, at 5:01 AM, Tim Franklin wrote: > > >> So...why do you need publicly routable IP addresses if they aren't > >> publicly routable? > >=20 > > Because the RIRs aren't in the business of handing out publicly routable = > address space. They're in the business of handing out globally unique addr= > ess space - *one* of the reasons for which may be connection to the "public= > Internet", whatever that is at any given point in time and space. > >=20 > > RIPE are really good about making the distinction and using the latter ph= > rase rather than the former. I'm not familiar enough with the correspondin= > g ARIN documents to comment on the language used there. > > It's very clear in the ARIN region as well. From=20 > the ARIN Number Resource Policy Manual (NRPM), > - > > "4.1. General Principles=20 > 4.1.1. Routability > Provider independent (portable) addresses issued directly from ARIN or= > other Regional Registries are not guaranteed to be globally routable." Adding "or globally announced" may stop some of this in the future. > 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 nick at foobar.org Thu Sep 20 21:36:59 2012 From: nick at foobar.org (Nick Hilliard) Date: Thu, 20 Sep 2012 22:36:59 +0100 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <00bc01cd9764$3aa38090$afea81b0$@tndh.net> References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> <231483E9-5129-4722-87DE-635FEC3AC422@virtualized.org> <505A440D.5080701@dougbarton.us> <505A48D8.4040800@ttec.com> <36217.1348098710@turing-police.cc.vt.edu> <505A6844.9050703@ttec.com> <505A99D9.6010109@ttec.com> <505AC3F8.9060905@bogus.com> <8270A4D4-5B82-45B6-BD78-FD3586545D6F@gmail.com> <505B23E0.4030906@ttec.com> <00bc01cd9764$3aa38090$afea81b0$@tndh.net> Message-ID: <505B8C7B.7000408@foobar.org> On 20/09/2012 20:14, Tony Hain wrote: > Once the shift starts it will only take 5 years or so > before people start asking what all the IPv4 fuss was about. Tony, ipv4 succeeded because it was compelling enough to do so (killer apps of the time: email / news / ftp, later www instead of limited BBS's, teletext, etc), because the billing model was right for longhaul access (unmetered instead of the default expensive models at the time) and because it worked well over both LANs and WANs (unlike SNA, IPX, decnet, etc). ipv6 has none of these benefits over ipv4. The only thing in its favour is a scalable addressing model. Other than that, it's a world of pain with application level support required for everything, poor CPE connectivity, lots of ipv6-incapable hardware out in the world, higher support costs due to dual-stacking, lots of training required, roll-out costs, licensing costs (even on service provider equipment - and both vendors C and J are guilty as accused here), poor application failover mechanisms (ever tried using outlook when ipv6 connectivity is down?), etc. The reality is that no-one will seriously move to ipv6 unless the pain of address starvation substantially outweighs all these issues from a business / financial perspective. It may be happening in places in china - where there is ipv4 significant address starvation and massive growth, but in places of effectively full internet penetration and relatively plentiful ipv4 addresses (e.g. the US + Europe + large parts of asia), its disadvantages substantially outweigh its sole advantage. I wish I shared your optimisation that we would soon be living in an ipv6 world, but the sad reality is that its sorry state bears more than a passing resemblance to the failure of the OSI protocol stack. Nick From bill at herrin.us Thu Sep 20 21:57:42 2012 From: bill at herrin.us (William Herrin) Date: Thu, 20 Sep 2012 17:57:42 -0400 Subject: IPv6 Burgers (was: IPv6 Ignorance) In-Reply-To: References: <6738D7C4-2837-45D6-9DF9-76DF2DA2A554@intermapper.com> Message-ID: On Thu, Sep 20, 2012 at 4:29 PM, William Herrin wrote: > The 1/4 inch patty holds all the IPv4 LANs whose IPv4 capacity I'm > calling 2^28. IPv6's in principle has 2^64 LANs, so an increase of > 2^36 LANs. Patty was 1/4 inch, so our IPv6 patty is 2^32 inches or > about 10 billionths of a lightyear. 68,000 miles, a little over a > quarter of the distance to the moon. 2^34, my bad. So you get a full moon burger out of it. -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From randy at psg.com Thu Sep 20 23:15:16 2012 From: randy at psg.com (Randy Bush) Date: Fri, 21 Sep 2012 08:15:16 +0900 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <00bc01cd9764$3aa38090$afea81b0$@tndh.net> References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> <231483E9-5129-4722-87DE-635FEC3AC422@virtualized.org> <505A440D.5080701@dougbarton.us> <505A48D8.4040800@ttec.com> <36217.1348098710@turing-police.cc.vt.edu> <505A6844.9050703@ttec.com> <505A99D9.6010109@ttec.com> <505AC3F8.9060905@bogus.com> <8270A4D4-5B82-45B6-BD78-FD3586545D6F@gmail.com> <505B23E0.4030906@ttec.com> <00bc01cd9764$3aa38090$afea81b0$@tndh.net> Message-ID: > IPv4 is dead, and while the corpse is still wandering about, it will > collapse soon enough. No amount of bargaining or negotiation will > prevent that. Just look back to the claims in the '90s about > SNA-Forever and 'Serious Business doesn't operate on research > protocols' to see what is ahead. Once the shift starts it will only > take 5 years or so before people start asking what all the IPv4 fuss > was about. tony, something is wrong with your mail transfer agent. it is regurgitating mail you wrote a decade ago. randy From alh-ietf at tndh.net Thu Sep 20 23:47:47 2012 From: alh-ietf at tndh.net (Tony Hain) Date: Thu, 20 Sep 2012 16:47:47 -0700 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <505B8C7B.7000408@foobar.org> References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> <231483E9-5129-4722-87DE-635FEC3AC422@virtualized.org> <505A440D.5080701@dougbarton.us> <505A48D8.4040800@ttec.com> <36217.1348098710@turing-police.cc.vt.edu> <505A6844.9050703@ttec.com> <505A99D9.6010109@ttec.com> <505AC3F8.9060905@bogus.com> <8270A4D4-5B82-45B6-BD78-FD3586545D6F@gmail.com> <505B23E0.4030906@ttec.com> <00bc01cd9764$3aa38090$afea81b0$@tndh.net> <505B8C7B.7000408@foobar.org> Message-ID: <00e701cd978a$5654c710$02fe5530$@tndh.net> > -----Original Message----- > From: Nick Hilliard [mailto:nick at foobar.org] > Sent: Thursday, September 20, 2012 2:37 PM > To: Tony Hain > Cc: nanog at nanog.org > Subject: Re: The Department of Work and Pensions, UK has an entire /8 > > On 20/09/2012 20:14, Tony Hain wrote: > > Once the shift starts it will only take 5 years or so before people > > start asking what all the IPv4 fuss was about. > > Tony, ipv4 succeeded because it was compelling enough to do so (killer apps > of the time: email / news / ftp, later www instead of limited BBS's, teletext, > etc), because the billing model was right for longhaul access (unmetered > instead of the default expensive models at the time) and because it worked > well over both LANs and WANs (unlike SNA, IPX, decnet, etc). > > ipv6 has none of these benefits over ipv4. You are comparing IPv6 to the historical deployment of IPv4. Get with the times and realize that CGN/LSN breaks all those wonderful location-aware apps people are so into now, not to mention raising the cost for operating the network which eventually get charged back to the user. > The only thing in its favour is a > scalable addressing model. Other than that, it's a world of pain with > application level support required for everything, poor CPE connectivity, lots > of ipv6-incapable hardware out in the world, higher support costs due to > dual-stacking, lots of training required, roll-out costs, licensing costs (even on > service provider equipment - and both vendors C and J are guilty as accused > here), Nanog in general has a problem taking the myopic viewpoint 'the only thing that matters is the network'. The real costs are in app development and support, so crap in the middle of the network (which is only there to keep the network managers from learning something new) will be worked around. While shifting apps to IPv6 has a cost, doing that is a onetime operation vs. having to do it over and over for each app class and new wart that the network managers throw into the middle. IPv4 even with all its warts makes a reasonable global layer-2 network which IPv6 will run over just fine. (Well mostly ... I am still chasing a 20ms tunnel asymmetry which is causing all my IPv6 NTP peers to appear to be off by 10ms) > poor application failover mechanisms (ever tried using outlook when > ipv6 connectivity is down?), etc. Outlook fails when IPv4 service is lame (but I could have stopped at the second word). I use Outlook over IPv6 regularly, and have had more problems with exhausted IPv4 DHCP pools than I have with Outlook over IPv6 in the last 10 years. > > The reality is that no-one will seriously move to ipv6 unless the pain of > address starvation substantially outweighs all these issues from a business / > financial perspective. It may be happening in places in china - where there is > ipv4 significant address starvation and massive growth, but in places of > effectively full internet penetration and relatively plentiful > ipv4 addresses (e.g. the US + Europe + large parts of asia), its disadvantages > substantially outweigh its sole advantage. That depends on your time horizon and budget cycles. If your org suffers from the short-term focus imposed by Wall Street, then you will have a hard time making a case before the customers have started jumping ship in significant enough numbers that you will never get them back. If your time horizon is measured in decade units, you will have an easier time explaining how a 5 year roll out will alleviate costs and minimize pain down the road. Most of the press and casual observers didn't get the point of the 2003 DoD/US Fed mandates for 2008. That date was not picked because they believed they needed IPv6 in production by 2008, it was picked because they had significant new equipment purchases starting at that point that would be in production well past the point when it becomes likely those devices will find themselves in some part of the world where 'IPv6-only' is the network that got deployed. The only way you turn a ship that big is to set a hard date and require things that won't make sense to most people until much later. > > I wish I shared your optimisation that we would soon be living in an ipv6 > world, but the sad reality is that its sorry state bears more than a passing > resemblance to the failure of the OSI protocol stack. If operators would put less effort into blocking transition technologies and channel that energy into deploying real IPv6, the sorry state wouldn't be there. For all the complaints about 6to4, it was never intended to be the mainstay, it was supposed to be the fall back for people that had a lame ISP that was not doing anything about IPv6. All the complaining about 6rd-waste is just another case of finding excuses because an ISP-deployed-6to4-router with a longer than /16 announcement into the IPv6 table does a more efficient job, and would not have required new CPE ... Yes that violates a one-liner in an RFC, but changing that would have been an easier fix than an entirely new protocol definition and allocation policy discussion. In any case, the end system stacks that are less than 10 years old are ready, so the missing component is to get the app vendors to switch api's. That has been difficult since they are waiting for a network, and the network managers are waiting for apps. The entire point of the transition technologies was to break the dependencies and deadlock. The part that didn't happen that should have was for MSFT to fix DevStudio to constantly scream at the app dev about using a deprecated API, thereby getting them to shift to the new one just to shut the compiler up. If the apps are using the new api, they will continue to use IPv4 if that is all DNS gives them, but as soon as DNS is updated with a AAAA record, all that traffic will shift, and tunnel if it has to. That plan makes network managers upset, because they want to be in control, but if they really want that control they have to get out in front and deploy native IPv6 so the tunnel never starts, or is managed between routers they control. Again the vast majority of the support cost is at the edges, so it is cheaper from the edge perspective to ignore and tunnel over the middle if it is not ready. I focused on MSFT above, but AAPL could do the same at the drop of a hat if they chose to. Consider the impact if AAPL chose to change the requirement for an app to be in the iTunes store such that it 'had to work over an IPv6-only network, and could work over an IPv4 network'. If they coupled that with bundling miredo in the OS X & iOS updates, then published a few AAAA records, the network managers would be blinded to what their customers are doing overnight. All they would see was a vast shift to udp, while the app developers would see cheaper support costs after the initial investment to change api's. So far neither MSFT or AAPL has been willing to push hard on the app development community. If the network managers keep making life harder by inserting even more nonsense into the network, they won't have to do more than suggest there is an easier way, and packet shuffling will become even more of a commodity than it already is, because the endpoints will be working in a different space and immune to changes in service providers. Yes life in the core looks pretty dismal right now, because bean-counters lack vision. Those bean-counters will find replacement jobs though at the ISPs offering IPv6 once the customer base has abandoned the IPv4-only one. The people that will have trouble finding new work will be the ones that should have shouted down the bean-counters and pointed out the cliff they were driving the failed company over. Tony > > Nick From marka at isc.org Thu Sep 20 23:50:48 2012 From: marka at isc.org (Mark Andrews) Date: Fri, 21 Sep 2012 09:50:48 +1000 Subject: IPv6 Burgers (was: IPv6 Ignorance) In-Reply-To: Your message of "Thu, 20 Sep 2012 16:29:22 -0400." References: <6738D7C4-2837-45D6-9DF9-76DF2DA2A554@intermapper.com> Message-ID: <20120920235048.D43D3257C254@drugs.dv.isc.org> In message , W illiam Herrin writes: > Worse, that's if we were managing IPv6 delegations the way we manage > IPv4 delegations. We're not. We're using sparse allocation. And 6RD. > And default customer allocations of 65,000 LANs. And other interesting > stuff that drastically increases the consumption characteristics. 6rd can be dense as native deployment. In fact it is not hard to do so and if you are using the shared /10 just allocated or RFC 1918 between you and your customers more than once simple map all of IPv4 space does not work. RFC 5969 does NOT say you must use 32 bits and actually lots of examples where it isn't done. > Nice burger. Om nom nom nom. > > Regards, > Bill Herrin > > > > --=20 > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From stephen at sprunk.org Fri Sep 21 00:01:57 2012 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 20 Sep 2012 19:01:57 -0500 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> Message-ID: <505BAE75.5010609@sprunk.org> On 18-Sep-12 23:11, Mike Hale wrote: > "this is the arin vigilante cultural view of the world. luckily, the disease does not propagate sufficiently to cross oceans." > > I'd love to hear the reasoning for this. Why would it be bad policy to force companies to use the resources they are assigned or give them back to the general pool? In theory, that sounds great. However, the legal basis for actually taking them back is questionable since they pre-date the RIR system, registration agreements, utilization requirements, etc. And, in practice, those who _aren't_ using their assignments have, for the most part, given them back voluntarily, so it's a moot point. Also, as in the case at hand, most of the blocks that generate complaints turn out to be, upon closer examination, actively in use but just not advertised--at least on the particular internet that the complainer is using. Hint: there is more than one internet. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2312 bytes Desc: S/MIME Cryptographic Signature URL: From bill at herrin.us Fri Sep 21 00:04:16 2012 From: bill at herrin.us (William Herrin) Date: Thu, 20 Sep 2012 20:04:16 -0400 Subject: IPv6 Burgers (was: IPv6 Ignorance) In-Reply-To: <20120920235048.D43D3257C254@drugs.dv.isc.org> References: <6738D7C4-2837-45D6-9DF9-76DF2DA2A554@intermapper.com> <20120920235048.D43D3257C254@drugs.dv.isc.org> Message-ID: On Thu, Sep 20, 2012 at 7:50 PM, Mark Andrews wrote: > In message , W > illiam Herrin writes: >> Worse, that's if we were managing IPv6 delegations the way we manage >> IPv4 delegations. We're not. We're using sparse allocation. And 6RD. >> And default customer allocations of 65,000 LANs. And other interesting >> stuff that drastically increases the consumption characteristics. > > 6rd can be dense as native deployment. In fact it is not hard to Have you heard the one about the difference between theory and practice? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From stephen at sprunk.org Fri Sep 21 00:13:14 2012 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 20 Sep 2012 19:13:14 -0500 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <50598664.9020302@gmail.com> References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <1A05B0E5-0269-4C14-9B30-5E424B990237@delong.com> <20120919065959.AFD332568362@drugs.dv.isc.org> <50598664.9020302@gmail.com> Message-ID: <505BB11A.8050706@sprunk.org> On 19-Sep-12 03:46, Alex Harrowell wrote: > On the other hand, the scarcity is of *globally unique routable* > addresses. You can make a case that private use of (non-RFC1918) IPv4 > resources is wasteful in itself at the moment. To be provocative, what > on earth is their excuse for not using IPv6 internally? By definition, > an internal network that isn't announced to the public Internet > doesn't have to worry about happy eyeballs, broken carrier NAT, and > the like because it doesn't have to be connected to them if it doesn't > want to be. A lot of the transition issues are much less problematic > if you're not on the public Internet. Actually, they're not any different, aside from scale. Some private internets have hundreds to thousands of participants, and they often use obscure protocols on obscure systems that were killed off by their vendors (if the vendors even exist anymore) a decade or more ago, and no source code or upgrade path is available. The "enterprise" networking world is just as ugly as, if not uglier than, the consumer one. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2312 bytes Desc: S/MIME Cryptographic Signature URL: From sethm at rollernet.us Fri Sep 21 00:26:54 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 20 Sep 2012 17:26:54 -0700 Subject: Verizon IPv6 LTE Message-ID: <505BB44E.9070006@rollernet.us> Does Verizon have IPv6 on their LTE network everywhere or is it limited to specific regions? I ask because I have a Verizon LTE iPad just upgraded to iOS6 (which supposedly added this capability), but it's not getting an IPv6 address on the LTE interface. Or does Verizon now need to authorize these newly capable devices as IPv6-able? ~Seth From trejrco at gmail.com Fri Sep 21 00:34:31 2012 From: trejrco at gmail.com (TJ) Date: Thu, 20 Sep 2012 20:34:31 -0400 Subject: Verizon IPv6 LTE In-Reply-To: <505BB44E.9070006@rollernet.us> References: <505BB44E.9070006@rollernet.us> Message-ID: My understanding, and experience (albeit with Android), is that all VZW LTE is IPv6-capable. I'd love to hear if Apple or VZW is at fault here, or if something weird is happening ... /TJ On Sep 20, 2012 8:28 PM, "Seth Mattinen" wrote: > Does Verizon have IPv6 on their LTE network everywhere or is it limited > to specific regions? I ask because I have a Verizon LTE iPad just > upgraded to iOS6 (which supposedly added this capability), but it's not > getting an IPv6 address on the LTE interface. Or does Verizon now need > to authorize these newly capable devices as IPv6-able? > > ~Seth > > From jared at puck.nether.net Fri Sep 21 00:35:45 2012 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 20 Sep 2012 20:35:45 -0400 Subject: Verizon IPv6 LTE In-Reply-To: <505BB44E.9070006@rollernet.us> References: <505BB44E.9070006@rollernet.us> Message-ID: <4790B93B-E648-45AC-9AEB-06B22C1CC4A8@puck.nether.net> I'm also curious about this. Jared Mauch On Sep 20, 2012, at 8:26 PM, Seth Mattinen wrote: > Does Verizon have IPv6 on their LTE network everywhere or is it limited > to specific regions? I ask because I have a Verizon LTE iPad just > upgraded to iOS6 (which supposedly added this capability), but it's not > getting an IPv6 address on the LTE interface. Or does Verizon now need > to authorize these newly capable devices as IPv6-able? > > ~Seth From cb.list6 at gmail.com Fri Sep 21 00:39:49 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Thu, 20 Sep 2012 17:39:49 -0700 Subject: Verizon IPv6 LTE In-Reply-To: <505BB44E.9070006@rollernet.us> References: <505BB44E.9070006@rollernet.us> Message-ID: On Sep 20, 2012 5:27 PM, "Seth Mattinen" wrote: > > Does Verizon have IPv6 on their LTE network everywhere or is it limited > to specific regions? I ask because I have a Verizon LTE iPad just > upgraded to iOS6 (which supposedly added this capability), but it's not > getting an IPv6 address on the LTE interface. Or does Verizon now need > to authorize these newly capable devices as IPv6-able? > > ~Seth > Verizon has ipv6 everywhere they have LTE. Verizon also requires it on all their LTE devices that they sell. Your problem is likely with Apple, they have not yet supported ipv6 on the cellular interface afaik. CB From jared at puck.nether.net Fri Sep 21 00:41:29 2012 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 20 Sep 2012 20:41:29 -0400 Subject: Verizon IPv6 LTE In-Reply-To: <505BB44E.9070006@rollernet.us> References: <505BB44E.9070006@rollernet.us> Message-ID: <21F1D9BF-BB16-4CC6-A839-682A843A4152@puck.nether.net> Oh... It works... Your IPv4 address on the public Internet appears to be 70.194.10.15 Your IPv6 address on the public Internet appears to be 2600:1007:b010:a057:d91a:7d40:9871:f1a3 10/11 tests run On Sep 20, 2012, at 8:26 PM, Seth Mattinen wrote: > Does Verizon have IPv6 on their LTE network everywhere or is it limited > to specific regions? I ask because I have a Verizon LTE iPad just > upgraded to iOS6 (which supposedly added this capability), but it's not > getting an IPv6 address on the LTE interface. Or does Verizon now need > to authorize these newly capable devices as IPv6-able? > > ~Seth From jared at puck.nether.net Fri Sep 21 00:44:47 2012 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 20 Sep 2012 20:44:47 -0400 Subject: Verizon IPv6 LTE In-Reply-To: References: <505BB44E.9070006@rollernet.us> Message-ID: <7B611A85-BDB4-4E93-B4C5-2FA44396FC09@puck.nether.net> On Sep 20, 2012, at 8:39 PM, Cameron Byrne wrote: > On Sep 20, 2012 5:27 PM, "Seth Mattinen" wrote: >> >> Does Verizon have IPv6 on their LTE network everywhere or is it limited >> to specific regions? I ask because I have a Verizon LTE iPad just >> upgraded to iOS6 (which supposedly added this capability), but it's not >> getting an IPv6 address on the LTE interface. Or does Verizon now need >> to authorize these newly capable devices as IPv6-able? >> >> ~Seth > > Verizon has ipv6 everywhere they have LTE. Verizon also requires it on all > their LTE devices that they sell. > > Your problem is likely with Apple, they have not yet supported ipv6 on the > cellular interface afaik. Looks to work. -- snip-- Your IPv4 address on the public Internet appears to be 70.194.10.15 Your IPv6 address on the public Internet appears to be 2600:1007:b010:a057:d91a:7d40:9871:f1a3 The World IPv6 Launch day is June 6th, 2012. Good news! Your current browser, on this computer and at this location, are expected to keep working after the Launch. [more info] Congratulations! You appear to have both IPv4 and IPv6 Internet working. If a publisher publishes to IPv6, your browser will connect using IPv6. Note: Your browser appears to prefer IPv4 over IPv6 when given the choice. This may in the future affect the accuracy of sites who guess at your location. Your DNS server (possibly run by your ISP) appears to have IPv6 Internet access. Your readiness scores 10/10 for your IPv4 stability and readiness, when publishers offer both IPv4 and IPv6 10/10 for your IPv6 stability and readiness, when publishers are forced to go IPv6 only Click to see test data (Updated server side IPv6 readiness stats) From cb.list6 at gmail.com Fri Sep 21 00:49:38 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Thu, 20 Sep 2012 17:49:38 -0700 Subject: Verizon IPv6 LTE In-Reply-To: <21F1D9BF-BB16-4CC6-A839-682A843A4152@puck.nether.net> References: <505BB44E.9070006@rollernet.us> <21F1D9BF-BB16-4CC6-A839-682A843A4152@puck.nether.net> Message-ID: On Sep 20, 2012 5:45 PM, "Jared Mauch" wrote: > > Oh... It works... > > > Your IPv4 address on the public Internet appears to be 70.194.10.15 > > Your IPv6 address on the public Internet appears to be 2600:1007:b010:a057:d91a:7d40:9871:f1a3 > > 10/11 tests run > Cool! That is from an ipad on vzw LTE? Ios6? CB > > On Sep 20, 2012, at 8:26 PM, Seth Mattinen wrote: > > > Does Verizon have IPv6 on their LTE network everywhere or is it limited > > to specific regions? I ask because I have a Verizon LTE iPad just > > upgraded to iOS6 (which supposedly added this capability), but it's not > > getting an IPv6 address on the LTE interface. Or does Verizon now need > > to authorize these newly capable devices as IPv6-able? > > > > ~Seth From mohta at necom830.hpcl.titech.ac.jp Fri Sep 21 00:51:10 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 21 Sep 2012 09:51:10 +0900 Subject: Big Temporary Networks In-Reply-To: References: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> <50561ADD.2040404@necom830.hpcl.titech.ac.jp> <505626A2.1090700@foobar.org> <505663DE.7000309@necom830.hpcl.titech.ac.jp> <50586620.6080702@necom830.hpcl.titech.ac.jp> <505973A4.90705@necom830.hpcl.titech.ac.jp> <505A40CD.8030701@necom830.hpcl.titech.ac.jp> <505A7033.6040807@necom830.hpcl.titech.ac.jp> <505A8E76.3030800@necom830.hpcl.titech.ac.jp> <505A9DC8.2040508@tiggee.com> <505AB5E1.7080204@necom830.hpcl.titech.ac.jp> Message-ID: <505BB9FE.9010501@necom830.hpcl.titech.ac.jp> TJ wrote: >>> So, a single example of IPv4 behaving in a suboptimal manner would be >>> enough to declare IPv4 not operational? >> >> For example? > "Heavy reliance on broadcast for a wide range of instances where the > traffic is really only destined for a single node" would seem to be rather > sub-optimal. It's not sub-optimal w.r.t. link bandwidth, if the link is a broadcast domain. Moreover, broadcast is no worse than all-node multicast. And, given the CATENET model of the Internet to connect broadcast domains including small number of devices by routers, over which there is no broadcast, that is a sub-optimal operation. In this thread, there is an example of such an operation to have a lot of WiFi base stations with omnidirectional antennas at full power. No protocol can be fool proof against sub-optimal operations. Masataka Ohta From jared at puck.nether.net Fri Sep 21 00:58:29 2012 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 20 Sep 2012 20:58:29 -0400 Subject: Verizon IPv6 LTE In-Reply-To: References: <505BB44E.9070006@rollernet.us> <21F1D9BF-BB16-4CC6-A839-682A843A4152@puck.nether.net> Message-ID: On Sep 20, 2012, at 8:49 PM, Cameron Byrne wrote: > > On Sep 20, 2012 5:45 PM, "Jared Mauch" wrote: > > > > Oh... It works... > > > > > > Your IPv4 address on the public Internet appears to be 70.194.10.15 > > > > Your IPv6 address on the public Internet appears to be 2600:1007:b010:a057:d91a:7d40:9871:f1a3 > > > > 10/11 tests run > > > > Cool! > > That is from an ipad on vzw LTE? Ios6? > Yes... Please don't hack or ddos it :-) I'm guessing there will be a lot of new ipv6 traffic from LTE handsets on vzw tomorrow. Should be interesting if apple turned on their Phobos domains for App Store as v6 via akamai. I would expect a lot of traffic to shift then. - Jared From tknchris at gmail.com Fri Sep 21 01:11:43 2012 From: tknchris at gmail.com (chris) Date: Thu, 20 Sep 2012 21:11:43 -0400 Subject: Verizon IPv6 LTE In-Reply-To: References: <505BB44E.9070006@rollernet.us> <21F1D9BF-BB16-4CC6-A839-682A843A4152@puck.nether.net> Message-ID: thank god for unlimited 4g on vz :) hold onto it while you can they are trying hard to kill it! On Thu, Sep 20, 2012 at 8:58 PM, Jared Mauch wrote: > > > On Sep 20, 2012, at 8:49 PM, Cameron Byrne wrote: > > > > > On Sep 20, 2012 5:45 PM, "Jared Mauch" wrote: > > > > > > Oh... It works... > > > > > > > > > Your IPv4 address on the public Internet appears to be 70.194.10.15 > > > > > > Your IPv6 address on the public Internet appears to be > 2600:1007:b010:a057:d91a:7d40:9871:f1a3 > > > > > > 10/11 tests run > > > > > > > Cool! > > > > That is from an ipad on vzw LTE? Ios6? > > > > > Yes... > > Please don't hack or ddos it :-) > > I'm guessing there will be a lot of new ipv6 traffic from LTE handsets on > vzw tomorrow. > > Should be interesting if apple turned on their Phobos domains for App > Store as v6 via akamai. I would expect a lot of traffic to shift then. > > - Jared From jared at puck.nether.net Fri Sep 21 01:22:49 2012 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 20 Sep 2012 21:22:49 -0400 Subject: Verizon IPv6 LTE In-Reply-To: References: <505BB44E.9070006@rollernet.us> <21F1D9BF-BB16-4CC6-A839-682A843A4152@puck.nether.net> Message-ID: <044B62A1-D99E-4B04-9D11-67C2E375984B@puck.nether.net> One other thing... When on non-v6 wifi, it appears to still be using LTE for v6... (At least according to test-ipv6.com) This could result in some unexpected usage patterns.. - Jared On Sep 20, 2012, at 8:49 PM, Cameron Byrne wrote: > Cool! > > That is from an ipad on vzw LTE? Ios6? > From sethm at rollernet.us Fri Sep 21 01:27:42 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 20 Sep 2012 18:27:42 -0700 Subject: Verizon IPv6 LTE In-Reply-To: References: <505BB44E.9070006@rollernet.us> Message-ID: <505BC28E.2020203@rollernet.us> On 9/20/12 5:39 PM, Cameron Byrne wrote: > > Your problem is likely with Apple, they have not yet supported ipv6 on > the cellular interface afaik. > Well, that's true under iOS 5, but iOS 6 released yesterday (and assuming you have a third gen iPad with LTE) was supposed to correct that. It runs IPv6 like a champ on wifi but I was excited to install the update to finally have my first IPv6 connection that wasn't through my AS. ~Seth From sethm at rollernet.us Fri Sep 21 01:33:46 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 20 Sep 2012 18:33:46 -0700 Subject: Verizon IPv6 LTE In-Reply-To: <505BB44E.9070006@rollernet.us> References: <505BB44E.9070006@rollernet.us> Message-ID: <505BC3FA.2030507@rollernet.us> Huh, so I come home and now I'm getting IPv6 from Verizon LTE. But I definitely wasn't at the office. I verified with an app called "IT Tools" that shows the interfaces and routing table, plus it does traceroute/ping. Maybe the nearest tower over there doesn't support IPv6? Odd. Running test-ipv6.com it passes all tests except "test if your ISP's DNS server uses IPv6". ~Seth From sethm at rollernet.us Fri Sep 21 01:37:34 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 20 Sep 2012 18:37:34 -0700 Subject: Verizon IPv6 LTE In-Reply-To: <505BC3FA.2030507@rollernet.us> References: <505BB44E.9070006@rollernet.us> <505BC3FA.2030507@rollernet.us> Message-ID: <505BC4DE.70601@rollernet.us> On 9/20/12 6:33 PM, Seth Mattinen wrote: > > Huh, so I come home and now I'm getting IPv6 from Verizon LTE. But I > definitely wasn't at the office. I verified with an app called "IT > Tools" that shows the interfaces and routing table, plus it does > traceroute/ping. Maybe the nearest tower over there doesn't support > IPv6? Odd. > Safari on the iPad seems to be preferring A over AAAA if a hostname has both, though. I can browse to a bracketed IPv6 address so it is working. ~Seth From trejrco at gmail.com Fri Sep 21 01:47:00 2012 From: trejrco at gmail.com (TJ) Date: Thu, 20 Sep 2012 21:47:00 -0400 Subject: Verizon IPv6 LTE In-Reply-To: <505BC4DE.70601@rollernet.us> References: <505BB44E.9070006@rollernet.us> <505BC3FA.2030507@rollernet.us> <505BC4DE.70601@rollernet.us> Message-ID: Did Apple use their version of Happy Eyeballs on the iPads? ISTR they cache certain timeouts, so if IPv6 was failing before it may take awhile for it to become preferred again. /TJ On Thu, Sep 20, 2012 at 9:37 PM, Seth Mattinen wrote: > On 9/20/12 6:33 PM, Seth Mattinen wrote: > > > > Huh, so I come home and now I'm getting IPv6 from Verizon LTE. But I > > definitely wasn't at the office. I verified with an app called "IT > > Tools" that shows the interfaces and routing table, plus it does > > traceroute/ping. Maybe the nearest tower over there doesn't support > > IPv6? Odd. > > > > > Safari on the iPad seems to be preferring A over AAAA if a hostname has > both, though. I can browse to a bracketed IPv6 address so it is working. > > ~Seth > > From sethm at rollernet.us Fri Sep 21 01:48:51 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 20 Sep 2012 18:48:51 -0700 Subject: Verizon IPv6 LTE In-Reply-To: References: <505BB44E.9070006@rollernet.us> <505BC3FA.2030507@rollernet.us> <505BC4DE.70601@rollernet.us> Message-ID: <505BC783.4020809@rollernet.us> On 9/20/12 6:47 PM, TJ wrote: > Did Apple use their version of Happy Eyeballs on the iPads? > ISTR they cache certain timeouts, so if IPv6 was failing before it may take > awhile for it to become preferred again. > Well, I can try creating a new DNS record that never existed before and see. ~Seth From george.herbert at gmail.com Fri Sep 21 01:51:41 2012 From: george.herbert at gmail.com (George Herbert) Date: Thu, 20 Sep 2012 18:51:41 -0700 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <505BB11A.8050706@sprunk.org> References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <1A05B0E5-0269-4C14-9B30-5E424B990237@delong.com> <20120919065959.AFD332568362@drugs.dv.isc.org> <50598664.9020302@gmail.com> <505BB11A.8050706@sprunk.org> Message-ID: On Thu, Sep 20, 2012 at 5:13 PM, Stephen Sprunk wrote: > On 19-Sep-12 03:46, Alex Harrowell wrote: >> On the other hand, the scarcity is of *globally unique routable* >> addresses. You can make a case that private use of (non-RFC1918) IPv4 >> resources is wasteful in itself at the moment. To be provocative, what >> on earth is their excuse for not using IPv6 internally? By definition, >> an internal network that isn't announced to the public Internet >> doesn't have to worry about happy eyeballs, broken carrier NAT, and >> the like because it doesn't have to be connected to them if it doesn't >> want to be. A lot of the transition issues are much less problematic >> if you're not on the public Internet. > > Actually, they're not any different, aside from scale. Some private > internets have hundreds to thousands of participants, and they often use > obscure protocols on obscure systems that were killed off by their > vendors (if the vendors even exist anymore) a decade or more ago, and no > source code or upgrade path is available. > > The "enterprise" networking world is just as ugly as, if not uglier > than, the consumer one. I haven't worked much on the commercial private internets, but I did work for someone who connected on the back end into numerous telco cellphone IP data networks. For all of those who argue that these applications should use 1918 space, I give you those networks, where at one point I counted literally 8 different 10.200.x/16 nets I could talk to at different partners (scarily enough, 2 of those were "the same company"...). And hundreds and hundreds of other space conflicts. Yes, you can NAT all of that, but if you get network issues where you need to know the phone end address and do end to end debugging on stuff, there are no curse words strong enough in the English language. -- -george william herbert george.herbert at gmail.com From sethm at rollernet.us Fri Sep 21 02:01:48 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 20 Sep 2012 19:01:48 -0700 Subject: Verizon IPv6 LTE In-Reply-To: References: <505BB44E.9070006@rollernet.us> <505BC3FA.2030507@rollernet.us> <505BC4DE.70601@rollernet.us> Message-ID: <505BCA8C.8040901@rollernet.us> On 9/20/12 6:47 PM, TJ wrote: > Did Apple use their version of Happy Eyeballs on the iPads? > ISTR they cache certain timeouts, so if IPv6 was failing before it may take > awhile for it to become preferred again. > It seems you may be correct. ~Seth From rcarpen at network1.net Fri Sep 21 03:00:37 2012 From: rcarpen at network1.net (Randy Carpenter) Date: Thu, 20 Sep 2012 23:00:37 -0400 (EDT) Subject: Verizon IPv6 LTE In-Reply-To: <505BCA8C.8040901@rollernet.us> Message-ID: <2138595174.221799.1348196437402.JavaMail.root@network1.net> Safari is definitely preferring IPv4. In a happier note, if you tether a device via hotspot on an IOS6 iPad, the clients get native IPv6. Strangely, they get addresses out of the same /64 as the iPad's LTE interface. Anyone know how that is working? I would have thought they would use prefix-delegation, and there would be a separate routed /64. thanks, -Randy ----- Original Message ----- > On 9/20/12 6:47 PM, TJ wrote: > > Did Apple use their version of Happy Eyeballs on the iPads? > > ISTR they cache certain timeouts, so if IPv6 was failing before it > > may take > > awhile for it to become preferred again. > > > > > It seems you may be correct. > > ~Seth > > > From streiner at cluebyfour.org Fri Sep 21 03:45:51 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 20 Sep 2012 23:45:51 -0400 (EDT) Subject: Verizon IPv6 LTE In-Reply-To: References: <505BB44E.9070006@rollernet.us> Message-ID: On Thu, 20 Sep 2012, TJ wrote: > My understanding, and experience (albeit with Android), is that all VZW LTE > is IPv6-capable. > > I'd love to hear if Apple or VZW is at fault here, or if something weird is > happening ... I don't know about Apple devices on VZW, but my Android phone definitely has IPv6 connectivity on VZW 4G LTE in Pittsburgh. jms From mohta at necom830.hpcl.titech.ac.jp Fri Sep 21 03:54:49 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 21 Sep 2012 12:54:49 +0900 Subject: Big Temporary Networks In-Reply-To: <00b301cd975f$2ee354b0$8ca9fe10$@tndh.net> References: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> <50561ADD.2040404@necom830.hpcl.titech.ac.jp> <505626A2.1090700@foobar.org> <505663DE.7000309@necom830.hpcl.titech.ac.jp> <50586620.6080702@necom830.hpcl.titech.ac.jp> <505973A4.90705@necom830.hpcl.titech.ac.jp> <505A40CD.8030701@necom830.hpcl.titech.ac.jp> <505A7033.6040807@necom830.hpcl.titech.ac.jp> <505A8E76.3030800@necom830.hpcl.titech.ac.jp> <505A9DC8.2040508@tiggee.com> <505AB5E1.7080204@necom830.hpcl.titech.ac.jp> <00b301cd975f$2ee354b0$8ca9fe10$@tndh.net> Message-ID: <505BE509.1000008@necom830.hpcl.titech.ac.jp> Tony Hain wrote: >>> So, a single example of IPv4 behaving in a suboptimal manner would be >>> enough to declare IPv4 not operational? >> >> For example? > > Your own example --- >> ... that a very crowded train arrives at a station and all the smart > phones of passengers try to connect to APs ... > > IPv4 has a train load of devices unicasting and retransmitting all the > dropped packets, IPv4 merely need a broadcast ARP request and broadcast DHCP discover to be piggy backed in a single IEEE802.11ai frame reliably unicast to an AP. > where an IPv6 multicast RA allows all the devices to > configure based on reception of a single packet. You miss multicast storm caused by DAD. > Just because you personally want IPv6 to be nothing more than IPv4 > in every aspect is no reason to troll the nanog list and create > confusion that causes others to delay their IPv6 deployment. Just because IPv6 is working without much problem somehow somewhere is not a valid reason to say others should use IPv6. As IP is so essential to the Internet, IP protocol must be perfect w.r.t. the scale and diversity of the Internet. IPv4 has evolved so, as the Internet evolve. IPv6 could have been so, if it were a exact copy of IPv4 save address length. But, it is not, which is why IPv6 failed on various points which are different from IPv4. > Your complaints about IPv6 behavior > on wifi ignore the point that IPv6 ND behavior was defined before or in > parallel as wifi was defined by a different committee. The problem is "ND uber Alles" approach, which makes it impossible to make "IP uber Alles". > There will always be > newer L2 technologies that arrive after an L3 protocol is defined, and the > behavior of the L3 will be 'suboptimal' for the new L2. When the issue is > serious enough to warrant documentation, addendum documents are issued. Because of "ND uber Alles" approach, the document just says "IPv6 works suboptimal" without solving the issue. OTOH with IPv4, the document can solve the problem by having a new adaptation mechanism much different from ARP or PPP. Masataka Ohta From swmike at swm.pp.se Fri Sep 21 04:14:49 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 21 Sep 2012 06:14:49 +0200 (CEST) Subject: Verizon IPv6 LTE In-Reply-To: <2138595174.221799.1348196437402.JavaMail.root@network1.net> References: <2138595174.221799.1348196437402.JavaMail.root@network1.net> Message-ID: On Thu, 20 Sep 2012, Randy Carpenter wrote: > In a happier note, if you tether a device via hotspot on an IOS6 iPad, > the clients get native IPv6. Strangely, they get addresses out of the > same /64 as the iPad's LTE interface. Anyone know how that is working? I > would have thought they would use prefix-delegation, and there would be > a separate routed /64. Prefix delegation isn't generally available in mobile networks yet, that'll come in the next few years. It's probably using ND proxy or similar technique. is a good starting point for further study, more specifically to answer your above question. -- Mikael Abrahamsson email: swmike at swm.pp.se From paul4004 at gmail.com Fri Sep 21 05:15:56 2012 From: paul4004 at gmail.com (PC) Date: Thu, 20 Sep 2012 23:15:56 -0600 Subject: Verizon IPv6 LTE In-Reply-To: References: <505BB44E.9070006@rollernet.us> <21F1D9BF-BB16-4CC6-A839-682A843A4152@puck.nether.net> Message-ID: "Please don't hack or ddos it :-) " Unfortunately, while you do get an ipv6 address, mobile terminated data doesn't work, so you don't have to worry about this. It is firewalled by Verizon. I actually tried to set up a VPN on a LTE data card using the ipv6 address since the IPV4 one is behind carrier grade NAT. I found out the hard way that was a no-go, either. One more tip: IPv6 will work over the legacy 3g network. Don't ask me much about it, but it "tunnels" it using eHRPD to the same IP/IPv6 headend to enable seamless EVDO/LTE handover. On Thu, Sep 20, 2012 at 6:58 PM, Jared Mauch wrote: > > > On Sep 20, 2012, at 8:49 PM, Cameron Byrne wrote: > > > > > On Sep 20, 2012 5:45 PM, "Jared Mauch" wrote: > > > > > > Oh... It works... > > > > > > > > > Your IPv4 address on the public Internet appears to be 70.194.10.15 > > > > > > Your IPv6 address on the public Internet appears to be > 2600:1007:b010:a057:d91a:7d40:9871:f1a3 > > > > > > 10/11 tests run > > > > > > > Cool! > > > > That is from an ipad on vzw LTE? Ios6? > > > > > Yes... > > Please don't hack or ddos it :-) > > I'm guessing there will be a lot of new ipv6 traffic from LTE handsets on > vzw tomorrow. > > Should be interesting if apple turned on their Phobos domains for App > Store as v6 via akamai. I would expect a lot of traffic to shift then. > > - Jared From tore.anderson at redpill-linpro.com Fri Sep 21 05:51:02 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Fri, 21 Sep 2012 07:51:02 +0200 Subject: Verizon IPv6 LTE In-Reply-To: References: <505BB44E.9070006@rollernet.us> <21F1D9BF-BB16-4CC6-A839-682A843A4152@puck.nether.net> Message-ID: <505C0046.4050403@redpill-linpro.com> * PC > One more tip: IPv6 will work over the legacy 3g network. Don't ask me > much about it, but it "tunnels" it using eHRPD to the same IP/IPv6 headend > to enable seamless EVDO/LTE handover. Interesting. Does this happens only if you start out in LTE coverage and then roam onto EV-DO, or does IPv6 work if you connect to the network outside of LTE coverage too? I wonder if there will be similar magic provided for UMTS/LTE networks.. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From swmike at swm.pp.se Fri Sep 21 05:59:30 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 21 Sep 2012 07:59:30 +0200 (CEST) Subject: Verizon IPv6 LTE In-Reply-To: <505C0046.4050403@redpill-linpro.com> References: <505BB44E.9070006@rollernet.us> <21F1D9BF-BB16-4CC6-A839-682A843A4152@puck.nether.net> <505C0046.4050403@redpill-linpro.com> Message-ID: On Fri, 21 Sep 2012, Tore Anderson wrote: > I wonder if there will be similar magic provided for UMTS/LTE networks.. I doubt it. The path there should be to upgrade GSM/UMTS network to release 9 and support v4v6 pdp context and then you don't need any magic at all (as far as I can tell). -- Mikael Abrahamsson email: swmike at swm.pp.se From jamie at photon.com Fri Sep 21 11:19:30 2012 From: jamie at photon.com (Jamie Bowden) Date: Fri, 21 Sep 2012 11:19:30 +0000 Subject: Verizon IPv6 LTE In-Reply-To: References: <505BB44E.9070006@rollernet.us> Message-ID: <465966A5F5B867419F604CD3E604C1E5063738F4@PRA-DCA-MAIL.pra.ray.com> > Justin M. Streiner > On Thu, 20 Sep 2012, TJ wrote: > > > My understanding, and experience (albeit with Android), is that all > VZW LTE > > is IPv6-capable. > > > > I'd love to hear if Apple or VZW is at fault here, or if something > weird is > > happening ... > > I don't know about Apple devices on VZW, but my Android phone > definitely > has IPv6 connectivity on VZW 4G LTE in Pittsburgh. Same in the DC Metro area. My RAZR is all v6 all the time on LTE. Jamie From bclaise at cisco.com Fri Sep 21 12:48:36 2012 From: bclaise at cisco.com (Benoit Claise) Date: Fri, 21 Sep 2012 14:48:36 +0200 Subject: Real world sflow vs netflow? In-Reply-To: References: Message-ID: <505C6224.3040409@cisco.com> http://www.plixer.com/blog/netflow/netflow-vs-sflow-for-network-monitoring-and-security-the-final-say/ Regards, Benoit. > Can anyone on or off list give me some real world > thoughts on sflow vs netflow for border > routers? (multi-homed, BGP, straight v4 & v6 only > for web hosting, no mpls, vpns, vlans, etc.) > > Finding it hard to decipher the vendor version > of the answer to that question. We use > netflow v9 currently but are considering hardware > that would be sflow. We don't use it for > billing purposes, mostly for spotting malicious > remote hosts doing things like scans, spotting > traffic such as weird ports in use in either > direction that warrant further investigation, > watching for ddos/dos destinations to act on > mitigation, or investigating the nature of unusual > levels of traffic on switch ports that set off > alarms. I'm concerned things like port scans, > etc. won't be picked up by the NMS if fed by > sflow due to the sampling nature, or similar > concern if 500 ssh connections by the same remote > host are sampled as 1 connection, etc. Of course > these concerns were put in my head by someone > interested in me continuing to use equipment that > happens to output netflow data, hence me wanting some > real people answers. :-) > > Thanks! > > > > From mark at amplex.net Fri Sep 21 13:31:25 2012 From: mark at amplex.net (Mark Radabaugh) Date: Fri, 21 Sep 2012 09:31:25 -0400 Subject: Throw me a IPv6 bone (sort of was IPv6 ignorance) Message-ID: <505C6C2D.7030204@amplex.net> The part of IPv6 that I am unclear on and have not found much documentation on is how to run IPv6 only to end users. Anyone care to point me in the right direction? Can we assign IPv6 only to end users? What software/equipment do we need in place as a ISP to ensure these customers can reach IPv4 only hosts? The Interwebs are full of advice on setting up IPv6 tunnels for your house (nice but...). There is lots of really old documentation out there for IPv6 mechanisms that are depreciated or didn't fly. What is current best practice? -- Mark Radabaugh Amplex mark at amplex.net 419.837.5015 From cb.list6 at gmail.com Fri Sep 21 13:40:25 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Fri, 21 Sep 2012 06:40:25 -0700 Subject: Verizon IPv6 LTE In-Reply-To: References: <505BB44E.9070006@rollernet.us> <21F1D9BF-BB16-4CC6-A839-682A843A4152@puck.nether.net> Message-ID: On Thu, Sep 20, 2012 at 10:15 PM, PC wrote: > "Please don't hack or ddos it :-) " > > Unfortunately, while you do get an ipv6 address, mobile terminated data > doesn't work, so you don't have to worry about this. It is firewalled by > Verizon. > T-Mobile USA allows mobile terminated data on IPv6 http://www.androidpolice.com/2012/01/29/t-mobile-usa-testing-ipv6-on-select-devices-here-is-what-it-all-means-and-yes-no-more-nat/ CB > I actually tried to set up a VPN on a LTE data card using the ipv6 address > since the IPV4 one is behind carrier grade NAT. I found out the hard way > that was a no-go, either. > > One more tip: IPv6 will work over the legacy 3g network. Don't ask me much > about it, but it "tunnels" it using eHRPD to the same IP/IPv6 headend to > enable seamless EVDO/LTE handover. > > > On Thu, Sep 20, 2012 at 6:58 PM, Jared Mauch wrote: >> >> >> >> On Sep 20, 2012, at 8:49 PM, Cameron Byrne wrote: >> >> > >> > On Sep 20, 2012 5:45 PM, "Jared Mauch" wrote: >> > > >> > > Oh... It works... >> > > >> > > >> > > Your IPv4 address on the public Internet appears to be 70.194.10.15 >> > > >> > > Your IPv6 address on the public Internet appears to be >> > > 2600:1007:b010:a057:d91a:7d40:9871:f1a3 >> > > >> > > 10/11 tests run >> > > >> > >> > Cool! >> > >> > That is from an ipad on vzw LTE? Ios6? >> > >> >> >> Yes... >> >> Please don't hack or ddos it :-) >> >> I'm guessing there will be a lot of new ipv6 traffic from LTE handsets on >> vzw tomorrow. >> >> Should be interesting if apple turned on their Phobos domains for App >> Store as v6 via akamai. I would expect a lot of traffic to shift then. >> >> - Jared > > From jeroen at unfix.org Fri Sep 21 13:40:48 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 21 Sep 2012 15:40:48 +0200 Subject: Throw me a IPv6 bone (sort of was IPv6 ignorance) In-Reply-To: <505C6C2D.7030204@amplex.net> References: <505C6C2D.7030204@amplex.net> Message-ID: <505C6E60.3000806@unfix.org> On 2012-09-21 15:31 , Mark Radabaugh wrote: > > The part of IPv6 that I am unclear on and have not found much > documentation on is how to run IPv6 only to end users. Anyone care to > point me in the right direction? > > Can we assign IPv6 only to end users? What software/equipment do we > need in place as a ISP to ensure these customers can reach IPv4 only hosts? > > The Interwebs are full of advice on setting up IPv6 tunnels for your > house (nice but...). There is lots of really old documentation out > there for IPv6 mechanisms that are depreciated or didn't fly. > > What is current best practice? The IETF BCP is to deploy Dual Stack, thus both IPv4 and IPv6 at the same time. When that is not possible, as you ran out of IPv4 addresses, you should look at Dual Stack Lite (DS Lite) eg as supplied by ISC's AFTR and other such implementations. Depending on your business model you can of course also stick everybody behind a huge NAT or require them to use HTTP proxies to get to the Internet as most people define it... Do note that if you are asking any of these questions today you are years late in reading up and you missed your chance to be prepared for this in all kinds of ways. Greets, Jeroen From jared at puck.nether.net Fri Sep 21 14:04:22 2012 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 21 Sep 2012 10:04:22 -0400 Subject: Throw me a IPv6 bone (sort of was IPv6 ignorance) In-Reply-To: <505C6C2D.7030204@amplex.net> References: <505C6C2D.7030204@amplex.net> Message-ID: On Sep 21, 2012, at 9:31 AM, Mark Radabaugh wrote: > The part of IPv6 that I am unclear on and have not found much documentation on is how to run IPv6 only to end users. Anyone care to point me in the right direction? This all depends on how your manage your last-mile and terminate users now. I have a friend with a local WISP here and he gives everyone a /24 out of 172.16/12 and dumps them through his load-balancer for his few connections. His "CGN" box seems to handle this fine. > Can we assign IPv6 only to end users? What software/equipment do we need in place as a ISP to ensure these customers can reach IPv4 only hosts? I would say you want to do dual-stack, but shift the users that don't *need* public IPs into 1918 space and deliver v6 native as feasible. If you have a server lan, you can do this with SLAAC, but to get the other information to your hosts, either via RA's and otherwise, it's just becoming easier to do. PPPo* you can get IPv6 IPCP up and going, but the device has to support it. > The Interwebs are full of advice on setting up IPv6 tunnels for your house (nice but...). There is lots of really old documentation out there for IPv6 mechanisms that are depreciated or didn't fly. ASR1K and other devices can serve as nat64.. (I think Juniper does the same, but I don't recall their roadmap/product set). I'm sure you can do it with a Linux or *BSD box as well. > What is current best practice? I would say there is none as it largely depends on how you terminate that transport, and there are a few ways one can do that. Hope this helps, - Jared From richard.barnes at gmail.com Fri Sep 21 14:50:41 2012 From: richard.barnes at gmail.com (Richard Barnes) Date: Fri, 21 Sep 2012 10:50:41 -0400 Subject: Throw me a IPv6 bone (sort of was IPv6 ignorance) In-Reply-To: <505C6C2D.7030204@amplex.net> References: <505C6C2D.7030204@amplex.net> Message-ID: The folks that have done the most work in enabling IPv6-only end users seem to be CERNET2 in China. To let people get to v4, they're using what they call IVI (get it?), which is basically NAT64+DNS64. If you don't mind running IPv4 in a tunnel over that IPv6 network, you can do DSlite or 4rd < http://en.wikipedia.org/wiki/IPv6_transition_mechanisms#Dual-Stack_Lite_.28DS-Lite.29 > On Friday, September 21, 2012, Mark Radabaugh wrote: > > The part of IPv6 that I am unclear on and have not found much > documentation on is how to run IPv6 only to end users. Anyone care to > point me in the right direction? > > Can we assign IPv6 only to end users? What software/equipment do we need > in place as a ISP to ensure these customers can reach IPv4 only hosts? > > The Interwebs are full of advice on setting up IPv6 tunnels for your house > (nice but...). There is lots of really old documentation out there for > IPv6 mechanisms that are depreciated or didn't fly. > > What is current best practice? > > -- > Mark Radabaugh > Amplex > > mark at amplex.net 419.837.5015 > > > From joelja at bogus.com Fri Sep 21 14:57:50 2012 From: joelja at bogus.com (joel jaeggli) Date: Fri, 21 Sep 2012 07:57:50 -0700 Subject: Throw me a IPv6 bone (sort of was IPv6 ignorance) In-Reply-To: <505C6E60.3000806@unfix.org> References: <505C6C2D.7030204@amplex.net> <505C6E60.3000806@unfix.org> Message-ID: <505C806E.2090000@bogus.com> On 9/21/12 6:40 AM, Jeroen Massar wrote: > On 2012-09-21 15:31 , Mark Radabaugh wrote: >> The part of IPv6 that I am unclear on and have not found much >> documentation on is how to run IPv6 only to end users. Anyone care to >> point me in the right direction? >> >> Can we assign IPv6 only to end users? What software/equipment do we >> need in place as a ISP to ensure these customers can reach IPv4 only hosts? >> >> The Interwebs are full of advice on setting up IPv6 tunnels for your >> house (nice but...). There is lots of really old documentation out >> there for IPv6 mechanisms that are depreciated or didn't fly. >> >> What is current best practice? > The IETF BCP is to deploy Dual Stack, thus both IPv4 and IPv6 at the > same time. That's likely to be congruent with the expectations of residential customers but it's not the sole model we've seen, at some point IPv4 backward compatibility plays second fiddle to your ipv6 deployment. the alternatives do get discussed, e.g. http://tools.ietf.org/html/rfc6180 > When that is not possible, as you ran out of IPv4 addresses, you should > look at Dual Stack Lite (DS Lite) eg as supplied by ISC's AFTR and other > such implementations. > > Depending on your business model you can of course also stick everybody > behind a huge NAT or require them to use HTTP proxies to get to the > Internet as most people define it... > > > Do note that if you are asking any of these questions today you are > years late in reading up and you missed your chance to be prepared for > this in all kinds of ways. > > Greets, > Jeroen > > > From sethm at rollernet.us Fri Sep 21 15:48:50 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 21 Sep 2012 08:48:50 -0700 Subject: Verizon IPv6 LTE In-Reply-To: <505BB44E.9070006@rollernet.us> References: <505BB44E.9070006@rollernet.us> Message-ID: <505C8C62.5070406@rollernet.us> So I'm back at the office this morning and the iPad is *not* getting an IPv6 address but is showing LTE service. It did do IPv6 over LTE at home so it's not a device problem. So I suppose the closest tower to my office is not IPv6 enabled. Is this an expected behavior in some areas or something that needs fixing? ~Seth From bill at herrin.us Fri Sep 21 15:54:21 2012 From: bill at herrin.us (William Herrin) Date: Fri, 21 Sep 2012 11:54:21 -0400 Subject: Big Temporary Networks In-Reply-To: <505BE509.1000008@necom830.hpcl.titech.ac.jp> References: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> <50561ADD.2040404@necom830.hpcl.titech.ac.jp> <505626A2.1090700@foobar.org> <505663DE.7000309@necom830.hpcl.titech.ac.jp> <50586620.6080702@necom830.hpcl.titech.ac.jp> <505973A4.90705@necom830.hpcl.titech.ac.jp> <505A40CD.8030701@necom830.hpcl.titech.ac.jp> <505A7033.6040807@necom830.hpcl.titech.ac.jp> <505A8E76.3030800@necom830.hpcl.titech.ac.jp> <505A9DC8.2040508@tiggee.com> <505AB5E1.7080204@necom830.hpcl.titech.ac.jp> <00b301cd975f$2ee354b0$8ca9fe10$@tndh.net> <505BE509.1000008@necom830.hpcl.titech.ac.jp> Message-ID: On Thu, Sep 20, 2012 at 11:54 PM, Masataka Ohta wrote: > Tony Hain wrote: >> where an IPv6 multicast RA allows all the devices to >> configure based on reception of a single packet. > > You miss multicast storm caused by DAD. This is a long solved issue. First, it already occurs with ARP broadcasts which the AP in principle resends out to everybody else on the wlan. Second, in the hotspot scenarios where this is likely to be a problem (in IPv4 -or- IPv6) it's addressed by the "AP isolation" feature that's getting close to omnipresent even in the low end APs. With this feature enabled, stations are not allowed to talk to each other over the wlan; they can only talk to hosts on the wired side of the lan. The DAD packets are simply never sent to the other stations. In theory there are some problems with this. In practice, it's in wide deployment and has been demonstrated to work just fine. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From uwcableguy at gmail.com Fri Sep 21 16:04:15 2012 From: uwcableguy at gmail.com (Ben Bartsch) Date: Fri, 21 Sep 2012 11:04:15 -0500 Subject: TWTC BGP IPv6 /40 prefix Message-ID: I am trying to add a /40 prefix to be accepted by a couple of TWTC circuits we have in Louisiana (Shreveport and Baton Rouge). My only options available are /32, /48, /56, /64 in the web portal. Is there somebody from TWTC that could contact me off list? Thanks. -bb From nick at foobar.org Fri Sep 21 16:13:09 2012 From: nick at foobar.org (Nick Hilliard) Date: Fri, 21 Sep 2012 17:13:09 +0100 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <00e701cd978a$5654c710$02fe5530$@tndh.net> References: <20120918140712.GF9750@leitl.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> <231483E9-5129-4722-87DE-635FEC3AC422@virtualized.org> <505A440D.5080701@dougbarton.us> <505A48D8.4040800@ttec.com> <36217.1348098710@turing-police.cc.vt.edu> <505A6844.9050703@ttec.com> <505A99D9.6010109@ttec.com> <505AC3F8.9060905@bogus.com> <8270A4D4-5B82-45B6-BD78-FD3586545D6F@gmail.com> <505B23E0.4030906@ttec.com> <00bc01cd9764$3aa38090$afea81b0$@tndh.net> <505B8C7B.7000408@foobar.org> <00e701cd978a$5654c710$02fe5530$@tndh.net> Message-ID: <505C9215.6000108@foobar.org> On 21/09/2012 00:47, Tony Hain wrote: > You are comparing IPv6 to the historical deployment of IPv4. Get with the > times and realize that CGN/LSN breaks all those wonderful location-aware > apps people are so into now, not to mention raising the cost for operating > the network which eventually get charged back to the user. Address translation (already commonplace on many networks) is the consequence of the lack of a scalable addressing model. Yup, NAT breaks lots of things. Piles. It sucks. > Nanog in general has a problem taking the myopic viewpoint 'the only thing > that matters is the network'. Networking people build and (in some cases) care about networks. It's not the job of nanog people to fret about software development. > The real costs are in app development and > support It's certainly one of the costs. And application developers have only just begun to realise that they now need to be aware of the network. Previously, they could just open up sockets and fling data around. Now they need to handle protocol failover and multiple connectivity addresses and the like. Yep, it's an extra cost point - one which has been studiously ignored by most ipv6 evangelists over the lifetime of ipv6. > That depends on your time horizon and budget cycles. If your org suffers > from the short-term focus imposed by Wall Street, Most organisations are in this category, not just those beholden to the whims of Wall Street. > If operators would put less effort into blocking transition technologies and > channel that energy into deploying real IPv6, the sorry state wouldn't be > there. There are never shortages of fingers when failures happen, whether they be used for wagging or pointing. > For all the complaints about 6to4, it was never intended to be the > mainstay, it was supposed to be the fall back for people that had a lame ISP > that was not doing anything about IPv6. 6to4 is full of fail. Inter-as tunnelling is a bad idea. Asymmetric inter-as tunnelling is worse, and asymmetric inter-as tunnelling based on anycast addresses with no hope of tracing blackholes is complete protocol fail. Despite the total failure that it causes the ipv6 world, we couldn't even agree on v6ops at ietf that 6to4 should be recategorised as historical. My facepalm ran over my wtf. But really, 6to4 is a minor player. > All the complaining about 6rd-waste > is just another case of finding excuses because an ISP-deployed-6to4-router > with a longer than /16 announcement into the IPv6 table does a more > efficient job, and would not have required new CPE ... Yes that violates a > one-liner in an RFC, but changing that would have been an easier fix than an > entirely new protocol definition and allocation policy discussion. I'm not understanding the 6rd hate here. Intra-as tunnelling is fine, because the network operator has control over all points along the way. It fixes the problem of having eyeball access devices which don't support v6 properly. Don't hate it - it's useful for some operators, and quite good for deploying v6 over an older infrastructure. > So far neither MSFT or AAPL has been willing to push hard on the app > development community. This is a generic awareness problem in the developer community and it's not microsoft's or apple's business to tell them what to do about it. Deprecating historic APIs is fine, but you cannot force an application developer to do what they don't want to do. Software didn't get ported from ipx and decnet to ipv4 just because the compiler manufacturers nagged the developers about it. IPv6 will become commonplace when there is a compelling reason for it to do so. History tells us that it won't happen before this point. Nick From jra at baylink.com Fri Sep 21 17:00:59 2012 From: jra at baylink.com (Jay Ashworth) Date: Fri, 21 Sep 2012 13:00:59 -0400 (EDT) Subject: the economies of scale of a Worldcon, and how to make this topic relevant to Nanog In-Reply-To: Message-ID: <18055291.25902.1348246859576.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jo Rhett" > Those of us who feel Internet access is mission critical carry LTE > network devices or make other arrangements. Obviously the growth of > smartphones and tablets is starting to change that equation, but at > the moment none of the Worldcons have done a very good job of > providing useful online interaction so there's no actual use for > onsite data related to the conference itself. Obviously I would love > to see this change. And this is pretty much precisely why I'm hammering the nail; there's *lots* of stuff that could -- and properly should -- be technology assisted at the world's largest gathering of science fiction enthusiasts. > Now, if we want to make this topic relevant to Nanog, the operative > question is the feasability of a data provider putting good wireless > gear near these facilities and selling data access to attendees. For a > useful comparison, the 2010 Worldcon in Melbourne had an expensive > wifi service in the building that kept falling over. A cell provider > across the street put up banners advertising cheap data service, and > put people on the sidewalk in from of the convention selling pay as > you go SIM cards with data service. They made brisk business. *THIS* > is where us network operators can provide good networking service to a > large facility, and pretty much kill the expensive data plans operated > by the facility. Assuming you can get close enough -- which won't be geographically practical for ... oh, wait; you're envisioning 3G, not WLAN. Yeah, I suppose that might work... until you consider that I will, personally, be bringing both laptops, my tablet, and my phone, all of which want to talk to the outside world. I would bet that I'm not all *that* unusual in that, at a Worldcon, based on some attendee conversations I've had at Anticipation and the much less well attended NASfic 10, ReConstruction. A lot of this, too, depends on what the concom negotiated with the property about wifi access already. > Instead of building up and tearing down a network for each convention, > put an LTE tower near the facility and sell to every group that uses > the convention center. Can I get 12000 sessions on a single LTE tower? That's my benchmark for the moment, in the absence of real numbers. :-) Alas, this property has already just rebuilt it's wifi, I'm told. Course, the con is in 2015, so they may rebuild *again* by then. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From peter.phaal at gmail.com Fri Sep 21 17:40:40 2012 From: peter.phaal at gmail.com (Peter Phaal) Date: Fri, 21 Sep 2012 10:40:40 -0700 Subject: Real world sflow vs netflow? In-Reply-To: References: <50012E21.4060802@bromirski.net> Message-ID: On Thu, Sep 20, 2012 at 11:21 AM, Mikael Abrahamsson wrote: > Most of the platforms I know of do sampled netflow at 1:100-1:1000 or so, > and then I don't really see the fundamental difference in doing the flow > analysis on the router itself (classic netflow) or doing the same but at the > sFlow collector. There is no difference in the flow records you would obtain in either case. However, moving the flow generation out of the router gives a lot of flexibility. You can now choose how you want to generate flows, rather than depend on the router vendor. You are also guaranteed multi-vendor interoperability since problems associated with differences in how each vendor generates flows are eliminated. For a real world example on the need for flexibility in monitoring, consider the challenge posed by IPv6 migration and virtualization as they greatly increase the amount of layer 2, 3 and 4 tunneled traffic. With an external software based flow generation you can easily upgrade the software to report flows within the tunnels etc. http://blog.sflow.com/2012/05/tunnels.html There are many other things you can do with packet oriented (sFlow) data besides flow generation and analysis that I think are worth being aware of: 1. Route analytics. Packet forwarding decisions are made on a packet by packet basis and sFlow accurately captures the forwarding decision made for each sampled packet (flows are not a good way to report forwarding decisions since you are forced to assume that the all packets in the flow took the same forwarding path, which may not be the case). With packet oriented measurements you can build a route cache and use it to understand traffic forwarding based on AS-path, next hop router etc. 2. Analysis of multi-path forwarding. Detailed visibility into per-packet forwarding lets you diagnose issues with unbalanced LAG groups, ECMP paths, TRILL paths etc. 3. Packet sizes. With packet oriented data you can easily calculate packet size distributions by protocol, DSCP class, egress port etc. 4. DDoS detection and mitigation. Analysis of the sampled packet stream can detect DDoS attacks within seconds and an automatic response can be constructed using packet forwarding and header information to find a signature for the attack, point of ingress etc. You can also use packet analyzers like Wireshark and tcpdump to look at the sFlow packet header records, http://blog.sflow.com/2011/11/wireshark.html 5. Packet counters. MIB-2 interface counters are included in the set of measurements that sFlow exports. Eliminating SNMP polling reduces CPU load on the router (I have seen very high router CPU loads associated with SNMP) and provides much faster updates on link utilizations, packet discard rates etc. I think Nick Hilliard put it well: > Flows are good for measuring some things; raw packet sampling is good for > measuring others. > > Decide on what you're trying to measure, then pick the best tool for the job. However, to choose intelligently requires an understanding of the fundamental differences between packet oriented and flow oriented measurements, particularly as to how those differences relate to the problem you are trying to solve. The two types of measurement are related, but not the same. From dan-nanog at drown.org Fri Sep 21 17:40:52 2012 From: dan-nanog at drown.org (Dan Drown) Date: Fri, 21 Sep 2012 12:40:52 -0500 Subject: Verizon IPv6 LTE In-Reply-To: <2138595174.221799.1348196437402.JavaMail.root@network1.net> References: <2138595174.221799.1348196437402.JavaMail.root@network1.net> Message-ID: <20120921124052.21635qn0vozq15c8@mail.drown.org> Quoting Randy Carpenter : > Safari is definitely preferring IPv4. > > In a happier note, if you tether a device via hotspot on an IOS6 iPad, the > clients get native IPv6. Strangely, they get addresses out of the > same /64 as the iPad's LTE interface. Anyone know how that is > working? I would have thought they would use prefix-delegation, and > there would be a separate routed /64. I assume they're doing the same thing I am. The cell network interface is just a p2p interface, and the whole /64 is routed to the phone/tablet. You can configure the p2p interface address as a /128 and configure the /64 on the wifi interface. My understanding of the 3gpp specs is that the cell provider won't have an address in that /64, so you won't conflict with anything upstream of the phone/tablet. Here's a screenshot of my (wifi-only) tablet getting v6 while tethered through my phone: http://dan.drown.org/android/clat/IMG_20120425_105124.jpg From alh-ietf at tndh.net Fri Sep 21 18:23:26 2012 From: alh-ietf at tndh.net (Tony Hain) Date: Fri, 21 Sep 2012 11:23:26 -0700 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <505C9215.6000108@foobar.org> References: <20120918140712.GF9750@leitl.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> <231483E9-5129-4722-87DE-635FEC3AC422@virtualized.org> <505A440D.5080701@dougbarton.us> <505A48D8.4040800@ttec.com> <36217.1348098710@turing-police.cc.vt.edu> <505A6844.9050703@ttec.com> <505A99D9.6010109@ttec.com> <505AC3F8.9060905@bogus.com> <8270A4D4-5B82-45B6-BD78-FD3586545D6F@gmail.com> <505B23E0.4030906@ttec.com> <00bc01cd9764$3aa38090$afea81b0$@tndh.net> <505B8C7B.7000408@foobar.org> <00e701cd978a$5654c710$02fe5530$@tndh.net> <505C9215.6000108@foobar.org> Message-ID: <017801cd9826$31616ca0$942445e0$@tndh.net> > -----Original Message----- > From: Nick Hilliard [mailto:nick at foobar.org] > Sent: Friday, September 21, 2012 9:13 AM > To: Tony Hain > Cc: nanog at nanog.org > Subject: Re: The Department of Work and Pensions, UK has an entire /8 > > On 21/09/2012 00:47, Tony Hain wrote: > > You are comparing IPv6 to the historical deployment of IPv4. Get with > > the times and realize that CGN/LSN breaks all those wonderful > > location-aware apps people are so into now, not to mention raising the > > cost for operating the network which eventually get charged back to the > user. > > Address translation (already commonplace on many networks) is the > consequence of the lack of a scalable addressing model. Yup, NAT breaks > lots of things. Piles. It sucks. > > > Nanog in general has a problem taking the myopic viewpoint 'the only > > thing that matters is the network'. > > Networking people build and (in some cases) care about networks. It's not > the job of nanog people to fret about software development. > > > The real costs are in app development and support > > It's certainly one of the costs. And application developers have only just > begun to realise that they now need to be aware of the network. > Previously, they could just open up sockets and fling data around. Now they > need to handle protocol failover and multiple connectivity addresses and the > like. Yep, it's an extra cost point - one which has been studiously ignored by > most ipv6 evangelists over the lifetime of ipv6. App developers have never wanted to be aware of the network. As far as they are concerned it is the network managers job to get bits from the endpoint they are on to the endpoint they want to get to. Making them do contortions to figure out that they need to, and then how to, tell the network to do that adds complexity to their development and support. This is not an IPv6 issue, it is historic reality. The only place IPv6 gets involved is that it offers a way back to the transparent end-to-end consistent addressing model. The actual path may have firewalls which prevent communication, but that happens on both versions and has nothing to do with the simplicity of a consistent addressing model. > > > That depends on your time horizon and budget cycles. If your org > > suffers from the short-term focus imposed by Wall Street, > > Most organisations are in this category, not just those beholden to the > whims of Wall Street. > > > If operators would put less effort into blocking transition > > technologies and channel that energy into deploying real IPv6, the > > sorry state wouldn't be there. > > There are never shortages of fingers when failures happen, whether they be > used for wagging or pointing. > > > For all the complaints about 6to4, it was never intended to be the > > mainstay, it was supposed to be the fall back for people that had a > > lame ISP that was not doing anything about IPv6. > > 6to4 is full of fail. Inter-as tunnelling is a bad idea. And something that is easy to fix by simply deploying a 6to4 relay in each AS and announcing the correct IPv6 prefix set to make it symmetric. > Asymmetric inter-as > tunnelling is worse, and asymmetric inter-as tunnelling based on anycast > addresses with no hope of tracing blackholes is complete protocol fail. > > Despite the total failure that it causes the ipv6 world, we couldn't even agree > on v6ops at ietf that 6to4 should be recategorised as historical. My facepalm > ran over my wtf. > > But really, 6to4 is a minor player. > > > All the complaining about 6rd-waste > > is just another case of finding excuses because an > > ISP-deployed-6to4-router with a longer than /16 announcement into the > > IPv6 table does a more efficient job, and would not have required new > > CPE ... Yes that violates a one-liner in an RFC, but changing that > > would have been an easier fix than an entirely new protocol definition and > allocation policy discussion. > > I'm not understanding the 6rd hate here. Intra-as tunnelling is fine, because > the network operator has control over all points along the way. It fixes the > problem of having eyeball access devices which don't support v6 properly. > Don't hate it - it's useful for some operators, and quite good for deploying v6 > over an older infrastructure. There is no 6rd hate here. I personally spent many hours helping Remi tune up the original doc and get in into the IETF process. My point was that we didn't need to go through that entire process and have extended policy discussions about what size prefix each org needs when they are deploying 6rd. At the end of the day, a 6to4 relay at every point that has a 6rd router does exactly the same thing at the tunneling level (except that 6to4 always results in a /48 for the customer). It may have resulted in more prefixes being announced into the IPv6 table, but given the ongoing proliferation of intentional deaggretation for traffic engineering, there may eventually be just as many IPv6 prefixes announced with 6rd. > > > So far neither MSFT or AAPL has been willing to push hard on the app > > development community. > > This is a generic awareness problem in the developer community and it's not > microsoft's or apple's business to tell them what to do about it. > Deprecating historic APIs is fine, but you cannot force an application > developer to do what they don't want to do. Software didn't get ported > from ipx and decnet to ipv4 just because the compiler manufacturers nagged > the developers about it. Those ports happened because there were more endpoints reachable directly without having to deal with network layer gateways and translators. IPv4 lost that with RFC 1597, and with the layering of the problem that is ahead, the app community will be driven away. MSFT & AAPL can't make the app developers change, but they can offer a path to make their life easier. If one does so and word starts to spread that "it is easier to build and support location aware apps on platform Z", expect the other to announce the same tool set to counter that. In some ways I am surprised that GOOG hasn't already started something like that for the 4G android devices, but maybe it just hasn't gone public yet ... > > IPv6 will become commonplace when there is a compelling reason for it to do > so. History tells us that it won't happen before this point. And network managers that are squeezing the balloon to over optimize their part of the system without concern for the rest will provide the compelling event. Those that are doing so intentionally, while providing the long term path in parallel, can be described as weaning their customers off the legacy. Those that are doing so inadvertently, because they don't care about anything but their tiny part of the overall system, will lose customers to the provider offering the long term path. Tony > > Nick From cscora at apnic.net Fri Sep 21 18:47:17 2012 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 22 Sep 2012 04:47:17 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201209211847.q8LIlHh6005983@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, TRNOG, 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 22 Sep, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 427480 Prefixes after maximum aggregation: 178522 Deaggregation factor: 2.39 Unique aggregates announced to Internet: 208854 Total ASes present in the Internet Routing Table: 42150 Prefixes per ASN: 10.14 Origin-only ASes present in the Internet Routing Table: 33623 Origin ASes announcing only one prefix: 15762 Transit ASes present in the Internet Routing Table: 5619 Transit-only ASes present in the Internet Routing Table: 136 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 32 Max AS path prepend of ASN ( 48687) 24 Prefixes from unregistered ASNs in the Routing Table: 736 Unregistered ASNs in the Routing Table: 268 Number of 32-bit ASNs allocated by the RIRs: 3307 Number of 32-bit ASNs visible in the Routing Table: 2908 Prefixes from 32-bit ASNs in the Routing Table: 7789 Special use prefixes present in the Routing Table: 9 Prefixes being announced from unallocated address space: 170 Number of addresses announced to Internet: 2597807124 Equivalent to 154 /8s, 215 /16s and 100 /24s Percentage of available address space announced: 70.2 Percentage of allocated address space announced: 70.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 93.7 Total number of prefixes smaller than registry allocations: 150657 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 102817 Total APNIC prefixes after maximum aggregation: 32533 APNIC Deaggregation factor: 3.16 Prefixes being announced from the APNIC address blocks: 103474 Unique aggregates announced from the APNIC address blocks: 42726 APNIC Region origin ASes present in the Internet Routing Table: 4760 APNIC Prefixes per ASN: 21.74 APNIC Region origin ASes announcing only one prefix: 1238 APNIC Region transit ASes present in the Internet Routing Table: 768 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 316 Number of APNIC addresses announced to Internet: 708467008 Equivalent to 42 /8s, 58 /16s and 89 /24s Percentage of available APNIC address space announced: 82.8 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 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, 150/8, 153/8, 163/8, 171/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: 154454 Total ARIN prefixes after maximum aggregation: 78148 ARIN Deaggregation factor: 1.98 Prefixes being announced from the ARIN address blocks: 155396 Unique aggregates announced from the ARIN address blocks: 69131 ARIN Region origin ASes present in the Internet Routing Table: 15249 ARIN Prefixes per ASN: 10.19 ARIN Region origin ASes announcing only one prefix: 5758 ARIN Region transit ASes present in the Internet Routing Table: 1599 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 17 Number of ARIN addresses announced to Internet: 1084628608 Equivalent to 64 /8s, 166 /16s and 30 /24s Percentage of available ARIN address space announced: 57.4 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, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/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: 108700 Total RIPE prefixes after maximum aggregation: 57005 RIPE Deaggregation factor: 1.91 Prefixes being announced from the RIPE address blocks: 111222 Unique aggregates announced from the RIPE address blocks: 71031 RIPE Region origin ASes present in the Internet Routing Table: 16856 RIPE Prefixes per ASN: 6.60 RIPE Region origin ASes announcing only one prefix: 8154 RIPE Region transit ASes present in the Internet Routing Table: 2720 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1889 Number of RIPE addresses announced to Internet: 646098660 Equivalent to 38 /8s, 130 /16s and 174 /24s Percentage of available RIPE address space announced: 93.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 59392-61439, 196608-199679 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, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 43822 Total LACNIC prefixes after maximum aggregation: 8560 LACNIC Deaggregation factor: 5.12 Prefixes being announced from the LACNIC address blocks: 46964 Unique aggregates announced from the LACNIC address blocks: 22336 LACNIC Region origin ASes present in the Internet Routing Table: 1646 LACNIC Prefixes per ASN: 28.53 LACNIC Region origin ASes announcing only one prefix: 440 LACNIC Region transit ASes present in the Internet Routing Table: 319 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 680 Number of LACNIC addresses announced to Internet: 116497520 Equivalent to 6 /8s, 241 /16s and 156 /24s Percentage of available LACNIC address space announced: 69.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, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 9773 Total AfriNIC prefixes after maximum aggregation: 2218 AfriNIC Deaggregation factor: 4.41 Prefixes being announced from the AfriNIC address blocks: 10254 Unique aggregates announced from the AfriNIC address blocks: 3489 AfriNIC Region origin ASes present in the Internet Routing Table: 561 AfriNIC Prefixes per ASN: 18.28 AfriNIC Region origin ASes announcing only one prefix: 172 AfriNIC Region transit ASes present in the Internet Routing Table: 128 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 41815296 Equivalent to 2 /8s, 126 /16s and 13 /24s Percentage of available AfriNIC address space announced: 41.5 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2977 11429 901 Korea Telecom (KIX) 17974 2356 702 54 PT TELEKOMUNIKASI INDONESIA 7545 1760 301 87 TPG Internet Pty Ltd 4755 1620 387 162 TATA Communications formerly 9829 1335 1106 41 BSNL National Internet Backbo 9583 1180 87 513 Sify Limited 7552 1136 1062 11 Vietel Corporation 4808 1119 2044 317 CNCGROUP IP network: China169 24560 1041 386 160 Bharti Airtel Ltd., Telemedia 18101 1015 135 169 Reliance Infocom Ltd Internet 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 3311 3733 186 bellsouth.net, inc. 7029 3164 990 161 Windstream Communications Inc 18566 2084 382 180 Covad Communications 1785 1916 678 128 PaeTec Communications, Inc. 22773 1884 2931 129 Cox Communications, Inc. 20115 1661 1580 614 Charter Communications 4323 1575 1153 386 Time Warner Telecom 30036 1379 273 739 Mediacom Communications Corp 7018 1249 10318 832 AT&T WorldNet Services 7011 1204 329 698 Citizens Utilities 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 8402 1594 544 16 Corbina telecom 2118 1399 97 14 EUnet/RELCOM Autonomous Syste 15557 1229 2247 55 LDCOM NETWORKS 12479 839 774 77 Uni2 Autonomous System 34984 774 206 181 BILISIM TELEKOM 6830 724 2313 448 UPC Distribution Services 20940 709 225 544 Akamai Technologies European 31148 709 37 9 FreeNet ISP 13188 691 92 162 Educational Network 58113 631 70 366 LIR DATACENTER TELECOM SRL 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 2164 370 219 TVCABLE BOGOTA 28573 2137 1249 55 NET Servicos de Comunicao S.A 8151 1588 3045 345 UniNet S.A. de C.V. 7303 1564 1034 200 Telecom Argentina Stet-France 6503 1536 435 68 AVANTEL, S.A. 27947 725 74 94 Telconet S.A 6458 681 81 15 GUATEL 3816 623 258 114 Empresa Nacional de Telecomun 11172 595 85 69 Servicios Alestra S.A de C.V 14420 587 86 101 CORPORACION NACIONAL DE TELEC 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 882 275 36 LINKdotNET AS number 8452 796 958 13 TEDATA 36998 772 48 3 MOBITEL 6713 517 650 19 Itissalat Al-MAGHRIB 24835 269 80 8 RAYA Telecom - Egypt 3741 264 904 224 The Internet Solution 12258 194 28 66 Vodacom Internet Company 15706 192 32 6 Sudatel Internet Exchange Aut 29975 191 667 21 Vodacom 33776 179 13 11 Starcomms Nigeria Limited 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 3311 3733 186 bellsouth.net, inc. 7029 3164 990 161 Windstream Communications Inc 4766 2977 11429 901 Korea Telecom (KIX) 17974 2356 702 54 PT TELEKOMUNIKASI INDONESIA 10620 2164 370 219 TVCABLE BOGOTA 28573 2137 1249 55 NET Servicos de Comunicao S.A 18566 2084 382 180 Covad Communications 1785 1916 678 128 PaeTec Communications, Inc. 22773 1884 2931 129 Cox Communications, Inc. 7545 1760 301 87 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7029 3164 3003 Windstream Communications Inc 17974 2356 2302 PT TELEKOMUNIKASI INDONESIA 28573 2137 2082 NET Servicos de Comunicao S.A 4766 2977 2076 Korea Telecom (KIX) 10620 2164 1945 TVCABLE BOGOTA 18566 2084 1904 Covad Communications 1785 1916 1788 PaeTec Communications, Inc. 22773 1884 1755 Cox Communications, Inc. 7545 1760 1673 TPG Internet Pty Ltd 8402 1594 1578 Corbina telecom Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 59505 UNALLOCATED 5.2.65.0/24 50673 Serverius AS 59505 UNALLOCATED 5.2.66.0/24 50673 Serverius AS 59414 UNALLOCATED 5.102.144.0/21 15576 Nextra backbone in D 59395 UNALLOCATED 5.133.16.0/21 12658 Dexterity Networks L 59407 UNALLOCATED 5.134.16.0/21 51167 Giga-Hosting GmbH 59521 UNALLOCATED 5.134.192.0/21 29518 Labs2 59441 UNALLOCATED 5.144.128.0/21 50810 Mobin Net Communicat 59581 UNALLOCATED 5.149.8.0/21 25577 C4L main AS 59457 UNALLOCATED 5.149.64.0/24 35567 DASTO semtel d.o.o. 59457 UNALLOCATED 5.149.64.0/19 35567 DASTO semtel d.o.o. Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.24.0/21 41794 Altline LLC 128.0.64.0/22 49466 Declic Telecom SAS 128.0.68.0/22 49466 Declic Telecom SAS 128.0.80.0/20 52041 Timer LTD 128.0.160.0/21 23456 32-bit ASN transition 128.0.168.0/21 15772 W-NET Kiev 128.0.170.0/24 24685 ISP Elencom autonomous system 128.0.176.0/20 30764 PODA s.r.o. 128.0.192.0/21 51483 SaSG GmbH & Co. KG Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.0.0/22 45464 Room 201, TGU Bldg 14.192.4.0/22 45464 Room 201, TGU Bldg 14.192.8.0/22 45464 Room 201, TGU Bldg 14.192.12.0/22 45464 Room 201, TGU Bldg 14.192.16.0/22 45464 Room 201, TGU Bldg 14.192.20.0/22 45464 Room 201, TGU Bldg 14.192.24.0/22 45464 Room 201, TGU Bldg 14.192.28.0/22 45464 Room 201, TGU Bldg 27.112.114.0/24 23884 Proimage Engineering and Comm 41.220.80.0/24 38925 DAC AS Germany 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:18 /9:14 /10:29 /11:84 /12:237 /13:476 /14:841 /15:1548 /16:12409 /17:6470 /18:10855 /19:21100 /20:30284 /21:32205 /22:42557 /23:39934 /24:224158 /25:1390 /26:1668 /27:921 /28:176 /29:64 /30:18 /31:0 /32:24 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 2646 3164 Windstream Communications Inc 18566 2034 2084 Covad Communications 6389 1841 3311 bellsouth.net, inc. 30036 1313 1379 Mediacom Communications Corp 8402 1308 1594 Corbina telecom 22773 1227 1884 Cox Communications, Inc. 15557 1173 1229 LDCOM NETWORKS 11492 1161 1198 Cable One 6503 1054 1536 AVANTEL, S.A. 1785 1015 1916 PaeTec Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:622 2:613 3:1 4:13 5:507 6:3 8:457 12:1987 13:1 14:665 15:11 16:3 17:6 20:27 23:206 24:1790 27:1334 31:1013 32:54 33:2 34:2 36:7 37:791 38:832 39:2 40:133 41:3023 42:158 44:3 46:1587 47:2 49:481 50:596 52:13 54:20 55:9 56:1 57:30 58:990 59:539 60:237 61:1288 62:979 63:1996 64:4268 65:2240 66:4511 67:2052 68:1167 69:3233 70:982 71:509 72:1872 74:2602 75:485 76:314 77:967 78:956 79:493 80:1268 81:964 82:633 83:528 84:625 85:1152 86:809 87:918 88:363 89:1792 90:304 91:5212 92:576 93:1540 94:1617 95:1118 96:418 97:320 98:979 99:39 100:23 101:262 103:1548 105:512 106:118 107:198 108:456 109:1950 110:802 111:1001 112:449 113:699 114:633 115:879 116:893 117:728 118:965 119:1261 120:307 121:689 122:1642 123:1169 124:1332 125:1275 128:561 129:184 130:282 131:632 132:310 133:22 134:250 135:61 136:217 137:239 138:338 139:171 140:497 141:281 142:485 143:377 144:489 145:81 146:518 147:261 148:761 149:323 150:155 151:172 152:449 153:178 154:20 155:420 156:226 157:372 158:261 159:654 160:342 161:413 162:364 163:191 164:693 165:421 166:528 167:552 168:965 169:125 170:906 171:161 172:7 173:1693 174:608 175:447 176:794 177:1227 178:1605 180:1362 181:136 182:1053 183:296 184:604 185:2 186:2184 187:1242 188:1674 189:1583 190:6040 192:6034 193:5717 194:4564 195:3475 196:1220 197:220 198:3806 199:5020 200:6002 201:1973 202:8721 203:8730 204:4426 205:2545 206:2761 207:2875 208:4071 209:3668 210:2844 211:1527 212:1997 213:1829 214:879 215:87 216:5123 217:1538 218:567 219:315 220:1246 221:536 222:336 223:390 End of report From mark at amplex.net Fri Sep 21 19:42:20 2012 From: mark at amplex.net (Mark Radabaugh) Date: Fri, 21 Sep 2012 15:42:20 -0400 Subject: Throw me a IPv6 bone (sort of was IPv6 ignorance) In-Reply-To: <505C6E60.3000806@unfix.org> References: <505C6C2D.7030204@amplex.net> <505C6E60.3000806@unfix.org> Message-ID: <505CC31C.3040709@amplex.net> On 9/21/12 9:40 AM, Jeroen Massar wrote: > On 2012-09-21 15:31 , Mark Radabaugh wrote: >> The part of IPv6 that I am unclear on and have not found much >> documentation on is how to run IPv6 only to end users. Anyone care to >> point me in the right direction? >> >> Can we assign IPv6 only to end users? What software/equipment do we >> need in place as a ISP to ensure these customers can reach IPv4 only hosts? >> >> The Interwebs are full of advice on setting up IPv6 tunnels for your >> house (nice but...). There is lots of really old documentation out >> there for IPv6 mechanisms that are depreciated or didn't fly. >> >> What is current best practice? > The IETF BCP is to deploy Dual Stack, thus both IPv4 and IPv6 at the > same time. > > When that is not possible, as you ran out of IPv4 addresses, you should > look at Dual Stack Lite (DS Lite) eg as supplied by ISC's AFTR and other > such implementations. > > Depending on your business model you can of course also stick everybody > behind a huge NAT or require them to use HTTP proxies to get to the > Internet as most people define it... > > > Do note that if you are asking any of these questions today you are > years late in reading up and you missed your chance to be prepared for > this in all kinds of ways. > > Greets, > Jeroen > We can already do dual stack - that's not really a problem. I was really rather hoping to avoid the giant NAT box. I'll take a look at DS Lite and or NAT64/DNS64 and see if that makes any sense. Dual stack isn't all that hard to deploy in the enterprise, perhaps even IPv6 only with NAT for backward compatibility. Running dual stack to residential consumers still has huge issues with CPE. It's not an environment where we have control over the router the customer picks up at Walmart. There is really very little point in spending a lot of resources on something the consumer can't currently use. I don't think saying we missed the boat really applies - and the consumer CPE ship is sinking at the dock. -- Mark Radabaugh Amplex mark at amplex.net 419.837.5015 From mark at amplex.net Fri Sep 21 19:48:06 2012 From: mark at amplex.net (Mark Radabaugh) Date: Fri, 21 Sep 2012 15:48:06 -0400 Subject: http://www.isc.org/software/aftr Message-ID: <505CC476.2020008@amplex.net> -- Mark Radabaugh Amplex mark at amplex.net 419.837.5015 From morrowc.lists at gmail.com Fri Sep 21 19:52:32 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 21 Sep 2012 15:52:32 -0400 Subject: http://www.isc.org/software/aftr In-Reply-To: <505CC476.2020008@amplex.net> References: <505CC476.2020008@amplex.net> Message-ID: On Fri, Sep 21, 2012 at 3:48 PM, Mark Radabaugh wrote: > I see your url and raise you a youtube video ... http://youtu.be/bqi-_d4C5xg From seth.mos at dds.nl Fri Sep 21 19:55:18 2012 From: seth.mos at dds.nl (Seth Mos) Date: Fri, 21 Sep 2012 21:55:18 +0200 Subject: Throw me a IPv6 bone (sort of was IPv6 ignorance) In-Reply-To: <505CC31C.3040709@amplex.net> References: <505C6C2D.7030204@amplex.net> <505C6E60.3000806@unfix.org> <505CC31C.3040709@amplex.net> Message-ID: <505CC626.6080805@dds.nl> Op 21-9-2012 21:42, Mark Radabaugh schreef: > > Running dual stack to residential consumers still has huge issues with > CPE. It's not an environment where we have control over the router > the customer picks up at Walmart. There is really very little point > in spending a lot of resources on something the consumer can't > currently use. I don't think saying we missed the boat really applies > - and the consumer CPE ship is sinking at the dock. > Enable dual stack per default, the old routers ignore it anyhow. The new ones that do support it, and really, Linksys and D-Link as well as Netgear do support it now will use it and should just work. I recommend DHCP-PD, it seems to work well with relatively low overhead. AVM seems to know just how to make these relatively cheap all-in-ones with a great feature set and reasonable quality. There is a lot of room for improvement, there always have been. It's not like the original Linksys WRT54G was really _that_ good, was it? The other good news is that there is a new Wifi standard! You'll see a new surge of people swapping out 30$ routers because they are convinced that the new 30$ router will be a lot better then the previous one. Maybe it is. I know it's a chicken and egg problem, and shoving it out further means you just decided for the ISP that you need a far beefier CGN box in the future. I am not totally convinced that was your long term plan. Most ISPs in asia that are now pouring significant monetary resources into a CGN box that might be almost pointless in 5 years is not the investment they were looking for. From jrhett at netconsonance.com Fri Sep 21 20:08:22 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Fri, 21 Sep 2012 13:08:22 -0700 Subject: the economies of scale of a Worldcon, and how to make this topic relevant to Nanog In-Reply-To: <18055291.25902.1348246859576.JavaMail.root@benjamin.baylink.com> References: <18055291.25902.1348246859576.JavaMail.root@benjamin.baylink.com> Message-ID: On Sep 21, 2012, at 10:00 AM, Jay Ashworth wrote: > And this is pretty much precisely why I'm hammering the nail; there's > *lots* of stuff that could -- and properly should -- be technology > assisted at the world's largest gathering of science fiction enthusiasts. No point in building fast access to nothing (related to the con) ;-) I'm not saying that's right, but it is what is. And don't forget that right now hard SF is a pretty mean minority. The vast majority of sci-fi fans are into steampunk and other alt history these days. (and don't get me started about that) iPhones are not generally strapped to their victorian outfits. > Assuming you can get close enough -- which won't be geographically > practical for ... oh, wait; you're envisioning 3G, not WLAN. Yeah, > I suppose that might work... until you consider that I will, personally, > be bringing both laptops, my tablet, and my phone, all of which want All of which can use LTE either natively or with a dongle. > to talk to the outside world. I would bet that I'm not all *that* > unusual in that, at a Worldcon, based on some attendee conversations > I've had at Anticipation and the much less well attended NASfic 10, > ReConstruction. You aren't unusual, but you aren't the average by a long shot. > A lot of this, too, depends on what the concom negotiated with the > property about wifi access already. And this is where you're going to hit some very hard walls. One of which I forgot to mention. Many of the hotels (I believe all Hilton properties at this time) have sold the facilities space for their wifi network to another company. They CAN'T negotiate it with you, because they don't own it any more. And most of these wifi networks have stealth killers enabled, so that they spoof any other wifi zone they see and send back reject messages to the clients. So you can't run them side by side. Try having a conversation with the hotel rep in charge of selling convention space about these kind of technical bits about wifi networks sometime. If you don't mind tearing your hair out at the time. Or tearing it out later, after you've been assured that the hotel will "make it all work" and then find that none of this equipment is within their control. (they don't care, you're already there and can't go anywhere else) Sorry I'm being so negative on this topic. Got more than a few burnt fingers on this one :) > Can I get 12000 sessions on a single LTE tower? Yes. Can you get 12000 sessions through any single POE gateway? ;-) -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. From stephen at sprunk.org Fri Sep 21 20:21:01 2012 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 21 Sep 2012 15:21:01 -0500 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: References: <20120918140712.GF9750@leitl.org> <50588250.6070802@unfix.org> <1A05B0E5-0269-4C14-9B30-5E424B990237@delong.com> <20120919065959.AFD332568362@drugs.dv.isc.org> <50598664.9020302@gmail.com> <505BB11A.8050706@sprunk.org> Message-ID: <505CCC2D.3000700@sprunk.org> On 20-Sep-12 20:51, George Herbert wrote: > On Thu, Sep 20, 2012 at 5:13 PM, Stephen Sprunk > wrote: >> Actually, they're not any different, aside from scale. Some >> private internets have hundreds to thousands of participants, and >> they often use obscure protocols on obscure systems that were >> killed off by their vendors (if the vendors even exist anymore) a >> decade or more ago, and no source code or upgrade path is >> available. >> >> The "enterprise" networking world is just as ugly as, if not >> uglier than, the consumer one. > > I haven't worked much on the commercial private internets, but I did > work for someone who connected on the back end into numerous telco > cellphone IP data networks. > > For all of those who argue that these applications should use 1918 > space, I give you those networks, where at one point I counted > literally 8 different 10.200.x/16 nets I could talk to at different > partners (scarily enough, 2 of those were "the same company"...). > And hundreds and hundreds of other space conflicts. That's all? I consulted for one customer that had several (six? eight?) instances of 10/8 within their own enterprise, simply because they needed that many addresses. That doesn't include the dozens of legacy /16s they used in their data centers--plus the hundreds of legacy /24s they used in double-sided NAT configurations between them and various business partners, COINs, etc. Yet all that was exposed to the consumer internet was a couple of /24s for their web servers, email servers and VPN concentrators. > Yes, you can NAT all of that, but if you get network issues where > you need to know the phone end address and do end to end debugging > on stuff, there are no curse words strong enough in the English > language. That's the truth. To get from a credit card terminal to the bank involved _at least_ three layers of NAT on our side, and I don't know how many layers of NAT there were in total on the bank's side, but it was at least two. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2312 bytes Desc: S/MIME Cryptographic Signature URL: From Valdis.Kletnieks at vt.edu Fri Sep 21 20:53:36 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 21 Sep 2012 16:53:36 -0400 Subject: Throw me a IPv6 bone (sort of was IPv6 ignorance) In-Reply-To: Your message of "Fri, 21 Sep 2012 15:42:20 -0400." <505CC31C.3040709@amplex.net> References: <505C6C2D.7030204@amplex.net> <505C6E60.3000806@unfix.org> <505CC31C.3040709@amplex.net> Message-ID: <24322.1348260816@turing-police.cc.vt.edu> On Fri, 21 Sep 2012 15:42:20 -0400, Mark Radabaugh said: > Running dual stack to residential consumers still has huge issues with > CPE. It's not an environment where we have control over the router the > customer picks up at Walmart. There is really very little point in > spending a lot of resources on something the consumer can't currently > use. You *do* realize that the reason my site runs like 60% IPv6 traffic *now* is because we spend the resources 5 and 10 years ago getting ready for when Microsoft and Apple shipped stuff that worked for the end user, right? Of course, if you want to wait to get *started* on the deployment curve until everybody's replaced their stuff, that's fine by me. But I'd double-check if you have any competitors that have an earlier schedule. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From nick at foobar.org Fri Sep 21 21:33:21 2012 From: nick at foobar.org (Nick Hilliard) Date: Fri, 21 Sep 2012 22:33:21 +0100 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: <017801cd9826$31616ca0$942445e0$@tndh.net> References: <20120918140712.GF9750@leitl.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> <231483E9-5129-4722-87DE-635FEC3AC422@virtualized.org> <505A440D.5080701@dougbarton.us> <505A48D8.4040800@ttec.com> <36217.1348098710@turing-police.cc.vt.edu> <505A6844.9050703@ttec.com> <505A99D9.6010109@ttec.com> <505AC3F8.9060905@bogus.com> <8270A4D4-5B82-45B6-BD78-FD3586545D6F@gmail.com> <505B23E0.4030906@ttec.com> <00bc01cd9764$3aa38090$afea81b0$@tndh.net> <505B8C7B.7000408@foobar.org> <00e701cd978a$5654c710$02fe5530$@tndh.net> <505C9215.6000108@foobar.org> <017801cd9826$31616ca0$942445e0$@tndh.net> Message-ID: <505CDD21.4080103@foobar.org> On 21/09/2012 19:23, Tony Hain wrote: > App developers have never wanted to be aware of the network. By not sitting down and thinking about the user experience of a dual-stacked network, we have now forced them to be aware of the network and that's not a good thing because they are as clued out about networking as most network operators are about programming. If we had designed a portable and consistent happy-eyeballs API 10 years ago, it would be widely available for use now. But we didn't do that because we were thinking about the network rather than the users. So now, each dual stack developer is going to have to sit down and reimplement happy eyeballs for themselves. What a waste. > As far as they > are concerned it is the network managers job to get bits from the endpoint > they are on to the endpoint they want to get to. Making them do contortions > to figure out that they need to, and then how to, tell the network to do > that adds complexity to their development and support. This is not an IPv6 > issue, it is historic reality. No, it's a current reality for early venturers into ipv6. It may become a future reality in the mainstream if ipv6 takes off in a way that I can't foresee at the moment. One day in the future, maybe, it will become less of an issue if people go back to a single-stack endpoint system. > And something that is easy to fix by simply deploying a 6to4 relay in each > AS and announcing the correct IPv6 prefix set to make it symmetric. In theory yes. In practice no. > event. Those that are doing so intentionally, while providing the long term > path in parallel, can be described as weaning their customers off the > legacy. Those that are doing so inadvertently, because they don't care about > anything but their tiny part of the overall system, will lose customers to > the provider offering the long term path. So long as the cost of that is less than the cost of deploying ipv6 and pushing people in that direction, it's a good business plan in the short term. Which is what most people care about. I'm with you that it's a hopeless long term business plan, but that's not the world we live in. Nick From cidr-report at potaroo.net Fri Sep 21 22:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 21 Sep 2012 22:00:00 GMT Subject: The Cidr Report Message-ID: <201209212200.q8LM00W0066401@wattle.apnic.net> This report has been generated at Fri Sep 21 21:13:04 2012 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 14-09-12 429020 246442 15-09-12 429325 246777 16-09-12 429508 246698 17-09-12 429346 246899 18-09-12 429763 247243 19-09-12 430009 247144 20-09-12 429920 247029 21-09-12 430248 247406 AS Summary 42264 Number of ASes in routing system 17619 Number of ASes announcing only one prefix 3311 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 113672416 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'). --- 21Sep12 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 430328 247263 183065 42.5% All ASes AS6389 3311 191 3120 94.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2136 57 2079 97.3% NET Servicos de Comunicao S.A. AS4766 2982 941 2041 68.4% KIXS-AS-KR Korea Telecom AS22773 1884 141 1743 92.5% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS17974 2356 616 1740 73.9% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS7029 3164 1485 1679 53.1% WINDSTREAM - Windstream Communications Inc AS18566 2084 423 1661 79.7% COVAD - Covad Communications Co. AS2118 1399 14 1385 99.0% RELCOM-AS OOO "NPO Relcom" AS10620 2164 801 1363 63.0% Telmex Colombia S.A. AS4323 1579 392 1187 75.2% TWTC - tw telecom holdings, inc. AS7303 1559 447 1112 71.3% Telecom Argentina S.A. AS1785 1919 828 1091 56.9% AS-PAETEC-NET - PaeTec Communications, Inc. AS4755 1620 547 1073 66.2% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7552 1136 205 931 82.0% VIETEL-AS-AP Vietel Corporation AS8151 1594 704 890 55.8% Uninet S.A. de C.V. AS18101 1015 172 843 83.1% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1119 350 769 68.7% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS13977 859 120 739 86.0% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS15557 1229 563 666 54.2% LDCOMNET Societe Francaise du Radiotelephone S.A AS6458 680 42 638 93.8% Telgua AS855 685 52 633 92.4% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS3356 1107 478 629 56.8% LEVEL3 Level 3 Communications AS17676 711 86 625 87.9% GIGAINFRA Softbank BB Corp. AS36998 772 148 624 80.8% SDN-MOBITEL AS22561 1039 435 604 58.1% DIGITAL-TELEPORT - Digital Teleport Inc. AS19262 1002 404 598 59.7% VZGNI-TRANSIT - Verizon Online LLC AS24560 1041 447 594 57.1% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS3549 1009 437 572 56.7% GBLX Global Crossing Ltd. AS30036 1379 819 560 40.6% MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp AS4804 643 97 546 84.9% MPX-AS Microplex PTY LTD Total 45177 12442 32735 72.5% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 14.192.0.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.4.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.8.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.12.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.16.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.20.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.24.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.28.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 41.220.80.0/24 AS38925 DAC-AS G.I.T. TELECOM LIMITED 41.220.81.0/24 AS38925 DAC-AS G.I.T. TELECOM LIMITED 41.220.94.0/23 AS42235 IDC-AS Intra Data Communication 41.222.80.0/21 AS37110 moztel-as 41.223.108.0/22 AS36966 EDL_AS Edgenet AS 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.66.32.0/20 AS18864 64.187.208.0/24 AS174 COGENT Cogent/PSI 64.187.209.0/24 AS23005 SWITCH-COMMUNICATIONS - SWITCH Communications Group LLC 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 70.34.112.0/20 AS27589 MOJOHOST - MOJOHOST 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.115.124.0/23 AS46540 74.115.126.0/24 AS11260 EASTLINK-HSI - EastLink 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 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 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 172.120.16.0/21 AS19891 BML-AS Bill Me Later, Inc 172.254.254.0/24 AS26274 192.0.0.0/24 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 198.18.0.0/15 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 198.51.100.0/24 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.6.49.0/24 AS23148 TERREMARK Terremark 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 200.58.248.0/21 AS27849 200.75.184.0/24 AS14754 Telgua 200.75.185.0/24 AS14754 Telgua 200.75.186.0/24 AS14754 Telgua 200.75.187.0/24 AS14754 Telgua 200.75.188.0/24 AS14754 Telgua 200.75.189.0/24 AS14754 Telgua 200.75.190.0/24 AS14754 Telgua 200.75.191.0/24 AS14754 Telgua 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 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.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.151.40.0/21 AS24453 202.151.40.0/24 AS24453 202.151.41.0/24 AS24453 202.151.42.0/24 AS24453 202.151.43.0/24 AS24453 202.151.44.0/24 AS24453 202.151.45.0/24 AS24453 202.151.46.0/24 AS24453 202.151.47.0/24 AS24453 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.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.0.113.0/24 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 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.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.142.219.0/24 AS45149 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.14.0.0/21 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 204.14.0.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 204.14.2.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 204.14.3.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 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.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.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.93.144.0/21 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 208.93.151.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.21.160.0/20 AS27876 American Data Networks 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.194.160.0/20 AS27876 American Data Networks 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org 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 Sep 21 22:00:02 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 21 Sep 2012 22:00:02 GMT Subject: BGP Update Report Message-ID: <201209212200.q8LM02FZ066422@wattle.apnic.net> BGP Update Report Interval: 13-Sep-12 -to- 20-Sep-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS8402 50791 1.7% 24.9 -- CORBINA-AS OJSC "Vimpelcom" 2 - AS9829 36316 1.2% 27.2 -- BSNL-NIB National Internet Backbone 3 - AS22561 29726 1.0% 27.8 -- DIGITAL-TELEPORT - Digital Teleport Inc. 4 - AS24560 28930 1.0% 27.8 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 5 - AS27947 28720 0.9% 37.7 -- Telconet S.A 6 - AS10620 22031 0.7% 10.2 -- Telmex Colombia S.A. 7 - AS13118 20062 0.7% 418.0 -- ASN-YARTELECOM OJSC Rostelecom 8 - AS7552 18689 0.6% 16.3 -- VIETEL-AS-AP Vietel Corporation 9 - AS6389 17986 0.6% 5.4 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 10 - AS27738 15727 0.5% 28.2 -- Ecuadortelecom S.A. 11 - AS28573 15693 0.5% 7.2 -- NET Servicos de Comunicao S.A. 12 - AS17974 15024 0.5% 6.4 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 13 - AS7029 14898 0.5% 4.6 -- WINDSTREAM - Windstream Communications Inc 14 - AS2118 12565 0.4% 9.0 -- RELCOM-AS OOO "NPO Relcom" 15 - AS45595 12535 0.4% 25.0 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited 16 - AS7545 12508 0.4% 7.1 -- TPG-INTERNET-AP TPG Internet Pty Ltd 17 - AS21599 12065 0.4% 67.8 -- NETDIRECT S.A. 18 - AS25620 11640 0.4% 55.4 -- COTAS LTDA. 19 - AS8151 11619 0.4% 7.3 -- Uninet S.A. de C.V. 20 - AS1637 11601 0.4% 59.5 -- DNIC-AS-01637 - Headquarters, USAISC TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS44410 10148 0.3% 3382.7 -- ENTEKHAB-AS ENTEKHAB INDUSTRIAL GROUP 2 - AS15053 3188 0.1% 3188.0 -- ROLL-GLOBAL-LLC - Roll Global LLC 3 - AS14680 7488 0.2% 2496.0 -- REALE-6 - Auction.com 4 - AS41733 7040 0.2% 1005.7 -- ZTELECOM-AS JSC "Z-Telecom" 5 - AS48696 962 0.0% 962.0 -- TEMP-AS TEMP Ltd. 6 - AS29126 792 0.0% 792.0 -- DATIQ-AS Datiq B.V. 7 - AS38142 10593 0.3% 662.1 -- UNAIR-AS-ID Universitas Airlangga 8 - AS38857 1117 0.0% 558.5 -- ESOFT-TRANSIT-AS-AP e.Soft Technologies Ltd. 9 - AS57201 550 0.0% 550.0 -- EDF-AS Estonian Defence Forces 10 - AS25911 502 0.0% 502.0 -- TALISMAN-CH3 - TALISMAN ENERGY INC. 11 - AS29398 449 0.0% 449.0 -- PETROBALTIC "Petrobaltic" S.A. 12 - AS53205 5338 0.2% 444.8 -- 13 - AS23861 4865 0.2% 442.3 -- ETRADING-AS-ID-AP PT eTrading Securities 14 - AS9223 426 0.0% 426.0 -- INDUS-TOWERS Spreaded across 35 locations in india 15 - AS13118 20062 0.7% 418.0 -- ASN-YARTELECOM OJSC Rostelecom 16 - AS32529 405 0.0% 405.0 -- CGI-FEDERAL-ASN-1 - CGI Federal 17 - AS21023 405 0.0% 405.0 -- UPB-AS Joint Stock Company Ural Industrial Bank 18 - AS2 385 0.0% 637.0 -- BIORAD-AP 1000 Alfred Nobel Drive US 19 - AS52118 373 0.0% 373.0 -- GU-YAO-AS GU YaO Yaroslavl Centre for Telecommunications and Information Technologies in Education 20 - AS36948 737 0.0% 368.5 -- KENIC TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/19 19841 0.6% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 184.159.130.0/23 12486 0.3% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. 3 - 184.157.224.0/19 10562 0.3% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. 4 - 200.46.0.0/19 10207 0.3% AS21599 -- NETDIRECT S.A. 5 - 202.41.70.0/24 7856 0.2% AS2697 -- ERX-ERNET-AS Education and Research Network 6 - 122.161.0.0/16 7475 0.2% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 7 - 5.16.0.0/16 7010 0.2% AS41733 -- ZTELECOM-AS JSC "Z-Telecom" 8 - 190.60.31.0/24 6676 0.2% AS18747 -- IFX-NW - IFX Communication Ventures, Inc. 9 - 202.56.215.0/24 6509 0.2% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 10 - 182.64.0.0/16 6419 0.2% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 11 - 12.139.133.0/24 6028 0.2% AS14680 -- REALE-6 - Auction.com 12 - 166.137.184.0/22 5566 0.2% AS20057 -- AT&T Wireless Service 13 - 78.111.6.0/24 5539 0.1% AS44410 -- ENTEKHAB-AS ENTEKHAB INDUSTRIAL GROUP AS48159 -- TIC-AS Telecommunication Infrastructure Company 14 - 49.248.72.0/21 5083 0.1% AS17762 -- HTIL-TTML-IN-AP Tata Teleservices Maharashtra Ltd 15 - 192.58.2.0/24 5011 0.1% AS6629 -- NOAA-AS - NOAA 16 - 192.58.232.0/24 4930 0.1% AS6629 -- NOAA-AS - NOAA 17 - 194.63.9.0/24 4801 0.1% AS1273 -- CW Cable and Wireless Worldwide plc 18 - 78.111.6.0/23 4592 0.1% AS44410 -- ENTEKHAB-AS ENTEKHAB INDUSTRIAL GROUP AS48159 -- TIC-AS Telecommunication Infrastructure Company 19 - 69.38.178.0/24 3976 0.1% AS19406 -- TWRS-MA - Towerstream I, Inc. 20 - 199.231.236.0/24 3188 0.1% AS15053 -- ROLL-GLOBAL-LLC - Roll Global LLC Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From trejrco at gmail.com Fri Sep 21 23:22:18 2012 From: trejrco at gmail.com (TJ) Date: Fri, 21 Sep 2012 19:22:18 -0400 Subject: Throw me a IPv6 bone (sort of was IPv6 ignorance) In-Reply-To: <505CC31C.3040709@amplex.net> References: <505C6C2D.7030204@amplex.net> <505C6E60.3000806@unfix.org> <505CC31C.3040709@amplex.net> Message-ID: > Running dual stack to residential consumers still has huge issues with CPE. It's not an environment where we have control over the router the customer picks up at Walmart. There is really very little point in spending a lot of resources on something the consumer can't currently use. > Note: Some of us regular, residential customers can and do have native IPv6 at home ... off the shelf gear, default configs, etc. From mohta at necom830.hpcl.titech.ac.jp Sat Sep 22 02:42:08 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 22 Sep 2012 11:42:08 +0900 Subject: Big Temporary Networks In-Reply-To: References: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> <505626A2.1090700@foobar.org> <505663DE.7000309@necom830.hpcl.titech.ac.jp> <50586620.6080702@necom830.hpcl.titech.ac.jp> <505973A4.90705@necom830.hpcl.titech.ac.jp> <505A40CD.8030701@necom830.hpcl.titech.ac.jp> <505A7033.6040807@necom830.hpcl.titech.ac.jp> <505A8E76.3030800@necom830.hpcl.titech.ac.jp> <505A9DC8.2040508@tiggee.com> <505AB5E1.7080204@necom830.hpcl.titech.ac.jp> <00b301cd975f$2ee354b0$8ca9fe10$@tndh.net> <505BE509.1000008@necom830.hpcl.titech.ac.jp> Message-ID: <505D2580.7000309@necom830.hpcl.titech.ac.jp> William Herrin wrote: >> You miss multicast storm caused by DAD. > Second, in the hotspot scenarios where this is likely to be a problem > (in IPv4 -or- IPv6) it's addressed by the "AP isolation" feature As you stated : I think Masataka meant to say (and said previously) that the DHCP : request from the wifi station is, like all packets from the wifi : station to the AP, subject to wifi's layer 2 error recovery. that is not a problem for IPv4 ARP and DHCP. > that's getting close to omnipresent even in the low end APs. With this > feature enabled, stations are not allowed to talk to each other over > the wlan; they can only talk to hosts on the wired side of the lan. > The DAD packets are simply never sent to the other stations. You are saying to disable DAD, which is a violation of SLAAC. > In theory there are some problems with this. In practice, it's in wide > deployment and has been demonstrated to work just fine. Tell it to IETF to modify SLAAC to exclude DAD. Masataka Ohta From Valdis.Kletnieks at vt.edu Sat Sep 22 02:58:12 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 21 Sep 2012 22:58:12 -0400 Subject: Throw me a IPv6 bone (sort of was IPv6 ignorance) In-Reply-To: Your message of "Fri, 21 Sep 2012 19:22:18 -0400." References: <505C6C2D.7030204@amplex.net> <505C6E60.3000806@unfix.org> <505CC31C.3040709@amplex.net> Message-ID: <73971.1348282692@turing-police.cc.vt.edu> On Fri, 21 Sep 2012 19:22:18 -0400, TJ said: > > Running dual stack to residential consumers still has huge issues with > CPE. It's not an environment where we have control over the router the > customer picks up at Walmart. There is really very little point in > spending a lot of resources on something the consumer can't currently use. > > > > Note: Some of us regular, residential customers can and do have native IPv6 > at home ... off the shelf gear, default configs, etc. But you have to admit it works a lot better if you're a customer of an ISP that isn't waiting to spend the resources... :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From ops.lists at gmail.com Sat Sep 22 03:03:34 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 22 Sep 2012 08:33:34 +0530 Subject: Throw me a IPv6 bone (sort of was IPv6 ignorance) In-Reply-To: <505C6C2D.7030204@amplex.net> References: <505C6C2D.7030204@amplex.net> Message-ID: Dhcpv6, radius .. take your pick --srs (htc one x) On Sep 21, 2012 7:04 PM, "Mark Radabaugh" wrote: > > The part of IPv6 that I am unclear on and have not found much > documentation on is how to run IPv6 only to end users. Anyone care to > point me in the right direction? > > Can we assign IPv6 only to end users? What software/equipment do we need > in place as a ISP to ensure these customers can reach IPv4 only hosts? > > The Interwebs are full of advice on setting up IPv6 tunnels for your house > (nice but...). There is lots of really old documentation out there for > IPv6 mechanisms that are depreciated or didn't fly. > > What is current best practice? > > -- > Mark Radabaugh > Amplex > > mark at amplex.net 419.837.5015 > > > From marka at isc.org Sat Sep 22 03:31:33 2012 From: marka at isc.org (Mark Andrews) Date: Sat, 22 Sep 2012 13:31:33 +1000 Subject: Throw me a IPv6 bone (sort of was IPv6 ignorance) In-Reply-To: References: <505C6C2D.7030204@amplex.net> Message-ID: <5234D0D8-3A81-4C42-84DB-E442330352F6@isc.org> On 22/09/2012, at 12:04 AM, Jared Mauch wrote: >> Can we assign IPv6 only to end users? What software/equipment do we need in place as a ISP to ensure these customers can reach IPv4 only hosts? > > I would say you want to do dual-stack, but shift the users that don't *need* public IPs into 1918 space and deliver v6 native as feasible. If you have a server lan, you can do this with SLAAC, but to get the other information to your hosts, either via RA's and otherwise, it's just becoming easier to do No. Use RFC 6598 space which was allocated for this purpose. Mark From rdobbins at arbor.net Sat Sep 22 05:02:39 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sat, 22 Sep 2012 05:02:39 +0000 Subject: Real world sflow vs netflow? In-Reply-To: References: <50012E21.4060802@bromirski.net> Message-ID: <4D7095F3-6FA5-4507-AA49-D5192BA58437@arbor.net> On Sep 22, 2012, at 12:40 AM, Peter Phaal wrote: > However, moving the flow generation out of the router gives a lot of flexibility. Actually, moving it out of the router creates huge problems and destroys a lot of the value of the flow telemetry - it nullifies your ability to traceback where traffic is ingressing your network, which is key for both security as well as traffic engineering, peering analysis, etc. It is far, far better to get your flow telemetry from your various edge routers, if at all possible, rather that probes. Scales better, too - and is less expensive in terms of both capex and opex. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From bill at herrin.us Sat Sep 22 06:12:03 2012 From: bill at herrin.us (William Herrin) Date: Sat, 22 Sep 2012 02:12:03 -0400 Subject: Big Temporary Networks In-Reply-To: <505D2580.7000309@necom830.hpcl.titech.ac.jp> References: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> <505626A2.1090700@foobar.org> <505663DE.7000309@necom830.hpcl.titech.ac.jp> <50586620.6080702@necom830.hpcl.titech.ac.jp> <505973A4.90705@necom830.hpcl.titech.ac.jp> <505A40CD.8030701@necom830.hpcl.titech.ac.jp> <505A7033.6040807@necom830.hpcl.titech.ac.jp> <505A8E76.3030800@necom830.hpcl.titech.ac.jp> <505A9DC8.2040508@tiggee.com> <505AB5E1.7080204@necom830.hpcl.titech.ac.jp> <00b301cd975f$2ee354b0$8ca9fe10$@tndh.net> <505BE509.1000008@necom830.hpcl.titech.ac.jp> <505D2580.7000309@necom830.hpcl.titech.ac.jp> Message-ID: On Fri, Sep 21, 2012 at 10:42 PM, Masataka Ohta wrote: > William Herrin wrote: >> that's getting close to omnipresent even in the low end APs. With this >> feature enabled, stations are not allowed to talk to each other over >> the wlan; they can only talk to hosts on the wired side of the lan. >> The DAD packets are simply never sent to the other stations. > > You are saying to disable DAD, which is a violation of SLAAC. We do that on some wired ethernets too. The Cisco configuration command is "switchport protected." It helps control virus outbreaks if machines designated clients can't talk to each other at layer 2, regardless of how that annoys layer 3. Does this bother you? Tough. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tore.anderson at redpill-linpro.com Sat Sep 22 08:03:31 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Sat, 22 Sep 2012 10:03:31 +0200 Subject: Throw me a IPv6 bone (sort of was IPv6 ignorance) In-Reply-To: <505CC31C.3040709@amplex.net> References: <505C6C2D.7030204@amplex.net> <505C6E60.3000806@unfix.org> <505CC31C.3040709@amplex.net> Message-ID: <505D70D3.6070702@redpill-linpro.com> * Mark Radabaugh > We can already do dual stack - that's not really a problem. I was > really rather hoping to avoid the giant NAT box. I'll take a look at DS > Lite and or NAT64/DNS64 and see if that makes any sense. Both DS-Lite and NAT64 contain some form of a ?giant NAT box? as part of the solution, I'm afraid. Same shit, different wrapping. You might want to look into MAP, which to the best of my knowledge is the only solution that facilitates IPv4 address sharing between subscribers without any form of (centralised) NAT. > Running dual stack to residential consumers still has huge issues with > CPE. It's not an environment where we have control over the router the > customer picks up at Walmart. In that case, running IPv6-only to your subscribers isn't a realistic proposition at this point in time. Unfortunately. If you're running out of IPv4 addresses, you better try to get your hands on more of them, somehow, or start planning for the ?giant NAT box? you're going to need. Alternatively, you could begin providing all your *new* subscribers with managed CPEs that support DS-Lite, MAP, NAT64/DNS64/464XLAT (or whichever other IPv4 life-support technology you end up choosing), while at the same time letting your old subscribers with their IPv4-only Walmart CPEs hang on to their public IPv4 address for as long as they need it. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From bonomi at mail.r-bonomi.com Sat Sep 22 08:17:44 2012 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Sat, 22 Sep 2012 03:17:44 -0500 (CDT) Subject: the economies of scale of a Worldcon, and how to make this topic relevant to Nanog In-Reply-To: Message-ID: <201209220817.q8M8Hi72012344@mail.r-bonomi.com> > Subject: Re: the economies of scale of a Worldcon, > From: Jo Rhett > Date: Fri, 21 Sep 2012 13:08:22 -0700 > > On Sep 21, 2012, at 10:00 AM, Jay Ashworth wrote: > > > A lot of this, too, depends on what the concom negotiated with the > > property about wifi access already. > > And this is where you're going to hit some very hard walls. > > One of which I forgot to mention. Many of the hotels (I believe all > Hilton properties at this time) have sold the facilities space for their > wifi network to another company. They CAN'T negotiate it with you, > because they don't own it any more. And most of these wifi networks have > stealth killers enabled, so that they spoof any other wifi zone they see > and send back reject messages to the clients. So you can't run them side > by side. This _is_ a "let's you and him fight" comment, but one might want to run an inquiry past the Friendly Candy Company, about the _legality_ of such 'killers' -- there are rules prorscribing _deliberate_/_intentional_ *active* "interference with radio communication" that do apply to 'unlicensed' spectrum. From marka at isc.org Sat Sep 22 10:21:44 2012 From: marka at isc.org (Mark Andrews) Date: Sat, 22 Sep 2012 20:21:44 +1000 Subject: The Department of Work and Pensions, UK has an entire /8 In-Reply-To: Your message of "Fri, 21 Sep 2012 22:33:21 +0100." <505CDD21.4080103@foobar.org> References: <20120918140712.GF9750@leitl.org> <20120919044603.1F64925671AD@drugs.dv.isc.org> <231483E9-5129-4722-87DE-635FEC3AC422@virtualized.org> <505A440D.5080701@dougbarton.us> <505A48D8.4040800@ttec.com> <36217.1348098710@turing-police.cc.vt.edu> <505A6844.9050703@ttec.com> <505A99D9.6010109@ttec.com> <505AC3F8.9060905@bogus.com> <8270A4D4-5B82-45B6-BD78-FD3586545D6F@gmail.com> <505B23E0.4030906@ttec.com> <00bc01cd9764$3aa38090$afea81b0$@tndh.net> <505B8C7B.7000408@foobar.org> <00e701cd978a$5654c710$02fe5530$@tndh.net> <505C9215.6000108@foobar.org> <017801cd9826$31616ca0$942445e0$@tndh.net> <505CDD21.40 80103@fo obar.org> Message-ID: <20120922102144.8DCF5278EDD3@drugs.dv.isc.org> In message <505CDD21.4080103 at foobar.org>, Nick Hilliard writes: > On 21/09/2012 19:23, Tony Hain wrote: > > App developers have never wanted to be aware of the network. > > By not sitting down and thinking about the user experience of a > dual-stacked network, we have now forced them to be aware of the network > and that's not a good thing because they are as clued out about networking > as most network operators are about programming. If we had designed a > portable and consistent happy-eyeballs API 10 years ago, it would be widely > available for use now. But we didn't do that because we were thinking > about the network rather than the users. So now, each dual stack developer > is going to have to sit down and reimplement happy eyeballs for themselves. > What a waste. RFC 1123 told app developers that they needed to support multihomed servers. That was over 2 decades ago. HE would not have been needed if app developers had followed that advice. > > As far as they > > are concerned it is the network managers job to get bits from the endpoint > > they are on to the endpoint they want to get to. Making them do contortions > > to figure out that they need to, and then how to, tell the network to do > > that adds complexity to their development and support. This is not an IPv6 > > issue, it is historic reality. > > No, it's a current reality for early venturers into ipv6. It may become a > future reality in the mainstream if ipv6 takes off in a way that I can't > foresee at the moment. One day in the future, maybe, it will become less > of an issue if people go back to a single-stack endpoint system. IPv6 will still be multi-homed. Dual stack is just a example of multi-homed. > > And something that is easy to fix by simply deploying a 6to4 relay in each > > AS and announcing the correct IPv6 prefix set to make it symmetric. > > In theory yes. In practice no. > > > event. Those that are doing so intentionally, while providing the long term > > path in parallel, can be described as weaning their customers off the > > legacy. Those that are doing so inadvertently, because they don't care abou > t > > anything but their tiny part of the overall system, will lose customers to > > the provider offering the long term path. > > So long as the cost of that is less than the cost of deploying ipv6 and > pushing people in that direction, it's a good business plan in the short > term. Which is what most people care about. I'm with you that it's a > hopeless long term business plan, but that's not the world we live in. > > Nick > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mohta at necom830.hpcl.titech.ac.jp Sat Sep 22 10:30:48 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 22 Sep 2012 19:30:48 +0900 Subject: Big Temporary Networks In-Reply-To: References: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> <50586620.6080702@necom830.hpcl.titech.ac.jp> <505973A4.90705@necom830.hpcl.titech.ac.jp> <505A40CD.8030701@necom830.hpcl.titech.ac.jp> <505A7033.6040807@necom830.hpcl.titech.ac.jp> <505A8E76.3030800@necom830.hpcl.titech.ac.jp> <505A9DC8.2040508@tiggee.com> <505AB5E1.7080204@necom830.hpcl.titech.ac.jp> <00b301cd975f$2ee354b0$8ca9fe10$@tndh.net> <505BE509.1000008@necom830.hpcl.titech.ac.jp> <505D2580.7000309@necom830.hpcl.titech.ac.jp> Message-ID: <505D9358.6040908@necom830.hpcl.titech.ac.jp> William Herrin wrote: >> You are saying to disable DAD, which is a violation of SLAAC. > > We do that on some wired ethernets too. You are calling such a link Ethernet. OK. Fine. > The Cisco configuration > command is "switchport protected." It helps control virus outbreaks if > machines designated clients can't talk to each other at layer 2, > regardless of how that annoys layer 3. It means IPv6 is broken over not only WiFi but also Ethernet. > Does this bother you? No, not me, not at all. Masataka Ohta From randy at psg.com Sat Sep 22 11:21:27 2012 From: randy at psg.com (Randy Bush) Date: Sat, 22 Sep 2012 20:21:27 +0900 Subject: Throw me a IPv6 bone (sort of was IPv6 ignorance) In-Reply-To: <505D70D3.6070702@redpill-linpro.com> References: <505C6C2D.7030204@amplex.net> <505C6E60.3000806@unfix.org> <505CC31C.3040709@amplex.net> <505D70D3.6070702@redpill-linpro.com> Message-ID: > Both DS-Lite and NAT64 contain some form of a ?giant NAT box? as part > of the solution, I'm afraid. Same shit, different wrapping. ds-lite is in the provider core. talk to the telco's lawyers when you want to use a new protocol. nat64 is at my cpe border. randy From marka at isc.org Sat Sep 22 11:39:05 2012 From: marka at isc.org (Mark Andrews) Date: Sat, 22 Sep 2012 21:39:05 +1000 Subject: Throw me a IPv6 bone (sort of was IPv6 ignorance) In-Reply-To: Your message of "Sat, 22 Sep 2012 20:21:27 +0900." References: <505C6C2D.7030204@amplex.net> <505C6E60.3000806@unfix.org> <505CC31C.3040709@amplex.net> <505D70D3.6070702@redpill-linpro.com> Message-ID: <20120922113905.5A033278F342@drugs.dv.isc.org> In message , Randy Bush writes: > > Both DS-Lite and NAT64 contain some form of a =ABgiant NAT box=BB as part > > of the solution, I'm afraid. Same shit, different wrapping. > > ds-lite is in the provider core. talk to the telco's lawyers when you > want to use a new protocol. DS-lite can be deployed between between customer and anyone that wants to provide IPv4 service for that customer. I would expect DS-lite to be out sourced by ISPs. > nat64 is at my cpe border. > > randy > -- 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 Sat Sep 22 12:07:18 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Sat, 22 Sep 2012 14:07:18 +0200 Subject: Throw me a IPv6 bone (sort of was IPv6 ignorance) In-Reply-To: References: <505C6C2D.7030204@amplex.net> <505C6E60.3000806@unfix.org> <505CC31C.3040709@amplex.net> <505D70D3.6070702@redpill-linpro.com> Message-ID: <505DA9F6.30106@redpill-linpro.com> * Randy Bush >> Both DS-Lite and NAT64 contain some form of a ?giant NAT box? as part >> of the solution, I'm afraid. Same shit, different wrapping. > > ds-lite is in the provider core. talk to the telco's lawyers when you > want to use a new protocol. > > nat64 is at my cpe border. Mark was asking about how to run IPv6-only to his subscribers. I don't see how doing NAT64 in the CPE could possibly help him with that, as the NAT64 function would require an IPv4 address for its outside interface. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From mark at amplex.net Sat Sep 22 13:23:10 2012 From: mark at amplex.net (Mark Radabaugh) Date: Sat, 22 Sep 2012 09:23:10 -0400 Subject: Throw me a IPv6 bone (sort of was IPv6 ignorance) In-Reply-To: <505D70D3.6070702@redpill-linpro.com> References: <505C6C2D.7030204@amplex.net> <505C6E60.3000806@unfix.org> <505CC31C.3040709@amplex.net> <505D70D3.6070702@redpill-linpro.com> Message-ID: <505DBBBE.1030804@amplex.net> On 9/22/12 4:03 AM, Tore Anderson wrote: > * Mark Radabaugh > >> We can already do dual stack - that's not really a problem. I was >> really rather hoping to avoid the giant NAT box. I'll take a look at DS >> Lite and or NAT64/DNS64 and see if that makes any sense. > Both DS-Lite and NAT64 contain some form of a ?giant NAT box? as part of > the solution, I'm afraid. Same shit, different wrapping. > > You might want to look into MAP, which to the best of my knowledge is > the only solution that facilitates IPv4 address sharing between > subscribers without any form of (centralised) NAT. > >> Running dual stack to residential consumers still has huge issues with >> CPE. It's not an environment where we have control over the router the >> customer picks up at Walmart. > In that case, running IPv6-only to your subscribers isn't a realistic > proposition at this point in time. Unfortunately. If you're running out > of IPv4 addresses, you better try to get your hands on more of them, > somehow, or start planning for the ?giant NAT box? you're going to need. > > Alternatively, you could begin providing all your *new* subscribers with > managed CPEs that support DS-Lite, MAP, NAT64/DNS64/464XLAT (or > whichever other IPv4 life-support technology you end up choosing), while > at the same time letting your old subscribers with their IPv4-only > Walmart CPEs hang on to their public IPv4 address for as long as they > need it. > > Best regards, Thanks for the help. We are actually in decent shape with respect to IPv4, probably at least 1 if not 2 years at current growth rate. We can deliver dual stack with public IPv4/6 to customers now. This is the planning stage for <>, assuming there are no better options. We are starting to provide some customers with managed CPE and your alternative suggestion may be the way to go. There are several other business/management/support advantages to Amplex supplying the CPE. This may be reason enough to expand that program. I didn't really think we would be able to run IPv6 only in the near future but wanted to make sure I wasn't missing something obvious. -- Mark Radabaugh Amplex mark at amplex.net 419.837.5015 From tore.anderson at redpill-linpro.com Sat Sep 22 15:57:45 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Sat, 22 Sep 2012 17:57:45 +0200 Subject: Throw me a IPv6 bone (sort of was IPv6 ignorance) In-Reply-To: <505DBBBE.1030804@amplex.net> References: <505C6C2D.7030204@amplex.net> <505C6E60.3000806@unfix.org> <505CC31C.3040709@amplex.net> <505D70D3.6070702@redpill-linpro.com> <505DBBBE.1030804@amplex.net> Message-ID: <505DDFF9.7030302@redpill-linpro.com> * Mark Radabaugh > Thanks for the help. We are actually in decent shape with respect to > IPv4, probably at least 1 if not 2 years at current growth rate. We can > deliver dual stack with public IPv4/6 to customers now. This is the > planning stage for <>, assuming there are no better options. > > We are starting to provide some customers with managed CPE and your > alternative suggestion may be the way to go. There are several other > business/management/support advantages to Amplex supplying the CPE. > This may be reason enough to expand that program. > > I didn't really think we would be able to run IPv6 only in the near > future but wanted to make sure I wasn't missing something obvious. Okay. In this case I would pay very close attention to MAP/4RD. Here are some drafts to get you started: http://tools.ietf.org/html/draft-mdt-softwire-map-encapsulation-00 http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01 http://tools.ietf.org/html/draft-despres-softwire-4rd-u-06 There are different flavours, but as I understand it, the basic idea is the same... You won't find shipping products today, but there will probably be by the time you need it. Like DS-Lite, it assumes an IPv6-only access network, with the CPE communicating with a centralised component over IPv6 to provision IPv4 service for the subscriber's LAN. Unlike DS-Lite, however, the central component does not perform NAT or any other stateful translations - what it essentially does is to steal bits from the TCP/UDP port space for routing, so (oversimplified) subscriber A gets ports 2000-2999, B gets 3000-3999, and so forth. The subscriber will be able to receive internet-initiated traffic to his assigned port range. The NAT44 function in the CPE works pretty much like today, except that it must ensure the source ports are rewritten to fall inside its assigned range. You can also provision an ?entire IPv4? to a single CPE also, for example as a premium service. The central component is operating in stateless mode, so it'll be easier to scale than any centralised NAT, and you can also anycast it, load balance between several instances using ECMP, and so on. In my opinion, it looks like a much better approach than DS-Lite, both for the subscriber and the service provider - as long as you can wait for it a little while. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From peter.phaal at gmail.com Sat Sep 22 18:51:35 2012 From: peter.phaal at gmail.com (Peter Phaal) Date: Sat, 22 Sep 2012 11:51:35 -0700 Subject: Real world sflow vs netflow? In-Reply-To: <4D7095F3-6FA5-4507-AA49-D5192BA58437@arbor.net> References: <50012E21.4060802@bromirski.net> <4D7095F3-6FA5-4507-AA49-D5192BA58437@arbor.net> Message-ID: On Fri, Sep 21, 2012 at 10:02 PM, Dobbins, Roland wrote: > > On Sep 22, 2012, at 12:40 AM, Peter Phaal wrote: > >> However, moving the flow generation out of the router gives a lot of flexibility. > > Actually, moving it out of the router creates huge problems and destroys a lot of the value of the flow telemetry - it nullifies your ability to traceback where traffic is ingressing your network, which is key for both security as well as traffic engineering, peering analysis, etc. > > It is far, far better to get your flow telemetry from your various edge routers, if at all possible, rather that probes. Scales better, too - and is less expensive in terms of both capex and opex. Roland, I probably wasn't as clear as a should have been in describing how sFlow works. Here are some comments and links to additional information that address each of your concerns: 1. There are no probes involved when using sFlow, the architecture looks very similar to NetFlow with UDP records streaming from multiple routers to a software collector. http://blog.sflow.com/2009/05/choosing-sflow-analyzer.html 2. The sFlow records exported by the router include telemetry that allows you to trace traffic paths through the network (ingress port, egress port, FIB entry etc.). http://blog.sflow.com/2009/05/packet-paths.html 3. sFlow has a lower CAPEX, the flow cache resides in inexpensive memory on a commodity server instead of limited, expensive, TCAM memory on the router. The sFlow instrumentation is included in ASICs and is a base feature of the device; unlike NetFlow which often requires upgraded supervisor cards etc. sFlow is widely supported in merchant silicon, further reducing costs and increasing multi-vendor interoperability - Cisco supports sFlow in the merchant silicon based Nexus 3k series. http://blog.sflow.com/2010/09/superlinear.html http://blog.sflow.com/2011/12/merchant-silicon.html http://blog.sflow.com/2012/09/vendor-support.html http://blog.sflow.com/2012/08/cisco-adds-sflow-support.html 4. sFlow has lower OPEX, the architecture is simpler, has lower operational complexity and provides much greater scalability. http://blog.sflow.com/2010/11/complexity-kills.html http://blog.sflow.com/2010/09/superlinear.html Peter From rdobbins at arbor.net Sat Sep 22 23:41:18 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sat, 22 Sep 2012 23:41:18 +0000 Subject: Real world sflow vs netflow? In-Reply-To: References: <50012E21.4060802@bromirski.net> <4D7095F3-6FA5-4507-AA49-D5192BA58437@arbor.net> Message-ID: On Sep 23, 2012, at 1:51 AM, Peter Phaal wrote: > Here are some comments and links to additional information that address each of your concerns: You have misinterpreted what I said. I was saying that flow telemetry of any variety must be exported from edge devices, which in most cases are routers (in some cases layer-3 switches), in response to your 'move it out of the router' comment. I disagree quite strongly with your comments regarding s/Flow vs. NetFlow, but am not interested in spamming the list with an extended discussion thereof. Let's just agree to disagree on that issue. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From peter.phaal at gmail.com Sun Sep 23 04:43:01 2012 From: peter.phaal at gmail.com (Peter Phaal) Date: Sat, 22 Sep 2012 21:43:01 -0700 Subject: Real world sflow vs netflow? In-Reply-To: References: <50012E21.4060802@bromirski.net> <4D7095F3-6FA5-4507-AA49-D5192BA58437@arbor.net> Message-ID: On Sat, Sep 22, 2012 at 4:41 PM, Dobbins, Roland wrote: > You have misinterpreted what I said. I was saying that flow telemetry of any > variety must be exported from edge devices, which in most cases are routers > (in some cases layer-3 switches), in response to your 'move it out of the router' > comment. I am sorry I misunderstood your comment, I agree that it is important to gather telemetry directly from your edge devices. The comment "move it out of the router" referred to the location of the flow-cache in the following scenario. On Thu, Sep 20, 2012 at 11:21 AM, Mikael Abrahamsson wrote: > Most of the platforms I know of do sampled netflow at 1:100-1:1000 or so, > and then I don't really see the fundamental difference in doing the flow > analysis on the router itself (classic netflow) or doing the same but at the > sFlow collector. In both cases the router is generating the telemetry, in the netflow case, packets are sampled on the router, the router builds flow records based on the contents of the sampled packets, and the flow records are exported. In the sFlow case, the raw sampled packet headers are exported to external software which builds flow records. In both cases the router is making the primary measurements and you end up with the same measurements. On Fri, Sep 21, 2012 at 10:02 PM, Dobbins, Roland wrote: > Actually, moving it out of the router creates huge problems and destroys a lot of > the value of the flow telemetry - it nullifies your ability to traceback where traffic is > ingressing your network, which is key for both security as well as traffic > engineering, peering analysis, etc. > > It is far, far better to get your flow telemetry from your various edge routers, if at > all possible, rather that probes. Scales better, too - and is less expensive in > terms of both capex and opex. I agree completely, probes are expensive, difficult to manage and can't accurately tell you how the traffic passed through the router. From danny at tcb.net Sun Sep 23 12:55:32 2012 From: danny at tcb.net (Danny McPherson) Date: Sun, 23 Sep 2012 08:55:32 -0400 Subject: Real world sflow vs netflow? In-Reply-To: References: <50012E21.4060802@bromirski.net> <4D7095F3-6FA5-4507-AA49-D5192BA58437@arbor.net> Message-ID: <57755E40-54AA-47F1-903D-58B64E22577C@tcb.net> On Sep 23, 2012, at 12:43 AM, Peter Phaal wrote: > In both cases the router is generating the telemetry, in the netflow > case, packets are sampled on the router, the router builds flow > records based on the contents of the sampled packets, and the flow > records are exported. In the sFlow case, the raw sampled packet > headers are exported to external software which builds flow records. > In both cases the router is making the primary measurements and you > end up with the same measurements. Actually, you don't... If the *flow generation process is not performed on the router (or otherwise conveyed by some metadata outside of "raw [sampled] packet headers") then you lose visibility to ingress and egress ifIndex (interface) information -- information which is required if/when deploying controls on those systems to squelch various traffic flows. This is _part of the point Roland was trying to make. -danny From rdobbins at arbor.net Sun Sep 23 15:16:26 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 23 Sep 2012 15:16:26 +0000 Subject: Real world sflow vs netflow? In-Reply-To: <57755E40-54AA-47F1-903D-58B64E22577C@tcb.net> References: <50012E21.4060802@bromirski.net> <4D7095F3-6FA5-4507-AA49-D5192BA58437@arbor.net> <57755E40-54AA-47F1-903D-58B64E22577C@tcb.net> Message-ID: <6A181F19-EB7B-44D2-AFAE-0B58055AE574@arbor.net> On Sep 23, 2012, at 7:55 PM, Danny McPherson wrote: > If the *flow generation process is not performed on the router (or otherwise conveyed by some metadata outside of "raw [sampled] packet headers") then you lose visibility to ingress and egress ifIndex (interface) information -- information which is required if/when deploying controls on those systems to squelch various traffic flows. Thanks, Danny - I guess I should've spelled it out, thanks for clarifying, heh. It should also be noted that generating the flows directly from the data plane of the router/switch or doing it offboard (as long as sufficient ingress/egress ifindex metadata are collected and exported, as you note) is just an implementation detail - it isn't inherent to s/Flow, NetFlow, IPFIX, et. al. So, claiming this as some kind of advantage for a particular flow telemetry format is a non sequitur. ;> ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From peter.phaal at gmail.com Sun Sep 23 16:23:57 2012 From: peter.phaal at gmail.com (Peter Phaal) Date: Sun, 23 Sep 2012 09:23:57 -0700 Subject: Real world sflow vs netflow? In-Reply-To: <6A181F19-EB7B-44D2-AFAE-0B58055AE574@arbor.net> References: <50012E21.4060802@bromirski.net> <4D7095F3-6FA5-4507-AA49-D5192BA58437@arbor.net> <57755E40-54AA-47F1-903D-58B64E22577C@tcb.net> <6A181F19-EB7B-44D2-AFAE-0B58055AE574@arbor.net> Message-ID: On Sun, Sep 23, 2012 at 8:16 AM, Dobbins, Roland wrote: > > On Sep 23, 2012, at 7:55 PM, Danny McPherson wrote: > >> If the *flow generation process is not performed on the router (or otherwise >> conveyed by some metadata outside of "raw [sampled] packet headers") then >> you lose visibility to ingress and egress ifIndex (interface) information -- >> information which is required if/when deploying controls on those systems to >> squelch various traffic flows. > > Thanks, Danny - I guess I should've spelled it out, thanks for clarifying, heh. > > It should also be noted that generating the flows directly from the data plane of the > router/switch or doing it offboard (as long as sufficient ingress/egress ifindex > metadata are collected and exported, as you note) is just an implementation detail > - it isn't inherent to s/Flow, NetFlow, IPFIX, et. al. So, claiming this as some kind > of advantage for a particular flow telemetry format is a non sequitur. Exporting packet oriented measurements doesn't mean that you have to loose ingress/egress interface data. In the specific example being discussed (sFlow export), detailed forwarding information from the router forwarding plane is exported with each sampled packet header (full AS-path if you are using BGP). An external flow generator in this case can produce flow records that are identical to those that the device would produce, i.e. include ingress/egress ports. The difference between packet oriented or flow oriented export is an "implementation detail" if your only requirement is to obtain layer IP flow records, but becomes significant if you want to create customized flow records or create packet oriented metrics. Applications for packet oriented metrics mentioned earlier in this thread included route analytics, analysis of ECMP/LAG/TRILL forwarding, packet size distribution vs. DSCP, DDoS mitigation. The problem with having the router perform the flow analysis is that once data is aggregated, it can't be disaggregated. It's like the difference between receiving eggs or an omelette. If you like the omelette, great! But if you wan't a different omelette or would like to poach, boil, scramble or bake your eggs then getting the raw eggs is a lot more versatile. From sh.vahabzadeh at gmail.com Sun Sep 23 18:51:33 2012 From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh) Date: Sun, 23 Sep 2012 22:21:33 +0330 Subject: Cisco 7206 IOS for PPPoE Termination Message-ID: Hello everybody, I am using C7206 VXR NPE-G2 routers as BRAS in my network and the current IOS is *c7200p-adventerprisek9-mz.124-24.T.bin* on them. Also their memory upgraded to 2GB instead of 1GB. And I have near 6500 online user on each of my BRAS and there is no speciefic feature except aaa with radius and ordinary features. There router is also terminating dot1q too because my PSTN centers traffic comes through dot1q vlans to BRAS es. I think I have some problem with current IOS, My CPU Usage is abnormal and Its near %70 or %80. And when I have a network problem and some of PSTN centers goes down CPU go to %99 and it gets problem to recovery. Do you know any good IOS for me as a service provider to use? I heard that some service providers have near 8000 online user on 7206. Thanks -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 From rinse.kloek at isp.solcon.nl Sun Sep 23 19:13:02 2012 From: rinse.kloek at isp.solcon.nl (Rinse Kloek) Date: Sun, 23 Sep 2012 21:13:02 +0200 Subject: Cisco 7206 IOS for PPPoE Termination In-Reply-To: References: Message-ID: <505F5F3E.2020404@isp.solcon.nl> 6000 PPP users on a NPE-G2 is way too much imho. Currently we do no more than 3000 users on a NPE-G2 with PPPoA. (Max cpu 50%). 5 years ago, we did about 5000 users on a NPE-G2, but as traffic ratio's grow each year the maximum users a NPE-G2 can handle will drop each year. Don't forget an NPE-G2 is a software based plaform, so traffic forwarding is done in software CPU. regards, Rinse Kloek Op 23-9-2012 20:51, Shahab Vahabzadeh schreef: > Hello everybody, > I am using C7206 VXR NPE-G2 routers as BRAS in my network and the current > IOS is *c7200p-adventerprisek9-mz.124-24.T.bin* on them. > Also their memory upgraded to 2GB instead of 1GB. > And I have near 6500 online user on each of my BRAS and there is no > speciefic feature except aaa with radius and ordinary features. > There router is also terminating dot1q too because my PSTN centers traffic > comes through dot1q vlans to BRAS es. > I think I have some problem with current IOS, My CPU Usage is abnormal and > Its near %70 or %80. > And when I have a network problem and some of PSTN centers goes down CPU go > to %99 and it gets problem to recovery. > Do you know any good IOS for me as a service provider to use? > I heard that some service providers have near 8000 online user on 7206. > Thanks > From rdobbins at arbor.net Sun Sep 23 19:17:42 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 23 Sep 2012 19:17:42 +0000 Subject: Real world sflow vs netflow? In-Reply-To: References: <50012E21.4060802@bromirski.net> <4D7095F3-6FA5-4507-AA49-D5192BA58437@arbor.net> <57755E40-54AA-47F1-903D-58B64E22577C@tcb.net> <6A181F19-EB7B-44D2-AFAE-0B58055AE574@arbor.net> Message-ID: On Sep 23, 2012, at 11:23 PM, Peter Phaal wrote: > The difference between packet oriented or flow oriented export is an "implementation detail" if your only requirement is to obtain layer IP flow records, but becomes significant if you want to create customized flow records or create packet oriented metrics. Applications for packet oriented metrics mentioned earlier in this thread included route analytics, analysis of ECMP/LAG/TRILL forwarding, packet size distribution vs. DSCP, DDoS mitigation. It might be a good idea to read up on Flexible NetFlow, IPFIX, and PSAMP over IPFIX, since everything you mention above can be done by collecting/analyzing those telemetry formats. In fact, it might be a good idea to read up on plain old classical NetFlow v5 and v9, too, as almost all of what's mentioned above is accomplished every day using them, as well, heh. > The problem with having the router perform the flow analysis is that once data is aggregated, it can't be disaggregated. Nobody in this thread has advocated aggregated NetFlow. I certainly don't. At any rate, I knew this would happen if we started talking about the merits of s/Flow vs. NetFlow. For some reason, s/Flow advocates seem to feel compelled to come up with straw-man arguments and misstatements, and try to use them to 'prove' what they view as the inherent superiority of s/Flow - when any unbiased indvidual who's worked with both formats at length knows that this simply isn't true. In this particular instance, I guess it's natural to feel compelled to present one's own creations in a positive light. However, it just isn't cricket to make incorrect, incomplete, and/or misleading statements about perceived competitors to one's own creations, you know? > It's like the difference between receiving eggs or an omelette. If you like the omelette, great! But if you wan't a different omelette or would like > to poach, boil, scramble or bake your eggs then getting the raw eggs is a lot more versatile. At any rate, I've wasted enough of everyone's time/bandwidth as a result of this particular instance of flow telemetry format trolling; I won't be providing anything more in the way of sustenance. ;> ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From sh.vahabzadeh at gmail.com Sun Sep 23 19:23:36 2012 From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh) Date: Sun, 23 Sep 2012 22:53:36 +0330 Subject: Cisco 7206 IOS for PPPoE Termination In-Reply-To: <505F5F3E.2020404@isp.solcon.nl> References: <505F5F3E.2020404@isp.solcon.nl> Message-ID: Which software you used before for them? On Sun, Sep 23, 2012 at 10:43 PM, Rinse Kloek wrote: > 6000 PPP users on a NPE-G2 is way too much imho. Currently we do no more > than 3000 users on a NPE-G2 with PPPoA. (Max cpu 50%). > 5 years ago, we did about 5000 users on a NPE-G2, but as traffic ratio's > grow each year the maximum users a NPE-G2 can handle will drop each year. > Don't forget an NPE-G2 is a software based plaform, so traffic forwarding > is done in software CPU. > > regards, > Rinse Kloek > Op 23-9-2012 20:51, Shahab Vahabzadeh schreef: > >> Hello everybody, >> I am using C7206 VXR NPE-G2 routers as BRAS in my network and the current >> IOS is *c7200p-adventerprisek9-mz.**124-24.T.bin* on them. >> >> Also their memory upgraded to 2GB instead of 1GB. >> And I have near 6500 online user on each of my BRAS and there is no >> speciefic feature except aaa with radius and ordinary features. >> There router is also terminating dot1q too because my PSTN centers traffic >> comes through dot1q vlans to BRAS es. >> I think I have some problem with current IOS, My CPU Usage is abnormal and >> Its near %70 or %80. >> And when I have a network problem and some of PSTN centers goes down CPU >> go >> to %99 and it gets problem to recovery. >> Do you know any good IOS for me as a service provider to use? >> I heard that some service providers have near 8000 online user on 7206. >> Thanks >> >> -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 From paul4004 at gmail.com Sun Sep 23 19:47:35 2012 From: paul4004 at gmail.com (PC) Date: Sun, 23 Sep 2012 13:47:35 -0600 Subject: Cisco 7206 IOS for PPPoE Termination In-Reply-To: References: <505F5F3E.2020404@isp.solcon.nl> Message-ID: For this application, you may wish to consider the service provider images. The latest 15.x(S) image works, as it is the derivative of what was formerly the service-provider oriented 12.2(SRx) images. However, it's unlikely to drop steady state CPU, but it may contain some optimizations for concurrent PPP (re)negotiations on the G2 platform during session recovery. PPPoE will generally handle more users on ethernet as it is easier to push packets on when not dealing with the ATM encapsulations, but to what extent this holds true on the 7200, I can't tell you for sure. I'd also read the broadband aggregation guide under the IOS documentation on cisco.com, and tune all the knobs that may help you, there are some pointers on what items on virtual-templates are punitive in performance, other optional items such as disabling SNMP counters on virtual access interfaces to reduce cpu usage, and other items that may help little by little. There are also various knobs to throttle PPPoE renegotiation rates during recovery. I wish you luck (and consider getting another and/or bigger router to split the load). On Sun, Sep 23, 2012 at 1:23 PM, Shahab Vahabzadeh wrote: > Which software you used before for them? > > On Sun, Sep 23, 2012 at 10:43 PM, Rinse Kloek >wrote: > > > 6000 PPP users on a NPE-G2 is way too much imho. Currently we do no more > > than 3000 users on a NPE-G2 with PPPoA. (Max cpu 50%). > > 5 years ago, we did about 5000 users on a NPE-G2, but as traffic ratio's > > grow each year the maximum users a NPE-G2 can handle will drop each year. > > Don't forget an NPE-G2 is a software based plaform, so traffic forwarding > > is done in software CPU. > > > > regards, > > Rinse Kloek > > Op 23-9-2012 20:51, Shahab Vahabzadeh schreef: > > > >> Hello everybody, > >> I am using C7206 VXR NPE-G2 routers as BRAS in my network and the > current > >> IOS is *c7200p-adventerprisek9-mz.**124-24.T.bin* on them. > >> > >> Also their memory upgraded to 2GB instead of 1GB. > >> And I have near 6500 online user on each of my BRAS and there is no > >> speciefic feature except aaa with radius and ordinary features. > >> There router is also terminating dot1q too because my PSTN centers > traffic > >> comes through dot1q vlans to BRAS es. > >> I think I have some problem with current IOS, My CPU Usage is abnormal > and > >> Its near %70 or %80. > >> And when I have a network problem and some of PSTN centers goes down CPU > >> go > >> to %99 and it gets problem to recovery. > >> Do you know any good IOS for me as a service provider to use? > >> I heard that some service providers have near 8000 online user on 7206. > >> Thanks > >> > >> > > > -- > Regards, > Shahab Vahabzadeh, Network Engineer and System Administrator > > Cell Phone: +1 (415) 871 0742 > PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 > From jako.andras at eik.bme.hu Sun Sep 23 19:50:19 2012 From: jako.andras at eik.bme.hu (=?ISO-8859-15?Q?J=C1K=D3_Andr=E1s?=) Date: Sun, 23 Sep 2012 21:50:19 +0200 (CEST) Subject: Big Temporary Networks In-Reply-To: References: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> <505626A2.1090700@foobar.org> <505663DE.7000309@necom830.hpcl.titech.ac.jp> <50586620.6080702@necom830.hpcl.titech.ac.jp> <505973A4.90705@necom830.hpcl.titech.ac.jp> <505A40CD.8030701@necom830.hpcl.titech.ac.jp> <505A7033.6040807@necom830.hpcl.titech.ac.jp> <505A8E76.3030800@necom830.hpcl.titech.ac.jp> <505A9DC8.2040508@tiggee.com> <505AB5E1.7080204@necom830.hpcl.titech.ac.jp> <00b301cd975f$2ee354b0$8ca9fe10$@tndh.net> <505BE509.1000008@necom830.hpcl.titech.ac.jp> Message-ID: > Second, in the hotspot scenarios where this is likely to be a problem > (in IPv4 -or- IPv6) it's addressed by the "AP isolation" feature > that's getting close to omnipresent even in the low end APs. With this > feature enabled, stations are not allowed to talk to each other over > the wlan; they can only talk to hosts on the wired side of the lan. Not related to the original subject, neither to IPv6 usability on WLANs, just a small comment: As far as I understand "AP isolation" doesn't work if you don't have a WLAN controller but do have more than one APs. E.g. in the following setup ap1--sw1--sw2--ap2 with "AP isolation" turned on, clients associated to ap1 cannot communicate directly with other clients associated to ap1, however they can communicate directly with those associated to ap2. Broadcast from ap1's clients does also get to all clients at ap2. Regards, Andr?s From sh.vahabzadeh at gmail.com Sun Sep 23 20:36:47 2012 From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh) Date: Mon, 24 Sep 2012 00:06:47 +0330 Subject: Cisco 7206 IOS for PPPoE Termination In-Reply-To: References: <505F5F3E.2020404@isp.solcon.nl> Message-ID: Dear Paul, Thanks for you reply, May I have those optimization knobs for virtual-template and throttles? Maybe looking into your configurations help me in this field. I will look for the service provider image too. Thanks On Sun, Sep 23, 2012 at 11:17 PM, PC wrote: > For this application, you may wish to consider the service provider images. > > The latest 15.x(S) image works, as it is the derivative of what was > formerly the service-provider oriented 12.2(SRx) images. > > However, it's unlikely to drop steady state CPU, but it may contain some > optimizations for concurrent PPP (re)negotiations on the G2 platform during > session recovery. > > PPPoE will generally handle more users on ethernet as it is easier to push > packets on when not dealing with the ATM encapsulations, but to what extent > this holds true on the 7200, I can't tell you for sure. > > I'd also read the broadband aggregation guide under the IOS documentation > on cisco.com, and tune all the knobs that may help you, there are some > pointers on what items on virtual-templates are punitive in performance, > other optional items such as disabling SNMP counters on virtual access > interfaces to reduce cpu usage, and other items that may help little by > little. There are also various knobs to throttle PPPoE renegotiation rates > during recovery. > > I wish you luck (and consider getting another and/or bigger router to > split the load). > > On Sun, Sep 23, 2012 at 1:23 PM, Shahab Vahabzadeh < > sh.vahabzadeh at gmail.com> wrote: > >> Which software you used before for them? >> >> On Sun, Sep 23, 2012 at 10:43 PM, Rinse Kloek > >wrote: >> >> > 6000 PPP users on a NPE-G2 is way too much imho. Currently we do no more >> > than 3000 users on a NPE-G2 with PPPoA. (Max cpu 50%). >> > 5 years ago, we did about 5000 users on a NPE-G2, but as traffic ratio's >> > grow each year the maximum users a NPE-G2 can handle will drop each >> year. >> > Don't forget an NPE-G2 is a software based plaform, so traffic >> forwarding >> > is done in software CPU. >> > >> > regards, >> > Rinse Kloek >> > Op 23-9-2012 20:51, Shahab Vahabzadeh schreef: >> > >> >> Hello everybody, >> >> I am using C7206 VXR NPE-G2 routers as BRAS in my network and the >> current >> >> IOS is *c7200p-adventerprisek9-mz.**124-24.T.bin* on them. >> >> >> >> >> Also their memory upgraded to 2GB instead of 1GB. >> >> And I have near 6500 online user on each of my BRAS and there is no >> >> speciefic feature except aaa with radius and ordinary features. >> >> There router is also terminating dot1q too because my PSTN centers >> traffic >> >> comes through dot1q vlans to BRAS es. >> >> I think I have some problem with current IOS, My CPU Usage is abnormal >> and >> >> Its near %70 or %80. >> >> And when I have a network problem and some of PSTN centers goes down >> CPU >> >> go >> >> to %99 and it gets problem to recovery. >> >> Do you know any good IOS for me as a service provider to use? >> >> I heard that some service providers have near 8000 online user on 7206. >> >> Thanks >> >> >> >> >> >> >> -- >> Regards, >> Shahab Vahabzadeh, Network Engineer and System Administrator >> >> Cell Phone: +1 (415) 871 0742 >> PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 >> > > -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 From MGauvin at dryden.ca Sun Sep 23 20:49:38 2012 From: MGauvin at dryden.ca (Mark Gauvin) Date: Sun, 23 Sep 2012 15:49:38 -0500 Subject: Cisco 7206 IOS for PPPoE Termination In-Reply-To: References: <505F5F3E.2020404@isp.solcon.nl> Message-ID: <7F4ED960-4203-4695-B19A-5EF464D76955@dryden.ca> You are joking I hope Sent from my iPhone On 2012-09-23, at 3:38 PM, "Shahab Vahabzadeh" wrote: > Dear Paul, > Thanks for you reply, May I have those optimization knobs for > virtual-template and throttles? > Maybe looking into your configurations help me in this field. > I will look for the service provider image too. > Thanks > > On Sun, Sep 23, 2012 at 11:17 PM, PC wrote: > >> For this application, you may wish to consider the service provider images. >> >> The latest 15.x(S) image works, as it is the derivative of what was >> formerly the service-provider oriented 12.2(SRx) images. >> >> However, it's unlikely to drop steady state CPU, but it may contain some >> optimizations for concurrent PPP (re)negotiations on the G2 platform during >> session recovery. >> >> PPPoE will generally handle more users on ethernet as it is easier to push >> packets on when not dealing with the ATM encapsulations, but to what extent >> this holds true on the 7200, I can't tell you for sure. >> >> I'd also read the broadband aggregation guide under the IOS documentation >> on cisco.com, and tune all the knobs that may help you, there are some >> pointers on what items on virtual-templates are punitive in performance, >> other optional items such as disabling SNMP counters on virtual access >> interfaces to reduce cpu usage, and other items that may help little by >> little. There are also various knobs to throttle PPPoE renegotiation rates >> during recovery. >> >> I wish you luck (and consider getting another and/or bigger router to >> split the load). >> >> On Sun, Sep 23, 2012 at 1:23 PM, Shahab Vahabzadeh < >> sh.vahabzadeh at gmail.com> wrote: >> >>> Which software you used before for them? >>> >>> On Sun, Sep 23, 2012 at 10:43 PM, Rinse Kloek >>> wrote: >>> >>>> 6000 PPP users on a NPE-G2 is way too much imho. Currently we do no more >>>> than 3000 users on a NPE-G2 with PPPoA. (Max cpu 50%). >>>> 5 years ago, we did about 5000 users on a NPE-G2, but as traffic ratio's >>>> grow each year the maximum users a NPE-G2 can handle will drop each >>> year. >>>> Don't forget an NPE-G2 is a software based plaform, so traffic >>> forwarding >>>> is done in software CPU. >>>> >>>> regards, >>>> Rinse Kloek >>>> Op 23-9-2012 20:51, Shahab Vahabzadeh schreef: >>>> >>>>> Hello everybody, >>>>> I am using C7206 VXR NPE-G2 routers as BRAS in my network and the >>> current >>>>> IOS is *c7200p-adventerprisek9-mz.**124-24.T.bin* on them. >>> >>>>> >>>>> Also their memory upgraded to 2GB instead of 1GB. >>>>> And I have near 6500 online user on each of my BRAS and there is no >>>>> speciefic feature except aaa with radius and ordinary features. >>>>> There router is also terminating dot1q too because my PSTN centers >>> traffic >>>>> comes through dot1q vlans to BRAS es. >>>>> I think I have some problem with current IOS, My CPU Usage is abnormal >>> and >>>>> Its near %70 or %80. >>>>> And when I have a network problem and some of PSTN centers goes down >>> CPU >>>>> go >>>>> to %99 and it gets problem to recovery. >>>>> Do you know any good IOS for me as a service provider to use? >>>>> I heard that some service providers have near 8000 online user on 7206. >>>>> Thanks >>>>> >>>>> >>> >>> >>> -- >>> Regards, >>> Shahab Vahabzadeh, Network Engineer and System Administrator >>> >>> Cell Phone: +1 (415) 871 0742 >>> PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 >>> >> >> > > > -- > Regards, > Shahab Vahabzadeh, Network Engineer and System Administrator > > Cell Phone: +1 (415) 871 0742 > PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 From sh.vahabzadeh at gmail.com Sun Sep 23 20:50:53 2012 From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh) Date: Mon, 24 Sep 2012 00:20:53 +0330 Subject: Cisco 7206 IOS for PPPoE Termination In-Reply-To: <7F4ED960-4203-4695-B19A-5EF464D76955@dryden.ca> References: <505F5F3E.2020404@isp.solcon.nl> <7F4ED960-4203-4695-B19A-5EF464D76955@dryden.ca> Message-ID: why joking Mark? On Mon, Sep 24, 2012 at 12:19 AM, Mark Gauvin wrote: > You are joking I hope > > Sent from my iPhone > > On 2012-09-23, at 3:38 PM, "Shahab Vahabzadeh" > wrote: > > > Dear Paul, > > Thanks for you reply, May I have those optimization knobs for > > virtual-template and throttles? > > Maybe looking into your configurations help me in this field. > > I will look for the service provider image too. > > Thanks > > > > On Sun, Sep 23, 2012 at 11:17 PM, PC wrote: > > > >> For this application, you may wish to consider the service provider > images. > >> > >> The latest 15.x(S) image works, as it is the derivative of what was > >> formerly the service-provider oriented 12.2(SRx) images. > >> > >> However, it's unlikely to drop steady state CPU, but it may contain some > >> optimizations for concurrent PPP (re)negotiations on the G2 platform > during > >> session recovery. > >> > >> PPPoE will generally handle more users on ethernet as it is easier to > push > >> packets on when not dealing with the ATM encapsulations, but to what > extent > >> this holds true on the 7200, I can't tell you for sure. > >> > >> I'd also read the broadband aggregation guide under the IOS > documentation > >> on cisco.com, and tune all the knobs that may help you, there are some > >> pointers on what items on virtual-templates are punitive in performance, > >> other optional items such as disabling SNMP counters on virtual access > >> interfaces to reduce cpu usage, and other items that may help little by > >> little. There are also various knobs to throttle PPPoE renegotiation > rates > >> during recovery. > >> > >> I wish you luck (and consider getting another and/or bigger router to > >> split the load). > >> > >> On Sun, Sep 23, 2012 at 1:23 PM, Shahab Vahabzadeh < > >> sh.vahabzadeh at gmail.com> wrote: > >> > >>> Which software you used before for them? > >>> > >>> On Sun, Sep 23, 2012 at 10:43 PM, Rinse Kloek < > rinse.kloek at isp.solcon.nl > >>>> wrote: > >>> > >>>> 6000 PPP users on a NPE-G2 is way too much imho. Currently we do no > more > >>>> than 3000 users on a NPE-G2 with PPPoA. (Max cpu 50%). > >>>> 5 years ago, we did about 5000 users on a NPE-G2, but as traffic > ratio's > >>>> grow each year the maximum users a NPE-G2 can handle will drop each > >>> year. > >>>> Don't forget an NPE-G2 is a software based plaform, so traffic > >>> forwarding > >>>> is done in software CPU. > >>>> > >>>> regards, > >>>> Rinse Kloek > >>>> Op 23-9-2012 20:51, Shahab Vahabzadeh schreef: > >>>> > >>>>> Hello everybody, > >>>>> I am using C7206 VXR NPE-G2 routers as BRAS in my network and the > >>> current > >>>>> IOS is *c7200p-adventerprisek9-mz.**124-24.T.bin* on them. > >>> > >>>>> > >>>>> Also their memory upgraded to 2GB instead of 1GB. > >>>>> And I have near 6500 online user on each of my BRAS and there is no > >>>>> speciefic feature except aaa with radius and ordinary features. > >>>>> There router is also terminating dot1q too because my PSTN centers > >>> traffic > >>>>> comes through dot1q vlans to BRAS es. > >>>>> I think I have some problem with current IOS, My CPU Usage is > abnormal > >>> and > >>>>> Its near %70 or %80. > >>>>> And when I have a network problem and some of PSTN centers goes down > >>> CPU > >>>>> go > >>>>> to %99 and it gets problem to recovery. > >>>>> Do you know any good IOS for me as a service provider to use? > >>>>> I heard that some service providers have near 8000 online user on > 7206. > >>>>> Thanks > >>>>> > >>>>> > >>> > >>> > >>> -- > >>> Regards, > >>> Shahab Vahabzadeh, Network Engineer and System Administrator > >>> > >>> Cell Phone: +1 (415) 871 0742 > >>> PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 > BF90 > >>> > >> > >> > > > > > > -- > > Regards, > > Shahab Vahabzadeh, Network Engineer and System Administrator > > > > Cell Phone: +1 (415) 871 0742 > > PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 > -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 From jra at baylink.com Sun Sep 23 22:48:36 2012 From: jra at baylink.com (Jay Ashworth) Date: Sun, 23 Sep 2012 18:48:36 -0400 (EDT) Subject: the economies of scale of a Worldcon, and how to make this topic relevant to Nanog In-Reply-To: Message-ID: <33150791.25988.1348440516118.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jo Rhett" > On Sep 21, 2012, at 10:00 AM, Jay Ashworth wrote: > > And this is pretty much precisely why I'm hammering the nail; > > there's > > *lots* of stuff that could -- and properly should -- be technology > > assisted at the world's largest gathering of science fiction > > enthusiasts. > > No point in building fast access to nothing (related to the con) ;-) True 'nuff. > I'm not saying that's right, but it is what is. And don't forget that > right now hard SF is a pretty mean minority. The vast majority of > sci-fi fans are into steampunk and other alt history these days. (and > don't get me started about that) iPhones are not generally strapped to > their victorian outfits. Heh. > > Assuming you can get close enough -- which won't be geographically > > practical for ... oh, wait; you're envisioning 3G, not WLAN. Yeah, > > I suppose that might work... until you consider that I will, personally, > > be bringing both laptops, my tablet, and my phone, all of which want > > All of which can use LTE either natively or with a dongle. As I noted in another reply, there are both "having a dongle" and "having an account" problem with that which are generally not easy to solve for the duration of a Worldcon (only). > > to talk to the outside world. I would bet that I'm not all *that* > > unusual in that, at a Worldcon, based on some attendee conversations > > I've had at Anticipation and the much less well attended NASfic 10, > > ReConstruction. > > You aren't unusual, but you aren't the average by a long shot. Stipulated. > > A lot of this, too, depends on what the concom negotiated with the > > property about wifi access already. > > And this is where you're going to hit some very hard walls. I don't know yet. > One of which I forgot to mention. Many of the hotels (I believe all > Hilton properties at this time) have sold the facilities space for > their wifi network to another company. They CAN'T negotiate it with > you, because they don't own it any more. And most of these wifi > networks have stealth killers enabled, so that they spoof any other > wifi zone they see and send back reject messages to the clients. So > you can't run them side by side. Do FCC regs actually permit that, license-free-band be damned? > Try having a conversation with the hotel rep in charge of selling > convention space about these kind of technical bits about wifi > networks sometime. If you don't mind tearing your hair out at the > time. Or tearing it out later, after you've been assured that the > hotel will "make it all work" and then find that none of this > equipment is within their control. (they don't care, you're already > there and can't go anywhere else) Well, yeah, but I don't think the contract is actually *signed* yet, and that I know which questions to ask, and what valid answers are, is precisely why I'm sticking my nose into it in the first place. > Sorry I'm being so negative on this topic. Got more than a few burnt > fingers on this one :) Understood. Thanks for throwing yourself manfully on the grenade. > > Can I get 12000 sessions on a single LTE tower? > > Yes. Can you get 12000 sessions through any single POE gateway? ;-) POE? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From mysidia at gmail.com Sun Sep 23 23:25:38 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 23 Sep 2012 18:25:38 -0500 Subject: the economies of scale of a Worldcon, and how to make this topic relevant to Nanog In-Reply-To: <33150791.25988.1348440516118.JavaMail.root@benjamin.baylink.com> References: <33150791.25988.1348440516118.JavaMail.root@benjamin.baylink.com> Message-ID: On 9/23/12, Jay Ashworth wrote: > Do FCC regs actually permit that, license-free-band be damned? [snip] In the US, operation of 802.11 WiFi devices in the unlicensed bands is authorized under part 15 of FCC regulations only; LICENSED radio operators, may be able to operate wireless networking devices e.g. WiMax under different rules, within their allocated frequency range. If you know of an access point that is manufactured and marketed that intentionally causes radio interference when operated, then that might be grounds for a complaint against the FCC certification of the device, but sending forged protocol transmissions that look like 'reject' messages might not count, or may be a gray area; I have not heard of a ruling on..... I suppose it is an open question? http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr&sid=3fb4a93ba82bbca4b37c178c76f1f968&rgn=div5&view=text&node=47:1.0.1.1.16&idno=47 " (b) Operation of an intentional, unintentional, or incidental radiator is subject to the conditions that no harmful interference is caused and that interference must be accepted that may be caused by the operation of an authorized radio station, by another intentional or unintentional radiator, by industrial, scientific and medical (ISM) equipment, or by an incidental radiator. (c) The operator of a radio frequency device shall be required to cease operating the device upon notification by a Commission representative that the device is causing harmful interference. Operation shall not resume until the condition causing the harmful interference has been corrected. (d) Intentional radiators that produce Class B emissions (damped wave) are prohibited. " -- -JH From jared at puck.nether.net Sun Sep 23 23:41:07 2012 From: jared at puck.nether.net (Jared Mauch) Date: Sun, 23 Sep 2012 19:41:07 -0400 Subject: the economies of scale of a Worldcon, and how to make this topic relevant to Nanog In-Reply-To: References: <18055291.25902.1348246859576.JavaMail.root@benjamin.baylink.com> Message-ID: <9D131EF8-B113-4CEF-8891-4472F7813A35@puck.nether.net> I think you mean AT&T / wayport. They have ruined a number of hotels that I stay at. When you talk to support they always claim "unusual" event load due to the guests involved. I'm not expecting 50mbps in the room, but not getting past 256k or 512k defeats the purpose of asking me to offload their cellular network. (Which seems to not be congested by the same population). Jared Mauch On Sep 21, 2012, at 4:08 PM, Jo Rhett wrote: > One of which I forgot to mention. Many of the hotels (I believe all Hilton properties at this time) have sold the facilities space for their wifi network to another company. From joe at nethead.com Sun Sep 23 23:42:45 2012 From: joe at nethead.com (Joe Hamelin) Date: Sun, 23 Sep 2012 16:42:45 -0700 Subject: the economies of scale of a Worldcon, and how to make this topic relevant to Nanog In-Reply-To: <33150791.25988.1348440516118.JavaMail.root@benjamin.baylink.com> References: <33150791.25988.1348440516118.JavaMail.root@benjamin.baylink.com> Message-ID: Jo Rhett said: > One of which I forgot to mention. Many of the hotels (I believe all > Hilton properties at this time) have sold the facilities space for > their wifi network to another company. PSAV is the company. I just installed about 20 Cisco WiFi radios at the Doubletree (a Hilton prop) at Sea-Tac. These covered only the convention space, conf rooms, ball rooms, whatnot. It would seem that the hotel is running their own system in the other public areas such as check-in, coffee shops and bars. Mostly they were well placed, often in the same spot as the existing radios. But I'd never throw a geek-con at that system. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From bill at herrin.us Mon Sep 24 00:44:10 2012 From: bill at herrin.us (William Herrin) Date: Sun, 23 Sep 2012 20:44:10 -0400 Subject: Big Temporary Networks In-Reply-To: References: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> <505626A2.1090700@foobar.org> <505663DE.7000309@necom830.hpcl.titech.ac.jp> <50586620.6080702@necom830.hpcl.titech.ac.jp> <505973A4.90705@necom830.hpcl.titech.ac.jp> <505A40CD.8030701@necom830.hpcl.titech.ac.jp> <505A7033.6040807@necom830.hpcl.titech.ac.jp> <505A8E76.3030800@necom830.hpcl.titech.ac.jp> <505A9DC8.2040508@tiggee.com> <505AB5E1.7080204@necom830.hpcl.titech.ac.jp> <00b301cd975f$2ee354b0$8ca9fe10$@tndh.net> <505BE509.1000008@necom830.hpcl.titech.ac.jp> Message-ID: On Sun, Sep 23, 2012 at 3:50 PM, J?K? Andr?s wrote: >> Second, in the hotspot scenarios where this is likely to be a problem >> (in IPv4 -or- IPv6) it's addressed by the "AP isolation" feature >> that's getting close to omnipresent even in the low end APs. With this >> feature enabled, stations are not allowed to talk to each other over >> the wlan; they can only talk to hosts on the wired side of the lan. > > Not related to the original subject, neither to IPv6 usability on WLANs, > just a small comment: As far as I understand "AP isolation" doesn't work > if you don't have a WLAN controller but do have more than one APs. E.g. in > the following setup > > ap1--sw1--sw2--ap2 > > with "AP isolation" turned on, clients associated to ap1 cannot > communicate directly with other clients associated to ap1, however they > can communicate directly with those associated to ap2. Broadcast from > ap1's clients does also get to all clients at ap2. Hi Andr?s, This is one place where Cisco's "switchport protected" comes in handy. Plug both APs into switches where the port is set to protected mode and neither they nor the associated clients will be able to talk to each other. You can get the same effect with other brands. For example, in one on-the-cheap 5-AP hotspot I did, I vlaned the APs (using an older 802.1q capable switch) back to a Linux bridge with "ebtables --insert FORWARD --jump DROP". The Linux bridge was also the default router out of the wlan, so anything *to* the router worked but anything that would be forwarded was dropped instead. Works great. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From knife at toaster.net Mon Sep 24 01:02:02 2012 From: knife at toaster.net (Sean Lazar) Date: Sun, 23 Sep 2012 18:02:02 -0700 Subject: Cisco 7206 IOS for PPPoE Termination In-Reply-To: References: <505F5F3E.2020404@isp.solcon.nl> <7F4ED960-4203-4695-B19A-5EF464D76955@dryden.ca> Message-ID: <505FB10A.3030509@toaster.net> http://lmgtfy.com/?q=site%3Acisco.com+ios+broadband+aggregation+guide On 9/23/12 1:50 PM, Shahab Vahabzadeh wrote: > why joking Mark? > > On Mon, Sep 24, 2012 at 12:19 AM, Mark Gauvin wrote: > >> You are joking I hope >> >> Sent from my iPhone >> >> On 2012-09-23, at 3:38 PM, "Shahab Vahabzadeh" >> wrote: >> >>> Dear Paul, >>> Thanks for you reply, May I have those optimization knobs for >>> virtual-template and throttles? >>> Maybe looking into your configurations help me in this field. >>> I will look for the service provider image too. >>> Thanks >>> >>> On Sun, Sep 23, 2012 at 11:17 PM, PC wrote: >>> >>>> For this application, you may wish to consider the service provider >> images. >>>> The latest 15.x(S) image works, as it is the derivative of what was >>>> formerly the service-provider oriented 12.2(SRx) images. >>>> >>>> However, it's unlikely to drop steady state CPU, but it may contain some >>>> optimizations for concurrent PPP (re)negotiations on the G2 platform >> during >>>> session recovery. >>>> >>>> PPPoE will generally handle more users on ethernet as it is easier to >> push >>>> packets on when not dealing with the ATM encapsulations, but to what >> extent >>>> this holds true on the 7200, I can't tell you for sure. >>>> >>>> I'd also read the broadband aggregation guide under the IOS >> documentation >>>> on cisco.com, and tune all the knobs that may help you, there are some >>>> pointers on what items on virtual-templates are punitive in performance, >>>> other optional items such as disabling SNMP counters on virtual access >>>> interfaces to reduce cpu usage, and other items that may help little by >>>> little. There are also various knobs to throttle PPPoE renegotiation >> rates >>>> during recovery. >>>> >>>> I wish you luck (and consider getting another and/or bigger router to >>>> split the load). >>>> >>>> On Sun, Sep 23, 2012 at 1:23 PM, Shahab Vahabzadeh < >>>> sh.vahabzadeh at gmail.com> wrote: >>>> >>>>> Which software you used before for them? >>>>> >>>>> On Sun, Sep 23, 2012 at 10:43 PM, Rinse Kloek < >> rinse.kloek at isp.solcon.nl >>>>>> wrote: >>>>>> 6000 PPP users on a NPE-G2 is way too much imho. Currently we do no >> more >>>>>> than 3000 users on a NPE-G2 with PPPoA. (Max cpu 50%). >>>>>> 5 years ago, we did about 5000 users on a NPE-G2, but as traffic >> ratio's >>>>>> grow each year the maximum users a NPE-G2 can handle will drop each >>>>> year. >>>>>> Don't forget an NPE-G2 is a software based plaform, so traffic >>>>> forwarding >>>>>> is done in software CPU. >>>>>> >>>>>> regards, >>>>>> Rinse Kloek >>>>>> Op 23-9-2012 20:51, Shahab Vahabzadeh schreef: >>>>>> >>>>>>> Hello everybody, >>>>>>> I am using C7206 VXR NPE-G2 routers as BRAS in my network and the >>>>> current >>>>>>> IOS is *c7200p-adventerprisek9-mz.**124-24.T.bin* on them. >>>>>>> Also their memory upgraded to 2GB instead of 1GB. >>>>>>> And I have near 6500 online user on each of my BRAS and there is no >>>>>>> speciefic feature except aaa with radius and ordinary features. >>>>>>> There router is also terminating dot1q too because my PSTN centers >>>>> traffic >>>>>>> comes through dot1q vlans to BRAS es. >>>>>>> I think I have some problem with current IOS, My CPU Usage is >> abnormal >>>>> and >>>>>>> Its near %70 or %80. >>>>>>> And when I have a network problem and some of PSTN centers goes down >>>>> CPU >>>>>>> go >>>>>>> to %99 and it gets problem to recovery. >>>>>>> Do you know any good IOS for me as a service provider to use? >>>>>>> I heard that some service providers have near 8000 online user on >> 7206. >>>>>>> Thanks >>>>>>> >>>>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> Shahab Vahabzadeh, Network Engineer and System Administrator >>>>> >>>>> Cell Phone: +1 (415) 871 0742 >>>>> PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 >> BF90 >>>> >>> >>> -- >>> Regards, >>> Shahab Vahabzadeh, Network Engineer and System Administrator >>> >>> Cell Phone: +1 (415) 871 0742 >>> PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 > > From sh.vahabzadeh at gmail.com Mon Sep 24 06:07:46 2012 From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh) Date: Mon, 24 Sep 2012 09:37:46 +0330 Subject: Cisco 7206 IOS for PPPoE Termination In-Reply-To: <505FB10A.3030509@toaster.net> References: <505F5F3E.2020404@isp.solcon.nl> <7F4ED960-4203-4695-B19A-5EF464D76955@dryden.ca> <505FB10A.3030509@toaster.net> Message-ID: I know how to use Google dear Mark, but I mean which configuration is working succesfully in their network. I am currently using this config: bba-group pppoe TEST virtual-template 1 sessions per-mac limit 2 sessions per-vlan limit 5000 sessions per-vc throttle 15 30 300 sessions per-mac throttle 15 30 300 sessions auto cleanup On Mon, Sep 24, 2012 at 4:32 AM, Sean Lazar wrote: > http://lmgtfy.com/?q=site%3Acisco.com+ios+broadband+aggregation+guide > > On 9/23/12 1:50 PM, Shahab Vahabzadeh wrote: > > why joking Mark? > > > > On Mon, Sep 24, 2012 at 12:19 AM, Mark Gauvin wrote: > > > >> You are joking I hope > >> > >> Sent from my iPhone > >> > >> On 2012-09-23, at 3:38 PM, "Shahab Vahabzadeh" > > >> wrote: > >> > >>> Dear Paul, > >>> Thanks for you reply, May I have those optimization knobs for > >>> virtual-template and throttles? > >>> Maybe looking into your configurations help me in this field. > >>> I will look for the service provider image too. > >>> Thanks > >>> > >>> On Sun, Sep 23, 2012 at 11:17 PM, PC wrote: > >>> > >>>> For this application, you may wish to consider the service provider > >> images. > >>>> The latest 15.x(S) image works, as it is the derivative of what was > >>>> formerly the service-provider oriented 12.2(SRx) images. > >>>> > >>>> However, it's unlikely to drop steady state CPU, but it may contain > some > >>>> optimizations for concurrent PPP (re)negotiations on the G2 platform > >> during > >>>> session recovery. > >>>> > >>>> PPPoE will generally handle more users on ethernet as it is easier to > >> push > >>>> packets on when not dealing with the ATM encapsulations, but to what > >> extent > >>>> this holds true on the 7200, I can't tell you for sure. > >>>> > >>>> I'd also read the broadband aggregation guide under the IOS > >> documentation > >>>> on cisco.com, and tune all the knobs that may help you, there are > some > >>>> pointers on what items on virtual-templates are punitive in > performance, > >>>> other optional items such as disabling SNMP counters on virtual access > >>>> interfaces to reduce cpu usage, and other items that may help little > by > >>>> little. There are also various knobs to throttle PPPoE renegotiation > >> rates > >>>> during recovery. > >>>> > >>>> I wish you luck (and consider getting another and/or bigger router to > >>>> split the load). > >>>> > >>>> On Sun, Sep 23, 2012 at 1:23 PM, Shahab Vahabzadeh < > >>>> sh.vahabzadeh at gmail.com> wrote: > >>>> > >>>>> Which software you used before for them? > >>>>> > >>>>> On Sun, Sep 23, 2012 at 10:43 PM, Rinse Kloek < > >> rinse.kloek at isp.solcon.nl > >>>>>> wrote: > >>>>>> 6000 PPP users on a NPE-G2 is way too much imho. Currently we do no > >> more > >>>>>> than 3000 users on a NPE-G2 with PPPoA. (Max cpu 50%). > >>>>>> 5 years ago, we did about 5000 users on a NPE-G2, but as traffic > >> ratio's > >>>>>> grow each year the maximum users a NPE-G2 can handle will drop each > >>>>> year. > >>>>>> Don't forget an NPE-G2 is a software based plaform, so traffic > >>>>> forwarding > >>>>>> is done in software CPU. > >>>>>> > >>>>>> regards, > >>>>>> Rinse Kloek > >>>>>> Op 23-9-2012 20:51, Shahab Vahabzadeh schreef: > >>>>>> > >>>>>>> Hello everybody, > >>>>>>> I am using C7206 VXR NPE-G2 routers as BRAS in my network and the > >>>>> current > >>>>>>> IOS is *c7200p-adventerprisek9-mz.**124-24.T.bin* on them. > >>>>>>> Also their memory upgraded to 2GB instead of 1GB. > >>>>>>> And I have near 6500 online user on each of my BRAS and there is no > >>>>>>> speciefic feature except aaa with radius and ordinary features. > >>>>>>> There router is also terminating dot1q too because my PSTN centers > >>>>> traffic > >>>>>>> comes through dot1q vlans to BRAS es. > >>>>>>> I think I have some problem with current IOS, My CPU Usage is > >> abnormal > >>>>> and > >>>>>>> Its near %70 or %80. > >>>>>>> And when I have a network problem and some of PSTN centers goes > down > >>>>> CPU > >>>>>>> go > >>>>>>> to %99 and it gets problem to recovery. > >>>>>>> Do you know any good IOS for me as a service provider to use? > >>>>>>> I heard that some service providers have near 8000 online user on > >> 7206. > >>>>>>> Thanks > >>>>>>> > >>>>>>> > >>>>> > >>>>> -- > >>>>> Regards, > >>>>> Shahab Vahabzadeh, Network Engineer and System Administrator > >>>>> > >>>>> Cell Phone: +1 (415) 871 0742 > >>>>> PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 > >> BF90 > >>>> > >>> > >>> -- > >>> Regards, > >>> Shahab Vahabzadeh, Network Engineer and System Administrator > >>> > >>> Cell Phone: +1 (415) 871 0742 > >>> PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 > BF90 > > > > > > -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 From jako.andras at eik.bme.hu Mon Sep 24 07:04:07 2012 From: jako.andras at eik.bme.hu (=?ISO-8859-15?Q?J=C1K=D3_Andr=E1s?=) Date: Mon, 24 Sep 2012 09:04:07 +0200 (CEST) Subject: Big Temporary Networks In-Reply-To: References: <20276810.25170.1347812577275.JavaMail.root@benjamin.baylink.com> <50586620.6080702@necom830.hpcl.titech.ac.jp> <505973A4.90705@necom830.hpcl.titech.ac.jp> <505A40CD.8030701@necom830.hpcl.titech.ac.jp> <505A7033.6040807@necom830.hpcl.titech.ac.jp> <505A8E76.3030800@necom830.hpcl.titech.ac.jp> <505A9DC8.2040508@tiggee.com> <505AB5E1.7080204@necom830.hpcl.titech.ac.jp> <00b301cd975f$2ee354b0$8ca9fe10$@tndh.net> <505BE509.1000008@necom830.hpcl.titech.ac.jp> Message-ID: > > just a small comment: As far as I understand "AP isolation" doesn't work > > if you don't have a WLAN controller but do have more than one APs. E.g. in > > the following setup > > > > ap1--sw1--sw2--ap2 > > > > with "AP isolation" turned on, clients associated to ap1 cannot > > communicate directly with other clients associated to ap1, however they > > can communicate directly with those associated to ap2. Broadcast from > > ap1's clients does also get to all clients at ap2. > > Hi Andr?s, > > This is one place where Cisco's "switchport protected" comes in handy. Yes, but only as long as all APs are connected to the same switch, as I understand. (That's why I put two switches in the example above.) > You can get the same effect with other brands. For example, in one > on-the-cheap 5-AP hotspot I did, I vlaned the APs (using an older > 802.1q capable switch) back to a Linux bridge with "ebtables --insert > FORWARD --jump DROP". The Linux bridge was also the default router out > of the wlan, so anything *to* the router worked but anything that > would be forwarded was dropped instead. Works great. Nice, that should do the trick with multiple switches too. Regards, Andr?s From jloiacon at csc.com Mon Sep 24 12:48:19 2012 From: jloiacon at csc.com (Joe Loiacono) Date: Mon, 24 Sep 2012 08:48:19 -0400 Subject: Real world sflow vs netflow? In-Reply-To: References: <50012E21.4060802@bromirski.net> <4D7095F3-6FA5-4507-AA49-D5192BA58437@arbor.net> <57755E40-54AA-47F1-903D-58B64E22577C@tcb.net> <6A181F19-EB7B-44D2-AFAE-0B58055AE574@arbor.net> Message-ID: Peter Phaal wrote on 09/23/2012 12:23:57 PM: > Exporting packet oriented measurements doesn't mean that you have to > loose ingress/egress interface data. In the specific example being > discussed (sFlow export), detailed forwarding information from the > router forwarding plane is exported with each sampled packet header > (full AS-path if you are using BGP). Wrt AS-path, I don't get how this happens. Since this is important to this community, could you explain? Thanks, Joe From jeroen at unfix.org Mon Sep 24 13:10:10 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 24 Sep 2012 15:10:10 +0200 Subject: Real world sflow vs netflow? In-Reply-To: References: <50012E21.4060802@bromirski.net> <4D7095F3-6FA5-4507-AA49-D5192BA58437@arbor.net> <57755E40-54AA-47F1-903D-58B64E22577C@tcb.net> <6A181F19-EB7B-44D2-AFAE-0B58055AE574@arbor.net> Message-ID: <50605BB2.30905@unfix.org> On 2012-09-24 14:48 , Joe Loiacono wrote: > Peter Phaal wrote on 09/23/2012 12:23:57 PM: > >> Exporting packet oriented measurements doesn't mean that you have to >> loose ingress/egress interface data. Note that you get these in NetFlow too. Depends on which version you pick or how you combine your template and of course if the hard and software allows it, but it is there. > In the specific example being >> discussed (sFlow export), detailed forwarding information from the >> router forwarding plane is exported with each sampled packet header >> (full AS-path if you are using BGP). > > Wrt AS-path, I don't get how this happens. Since this is important to this > community, could you explain? As sFlow runs on the same box that knows the BGP tables the packets sflow packets get that information too. No magic there. This can also be done with NetFlow/IPFIX though, as shown in: http://www.pmacct.net/building_traffic_matrices_n49.pdf thus by combining a BGP feed with the NetFlow/IPFIX feed. There is of course a small chance in such a setup that the tables mismatch and is not the same as the router would have made it. Then again with sFlow you typically sample and thus you have windows of loss anyway... Note that there are IPFIX/NetFlow enabled boxes which also include BGP details if one is worried about that, though if your path changes mid-flow you have a slight error there too again. Greets, Jeroen From peter.phaal at gmail.com Mon Sep 24 14:39:26 2012 From: peter.phaal at gmail.com (Peter Phaal) Date: Mon, 24 Sep 2012 07:39:26 -0700 Subject: Real world sflow vs netflow? In-Reply-To: References: <50012E21.4060802@bromirski.net> <4D7095F3-6FA5-4507-AA49-D5192BA58437@arbor.net> <57755E40-54AA-47F1-903D-58B64E22577C@tcb.net> <6A181F19-EB7B-44D2-AFAE-0B58055AE574@arbor.net> Message-ID: On Mon, Sep 24, 2012 at 5:48 AM, Joe Loiacono wrote: > Peter Phaal wrote on 09/23/2012 12:23:57 PM: > > >> Exporting packet oriented measurements doesn't mean that you have to >> loose ingress/egress interface data. In the specific example being >> discussed (sFlow export), detailed forwarding information from the >> router forwarding plane is exported with each sampled packet header >> (full AS-path if you are using BGP). > > > Wrt AS-path, I don't get how this happens. Since this is important to this > community, could you explain? Sure. I think it's worth discussing in some detail since this is relevant to the NANOG community and it is important to understand how it works. When a switch/router decides to sample a packet it records the ingress/egress interfaces and accumulates information about how it decided to forward the packet by examining its FIB tables. Each packet may take a different path, some may by switched at layer 2, others may be forwarded based on a local routing protocol like OSPF, and still others may be forwarded based on BGP. The forwarding data associated with each packet is irregular (e.g. a switched packet won't have BGP information), and so sFlow doesn't try to flatten it into tables, but instead encodes the data using XDR (RFC 1832), expressing each element of the forwarding decision as a tag, length, value encoded structure that contains attributes relevant to each type of forwarding decision. The AS-Path itself is a fairly complicated, variable length structure and again, this is encoded as XDR. These are all optional fields in sFlow, so you should check with your switch vendor to see which ones they support. If they don't currently export the FIB data you are looking for, you should ask them to upgrade their agent because as Jeroen pointed out, populating each structure is just an extra lookup performed by the management CPU on the router. FYI I have see full AS-path data exported from a busy 100G router, so there should be no problem collecting these measurements in a production setting. The following extract from the sFlow version 5 specification shows what forwarding information is exported: /* Extended Flow Data Extended data types provide supplimentary information about the sampled packet. All applicable extended flow records should be included with each flow sample. */ /* Extended Switch Data */ /* opaque = flow_data; enterprise = 0; format = 1001 */ /* Note: For untagged ingress ports, use the assigned vlan and priority of the port for the src_vlan and src_priority values. For untagged egress ports, use the values for dst_vlan and dst_priority that would have been placed in the 802.Q tag had the egress port been a tagged member of the VLAN instead of an untagged member. */ struct extended_switch { unsigned int src_vlan; /* The 802.1Q VLAN id of incoming frame */ unsigned int src_priority; /* The 802.1p priority of incoming frame */ unsigned int dst_vlan; /* The 802.1Q VLAN id of outgoing frame */ unsigned int dst_priority; /* The 802.1p priority of outgoing frame */ } /* IP Route Next Hop ipForwardNextHop (RFC 2096) for IPv4 routes. ipv6RouteNextHop (RFC 2465) for IPv6 routes. */ typedef next_hop address; /* Extended Router Data */ /* opaque = flow_data; enterprise = 0; format = 1002 */ struct extended_router { next_hop nexthop; /* IP address of next hop router */ unsigned int src_mask_len; /* Source address prefix mask (expressed as number of bits) */ unsigned int dst_mask_len; /* Destination address prefix mask (expressed as number of bits) */ } enum as_path_segment_type { AS_SET = 1, /* Unordered set of ASs */ AS_SEQUENCE = 2 /* Ordered set of ASs */ } union as_path_type (as_path_segment_type) { case AS_SET: unsigned int as_set<>; case AS_SEQUENCE: unsigned int as_sequence<>; } /* Extended Gateway Data */ /* opaque = flow_data; enterprise = 0; format = 1003 */ struct extended_gateway { next_hop nexthop; /* Address of the border router that should be used for the destination network */ unsigned int as; /* Autonomous system number of router */ unsigned int src_as; /* Autonomous system number of source */ unsigned int src_peer_as; /* Autonomous system number of source peer */ as_path_type dst_as_path<>; /* Autonomous system path to the destination */ unsigned int communities<>; /* Communities associated with this route */ unsigned int localpref; /* LocalPref associated with this route */ } From jra at baylink.com Mon Sep 24 16:01:07 2012 From: jra at baylink.com (Jay Ashworth) Date: Mon, 24 Sep 2012 12:01:07 -0400 (EDT) Subject: POLL: 802.1x deployment Message-ID: <664863.26368.1348502467243.JavaMail.root@benjamin.baylink.com> I'm tech-reading an upcoming book, and it makes the implication that 802.1x is not very widely deployed... which seems possibly an overly narrow view of the Real World. If you regularly use one or more 802.1x protected networks, could you take a moment to reply off-list, and tell me the size of the network (homelab, smb, enterprise, carrier), and, if you know, how long 802.1x has been deployed there? I'm also interested in whether any network you use has dropped .1x. I'll summarize to the list if there's interest. Thanks. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From tore.anderson at redpill-linpro.com Mon Sep 24 16:57:35 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Mon, 24 Sep 2012 18:57:35 +0200 Subject: Throw me a IPv6 bone (sort of was IPv6 ignorance) In-Reply-To: <505DDFF9.7030302@redpill-linpro.com> References: <505C6C2D.7030204@amplex.net> <505C6E60.3000806@unfix.org> <505CC31C.3040709@amplex.net> <505D70D3.6070702@redpill-linpro.com> <505DBBBE.1030804@amplex.net> <505DDFF9.7030302@redpill-linpro.com> Message-ID: <506090FF.30001@redpill-linpro.com> * Tore Anderson > I would pay very close attention to MAP/4RD. FYI, Mark Townsley had a great presentation about MAP at RIPE65 today, it's 35 minutes you won't regret spending: https://ripe65.ripe.net/archives/video/5 https://ripe65.ripe.net/presentations/91-townsley-map-ripe65-ams-sept-24-2012.pdf Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From excelsio at gmx.com Mon Sep 24 16:32:33 2012 From: excelsio at gmx.com (Michael Muller) Date: Mon, 24 Sep 2012 18:32:33 +0200 Subject: POLL: 802.1x deployment In-Reply-To: <664863.26368.1348502467243.JavaMail.root@benjamin.baylink.com> References: <664863.26368.1348502467243.JavaMail.root@benjamin.baylink.com> Message-ID: <50608B21.9010103@gmx.com> Hi, I?d suggest you to ask the guys from Enterasys mailing list. Sorry, couldn?t resist ;-) Michael P.S.: No, I don?t have 802.1x enabled on LAN for my users sitting in their offices. From jloiacon at csc.com Mon Sep 24 18:19:58 2012 From: jloiacon at csc.com (Joe Loiacono) Date: Mon, 24 Sep 2012 14:19:58 -0400 Subject: Real world sflow vs netflow? In-Reply-To: References: <50012E21.4060802@bromirski.net> <4D7095F3-6FA5-4507-AA49-D5192BA58437@arbor.net> <57755E40-54AA-47F1-903D-58B64E22577C@tcb.net> <6A181F19-EB7B-44D2-AFAE-0B58055AE574@arbor.net> Message-ID: Peter Phaal wrote on 09/24/2012 10:39:26 AM: > When a switch/router decides to sample a packet it records the > ingress/egress interfaces and accumulates information about how it > decided to forward the packet by examining its FIB tables. Each packet > may take a different path, some may by switched at layer 2, others may > be forwarded based on a local routing protocol like OSPF, and still > others may be forwarded based on BGP. OK, Well I guess I was thinking sFlow was primarily a switch oriented technology versus on a layer-3 peering router. From peter.phaal at gmail.com Mon Sep 24 18:52:28 2012 From: peter.phaal at gmail.com (Peter Phaal) Date: Mon, 24 Sep 2012 11:52:28 -0700 Subject: Real world sflow vs netflow? In-Reply-To: References: <50012E21.4060802@bromirski.net> <4D7095F3-6FA5-4507-AA49-D5192BA58437@arbor.net> <57755E40-54AA-47F1-903D-58B64E22577C@tcb.net> <6A181F19-EB7B-44D2-AFAE-0B58055AE574@arbor.net> Message-ID: On Mon, Sep 24, 2012 at 11:19 AM, Joe Loiacono wrote: > OK, Well I guess I was thinking sFlow was primarily a switch oriented > technology versus on a layer-3 peering router. The sFlow technology is a good fit for any device that performs a packet forwarding function (including routers) and the sFlow.org web site maintains a list of switches and routers that implement the technology, http://sflow.org/products/network.php However, you are correct that today sFlow is more broadly implemented in switching platforms than routing platforms, but I expect this will change as network speeds increase and platforms converge. From jrhett at netconsonance.com Mon Sep 24 20:06:57 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Mon, 24 Sep 2012 13:06:57 -0700 Subject: the economies of scale of a Worldcon, and how to make this topic relevant to Nanog In-Reply-To: References: <33150791.25988.1348440516118.JavaMail.root@benjamin.baylink.com> Message-ID: <3576C10A-CA6F-4F66-A6DB-2B06DD647FC3@netconsonance.com> On Sep 23, 2012, at 4:42 PM, Joe Hamelin wrote: > PSAV is the company. I just installed about 20 Cisco WiFi radios at the > Doubletree (a Hilton prop) at Sea-Tac. These covered only the convention > space, conf rooms, ball rooms, whatnot. It would seem that the hotel is > running their own system in the other public areas such as check-in, coffee > shops and bars. > > Mostly they were well placed, often in the same spot as the existing > radios. But I'd never throw a geek-con at that system. Yeah, I just stayed at SeaTac a month back and had to shift to working offline and syncing upward, since I was getting modem-like speed through the network there. I think I ended up using my phone more than their wifi :( -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. From aid at logic.org.uk Mon Sep 24 20:11:12 2012 From: aid at logic.org.uk (Adrian Bool) Date: Mon, 24 Sep 2012 21:11:12 +0100 Subject: Throw me a IPv6 bone (sort of was IPv6 ignorance) In-Reply-To: <506090FF.30001@redpill-linpro.com> References: <505C6C2D.7030204@amplex.net> <505C6E60.3000806@unfix.org> <505CC31C.3040709@amplex.net> <505D70D3.6070702@redpill-linpro.com> <505DBBBE.1030804@amplex.net> <505DDFF9.7030302@redpill-linpro.com> <506090FF.30001@redpill-linpro.com> Message-ID: <7B6B102F-E054-4D62-B7D3-20D859C3A33A@logic.org.uk> On 24 Sep 2012, at 17:57, Tore Anderson wrote: > * Tore Anderson > >> I would pay very close attention to MAP/4RD. > > FYI, Mark Townsley had a great presentation about MAP at RIPE65 today, > it's 35 minutes you won't regret spending: > > https://ripe65.ripe.net/archives/video/5 > https://ripe65.ripe.net/presentations/91-townsley-map-ripe65-ams-sept-24-2012.pdf Interesting video; thanks for posting the link. This does seem a strange proposal though. My understanding from the video is that it is a technology to help not with the deployment of IPv6 but with the scarcity of IPv4 addresses. In summary; it simply allows a number of users (e.g. 1024) to share a single public IPv4 address. My feeling is therefore, why are the IPv4 packets to/from the end user being either encapsulated or translated into IPv6 - why do they not simply remain as IPv4 packets? If the data is kept as IPv4, this seems to come down to just two changes, * The ISP's router to which the user connects being able to route packets on routes that go beyond the IP address and into the port number field of TCP/UDP. * A CE router being instructed to constrain itself to using a limited set of ports on the WAN side in its NAT44 implementation. Why all the IPv6 shenanigans complicating matters? Cheers, aid From ras at e-gerbil.net Mon Sep 24 21:25:47 2012 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Mon, 24 Sep 2012 16:25:47 -0500 Subject: Real world sflow vs netflow? In-Reply-To: References: <4D7095F3-6FA5-4507-AA49-D5192BA58437@arbor.net> <57755E40-54AA-47F1-903D-58B64E22577C@tcb.net> <6A181F19-EB7B-44D2-AFAE-0B58055AE574@arbor.net> Message-ID: <20120924212547.GP66560@gerbil.cluepon.net> On Mon, Sep 24, 2012 at 11:52:28AM -0700, Peter Phaal wrote: > On Mon, Sep 24, 2012 at 11:19 AM, Joe Loiacono wrote: > > OK, Well I guess I was thinking sFlow was primarily a switch oriented > > technology versus on a layer-3 peering router. > > The sFlow technology is a good fit for any device that performs a > packet forwarding function (including routers) and the sFlow.org web > site maintains a list of switches and routers that implement the > technology, Minus a whole pile of babble from people who don't actually know what a router vs layer 3 switch is...The difference at this point is mostly that NetFlow has provisions to allow exporting all data about an ENTIRE flow, whereas sFlow is designed to only take statistical samples for overall traffic analysis. Tracking an entire flow is much harder, it requires keeping state on the router, so if you only care about overall traffic analysis sampling is just fine. Originally sFlow introduced features like raw packet export (including layer 2 headers), and extensible formatting, which NetFlow later copied with v9 and v10/IPFIX. At this point they're "mostly" on the same footing technically, though sFlow does have a "counter export" feature which is essentially a "push" version of polling SNMP IF-MIB counters. Only Cisco and Juniper are still trying to push NetFlow though, sFlow has been adopted by nearly ehter other vendor at this point. Even some Juniper products, like EX (which is really Marvell ASICs with a JUNOS wrapper), support sFlow only. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From mike at mikejones.in Mon Sep 24 21:42:46 2012 From: mike at mikejones.in (Mike Jones) Date: Mon, 24 Sep 2012 22:42:46 +0100 Subject: Throw me a IPv6 bone (sort of was IPv6 ignorance) In-Reply-To: <7B6B102F-E054-4D62-B7D3-20D859C3A33A@logic.org.uk> References: <505C6C2D.7030204@amplex.net> <505C6E60.3000806@unfix.org> <505CC31C.3040709@amplex.net> <505D70D3.6070702@redpill-linpro.com> <505DBBBE.1030804@amplex.net> <505DDFF9.7030302@redpill-linpro.com> <506090FF.30001@redpill-linpro.com> <7B6B102F-E054-4D62-B7D3-20D859C3A33A@logic.org.uk> Message-ID: On 24 September 2012 21:11, Adrian Bool wrote: > > On 24 Sep 2012, at 17:57, Tore Anderson wrote: > >> * Tore Anderson >> >>> I would pay very close attention to MAP/4RD. >> >> FYI, Mark Townsley had a great presentation about MAP at RIPE65 today, >> it's 35 minutes you won't regret spending: >> >> https://ripe65.ripe.net/archives/video/5 >> https://ripe65.ripe.net/presentations/91-townsley-map-ripe65-ams-sept-24-2012.pdf > > Interesting video; thanks for posting the link. > > This does seem a strange proposal though. My understanding from the video is that it is a technology to help not with the deployment of IPv6 but with the scarcity of IPv4 addresses. In summary; it simply allows a number of users (e.g. 1024) to share a single public IPv4 address. > > My feeling is therefore, why are the IPv4 packets to/from the end user being either encapsulated or translated into IPv6 - why do they not simply remain as IPv4 packets? > > If the data is kept as IPv4, this seems to come down to just two changes, > > * The ISP's router to which the user connects being able to route packets on routes that go beyond the IP address and into the port number field of TCP/UDP. > * A CE router being instructed to constrain itself to using a limited set of ports on the WAN side in its NAT44 implementation. > > Why all the IPv6 shenanigans complicating matters? While you could do something similar without the encapsulation this would require that every router on your network support routing on port numbers, by using IPv6 packets it can be routed around your network by existing routers. And it's not like anyone is going to be deploying such a system without also deploying IPv6, so it's not adding any additional requirements doing it that way. - Mike From aid at logic.org.uk Mon Sep 24 22:34:30 2012 From: aid at logic.org.uk (Adrian Bool) Date: Mon, 24 Sep 2012 23:34:30 +0100 Subject: Throw me a IPv6 bone (sort of was IPv6 ignorance) In-Reply-To: References: <505C6C2D.7030204@amplex.net> <505C6E60.3000806@unfix.org> <505CC31C.3040709@amplex.net> <505D70D3.6070702@redpill-linpro.com> <505DBBBE.1030804@amplex.net> <505DDFF9.7030302@redpill-linpro.com> <506090FF.30001@redpill-linpro.com> <7B6B102F-E054-4D62-B7D3-20D859C3A33A@logic.org.uk> Message-ID: <8BEEBCDA-B6FA-4407-BF95-E122B26F4916@logic.org.uk> On 24 Sep 2012, at 22:42, Mike Jones wrote: > While you could do something similar without the encapsulation this > would require that every router on your network support routing on > port numbers, Well, not really. As the video pointed out, the system was designed to leverage hierarchy to reduce routing complexity. Using the hierarchy, port number routing is only required at the level where a routes diverge on a port basis - which if you're being sensible about such a deployment would only be at the edge of the access layer. aid From mitch at illuminati.org Mon Sep 24 22:52:48 2012 From: mitch at illuminati.org (John Mitchell) Date: Mon, 24 Sep 2012 23:52:48 +0100 Subject: IPv6 Address allocation best practises for sites. Message-ID: <5060E440.9020503@illuminati.org> Question about what other service/network providers are doing in relation to allocation of addresses for websites. With IPv6 starting to trickle its way in, what is considered the industry best practise now for IP(v6) addresses bonded to websites. In the past the standard practise was to have a single IPv4 address shared between multiple sites using a name based virtual host directive in Apache/IIS, unless of course the site was SSL in which case it normally needed a IP of its own (unless you had a client who was happy to only support SSL on IE7+ browsers with SNI). Does the best practise switch to now using one IPv6 per site, or still the same one IPv6 for multi-sites? - Mitch From bill at herrin.us Mon Sep 24 23:37:31 2012 From: bill at herrin.us (William Herrin) Date: Mon, 24 Sep 2012 19:37:31 -0400 Subject: IPv6 Address allocation best practises for sites. In-Reply-To: <5060E440.9020503@illuminati.org> References: <5060E440.9020503@illuminati.org> Message-ID: On Mon, Sep 24, 2012 at 6:52 PM, John Mitchell wrote: > Question about what other service/network providers are doing in relation to > allocation of addresses for websites. > > With IPv6 starting to trickle its way in, what is considered the industry > best practise now for IP(v6) addresses bonded to websites. In the past the > standard practise was to have a single IPv4 address shared between multiple > sites using a name based virtual host directive in Apache/IIS, unless of > course the site was SSL in which case it normally needed a IP of its own > (unless you had a client who was happy to only support SSL on IE7+ browsers > with SNI). > > Does the best practise switch to now using one IPv6 per site, or still the > same one IPv6 for multi-sites? Hi John, Given web browser issues with javascript and DNS changes (see DNS pinning) I'm not sure why you wouldn't want to pick a configuration strategy where the IP could follow the site name from server to server. I'm not in the multi-site web server business any more. The stuff I build these days needs a load balancer. If I was I suspect I'd start at routing a /64 to each web server. Then I'd take a long hard look at whether it was a better plan to put all the multiply-addressed servers on a single /64 and let neighbor discovery find the right one for each site, or to implement /64''s per server and put /128 overrides in the adjacent router for sites that move from the original server (because the customer upgraded of course). Then I'd consider whether to route a /112 to each server instead of a /64 and assign a single /64 for the set of web servers. I don't know of any specific problem with routing 2^64 addresses to a single host but I also can't imagine hosting more than 65,000 sites on a single server. So, not a BCP but perhaps some food for thought when choosing your approach. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From johnl at iecc.com Mon Sep 24 23:47:18 2012 From: johnl at iecc.com (John Levine) Date: 24 Sep 2012 23:47:18 -0000 Subject: IPv6 Address allocation best practises for sites. In-Reply-To: <5060E440.9020503@illuminati.org> Message-ID: <20120924234718.86240.qmail@joyce.lan> >Does the best practise switch to now using one IPv6 per site, or still >the same one IPv6 for multi-sites? As I've been migrating my sites to IPv6, each site gets its own IP. Works great. I did find that I needed to improve my tools so I could track the individual IP addresses and assign the appropriate DNS names to them, as I took several dozen (it's a small machine) sites and put them on IPv6. Other than not wanting to go to the effort to change all the config files, it's hard to think of a reason to share IPv6 addresses for anything. Virtual hosts were specifically invented to conserve IPv4 addresses; they don't provide any added function. R's, John PS: Well, there is my spider trap at http://web.sp.am which would be hard to do without using a shared IP. But that's perverse. From dot at dotat.at Mon Sep 24 23:56:13 2012 From: dot at dotat.at (Tony Finch) Date: Tue, 25 Sep 2012 00:56:13 +0100 Subject: IPv6 Address allocation best practises for sites. In-Reply-To: References: <5060E440.9020503@illuminati.org> Message-ID: William Herrin wrote: > > but I also can't imagine hosting more than 65,000 sites on a single > server. Demon's homepages service was based on IPv4 virtual hosting and had IIRC a /16 and two /18s allocated to it. It was a single web server with a few reverse proxies that took most of the load and that also had all the IP addresses. The Irix version used a cunning firewall configuration to accept connections to all the addresses without stupid numbers of virtual interfaces; the BSD version used a kernel hack. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/12071 On the web server we stuffed the IP address into the filesystem path name to find the document root. (Or used various evil hacks to map the IP address to a canonical virtual server host name before stuffing the latter in the path.) Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From owen at delong.com Tue Sep 25 01:10:01 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Sep 2012 18:10:01 -0700 Subject: Throw me a IPv6 bone (sort of was IPv6 ignorance) In-Reply-To: <505CC31C.3040709@amplex.net> References: <505C6C2D.7030204@amplex.net> <505C6E60.3000806@unfix.org> <505CC31C.3040709@amplex.net> Message-ID: You can avoid the giant NAT box as long as you don't have to add a new customer for whom you don't have an available IPv4 address. At that point, you either have to implement the giant NAT box for your future (and possibly an increasing percentage of your existing) customers, or, stop adding new customers. In terms of the CPE situation, until you solve that, IPv6-only isn't going to work for them, either, so the CPE issues simply can't be avoided no matter what. We need to find a way to get the vendors to make that float. Owen On Sep 21, 2012, at 12:42 , Mark Radabaugh wrote: > On 9/21/12 9:40 AM, Jeroen Massar wrote: >> On 2012-09-21 15:31 , Mark Radabaugh wrote: >>> The part of IPv6 that I am unclear on and have not found much >>> documentation on is how to run IPv6 only to end users. Anyone care to >>> point me in the right direction? >>> >>> Can we assign IPv6 only to end users? What software/equipment do we >>> need in place as a ISP to ensure these customers can reach IPv4 only hosts? >>> >>> The Interwebs are full of advice on setting up IPv6 tunnels for your >>> house (nice but...). There is lots of really old documentation out >>> there for IPv6 mechanisms that are depreciated or didn't fly. >>> >>> What is current best practice? >> The IETF BCP is to deploy Dual Stack, thus both IPv4 and IPv6 at the >> same time. >> >> When that is not possible, as you ran out of IPv4 addresses, you should >> look at Dual Stack Lite (DS Lite) eg as supplied by ISC's AFTR and other >> such implementations. >> >> Depending on your business model you can of course also stick everybody >> behind a huge NAT or require them to use HTTP proxies to get to the >> Internet as most people define it... >> >> >> Do note that if you are asking any of these questions today you are >> years late in reading up and you missed your chance to be prepared for >> this in all kinds of ways. >> >> Greets, >> Jeroen >> > We can already do dual stack - that's not really a problem. I was really rather hoping to avoid the giant NAT box. I'll take a look at DS Lite and or NAT64/DNS64 and see if that makes any sense. > > Dual stack isn't all that hard to deploy in the enterprise, perhaps even IPv6 only with NAT for backward compatibility. > > Running dual stack to residential consumers still has huge issues with CPE. It's not an environment where we have control over the router the customer picks up at Walmart. There is really very little point in spending a lot of resources on something the consumer can't currently use. I don't think saying we missed the boat really applies - and the consumer CPE ship is sinking at the dock. > > > -- > Mark Radabaugh > Amplex > > mark at amplex.net 419.837.5015 > From jsw at inconcepts.biz Tue Sep 25 04:08:15 2012 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Tue, 25 Sep 2012 00:08:15 -0400 Subject: IPv6 Address allocation best practises for sites. In-Reply-To: <5060E440.9020503@illuminati.org> References: <5060E440.9020503@illuminati.org> Message-ID: On Mon, Sep 24, 2012 at 6:52 PM, John Mitchell wrote: > Does the best practise switch to now using one IPv6 per site, or still the > same one IPv6 for multi-sites? Certainly it would be nice to have IPv6 address per vhost. In many cases, this will be practical. It also sometimes will NOT be practical. Imagine that I am one of the rather clueless hosting companies who are handing out /64 networks to any customer who asks for one, and using NDP to find the machine using each address in the /64. Churn problems aside, if you have any customer doing particularly dense virtual hosting, say a few thousand IPv6 addresses on his one or more machines, then he will use up the whole NDP table for just himself. You probably won't want to be a customer on the same layer-3 device as that guy. Now that there might be dozens of VMs per physical server and maybe 40 physical servers per each top-of-rack device, you can quickly exhaust all of your NDP entries even with normal, legitimate uses like www virtual hosting. Now imagine the hosting company has decided the "stacking" trend is a good idea, and stacked up a row of 10 EX4200s so they can all share the same configuration, uplinks, etc. They also share the same NDP table, so it will be quite easy to run out of NDP (there is only room for a few thousand entries) not just on one top-of-rack switch, but on the whole row. Further, imagine you decided to use a 6500 for a room full of customers, or even your whole datacenter, which will often work just fine for IPv4. Suddenly it won't for IPv6, because each customer may want to make hundreds of NDP entries for his various virtual-hosts. Just one busy customer with a lot of virtual hosting will run out a resource shared by every other customer. So yes, having an IPv6 address per each www virtual-host is certainly a nice idea. If you have to use NDP to get your addresses to your web server, though, it might not be practical. It certainly will be foolish in a "dedicated server" type of environment where you are renting individual machines or VMs and not owning your own layer-3 box. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From nanog-poster at axu.tm Tue Sep 25 05:20:01 2012 From: nanog-poster at axu.tm (Aleksi Suhonen) Date: Tue, 25 Sep 2012 08:20:01 +0300 Subject: IPv6 Address allocation best practises for sites. Message-ID: <50613F01.4000501@axu.tm> Morning, The way to allocate IPv6 addresses per website depends more on the technologies already in use at the hosting site. An existing hoster will move slowly to any alternative method. I predict a bigger, faster change in the way medium sized sites do load balancing. IPv6 allows hosters to go back to DNS round robin based load balancing, which still works much better than often reported. It became an unfashionable way to do things because there weren't enough IPv4 addresses for everyone to be doing it, but this limitation won't be an issue in IPv6. I had a customer case a couple of years back where the client tried it out and was amazed at the results. In that particular case each server announced 2 /128s to the closest router, one with a better metric and the other with a worse metric. So during failovers, one server got twice the normal traffic until that DNS entry was pulled from the round robin set. Said client went back to "the old ways" tho because they couldn't do the same thing on IPv4 and they didn't want to have two different load balancing methods for two different IP versions. They are very fervent believers in the KISS principle. They are now waiting and hoping for the IPv4 traffic to die down and IPv6 traffic to pick up so that they can start doing things on IPv6's terms instead. :-) Hoping against all odds that they won't have to wait long, -- Aleksi Suhonen / Axu TM Oy Internetworking Consulting Cellular: +358 45 670 2048 World Wide Web: www.axu.tm From tore.anderson at redpill-linpro.com Tue Sep 25 06:56:03 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 25 Sep 2012 08:56:03 +0200 Subject: Throw me a IPv6 bone (sort of was IPv6 ignorance) In-Reply-To: <8BEEBCDA-B6FA-4407-BF95-E122B26F4916@logic.org.uk> References: <505C6C2D.7030204@amplex.net> <505C6E60.3000806@unfix.org> <505CC31C.3040709@amplex.net> <505D70D3.6070702@redpill-linpro.com> <505DBBBE.1030804@amplex.net> <505DDFF9.7030302@redpill-linpro.com> <506090FF.30001@redpill-linpro.com> <7B6B102F-E054-4D62-B7D3-20D859C3A33A@logic.org.uk> <8BEEBCDA-B6FA-4407-BF95-E122B26F4916@logic.org.uk> Message-ID: <50615583.5010604@redpill-linpro.com> * Adrian Bool > > On 24 Sep 2012, at 22:42, Mike Jones wrote: > >> While you could do something similar without the encapsulation >> this would require that every router on your network support >> routing on port numbers, > > Well, not really. As the video pointed out, the system was designed > to leverage hierarchy to reduce routing complexity. Using the > hierarchy, port number routing is only required at the level where a > routes diverge on a port basis - which if you're being sensible about > such a deployment would only be at the edge of the access layer. While that might be true, the access network would normally be the largest part of an SP's network, when it comes to router count. The access part might have 100s or 1000s of times more routers than the core/border. The cone gets wider the closer to the customer edge you get. Slide 6 illustrates this well. By not doing translation or encapsulation of the IPv4 packets, instead relying on the access routers to natively route based on A+P, we would have made sure that the ISPs that have already deployed IPv6 could not use the technology, and that ISPs that have not yet deployed IPv6 and think the technology looks interesting have a huge incentive to put off the entire project for several years, while they wait for new router products or software images that support A+P to be made available. Not exactly desirable. There are also other problems with the idea - not only do you need the router to be able to forward based on A+P, you would also need to distribute these A+P routes in the network. Which means we would need to update OSPFv2, IS-IS, or whatever else the SP might be using. We would have to update DHCPv4 (both the protocol and the SP's server) too, as there is currently no way it can give you a lease for a "partial" IPv4 address. This would also touch on layer 2 devices doing layer 3 inspection and policing, such as DHCP Snooping. You'd also need to update ARP, as there is currently no way to send an "ARP who-has 192.0.2.1 port 1234" request, which you would have to do. The amount of changes required is so large that you might as well call the result IPv4? instead of MAP. Finally, operating a single-stack network (regardless of that single stack being IPv4 or IPv6) is much preferable to operating a dual-stack one. Less complexity, less things to trouble-shoot, less things to set up, less things to monitor, less things to train staff in, and so forth. That MAP (and DS-Lite) means single-stack IPv6 in the vast majority of the network is a very desirable trait, in my opinion. Your proposal would remove this benefit, instead we'd end up with a dual-stack IPv4?/IPv6 network. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From brandonwade at icastcenter.com Thu Sep 20 23:57:38 2012 From: brandonwade at icastcenter.com (Brandon Wade) Date: Thu, 20 Sep 2012 18:57:38 -0500 Subject: Announcing APNIC IP's in ARIN region Message-ID: <505BAD72.9070605@icastcenter.com> Hello, I was wondering if there are any problems originating APNIC IP's in the ARIN region through transit providers? I have a Singapore-based prospect who would like to do business with us, but I'm not sure if I'll run into problems originating their IP's in the US - which were assigned to them from APNIC. Best regards, Brandon Wade iCastCenter.com From jeroen at unfix.org Tue Sep 25 08:30:59 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 25 Sep 2012 10:30:59 +0200 Subject: Announcing APNIC IP's in ARIN region In-Reply-To: <505BAD72.9070605@icastcenter.com> References: <505BAD72.9070605@icastcenter.com> Message-ID: <50616BC3.5090601@unfix.org> On 2012-09-21 01:57, Brandon Wade wrote: > Hello, > > I was wondering if there are any problems originating APNIC IP's in the > ARIN region through transit providers? I have a Singapore-based prospect > who would like to do business with us, but I'm not sure if I'll run into > problems originating their IP's in the US - which were assigned to them > from APNIC. As this Internet thing is a global thing, why would that be an issue? (unless it is a spammer outfit of course ;) Greets, Jeroen From web at typo.org Tue Sep 25 09:05:34 2012 From: web at typo.org (Wayne E Bouchard) Date: Tue, 25 Sep 2012 02:05:34 -0700 Subject: Announcing APNIC IP's in ARIN region In-Reply-To: <50616BC3.5090601@unfix.org> References: <505BAD72.9070605@icastcenter.com> <50616BC3.5090601@unfix.org> Message-ID: <20120925090534.GA7293@wakko.typo.org> It presents no technical problem but has always been considered politically inadvisable. I mean, there are multiple registries for a reason that goes beyond mere oranization and load sharing. Increasingly, governments are trying to take more control over packets (there is ever the push for geographic maping mechanisms and so on) and that may introduce potential legal problems in the future, depending on the nation you're in and how paranoid they become. So in short, do what you need to do. Just be aware of sub-optimal. -Wayne On Tue, Sep 25, 2012 at 10:30:59AM +0200, Jeroen Massar wrote: > On 2012-09-21 01:57, Brandon Wade wrote: > > Hello, > > > > I was wondering if there are any problems originating APNIC IP's in the > > ARIN region through transit providers? I have a Singapore-based prospect > > who would like to do business with us, but I'm not sure if I'll run into > > problems originating their IP's in the US - which were assigned to them > > from APNIC. > > As this Internet thing is a global thing, why would that be an issue? > > (unless it is a spammer outfit of course ;) > > Greets, > Jeroen > --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From owen at delong.com Tue Sep 25 09:02:09 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 25 Sep 2012 02:02:09 -0700 Subject: IPv6 Address allocation best practises for sites. In-Reply-To: References: <5060E440.9020503@illuminati.org> Message-ID: <152FD6F6-BE9C-41E6-8305-B5EE68A18232@delong.com> On Sep 24, 2012, at 21:08 , Jeff Wheeler wrote: > On Mon, Sep 24, 2012 at 6:52 PM, John Mitchell wrote: >> Does the best practise switch to now using one IPv6 per site, or still the >> same one IPv6 for multi-sites? > > Certainly it would be nice to have IPv6 address per vhost. In many > cases, this will be practical. > > It also sometimes will NOT be practical. > > Imagine that I am one of the rather clueless hosting companies who are > handing out /64 networks to any customer who asks for one, and using > NDP to find the machine using each address in the /64. Churn problems > aside, if you have any customer doing particularly dense virtual > hosting, say a few thousand IPv6 addresses on his one or more > machines, then he will use up the whole NDP table for just himself. > You probably won't want to be a customer on the same layer-3 device as > that guy. Now that there might be dozens of VMs per physical server > and maybe 40 physical servers per each top-of-rack device, you can > quickly exhaust all of your NDP entries even with normal, legitimate > uses like www virtual hosting. > That's not the best way to stand up /64s for vhosts. If you're smart, the customer gets a /64 for machine addresses (put your interfaces in this /64) and each machine gets a /64 for vHosts (put your vhost addresses on the loopback interface of the applicable machine). Then, you route the /64 to the machine address for the applicable machine and the vhosts never hit your neighbor table. [snip] Deleted a whole bunch of additional reasons you really want to do things the way I suggest above [/snip] Owen From marka at isc.org Tue Sep 25 09:18:08 2012 From: marka at isc.org (Mark Andrews) Date: Tue, 25 Sep 2012 19:18:08 +1000 Subject: Announcing APNIC IP's in ARIN region In-Reply-To: Your message of "Thu, 20 Sep 2012 18:57:38 EST." <505BAD72.9070605@icastcenter.com> References: <505BAD72.9070605@icastcenter.com> Message-ID: <20120925091809.049AA279E8AC@drugs.dv.isc.org> In message <505BAD72.9070605 at icastcenter.com>, Brandon Wade writes: > Hello, > > I was wondering if there are any problems originating APNIC IP's in the > ARIN region through transit providers? I have a Singapore-based prospect > who would like to do business with us, but I'm not sure if I'll run into > problems originating their IP's in the US - which were assigned to them > from APNIC. > > Best regards, > Brandon Wade > iCastCenter.com There should be no problems. -- 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 Tue Sep 25 09:26:41 2012 From: marka at isc.org (Mark Andrews) Date: Tue, 25 Sep 2012 19:26:41 +1000 Subject: Announcing APNIC IP's in ARIN region In-Reply-To: Your message of "Tue, 25 Sep 2012 02:05:34 MST." <20120925090534.GA7293@wakko.typo.org> References: <505BAD72.9070605@icastcenter.com> <50616BC3.5090601@unfix.org> <20120925090534.GA7293@wakko.typo.org> Message-ID: <20120925092641.E006F279E998@drugs.dv.isc.org> In message <20120925090534.GA7293 at wakko.typo.org>, Wayne E Bouchard writes: > It presents no technical problem but has always been considered > politically inadvisable. I mean, there are multiple registries for a > reason that goes beyond mere oranization and load sharing. There are multiple registries because it is easier to deal with someone the speaks you language / is in the same approximate time zone. The SG site has got addresses from APNIC. There is no requirement to connect in the APNIC region. Lots of APNIC sites connect to the rest of the world in the US. > Increasingly, governments are trying to take more control over packets > (there is ever the push for geographic maping mechanisms and so on) > and that may introduce potential legal problems in the future, > depending on the nation you're in and how paranoid they become. > > So in short, do what you need to do. Just be aware of sub-optimal. > > -Wayne > > On Tue, Sep 25, 2012 at 10:30:59AM +0200, Jeroen Massar wrote: > > On 2012-09-21 01:57, Brandon Wade wrote: > > > Hello, > > > > > > I was wondering if there are any problems originating APNIC IP's in the > > > ARIN region through transit providers? I have a Singapore-based prospect > > > who would like to do business with us, but I'm not sure if I'll run into > > > problems originating their IP's in the US - which were assigned to them > > > from APNIC. > > > > As this Internet thing is a global thing, why would that be an issue? > > > > (unless it is a spammer outfit of course ;) > > > > Greets, > > Jeroen > > > > --- > Wayne Bouchard > web at typo.org > Network Dude > http://www.typo.org/~web/ > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From anders.hansen at dsv.com Tue Sep 25 11:12:14 2012 From: anders.hansen at dsv.com (Anders Hansen - DSV) Date: Tue, 25 Sep 2012 13:12:14 +0200 Subject: Google IP Contact Message-ID: If anyone from Google is reading this list, I would appreciate if you could contact me off-list. We've got some issues with one of our CIDR's being treated as German, and would very much like to have this corrected. Tried to report the problem online, but unfortunately without any effect. Best regards, Anders Hansen Network Specialist Group IT - ITS, Communication Services DSV A/S Litauen Alle 4 P. O. Box 157 DK-2630 Taastrup +45 43 20 30 40 Tel. +45 43 20 42 59 Direct Tel. +45 25 41 76 73 Mobile anders.hansen at dsv.com www.dsv.com From anders.hansen at dsv.com Tue Sep 25 13:23:38 2012 From: anders.hansen at dsv.com (Anders Hansen - DSV) Date: Tue, 25 Sep 2012 15:23:38 +0200 Subject: Google IP Contact Message-ID: Got in contact.. thx! Best regards, Anders Hansen Network Specialist Group IT - ITS, Communication Services DSV A/S Litauen Alle 4 P. O. Box 157 DK-2630 Taastrup +45 43 20 30 40 Tel. +45 43 20 42 59 Direct Tel. +45 25 41 76 73 Mobile anders.hansen at dsv.com www.dsv.com From: Anders Hansen - DSV Sent: 25. september 2012 13:12 To: 'nanog at nanog.org' Subject: Google IP Contact If anyone from Google is reading this list, I would appreciate if you could contact me off-list. We've got some issues with one of our CIDR's being treated as German, and would very much like to have this corrected. Tried to report the problem online, but unfortunately without any effect. Best regards, Anders Hansen Network Specialist Group IT - ITS, Communication Services DSV A/S Litauen Alle 4 P. O. Box 157 DK-2630 Taastrup +45 43 20 30 40 Tel. +45 43 20 42 59 Direct Tel. +45 25 41 76 73 Mobile anders.hansen at dsv.com www.dsv.com From Dave.Siegel at level3.com Tue Sep 25 13:26:21 2012 From: Dave.Siegel at level3.com (Siegel, David) Date: Tue, 25 Sep 2012 13:26:21 +0000 Subject: Announcing APNIC IP's in ARIN region In-Reply-To: <505BAD72.9070605@icastcenter.com> References: <505BAD72.9070605@icastcenter.com> Message-ID: <72A2F9AF18EC024C962A748EA6CF75B90ED00F22@W8USSFJ204.ams.gblxint.com> The only problem I've ever run into is with IP geo-location providers using the country of origin of the original assignments to determine the locale of the IP. Major CDN providers and content owners then use these geo-location providers to provide geography specific content or for content localization. A problem we saw at GC when using our ARIN space in APAC (which I realize is the inverse of your situation) is that our enterprise customers often got redirected to a cloud server in the United States rather than in their originating country, and this was in spite of their block being SWIP'd out to them in that country. It's conceivable that you could have some sort of similar problem depending on the nature of your project and how you are planning to use their IP's. Dave -----Original Message----- From: Brandon Wade [mailto:brandonwade at icastcenter.com] Sent: Thursday, September 20, 2012 5:58 PM To: nanog at nanog.org Subject: Announcing APNIC IP's in ARIN region Hello, I was wondering if there are any problems originating APNIC IP's in the ARIN region through transit providers? I have a Singapore-based prospect who would like to do business with us, but I'm not sure if I'll run into problems originating their IP's in the US - which were assigned to them from APNIC. Best regards, Brandon Wade iCastCenter.com From rsm at fast-serv.com Tue Sep 25 13:32:03 2012 From: rsm at fast-serv.com (Randy McAnally) Date: Tue, 25 Sep 2012 09:32:03 -0400 Subject: Charter Blackholing AS29889 Message-ID: <833c6b762ab7fdc3dfc7b326264d1cd6@mailbox.fastserv.com> Hi guys (and sorry for the noise), It appears return traffic from Charter to our ASN is blackholed. According to all three of our upstreams they are delivering traffic but it's not coming back. Unfortunately I don't have a reverse traceroute (our emails to charter customers are bouncing) so I have no idea what transit path they are returning traffic on. I tried fiddling with our outbound paths to no avail. If someone on a Charter connection could shoot me a traceroute to 209.9.238.7 that would be great. Ultimately if someone from Charter is willing to help that would be awesome as well. Source IP: 209.9.238.7 (AS29889) Dest IP: 75.140.10.216 Via HE: [root at mon ~]# traceroute 75.140.10.216 traceroute to 75.140.10.216 (75.140.10.216), 30 hops max, 60 byte packets 1 209.9.238.1 (209.9.238.1) 0.551 ms 0.790 ms 0.512 ms 2 gige-g4-13.core1.ash1.he.net (216.66.0.225) 12.029 ms 12.094 ms 12.158 ms 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * Via Abovenet: [root at mon ~]# traceroute 75.140.10.216 traceroute to 75.140.10.216 (75.140.10.216), 30 hops max, 60 byte packets 1 209.9.238.1 (209.9.238.1) 0.544 ms 0.540 ms 0.573 ms 2 208.185.24.1 (208.185.24.1) 0.206 ms 0.218 ms 0.200 ms 3 xe-4-2-0.er1.iad10.us.above.net (64.125.29.198) 0.228 ms 0.232 ms 0.215 ms 4 above-telia.iad10.us.above.net (64.125.13.158) 117.943 ms 117.958 ms 117.763 ms 5 las-bb1-link.telia.net (80.91.246.71) 62.157 ms 62.162 ms 62.189 ms 6 cco-ic-151505-las-bb1.c.telia.net (213.248.79.102) 72.780 ms 70.183 ms 70.151 ms 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * -- Randy McAnally From jra at baylink.com Tue Sep 25 13:50:40 2012 From: jra at baylink.com (Jay Ashworth) Date: Tue, 25 Sep 2012 09:50:40 -0400 (EDT) Subject: FOLO: POLL: 802.1x deployment In-Reply-To: Message-ID: <31003220.26498.1348581040770.JavaMail.root@benjamin.baylink.com> I've gotten quite a number of useful responses so far; I'll keep aggregating them until tomorrow afternoon or so, and then post a summary. I propose to mention educational institutions by name, but companies only by market segment, and not to mention any contributors names; if that's not opaque enough for anyone who replied, please let me know. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From drc at virtualized.org Tue Sep 25 15:29:32 2012 From: drc at virtualized.org (David Conrad) Date: Tue, 25 Sep 2012 08:29:32 -0700 Subject: Announcing APNIC IP's in ARIN region In-Reply-To: <20120925090534.GA7293@wakko.typo.org> References: <505BAD72.9070605@icastcenter.com> <50616BC3.5090601@unfix.org> <20120925090534.GA7293@wakko.typo.org> Message-ID: <51C5031A-2114-4C84-B67D-86788162985E@virtualized.org> On Sep 25, 2012, at 2:05 AM, Wayne E Bouchard wrote: > It presents no technical problem but has always been considered > politically inadvisable. I mean, there are multiple registries for a > reason that goes beyond mere oranization and load sharing. Always? Actually, no. Back when the RIRs were first starting up, we pushed multinationals to obtain their addresses from the RIR that served the region in which their headquarters were located. The theory was that a single RIR would be better able to ensure addresses were used efficiently and it was more likely routing announcements could be limited. I personally got into a long argument with folks from Shell who wanted addresses from APNIC for their AP region networks and were displeased when I pushed them to RIPE-NCC ("Royal Dutch Shell", headquarters in The Hague). I believe Geert Jan DeGroot at RIPE-NCC (who tended to be a stickler for those sorts of things) got into similar arguments with folks from Mitsubishi in Europe. Of course, the cynical might suggest that over time, such niceties as conserving address space and routing slots would, of course, take a lower priority to marking territory and RIR revenues, but who would be that cynical? Regards, -drc From o.calvano at gmail.com Tue Sep 25 15:49:24 2012 From: o.calvano at gmail.com (Olivier CALVANO) Date: Tue, 25 Sep 2012 17:49:24 +0200 Subject: URGENT - ISP/Telecom Message-ID: Hi I am looking for an operator that can build a ADSL or SDSL in record time. Best regards Olivier From streiner at cluebyfour.org Tue Sep 25 16:14:46 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 25 Sep 2012 12:14:46 -0400 (EDT) Subject: URGENT - ISP/Telecom In-Reply-To: References: Message-ID: On Tue, 25 Sep 2012, Olivier CALVANO wrote: > I am looking for an operator that can build a ADSL or SDSL in record time. With a request this detailed, I wish you the best of luck. jms From jabley at hopcount.ca Tue Sep 25 16:31:57 2012 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 25 Sep 2012 12:31:57 -0400 Subject: URGENT - ISP/Telecom In-Reply-To: References: Message-ID: On 2012-09-25, at 11:49, Olivier CALVANO wrote: > I am looking for an operator that can build a ADSL or SDSL in record time. I just pulled a 2-metre pair of copper between a modem and a DSLAM in the lab, and I can ping things. Total elapsed time 12 minutes (I stopped on the way for coffee). Do I win $5? Joe From mitch at illuminati.org Tue Sep 25 16:36:26 2012 From: mitch at illuminati.org (John Mitchell) Date: Tue, 25 Sep 2012 17:36:26 +0100 Subject: URGENT - ISP/Telecom In-Reply-To: References: Message-ID: <5061DD8A.60702@illuminati.org> On 25/09/12 17:31, Joe Abley wrote: > On 2012-09-25, at 11:49, Olivier CALVANO wrote: > >> I am looking for an operator that can build a ADSL or SDSL in record time. > I just pulled a 2-metre pair of copper between a modem and a DSLAM in the lab, and I can ping things. Total elapsed time 12 minutes (I stopped on the way for coffee). Do I win $5? > > > Joe I think your disqualified for not wrapping it in black trash bags, pink bubble wrap, or duck tape like we've seen some other vendors do in recent months on nanog. From rajiva at cisco.com Tue Sep 25 16:38:18 2012 From: rajiva at cisco.com (Rajiv Asati (rajiva)) Date: Tue, 25 Sep 2012 16:38:18 +0000 Subject: Throw me a IPv6 bone (sort of was IPv6 ignorance) In-Reply-To: Message-ID: Adrian, MAP facilitates both IPv6 deployment and IPv4 address exhaustion without involving any CGN mess in the network. This allows the home networks to stay dual-stack, use IPv6 as possible, and resort to IPv4 if IPv6 is not feasible for the intended destinations. One could promote the intent being that as more and more traffic goes over IPv6, less and less IPv4 will be needed (thereby shrinking the reliance on IPv4 ports sharing). Note that MAP Translation mode (i.e. MAP-T) does not involve any encapsulation, so, any QoS or Security or LI or DPI or Caching needing access to Layer4 info (i.e. UDP/TCP ports) would work just fine anywhere in the network. In case of MAP-E (Encapsulation mode), layer4 info (i.e. UDP/TCP ports) is not available in the network (until at boundary of the network where decapsulation is done). > * The ISP's router to which the user connects being > able to route packets on routes that go beyond the > IP address and into the port number field of TCP/UDP. Nope. The routers still follow the dynamic IPv4 and IPv6 routing for packet forwarding. That is UNCHANGED. The routers (expected to the boundary routers/ASBR, not the PE routers connecting the users) must have to look at the ports for IPv4->IPv6 stateless translation. Once translated, routing lookup as usual. > * A CE router being instructed to constrain itself to > using a limited set of ports on the WAN side in its > NAT44 implementation. Indeed. And it is not much different from how it works today. Almost all CPEs (I.e. Residential routers) work with limited set of ports (typically 2000) for dynamic NAT44 anyway. Of course, when MAP is enabled, the range would no longer be the default (as is the case today), rather something that is assigned using DHCP or TR069. That's in the control plane. Cheers, Rajiv -----Original Message----- From: "nanog-request at nanog.org" Reply-To: "nanog at nanog.org" Date: Tuesday, September 25, 2012 12:08 AM To: "nanog at nanog.org" Subject: NANOG Digest, Vol 56, Issue 84 >Date: Mon, 24 Sep 2012 22:42:46 +0100 >From: Mike Jones >To: Adrian Bool >Cc: "nanog at nanog.org" >Subject: Re: Throw me a IPv6 bone (sort of was IPv6 ignorance) >Message-ID: > >Content-Type: text/plain; charset=UTF-8 > >On 24 September 2012 21:11, Adrian Bool wrote: >> >>On 24 Sep 2012, at 17:57, Tore Anderson >> wrote: >> >>>* Tore Anderson >>> >>>>I would pay very close attention to MAP/4RD. >>> >>>FYI, Mark Townsley had a great presentation about MAP at RIPE65 today, >>>it's 35 minutes you won't regret spending: >>> >>>https://ripe65.ripe.net/archives/video/5 >>>https://ripe65.ripe.net/presentations/91-townsley-map-ripe65-ams-sept-24 >>>-2012.pdf >> >>Interesting video; thanks for posting the link. >> >>This does seem a strange proposal though. My understanding from the >>video is that it is a technology to help not with the deployment of IPv6 >>but with the scarcity of IPv4 addresses. In summary; it simply allows a >>number of users (e.g. 1024) to share a single public IPv4 address. >> >>My feeling is therefore, why are the IPv4 packets to/from the end user >>being either encapsulated or translated into IPv6 - why do they not >>simply remain as IPv4 packets? >> >>If the data is kept as IPv4, this seems to come down to just two changes, >> >>* The ISP's router to which the user connects being able to route >>packets on routes that go beyond the IP address and into the port number >>field of TCP/UDP. >>* A CE router being instructed to constrain itself to using a limited >>set of ports on the WAN side in its NAT44 implementation. >> >>Why all the IPv6 shenanigans complicating matters? > >While you could do something similar without the encapsulation this >would require that every router on your network support routing on >port numbers, by using IPv6 packets it can be routed around your >network by existing routers. And it's not like anyone is going to be >deploying such a system without also deploying IPv6, so it's not >adding any additional requirements doing it that way. > >- Mike > > > >------------------------------ > >Message: 3 >Date: Mon, 24 Sep 2012 23:34:30 +0100 >From: Adrian Bool >To: "nanog at nanog.org" >Subject: Re: Throw me a IPv6 bone (sort of was IPv6 ignorance) >Message-ID: <8BEEBCDA-B6FA-4407-BF95-E122B26F4916 at logic.org.uk> >Content-Type: text/plain; charset=us-ascii > > >On 24 Sep 2012, at 22:42, Mike Jones wrote: > >>While you could do something similar without the encapsulation this >>would require that every router on your network support routing on >>port numbers, > >Well, not really. As the video pointed out, the system was designed to >leverage hierarchy to reduce routing complexity. Using the hierarchy, >port number routing is only required at the level where a routes diverge >on a port basis - which if you're being sensible about such a deployment >would only be at the edge of the access layer. > >aid > From EWieling at nyigc.com Tue Sep 25 16:45:21 2012 From: EWieling at nyigc.com (Eric Wieling) Date: Tue, 25 Sep 2012 12:45:21 -0400 Subject: URGENT - ISP/Telecom In-Reply-To: <5061DD8A.60702@illuminati.org> References: <5061DD8A.60702@illuminati.org> Message-ID: <616B4ECE1290D441AD56124FEBB03D0885379AED@mailserver2007.nyigc.globe> Heh, yesterday I received notification from Verizon that they replaced plastic bags, bubble wrap and electrical tape with a real enclosure. -----Original Message----- From: John Mitchell [mailto:mitch at illuminati.org] Sent: Tuesday, September 25, 2012 12:36 PM To: NANOG list (nanog at nanog.org) Subject: Re: URGENT - ISP/Telecom On 25/09/12 17:31, Joe Abley wrote: > On 2012-09-25, at 11:49, Olivier CALVANO wrote: > >> I am looking for an operator that can build a ADSL or SDSL in record time. > I just pulled a 2-metre pair of copper between a modem and a DSLAM in the lab, and I can ping things. Total elapsed time 12 minutes (I stopped on the way for coffee). Do I win $5? > > > Joe I think your disqualified for not wrapping it in black trash bags, pink bubble wrap, or duck tape like we've seen some other vendors do in recent months on nanog. From jim at reptiles.org Tue Sep 25 17:35:56 2012 From: jim at reptiles.org (Jim Mercer) Date: Tue, 25 Sep 2012 13:35:56 -0400 Subject: URGENT - ISP/Telecom In-Reply-To: References: Message-ID: <20120925173556.GA4941@reptiles.org> On Tue, Sep 25, 2012 at 05:49:24PM +0200, Olivier CALVANO wrote: > I am looking for an operator that can build a ADSL or SDSL in record time. i used to pursue leads like this. now i get SSSS on all my boarding passes. -- Jim Mercer Reptilian Research jim at reptiles.org +1 416 410-5633 "He who dies with the most toys is nonetheless dead" From AOsgood at Streamline-Solutions.net Tue Sep 25 18:17:41 2012 From: AOsgood at Streamline-Solutions.net (Aaron D. Osgood) Date: Tue, 25 Sep 2012 14:17:41 -0400 Subject: URGENT - ISP/Telecom In-Reply-To: References: Message-ID: <028a01cd9b4a$0e24a460$2a6ded20$@net> DING DING DING DING - We have a winning entry! :-) Aaron D. Osgood Streamline Solutions L.L.C P.O. Box 6115 Falmouth, ME 04105 TEL: 207-781-5561 MOBILE: 207-831-5829 ICQ: 206889374 GVoice: 207.518.8455 GTalk: aaron.osgood AOsgood at Streamline-Solutions.net http://www.streamline-solutions.net Introducing Efficiency to Business since 1986. -----Original Message----- From: Joe Abley [mailto:jabley at hopcount.ca] Sent: Tuesday, September 25, 2012 12:32 PM To: Olivier CALVANO Cc: NANOG list (nanog at nanog.org) Subject: Re: URGENT - ISP/Telecom On 2012-09-25, at 11:49, Olivier CALVANO wrote: > I am looking for an operator that can build a ADSL or SDSL in record time. I just pulled a 2-metre pair of copper between a modem and a DSLAM in the lab, and I can ping things. Total elapsed time 12 minutes (I stopped on the way for coffee). Do I win $5? Joe From bonomi at mail.r-bonomi.com Tue Sep 25 19:46:49 2012 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Tue, 25 Sep 2012 14:46:49 -0500 (CDT) Subject: URGENT - ISP/Telecom In-Reply-To: Message-ID: <201209251946.q8PJkn3S062299@mail.r-bonomi.com> > Date: Tue, 25 Sep 2012 17:49:24 +0200 > Subject: URGENT - ISP/Telecom > From: Olivier CALVANO > To: "NANOG list (nanog at nanog.org)" > > Hi > > I am looking for an operator that can build a ADSL or SDSL in record time. Are you prepared to pay a record amount of money? If so, feel free to contact me. From rsm at fast-serv.com Tue Sep 25 20:06:50 2012 From: rsm at fast-serv.com (Randy McAnally) Date: Tue, 25 Sep 2012 16:06:50 -0400 Subject: Charter Blackholing AS29889 Message-ID: On 09/25/2012 9:32 am, Randy McAnally wrote: > Hi guys (and sorry for the noise), Thanks to all those who replied as well as Charter's help we defermined uRPF between Charter and some of their peers were filtering ICMP packets making traceroutes appear dead. Compounded by the fact our test server was blocking certain ICMP packets. The issue appears to have been a non issue from the beginning. Carry on folks :) -- Randy McAnally From dmburgess at linktechs.net Tue Sep 25 20:33:08 2012 From: dmburgess at linktechs.net (Dennis Burgess) Date: Tue, 25 Sep 2012 15:33:08 -0500 Subject: Rogers Contact ? Offlist please? Message-ID: <50710E9A7E64454C974049FC998EB6556819BA@03-exchange.lti.local> Region, Owen Sound, any technical contact for help with a fiber connection with slow/bursty uploads. ? Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition " Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net - Skype: linktechs -- Create Wireless Coverage's with www.towercoverage.com - 900Mhz - LTE - 3G - 3.65 - TV Whitespace 5-Day Advanced RouterOS Workshop - Oct 8th 2012 - St. Louis, MO, USA From owen at delong.com Tue Sep 25 20:56:12 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 25 Sep 2012 13:56:12 -0700 Subject: Announcing APNIC IP's in ARIN region In-Reply-To: <20120925090534.GA7293@wakko.typo.org> References: <505BAD72.9070605@icastcenter.com> <50616BC3.5090601@unfix.org> <20120925090534.GA7293@wakko.typo.org> Message-ID: Wayne, This isn't entirely true... As a general rule, most people have no objection so long as a given organization that is getting space from RIRs conforms to one of the following: Get from the RIR where HQ is located. Get from the RIR where addresses are deployed. For example, an organization in the APNIC region that wanted to deploy a router at a US XP and announce their space there is entirely valid. An ISP headquartered in the AfriNIC region that expanded into Europe would be able to use their Afrinic space for that expansion as well. Owen On Sep 25, 2012, at 02:05 , Wayne E Bouchard wrote: > It presents no technical problem but has always been considered > politically inadvisable. I mean, there are multiple registries for a > reason that goes beyond mere oranization and load sharing. > Increasingly, governments are trying to take more control over packets > (there is ever the push for geographic maping mechanisms and so on) > and that may introduce potential legal problems in the future, > depending on the nation you're in and how paranoid they become. > > So in short, do what you need to do. Just be aware of sub-optimal. > > -Wayne > > On Tue, Sep 25, 2012 at 10:30:59AM +0200, Jeroen Massar wrote: >> On 2012-09-21 01:57, Brandon Wade wrote: >>> Hello, >>> >>> I was wondering if there are any problems originating APNIC IP's in the >>> ARIN region through transit providers? I have a Singapore-based prospect >>> who would like to do business with us, but I'm not sure if I'll run into >>> problems originating their IP's in the US - which were assigned to them >>> from APNIC. >> >> As this Internet thing is a global thing, why would that be an issue? >> >> (unless it is a spammer outfit of course ;) >> >> Greets, >> Jeroen >> > > --- > Wayne Bouchard > web at typo.org > Network Dude > http://www.typo.org/~web/ From tjc at ecs.soton.ac.uk Tue Sep 25 21:02:37 2012 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Tue, 25 Sep 2012 22:02:37 +0100 Subject: FOLO: POLL: 802.1x deployment In-Reply-To: <31003220.26498.1348581040770.JavaMail.root@benjamin.baylink.com> References: <31003220.26498.1348581040770.JavaMail.root@benjamin.baylink.com> <09335D5E-6686-468C-8DF3-4439E03EC6E0@ecs.soton.ac.uk> Message-ID: On 25 Sep 2012, at 14:50, Jay Ashworth wrote: > > I propose to mention educational institutions by name, There's an awful lot of those using 802.1x. It'll be some list :) Tim From cabo at tzi.org Tue Sep 25 22:37:38 2012 From: cabo at tzi.org (Carsten Bormann) Date: Wed, 26 Sep 2012 00:37:38 +0200 Subject: POLL: 802.1x deployment In-Reply-To: <664863.26368.1348502467243.JavaMail.root@benjamin.baylink.com> References: <664863.26368.1348502467243.JavaMail.root@benjamin.baylink.com> Message-ID: <4AB62262-2FF9-4DC8-8627-786A03A17B33@tzi.org> > If you regularly use one or more 802.1x protected networks, could you take > a moment to reply off-list, and tell me the size of the network (homelab, > smb, enterprise, carrier), and, if you know, how long 802.1x has been deployed > there? Surely you are joking, Mr. Ashworth. The entirety of eduroam is on 802.1X (better known as WPA Enterprise). That must be an 8-digit number of users. If you need a list of sites, start with http://en.wikipedia.org/wiki/Eduroam (but, aside from the US, it mostly lists just the countries). When you are done drilling down, there should be about 6500 names of sites on the list. If you are talking about wired .1X: It is relatively common for eduroam-enabled institutions to also provide publicly accessible wired ports controlled by .1X and connected to the same RADIUS servers. But I don't have any numbers at all. > I'm also interested in whether any network you use has dropped .1x. eduroam deployment started in 2003. Your university academic computing environment would need to be pretty stupid to leave eduroam once it is deployed. But stranger things have happened. If your academic computing environment is not yet on eduroam, they still almost certainly use .1X for the wireless. Not all 100+ million students worldwide have access to on-campus WiFi, but nowadays most do. Gr??e, Carsten From seitz at bsd-unix.net Tue Sep 25 23:11:04 2012 From: seitz at bsd-unix.net (Bryan Seitz) Date: Tue, 25 Sep 2012 19:11:04 -0400 Subject: Verizon FIOS troubleshooting Message-ID: <50623A08.8000908@bsd-unix.net> All, Recently began seeing things like this to the default GW from inside and outside the FIOS network. Called tech support but all they could do was put a ticket in for the NetEng team. http://pastie.org/4800421 http://www.bsd-unix.net/smokeping/smokeping.cgi?target=people.bryan The pings jumping from an avg of 3ms to 80 is what gets me. Also my downloading / uploading on my segment doesn't seem to affect the latency jumps on the default GW either way (when testing from my COLO). Any thoughts or suggestions would be appreciated! From jra at baylink.com Wed Sep 26 00:02:22 2012 From: jra at baylink.com (Jay Ashworth) Date: Tue, 25 Sep 2012 20:02:22 -0400 (EDT) Subject: URGENT - ISP/Telecom In-Reply-To: Message-ID: <20724865.26662.1348617742733.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Joe Abley" > On 2012-09-25, at 11:49, Olivier CALVANO wrote: > > I am looking for an operator that can build a ADSL or SDSL in record > > time. > > I just pulled a 2-metre pair of copper between a modem and a DSLAM in > the lab, and I can ping things. Total elapsed time 12 minutes (I > stopped on the way for coffee). Do I win $5? Next time NANOG comes back to Tampa, yes. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From mysidia at gmail.com Wed Sep 26 00:32:23 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 25 Sep 2012 19:32:23 -0500 Subject: POLL: 802.1x deployment In-Reply-To: <4AB62262-2FF9-4DC8-8627-786A03A17B33@tzi.org> References: <664863.26368.1348502467243.JavaMail.root@benjamin.baylink.com> <4AB62262-2FF9-4DC8-8627-786A03A17B33@tzi.org> Message-ID: On 9/25/12, Carsten Bormann wrote: > Surely you are joking, Mr. Ashworth. > The entirety of eduroam is on 802.1X (better known as WPA Enterprise). ding ding ding. WPA Ent wireless authentication calls upon 802.1X. And 802.1X wired port security is also a feature of many switches, and provides stronger protection than MAC-address based port security functionality; and 802.1x option may be used by at least some organizations, to protect against unauthorized connections to secure wired networks, and/or to force guests / salespeople / vendors plugging in their laptop, to be placed in a guest LAN; instead of gaining access to the company's secure internal network, if they sneak over to someone's desk, unplug the desktop, and plug in their laptop to attempt some covert network scanning..... Wired switch vendors don't add 802.1X to their switches for their health, it would be less expensive to make a product without the development effort to add the function; someone wants the feature. In this case, the remaining burden of proof should be on whomever wants to claim it's not widely deployed. > http://en.wikipedia.org/wiki/Eduroam > (but, aside from the US, it mostly lists just the countries). > When you are done drilling down, there should be about 6500 names of sites > on the list. > eduroam deployment started in 2003. Eduroam? What standard is that? > Gr??e, Carsten --- -JH From Valdis.Kletnieks at vt.edu Wed Sep 26 00:53:18 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 25 Sep 2012 20:53:18 -0400 Subject: POLL: 802.1x deployment In-Reply-To: Your message of "Wed, 26 Sep 2012 00:37:38 +0200." <4AB62262-2FF9-4DC8-8627-786A03A17B33@tzi.org> References: <664863.26368.1348502467243.JavaMail.root@benjamin.baylink.com> <4AB62262-2FF9-4DC8-8627-786A03A17B33@tzi.org> Message-ID: <38300.1348620798@turing-police.cc.vt.edu> On Wed, 26 Sep 2012 00:37:38 +0200, Carsten Bormann said: > The entirety of eduroam is on 802.1X (better known as WPA Enterprise). > That must be an 8-digit number of users. > If you need a list of sites, start with http://en.wikipedia.org/wiki/Eduroam However, that would be more a confederation of deployments than one single large deployment. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From john.yocum at fluidhosting.com Wed Sep 26 00:56:40 2012 From: john.yocum at fluidhosting.com (John T. Yocum) Date: Tue, 25 Sep 2012 17:56:40 -0700 Subject: Verizon FIOS troubleshooting In-Reply-To: <50623A08.8000908@bsd-unix.net> References: <50623A08.8000908@bsd-unix.net> Message-ID: <506252C8.2050001@fluidhosting.com> On 9/25/2012 4:11 PM, Bryan Seitz wrote: > > All, > > Recently began seeing things like this to the default GW from > inside and outside the FIOS network. Called tech support but all they > could do was put a ticket in for the NetEng team. > > http://pastie.org/4800421 > > http://www.bsd-unix.net/smokeping/smokeping.cgi?target=people.bryan > > The pings jumping from an avg of 3ms to 80 is what gets me. Also my > downloading / uploading on my segment doesn't seem to affect the latency > jumps on the default GW either way (when testing from my COLO). Any > thoughts or suggestions would be appreciated! > > > Most likely Verizon has their routers configured to rate limit, or reduce priority to replying to pings directed at them. --John From rsm at fast-serv.com Wed Sep 26 01:50:01 2012 From: rsm at fast-serv.com (Randy McAnally) Date: Tue, 25 Sep 2012 21:50:01 -0400 Subject: Verizon FIOS troubleshooting In-Reply-To: <50623A08.8000908@bsd-unix.net> References: <50623A08.8000908@bsd-unix.net> Message-ID: <6a63ff1e7e7714c0430f0510754f5944@mailbox.fastserv.com> On 09/25/2012 7:11 pm, Bryan Seitz wrote: > All, > > Recently began seeing things like this to the default GW from > inside and outside the FIOS network. Called tech support but all > they > could do was put a ticket in for the NetEng team. > > http://pastie.org/4800421 > > http://www.bsd-unix.net/smokeping/smokeping.cgi?target=people.bryan > > The pings jumping from an avg of 3ms to 80 is what gets me. Also my > downloading / uploading on my segment doesn't seem to affect the > latency jumps on the default GW either way (when testing from my > COLO). Any thoughts or suggestions would be appreciated! Worry about a connected hosts, not the gateway router. If you see the same behavior between hosts then check your upstream/downstream rates since they will buffer your connection if you get close to the advertised rates, even for micro bursts. -- Randy M From mohacsi at niif.hu Wed Sep 26 07:27:13 2012 From: mohacsi at niif.hu (Mohacsi Janos) Date: Wed, 26 Sep 2012 09:27:13 +0200 (CEST) Subject: POLL: 802.1x deployment In-Reply-To: <38300.1348620798@turing-police.cc.vt.edu> References: <664863.26368.1348502467243.JavaMail.root@benjamin.baylink.com> <4AB62262-2FF9-4DC8-8627-786A03A17B33@tzi.org> <38300.1348620798@turing-police.cc.vt.edu> Message-ID: On Tue, 25 Sep 2012, Valdis.Kletnieks at vt.edu wrote: > On Wed, 26 Sep 2012 00:37:38 +0200, Carsten Bormann said: > >> The entirety of eduroam is on 802.1X (better known as WPA Enterprise). >> That must be an 8-digit number of users. >> If you need a list of sites, start with http://en.wikipedia.org/wiki/Eduroam > > However, that would be more a confederation of deployments than > one single large deployment. But each participating institution (more than 5000 universities and research centres) deployed 802.1x in their premises. Big bonus that they work together seamlessly (inter organisation roaming and 802.1x usage). Have look at the official homepage of eduroam: http://www.eduroam.org/ Best Regards, Janos Mohacsi > From brent at brentrjones.com Wed Sep 26 07:43:24 2012 From: brent at brentrjones.com (Brent Jones) Date: Wed, 26 Sep 2012 00:43:24 -0700 Subject: POLL: 802.1x deployment In-Reply-To: References: <664863.26368.1348502467243.JavaMail.root@benjamin.baylink.com> <4AB62262-2FF9-4DC8-8627-786A03A17B33@tzi.org> <38300.1348620798@turing-police.cc.vt.edu> Message-ID: That is quite impressive that 5,000 orgs got 802.1x working correctly in this fashion. I had a lot of questions how they handled auth, but it appears auth is distributed according to a roaming user's realm/domain suffix. https://confluence.terena.org/display/H2eduroam/How+to+deploy+eduroam+on-site+or+on+campus Fairly decent wiki on their site, bet others would find this helpful for non-eduroam dot1x On Wed, Sep 26, 2012 at 12:27 AM, Mohacsi Janos wrote: > > > On Tue, 25 Sep 2012, Valdis.Kletnieks at vt.edu wrote: > >> On Wed, 26 Sep 2012 00:37:38 +0200, Carsten Bormann said: >> >>> The entirety of eduroam is on 802.1X (better known as WPA Enterprise). >>> That must be an 8-digit number of users. >>> If you need a list of sites, start with >>> http://en.wikipedia.org/wiki/Eduroam >> >> >> However, that would be more a confederation of deployments than >> one single large deployment. > > > But each participating institution (more than 5000 universities and research > centres) deployed 802.1x in their premises. Big bonus that they work > together seamlessly (inter organisation roaming and 802.1x usage). > > Have look at the official homepage of eduroam: > http://www.eduroam.org/ > > Best Regards, > Janos Mohacsi > >> > -- Brent Jones brent at brentrjones.com From peterc at luddite.com.au Wed Sep 26 07:55:19 2012 From: peterc at luddite.com.au (Peter J. Cherny) Date: Wed, 26 Sep 2012 17:55:19 +1000 Subject: POLL: 802.1x deployment In-Reply-To: <664863.26368.1348502467243.JavaMail.root@benjamin.baylink.com> References: <664863.26368.1348502467243.JavaMail.root@benjamin.baylink.com> Message-ID: <5062B4E7.5090102@luddite.com.au> I've (re)sent this to the list as no-one else has noted it Possibly a game-changer in the (academic) 802.1x space ... http://www.project-moonshot.org/diary http://www.painless-security.com/blog/ From adam.vitkovsky at swan.sk Wed Sep 26 09:28:32 2012 From: adam.vitkovsky at swan.sk (Adam Vitkovsky) Date: Wed, 26 Sep 2012 11:28:32 +0200 Subject: Ethernet OAM BCPs Please are there any yet??? Message-ID: <024001cd9bc9$4bdeb230$e39c1690$@swan.sk> Hi Are there any best common practices for the CFM levels use Since my pure Ethernet aggregation layers are small I believe I only need two CFM levels I plan on using Level 5 between CPEs managed by us and Level 4 between Aggregation devices -that's where MPLS PWs kicks in So leaving Level 7 and Level 6 for customers and carrier-customers respectfully -would this be enough please? I'm also interested on what's the rule of thumb for CCMs Frequency, Number of Packets, Interpacket Interval, Packet Size and Lifetime for the particular operation Thanks a lot for any inputs adam From nanog at ml.karotte.org Wed Sep 26 12:46:04 2012 From: nanog at ml.karotte.org (Sebastian Wiesinger) Date: Wed, 26 Sep 2012 14:46:04 +0200 Subject: What are qatesttwai.gov/fttesttwai.gov? Message-ID: <20120926124604.GA6353@danton.fire-world.de> Hello, my resolver running on a dedicated server is warning about DNSSEC validation failure for these two .gov domains 7 minutes after every full hour: Sep 26 13:07:04 alita unbound: [28931:0] info: validation failure : no keys have a DS with algorithm RSASHA1-NSEC3-SHA1 from 199.169.196.64 for key qatesttwai.gov. while building chain of trust Sep 26 13:07:04 alita unbound: [28931:0] info: validation failure : no keys have a DS with algorithm RSASHA1-NSEC3-SHA1 from 199.169.196.64 for key fttesttwai.gov. while building chain of trust Does anyone know what these are? There are placeholder https sites at these hosts but nothing else. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant From bonomi at mail.r-bonomi.com Wed Sep 26 13:14:28 2012 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Wed, 26 Sep 2012 08:14:28 -0500 (CDT) Subject: What are qatesttwai.gov/fttesttwai.gov? In-Reply-To: <20120926124604.GA6353@danton.fire-world.de> Message-ID: <201209261314.q8QDESX2068272@mail.r-bonomi.com> > Date: Wed, 26 Sep 2012 14:46:04 +0200 > From: Sebastian Wiesinger > To: NANOG > Subject: What are qatesttwai.gov/fttesttwai.gov? > 'TWAI' is the U.S. gov't reasury eb pplications nfrastructre, run by the Federal Reerve, for a number of secure Treasury-wide application. Parallel production and 'test' environments. looks like these are parts of the 'test' environment. z From psirt at cisco.com Wed Sep 26 16:16:45 2012 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 26 Sep 2012 12:16:45 -0400 Subject: Cisco Security Advisory: Cisco Unified Communications Manager Session Initiation Protocol Denial of Service Vulnerability Message-ID: <201209261216018.cisco-sa-20120926-cucm@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco Unified Communications Manager Session Initiation Protocol Denial of Service Vulnerability Advisory ID: cisco-sa-20120926-cucm Revision 1.0 For Public Release 2012 September 26 16:00 UTC (GMT) +--------------------------------------------------------------------- Summary ======= Cisco Unified Communications Manager contains a vulnerability in its Session Initiation Protocol (SIP) implementation that could allow an unauthenticated, remote attacker to cause a critical service to fail, which could interrupt voice services. Affected devices must be configured to process SIP messages for this vulnerability to be exploitable. Cisco has released free software updates that address this vulnerability. A workaround exists for customers who do not require SIP in their environment. This advisory is available at: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120926-cucm Note: The September 26, 2012, Cisco IOS Software Security Advisory bundled publication includes 9 Cisco Security Advisories. Eight of the advisories address vulnerabilities in Cisco IOS Software, and one advisory addresses a vulnerability in Cisco Unified Communications Manager. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the September 2012 bundled publication. Individual publication links are in "Cisco Event Response: Semi-Annual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep12.html Cisco IOS Software and Cisco IOS XE Software are affected by the vulnerability described in this advisory. A separate Cisco Security Advisory has been published to disclose the vulnerability that affects Cisco IOS Software and Cisco IOS XE Software at the following location: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120926-sip -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlBgiVQACgkQUddfH3/BbTqDrAD9GKw11Pk/9nwMJBzSQ7znHH8u JzDBtraEHMNDkyEacLAA/2ZbaNvWDOhuly4XCs84hvZhUtxnaHFCNheFGI3Go8nj =0fGN -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 26 16:18:34 2012 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 26 Sep 2012 12:18:34 -0400 Subject: Cisco Security Advisory: Cisco IOS Software Session Initiation Protocol Denial of Service Vulnerability Message-ID: <201209261218018.cisco-sa-20120926-sip@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco IOS Software Session Initiation Protocol Denial of Service Vulnerability Advisory ID: cisco-sa-20120926-sip Revision 1.0 For Public Release 2012 September 26 16:00 UTC (GMT) +--------------------------------------------------------------------- Summary ======= A vulnerability exists in the Session Initiation Protocol (SIP) implementation in Cisco IOS Software and Cisco IOS XE Software that could allow an unauthenticated, remote attacker to cause an affected device to reload. Affected devices must be configured to process SIP messages and for pass-through of Session Description Protocol (SDP) for this vulnerability to be exploitable. Cisco has released free software updates that address this vulnerability. There are no workarounds for devices that must run SIP; however, mitigations are available to limit exposure to the vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120926-sip Note: The September 26, 2012, Cisco IOS Software Security Advisory bundled publication includes 9 Cisco Security Advisories. Eight of the advisories address vulnerabilities in Cisco IOS Software, and one advisory addresses a vulnerability in Cisco Unified Communications Manager. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the September 2012 bundled publication. Individual publication links are in "Cisco Event Response: Semi-Annual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep12.html Cisco Unified Communications Manager is affected by the vulnerability described in this advisory. A separate Cisco Security Advisory has been published to disclose the vulnerability that affects the Cisco Unified Communications Manager at the following location: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120926-cucm -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlBgeEAACgkQUddfH3/BbTob/wD/Qp0Y5YKNdLu4RUcBgkHojBc+ EQQQyJVSQTrHNG6GJcoA/jXiO1Lic8HzNUQdmusjvD+dIdKjQd8GrMOwAhKOQWpU =vIHn -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 26 16:18:34 2012 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 26 Sep 2012 12:18:34 -0400 Subject: Cisco Security Advisory: Cisco IOS Software Intrusion Prevention System Denial of Service Vulnerability Message-ID: <201209261218018.cisco-sa-20120926-ios-ips@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco IOS Software Intrusion Prevention System Denial of Service Vulnerability Advisory ID: cisco-sa-20120926-ios-ips Revision 1.0 For Public Release 2012 September 26 16:00 UTC (GMT) +--------------------------------------------------------------------- Summary ======= Cisco IOS Software contains a vulnerability in the Intrusion Prevention System (IPS) feature that could allow an unauthenticated, remote attacker to cause a reload of an affected device if specific Cisco IOS IPS configurations exist. Cisco has released free software updates that address this vulnerability. Workarounds that mitigate this vulnerability are available. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120926-ios-ips Note: The September 26, 2012, Cisco IOS Software Security Advisory bundled publication includes 9 Cisco Security Advisories. Eight of the advisories address vulnerabilities in Cisco IOS Software, and one advisory addresses a vulnerability in Cisco Unified Communications Manager. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the September 2012 bundled publication. Individual publication links are in "Cisco Event Response: Semi-Annual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep12.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlBgeD8ACgkQUddfH3/BbTpJqQD+IN51ZWVrBuSFzCEOb3hRHC+o i093jjXqPMmZ90pvT8wA/2LNuyuDuc7hat0gxy02+ZQbwKfDwaFFsJQ7UnV3WQf/ =QlOw -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 26 16:18:34 2012 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 26 Sep 2012 12:18:34 -0400 Subject: Cisco Security Advisory: Cisco IOS Software Tunneled Traffic Queue Wedge Vulnerability Message-ID: <201209261218018.cisco-sa-20120926-c10k-tunnels@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco IOS Software Tunneled Traffic Queue Wedge Vulnerability Advisory ID: cisco-sa-20120926-c10k-tunnels Revision 1.0 For Public Release 2012 September 26 16:00 UTC (GMT) +--------------------------------------------------------------------- Summary ======= Cisco IOS Software contains a queue wedge vulnerability that can be triggered when processing IP tunneled packets. Only Cisco IOS Software running on the Cisco 10000 Series router has been demonstrated to be affected. Successful exploitation of this vulnerability may prevent traffic from transiting the affected interfaces. Cisco has released free software updates that addresses this vulnerability. There are no workarounds for this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120926-c10k-tunnels Note: The September 26, 2012, Cisco IOS Software Security Advisory bundled publication includes 9 Cisco Security Advisories. Eight of the advisories address vulnerabilities in Cisco IOS Software, and one advisory addresses a vulnerability in Cisco Unified Communications Manager. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the September 2012 bundled publication. Individual publication links are in "Cisco Event Response: Semi-Annual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep12.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlBgeD4ACgkQUddfH3/BbTpLigD/fKng67LLI/XQ0AkD8l6YyPct /hYpJdygEEIqvm2htS8BAIGs1zHnI0iD1w9RTmKc+uaeopmfO8F7qsutxUFX4KhJ =cGGl -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 26 16:18:34 2012 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 26 Sep 2012 12:18:34 -0400 Subject: Cisco Security Advisory: Cisco IOS Software Malformed Border Gateway Protocol Attribute Vulnerability Message-ID: <201209261218018.cisco-sa-20120926-bgp@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco IOS Software Malformed Border Gateway Protocol Attribute Vulnerability Advisory ID: cisco-sa-20120926-bgp Revision 1.0 For Public Release 2012 September 26 16:00 UTC (GMT) +--------------------------------------------------------------------- Summary ======= Cisco IOS Software contains a vulnerability in the Border Gateway Protocol (BGP) routing protocol feature. The vulnerability can be triggered when the router receives a malformed attribute from a peer on an existing BGP session. Successful exploitation of this vulnerability can cause all BGP sessions to reset. Repeated exploitation may result in an inability to route packets to BGP neighbors during reconvergence times. Cisco has released free software updates that address this vulnerability. There are no workarounds for this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120926-bgp Note: The September 26, 2012, Cisco IOS Software Security Advisory bundled publication includes 9 Cisco Security Advisories. Eight of the advisories address vulnerabilities in Cisco IOS Software, and one advisory addresses a vulnerability in Cisco Unified Communications Manager. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the September 2012 bundled publication. Individual publication links are in "Cisco Event Response: Semi-Annual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep12.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlBgeD0ACgkQUddfH3/BbTpwbwD+IkJ8uofSPxpZwUFgVu8dVRWq 6OpD4B6w1i+wGN5IOEQA/1o7VdakD9PFvIZODdfcptJSRK4k4SbeAf46KMFAiSYM =/DrE -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 26 16:18:34 2012 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 26 Sep 2012 12:18:34 -0400 Subject: Cisco Security Advisory: Cisco IOS Software Network Address Translation Vulnerabilities Message-ID: <201209261218018.cisco-sa-20120926-nat@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco IOS Software Network Address Translation Vulnerabilities Advisory ID: cisco-sa-20120926-nat Revision 1.0 For Public Release 2012 September 26 16:00 UTC (GMT) +--------------------------------------------------------------------- Summary ======= The Cisco IOS Software Network Address Translation (NAT) feature contains two denial of service (DoS) vulnerabilities in the translation of IP packets. The vulnerabilities are caused when packets in transit on the vulnerable device require translation. Cisco has released free software updates that address these vulnerabilities. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120926-nat Note: The September 26, 2012, Cisco IOS Software Security Advisory bundled publication includes 9 Cisco Security Advisories. Eight of the advisories address vulnerabilities in Cisco IOS Software, and one advisory addresses a vulnerability in Cisco Unified Communications Manager. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the September 2012 bundled publication. Individual publication links are in "Cisco Event Response: Semi-Annual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep12.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlBgeD8ACgkQUddfH3/BbTrGtwD8CaC1pyjW+b1ltiGIsvX+jMfG jEEqlzr6VT/F1vjvaDgA/2pAjCs0T5rcGdJUhyKRlQH+PjVLBRVQaQTp/kk5T4+i =q0VJ -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 26 16:18:34 2012 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 26 Sep 2012 12:18:34 -0400 Subject: Cisco Security Advisory: Cisco IOS Software DHCP Version 6 Denial of Service Vulnerability Message-ID: <201209261218018.cisco-sa-20120926-dhcpv6@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco IOS Software DHCP Version 6 Server Denial of Service Vulnerability Advisory ID: cisco-sa-20120926-dhcpv6 Revision 1.0 For Public Release 2012 September 26 16:00 UTC (GMT) +--------------------------------------------------------------------- Summary ======= Cisco IOS Software and Cisco IOS XE Software contain a vulnerability that could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition. An attacker could exploit this vulnerability by sending a crafted request to an affected device that has the DHCP version 6 (DHCPv6) server feature enabled, causing a reload. Cisco has released free software updates that address this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120926-dhcpv6 Note: The September 26, 2012, Cisco IOS Software Security Advisory bundled publication includes 9 Cisco Security Advisories. Eight of the advisories address vulnerabilities in Cisco IOS Software, and one advisory addresses a vulnerability in Cisco Unified Communications Manager. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the September 2012 bundled publication. Individual publication links are in "Cisco Event Response: Semi-Annual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep12.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlBgeD4ACgkQUddfH3/BbTpTmwD/aWSNsmnurhMHzokzSTJUI4/B 428bYcAKinMffKT+bgIA/20BRb6rR7qCoIK0ynVDnbtYiNjwCMy+EQFEUrDWhpl1 =kAhj -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 26 16:18:34 2012 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 26 Sep 2012 12:18:34 -0400 Subject: Cisco Security Advisory: Cisco IOS Software DHCP Denial of Service Vulnerability Message-ID: <201209261218018.cisco-sa-20120926-dhcp@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco IOS Software DHCP Denial of Service Vulnerability Advisory ID: cisco-sa-20120926-dhcp Revision 1.0 For Public Release 2012 September 26 16:00 UTC (GMT) +--------------------------------------------------------------------- Summary ======= Cisco IOS Software contains a vulnerability that could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition. An attacker could exploit this vulnerability by sending a single DHCP packet to or through an affected device, causing the device to reload. Cisco has released free software updates that address this vulnerability. A workaround that mitigates this vulnerability is available. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120926-dhcp Note: The September 26, 2012, Cisco IOS Software Security Advisory bundled publication includes 9 Cisco Security Advisories. Eight of the advisories address vulnerabilities in Cisco IOS Software, and one advisory addresses a vulnerability in Cisco Unified Communications Manager. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the September 2012 bundled publication. Individual publication links are in "Cisco Event Response: Semi-Annual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep12.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlBgeD4ACgkQUddfH3/BbTrJBgD8D/YGAbTV2hF3i3v0Gg8nFc2x jVoS/mVfTMurWAYQflIA/0HU8TpFR6A9Oegidg2Cjc27Vyx2RbAqah6Y57BceTco =WgD1 -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 26 16:18:34 2012 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 26 Sep 2012 12:18:34 -0400 Subject: Cisco Security Advisory: Cisco Catalyst 4500E Series Switch with Cisco Catalyst Supervisor Engine 7L-E Denial of Service Vulnerability Message-ID: <201209261218018.cisco-sa-20120926-ecc@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco Catalyst 4500E Series Switch with Cisco Catalyst Supervisor Engine 7L-E Denial of Service Vulnerability Advisory ID: cisco-sa-20120926-ecc Revision 1.0 For Public Release 2012 September 26 16:00 UTC (GMT) +--------------------------------------------------------------------- Summary ======= The Catalyst 4500E series switch with Supervisor Engine 7L-E contains a denial of service (DoS) vulnerability when processing specially crafted packets that can cause a reload of the device. Cisco has released free software updates that address this vulnerability. Workarounds that mitigate this vulnerability are not available. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120926-ecc Note: The September 26, 2012, Cisco IOS Software Security Advisory bundled publication includes 9 Cisco Security Advisories. Eight of the advisories address vulnerabilities in Cisco IOS Software, and one advisory addresses a vulnerability in Cisco Unified Communications Manager. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the September 2012 bundled publication. Individual publication links are in "Cisco Event Response: Semi-Annual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep12.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlBgeD8ACgkQUddfH3/BbTptGQD+LJo6CaOPouQRBuPy+1jpi5SB EvY/pXj/6kA47NIeQtMA/A/K7sSoBEfEn/baeeTcOOvyJ4Yo4I9wekRMSMJFzxoz =kR+l -----END PGP SIGNATURE----- From Jonathon.Exley at kordia.co.nz Wed Sep 26 16:34:08 2012 From: Jonathon.Exley at kordia.co.nz (Jonathon Exley) Date: Wed, 26 Sep 2012 16:34:08 +0000 Subject: Ethernet OAM BCPs Please are there any yet??? In-Reply-To: <024001cd9bc9$4bdeb230$e39c1690$@swan.sk> References: <024001cd9bc9$4bdeb230$e39c1690$@swan.sk> Message-ID: The ITU recommend the following levels: 5,6,7 = Customer 3,4 = Provider 1,2 = Operator 0 = Local segment I don't know if there are any rules of thumb for the CCM interval - faster is more sensitive & unstable, slow is sluggish but stable. The spec allows between 3.33 ms and 10 minutes in 7 steps, with 1s being the midpoint. So we use 1s intervals. I'm not sure if the other parameters you mention are configurable for CCM. I think the packet has a constant size. Are you wanting to also do Y.1731 performance management? Jonathon > -----Original Message----- > From: Adam Vitkovsky [mailto:adam.vitkovsky at swan.sk] > Sent: Wednesday, 26 September 2012 9:29 p.m. > To: nanog at nanog.org > Subject: Ethernet OAM BCPs Please are there any yet??? > > Hi > Are there any best common practices for the CFM levels use Since my pure > Ethernet aggregation layers are small I believe I only need two CFM levels I > plan on using Level 5 between CPEs managed by us and Level 4 between > Aggregation devices -that's where MPLS PWs kicks in So leaving Level 7 and > Level 6 for customers and carrier-customers respectfully -would this be > enough please? > > I'm also interested on what's the rule of thumb for CCMs Frequency, > Number of Packets, Interpacket Interval, Packet Size and Lifetime for the > particular operation Thanks a lot for any inputs This email and attachments: are confidential; may be protected by privilege and copyright; if received in error may not be used, copied, or kept; are not guaranteed to be virus-free; may not express the views of Kordia(R); do not designate an information system; and do not give rise to any liability for Kordia(R). From derek at derekivey.com Wed Sep 26 16:59:39 2012 From: derek at derekivey.com (Derek Ivey) Date: Wed, 26 Sep 2012 12:59:39 -0400 Subject: Anyone from Verizon/TATA on here? Possible Packet Loss Message-ID: Hi guys, We host a web application for a client and they've been complaining that it's been slow since yesterday. It seems fast from the locations I've tested and the system looks fine, so I suspected there was packet loss going on somewhere between them and our colo facility. I did a few trace routes from our firewall to the client's IP and most of the time they look fine, however I occasionally see some packet loss. Good trace route: 1 65.61.0.97 0 msec 0 msec 0 msec 2 107.1.118.217 0 msec 10 msec 0 msec 3 69.139.194.21 0 msec 0 msec 0 msec 4 68.86.147.129 10 msec 10 msec 20 msec 5 68.86.94.169 20 msec 30 msec 20 msec 6 68.86.86.26 20 msec 20 msec 10 msec 7 216.6.87.97 10 msec 20 msec 20 msec 8 216.6.87.34 10 msec 20 msec 10 msec 9 152.63.34.22 20 msec 10 msec 20 msec 10 130.81.28.255 30 msec 30 msec 20 msec Traceroutes with packet loss (8th hop): 1 65.61.0.97 0 msec 0 msec 0 msec 2 107.1.118.217 0 msec 10 msec 0 msec 3 69.139.194.21 0 msec 0 msec 0 msec 4 68.86.147.129 20 msec 10 msec 10 msec 5 68.86.94.169 20 msec 20 msec 30 msec 6 68.86.86.26 20 msec 20 msec 10 msec 7 216.6.87.97 10 msec 20 msec 30 msec 8 216.6.87.34 10 msec * 10 msec 9 152.63.34.22 140 msec 110 msec 20 msec 10 130.81.28.255 20 msec 30 msec 30 msec 1 65.61.0.97 10 msec 0 msec 0 msec 2 107.1.118.217 0 msec 10 msec 0 msec 3 69.139.194.21 0 msec 0 msec 0 msec 4 68.86.147.129 20 msec 20 msec 10 msec 5 68.86.94.169 30 msec 20 msec 20 msec 6 68.86.86.26 20 msec 20 msec 20 msec 7 216.6.87.97 20 msec 10 msec 20 msec 8 216.6.87.34 20 msec 40 msec * 9 152.63.34.22 20 msec 10 msec 10 msec 10 130.81.28.255 30 msec 30 msec 20 msec It appears the 8th hop occasionally has packet loss. Thanks, Derek From ikiris at gmail.com Wed Sep 26 17:10:15 2012 From: ikiris at gmail.com (Blake Dunlap) Date: Wed, 26 Sep 2012 12:10:15 -0500 Subject: Anyone from Verizon/TATA on here? Possible Packet Loss In-Reply-To: References: Message-ID: This is not the proper way to interpret traceroute information. Also, 3 pings is not sufficient to determine levels of packet loss statistically. I suggest searching the archives regarding traceroute, or googling how to interpret them in regards to packet loss, as what you posted does not indicate what you think it does. -Blake On Wed, Sep 26, 2012 at 11:59 AM, Derek Ivey wrote: > Hi guys, > > We host a web application for a client and they've been complaining that > it's been slow since yesterday. It seems fast from the locations I've > tested and the system looks fine, so I suspected there was packet loss > going on somewhere between them and our colo facility. > > I did a few trace routes from our firewall to the client's IP and most of > the time they look fine, however I occasionally see some packet loss. > > Good trace route: > > 1 65.61.0.97 0 msec 0 msec 0 msec > 2 107.1.118.217 0 msec 10 msec 0 msec > 3 69.139.194.21 0 msec 0 msec 0 msec > 4 68.86.147.129 10 msec 10 msec 20 msec > 5 68.86.94.169 20 msec 30 msec 20 msec > 6 68.86.86.26 20 msec 20 msec 10 msec > 7 216.6.87.97 10 msec 20 msec 20 msec > 8 216.6.87.34 10 msec 20 msec 10 msec > 9 152.63.34.22 20 msec 10 msec 20 msec > 10 130.81.28.255 30 msec 30 msec 20 msec > > Traceroutes with packet loss (8th hop): > > 1 65.61.0.97 0 msec 0 msec 0 msec > 2 107.1.118.217 0 msec 10 msec 0 msec > 3 69.139.194.21 0 msec 0 msec 0 msec > 4 68.86.147.129 20 msec 10 msec 10 msec > 5 68.86.94.169 20 msec 20 msec 30 msec > 6 68.86.86.26 20 msec 20 msec 10 msec > 7 216.6.87.97 10 msec 20 msec 30 msec > 8 216.6.87.34 10 msec * 10 msec > 9 152.63.34.22 140 msec 110 msec 20 msec > 10 130.81.28.255 20 msec 30 msec 30 msec > > 1 65.61.0.97 10 msec 0 msec 0 msec > 2 107.1.118.217 0 msec 10 msec 0 msec > 3 69.139.194.21 0 msec 0 msec 0 msec > 4 68.86.147.129 20 msec 20 msec 10 msec > 5 68.86.94.169 30 msec 20 msec 20 msec > 6 68.86.86.26 20 msec 20 msec 20 msec > 7 216.6.87.97 20 msec 10 msec 20 msec > 8 216.6.87.34 20 msec 40 msec * > 9 152.63.34.22 20 msec 10 msec 10 msec > 10 130.81.28.255 30 msec 30 msec 20 msec > > It appears the 8th hop occasionally has packet loss. > > Thanks, > Derek > From djahandarie at gmail.com Wed Sep 26 17:16:04 2012 From: djahandarie at gmail.com (Darius Jahandarie) Date: Wed, 26 Sep 2012 13:16:04 -0400 Subject: Anyone from Verizon/TATA on here? Possible Packet Loss In-Reply-To: References: Message-ID: On Wed, Sep 26, 2012 at 1:10 PM, Blake Dunlap wrote: > This is not the proper way to interpret traceroute information. Also, 3 > pings is not sufficient to determine levels of packet loss statistically. > > I suggest searching the archives regarding traceroute, or googling how to > interpret them in regards to packet loss, as what you posted does not > indicate what you think it does. Agreed. Derek should read "A Practical Guide to (Correctly) Troubleshooting with Traceroute": http://www.nanog.org/meetings/nanog45/presentations/Sunday/RAS_traceroute_N45.pdf -- Darius Jahandarie From derek at derekivey.com Wed Sep 26 17:54:04 2012 From: derek at derekivey.com (Derek Ivey) Date: Wed, 26 Sep 2012 13:54:04 -0400 Subject: Anyone from Verizon/TATA on here? Possible Packet Loss In-Reply-To: References: Message-ID: <42FFDE3C-D460-4759-BEFF-D407563D791C@derekivey.com> Thanks guys. That was an informative read. I will do some more troubleshooting. Derek On Sep 26, 2012, at 1:16 PM, Darius Jahandarie wrote: > On Wed, Sep 26, 2012 at 1:10 PM, Blake Dunlap wrote: >> This is not the proper way to interpret traceroute information. Also, 3 >> pings is not sufficient to determine levels of packet loss statistically. >> >> I suggest searching the archives regarding traceroute, or googling how to >> interpret them in regards to packet loss, as what you posted does not >> indicate what you think it does. > > Agreed. Derek should read "A Practical Guide to (Correctly) > Troubleshooting with Traceroute": > http://www.nanog.org/meetings/nanog45/presentations/Sunday/RAS_traceroute_N45.pdf > > -- > Darius Jahandarie From jra at baylink.com Wed Sep 26 18:26:31 2012 From: jra at baylink.com (Jay Ashworth) Date: Wed, 26 Sep 2012 14:26:31 -0400 (EDT) Subject: The optimistically named Project Moonshot (was Re: POLL: 802.1x deployment) In-Reply-To: <5062B4E7.5090102@luddite.com.au> Message-ID: <16646423.26768.1348683991282.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Peter J. Cherny" > I've (re)sent this to the list as no-one else has noted it > > Possibly a game-changer in the (academic) 802.1x space ... > http://www.project-moonshot.org/diary > http://www.painless-security.com/blog/ I did see that come in, and was going to look into it more deeply tonight; if it is -- as it appears to be -- a framework for globally federated identification/authentication, then it will probably hit the same walls (of theory, not merely implementation) which other earlier attempts have hit: privacy and non-correlation being prime among them. It's orthogonal to 802.1x, though, unless anyone's shipping code to hook a dot1x server to it as you would, say, a Radius server. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From derek at derekivey.com Wed Sep 26 18:37:42 2012 From: derek at derekivey.com (Derek Ivey) Date: Wed, 26 Sep 2012 14:37:42 -0400 Subject: Anyone from Verizon/TATA on here? Possible Packet Loss In-Reply-To: <42FFDE3C-D460-4759-BEFF-D407563D791C@derekivey.com> References: <42FFDE3C-D460-4759-BEFF-D407563D791C@derekivey.com> Message-ID: After some further troubleshooting, I believe I have narrowed down the issue to one of Verizon's routers (130.81.28.255). ping 130.81.28.255 repeat 100 Type escape sequence to abort. Sending 100, 100-byte ICMP Echos to 130.81.28.255, timeout is 2 seconds: ?!!!!!!!!?!!!!!!!?!!!!!!!!?!!!!!!!!!!!!!!!?!!!!!!!!!!!!!!?!!!!!!!!!!!? !!!!!!!!!!!!!!!!!!!!!!?!!!?!!! Success rate is 91 percent (91/100), round-trip min/avg/max = 20/26/30 ms I had my client send me the output of the ping command (100 pings) and a trace route. Their 5th hop is 130.81.28.254 and one of the response times in their trace route was 175ms so the issue seems to be around there. I asked them to open a ticket with Verizon to take a look. Thanks, Derek On Sep 26, 2012, at 1:54 PM, Derek Ivey wrote: > Thanks guys. That was an informative read. I will do some more troubleshooting. > > Derek > > On Sep 26, 2012, at 1:16 PM, Darius Jahandarie wrote: > >> On Wed, Sep 26, 2012 at 1:10 PM, Blake Dunlap wrote: >>> This is not the proper way to interpret traceroute information. Also, 3 >>> pings is not sufficient to determine levels of packet loss statistically. >>> >>> I suggest searching the archives regarding traceroute, or googling how to >>> interpret them in regards to packet loss, as what you posted does not >>> indicate what you think it does. >> >> Agreed. Derek should read "A Practical Guide to (Correctly) >> Troubleshooting with Traceroute": >> http://www.nanog.org/meetings/nanog45/presentations/Sunday/RAS_traceroute_N45.pdf >> >> -- >> Darius Jahandarie > From jrhett at netconsonance.com Wed Sep 26 19:02:04 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed, 26 Sep 2012 12:02:04 -0700 Subject: Anyone from Verizon/TATA on here? Possible Packet Loss In-Reply-To: References: <42FFDE3C-D460-4759-BEFF-D407563D791C@derekivey.com> Message-ID: <18D0C1D3-6FEE-4963-B8C8-ED3A05FE3513@netconsonance.com> Many (most?) routers deprioritize ICMP meesages. Direct pings against the router are not informative re transit failures. On Sep 26, 2012, at 11:37 AM, Derek Ivey wrote: > After some further troubleshooting, I believe I have narrowed down the issue to one of Verizon's routers (130.81.28.255). > > ping 130.81.28.255 repeat 100 > Type escape sequence to abort. > Sending 100, 100-byte ICMP Echos to 130.81.28.255, timeout is 2 seconds: > ?!!!!!!!!?!!!!!!!?!!!!!!!!?!!!!!!!!!!!!!!!?!!!!!!!!!!!!!!?!!!!!!!!!!!? > !!!!!!!!!!!!!!!!!!!!!!?!!!?!!! > Success rate is 91 percent (91/100), round-trip min/avg/max = 20/26/30 ms > > I had my client send me the output of the ping command (100 pings) and a trace route. > > Their 5th hop is 130.81.28.254 and one of the response times in their trace route was 175ms so the issue seems to be around there. > > I asked them to open a ticket with Verizon to take a look. > > Thanks, > Derek > > On Sep 26, 2012, at 1:54 PM, Derek Ivey wrote: > >> Thanks guys. That was an informative read. I will do some more troubleshooting. >> >> Derek >> >> On Sep 26, 2012, at 1:16 PM, Darius Jahandarie wrote: >> >>> On Wed, Sep 26, 2012 at 1:10 PM, Blake Dunlap wrote: >>>> This is not the proper way to interpret traceroute information. Also, 3 >>>> pings is not sufficient to determine levels of packet loss statistically. >>>> >>>> I suggest searching the archives regarding traceroute, or googling how to >>>> interpret them in regards to packet loss, as what you posted does not >>>> indicate what you think it does. >>> >>> Agreed. Derek should read "A Practical Guide to (Correctly) >>> Troubleshooting with Traceroute": >>> http://www.nanog.org/meetings/nanog45/presentations/Sunday/RAS_traceroute_N45.pdf >>> >>> -- >>> Darius Jahandarie >> > > -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. From alexis at pellitteri.com.ar Wed Sep 26 19:18:43 2012 From: alexis at pellitteri.com.ar (Pellitteri Alexis) Date: Wed, 26 Sep 2012 16:18:43 -0300 Subject: Anyone from Verizon/TATA on here? Possible Packet Loss In-Reply-To: <18D0C1D3-6FEE-4963-B8C8-ED3A05FE3513@netconsonance.com> References: <42FFDE3C-D460-4759-BEFF-D407563D791C@derekivey.com> <18D0C1D3-6FEE-4963-B8C8-ED3A05FE3513@netconsonance.com> Message-ID: <50635513.2050807@pellitteri.com.ar> That router might be experiencing a high CPU load, thus not being able to reply ICMP on a timely manner or maybe QoS policies are influencing depending on the kind of traffic the router deals with. If packets are only being delayed/lost on that segment, I would start my analysis there. On 09/26/2012 04:02 PM, Jo Rhett wrote: > Many (most?) routers deprioritize ICMP meesages. Direct pings against the router are not informative re transit failures. > > On Sep 26, 2012, at 11:37 AM, Derek Ivey wrote: >> After some further troubleshooting, I believe I have narrowed down the issue to one of Verizon's routers (130.81.28.255). >> >> ping 130.81.28.255 repeat 100 >> Type escape sequence to abort. >> Sending 100, 100-byte ICMP Echos to 130.81.28.255, timeout is 2 seconds: >> ?!!!!!!!!?!!!!!!!?!!!!!!!!?!!!!!!!!!!!!!!!?!!!!!!!!!!!!!!?!!!!!!!!!!!? >> !!!!!!!!!!!!!!!!!!!!!!?!!!?!!! >> Success rate is 91 percent (91/100), round-trip min/avg/max = 20/26/30 ms >> >> I had my client send me the output of the ping command (100 pings) and a trace route. >> >> Their 5th hop is 130.81.28.254 and one of the response times in their trace route was 175ms so the issue seems to be around there. >> >> I asked them to open a ticket with Verizon to take a look. >> >> Thanks, >> Derek >> >> On Sep 26, 2012, at 1:54 PM, Derek Ivey wrote: >> >>> Thanks guys. That was an informative read. I will do some more troubleshooting. >>> >>> Derek >>> >>> On Sep 26, 2012, at 1:16 PM, Darius Jahandarie wrote: >>> >>>> On Wed, Sep 26, 2012 at 1:10 PM, Blake Dunlap wrote: >>>>> This is not the proper way to interpret traceroute information. Also, 3 >>>>> pings is not sufficient to determine levels of packet loss statistically. >>>>> >>>>> I suggest searching the archives regarding traceroute, or googling how to >>>>> interpret them in regards to packet loss, as what you posted does not >>>>> indicate what you think it does. >>>> Agreed. Derek should read "A Practical Guide to (Correctly) >>>> Troubleshooting with Traceroute": >>>> http://www.nanog.org/meetings/nanog45/presentations/Sunday/RAS_traceroute_N45.pdf >>>> >>>> -- >>>> Darius Jahandarie >> From alexis at pellitteri.com.ar Wed Sep 26 19:19:48 2012 From: alexis at pellitteri.com.ar (Pellitteri Alexis) Date: Wed, 26 Sep 2012 16:19:48 -0300 Subject: Anyone from Verizon/TATA on here? Possible Packet Loss In-Reply-To: <18D0C1D3-6FEE-4963-B8C8-ED3A05FE3513@netconsonance.com> References: <42FFDE3C-D460-4759-BEFF-D407563D791C@derekivey.com> <18D0C1D3-6FEE-4963-B8C8-ED3A05FE3513@netconsonance.com> Message-ID: <50635554.70905@pellitteri.com.ar> That router might be experiencing a high CPU load, thus not being able to reply ICMP on a timely manner or maybe QoS policies are influencing depending on the kind of traffic the router deals with. If packets are only being delayed/lost on that segment, I would start my analysis there. On 09/26/2012 04:02 PM, Jo Rhett wrote: Many (most?) routers deprioritize ICMP meesages. Direct pings against the router are not informative re transit failures. On Sep 26, 2012, at 11:37 AM, Derek Ivey wrote: > After some further troubleshooting, I believe I have narrowed down the issue to one of Verizon's routers (130.81.28.255). > > ping 130.81.28.255 repeat 100 > Type escape sequence to abort. > Sending 100, 100-byte ICMP Echos to 130.81.28.255, timeout is 2 seconds: > ?!!!!!!!!?!!!!!!!?!!!!!!!!?!!!!!!!!!!!!!!!?!!!!!!!!!!!!!!?!!!!!!!!!!!? > !!!!!!!!!!!!!!!!!!!!!!?!!!?!!! > Success rate is 91 percent (91/100), round-trip min/avg/max = 20/26/30 ms > > I had my client send me the output of the ping command (100 pings) and a trace route. > > Their 5th hop is 130.81.28.254 and one of the response times in their trace route was 175ms so the issue seems to be around there. > > I asked them to open a ticket with Verizon to take a look. > > Thanks, > Derek > > On Sep 26, 2012, at 1:54 PM, Derek Ivey wrote: > >> Thanks guys. That was an informative read. I will do some more troubleshooting. >> >> Derek >> >> On Sep 26, 2012, at 1:16 PM, Darius Jahandarie wrote: >> >>> On Wed, Sep 26, 2012 at 1:10 PM, Blake Dunlap wrote: >>>> This is not the proper way to interpret traceroute information. Also, 3 >>>> pings is not sufficient to determine levels of packet loss statistically. >>>> >>>> I suggest searching the archives regarding traceroute, or googling how to >>>> interpret them in regards to packet loss, as what you posted does not >>>> indicate what you think it does. >>> Agreed. Derek should read "A Practical Guide to (Correctly) >>> Troubleshooting with Traceroute": >>> http://www.nanog.org/meetings/nanog45/presentations/Sunday/RAS_traceroute_N45.pdf >>> >>> -- >>> Darius Jahandarie From rsm at fast-serv.com Wed Sep 26 21:34:48 2012 From: rsm at fast-serv.com (Randy McAnally) Date: Wed, 26 Sep 2012 17:34:48 -0400 Subject: Verizon FIOS troubleshooting In-Reply-To: <50623A08.8000908@bsd-unix.net> References: <50623A08.8000908@bsd-unix.net> Message-ID: <35c1bd92e2083e4d705a3827bd4c916b@mailbox.fastserv.com> On 09/25/2012 7:11 pm, Bryan Seitz wrote: > Recently began seeing things like this to the default GW from > inside and outside the FIOS network. Called tech support but all > they > could do was put a ticket in for the NetEng team. > > http://pastie.org/4800421 > http://www.bsd-unix.net/smokeping/smokeping.cgi?target=people.bryan I worked with Brian offline and can confirm there's definitely an issue, at least on his particular node/area (W.D.C.). Anyone from Verizon lurking? -- Randy M From derek at derekivey.com Thu Sep 27 00:45:54 2012 From: derek at derekivey.com (Derek Ivey) Date: Wed, 26 Sep 2012 20:45:54 -0400 Subject: Anyone from Verizon/TATA on here? Possible Packet Loss In-Reply-To: <50635554.70905@pellitteri.com.ar> References: <42FFDE3C-D460-4759-BEFF-D407563D791C@derekivey.com> <18D0C1D3-6FEE-4963-B8C8-ED3A05FE3513@netconsonance.com> <50635554.70905@pellitteri.com.ar> Message-ID: <5063A1C2.90001@derekivey.com> I'm at home now. I also have Verizon FiOS and believe I am seeing the same thing our client saw. So you guys are saying that the response times in traceroutes might not always be accurate because routers prioritize ICMP messages. Does that mean values from MTR aren't accurate? I fired up MTR and took 2 screenshots (http://imgur.com/a/RDyXO). What do you guys think? Most of the time the ping times seem fairly low, however I occasionally see these spikes. It seems sporadic... My boss also has FiOS and he is seeing the same thing. Pages load quick most of the time and sometimes take awhile to load. Thanks, Derek On 9/26/2012 3:19 PM, Pellitteri Alexis wrote: > That router might be experiencing a high CPU load, thus not being able > to reply ICMP on a timely manner or maybe QoS policies are influencing > depending on the kind of traffic the router deals with. > > If packets are only being delayed/lost on that segment, I would start > my analysis there. > > > On 09/26/2012 04:02 PM, Jo Rhett wrote: > > Many (most?) routers deprioritize ICMP meesages. Direct pings against > the router are not informative re transit failures. > > On Sep 26, 2012, at 11:37 AM, Derek Ivey wrote: > >> After some further troubleshooting, I believe I have narrowed down >> the issue to one of Verizon's routers (130.81.28.255). >> >> ping 130.81.28.255 repeat 100 >> Type escape sequence to abort. >> Sending 100, 100-byte ICMP Echos to 130.81.28.255, timeout is 2 seconds: >> ?!!!!!!!!?!!!!!!!?!!!!!!!!?!!!!!!!!!!!!!!!?!!!!!!!!!!!!!!?!!!!!!!!!!!? >> !!!!!!!!!!!!!!!!!!!!!!?!!!?!!! >> Success rate is 91 percent (91/100), round-trip min/avg/max = >> 20/26/30 ms >> >> I had my client send me the output of the ping command (100 pings) >> and a trace route. >> >> Their 5th hop is 130.81.28.254 and one of the response times in their >> trace route was 175ms so the issue seems to be around there. >> >> I asked them to open a ticket with Verizon to take a look. >> >> Thanks, >> Derek >> >> On Sep 26, 2012, at 1:54 PM, Derek Ivey wrote: >> >>> Thanks guys. That was an informative read. I will do some more >>> troubleshooting. >>> >>> Derek >>> >>> On Sep 26, 2012, at 1:16 PM, Darius Jahandarie >>> wrote: >>> >>>> On Wed, Sep 26, 2012 at 1:10 PM, Blake Dunlap >>>> wrote: >>>>> This is not the proper way to interpret traceroute information. >>>>> Also, 3 >>>>> pings is not sufficient to determine levels of packet loss >>>>> statistically. >>>>> >>>>> I suggest searching the archives regarding traceroute, or googling >>>>> how to >>>>> interpret them in regards to packet loss, as what you posted does not >>>>> indicate what you think it does. >>>> Agreed. Derek should read "A Practical Guide to (Correctly) >>>> Troubleshooting with Traceroute": >>>> http://www.nanog.org/meetings/nanog45/presentations/Sunday/RAS_traceroute_N45.pdf >>>> >>>> >>>> -- >>>> Darius Jahandarie > > From jra at baylink.com Thu Sep 27 01:11:16 2012 From: jra at baylink.com (Jay Ashworth) Date: Wed, 26 Sep 2012 21:11:16 -0400 (EDT) Subject: Anyone from Verizon/TATA on here? Possible Packet Loss In-Reply-To: <5063A1C2.90001@derekivey.com> Message-ID: <4912650.26828.1348708276322.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Derek Ivey" > I'm at home now. I also have Verizon FiOS and believe I am seeing the > same thing our client saw. So you guys are saying that the response > times in traceroutes might not always be accurate because routers > prioritize ICMP messages. Does that mean values from MTR aren't > accurate? I fired up MTR and took 2 screenshots > (http://imgur.com/a/RDyXO). What do you guys think? Most of the time > the ping times seem fairly low, however I occasionally see these spikes. > It seems sporadic... To recap, traceroute, mtr, and similar utilities work by talking to each succesive router along a path. Because this is so, and because Any Given Router may be too busy to deal with such packets in favor of "real" traffic (most routers handle data packets on the line cards, while they may have to expend actual CPU on things like ICMP), it's possible for a path with perfect connectivity to show some intermediate hops completely missing -- No Reply At All, you might say -- to diagnostic tools. The traces you show look pretty decent; I've seen much worse on links with fine interactive shell session response. The time you have to worry is when one router *and everything past it* shows packet loss of roughly the same amount, or when ping times jump markedly at a given spot (by which I mean, say, from 32 to 800ms, rather than from 32 to 125). The short version, though, which most people are are being uncharacteristically too nice to say (:-) is that this is still a tier 1 problem, and NANOG is generally tier 3 or 4. :-) You're welcome to take the issue up over on outages at outages.org, if you like... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From derek at derekivey.com Thu Sep 27 01:21:57 2012 From: derek at derekivey.com (Derek Ivey) Date: Wed, 26 Sep 2012 21:21:57 -0400 Subject: Anyone from Verizon/TATA on here? Possible Packet Loss In-Reply-To: <4912650.26828.1348708276322.JavaMail.root@benjamin.baylink.com> References: <4912650.26828.1348708276322.JavaMail.root@benjamin.baylink.com> Message-ID: <5063AA35.5040303@derekivey.com> Thanks guys. Sorry for the noise... Derek On 9/26/2012 9:11 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Derek Ivey" >> I'm at home now. I also have Verizon FiOS and believe I am seeing the >> same thing our client saw. So you guys are saying that the response >> times in traceroutes might not always be accurate because routers >> prioritize ICMP messages. Does that mean values from MTR aren't >> accurate? I fired up MTR and took 2 screenshots >> (http://imgur.com/a/RDyXO). What do you guys think? Most of the time >> the ping times seem fairly low, however I occasionally see these spikes. >> It seems sporadic... > To recap, traceroute, mtr, and similar utilities work by talking to each > succesive router along a path. Because this is so, and because Any Given > Router may be too busy to deal with such packets in favor of "real" traffic > (most routers handle data packets on the line cards, while they may have > to expend actual CPU on things like ICMP), it's possible for a path with > perfect connectivity to show some intermediate hops completely missing -- > No Reply At All, you might say -- to diagnostic tools. > > The traces you show look pretty decent; I've seen much worse on links > with fine interactive shell session response. The time you have to > worry is when one router *and everything past it* shows packet loss of > roughly the same amount, or when ping times jump markedly at a given > spot (by which I mean, say, from 32 to 800ms, rather than from 32 to 125). > > The short version, though, which most people are are being uncharacteristically > too nice to say (:-) is that this is still a tier 1 problem, and NANOG is > generally tier 3 or 4. :-) > > You're welcome to take the issue up over on outages at outages.org, if you > like... > > Cheers, > -- jra From adam.vitkovsky at swan.sk Thu Sep 27 07:39:29 2012 From: adam.vitkovsky at swan.sk (Adam Vitkovsky) Date: Thu, 27 Sep 2012 09:39:29 +0200 Subject: Ethernet OAM BCPs Please are there any yet??? In-Reply-To: References: <024001cd9bc9$4bdeb230$e39c1690$@swan.sk> Message-ID: <000b01cd9c83$3a6181d0$af248570$@swan.sk> Thank you so much Jonathon. This is exactly what I what I was searching for. Oh and yes I should have mentioned I'd like to do the Y.1731 and measure the delay and delay variance Just yesterday evening I found a great article about how ATT did theirs active measurements though for IP - wondering if I could do the same for my Y.1731 They used dedicated servers and I'll be running this form the routers ME3600X and CX and ASR9K so I'm a bit worried about the scaling of the whole thing ATT basically used two probes and each 24-hour day is divided into 96 test cycles of 15 minutes A Poisson probe sequence of duration equal to the test cycle characteristics: - Poisson distribution with average interarrival time of 3.3 s - Packet size of 278 bytes, including headers - UDP protocol Two periodic probe sequences in every test characteristics: - Interval of 20 ms between successive packets (or 50 packets/s) - 1 min duration - Random start time within the 15 min cycle - Packet size of 60 bytes (including headers) - UDP protocol adam -----Original Message----- From: Jonathon Exley [mailto:Jonathon.Exley at kordia.co.nz] Sent: Wednesday, September 26, 2012 6:34 PM To: nanog at nanog.org Subject: RE: Ethernet OAM BCPs Please are there any yet??? The ITU recommend the following levels: 5,6,7 = Customer 3,4 = Provider 1,2 = Operator 0 = Local segment I don't know if there are any rules of thumb for the CCM interval - faster is more sensitive & unstable, slow is sluggish but stable. The spec allows between 3.33 ms and 10 minutes in 7 steps, with 1s being the midpoint. So we use 1s intervals. I'm not sure if the other parameters you mention are configurable for CCM. I think the packet has a constant size. Are you wanting to also do Y.1731 performance management? Jonathon > -----Original Message----- > From: Adam Vitkovsky [mailto:adam.vitkovsky at swan.sk] > Sent: Wednesday, 26 September 2012 9:29 p.m. > To: nanog at nanog.org > Subject: Ethernet OAM BCPs Please are there any yet??? > > Hi > Are there any best common practices for the CFM levels use Since my > pure Ethernet aggregation layers are small I believe I only need two > CFM levels I plan on using Level 5 between CPEs managed by us and > Level 4 between Aggregation devices -that's where MPLS PWs kicks in So > leaving Level 7 and Level 6 for customers and carrier-customers > respectfully -would this be enough please? > > I'm also interested on what's the rule of thumb for CCMs Frequency, > Number of Packets, Interpacket Interval, Packet Size and Lifetime for > the particular operation Thanks a lot for any inputs This email and attachments: are confidential; may be protected by privilege and copyright; if received in error may not be used, copied, or kept; are not guaranteed to be virus-free; may not express the views of Kordia(R); do not designate an information system; and do not give rise to any liability for Kordia(R). From eugen at leitl.org Thu Sep 27 09:23:34 2012 From: eugen at leitl.org (Eugen Leitl) Date: Thu, 27 Sep 2012 11:23:34 +0200 Subject: is CERNET part of the Internet? Message-ID: <20120927092334.GY9750@leitl.org> I'm trying to figure out whether CERNET http://en.wikipedia.org/wiki/CERNET is part of the official Internet, or is behind the Great Firewall where access to invididual networks on the public Internet must be explicitly granted. Anyone in the know? From bortzmeyer at nic.fr Thu Sep 27 09:31:03 2012 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 27 Sep 2012 11:31:03 +0200 Subject: is CERNET part of the Internet? In-Reply-To: <20120927092334.GY9750@leitl.org> References: <20120927092334.GY9750@leitl.org> Message-ID: <20120927093103.GA23541@nic.fr> On Thu, Sep 27, 2012 at 11:23:34AM +0200, Eugen Leitl wrote a message of 5 lines which said: > the official Internet I wasn't aware there is an official Internet. Where is it? From jeroen at unfix.org Thu Sep 27 09:33:10 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 27 Sep 2012 11:33:10 +0200 Subject: is CERNET part of the Internet? In-Reply-To: <20120927092334.GY9750@leitl.org> References: <20120927092334.GY9750@leitl.org> Message-ID: <50641D56.1000907@unfix.org> On 2012-09-27 11:23 , Eugen Leitl wrote: > > I'm trying to figure out whether CERNET http://en.wikipedia.org/wiki/CERNET > is part of the official Internet, There is no 'official Internet', there is a 'view on the Internet'. Note that if you would do an eyeball count the 'official' one would be the Chinese one as there are potentially more people looking at it there... To answer your subject line though: yes CERNET is part of the Internet, they have IP addresses from IANA through their RIR APNIC and their website be reached from most locations on the general thing called the Internet. CERNET is IPv6-only for large portions though and those are not behind the GFW as they do not do IPv6 for that (yet at least as far as it is known). > or is behind the Great Firewall where > access to invididual networks on the public Internet must be explicitly > granted. Anyone in the know? Everything in China is behind their content filter. Only parts of Hong Kong are sometimes not yet. As far as it is known they do not 'allow' things but block specific things. I suggest you go through http://freehaven.net/anonbib/ for a good read about the various things that are known about the thing we call GFW. Greets, Jeroen From drohan at gmail.com Thu Sep 27 09:39:36 2012 From: drohan at gmail.com (Daniel Rohan) Date: Thu, 27 Sep 2012 12:39:36 +0300 Subject: is CERNET part of the Internet? In-Reply-To: <20120927092334.GY9750@leitl.org> References: <20120927092334.GY9750@leitl.org> Message-ID: On Thu, Sep 27, 2012 at 12:23 PM, Eugen Leitl wrote: > > I'm trying to figure out whether CERNET http://en.wikipedia.org/wiki/CERNET > is part of the official Internet, or is behind the Great Firewall where > access to invididual networks on the public Internet must be explicitly > granted. Anyone in the know? > Here's one of their many v4 networks from level 3: BGP routing table entry for 202.38.64.0/18 Paths: (2 available, best #1) 10026 4538 4538 4538 4538, (aggregated by 4538 202.112.60.1) AS-path translation: { APNIC-AS-3-BLOCK CERNET-BKB CERNET-BKB CERNET-BKB CERNET-BKB } edge2.SanJose3 (metric 26107) Origin IGP, localpref 100, valid, internal, atomic-aggregate, best Community: North_America Lclprf_100 Level3_Customer United_States San_Jose 10026:4200 10026:32344 10026:40104 Originator: edge2.SanJose3 10026 4538 4538 4538 4538, (aggregated by 4538 202.112.60.1) AS-path translation: { APNIC-AS-3-BLOCK CERNET-BKB CERNET-BKB CERNET-BKB CERNET-BKB } edge2.SanJose3 (metric 26107) Origin IGP, localpref 100, valid, internal, atomic-aggregate Community: North_America Lclprf_100 Level3_Customer United_States San_Jose 10026:4200 10026:32344 10026:40104 Originator: edge2.SanJose3 From askoorb+nanog at gmail.com Thu Sep 27 10:28:18 2012 From: askoorb+nanog at gmail.com (Alex Brooks) Date: Thu, 27 Sep 2012 11:28:18 +0100 Subject: is CERNET part of the Internet? In-Reply-To: <50641D56.1000907@unfix.org> References: <20120927092334.GY9750@leitl.org> <50641D56.1000907@unfix.org> Message-ID: Hi, On Thu, Sep 27, 2012 at 10:33 AM, Jeroen Massar wrote: > On 2012-09-27 11:23 , Eugen Leitl wrote: > > > > I'm trying to figure out whether CERNET > http://en.wikipedia.org/wiki/CERNET > > is part of the official Internet, > > There is no 'official Internet', there is a 'view on the Internet'. > > > or is behind the Great Firewall where > > access to invididual networks on the public Internet must be explicitly > > granted. Anyone in the know? > > Everything in China is behind their content filter. Only parts of Hong > Kong are sometimes not yet. As far as it is known they do not 'allow' > things but block specific things. > > I suggest you go through http://freehaven.net/anonbib/ for a good read > about the various things that are known about the thing we call GFW. > > A report was published about net 'freedom' in various countries three days ago that may be worth a read in relation to this topic: http://www.freedomhouse.org/sites/default/files/inline_images/FOTN%202012%20FINAL.pdf Alex From kemp at buddylove.uoregon.edu Thu Sep 27 12:47:38 2012 From: kemp at buddylove.uoregon.edu (John Kemp) Date: Thu, 27 Sep 2012 05:47:38 -0700 Subject: IMPLEMENTING A SOFTWARE BASED ROUTE SERVER In-Reply-To: <505AC713.5050004@network-services.uoregon.edu> References: <9be1f04b-6f4d-4d68-b11b-800519832f77@MX-IX-NBO> <122ed7f9-a760-4aea-9abe-da7572de9385@MX-IX-NBO> <20120919122952.GT90817@macbook.bluepipe.net> <505AC713.5050004@network-services.uoregon.edu> Message-ID: <50644AEA.9010602@buddylove.uoregon.edu> On 09/20/2012 12:34 AM, John Kemp wrote: > On 9/19/12 5:29 AM, Phil Regnauld wrote: >> Joseph M. Owino (jpmuga) writes: >>> Hi, >>> >>> Hope you are all well. I work at an exchange point and was seeking any assistance on how to implement a software based route server as currently we are using a Cisco Router for that purpose. Any form of assistance will be highly appreciated. >> Hello Joseph, >> >> You could do this in a number of ways, running Quagga or BIRD (or even >> BGPD) on a Linux or BSD server. >> >> Quagga documentation even has a chapter on this: >> >> http://www.nongnu.org/quagga/docs/quagga.html#SEC115 >> >> >> I'm sure several people on this list have experience with this and will >> contribute. Also, it might be send this inquiry to the AfNOG list as well >> (afnog.org). >> >> Finally (plug) we have some resources that may be of interest to you here: >> >> https://nsrc.org/route-bgp-ixp.html >> >> Cheers, >> Phil >> > Thought I would add some more links (Bird related...). > Seems like the genesis has been from a single-rib on the RS > to RIBs-per-client. And more recently to using the IRRs for > additional filtering options. AMS-IX for example: > https://www.ams-ix.net/technical/specifications-descriptions/ams-ix-route-servers > > Here's that BIRD stuff... > http://www.peering-forum.eu/epf3/presentations/day1/inex-epf-dublin-2008-09-15-01.pdf > https://git.nic.cz/redmine/projects/bird/wiki/Route_server_with_community_based_filtering > http://www.mail-archive.com/bird-users at atrey.karlin.mff.cuni.cz/msg00505.html > ) A few more comments on this ... At the recent RIPE meeting Ondrej Filip has a new feature called "secondary" that may be a work-around to get away from RIB-per-client. Presentation is here: https://ripe65.ripe.net/presentations/191-BIRD-20120926-OF-RIPE-EIX.pdf There was also a decent talk about a proposed draft for best current practices for BGP security at the IXP. Worth a read. https://ripe65.ripe.net/presentations/256-draft-jdurand-bgp-security-02-RIPE65-02.pdf John Kemp (kemp at routeviews.org) From eugen at leitl.org Thu Sep 27 12:51:57 2012 From: eugen at leitl.org (Eugen Leitl) Date: Thu, 27 Sep 2012 14:51:57 +0200 Subject: /. Terabit Ethernet is Dead, for Now Message-ID: <20120927125157.GT9750@leitl.org> http://slashdot.org/topic/datacenter/terabit-ethernet-is-dead-for-now/ Terabit Ethernet is Dead, for Now by Mark Hachman | September 26, 2012 A straw poll of the IEEE's high-speed Ethernet group finds that 400-Gbits/s is almost unanimously preferred. Sorry, everybody: terabit Ethernet looks like it will have to wait a while longer. The IEEE 802.3 Industry Connections Higher Speed Ethernet Consensus group met this week in Geneva, Switzerland, with attendees concluding?almost to a man?that 400 Gbits/s should be the next step in the evolution of Ethernet. A straw poll at its conclusion found that 61 of the 62 attendees that voted supported 400 Gbits/s as the basis for the near term ?call for interest,? or CFI. The bandwidth call to arms was sounded by a July report by the IEEE, which concluded that, if current trends continue, networks will need to support capacity requirements of 1 terabit per second in 2015 and 10 terabits per second by 2020. In 2015 there will be nearly 15 billion fixed and mobile-networked devices and machine-to-machine connections. The report goes on to predict that, from 2010 to 2015, global IP traffic will experience a fourfold increase from 20 exabytes per month in 2010 to 81 exabytes per month in 2015, a 32 percent CAGR. Storage growth is expected to grow to 7910 exabytes in 2015, with over half of it accessed via Ethernet. Of course, one of the first places the new, faster Ethernet links will occur will be in the data center. With that in mind, the IEEE 802.3 group began formulating a response. However, virtually all attendees seemed to be in agreement before the meeting opened, as only one presentation focused on the feasibility of one-terabit Ethernet, eventually concluding that 400 Gbits/s made more sense in the near term. Kai Cui and Peter Stassar from Huawei Technologies suggested that the most cost-effective method for developing a 1-terabit Physical Medium Dependent (PMD) would be to leverage today?s 100-Gbit technology, which isn?t yet in high volume, and therefore not cost-optimized. ?[The] cost target for 1Tb/s needs to be at or below 100G cost/bit*sec and required R&D investments should be modest,? they wrote as part of their presentation. ?100GbE technology based architecture would imply 40 lanes at 25G, which clearly would imply impractically big packages and large amount of interface signals,? Cui and Stassar added, which would need to reduce the number of electrical and optical interface lanes to enable a reasonable package size. While alternative modulation formats could be used (5?x200G DP-16QAM, 4 bits/symbol, 25G) ?neither the multi-level nor the phase modulation format based technologies have been demonstrated to be sufficiently mature to justify usage in client PMDs towards 100Gb/s to 1Tb/s applications.? They concluded: ?1Tb/s does seem a ?bridge too far? at least for the coming 3 to 4 years.? Chris Cole of optical components maker Finisar presented the case for a 400-Gbit CFI, with backing from Brocade, Cisco, HP, IBM, Intel, Juniper, and Verizon, among others. Like Huawei?s Cui and Stassar, Cole indicated that 400-Gbit Ethernet can reuse 100 GbE building blocks, and fits within the existing dense 100 GbE roadmap. Faster data rates require ?exotic? implementations, with higher R&D investments required and a longer time to market. ?Data rates beyond 400Gb/s require an increasingly impractical number of lanes if 100GbE technology is reused,? he said. 400 Gbit/s also makes more sense than a 4?100 Gb/s link aggregation, Cole added, as fewer items promotes management efficiency. Individual link congestion is also a concern: ?Without faster links, [the] link count grows exponentially, therefore management pain grows exponentially.? Cole suggested that a potential 400 Gb/s MAC/PCS ASIC could be fabricated in either 20- or 28-nm CMOS, using a 400-bit wide bus and a 1 GHz clock rate. ?There is a strong desire to reuse 802.3ba, 802.3bj, and 802.3bm technology building blocks,? he said. That?s not to say that terabit Ethernet won?t be needed, Cole concluded, or 1.6 terabit Ethernet, at that. The timeframes for those followon CFIs could be between 3 to 6 years, he said. The CFI hasn?t formally occurred; until it does, nothing has been decided. So far, the most likely dates for formalizing the CFI will take place in either November or next month. But at this point, it looks like terabit Ethernet is a dead duck, at least for the near future. From djahandarie at gmail.com Thu Sep 27 12:58:09 2012 From: djahandarie at gmail.com (Darius Jahandarie) Date: Thu, 27 Sep 2012 08:58:09 -0400 Subject: /. Terabit Ethernet is Dead, for Now In-Reply-To: <20120927125157.GT9750@leitl.org> References: <20120927125157.GT9750@leitl.org> Message-ID: On Thu, Sep 27, 2012 at 8:51 AM, Eugen Leitl wrote: > http://slashdot.org/topic/datacenter/terabit-ethernet-is-dead-for-now/ > > Terabit Ethernet is Dead, for Now I recall 40Gbit/s Ethernet being promoted heavily for similar reasons as the ones in this article, but then 100Gbit/s being the technology that actually ended up in most places. Could this be the same thing happening? -- Darius Jahandarie From bicknell at ufp.org Thu Sep 27 13:04:03 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 27 Sep 2012 06:04:03 -0700 Subject: /. Terabit Ethernet is Dead, for Now In-Reply-To: References: <20120927125157.GT9750@leitl.org> Message-ID: <20120927130403.GA81430@ussenterprise.ufp.org> In a message written on Thu, Sep 27, 2012 at 08:58:09AM -0400, Darius Jahandarie wrote: > I recall 40Gbit/s Ethernet being promoted heavily for similar reasons > as the ones in this article, but then 100Gbit/s being the technology > that actually ended up in most places. Could this be the same thing > happening? Everything I've read sounds like a repeat of the same broken decision making that happened last time. That is unsurprising though, the same people are involved. -- 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 jared at puck.nether.net Thu Sep 27 13:07:59 2012 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 27 Sep 2012 09:07:59 -0400 Subject: /. Terabit Ethernet is Dead, for Now In-Reply-To: References: <20120927125157.GT9750@leitl.org> Message-ID: <23047F2D-0BD7-4DDB-ADC3-54AE56684BEE@puck.nether.net> On Sep 27, 2012, at 8:58 AM, Darius Jahandarie wrote: > I recall 40Gbit/s Ethernet being promoted heavily for similar reasons > as the ones in this article, but then 100Gbit/s being the technology > that actually ended up in most places. Could this be the same thing > happening? I would say yes, except for the physics involved here. Getting the signal done optically is the "easy" part. I'm not concerned if the next step after 100 is 400. It's in the right direction and a fair multiple. There is also a problem in the 100GbE space where the market pricing hasn't yet reached an amount whereby the economics are "close enough" to push people beyond N*10G. - Jared From deleskie at gmail.com Thu Sep 27 13:26:39 2012 From: deleskie at gmail.com (jim deleskie) Date: Thu, 27 Sep 2012 10:26:39 -0300 Subject: /. Terabit Ethernet is Dead, for Now In-Reply-To: <23047F2D-0BD7-4DDB-ADC3-54AE56684BEE@puck.nether.net> References: <20120927125157.GT9750@leitl.org> <23047F2D-0BD7-4DDB-ADC3-54AE56684BEE@puck.nether.net> Message-ID: That problem IMO will only be worse with a 4x speed multiplier over 100G what premium will anyone be willing to spend to have a single 400G pipe over 4 bonded 100G pipes? -jim On Thu, Sep 27, 2012 at 10:07 AM, Jared Mauch wrote: > > On Sep 27, 2012, at 8:58 AM, Darius Jahandarie wrote: > >> I recall 40Gbit/s Ethernet being promoted heavily for similar reasons >> as the ones in this article, but then 100Gbit/s being the technology >> that actually ended up in most places. Could this be the same thing >> happening? > > I would say yes, except for the physics involved here. Getting the signal done optically is the "easy" part. > > I'm not concerned if the next step after 100 is 400. It's in the right direction and a fair multiple. There is also a problem in the 100GbE space where the market pricing hasn't yet reached an amount whereby the economics are "close enough" to push people beyond N*10G. > > - Jared From danshtr at gmail.com Thu Sep 27 13:26:34 2012 From: danshtr at gmail.com (Dan Shechter) Date: Thu, 27 Sep 2012 15:26:34 +0200 Subject: /. Terabit Ethernet is Dead, for Now In-Reply-To: <20120927125157.GT9750@leitl.org> References: <20120927125157.GT9750@leitl.org> Message-ID: If they would have rolled out 1000G networks now, I guess we will have to plug in 17 MTP interfaces ;) HTH, Dan #13685 (RS/Sec/SP) The CCIE troubleshooting blog: http://dans-net.com Bring order to your Private VLAN network: http://marathon-networks.com On Thu, Sep 27, 2012 at 2:51 PM, Eugen Leitl wrote: > > http://slashdot.org/topic/datacenter/terabit-ethernet-is-dead-for-now/ > > Terabit Ethernet is Dead, for Now > > by Mark Hachman | September 26, 2012 > > A straw poll of the IEEE's high-speed Ethernet group finds that 400-Gbits/s > is almost unanimously preferred. > > Sorry, everybody: terabit Ethernet looks like it will have to wait a while > longer. > > The IEEE 802.3 Industry Connections Higher Speed Ethernet Consensus group > met > this week in Geneva, Switzerland, with attendees concluding?almost to a > man?that 400 Gbits/s should be the next step in the evolution of Ethernet. > A > straw poll at its conclusion found that 61 of the 62 attendees that voted > supported 400 Gbits/s as the basis for the near term ?call for interest,? > or > CFI. > > The bandwidth call to arms was sounded by a July report by the IEEE, which > concluded that, if current trends continue, networks will need to support > capacity requirements of 1 terabit per second in 2015 and 10 terabits per > second by 2020. In 2015 there will be nearly 15 billion fixed and > mobile-networked devices and machine-to-machine connections. > > The report goes on to predict that, from 2010 to 2015, global IP traffic > will > experience a fourfold increase from 20 exabytes per month in 2010 to 81 > exabytes per month in 2015, a 32 percent CAGR. Storage growth is expected > to > grow to 7910 exabytes in 2015, with over half of it accessed via Ethernet. > Of > course, one of the first places the new, faster Ethernet links will occur > will be in the data center. > > With that in mind, the IEEE 802.3 group began formulating a response. > However, virtually all attendees seemed to be in agreement before the > meeting > opened, as only one presentation focused on the feasibility of one-terabit > Ethernet, eventually concluding that 400 Gbits/s made more sense in the > near > term. > > Kai Cui and Peter Stassar from Huawei Technologies suggested that the most > cost-effective method for developing a 1-terabit Physical Medium Dependent > (PMD) would be to leverage today?s 100-Gbit technology, which isn?t yet in > high volume, and therefore not cost-optimized. ?[The] cost target for 1Tb/s > needs to be at or below 100G cost/bit*sec and required R&D investments > should > be modest,? they wrote as part of their presentation. > > ?100GbE technology based architecture would imply 40 lanes at 25G, which > clearly would imply impractically big packages and large amount of > interface > signals,? Cui and Stassar added, which would need to reduce the number of > electrical and optical interface lanes to enable a reasonable package size. > While alternative modulation formats could be used (5?x200G DP-16QAM, 4 > bits/symbol, 25G) ?neither the multi-level nor the phase modulation format > based technologies have been demonstrated to be sufficiently mature to > justify usage in client PMDs towards 100Gb/s to 1Tb/s applications.? > > They concluded: ?1Tb/s does seem a ?bridge too far? at least for the > coming 3 > to 4 years.? > > Chris Cole of optical components maker Finisar presented the case for a > 400-Gbit CFI, with backing from Brocade, Cisco, HP, IBM, Intel, Juniper, > and > Verizon, among others. > > Like Huawei?s Cui and Stassar, Cole indicated that 400-Gbit Ethernet can > reuse 100 GbE building blocks, and fits within the existing dense 100 GbE > roadmap. Faster data rates require ?exotic? implementations, with higher > R&D > investments required and a longer time to market. ?Data rates beyond > 400Gb/s > require an increasingly impractical number of lanes if 100GbE technology is > reused,? he said. > > 400 Gbit/s also makes more sense than a 4?100 Gb/s link aggregation, Cole > added, as fewer items promotes management efficiency. Individual link > congestion is also a concern: ?Without faster links, [the] link count grows > exponentially, therefore management pain grows exponentially.? > > Cole suggested that a potential 400 Gb/s MAC/PCS ASIC could be fabricated > in > either 20- or 28-nm CMOS, using a 400-bit wide bus and a 1 GHz clock rate. > ?There is a strong desire to reuse 802.3ba, 802.3bj, and 802.3bm technology > building blocks,? he said. > > That?s not to say that terabit Ethernet won?t be needed, Cole concluded, or > 1.6 terabit Ethernet, at that. The timeframes for those followon CFIs could > be between 3 to 6 years, he said. > > The CFI hasn?t formally occurred; until it does, nothing has been decided. > So > far, the most likely dates for formalizing the CFI will take place in > either > November or next month. But at this point, it looks like terabit Ethernet > is > a dead duck, at least for the near future. > > From pr at isprime.com Thu Sep 27 13:35:44 2012 From: pr at isprime.com (Rosenthal Phil) Date: Thu, 27 Sep 2012 09:35:44 -0400 Subject: /. Terabit Ethernet is Dead, for Now In-Reply-To: References: <20120927125157.GT9750@leitl.org> <23047F2D-0BD7-4DDB-ADC3-54AE56684BEE@puck.nether.net> Message-ID: <335B002E-B7B1-4B78-9C59-A155EF7B8608@isprime.com> On Sep 27, 2012, at 9:26 AM, jim deleskie wrote: > That problem IMO will only be worse with a 4x speed multiplier over > 100G what premium will anyone be willing to spend to have a single > 400G pipe over 4 bonded 100G pipes? When you consider that 10GE is less than 10X the price of Gig-E, which is less than 10X the price of Fast-E (Slow-E by today's standards?) ... The economics don't really make sense that 40GE > 4 * 10GE, and 100GE > 10X 10GE ... The manufacturers are probably shooting themselves in the foot here, because for anyone who does not need anything faster than 10GE (which represents many ISP's, enterprises, etc), they would consider 40/100GE if it were cheap enough to have a nice luxury, but not if they are paying a huge premium. This translates into fewer overall sales, which translates into the product becoming "niche", and the parts ending up more expensive for those who do need it (Tier 1 ISP's, CDN's, Large Tier 2's, Exchanges, etc). As we all know, margins in many of those types of businesses are not huge in the first place, translating to an even smaller demand for that technology. That smaller demand ultimately translates to fewer dollars available for developing the next generation. The market doesn't just need faster interlinks, it needs them to be cheaper (per-bit), too! -Phil From swmike at swm.pp.se Thu Sep 27 13:41:52 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 27 Sep 2012 15:41:52 +0200 (CEST) Subject: /. Terabit Ethernet is Dead, for Now In-Reply-To: References: <20120927125157.GT9750@leitl.org> <23047F2D-0BD7-4DDB-ADC3-54AE56684BEE@puck.nether.net> Message-ID: On Thu, 27 Sep 2012, jim deleskie wrote: > That problem IMO will only be worse with a 4x speed multiplier over > 100G what premium will anyone be willing to spend to have a single 400G > pipe over 4 bonded 100G pipes? I'd say most are not willing to pay any premium at all, but are willing to adopt 4x interface speed when there is parity in cost/bit/s to bonded tech. I opposed 40GE, but since physics is a lot of the problem here, I think 400GE is favorable over 1TE. Already now we're sitting with platforms with forwarding performance per slot that doesn't really match 100GE nicely, imagine the equivalent problem for 1TE. By the time this is ready, will platforms be at slightly over 1T per slot, perhaps it then makes more sense to have 3x400GE instead of 1x1TE per slot. -- Mikael Abrahamsson email: swmike at swm.pp.se From smeuse at mara.org Thu Sep 27 13:56:01 2012 From: smeuse at mara.org (Steve Meuse) Date: Thu, 27 Sep 2012 09:56:01 -0400 Subject: /. Terabit Ethernet is Dead, for Now In-Reply-To: References: <20120927125157.GT9750@leitl.org> <23047F2D-0BD7-4DDB-ADC3-54AE56684BEE@puck.nether.net> Message-ID: On Thu, Sep 27, 2012 at 9:41 AM, Mikael Abrahamsson wrote: > > I opposed 40GE, but since physics is a lot of the problem here, I think > 400GE is favorable over 1TE. Already now we're sitting with platforms with > forwarding performance per slot that doesn't really match 100GE nicely, > imagine the equivalent problem for 1TE. By the time this is ready, will > platforms be at slightly over 1T per slot, perhaps it then makes more sense > to have 3x400GE instead of 1x1TE per slot. > > 1Tb/s per slot is a reality that will be here sooner than many might realize. I think the bonded vs. native argument can come down to optical bandwidth. If you are limited to N number of wavelengths on a segment having faster native interfaces becomes desirable (assuming similar optical bandwidth per unit). -Steve From nick at foobar.org Thu Sep 27 14:46:08 2012 From: nick at foobar.org (Nick Hilliard) Date: Thu, 27 Sep 2012 16:46:08 +0200 Subject: /. Terabit Ethernet is Dead, for Now In-Reply-To: References: <20120927125157.GT9750@leitl.org> Message-ID: <506466B0.8090305@foobar.org> On 27/09/2012 14:58, Darius Jahandarie wrote: > I recall 40Gbit/s Ethernet being promoted heavily for similar reasons > as the ones in this article, but then 100Gbit/s being the technology > that actually ended up in most places. Could this be the same thing > happening? no. the IEEE working group was split between 40GE and 100GE and ended up supporting both. As a result, the vendors ended up having to split time and resources investigating both, which was to the huge detriment of the industry. It's a good thing that they're deciding on a single spec, even if it isn't as fast as some people might like. Nick From mmata at intercom.com.sv Thu Sep 27 14:55:58 2012 From: mmata at intercom.com.sv (Miguel Mata) Date: Thu, 27 Sep 2012 08:55:58 -0600 Subject: really nasty attacks Message-ID: <506468FE.15908.A42E19D@mmata.intercom.com.sv> Guys, on recent days I've seen an UDP attack a couple of times. The attack is fairly simple, a full load of UDP packets filled with "X". The attacks comes from various sites from the other side of the pond (46.165.197.xx, 213.152.180.yy). Has anyone seen this kind of attack? Basically, the attack aims to fill your pipe (150Mbps over an STM1... guess what...) Then the question goes like this: besides asking your upstream provider to block, drop or whatever on the offending traffic, and Kontaktieren Sie den Administrator, what else can be done? Thanks in advance for any help you can provide. Please contact me off list. I'll post a recap on due time. -- Miguel Mata Gerente de Operaciones Comunicaciones IBW El Salvador tel.: ++(503) 2278-5068 fax: ++(503) 2207-1310 mmata at ibw.com "La confianza es la mejor conexion" From bmanning at vacation.karoshi.com Thu Sep 27 14:55:00 2012 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 27 Sep 2012 14:55:00 +0000 Subject: Are NAT'ed networks part of the Internet? In-Reply-To: <20120927092334.GY9750@leitl.org> References: <20120927092334.GY9750@leitl.org> Message-ID: <20120927145500.GA8827@vacation.karoshi.com.> On Thu, Sep 27, 2012 at 11:23:34AM +0200, Eugen Leitl wrote: > > I'm trying to figure out whether CERNET http://en.wikipedia.org/wiki/CERNET > is part of the official Internet, or is behind the Great Firewall where > access to invididual networks on the public Internet must be explicitly > granted. Anyone in the know? Well, they are part of -my- Internet. I'm Bill Manning and I approved this message. (there, its offical too) Since you raise the issue of "firewall" - I'll raise you one and ask; "Are networks behind NAT/ALG or that use RFC 1918 or the v6 equivalent address space, part of the 'Internet' or are they in networks where access to addresses/service ports must be explicitly granted?" /bill From jared at puck.nether.net Thu Sep 27 15:21:06 2012 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 27 Sep 2012 11:21:06 -0400 Subject: really nasty attacks In-Reply-To: <506468FE.15908.A42E19D@mmata.intercom.com.sv> References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> Message-ID: On Sep 27, 2012, at 10:55 AM, Miguel Mata wrote: > Guys, > > on recent days I've seen an UDP attack a couple of times. The attack is fairly simple, a full > load of UDP packets filled with "X". The attacks comes from various sites from the other side > of the pond (46.165.197.xx, 213.152.180.yy). > > Has anyone seen this kind of attack? Basically, the attack aims to fill your pipe (150Mbps > over an STM1... guess what...) Then the question goes like this: besides asking your > upstream provider to block, drop or whatever on the offending traffic, and Kontaktieren Sie > den Administrator, what else can be done? > > Thanks in advance for any help you can provide. > > Please contact me off list. I'll post a recap on due time. There are a lot of different attack types that one might see as an ISP/SP of services. 10 years+ ago it would be an ICMP flood. Some of us took to rate-limiting the icmp echo/echo-reply traffic to 2Mb/s on links to mitigate the flood. UDP can be a powerful tool in the hands of a compromised server. I recall in 96 putting 100M of udp through a 10m firewall/nat midpoint. Had to drive to the office to kill the process. Without knowing the nature of the pattern you are seeing, it is very hard to advise anything other than to contact your ISP for filtering. Traffic against udp/0 (fragments) would be handled different than others (eg: udp/80). I've seen many people just add udp/80 to their standard filters since I'm unaware of any UDP HTTP implementations. You can try to determine why you were attacked, but that too can be as simple as a "script kiddie" on IRC to an attack with far more malicious motive and implications. - Jared From bortzmeyer at nic.fr Thu Sep 27 15:34:08 2012 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 27 Sep 2012 17:34:08 +0200 Subject: really nasty attacks In-Reply-To: <506468FE.15908.A42E19D@mmata.intercom.com.sv> References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> Message-ID: <20120927153408.GA11650@nic.fr> On Thu, Sep 27, 2012 at 08:55:58AM -0600, Miguel Mata wrote a message of 30 lines which said: > Guys, No gals on NANOG? > The attacks comes from various sites from the other side of the pond > (46.165.197.xx, 213.152.180.yy). How can you be sure? With UDP, you have zero guarantee on the source IP address. (Checking the TTL can give you a hint if the packets really come from the same point.) Source and destination port? If source port is 53, it may means you're the target of a DNS reflection+amplification attack, a la CloudFlare . From ttauber at 1-4-5.net Thu Sep 27 15:41:07 2012 From: ttauber at 1-4-5.net (Tony Tauber) Date: Thu, 27 Sep 2012 11:41:07 -0400 Subject: Are NAT'ed networks part of the Internet? In-Reply-To: <506469c9.08ff2a0a.2e16.5b3cSMTPIN_ADDED@mx.google.com> References: <20120927092334.GY9750@leitl.org> <506469c9.08ff2a0a.2e16.5b3cSMTPIN_ADDED@mx.google.com> Message-ID: > "Are networks behind NAT/ALG or that use RFC 1918 or the v6 equivalent > address space, > part of the 'Internet' or are they in networks where access to > addresses/service ports > must be explicitly granted?" > RFC4084 (Terminology for Describing Internet Connectivity), IMHO, does a decent job of trying to enumerate/unpack these kinds of questions. I'm sure it's not uncontroversial, but may provide some common vocabulary. Tony From jfesler at gigo.com Thu Sep 27 15:52:30 2012 From: jfesler at gigo.com (Jason Fesler) Date: Thu, 27 Sep 2012 08:52:30 -0700 (PDT) Subject: Verizon IPv6 LTE In-Reply-To: <505BC4DE.70601@rollernet.us> References: <505BB44E.9070006@rollernet.us> <505BC3FA.2030507@rollernet.us> <505BC4DE.70601@rollernet.us> Message-ID: > Safari on the iPad seems to be preferring A over AAAA if a hostname has > both, though. I can browse to a bracketed IPv6 address so it is working. I think perhaps it is time to update test-ipv6.com a bit, and have it penalize the first number when IPv4 is used in preference. IPv4 CGN will make me a sad panda - especially when IPv6 is available but not being used. From tknchris at gmail.com Thu Sep 27 16:00:40 2012 From: tknchris at gmail.com (chris) Date: Thu, 27 Sep 2012 12:00:40 -0400 Subject: Verizon IPv6 LTE In-Reply-To: References: <505BB44E.9070006@rollernet.us> <505BC3FA.2030507@rollernet.us> <505BC4DE.70601@rollernet.us> Message-ID: I tested today just for giggles, test-ipv6.com shows I have working ipv4 and ipv6 10/10 on both tests. Interestingly enough I was only seeing 3G on the device at the time. So I guess its not just on LTE or is it LTE devices ? I'm running galaxy nexus on vz with stock jelly bean from the recent ota update On Thu, Sep 27, 2012 at 11:52 AM, Jason Fesler wrote: > Safari on the iPad seems to be preferring A over AAAA if a hostname has >> both, though. I can browse to a bracketed IPv6 address so it is working. >> > > I think perhaps it is time to update test-ipv6.com a bit, and have it > penalize the first number when IPv4 is used in preference. IPv4 CGN > will make me a sad panda - especially when IPv6 is available but not being > used. > > > From sethm at rollernet.us Thu Sep 27 16:04:27 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 27 Sep 2012 09:04:27 -0700 Subject: Verizon IPv6 LTE In-Reply-To: References: <505BB44E.9070006@rollernet.us> <505BC3FA.2030507@rollernet.us> <505BC4DE.70601@rollernet.us> Message-ID: <5064790B.8030804@rollernet.us> On 9/27/12 8:52 AM, Jason Fesler wrote: >> Safari on the iPad seems to be preferring A over AAAA if a hostname has >> both, though. I can browse to a bracketed IPv6 address so it is working. > > I think perhaps it is time to update test-ipv6.com a bit, and have it > penalize the first number when IPv4 is used in preference. IPv4 CGN > will make me a sad panda - especially when IPv6 is available but not > being used. > Sadly my iPad stopped getting an IPv6 address anywhere I normally go, even at home where it was previously working. ~Seth From patrick at ianai.net Thu Sep 27 16:12:50 2012 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 27 Sep 2012 12:12:50 -0400 Subject: really nasty attacks In-Reply-To: <20120927153408.GA11650@nic.fr> References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> <20120927153408.GA11650@nic.fr> Message-ID: <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> On Sep 27, 2012, at 11:34 , Stephane Bortzmeyer wrote: > On Thu, Sep 27, 2012 at 08:55:58AM -0600, Miguel Mata wrote > a message of 30 lines which said: > >> Guys, > > No gals on NANOG? Many. Although in fairness, some people use "guys" in a gender-neutral manner. >> The attacks comes from various sites from the other side of the pond >> (46.165.197.xx, 213.152.180.yy). > > How can you be sure? With UDP, you have zero guarantee on the source > IP address. (Checking the TTL can give you a hint if the packets > really come from the same point.) > > Source and destination port? If source port is 53, it may means you're > the target of a DNS reflection+amplification attack, a la CloudFlare > . I do not know of any name servers that reply to queries with UDP packets filled with only the letter X. The DNS Headers alone require more than the letter "X". -- TTFN, patrick From jim at reptiles.org Thu Sep 27 16:20:56 2012 From: jim at reptiles.org (Jim Mercer) Date: Thu, 27 Sep 2012 12:20:56 -0400 Subject: really nasty attacks In-Reply-To: <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> <20120927153408.GA11650@nic.fr> <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> Message-ID: <20120927162055.GA75762@reptiles.org> On Thu, Sep 27, 2012 at 12:12:50PM -0400, Patrick W. Gilmore wrote: > On Sep 27, 2012, at 11:34 , Stephane Bortzmeyer wrote: > > On Thu, Sep 27, 2012 at 08:55:58AM -0600, Miguel Mata wrote > > No gals on NANOG? > > Many. Although in fairness, some people use "guys" in a gender-neutral manner. heh. some people use it in a globally-neutral manner. "those guys over there" pointing at a rack full of servers. -- Jim Mercer Reptilian Research jim at reptiles.org +1 416 410-5633 "He who dies with the most toys is nonetheless dead" From ryan at u13.net Thu Sep 27 16:42:48 2012 From: ryan at u13.net (Ryan Rawdon) Date: Thu, 27 Sep 2012 11:42:48 -0500 Subject: Verizon IPv6 LTE In-Reply-To: References: <505BB44E.9070006@rollernet.us> <505BC3FA.2030507@rollernet.us> <505BC4DE.70601@rollernet.us> Message-ID: <19840881-4BE8-4CD7-8A1D-6590E08F35AE@u13.net> On Sep 27, 2012, at 11:00 AM, chris wrote: > I tested today just for giggles, test-ipv6.com shows I have working ipv4 > and ipv6 10/10 on both tests. Interestingly enough I was only seeing 3G on > the device at the time. > > So I guess its not just on LTE or is it LTE devices ? > > I'm running galaxy nexus on vz with stock jelly bean from the recent ota > update See quote from PC below regarding vzw, which matches colloquial evidence I have seen/heard as well. This is also true of T-Mobile's v6 deployment when switching between HSPA+, Edge, 3G, etc (though I do not know if PC's general explanation of "how" is true of TMo) On Sep 21, 2012, at 12:15 AM, PC wrote: > One more tip: IPv6 will work over the legacy 3g network. Don't ask me > much about it, but it "tunnels" it using eHRPD to the same IP/IPv6 headend > to enable seamless EVDO/LTE handover. > > On Thu, Sep 27, 2012 at 11:52 AM, Jason Fesler wrote: > >> Safari on the iPad seems to be preferring A over AAAA if a hostname has >>> both, though. I can browse to a bracketed IPv6 address so it is working. >>> >> >> I think perhaps it is time to update test-ipv6.com a bit, and have it >> penalize the first number when IPv4 is used in preference. IPv4 CGN >> will make me a sad panda - especially when IPv6 is available but not being >> used. >> >> >> From tom at cloudflare.com Thu Sep 27 18:01:29 2012 From: tom at cloudflare.com (Tom Paseka) Date: Thu, 27 Sep 2012 11:01:29 -0700 Subject: is CERNET part of the Internet? In-Reply-To: <50641D56.1000907@unfix.org> References: <20120927092334.GY9750@leitl.org> <50641D56.1000907@unfix.org> Message-ID: On Thu, Sep 27, 2012 at 2:33 AM, Jeroen Massar wrote: > Everything in China is behind their content filter. Only parts of Hong > Kong are sometimes not yet. As far as it is known they do not 'allow' > things but block specific things. All* of Hong Kong and Macau are not behind the chinese firewalls. *some hong kong and macau traffic *may* traverse mainland china and hence be firewalled, but the networks themselves operating in these two cities/regions do not have filtering per se. From jrhett at netconsonance.com Thu Sep 27 18:10:09 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 27 Sep 2012 11:10:09 -0700 Subject: guys != gender neutral In-Reply-To: <20120927162055.GA75762@reptiles.org> References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> <20120927153408.GA11650@nic.fr> <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> <20120927162055.GA75762@reptiles.org> Message-ID: On Sep 27, 2012, at 9:20 AM, Jim Mercer wrote: > On Thu, Sep 27, 2012 at 12:12:50PM -0400, Patrick W. Gilmore wrote: >> Many. Although in fairness, some people use "guys" in a gender-neutral manner. > > some people use it in a globally-neutral manner. > "those guys over there" pointing at a rack full of servers. Guys seem to think that it's gender neutral. The majority of women are used to this, but they have indicated to me that they don't believe it to be very neutral. Using "guys" is not gender neutral, it's flat out implying the other gender doesn't matter. * Given the lack of truly neutral terms in english, I have taken to alternative my pronouns interchangably when I write. "Those guys are chewing on that, but these gals are doing the vector calculations." (pointing at different racks of gear) Or when actually referring to persons of mixed gender, here's a quote from something I posted in a private forum (my own journal) which is safe for export: > Because frankly, we're all in this together and honestly everyone loves the competition. The guys I race with often come find me afterwards and tell me where they got past me, or ask me how I kept passing them. The really fast girls rarely want more than a beer to go out on the track and give you a detailed breakdown on what you are doing wrong. We all help each other. In this situation I'm leaving it up the reader to grasp that I'm not saying that the girls are all faster than the boys, but I believe it's understood in context as the topic was about how peers help each other out. I really wish that english had better pronouns for this. * As evidence of the nasty side effects of this, the bible was translated from a language which understands gender neutral terms to english, and was in translating reduced it to "man". Which is now used by only-english-speaking preachers to justify the "proper placement" of women in society. If for no other reason than that the use of a single gender pronoun confuses less intelligent types to assume that women aren't important in technology (and god knows this completely baseless assumption is widely held) do your part to mix it up! -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. From bortzmeyer at nic.fr Thu Sep 27 18:26:04 2012 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 27 Sep 2012 20:26:04 +0200 Subject: really nasty attacks In-Reply-To: <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> <20120927153408.GA11650@nic.fr> <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> Message-ID: <20120927182604.GA20296@sources.org> On Thu, Sep 27, 2012 at 12:12:50PM -0400, Patrick W. Gilmore wrote a message of 32 lines which said: > I do not know of any name servers that reply to queries with UDP > packets filled with only the letter X. The DNS Headers alone > require more than the letter "X". Yes, you're right but I'm not sure we should take the original report too litterally. May be he meant there were a lot of X in the packets (and he missed the headers), which is consistent with DNS "large TXT" attacks such as the one described in (where the attacker filled with consecutive numbers, not X). Anyway, without the actual pcap file, it is only speculation. From cciehelps at gmail.com Thu Sep 27 16:24:02 2012 From: cciehelps at gmail.com (ku po) Date: Fri, 28 Sep 2012 00:24:02 +0800 Subject: is CERNET part of the Internet? In-Reply-To: References: <20120927092334.GY9750@leitl.org> <50641D56.1000907@unfix.org> Message-ID: Well the answer is Yes and No. Content filter is not a reason you can call it non-internet. If you think it is not internet because of content filtering, think again, you have to exclude whole China from Internet. The real problem CERNET is not completely part of Internet is following: CERNET policy is FREE of charge for it's members, as long as the traffic is in their 'FREE networks' eg most of IP Blocks in China and some Universities in the world. However, outbound traffic to Non-free networks eg most blocks outside China will be charged. If you download a webpage from a China University, they are actually going to pay for it for your traffic. So some members tend to choose to block their visibility to 'Non-Free networks'. Of course major Universities won't do that but imagine a high school, they may very possibly do that. That is the main reason CERNET is not completely Internet. From owen at delong.com Thu Sep 27 18:34:38 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 27 Sep 2012 13:34:38 -0500 Subject: guys != gender neutral In-Reply-To: References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> <20120927153408.GA11650@nic.fr> <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> <20120927162055.GA75762@reptiles.org> Message-ID: <2DE28166-3AEB-451D-80E6-FA00331D8D45@delong.com> When did "people" stop being an acceptable gender-neutral substitute for {guys,gals}? Owen Sent from my iPad On Sep 27, 2012, at 1:10 PM, Jo Rhett wrote: > On Sep 27, 2012, at 9:20 AM, Jim Mercer wrote: >> On Thu, Sep 27, 2012 at 12:12:50PM -0400, Patrick W. Gilmore wrote: >>> Many. Although in fairness, some people use "guys" in a gender-neutral manner. >> >> some people use it in a globally-neutral manner. >> "those guys over there" pointing at a rack full of servers. > > > Guys seem to think that it's gender neutral. The majority of women are used to this, but they have indicated to me that they don't believe it to be very neutral. Using "guys" is not gender neutral, it's flat out implying the other gender doesn't matter. * > > Given the lack of truly neutral terms in english, I have taken to alternative my pronouns interchangably when I write. > "Those guys are chewing on that, but these gals are doing the vector calculations." (pointing at different racks of gear) > > Or when actually referring to persons of mixed gender, here's a quote from something I posted in a private forum (my own journal) which is safe for export: > >> Because frankly, we're all in this together and honestly everyone loves the competition. The guys I race with often come find me afterwards and tell me where they got past me, or ask me how I kept passing them. The really fast girls rarely want more than a beer to go out on the track and give you a detailed breakdown on what you are doing wrong. We all help each other. > > > In this situation I'm leaving it up the reader to grasp that I'm not saying that the girls are all faster than the boys, but I believe it's understood in context as the topic was about how peers help each other out. > > I really wish that english had better pronouns for this. > > * As evidence of the nasty side effects of this, the bible was translated from a language which understands gender neutral terms to english, and was in translating reduced it to "man". Which is now used by only-english-speaking preachers to justify the "proper placement" of women in society. > > If for no other reason than that the use of a single gender pronoun confuses less intelligent types to assume that women aren't important in technology (and god knows this completely baseless assumption is widely held) do your part to mix it up! > > -- > Jo Rhett > Net Consonance : net philanthropy to improve open source and internet projects. > > From jcdill.lists at gmail.com Thu Sep 27 18:36:03 2012 From: jcdill.lists at gmail.com (JC Dill) Date: Thu, 27 Sep 2012 11:36:03 -0700 Subject: guys != gender neutral In-Reply-To: References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> <20120927153408.GA11650@nic.fr> <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> <20120927162055.GA75762@reptiles.org> Message-ID: <50649C93.1090002@gmail.com> On 27/09/12 11:10 AM, Jo Rhett wrote: > Or when actually referring to persons of mixed gender, here's a quote > from something I posted in a private forum (my own journal) which is > safe for export: >> Because frankly, we're all in this together and honestly everyone loves the competition. The guys I race with often come find me afterwards and tell me where they got past me, or ask me how I kept passing them. The really fast girls rarely want more than a beer to go out on the track and give you a detailed breakdown on what you are doing wrong. We all help each other. > > In this situation I'm leaving it up the reader to grasp that I'm not saying that the girls are all faster than the boys, but I believe it's understood in context as the topic was about how peers help each other out. It's NOT helping to equivocate "guys" and "girls"! Guys and gals = equivalent Boys and girls = equivalent Guys and girls != equivalent All the TV shows that refer to female contestants as "girls" are not helping when they (universally) refer to the males as "guys". Unless you refer to the male contestants (on TV) or team members (at work) as "boys" you shouldn't be using the word "girls" to refer to the females. > I really wish that english had better pronouns for this. I really wish folks would dig a bit deeper into the thesaurus to find appropriate words. One can use a variety of gender neutral words with some simple re-writing. Remember, it's perfectly OK to employ singular "they" as well. http://en.wikipedia.org/wiki/Singular_they jc From mailing-lists at brianraaen.com Thu Sep 27 18:47:47 2012 From: mailing-lists at brianraaen.com (Brian Christopher Raaen) Date: Thu, 27 Sep 2012 14:47:47 -0400 Subject: guys != gender neutral In-Reply-To: <50649C93.1090002@gmail.com> References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> <20120927153408.GA11650@nic.fr> <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> <20120927162055.GA75762@reptiles.org> <50649C93.1090002@gmail.com> Message-ID: Here is the south we simply use "y'all". --- Brian Raaen Network Architect Zcorum On Thu, Sep 27, 2012 at 2:36 PM, JC Dill wrote: > On 27/09/12 11:10 AM, Jo Rhett wrote: >> >> Or when actually referring to persons of mixed gender, here's a quote from >> something I posted in a private forum (my own journal) which is safe for >> export: >>> >>> Because frankly, we're all in this together and honestly everyone loves >>> the competition. The guys I race with often come find me afterwards and tell >>> me where they got past me, or ask me how I kept passing them. The really >>> fast girls rarely want more than a beer to go out on the track and give you >>> a detailed breakdown on what you are doing wrong. We all help each other. >> >> >> In this situation I'm leaving it up the reader to grasp that I'm not >> saying that the girls are all faster than the boys, but I believe it's >> understood in context as the topic was about how peers help each other out. > > > It's NOT helping to equivocate "guys" and "girls"! > > Guys and gals = equivalent > Boys and girls = equivalent > Guys and girls != equivalent > > All the TV shows that refer to female contestants as "girls" are not helping > when they (universally) refer to the males as "guys". Unless you refer to > the male contestants (on TV) or team members (at work) as "boys" you > shouldn't be using the word "girls" to refer to the females. > > > >> I really wish that english had better pronouns for this. > > > I really wish folks would dig a bit deeper into the thesaurus to find > appropriate words. One can use a variety of gender neutral words with some > simple re-writing. Remember, it's perfectly OK to employ singular "they" as > well. > > http://en.wikipedia.org/wiki/Singular_they > > jc > From deleskie at gmail.com Thu Sep 27 18:52:08 2012 From: deleskie at gmail.com (deleskie at gmail.com) Date: Thu, 27 Sep 2012 18:52:08 +0000 Subject: guys != gender neutral In-Reply-To: <50649C93.1090002@gmail.com> References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> <20120927153408.GA11650@nic.fr> <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> <20120927162055.GA75762@reptiles.org> <50649C93.1090002@gmail.com> Message-ID: <1839502393-1348771928-cardhu_decombobulator_blackberry.rim.net-285181986-@b11.c17.bise6.blackberry> Maybe one of the folks here there aren't laywers but likes to give legal advice, that covers the use of male language to be for shortness in responses and no way indicate gender bias so we can all get back to talking about network :( Sent from my BlackBerry device on the Rogers Wireless Network -----Original Message----- From: JC Dill Date: Thu, 27 Sep 2012 11:36:03 To: Subject: Re: guys != gender neutral On 27/09/12 11:10 AM, Jo Rhett wrote: > Or when actually referring to persons of mixed gender, here's a quote > from something I posted in a private forum (my own journal) which is > safe for export: >> Because frankly, we're all in this together and honestly everyone loves the competition. The guys I race with often come find me afterwards and tell me where they got past me, or ask me how I kept passing them. The really fast girls rarely want more than a beer to go out on the track and give you a detailed breakdown on what you are doing wrong. We all help each other. > > In this situation I'm leaving it up the reader to grasp that I'm not saying that the girls are all faster than the boys, but I believe it's understood in context as the topic was about how peers help each other out. It's NOT helping to equivocate "guys" and "girls"! Guys and gals = equivalent Boys and girls = equivalent Guys and girls != equivalent All the TV shows that refer to female contestants as "girls" are not helping when they (universally) refer to the males as "guys". Unless you refer to the male contestants (on TV) or team members (at work) as "boys" you shouldn't be using the word "girls" to refer to the females. > I really wish that english had better pronouns for this. I really wish folks would dig a bit deeper into the thesaurus to find appropriate words. One can use a variety of gender neutral words with some simple re-writing. Remember, it's perfectly OK to employ singular "they" as well. http://en.wikipedia.org/wiki/Singular_they jc From trelane at trelane.net Thu Sep 27 18:57:36 2012 From: trelane at trelane.net (Andrew D Kirch) Date: Thu, 27 Sep 2012 14:57:36 -0400 Subject: guys != gender neutral In-Reply-To: References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> <20120927153408.GA11650@nic.fr> <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> <20120927162055.GA75762@reptiles.org> Message-ID: <5064A1A0.8030700@trelane.net> I really wish people would get over themselves and get to work. Work is a place where things get done, not where people piss and moan about every single perceived slight they can come up with. Andrew On 9/27/2012 2:10 PM, Jo Rhett wrote: From deric.kwok2000 at gmail.com Thu Sep 27 19:27:50 2012 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Thu, 27 Sep 2012 15:27:50 -0400 Subject: need help about 40G Message-ID: Hi all Do you have experience in 40G equipments eg: switch and NIC? Any brand name is reliable Thank you so much From jra at baylink.com Thu Sep 27 19:30:26 2012 From: jra at baylink.com (Jay Ashworth) Date: Thu, 27 Sep 2012 15:30:26 -0400 (EDT) Subject: is CERNET part of the Internet? In-Reply-To: <20120927093103.GA23541@nic.fr> Message-ID: <30729904.26986.1348774226681.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Stephane Bortzmeyer" > Eugen Leitl wrote > a message of 5 lines which said: > > > the official Internet > > I wasn't aware there is an official Internet. Where is it? "The largest equivalence class in the reflexive transitive symmetric closure of the relationship 'can be reached by an IP packet from'" -- Seth Breidbart. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From alexis at pellitteri.com.ar Thu Sep 27 19:36:33 2012 From: alexis at pellitteri.com.ar (Pellitteri Alexis) Date: Thu, 27 Sep 2012 16:36:33 -0300 Subject: need help about 40G In-Reply-To: References: Message-ID: <5064AAC1.90700@pellitteri.com.ar> Hi there ASR 9000 and CRS-3 as far as I am concerned. That would be in Cisco World. There are other brands. Take a look at this: http://en.wikipedia.org/wiki/100_Gigabit_Ethernet On 09/27/2012 04:27 PM, Deric Kwok wrote: Hi all Do you have experience in 40G equipments eg: switch and NIC? Any brand name is reliable Thank you so much From jra at baylink.com Thu Sep 27 19:39:13 2012 From: jra at baylink.com (Jay Ashworth) Date: Thu, 27 Sep 2012 15:39:13 -0400 (EDT) Subject: guys != gender neutral In-Reply-To: <2DE28166-3AEB-451D-80E6-FA00331D8D45@delong.com> Message-ID: <25525021.26990.1348774753636.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > When did "people" stop being an acceptable gender-neutral substitute > for {guys,gals}? As a form of address. "Hey, people" is ... well, nearly abrasive. (Envision a waitron walking up to a mixed table of 10.) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From james.cutler at consultant.com Thu Sep 27 19:39:40 2012 From: james.cutler at consultant.com (Cutler James R) Date: Thu, 27 Sep 2012 15:39:40 -0400 Subject: really nasty attacks In-Reply-To: <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> <20120927153408.GA11650@nic.fr> <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> Message-ID: <5F9F5C1E-CC00-49B9-820E-91D2B2B6A037@consultant.com> On Sep 27, 2012, at 12:12 PM, Patrick W. Gilmore wrote: > > On Sep 27, 2012, at 11:34 , Stephane Bortzmeyer wrote: >> On Thu, Sep 27, 2012 at 08:55:58AM -0600, Miguel Mata wrote >> a message of 30 lines which said: >> >>> Guys, >> >> No gals on NANOG? > > Many. Although in fairness, some people use "guys" in a gender-neutral manner. See, for example, "Sesame Street". From quantumfoam at gmail.com Thu Sep 27 19:39:57 2012 From: quantumfoam at gmail.com (Jonathan Rogers) Date: Thu, 27 Sep 2012 15:39:57 -0400 Subject: need help about 40G In-Reply-To: References: Message-ID: I've had good experience with Mellanox NICs for 40gbe. --J On Thu, Sep 27, 2012 at 3:27 PM, Deric Kwok wrote: > Hi all > > Do you have experience in 40G equipments > > eg: switch and NIC? > > Any brand name is reliable > > Thank you so much > > From EWieling at nyigc.com Thu Sep 27 19:42:12 2012 From: EWieling at nyigc.com (Eric Wieling) Date: Thu, 27 Sep 2012 15:42:12 -0400 Subject: guys != gender neutral In-Reply-To: <25525021.26990.1348774753636.JavaMail.root@benjamin.baylink.com> References: <2DE28166-3AEB-451D-80E6-FA00331D8D45@delong.com> <25525021.26990.1348774753636.JavaMail.root@benjamin.baylink.com> Message-ID: <616B4ECE1290D441AD56124FEBB03D0885379EA1@mailserver2007.nyigc.globe> Since we all know that on the Internet "the men are men, the women are men, and the children are FBI agents", I think saying "guys" is OK. -----Original Message----- From: Jay Ashworth [mailto:jra at baylink.com] Sent: Thursday, September 27, 2012 3:39 PM To: NANOG Subject: Re: guys != gender neutral ----- Original Message ----- > From: "Owen DeLong" > When did "people" stop being an acceptable gender-neutral substitute > for {guys,gals}? As a form of address. "Hey, people" is ... well, nearly abrasive. (Envision a waitron walking up to a mixed table of 10.) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From brunner at nic-naa.net Thu Sep 27 16:52:58 2012 From: brunner at nic-naa.net (brunner at nic-naa.net) Date: Thu, 27 Sep 2012 12:52:58 -0400 Subject: is CERNET part of the Internet? Message-ID: <201209271652.q8RGqwmd038297@nic-naa.net> On 9/27/12 9:24 AM, ku po wrote: > CERNET policy is FREE of charge for it's members, as long as the traffic is > in their 'FREE networks' eg most of IP Blocks in China and some > Universities in the world. > However, outbound traffic to Non-free networks eg most blocks outside China > will be charged. In 2001 I'd the pleasure of working with CNNIC in the IETF technical and ICANN policy areas. At the time a bug in the UTF8 processing in the then-prevelant version of IE yeilded packet sequences originating from the edge device, on a IP block in the PRC (and elsewhere resolution was attempted of labels in the Han Script input into in the IE navigation field) to IP addresses allocated to Microsoft, to IP addresses allocated to an "IDN Solutions Vendor" in Silicon Valley, and to IP addresses allocated to Verisign Registry. As there were a non-trivial number of instances of IE with this bug operating in the PRC in 2001, the aggregate of these several packets per string per IE instance had a non-trivial overseas bandwidth cost -- settled at the time in hard currency, USD -- a scarce resource at the time. I suggest that (a) substituting whatever one has as "the definition" of "the Internet" for settlement free peering is suspect, and (b) the cost of overseas bandwidth in the PRC is still non-negligible, and (c) the cost, when amortized over cache instances, may be less than the cost of cost recovery, and offered as "free", and (d) the cost of uncacheable traffic cannot be so amortized, and (e) while USD are not a scarce resource in the PRC at present, settlements may still be made in currency other then RMB. Eric From KevinC at uca.edu Thu Sep 27 19:52:23 2012 From: KevinC at uca.edu (Kevin Carmical) Date: Thu, 27 Sep 2012 14:52:23 -0500 Subject: guys != gender neutral In-Reply-To: <1839502393-1348771928-cardhu_decombobulator_blackberry.rim.net-285181986-@b11.c17.bise6.blackberry> References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> <20120927153408.GA11650@nic.fr> <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> <20120927162055.GA75762@reptiles.org> <50649C93.1090002@gmail.com> <1839502393-1348771928-cardhu_decombobulator_blackberry.rim.net-285181986-@b11.c17.bise6.blackberry> Message-ID: <506468270200004B00097B4C@fsgwia1.uca.edu> So say we all. Kevin Carmical Network Support UCA BBA 107 501-450-3107>>> 9/27/2012 1:52 PM >>> Maybe one of the folks here there aren't laywers but likes to give legal advice, that covers the use of male language to be for shortness in responses and no way indicate gender bias so we can all get back to talking about network :( Sent from my BlackBerry device on the Rogers Wireless Network -----Original Message----- From: JC Dill Date: Thu, 27 Sep 2012 11:36:03 To: Subject: Re: guys != gender neutral On 27/09/12 11:10 AM, Jo Rhett wrote: > Or when actually referring to persons of mixed gender, here's a quote > from something I posted in a private forum (my own journal) which is > safe for export: >> Because frankly, we're all in this together and honestly everyone loves the competition. The guys I race with often come find me afterwards and tell me where they got past me, or ask me how I kept passing them. The really fast girls rarely want more than a beer to go out on the track and give you a detailed breakdown on what you are doing wrong. We all help each other. > > In this situation I'm leaving it up the reader to grasp that I'm not saying that the girls are all faster than the boys, but I believe it's understood in context as the topic was about how peers help each other out. It's NOT helping to equivocate "guys" and "girls"! Guys and gals = equivalent Boys and girls = equivalent Guys and girls != equivalent All the TV shows that refer to female contestants as "girls" are not helping when they (universally) refer to the males as "guys". Unless you refer to the male contestants (on TV) or team members (at work) as "boys" you shouldn't be using the word "girls" to refer to the females. > I really wish that english had better pronouns for this. I really wish folks would dig a bit deeper into the thesaurus to find appropriate words. One can use a variety of gender neutral words with some simple re-writing. Remember, it's perfectly OK to employ singular "they" as well. http://en.wikipedia.org/wiki/Singular_they jc From rob at invaluement.com Thu Sep 27 19:52:49 2012 From: rob at invaluement.com (Rob McEwen) Date: Thu, 27 Sep 2012 15:52:49 -0400 Subject: guys != gender neutral In-Reply-To: References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> <20120927153408.GA11650@nic.fr> <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> <20120927162055.GA75762@reptiles.org> <50649C93.1090002@gmail.com> Message-ID: <5064AE91.2070800@invaluement.com> On 9/27/2012 2:47 PM, Brian Christopher Raaen wrote: > Here is the south we simply use "y'all". That's what I was thinking. Also, btw, I disagree with that earlier comment about gender usage in the Bible, as least in regards to the New Testament. The Greek language of that time period is the most specific/nuanced/sophisticated language in the history of the world.... far more specific/nuanced/sophisticated than modern day European languages. -- Rob McEwen http://dnsbl.invaluement.com/ rob at invaluement.com +1 (478) 475-9032 From uwcableguy at gmail.com Thu Sep 27 20:00:33 2012 From: uwcableguy at gmail.com (Ben Bartsch) Date: Thu, 27 Sep 2012 15:00:33 -0500 Subject: guys != gender neutral In-Reply-To: <506468270200004B00097B4C@fsgwia1.uca.edu> References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> <20120927153408.GA11650@nic.fr> <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> <20120927162055.GA75762@reptiles.org> <50649C93.1090002@gmail.com> <1839502393-1348771928-cardhu_decombobulator_blackberry.rim.net-285181986-@b11.c17.bise6.blackberry> <506468270200004B00097B4C@fsgwia1.uca.edu> Message-ID: y'all youse ye do not use 'gals'.....i've been told that is offensive here in the south (i'm a yankee transplant) On Thu, Sep 27, 2012 at 2:52 PM, Kevin Carmical wrote: > So say we all. > > > Kevin Carmical > Network Support > UCA > BBA 107 > 501-450-3107>>> 9/27/2012 1:52 PM >>> > Maybe one of the folks here there aren't laywers but likes to give legal > advice, that covers the use of male language to be for shortness in > responses and no way indicate gender bias so we can all get back to talking > about network :( > > > > Sent from my BlackBerry device on the Rogers Wireless Network > > -----Original Message----- > From: JC Dill > Date: Thu, 27 Sep 2012 11:36:03 > To: > Subject: Re: guys != gender neutral > > On 27/09/12 11:10 AM, Jo Rhett wrote: > > Or when actually referring to persons of mixed gender, here's a quote > > from something I posted in a private forum (my own journal) which is > > safe for export: > >> Because frankly, we're all in this together and honestly everyone loves > the competition. The guys I race with often come find me afterwards and > tell me where they got past me, or ask me how I kept passing them. The > really fast girls rarely want more than a beer to go out on the track and > give you a detailed breakdown on what you are doing wrong. We all help each > other. > > > > In this situation I'm leaving it up the reader to grasp that I'm not > saying that the girls are all faster than the boys, but I believe it's > understood in context as the topic was about how peers help each other out. > > It's NOT helping to equivocate "guys" and "girls"! > > Guys and gals = equivalent > Boys and girls = equivalent > Guys and girls != equivalent > > All the TV shows that refer to female contestants as "girls" are not > helping when they (universally) refer to the males as "guys". Unless > you refer to the male contestants (on TV) or team members (at work) as > "boys" you shouldn't be using the word "girls" to refer to the females. > > > > I really wish that english had better pronouns for this. > > I really wish folks would dig a bit deeper into the thesaurus to find > appropriate words. One can use a variety of gender neutral words with > some simple re-writing. Remember, it's perfectly OK to employ singular > "they" as well. > > http://en.wikipedia.org/wiki/Singular_they > > jc > > From bill at herrin.us Thu Sep 27 20:07:53 2012 From: bill at herrin.us (William Herrin) Date: Thu, 27 Sep 2012 16:07:53 -0400 Subject: guys != gender neutral In-Reply-To: <50649C93.1090002@gmail.com> References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> <20120927153408.GA11650@nic.fr> <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> <20120927162055.GA75762@reptiles.org> <50649C93.1090002@gmail.com> Message-ID: On Thu, Sep 27, 2012 at 2:36 PM, JC Dill wrote: > On 27/09/12 11:10 AM, Jo Rhett wrote: >> I really wish that english had better pronouns for this. > > I really wish folks would dig a bit deeper into the thesaurus to find > appropriate words. I find that "folks" is an excellent replacement that drops in most places I'm tempted to use "guys." On the other hand, using "they" as a replacement for "he" or "she" makes a sentence hard to parse. See that individual over there? They're fixing it. Ick! Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From rvandolson at esri.com Thu Sep 27 20:28:04 2012 From: rvandolson at esri.com (Ray Van Dolson) Date: Thu, 27 Sep 2012 13:28:04 -0700 Subject: guys != gender neutral In-Reply-To: <5064A1A0.8030700@trelane.net> References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> <20120927153408.GA11650@nic.fr> <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> <20120927162055.GA75762@reptiles.org> <5064A1A0.8030700@trelane.net> Message-ID: <20120927202804.GA6069@esri.com> On Thu, Sep 27, 2012 at 02:57:36PM -0400, Andrew D Kirch wrote: > I really wish people would get over themselves and get to work. > Work is a place where things get done, not where people piss and > moan about every single perceived slight they can come up with. > > Andrew I only wish you had used 'guys' instead of 'people' :) Ray From bmanning at vacation.karoshi.com Thu Sep 27 20:36:48 2012 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 27 Sep 2012 20:36:48 +0000 Subject: guys & dolls (a film motif) In-Reply-To: <20120927202804.GA6069@esri.com> References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> <20120927153408.GA11650@nic.fr> <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> <20120927162055.GA75762@reptiles.org> <5064A1A0.8030700@trelane.net> <20120927202804.GA6069@esri.com> Message-ID: <20120927203648.GB15531@vacation.karoshi.com.> http://en.wikipedia.org/wiki/Guys_and_Dolls_(film) i -think- the term we are looking for is: Troglodyte 1: A person considered to be reclusive, reactionary, out of date, or brutish. /bill (top posting like a civilized human...) On Thu, Sep 27, 2012 at 01:28:04PM -0700, Ray Van Dolson wrote: > On Thu, Sep 27, 2012 at 02:57:36PM -0400, Andrew D Kirch wrote: > > I really wish people would get over themselves and get to work. > > Work is a place where things get done, not where people piss and > > moan about every single perceived slight they can come up with. > > > > Andrew > > I only wish you had used 'guys' instead of 'people' :) > > Ray From george.herbert at gmail.com Thu Sep 27 20:42:15 2012 From: george.herbert at gmail.com (George Herbert) Date: Thu, 27 Sep 2012 13:42:15 -0700 Subject: /. Terabit Ethernet is Dead, for Now In-Reply-To: <20120927130403.GA81430@ussenterprise.ufp.org> References: <20120927125157.GT9750@leitl.org> <20120927130403.GA81430@ussenterprise.ufp.org> Message-ID: On Thu, Sep 27, 2012 at 6:04 AM, Leo Bicknell wrote: > In a message written on Thu, Sep 27, 2012 at 08:58:09AM -0400, Darius Jahandarie wrote: >> I recall 40Gbit/s Ethernet being promoted heavily for similar reasons >> as the ones in this article, but then 100Gbit/s being the technology >> that actually ended up in most places. Could this be the same thing >> happening? > > Everything I've read sounds like a repeat of the same broken decision > making that happened last time. > > That is unsurprising though, the same people are involved. If the vendors are saying costs will be prohibitive, are you willing to pay significantly more for the interfaces to make them do it anyways? -- -george william herbert george.herbert at gmail.com From trelane at trelane.net Thu Sep 27 20:47:16 2012 From: trelane at trelane.net (Andrew D Kirch) Date: Thu, 27 Sep 2012 16:47:16 -0400 Subject: guys & dolls (a film motif) In-Reply-To: <20120927203648.GB15531@vacation.karoshi.com.> References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> <20120927153408.GA11650@nic.fr> <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> <20120927162055.GA75762@reptiles.org> <5064A1A0.8030700@trelane.net> <20120927202804.GA6069@esri.com> <20120927203648.GB15531@vacation.karoshi.com.> Message-ID: <5064BB54.90405@trelane.net> This isn't a real issue. HUNGER is a real issue. WAR is a real issue. 12 year old girls being sold for $20 into SLAVERY in India is a real issue. TERRORist attacks on embassies are real issues. Expansion of POLICE power is a real issue. Erosion of human and civil RIGHTS are real issues. This is window dressing. I've highlighted the important words for you, and for emphasis, because obviously you don't get it. Andrew On 9/27/2012 4:36 PM, bmanning at vacation.karoshi.com wrote: > http://en.wikipedia.org/wiki/Guys_and_Dolls_(film) > > i -think- the term we are looking for is: Troglodyte > > 1: > A person considered to be reclusive, reactionary, out of date, or brutish. > > > /bill (top posting like a civilized human...) > > > On Thu, Sep 27, 2012 at 01:28:04PM -0700, Ray Van Dolson wrote: >> On Thu, Sep 27, 2012 at 02:57:36PM -0400, Andrew D Kirch wrote: >>> I really wish people would get over themselves and get to work. >>> Work is a place where things get done, not where people piss and >>> moan about every single perceived slight they can come up with. >>> >>> Andrew >> I only wish you had used 'guys' instead of 'people' :) >> >> Ray From lstewart at superb.net Thu Sep 27 20:55:32 2012 From: lstewart at superb.net (Landon Stewart) Date: Thu, 27 Sep 2012 13:55:32 -0700 Subject: guys != gender neutral In-Reply-To: <2DE28166-3AEB-451D-80E6-FA00331D8D45@delong.com> References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> <20120927153408.GA11650@nic.fr> <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> <20120927162055.GA75762@reptiles.org> <2DE28166-3AEB-451D-80E6-FA00331D8D45@delong.com> Message-ID: On 27 September 2012 11:34, Owen DeLong wrote: > When did "people" stop being an acceptable gender-neutral substitute for > {guys,gals}? > > Owen > > Using the word 'people' is good but I like to say 'humans'. What's up humans? Can I get you humans to drink? This rarely offends anyone. -- Landon Stewart Sr. Administrator Systems Engineering Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead of the Rest": http://www.superbhosting.net From bmanning at vacation.karoshi.com Thu Sep 27 20:59:37 2012 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 27 Sep 2012 20:59:37 +0000 Subject: guys & dolls (a film motif) In-Reply-To: <5064BB54.90405@trelane.net> References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> <20120927153408.GA11650@nic.fr> <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> <20120927162055.GA75762@reptiles.org> <5064A1A0.8030700@trelane.net> <20120927202804.GA6069@esri.com> <20120927203648.GB15531@vacation.karoshi.com.> <5064BB54.90405@trelane.net> Message-ID: <20120927205937.GA15705@vacation.karoshi.com.> thank you for your kind words and attempts to educate. clearly these items are critical for North American Network Operations (NANOG) and should be widely promoted and discussed ... But NOT, I think, here. may i humbly suggest that there exist other, better fora for discussion of these specific issues and ways/means to address them; Aleviating HUNGER Global Peace - where none take offense Exploitation of the helpless Definition of rights, both human and non-human. I would like to point you here: http://www.un.org/en/rights/ which actually has the charter to work on the issues that are so pressing in your mind. Can we kill this thread (oh dear, i'm advocating violence again...) and get back to Network Operations? Please? /bill On Thu, Sep 27, 2012 at 04:47:16PM -0400, Andrew D Kirch wrote: > This isn't a real issue. HUNGER is a real issue. WAR is a real issue. > 12 year old girls being sold for $20 into SLAVERY in India is a real > issue. TERRORist attacks on embassies are real issues. Expansion of > POLICE power is a real issue. Erosion of human and civil RIGHTS are > real issues. This is window dressing. I've highlighted the important > words for you, and for emphasis, because obviously you don't get it. > > Andrew > > On 9/27/2012 4:36 PM, bmanning at vacation.karoshi.com wrote: > >http://en.wikipedia.org/wiki/Guys_and_Dolls_(film) > > > >i -think- the term we are looking for is: Troglodyte > > > >1: > >A person considered to be reclusive, reactionary, out of date, or brutish. > > > > > >/bill (top posting like a civilized human...) > > > > > >On Thu, Sep 27, 2012 at 01:28:04PM -0700, Ray Van Dolson wrote: > >>On Thu, Sep 27, 2012 at 02:57:36PM -0400, Andrew D Kirch wrote: > >>>I really wish people would get over themselves and get to work. > >>>Work is a place where things get done, not where people piss and > >>>moan about every single perceived slight they can come up with. > >>> > >>>Andrew > >>I only wish you had used 'guys' instead of 'people' :) > >> > >>Ray > From rodrick.brown at gmail.com Thu Sep 27 21:09:43 2012 From: rodrick.brown at gmail.com (Rodrick Brown) Date: Thu, 27 Sep 2012 17:09:43 -0400 Subject: need help about 40G In-Reply-To: References: Message-ID: <5428124345999801386@unknownmsgid> On Sep 27, 2012, at 3:30 PM, Deric Kwok wrote: > Hi all > > Do you have experience in 40G equipments > > eg: switch and NIC? Infiniband or Ethernet? Mellanox CX3 is likely your only choice today for a reliable 40Gbe. > > Any brand name is reliable > > Thank you so much > From jethro.binks at strath.ac.uk Thu Sep 27 21:22:45 2012 From: jethro.binks at strath.ac.uk (Jethro R Binks) Date: Thu, 27 Sep 2012 22:22:45 +0100 (BST) Subject: guys != gender neutral In-Reply-To: References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> <20120927153408.GA11650@nic.fr> <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> <20120927162055.GA75762@reptiles.org> <2DE28166-3AEB-451D-80E6-FA00331D8D45@delong.com> Message-ID: On Thu, 27 Sep 2012, Landon Stewart wrote: > On 27 September 2012 11:34, Owen DeLong wrote: > > > When did "people" stop being an acceptable gender-neutral substitute for > > {guys,gals}? > > > > Owen > > > > > Using the word 'people' is good but I like to say 'humans'. > > What's up humans? > Can I get you humans to drink? > > This rarely offends anyone. This discussion is a well-trodden (and tediously dull) path. My favourite response to it: http://list.uvm.edu/cgi-bin/wa?A2=ind1001&L=UVMRESNET&D=0&P=2278 Thank you Jason Healy. Jethro. . . . . . . . . . . . . . . . . . . . . . . . . . Jethro R Binks, Network Manager, Information Services Directorate, University Of Strathclyde, Glasgow, UK The University of Strathclyde is a charitable body, registered in Scotland, number SC015263. From ncnet at sbcglobal.net Thu Sep 27 21:29:48 2012 From: ncnet at sbcglobal.net (Larry Stites) Date: Thu, 27 Sep 2012 14:29:48 -0700 (PDT) Subject: guys != gender neutral In-Reply-To: References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> <20120927153408.GA11650@nic.fr> <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> <20120927162055.GA75762@reptiles.org> <2DE28166-3AEB-451D-80E6-FA00331D8D45@delong.com> Message-ID: <1348781388.92533.YahooMailRC@web181503.mail.ne1.yahoo.com> EEK-Wallet-EE! ----- Original Message ---- > From: Jethro R Binks > To: "nanog at nanog.org" > Sent: Thu, September 27, 2012 2:23:28 PM > Subject: Re: guys != gender neutral > > On Thu, 27 Sep 2012, Landon Stewart wrote: > > > On 27 September 2012 11:34, Owen DeLong wrote: > > > > > When did "people" stop being an acceptable gender-neutral substitute for > > > {guys,gals}? > > > > > > Owen > > > > > > > > Using the word 'people' is good but I like to say 'humans'. > > > > What's up humans? > > Can I get you humans to drink? > > > > This rarely offends anyone. > > This discussion is a well-trodden (and tediously dull) path. My favourite > response to it: > > http://list.uvm.edu/cgi-bin/wa?A2=ind1001&L=UVMRESNET&D=0&P=2278 > > Thank you Jason Healy. > > Jethro. > > . . . . . . . . . . . . . . . . . . . . . . . . . > Jethro R Binks, Network Manager, > Information Services Directorate, University Of Strathclyde, Glasgow, UK > > The University of Strathclyde is a charitable body, registered in > Scotland, number SC015263. > > From lorell at hathcock.org Thu Sep 27 21:34:36 2012 From: lorell at hathcock.org (Lorell Hathcock) Date: Thu, 27 Sep 2012 16:34:36 -0500 Subject: guys != gender neutral In-Reply-To: References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> <20120927153408.GA11650@nic.fr> <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> <20120927162055.GA75762@reptiles.org> <2DE28166-3AEB-451D-80E6-FA00331D8D45@delong.com> Message-ID: <013501cd9cf7$e495cc50$adc164f0$@hathcock.org> We may not all be guys. We may not all be gals. But we are definitely all CLOWNS. This is a substitution that should be acceptable to all and it really works. Sales-clown. Yep! Mail-clown. Yep! Fire-clown. Yep! Police-clown. Yep! Congress-clown. Yep! Yep! -----Original Message----- From: Landon Stewart [mailto:lstewart at superb.net] Sent: Thursday, September 27, 2012 3:56 PM To: Owen DeLong Cc: nanog at nanog.org Subject: Re: guys != gender neutral On 27 September 2012 11:34, Owen DeLong wrote: > When did "people" stop being an acceptable gender-neutral substitute > for {guys,gals}? > > Owen > > Using the word 'people' is good but I like to say 'humans'. What's up humans? Can I get you humans to drink? This rarely offends anyone. -- Landon Stewart Sr. Administrator Systems Engineering Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead of the Rest": http://www.superbhosting.net From mmata at intercom.com.sv Thu Sep 27 21:43:10 2012 From: mmata at intercom.com.sv (Miguel Mata) Date: Thu, 27 Sep 2012 15:43:10 -0600 Subject: really nasty attacks In-Reply-To: <20120927182604.GA20296@sources.org> References: <506468FE.15908.A42E19D@mmata.intercom.com.sv>, <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net>, <20120927182604.GA20296@sources.org> Message-ID: <5064C86E.2594.BB7B058@mmata.intercom.com.sv> Guys and gals, in the text file you can find 4 to 5 of the captured packets. Some really interesting stuff. Yes, there are some UDP/80 traffic but mostly is UDP fragmented traffic. On 27 Sep 2012 at 20:26, Stephane Bortzmeyer wrote: > On Thu, Sep 27, 2012 at 12:12:50PM -0400, > Patrick W. Gilmore wrote > a message of 32 lines which said: -------------- next part -------------- The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- File information ----------- File: maravilla.txt Date: 27 Sep 2012, 15:41 Size: 47093 bytes. Type: Text -------------- next part -------------- A non-text attachment was scrubbed... Name: maravilla.txt Type: application/octet-stream Size: 47093 bytes Desc: not available URL: From Jonathon.Exley at kordia.co.nz Thu Sep 27 22:11:36 2012 From: Jonathon.Exley at kordia.co.nz (Jonathon Exley) Date: Thu, 27 Sep 2012 22:11:36 +0000 Subject: Ethernet OAM BCPs Please are there any yet??? In-Reply-To: <000b01cd9c83$3a6181d0$af248570$@swan.sk> References: <024001cd9bc9$4bdeb230$e39c1690$@swan.sk> <000b01cd9c83$3a6181d0$af248570$@swan.sk> Message-ID: I don't know if any Y.1731 gear will do anything other than constant interval probes. I'm also not sure what the values of randomly spaced probes would be. As far as I know the Y.1731 performance measurement probes are intended to be used to obtain performance data on circuits with as little impact on the available bandwidth as possible. Using a random departure time sounds like the sort of load test where you want to generate a synthetic data stream and consume bandwidth. Jonathon > -----Original Message----- > From: Adam Vitkovsky [mailto:adam.vitkovsky at swan.sk] > Sent: Thursday, 27 September 2012 7:39 p.m. > To: Jonathon Exley; nanog at nanog.org > Subject: RE: Ethernet OAM BCPs Please are there any yet??? > > Thank you so much Jonathon. > This is exactly what I what I was searching for. > Oh and yes I should have mentioned I'd like to do the Y.1731 and measure > the delay and delay variance > > Just yesterday evening I found a great article about how ATT did theirs > active measurements though for IP - wondering if I could do the same for > my > Y.1731 > They used dedicated servers and I'll be running this form the routers > ME3600X and CX and ASR9K so I'm a bit worried about the scaling of the > whole thing > > ATT basically used two probes and each 24-hour day is divided into 96 test > cycles of 15 minutes > > A Poisson probe sequence of duration equal to the test cycle > characteristics: > - Poisson distribution with average interarrival time of 3.3 s > - Packet size of 278 bytes, including headers > - UDP protocol > > Two periodic probe sequences in every test > characteristics: > - Interval of 20 ms between successive packets (or 50 packets/s) > - 1 min duration > - Random start time within the 15 min cycle > - Packet size of 60 bytes (including headers) > - UDP protocol > > > adam This email and attachments: are confidential; may be protected by privilege and copyright; if received in error may not be used, copied, or kept; are not guaranteed to be virus-free; may not express the views of Kordia(R); do not designate an information system; and do not give rise to any liability for Kordia(R). From scott at doc.net.au Thu Sep 27 23:08:11 2012 From: scott at doc.net.au (Scott Howard) Date: Thu, 27 Sep 2012 16:08:11 -0700 Subject: guys != gender neutral In-Reply-To: References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> <20120927153408.GA11650@nic.fr> <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> <20120927162055.GA75762@reptiles.org> Message-ID: On Thu, Sep 27, 2012 at 11:10 AM, Jo Rhett wrote: > Guys seem to think that it's gender neutral. The majority of women are > used to this, but they have indicated to me that they don't believe it to > be very neutral. Using "guys" is not gender neutral, it's flat out implying > the other gender doesn't matter. * > The Oxford English dictionary apparently disagrees with you. http://oxforddictionaries.com/definition/american_english/guy?region=us&q=guys (*guys*) people of either sex: * you guys want some coffee? * As other many words in the English language there are multiple definitions, and one of those definitions is gender specific - but the one above is very much gender neutral ("either sex" - it doesn't get much clearer than that!) Scott From davidpeahi at gmail.com Thu Sep 27 23:08:20 2012 From: davidpeahi at gmail.com (david peahi) Date: Thu, 27 Sep 2012 16:08:20 -0700 Subject: Ethernet OAM BCPs Please are there any yet??? In-Reply-To: <024001cd9bc9$4bdeb230$e39c1690$@swan.sk> References: <024001cd9bc9$4bdeb230$e39c1690$@swan.sk> Message-ID: I have used BRIX active measurement for IP for many years, but here is a link that describes BRIX in conjunction with ADVA for Ethernet probes. There is an article in IEEE Communications Magazine circa 2004-2005 by AT&T researchers describing their roll your own active measurement system, theoretical assumptions, and theory of probe data collection. David On Wed, Sep 26, 2012 at 2:28 AM, Adam Vitkovsky wrote: > Hi > Are there any best common practices for the CFM levels use > Since my pure Ethernet aggregation layers are small I believe I only need > two CFM levels > I plan on using Level 5 between CPEs managed by us and Level 4 between > Aggregation devices -that's where MPLS PWs kicks in > So leaving Level 7 and Level 6 for customers and carrier-customers > respectfully -would this be enough please? > > I'm also interested on what's the rule of thumb for CCMs Frequency, Number > of Packets, Interpacket Interval, Packet Size and Lifetime for the > particular operation > Thanks a lot for any inputs > > > adam > > > > > > > > > > > > > From lstewart at superb.net Thu Sep 27 23:13:55 2012 From: lstewart at superb.net (Landon Stewart) Date: Thu, 27 Sep 2012 16:13:55 -0700 Subject: guys != gender neutral In-Reply-To: References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> <20120927153408.GA11650@nic.fr> <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> <20120927162055.GA75762@reptiles.org> Message-ID: On 27 September 2012 16:08, Scott Howard wrote: > The Oxford English dictionary apparently disagrees with you. > > > http://oxforddictionaries.com/definition/american_english/guy?region=us&q=guys > (*guys*) people of either sex: * you guys want some coffee? > * > > As other many words in the English language there are multiple definitions, > and one of those definitions is gender specific - but the one above is very > much gender neutral ("either sex" - it doesn't get much clearer than that!) > > Well played Scott, well played. -- Landon Stewart Sr. Administrator Systems Engineering Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead of the Rest": http://www.superbhosting.net From jrhett at netconsonance.com Fri Sep 28 00:33:31 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 27 Sep 2012 17:33:31 -0700 Subject: guys != gender neutral In-Reply-To: <2DE28166-3AEB-451D-80E6-FA00331D8D45@delong.com> References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> <20120927153408.GA11650@nic.fr> <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> <20120927162055.GA75762@reptiles.org> <2DE28166-3AEB-451D-80E6-FA00331D8D45@delong.com> Message-ID: <397A66E0-5C51-4B19-B4A8-D2AC0BE4339C@netconsonance.com> It's not suitable to refer to a single person of either gender. On Sep 27, 2012, at 11:34 AM, Owen DeLong wrote: > When did "people" stop being an acceptable gender-neutral substitute for {guys,gals}? > > Owen > > > Sent from my iPad > > On Sep 27, 2012, at 1:10 PM, Jo Rhett wrote: > >> On Sep 27, 2012, at 9:20 AM, Jim Mercer wrote: >>> On Thu, Sep 27, 2012 at 12:12:50PM -0400, Patrick W. Gilmore wrote: >>>> Many. Although in fairness, some people use "guys" in a gender-neutral manner. >>> >>> some people use it in a globally-neutral manner. >>> "those guys over there" pointing at a rack full of servers. >> >> >> Guys seem to think that it's gender neutral. The majority of women are used to this, but they have indicated to me that they don't believe it to be very neutral. Using "guys" is not gender neutral, it's flat out implying the other gender doesn't matter. * >> >> Given the lack of truly neutral terms in english, I have taken to alternative my pronouns interchangably when I write. >> "Those guys are chewing on that, but these gals are doing the vector calculations." (pointing at different racks of gear) >> >> Or when actually referring to persons of mixed gender, here's a quote from something I posted in a private forum (my own journal) which is safe for export: >> >>> Because frankly, we're all in this together and honestly everyone loves the competition. The guys I race with often come find me afterwards and tell me where they got past me, or ask me how I kept passing them. The really fast girls rarely want more than a beer to go out on the track and give you a detailed breakdown on what you are doing wrong. We all help each other. >> >> >> In this situation I'm leaving it up the reader to grasp that I'm not saying that the girls are all faster than the boys, but I believe it's understood in context as the topic was about how peers help each other out. >> >> I really wish that english had better pronouns for this. >> >> * As evidence of the nasty side effects of this, the bible was translated from a language which understands gender neutral terms to english, and was in translating reduced it to "man". Which is now used by only-english-speaking preachers to justify the "proper placement" of women in society. >> >> If for no other reason than that the use of a single gender pronoun confuses less intelligent types to assume that women aren't important in technology (and god knows this completely baseless assumption is widely held) do your part to mix it up! >> >> -- >> Jo Rhett >> Net Consonance : net philanthropy to improve open source and internet projects. >> >> -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. From jrhett at netconsonance.com Fri Sep 28 00:36:35 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 27 Sep 2012 17:36:35 -0700 Subject: guys != gender neutral In-Reply-To: <50649C93.1090002@gmail.com> References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> <20120927153408.GA11650@nic.fr> <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> <20120927162055.GA75762@reptiles.org> <50649C93.1090002@gmail.com> Message-ID: On Sep 27, 2012, at 11:36 AM, JC Dill wrote: > It's NOT helping to equivocate "guys" and "girls"! *shrug* Sorry you are offended. Some are, most of my friends use those terms interchangeably. (I'm referring to friends of the female gender) Apparently some on the east coast get offended by this, but that post was to a tight audience who I knew well. I use 'boys' and 'guys' interchangeably too, and that probably offends someone. It's not sexism :) > I really wish folks would dig a bit deeper into the thesaurus to find appropriate words. One can use a variety of gender neutral words with some simple re-writing. Remember, it's perfectly OK to employ singular "they" as well. > > http://en.wikipedia.org/wiki/Singular_they I completely disagree. Abusing plural words causes confusion when trying to discuss topics and be specific about the numbers involved. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. From owen at delong.com Fri Sep 28 02:32:17 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 27 Sep 2012 19:32:17 -0700 Subject: RIRs give out unique addresses (Was: something has a /8! ...) In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0C6FF97D@MUNEXBE1.medline.com> References: <4bd0179a-8e3b-4e1d-b43d-b828bce9117c@mail.pelican.org> <9B9685A4-CD22-41E9-957A-23103D2C8F33@corp.arin.net> <505B23C0.4010102@unfix.org> <2A76E400AC84B845AAC35AA19F8E7A5D0C6FF97D@MUNEXBE1.medline.com> Message-ID: <4B327FA3-A5C3-45EB-888F-742D3A537885@delong.com> I believe that this section of NRPM says no. 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. Owen On Sep 20, 2012, at 7:56 AM, "Naslund, Steve" wrote: > I suppose that ARIN would say that they do not guarantee routability > because they do not have operational control of Internet routers. > However, Wouldn't you say that there is a very real expectation that > when you request address space through ARIN or RIPE that it would be > routable? I would think that what ARIN and RIPE are really saying is > that they issue unique addresses and you need to get your service > provider to route them. FWIW, the discussion of the military having > addresses pulled back is pretty much a non-starter unless they want to > give them back. When the management of IP address space was moved from > the US DoD, there were memorandums of understanding that the military > controlled their assigned address space and nothing would change that. > I know this for a fact because I was around this discussion in the US > Air Force. > > Steven Naslund > > -----Original Message----- > From: John Curran [mailto:jcurran at arin.net] > Sent: Thursday, September 20, 2012 9:40 AM > To: Jeroen Massar > Cc: NANOG list > Subject: Re: RIRs give out unique addresses (Was: something has a /8! > ...) > > On Sep 20, 2012, at 10:10 AM, Jeroen Massar > wrote: >> On 2012-09-20 16:01 , John Curran wrote: >>> >>> It's very clear in the ARIN region as well. From the ARIN Number >>> Resource Policy Manual (NRPM), >>> - >>> >>> "4.1. General Principles 4.1.1. Routability Provider independent >>> (portable) addresses issued directly from ARIN or other Regional >>> Registries are not guaranteed to be globally routable." >> >> While close, that is not the same. >> >> The RIPE variant solely guarantees uniqueness of the addresses. >> >> The ARIN variant states "we don't guarantee that you can route it >> everywhere", which is on top of the uniqueness portion. > > Agreed - I called it out because ARIN, like RIPE, does not assert that > the address blocks issued are "publicly routable address space" > (i.e. which was Tim Franklin's original statement, but he did not have > on hand the comparable ARIN reference for that point.) > > FYI, > /John > > > > From jason at thebaughers.com Fri Sep 28 03:19:25 2012 From: jason at thebaughers.com (Jason Baugher) Date: Thu, 27 Sep 2012 22:19:25 -0500 Subject: guys != gender neutral In-Reply-To: References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> <20120927153408.GA11650@nic.fr> <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> <20120927162055.GA75762@reptiles.org> <50649C93.1090002@gmail.com> Message-ID: <5065173D.4050609@thebaughers.com> I think people should get the sand out of their crack (notice that both genders have a crack, wouldn't want to offend anyone) and quit looking for the bogey-man behind every door. If you constantly look for things to offend, you'll be constantly offended. On 9/27/2012 7:36 PM, Jo Rhett wrote: > On Sep 27, 2012, at 11:36 AM, JC Dill wrote: >> It's NOT helping to equivocate "guys" and "girls"! > *shrug* Sorry you are offended. Some are, most of my friends use those terms interchangeably. (I'm referring to friends of the female gender) Apparently some on the east coast get offended by this, but that post was to a tight audience who I knew well. I use 'boys' and 'guys' interchangeably too, and that probably offends someone. It's not sexism :) > >> I really wish folks would dig a bit deeper into the thesaurus to find appropriate words. One can use a variety of gender neutral words with some simple re-writing. Remember, it's perfectly OK to employ singular "they" as well. >> >> http://en.wikipedia.org/wiki/Singular_they > > I completely disagree. Abusing plural words causes confusion when trying to discuss topics and be specific about the numbers involved. > From trelane at trelane.net Fri Sep 28 03:24:35 2012 From: trelane at trelane.net (Andrew D Kirch) Date: Thu, 27 Sep 2012 23:24:35 -0400 Subject: guys & dolls (a film motif) In-Reply-To: <20120927205937.GA15705@vacation.karoshi.com.> References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> <20120927153408.GA11650@nic.fr> <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> <20120927162055.GA75762@reptiles.org> <5064A1A0.8030700@trelane.net> <20120927202804.GA6069@esri.com> <20120927203648.GB15531@vacation.karoshi.com.> <5064BB54.90405@trelane.net> <20120927205937.GA15705@vacation.karoshi.com.> Message-ID: <50651873.3090004@trelane.net> I didn't think any of this should be discussed here, but I'm sick and tired of entitled whiners griping about some word that offends them. This still is not a real problem, and ALL of my points still apply. Andrew On 9/27/2012 4:59 PM, bmanning at vacation.karoshi.com wrote: > thank you for your kind words and attempts to educate. clearly these items are > critical for North American Network Operations (NANOG) and should be widely promoted > and discussed ... But NOT, I think, here. > > may i humbly suggest that there exist other, better fora for discussion of these specific > issues and ways/means to address them; > > Aleviating HUNGER > Global Peace - where none take offense > Exploitation of the helpless > Definition of rights, both human and non-human. > > I would like to point you here: http://www.un.org/en/rights/ which actually has the charter > to work on the issues that are so pressing in your mind. > > Can we kill this thread (oh dear, i'm advocating violence again...) and get back to Network > Operations? Please? > > /bill > > > On Thu, Sep 27, 2012 at 04:47:16PM -0400, Andrew D Kirch wrote: >> This isn't a real issue. HUNGER is a real issue. WAR is a real issue. >> 12 year old girls being sold for $20 into SLAVERY in India is a real >> issue. TERRORist attacks on embassies are real issues. Expansion of >> POLICE power is a real issue. Erosion of human and civil RIGHTS are >> real issues. This is window dressing. I've highlighted the important >> words for you, and for emphasis, because obviously you don't get it. >> >> Andrew >> >> On 9/27/2012 4:36 PM, bmanning at vacation.karoshi.com wrote: >>> http://en.wikipedia.org/wiki/Guys_and_Dolls_(film) >>> >>> i -think- the term we are looking for is: Troglodyte >>> >>> 1: >>> A person considered to be reclusive, reactionary, out of date, or brutish. >>> >>> >>> /bill (top posting like a civilized human...) >>> >>> >>> On Thu, Sep 27, 2012 at 01:28:04PM -0700, Ray Van Dolson wrote: >>>> On Thu, Sep 27, 2012 at 02:57:36PM -0400, Andrew D Kirch wrote: >>>>> I really wish people would get over themselves and get to work. >>>>> Work is a place where things get done, not where people piss and >>>>> moan about every single perceived slight they can come up with. >>>>> >>>>> Andrew >>>> I only wish you had used 'guys' instead of 'people' :) >>>> >>>> Ray From dougb at dougbarton.us Fri Sep 28 03:33:10 2012 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 27 Sep 2012 17:33:10 -1000 Subject: guys & dolls (a film motif) In-Reply-To: <50651873.3090004@trelane.net> References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> <20120927153408.GA11650@nic.fr> <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> <20120927162055.GA75762@reptiles.org> <5064A1A0.8030700@trelane.net> <20120927202804.GA6069@esri.com> <20120927203648.GB15531@vacation.karoshi.com.> <5064BB54.90405@trelane.net> <20120927205937.GA15705@vacation.karoshi.com.> <50651873.3090004@trelane.net> Message-ID: <50651A76.6090208@dougbarton.us> Regardless of how y'all may feel about these issues personally, like most things regarding fellow humans The Robustness Principle definitely applies here. From johnl at iecc.com Fri Sep 28 03:58:32 2012 From: johnl at iecc.com (John Levine) Date: 28 Sep 2012 03:58:32 -0000 Subject: guys & dolls (a film motif) In-Reply-To: <50651873.3090004@trelane.net> Message-ID: <20120928035832.87330.qmail@joyce.lan> >>>>> I only wish you had used 'guys' instead of 'people' :) Speciesist troglodyte. From joelja at bogus.com Thu Sep 27 14:39:57 2012 From: joelja at bogus.com (joel jaeggli) Date: Thu, 27 Sep 2012 07:39:57 -0700 Subject: /. Terabit Ethernet is Dead, for Now In-Reply-To: References: <20120927125157.GT9750@leitl.org> Message-ID: <5064653D.9020102@bogus.com> On 9/27/12 5:58 AM, Darius Jahandarie wrote: > On Thu, Sep 27, 2012 at 8:51 AM, Eugen Leitl wrote: >> http://slashdot.org/topic/datacenter/terabit-ethernet-is-dead-for-now/ >> >> Terabit Ethernet is Dead, for Now > I recall 40Gbit/s Ethernet being promoted heavily for similar reasons > as the ones in this article, but then 100Gbit/s being the technology > that actually ended up in most places. Could this be the same thing > happening? > 40Gb/s appears to be doing just fine in top of rack switches and datacenter distribution layer. Given that it's in most server NIC roadmaps in the relatively near term it doesn't have significant barriers to becoming the volume offering of choice. getting datacenters off of om3/4 multimode distribution is a long project however. From bjorn at mork.no Fri Sep 28 09:00:22 2012 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Fri, 28 Sep 2012 11:00:22 +0200 Subject: guys != gender neutral In-Reply-To: (Scott Howard's message of "Thu, 27 Sep 2012 16:08:11 -0700") References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> <20120927153408.GA11650@nic.fr> <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> <20120927162055.GA75762@reptiles.org> Message-ID: <87vceyy121.fsf@nemi.mork.no> Scott Howard writes: > On Thu, Sep 27, 2012 at 11:10 AM, Jo Rhett wrote: > >> Guys seem to think that it's gender neutral. The majority of women are >> used to this, but they have indicated to me that they don't believe it to >> be very neutral. Using "guys" is not gender neutral, it's flat out implying >> the other gender doesn't matter. * >> > > The Oxford English dictionary apparently disagrees with you. > > http://oxforddictionaries.com/definition/american_english/guy?region=us&q=guys > (*guys*) people of either sex: * you guys want some coffee? > * > > As other many words in the English language there are multiple definitions, > and one of those definitions is gender specific - but the one above is very > much gender neutral ("either sex" - it doesn't get much clearer than that!) Well, "either" sort of implies that there are only two sexes. I believe "people of any sex" would have been better. See e.g. http://en.wikipedia.org/wiki/Third_gender Bj?rn From tim at pelican.org Fri Sep 28 09:27:10 2012 From: tim at pelican.org (Tim Franklin) Date: Fri, 28 Sep 2012 10:27:10 +0100 (BST) Subject: guys != gender neutral In-Reply-To: Message-ID: <543f4532-1271-4f9e-a2e3-d17cea201022@mail.pelican.org> > Given the lack of truly neutral terms in english, I have > taken to alternative my pronouns interchangably when I write. "Folks"? I really do mean "folks" when I write "guys", but I do understand why it can come across as exclusionary, and I try to force myself into the habit of "folks". It sounds a bit odd in English, although not as archaic as "chaps", which I'm also guilty of; I'm assuming there's no additional cultural assumptions attached to "folks" in American? Cheers, Tim. From randy at psg.com Fri Sep 28 10:29:05 2012 From: randy at psg.com (Randy Bush) Date: Fri, 28 Sep 2012 12:29:05 +0200 Subject: guys != gender neutral In-Reply-To: <543f4532-1271-4f9e-a2e3-d17cea201022@mail.pelican.org> References: <543f4532-1271-4f9e-a2e3-d17cea201022@mail.pelican.org> Message-ID: > "Folks"? I really do mean "folks" when I write "guys", folk is the plural and, as far as the use of gender-biased terms, as someone said well the other day, when you are in a hole, stop digging randy From eric at eparsonage.com Fri Sep 28 10:35:31 2012 From: eric at eparsonage.com (Eric Parsonage) Date: Fri, 28 Sep 2012 20:05:31 +0930 Subject: guys != gender neutral In-Reply-To: <87vceyy121.fsf@nemi.mork.no> References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> <20120927153408.GA11650@nic.fr> <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> <20120927162055.GA75762@reptiles.org> <87vceyy121.fsf@nemi.mork.no> Message-ID: The assumption of a 1-1 correspondence between gender and sex is old fashioned nowadays. On 28/09/2012, at 6:30 PM, Bj?rn Mork wrote: > Scott Howard writes: >> On Thu, Sep 27, 2012 at 11:10 AM, Jo Rhett wrote: >> >>> Guys seem to think that it's gender neutral. The majority of women are >>> used to this, but they have indicated to me that they don't believe it to >>> be very neutral. Using "guys" is not gender neutral, it's flat out implying >>> the other gender doesn't matter. * >>> >> >> The Oxford English dictionary apparently disagrees with you. >> >> http://oxforddictionaries.com/definition/american_english/guy?region=us&q=guys >> (*guys*) people of either sex: * you guys want some coffee? >> * >> >> As other many words in the English language there are multiple definitions, >> and one of those definitions is gender specific - but the one above is very >> much gender neutral ("either sex" - it doesn't get much clearer than that!) > > Well, "either" sort of implies that there are only two sexes. I believe > "people of any sex" would have been better. See e.g. > http://en.wikipedia.org/wiki/Third_gender > > > Bj?rn > From otis at ocosa.com Fri Sep 28 11:32:56 2012 From: otis at ocosa.com (Otis L. Surratt, Jr.) Date: Fri, 28 Sep 2012 06:32:56 -0500 Subject: guys != gender neutral In-Reply-To: <543f4532-1271-4f9e-a2e3-d17cea201022@mail.pelican.org> References: <543f4532-1271-4f9e-a2e3-d17cea201022@mail.pelican.org> Message-ID: <5FE1FB6D43B8A647BBC821840C1AEA8B017E12@ocsbs.ocosa.com> Maybe the OP for "really nasty attacks" in hindsight wishes "NANOGers" was used instead to address the list. :) Having "all walks of life" essentially all around, it really makes one careful to truly think before speaking. Sometimes we miss this with everything we have going on, but no one is perfect. The bottomline is, no one can really sastifisfy any indivdual and their preference of how they would liked to be addressed. If one is to be offended or looks for offense they will capitalize on it period. I try much as possible to avoid those situations. When we refer to our clients in a mass communication we either utilize our tools to auto fix their name to the letter or we address them as "OCOSA Family" or "All" or "Clients". We are a very family-oriented business and are "down to Earth." We'd like to believe our clients are apart of our family and some may take offense but you might or never would know unless an opportunity presented itself. Personally, I practice using the person's name, I am in communication with...not "buddy", "bud", "pal", "man", "guys", "gal" "y'all" and etc. When addressing mixed gender groups, I simply speak or address as "all". Thus, no mistakes. When addressing both genders you have to be extremely careful. Ultimately, It depends on the audience and treating all with respect seems to work for me. For example: You could address a group a men and call them "boys". Well, that might offend some, especially if they are older than you. For example: You could address a group of young adults and call them "kids". Well, that might offend some. As Owen mentioned saying "human" seems okay and true but then again, because it's not the norm it raises some question. (Internal thinking process, "Oh I'm a HUMAN!!!!, well I that is true" then your temperature gets back to normal) :) In general, this is life and I simply have fun and enjoy it because it's too short. Otis From jgreco at ns.sol.net Fri Sep 28 11:13:57 2012 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 28 Sep 2012 06:13:57 -0500 (CDT) Subject: guys != gender neutral In-Reply-To: Message-ID: <201209281113.q8SBDvJs097053@aurora.sol.net> > > Guys seem to think that it's gender neutral. The majority of women are > > used to this, but they have indicated to me that they don't believe it to > > be very neutral. Using "guys" is not gender neutral, it's flat out implying > > the other gender doesn't matter. * > > The Oxford English dictionary apparently disagrees with you. > > http://oxforddictionaries.com/definition/american_english/guy?region=us&q=guys > (*guys*) people of either sex: * you guys want some coffee? > * > > As other many words in the English language there are multiple definitions, > and one of those definitions is gender specific - but the one above is very > much gender neutral ("either sex" - it doesn't get much clearer than that!) The modern English language generally lacks gender-neutral singular personal pronouns that are distinct from the masculine versions; this is either a bug or a feature of the language, but it is also a fact. Some advocate the use of indefinite pronouns to work around this lack, but fundamentally, if you want to interoperate with others who speak English, it is going to be a losing battle to be offended when "guys" is used. The argument in the first quoted paragraph isn't strictly rational. It could easily be argued that women get the special term "gals" that does refer exclusively to women, while men get the more general term "guys" that does not exclusively refer to men. This could easily be taken to mean that women matter more than men, because they get their own special term. However, in reality, this appears to be mostly an exercise in how to find ways to be offended at random things that are simply part of the language, and if someone is just setting out to find ways to be offended, nobody better open their mouth to begin with... I would propose that randomly switching back and forth between "guys" and "gals" is a violation of Postel's robustness principle (look at that NANOG tie-in!), because being conservative about what you're sending probably means not referring to males with the term "gals." On the other hand, using indefinite pronouns when speaking would be a suitable workaround under that guidance. Rather than further breaking the language, it might be more sensible to modify the language to address the deficiency. Maybe that's an RFC, or just needs a real-world working implementation, but I'll note that several gender-neutral pronouns have died out, so maybe there's just no demand. :-) ... 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 mfidelman at meetinghouse.net Fri Sep 28 11:43:21 2012 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Fri, 28 Sep 2012 07:43:21 -0400 Subject: guys != gender neutral In-Reply-To: <201209281113.q8SBDvJs097053@aurora.sol.net> References: <201209281113.q8SBDvJs097053@aurora.sol.net> Message-ID: <50658D59.3040304@meetinghouse.net> Given that this thread started out as a query re. a "really nasty attack," and resulted in: 5 on-topic responses (2 of which also commented on "guys") >20 responses re. "guys" (I stopped counting) It occurs to me that maybe "morons" or "idiots" might be an appropriate gender-neutral framing. -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From bmanning at vacation.karoshi.com Fri Sep 28 12:07:29 2012 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 28 Sep 2012 12:07:29 +0000 Subject: RIRs give out unique addresses (Was: something has a /8! ...) In-Reply-To: <4B327FA3-A5C3-45EB-888F-742D3A537885@delong.com> References: <4bd0179a-8e3b-4e1d-b43d-b828bce9117c@mail.pelican.org> <9B9685A4-CD22-41E9-957A-23103D2C8F33@corp.arin.net> <505B23C0.4010102@unfix.org> <2A76E400AC84B845AAC35AA19F8E7A5D0C6FF97D@MUNEXBE1.medline.com> <4B327FA3-A5C3-45EB-888F-742D3A537885@delong.com> Message-ID: <20120928120729.GA17888@vacation.karoshi.com.> not how i read that section Owen... "...networks require interconnectivity and the private IP address numbers are ineffective, globally unique addresses may be requested and used to provide this interconnectivity." One does not have to request RFC 1918 space from ARIN (or other RIR) and the NRPM is mute on legacy address assignments wrt "connectivity". /bill On Thu, Sep 27, 2012 at 07:32:17PM -0700, Owen DeLong wrote: > I believe that this section of NRPM says no. > > 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. > > Owen > > On Sep 20, 2012, at 7:56 AM, "Naslund, Steve" wrote: > > > I suppose that ARIN would say that they do not guarantee routability > > because they do not have operational control of Internet routers. > > However, Wouldn't you say that there is a very real expectation that > > when you request address space through ARIN or RIPE that it would be > > routable? I would think that what ARIN and RIPE are really saying is > > that they issue unique addresses and you need to get your service > > provider to route them. FWIW, the discussion of the military having > > addresses pulled back is pretty much a non-starter unless they want to > > give them back. When the management of IP address space was moved from > > the US DoD, there were memorandums of understanding that the military > > controlled their assigned address space and nothing would change that. > > I know this for a fact because I was around this discussion in the US > > Air Force. > > > > Steven Naslund > > > > -----Original Message----- > > From: John Curran [mailto:jcurran at arin.net] > > Sent: Thursday, September 20, 2012 9:40 AM > > To: Jeroen Massar > > Cc: NANOG list > > Subject: Re: RIRs give out unique addresses (Was: something has a /8! > > ...) > > > > On Sep 20, 2012, at 10:10 AM, Jeroen Massar > > wrote: > >> On 2012-09-20 16:01 , John Curran wrote: > >>> > >>> It's very clear in the ARIN region as well. From the ARIN Number > >>> Resource Policy Manual (NRPM), > >>> - > >>> > >>> "4.1. General Principles 4.1.1. Routability Provider independent > >>> (portable) addresses issued directly from ARIN or other Regional > >>> Registries are not guaranteed to be globally routable." > >> > >> While close, that is not the same. > >> > >> The RIPE variant solely guarantees uniqueness of the addresses. > >> > >> The ARIN variant states "we don't guarantee that you can route it > >> everywhere", which is on top of the uniqueness portion. > > > > Agreed - I called it out because ARIN, like RIPE, does not assert that > > the address blocks issued are "publicly routable address space" > > (i.e. which was Tim Franklin's original statement, but he did not have > > on hand the comparable ARIN reference for that point.) > > > > FYI, > > /John > > > > > > > > > > From aledm at qix.co.uk Fri Sep 28 12:40:14 2012 From: aledm at qix.co.uk (Aled Morris) Date: Fri, 28 Sep 2012 13:40:14 +0100 Subject: guys != gender neutral In-Reply-To: <013501cd9cf7$e495cc50$adc164f0$@hathcock.org> References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> <20120927153408.GA11650@nic.fr> <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> <20120927162055.GA75762@reptiles.org> <2DE28166-3AEB-451D-80E6-FA00331D8D45@delong.com> <013501cd9cf7$e495cc50$adc164f0$@hathcock.org> Message-ID: On 27 September 2012 22:34, Lorell Hathcock wrote: > Police-clown. Yep! Here in the UK, apparently the government preferred term for policepersons is "pleb"... http://duckduckgo.com/?q=police+pleb Aled From marine64 at gmail.com Fri Sep 28 13:00:48 2012 From: marine64 at gmail.com (Brian Henson) Date: Fri, 28 Sep 2012 09:00:48 -0400 Subject: guys != gender neutral In-Reply-To: References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> <20120927153408.GA11650@nic.fr> <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> <20120927162055.GA75762@reptiles.org> <2DE28166-3AEB-451D-80E6-FA00331D8D45@delong.com> <013501cd9cf7$e495cc50$adc164f0$@hathcock.org> Message-ID: Are we really still talking about this? On Fri, Sep 28, 2012 at 8:40 AM, Aled Morris wrote: > On 27 September 2012 22:34, Lorell Hathcock wrote: > > Police-clown. Yep! > > Here in the UK, apparently the government preferred term for > policepersons is "pleb"... > > http://duckduckgo.com/?q=police+pleb > > Aled > > From jamie at photon.com Fri Sep 28 13:06:31 2012 From: jamie at photon.com (Jamie Bowden) Date: Fri, 28 Sep 2012 13:06:31 +0000 Subject: guys != gender neutral In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8B017E12@ocsbs.ocosa.com> References: <543f4532-1271-4f9e-a2e3-d17cea201022@mail.pelican.org> <5FE1FB6D43B8A647BBC821840C1AEA8B017E12@ocsbs.ocosa.com> Message-ID: <465966A5F5B867419F604CD3E604C1E50C591C65@PRA-DCA-MAIL.pra.ray.com> > From: Otis L. Surratt, Jr. [mailto:otis at ocosa.com] > As Owen mentioned saying "human" seems okay and true but then again, > because it's not the norm it raises some question. (Internal thinking > process, "Oh I'm a HUMAN!!!!, well I that is true" then your > temperature gets back to normal) :) Listen up you prehistoric screwheads... Jamie From owen at delong.com Fri Sep 28 14:04:43 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 28 Sep 2012 07:04:43 -0700 Subject: RIRs give out unique addresses (Was: something has a /8! ...) In-Reply-To: <20120928120729.GA17888@vacation.karoshi.com.> References: <4bd0179a-8e3b-4e1d-b43d-b828bce9117c@mail.pelican.org> <9B9685A4-CD22-41E9-957A-23103D2C8F33@corp.arin.net> <505B23C0.4010102@unfix.org> <2A76E400AC84B845AAC35AA19F8E7A5D0C6FF97D@MUNEXBE1.medline.com> <4B327FA3-A5C3-45EB-888F-742D3A537885@delong.com> <20120928120729.GA17888@vacation.karoshi.com.> Message-ID: <45AD64C0-349D-48C4-968A-A18B2EA4E4C4@delong.com> Bill, I am unable to make sense of your reply. The question I was answering was: "Wouldn't you say that there is a very real expectation that when you request address space through ARIN or RIPE that it would be routable?" (Which I admit at the time I interpreted to also indicate an expectation that it would be routed, but I see now could be ambiguous). In that context, I believe that the policy section I quoted indicates that there is no expectation that numbers issued by ARIN or RIPE (or any other RIR) "will be routed" and other policy sections certainly convey that ARIN (and the other RIRs) have no control over routers, so I'm not sure it matters what they say about routability. As to your statement about legacy assignments, I fail to see any part of ARIN policy that distinguishes them from any other assignment with regards to the application of policy. However, other than the section quoted below (which essentially states that some level of connectivity is required to justify new resource allocations or assignments), I believe that the NRPM is mute with regards to connectivity on all addresses. Since there are, by definition, no new legacy allocations or assignments, I'm not sure how legacy is relevant to the discussion at hand. Owen On Sep 28, 2012, at 5:07 AM, bmanning at vacation.karoshi.com wrote: > > not how i read that section Owen... > > "...networks require interconnectivity and the private IP address numbers are > ineffective, globally unique addresses may be requested and used to provide this interconnectivity." > > One does not have to request RFC 1918 space from ARIN (or other RIR) > > and the NRPM is mute on legacy address assignments wrt "connectivity". > > /bill > > > On Thu, Sep 27, 2012 at 07:32:17PM -0700, Owen DeLong wrote: >> I believe that this section of NRPM says no. >> >> 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. >> >> Owen >> >> On Sep 20, 2012, at 7:56 AM, "Naslund, Steve" wrote: >> >>> I suppose that ARIN would say that they do not guarantee routability >>> because they do not have operational control of Internet routers. >>> However, Wouldn't you say that there is a very real expectation that >>> when you request address space through ARIN or RIPE that it would be >>> routable? I would think that what ARIN and RIPE are really saying is >>> that they issue unique addresses and you need to get your service >>> provider to route them. FWIW, the discussion of the military having >>> addresses pulled back is pretty much a non-starter unless they want to >>> give them back. When the management of IP address space was moved from >>> the US DoD, there were memorandums of understanding that the military >>> controlled their assigned address space and nothing would change that. >>> I know this for a fact because I was around this discussion in the US >>> Air Force. >>> >>> Steven Naslund >>> >>> -----Original Message----- >>> From: John Curran [mailto:jcurran at arin.net] >>> Sent: Thursday, September 20, 2012 9:40 AM >>> To: Jeroen Massar >>> Cc: NANOG list >>> Subject: Re: RIRs give out unique addresses (Was: something has a /8! >>> ...) >>> >>> On Sep 20, 2012, at 10:10 AM, Jeroen Massar >>> wrote: >>>> On 2012-09-20 16:01 , John Curran wrote: >>>>> >>>>> It's very clear in the ARIN region as well. From the ARIN Number >>>>> Resource Policy Manual (NRPM), >>>>> - >>>>> >>>>> "4.1. General Principles 4.1.1. Routability Provider independent >>>>> (portable) addresses issued directly from ARIN or other Regional >>>>> Registries are not guaranteed to be globally routable." >>>> >>>> While close, that is not the same. >>>> >>>> The RIPE variant solely guarantees uniqueness of the addresses. >>>> >>>> The ARIN variant states "we don't guarantee that you can route it >>>> everywhere", which is on top of the uniqueness portion. >>> >>> Agreed - I called it out because ARIN, like RIPE, does not assert that >>> the address blocks issued are "publicly routable address space" >>> (i.e. which was Tim Franklin's original statement, but he did not have >>> on hand the comparable ARIN reference for that point.) >>> >>> FYI, >>> /John >>> >>> >>> >>> >> >> From jra at baylink.com Fri Sep 28 14:18:42 2012 From: jra at baylink.com (Jay Ashworth) Date: Fri, 28 Sep 2012 10:18:42 -0400 (EDT) Subject: WAY OT Re: guys != gender neutral In-Reply-To: Message-ID: <27329992.27100.1348841922081.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > > As a form of address. "Hey, people" is ... well, nearly abrasive. > > (Envision a waitron walking up to a mixed table of 10.) > > > > Sure, in that limited context. In such a circumstance, I believe the phrase > "ladies and gentlem[ae]n" is usually adequate and equally gender neutral. Yes, cause Hooters waitresses are gonna use that phrasing all day long. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From owen at delong.com Fri Sep 28 14:18:54 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 28 Sep 2012 07:18:54 -0700 Subject: guys != gender neutral In-Reply-To: References: <543f4532-1271-4f9e-a2e3-d17cea201022@mail.pelican.org> Message-ID: <0673D7C0-B2CA-4797-8907-921B6B77570D@delong.com> On Sep 28, 2012, at 3:29 AM, Randy Bush wrote: >> "Folks"? I really do mean "folks" when I write "guys", > > > > folk is the plural > > and, as far as the use of gender-biased terms, as someone said well the > other day, when you are in a hole, stop digging > > randy According to my Dictionary, both "folk" and "folks" are acceptable plurals. Owen From jason at thebaughers.com Fri Sep 28 14:34:39 2012 From: jason at thebaughers.com (Jason Baugher) Date: Fri, 28 Sep 2012 09:34:39 -0500 Subject: WAY OT Re: guys != gender neutral In-Reply-To: <27329992.27100.1348841922081.JavaMail.root@benjamin.baylink.com> References: <27329992.27100.1348841922081.JavaMail.root@benjamin.baylink.com> Message-ID: <5065B57F.4090607@thebaughers.com> On 9/28/2012 9:18 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Owen DeLong" >>> As a form of address. "Hey, people" is ... well, nearly abrasive. >>> (Envision a waitron walking up to a mixed table of 10.) >>> >> Sure, in that limited context. In such a circumstance, I believe the phrase >> "ladies and gentlem[ae]n" is usually adequate and equally gender neutral. > Yes, cause Hooters waitresses are gonna use that phrasing all day long. :-) > > Cheers, > -- jra I like it when they call me "sweetie". Is that sexist? :) From Valdis.Kletnieks at vt.edu Fri Sep 28 14:34:20 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 28 Sep 2012 10:34:20 -0400 Subject: guys != gender neutral In-Reply-To: Your message of "Fri, 28 Sep 2012 07:43:21 -0400." <50658D59.3040304@meetinghouse.net> References: <201209281113.q8SBDvJs097053@aurora.sol.net> <50658D59.3040304@meetinghouse.net> Message-ID: <12258.1348842860@turing-police.cc.vt.edu> On Fri, 28 Sep 2012 07:43:21 -0400, Miles Fidelman said: > Given that this thread started out as a query re. a "really nasty > attack," and resulted in: > 5 on-topic responses (2 of which also commented on "guys") > >20 responses re. "guys" (I stopped counting) > It occurs to me that maybe "morons" or "idiots" might be an appropriate > gender-neutral framing. I usually use 'critters' for that. salescritters, congresscritters, trollcritters. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Fri Sep 28 14:38:42 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 28 Sep 2012 10:38:42 -0400 Subject: guys != gender neutral In-Reply-To: Your message of "Fri, 28 Sep 2012 07:18:54 -0700." <0673D7C0-B2CA-4797-8907-921B6B77570D@delong.com> References: <543f4532-1271-4f9e-a2e3-d17cea201022@mail.pelican.org> <0673D7C0-B2CA-4797-8907-921B6B77570D@delong.com> Message-ID: <12482.1348843122@turing-police.cc.vt.edu> On Fri, 28 Sep 2012 07:18:54 -0700, Owen DeLong said: > > On Sep 28, 2012, at 3:29 AM, Randy Bush wrote: > > >> "Folks"? I really do mean "folks" when I write "guys", > > > > > > > > folk is the plural > > > > and, as far as the use of gender-biased terms, as someone said well the > > other day, when you are in a hole, stop digging > > > > randy > > According to my Dictionary, both "folk" and "folks" are acceptable plurals. Somebody I know once described somebody else as 'pendantic'. I asked "Don't you mean pedantic?" and he replied "No, *you're* pedantic for asking. He just hangs around with nothing better to do." :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From mfidelman at meetinghouse.net Fri Sep 28 15:40:43 2012 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Fri, 28 Sep 2012 11:40:43 -0400 Subject: guys != gender neutral In-Reply-To: <12258.1348842860@turing-police.cc.vt.edu> References: <201209281113.q8SBDvJs097053@aurora.sol.net> <50658D59.3040304@meetinghouse.net> <12258.1348842860@turing-police.cc.vt.edu> Message-ID: <5065C4FB.6080100@meetinghouse.net> Valdis.Kletnieks at vt.edu wrote: > On Fri, 28 Sep 2012 07:43:21 -0400, Miles Fidelman said: >> Given that this thread started out as a query re. a "really nasty >> attack," and resulted in: >> 5 on-topic responses (2 of which also commented on "guys") >> >20 responses re. "guys" (I stopped counting) >> It occurs to me that maybe "morons" or "idiots" might be an appropriate >> gender-neutral framing. > I usually use 'critters' for that. salescritters, congresscritters, trollcritters. I'm kind of a fan of Greg House on this one. Or Mel Brooks, from Blazing Saddles: ?They?re common people ? the salt of the earth. You know ? Morons?. :-) -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From jra at baylink.com Fri Sep 28 16:15:48 2012 From: jra at baylink.com (Jay Ashworth) Date: Fri, 28 Sep 2012 12:15:48 -0400 (EDT) Subject: guys != gender neutral In-Reply-To: Message-ID: <8327.27152.1348848948402.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Eric Parsonage" > The assumption of a 1-1 correspondence between gender and sex is old > fashioned nowadays. Mammals have sex. *Words* (and only words) have gender. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Fri Sep 28 16:17:43 2012 From: jra at baylink.com (Jay Ashworth) Date: Fri, 28 Sep 2012 12:17:43 -0400 (EDT) Subject: guys != gender neutral In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8B017E12@ocsbs.ocosa.com> Message-ID: <28246235.27154.1348849063336.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Otis L. Surratt, Jr." > Having "all walks of life" essentially all around, it really makes one > careful to truly think before speaking. Sometimes we miss this with > everything we have going on, but no one is perfect. > > The bottomline is, no one can really sastifisfy any indivdual and > their preference of how they would liked to be addressed. If one is to > be offended or looks for offense they will capitalize on it period. I > try much as possible to avoid those situations. As is embodied in the FidoNet Principle: Be ye not overly annoying... nor *too easily annoyed*. (Emphasis mine). It comes down to "if you accuse people of malice in things they said without any, of course they're going to start a fight with you." Cheers, -- jar -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From streiner at cluebyfour.org Fri Sep 28 16:27:48 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 28 Sep 2012 12:27:48 -0400 (EDT) Subject: guys != gender neutral In-Reply-To: <28246235.27154.1348849063336.JavaMail.root@benjamin.baylink.com> References: <28246235.27154.1348849063336.JavaMail.root@benjamin.baylink.com> Message-ID: Note: this will be my one and only contribution to this thread. While this thread has generated some very interesting and thought-provoking discussions, I still think it strays pretty far from being on-topic for NANOG. That being the case, let's all get back to operating our respective networks and let this thread go. Thanks jms From simon.perreault at viagenie.ca Fri Sep 28 16:43:36 2012 From: simon.perreault at viagenie.ca (Simon Perreault) Date: Fri, 28 Sep 2012 12:43:36 -0400 Subject: guys != gender neutral In-Reply-To: <8327.27152.1348848948402.JavaMail.root@benjamin.baylink.com> References: <8327.27152.1348848948402.JavaMail.root@benjamin.baylink.com> Message-ID: <5065D3B8.8080704@viagenie.ca> Le 2012-09-28 12:15, Jay Ashworth a ?crit : >> The assumption of a 1-1 correspondence between gender and sex is old >> fashioned nowadays. > > Mammals have sex. > > *Words* (and only words) have gender. There's an RFC about that! RFC 6350, section 6.2.7, about the GENDER vCard property: 6.2.7. GENDER Purpose: To specify the components of the sex and gender identity of the object the vCard represents. Value type: A single structured value with two components. Each component has a single text value. Cardinality: *1 Special notes: The components correspond, in sequence, to the sex (biological), and gender identity. Each component is optional. Sex component: A single letter. M stands for "male", F stands for "female", O stands for "other", N stands for "none or not applicable", U stands for "unknown". Gender identity component: Free-form text. ABNF: GENDER-param = "VALUE=text" / any-param GENDER-value = sex [";" text] sex = "" / "M" / "F" / "O" / "N" / "U" Examples: GENDER:M GENDER:F GENDER:M;Fellow GENDER:F;grrrl GENDER:O;intersex GENDER:;it's complicated 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 frogstarr78 at gmail.com Fri Sep 28 16:55:55 2012 From: frogstarr78 at gmail.com (Scott Noel-Hemming) Date: Fri, 28 Sep 2012 09:55:55 -0700 Subject: guys != gender neutral In-Reply-To: <5065D3B8.8080704@viagenie.ca> References: <8327.27152.1348848948402.JavaMail.root@benjamin.baylink.com> <5065D3B8.8080704@viagenie.ca> Message-ID: <5065D69B.5050704@gmail.com> On 09/28/2012 09:43 AM, Simon Perreault wrote: > Le 2012-09-28 12:15, Jay Ashworth a ?crit : >>> The assumption of a 1-1 correspondence between gender and sex is old >>> fashioned nowadays. >> >> Mammals have sex. >> >> *Words* (and only words) have gender. > > There's an RFC about that! RFC 6350, section 6.2.7, about the GENDER > vCard property: > > 6.2.7. GENDER > > Purpose: To specify the components of the sex and gender identity of > the object the vCard represents. > > Value type: A single structured value with two components. Each > component has a single text value. > > Cardinality: *1 > > Special notes: The components correspond, in sequence, to the sex > (biological), and gender identity. Each component is optional. > > Sex component: A single letter. M stands for "male", F stands > for "female", O stands for "other", N stands for "none or not > applicable", U stands for "unknown". > > Gender identity component: Free-form text. > > ABNF: > > GENDER-param = "VALUE=text" / any-param > GENDER-value = sex [";" text] > > sex = "" / "M" / "F" / "O" / "N" / "U" > > Examples: > > GENDER:M > GENDER:F > GENDER:M;Fellow > GENDER:F;grrrl > GENDER:O;intersex > GENDER:;it's complicated > > Simon +1 for bringing it back to a technical discussion in a round about way. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From jra at baylink.com Fri Sep 28 17:02:51 2012 From: jra at baylink.com (Jay Ashworth) Date: Fri, 28 Sep 2012 13:02:51 -0400 (EDT) Subject: guys != gender neutral In-Reply-To: <5065D3B8.8080704@viagenie.ca> Message-ID: <20518189.27160.1348851771296.JavaMail.root@benjamin.baylink.com> ---- Original Message ----- > From: "Simon Perreault" > > *Words* (and only words) have gender. > > There's an RFC about that! RFC 6350, section 6.2.7, about the GENDER > vCard property: And kudos to Simon for bring it back to a semblence of on-topic-ness. Glad to see that the authors of 6350 were thinking ahead, but I (and I think OED) will continue to quibble with the choice of word. Just appropriating words that mean other things is generally not a safe approach... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jmaimon at ttec.com Fri Sep 28 18:08:46 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Fri, 28 Sep 2012 14:08:46 -0400 Subject: RFC becomes Visio Message-ID: <5065E7AE.7080504@ttec.com> Just got told by a Lightpath person that in order to do BGP on a customer gig circuit to them they would need a visio diagram (of what I dont know). Has anybody else seen this brain damage? Joe From rcarpen at network1.net Fri Sep 28 18:15:50 2012 From: rcarpen at network1.net (Randy Carpenter) Date: Fri, 28 Sep 2012 14:15:50 -0400 (EDT) Subject: RFC becomes Visio In-Reply-To: <5065E7AE.7080504@ttec.com> Message-ID: <1770117331.282854.1348856150216.JavaMail.root@network1.net> I've seen requests for a drawing of some sort, but never specifically and exclusively visio. If they insist on visio, I would send them a LART (at high velocity) instead. -Randy ----- Original Message ----- > Just got told by a Lightpath person that in order to do BGP on a > customer gig circuit to them they would need a visio diagram (of what > I > dont know). > > Has anybody else seen this brain damage? > > Joe > > > From sethm at rollernet.us Fri Sep 28 18:18:33 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 28 Sep 2012 11:18:33 -0700 Subject: RFC becomes Visio In-Reply-To: <5065E7AE.7080504@ttec.com> References: <5065E7AE.7080504@ttec.com> Message-ID: <5065E9F9.9080809@rollernet.us> On 9/28/12 11:08 AM, Joe Maimon wrote: > Just got told by a Lightpath person that in order to do BGP on a > customer gig circuit to them they would need a visio diagram (of what I > dont know). > > Has anybody else seen this brain damage? > Hand draw two squares, label them "our AS" and "your AS" with a line between them labeled "GigE". Bonus points for pencil. ~Seth From mike.lyon at gmail.com Fri Sep 28 18:22:14 2012 From: mike.lyon at gmail.com (Mike Lyon) Date: Fri, 28 Sep 2012 11:22:14 -0700 Subject: RFC becomes Visio In-Reply-To: <5065E9F9.9080809@rollernet.us> References: <5065E7AE.7080504@ttec.com> <5065E9F9.9080809@rollernet.us> Message-ID: And super duper bonus points is you draw pigeons carrying packets between the two blocks and stating that you are RFC 1149 compliant. -Mike On Fri, Sep 28, 2012 at 11:18 AM, Seth Mattinen wrote: > On 9/28/12 11:08 AM, Joe Maimon wrote: > > Just got told by a Lightpath person that in order to do BGP on a > > customer gig circuit to them they would need a visio diagram (of what I > > dont know). > > > > Has anybody else seen this brain damage? > > > > > Hand draw two squares, label them "our AS" and "your AS" with a line > between them labeled "GigE". Bonus points for pencil. > > ~Seth > > -- Mike Lyon 408-621-4826 mike.lyon at gmail.com http://www.linkedin.com/in/mlyon From rhys at rhavenindustrys.com Fri Sep 28 18:23:43 2012 From: rhys at rhavenindustrys.com (Rhys Rhaven) Date: Fri, 28 Sep 2012 13:23:43 -0500 Subject: RFC becomes Visio In-Reply-To: <5065E9F9.9080809@rollernet.us> References: <5065E7AE.7080504@ttec.com> <5065E9F9.9080809@rollernet.us> Message-ID: <5065EB2F.7020603@rhavenindustrys.com> As a person who often draws out + scans diagrams, I support this message. On 09/28/2012 01:18 PM, Seth Mattinen wrote: > Hand draw two squares, label them "our AS" and "your AS" with a line > between them labeled "GigE". Bonus points for pencil. > > ~Seth From mfidelman at meetinghouse.net Fri Sep 28 18:29:22 2012 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Fri, 28 Sep 2012 14:29:22 -0400 Subject: RFC becomes Visio In-Reply-To: <1770117331.282854.1348856150216.JavaMail.root@network1.net> References: <1770117331.282854.1348856150216.JavaMail.root@network1.net> Message-ID: <5065EC82.1000904@meetinghouse.net> Wow... talk about someone who doesn't want your business. Randy Carpenter wrote: > I've seen requests for a drawing of some sort, but never specifically and exclusively visio. > If they insist on visio, I would send them a LART (at high velocity) instead. > > -Randy > > > ----- Original Message ----- >> Just got told by a Lightpath person that in order to do BGP on a >> customer gig circuit to them they would need a visio diagram (of what >> I dont know). >> >> Has anybody else seen this brain damage? >> >> Joe >> >> >> -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From rcarpen at network1.net Fri Sep 28 18:29:50 2012 From: rcarpen at network1.net (Randy Carpenter) Date: Fri, 28 Sep 2012 14:29:50 -0400 (EDT) Subject: RFC becomes Visio In-Reply-To: <5065EB2F.7020603@rhavenindustrys.com> Message-ID: <492796764.282895.1348856990496.JavaMail.root@network1.net> Just make sure to name the scanned file VisioDi~1_vsd.png, and maybe they won't notice. -Randy ----- Original Message ----- > As a person who often draws out + scans diagrams, I support this > message. > > On 09/28/2012 01:18 PM, Seth Mattinen wrote: > > Hand draw two squares, label them "our AS" and "your AS" with a > > line > > between them labeled "GigE". Bonus points for pencil. > > > > ~Seth > > > > From trejrco at gmail.com Fri Sep 28 18:31:22 2012 From: trejrco at gmail.com (TJ) Date: Fri, 28 Sep 2012 14:31:22 -0400 Subject: RFC becomes Visio In-Reply-To: <5065EB2F.7020603@rhavenindustrys.com> References: <5065E7AE.7080504@ttec.com> <5065E9F9.9080809@rollernet.us> <5065EB2F.7020603@rhavenindustrys.com> Message-ID: > > As a person who often draws out + scans diagrams, I support this message. > > > Hand draw two squares, label them "our AS" and "your AS" with a line > > between them labeled "GigE". Bonus points for pencil. > Exactly - hand draw it, scan it it in and save the .JPG/.PNG in a .VSD. There, it is "in Visio". It is Friday, yes? /TJ From nick at foobar.org Fri Sep 28 18:31:42 2012 From: nick at foobar.org (Nick Hilliard) Date: Fri, 28 Sep 2012 19:31:42 +0100 Subject: RFC becomes Visio In-Reply-To: <5065E7AE.7080504@ttec.com> References: <5065E7AE.7080504@ttec.com> Message-ID: <5065ED0E.90701@foobar.org> On 28/09/2012 19:08, Joe Maimon wrote: > Just got told by a Lightpath person that in order to do BGP on a customer > gig circuit to them they would need a visio diagram (of what I dont know). > > Has anybody else seen this brain damage? I was once asked by a vendor support department for a network diagram for a case which involved a standalone switch. I almost sent them a picture of a switch, but decided not as it might have confused the person handling the case. Here's a visio diagram you can send them: http://www.foobar.org/~nick/bgp-network-diagram.vsd Nick From ghira at mistral.co.uk Fri Sep 28 18:46:04 2012 From: ghira at mistral.co.uk (Adam Atkinson) Date: Fri, 28 Sep 2012 19:46:04 +0100 Subject: need help about 40G In-Reply-To: References: Message-ID: <5065F06C.8050508@mistral.co.uk> Deric Kwok wrote: > Hi all > > Do you have experience in 40G equipments > > eg: switch and NIC? I have never used 40 gig but this: http://www.extremenetworks.com/products/blackdiamond-x.aspx appears to have 192 ports of it. I have never seen or used this product so am not recommending it or attempting to sell it to you. I have not seen Extreme mentioned in other replies so far, is all. It may or may not have advantages over other products mentioned so far. I have no idea since I've never seen or used any 40gig product. From cscora at apnic.net Fri Sep 28 18:51:47 2012 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 29 Sep 2012 04:51:47 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201209281851.q8SIpl5c004088@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, TRNOG, 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 29 Sep, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 427331 Prefixes after maximum aggregation: 178718 Deaggregation factor: 2.39 Unique aggregates announced to Internet: 209290 Total ASes present in the Internet Routing Table: 42215 Prefixes per ASN: 10.12 Origin-only ASes present in the Internet Routing Table: 33672 Origin ASes announcing only one prefix: 15754 Transit ASes present in the Internet Routing Table: 5612 Transit-only ASes present in the Internet Routing Table: 141 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 35 Max AS path prepend of ASN ( 48687) 24 Prefixes from unregistered ASNs in the Routing Table: 769 Unregistered ASNs in the Routing Table: 279 Number of 32-bit ASNs allocated by the RIRs: 3336 Number of 32-bit ASNs visible in the Routing Table: 2931 Prefixes from 32-bit ASNs in the Routing Table: 7916 Special use prefixes present in the Routing Table: 12 Prefixes being announced from unallocated address space: 164 Number of addresses announced to Internet: 2601743212 Equivalent to 155 /8s, 19 /16s and 115 /24s Percentage of available address space announced: 70.3 Percentage of allocated address space announced: 70.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 93.7 Total number of prefixes smaller than registry allocations: 150222 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 102740 Total APNIC prefixes after maximum aggregation: 32571 APNIC Deaggregation factor: 3.15 Prefixes being announced from the APNIC address blocks: 103414 Unique aggregates announced from the APNIC address blocks: 42743 APNIC Region origin ASes present in the Internet Routing Table: 4766 APNIC Prefixes per ASN: 21.70 APNIC Region origin ASes announcing only one prefix: 1237 APNIC Region transit ASes present in the Internet Routing Table: 773 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 315 Number of APNIC addresses announced to Internet: 708388512 Equivalent to 42 /8s, 57 /16s and 38 /24s Percentage of available APNIC address space announced: 82.8 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 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, 150/8, 153/8, 163/8, 171/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: 154519 Total ARIN prefixes after maximum aggregation: 78181 ARIN Deaggregation factor: 1.98 Prefixes being announced from the ARIN address blocks: 155430 Unique aggregates announced from the ARIN address blocks: 69144 ARIN Region origin ASes present in the Internet Routing Table: 15250 ARIN Prefixes per ASN: 10.19 ARIN Region origin ASes announcing only one prefix: 5766 ARIN Region transit ASes present in the Internet Routing Table: 1586 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 17 Number of ARIN addresses announced to Internet: 1087029632 Equivalent to 64 /8s, 202 /16s and 193 /24s Percentage of available ARIN address space announced: 57.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, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/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: 108275 Total RIPE prefixes after maximum aggregation: 57184 RIPE Deaggregation factor: 1.89 Prefixes being announced from the RIPE address blocks: 110843 Unique aggregates announced from the RIPE address blocks: 71392 RIPE Region origin ASes present in the Internet Routing Table: 16872 RIPE Prefixes per ASN: 6.57 RIPE Region origin ASes announcing only one prefix: 8127 RIPE Region transit ASes present in the Internet Routing Table: 2714 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 35 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1906 Number of RIPE addresses announced to Internet: 647248932 Equivalent to 38 /8s, 148 /16s and 60 /24s Percentage of available RIPE address space announced: 94.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 59392-61439, 196608-199679 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, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 43973 Total LACNIC prefixes after maximum aggregation: 8501 LACNIC Deaggregation factor: 5.17 Prefixes being announced from the LACNIC address blocks: 47221 Unique aggregates announced from the LACNIC address blocks: 22344 LACNIC Region origin ASes present in the Internet Routing Table: 1660 LACNIC Prefixes per ASN: 28.45 LACNIC Region origin ASes announcing only one prefix: 450 LACNIC Region transit ASes present in the Internet Routing Table: 321 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 687 Number of LACNIC addresses announced to Internet: 116918824 Equivalent to 6 /8s, 248 /16s and 10 /24s Percentage of available LACNIC address space announced: 69.7 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, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 9784 Total AfriNIC prefixes after maximum aggregation: 2224 AfriNIC Deaggregation factor: 4.40 Prefixes being announced from the AfriNIC address blocks: 10259 Unique aggregates announced from the AfriNIC address blocks: 3532 AfriNIC Region origin ASes present in the Internet Routing Table: 562 AfriNIC Prefixes per ASN: 18.25 AfriNIC Region origin ASes announcing only one prefix: 174 AfriNIC Region transit ASes present in the Internet Routing Table: 128 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 41850880 Equivalent to 2 /8s, 126 /16s and 152 /24s Percentage of available AfriNIC address space announced: 41.6 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2979 11428 904 Korea Telecom (KIX) 17974 2356 702 54 PT TELEKOMUNIKASI INDONESIA 7545 1762 301 87 TPG Internet Pty Ltd 4755 1624 387 163 TATA Communications formerly 9829 1332 1106 41 BSNL National Internet Backbo 9583 1181 88 515 Sify Limited 4808 1124 2046 319 CNCGROUP IP network: China169 7552 1108 1062 11 Vietel Corporation 24560 1039 386 160 Bharti Airtel Ltd., Telemedia 18101 1016 135 169 Reliance Infocom Ltd Internet 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 3291 3730 177 bellsouth.net, inc. 7029 3164 990 161 Windstream Communications Inc 18566 2084 382 180 Covad Communications 1785 1918 678 128 PaeTec Communications, Inc. 22773 1888 2931 128 Cox Communications, Inc. 20115 1656 1581 617 Charter Communications 4323 1576 1153 387 Time Warner Telecom 30036 1365 272 751 Mediacom Communications Corp 7018 1262 10320 840 AT&T WorldNet Services 7011 1205 329 699 Citizens Utilities 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 8402 1726 544 16 Corbina telecom 2118 1399 97 14 EUnet/RELCOM Autonomous Syste 12479 846 775 74 Uni2 Autonomous System 34984 782 206 181 BILISIM TELEKOM 6830 724 2313 448 UPC Distribution Services 31148 711 37 9 FreeNet ISP 13188 694 92 153 Educational Network 20940 691 219 531 Akamai Technologies European 58113 631 70 366 LIR DATACENTER TELECOM SRL 8551 575 364 61 Bezeq International 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 2190 376 218 TVCABLE BOGOTA 28573 2141 1251 56 NET Servicos de Comunicao S.A 8151 1594 3045 346 UniNet S.A. de C.V. 7303 1561 1034 199 Telecom Argentina Stet-France 6503 1536 435 68 AVANTEL, S.A. 27947 724 74 91 Telconet S.A 3816 642 309 53 Empresa Nacional de Telecomun 6458 601 81 15 GUATEL 11172 590 85 69 Servicios Alestra S.A de C.V 14420 588 87 102 CORPORACION NACIONAL DE TELEC 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 865 275 36 LINKdotNET AS number 8452 784 958 13 TEDATA 36998 772 48 3 MOBITEL 6713 517 650 19 Itissalat Al-MAGHRIB 24835 269 80 8 RAYA Telecom - Egypt 3741 264 904 224 The Internet Solution 12258 194 28 66 Vodacom Internet Company 15706 192 32 6 Sudatel Internet Exchange Aut 29975 191 667 21 Vodacom 33776 189 12 13 Starcomms Nigeria Limited 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 3291 3730 177 bellsouth.net, inc. 7029 3164 990 161 Windstream Communications Inc 4766 2979 11428 904 Korea Telecom (KIX) 17974 2356 702 54 PT TELEKOMUNIKASI INDONESIA 10620 2190 376 218 TVCABLE BOGOTA 28573 2141 1251 56 NET Servicos de Comunicao S.A 18566 2084 382 180 Covad Communications 1785 1918 678 128 PaeTec Communications, Inc. 22773 1888 2931 128 Cox Communications, Inc. 7545 1762 301 87 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7029 3164 3003 Windstream Communications Inc 17974 2356 2302 PT TELEKOMUNIKASI INDONESIA 28573 2141 2085 NET Servicos de Comunicao S.A 4766 2979 2075 Korea Telecom (KIX) 10620 2190 1972 TVCABLE BOGOTA 18566 2084 1904 Covad Communications 1785 1918 1790 PaeTec Communications, Inc. 22773 1888 1760 Cox Communications, Inc. 8402 1726 1710 Corbina telecom 7545 1762 1675 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 59505 UNALLOCATED 5.2.65.0/24 50673 Serverius AS 59505 UNALLOCATED 5.2.66.0/24 50673 Serverius AS 59414 UNALLOCATED 5.102.144.0/21 15576 Nextra backbone in D 59395 UNALLOCATED 5.133.16.0/21 12658 Dexterity Networks L 59407 UNALLOCATED 5.134.16.0/21 51167 Giga-Hosting GmbH 59521 UNALLOCATED 5.134.192.0/21 29518 Labs2 59441 UNALLOCATED 5.144.128.0/21 50810 Mobin Net Communicat 59581 UNALLOCATED 5.149.8.0/21 25577 C4L main AS 59457 UNALLOCATED 5.149.64.0/24 35567 DASTO semtel d.o.o. 59457 UNALLOCATED 5.149.64.0/19 35567 DASTO semtel d.o.o. Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.24.0/21 41794 Altline LLC 128.0.64.0/22 49466 Declic Telecom SAS 128.0.68.0/22 49466 Declic Telecom SAS 128.0.80.0/20 52041 Timer LTD 128.0.104.0/23 51848 FOP Gabidullina Ludmila Nikol 128.0.128.0/20 29285 AMT closed joint-stock compan 128.0.144.0/22 59675 >>UNKNOWN<< 128.0.160.0/21 23456 32-bit ASN transition 128.0.168.0/21 15772 W-NET Kiev 128.0.170.0/24 24685 ISP Elencom autonomous system Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.0.0/22 45464 Room 201, TGU Bldg 14.192.4.0/22 45464 Room 201, TGU Bldg 14.192.8.0/22 45464 Room 201, TGU Bldg 14.192.12.0/22 45464 Room 201, TGU Bldg 14.192.16.0/22 45464 Room 201, TGU Bldg 14.192.20.0/22 45464 Room 201, TGU Bldg 14.192.24.0/22 45464 Room 201, TGU Bldg 14.192.28.0/22 45464 Room 201, TGU Bldg 27.112.114.0/24 23884 Proimage Engineering and Comm 41.220.80.0/24 38925 DAC AS Germany 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:18 /9:14 /10:29 /11:87 /12:240 /13:477 /14:846 /15:1546 /16:12409 /17:6482 /18:10858 /19:21073 /20:30287 /21:32307 /22:42709 /23:40047 /24:223626 /25:1395 /26:1680 /27:914 /28:179 /29:66 /30:18 /31:0 /32:24 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 2647 3164 Windstream Communications Inc 18566 2034 2084 Covad Communications 6389 1838 3291 bellsouth.net, inc. 8402 1438 1726 Corbina telecom 30036 1299 1365 Mediacom Communications Corp 22773 1229 1888 Cox Communications, Inc. 11492 1164 1201 Cable One 6503 1054 1536 AVANTEL, S.A. 1785 1016 1918 PaeTec Communications, Inc. 7011 944 1205 Citizens Utilities Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:621 2:668 3:1 4:13 5:544 6:3 8:463 12:1985 13:1 14:666 15:11 16:3 17:6 20:27 23:202 24:1786 27:1345 31:1023 32:54 33:2 34:2 36:7 37:821 38:829 39:2 40:133 41:3032 42:159 44:3 46:1602 47:2 49:469 50:594 52:13 54:22 55:9 56:1 57:27 58:990 59:541 60:238 61:1290 62:938 63:1982 64:4271 65:2242 66:4512 67:2090 68:1165 69:3235 70:988 71:509 72:1871 74:2592 75:485 76:314 77:968 78:961 79:495 80:1234 81:970 82:635 83:529 84:516 85:1159 86:491 87:927 88:364 89:1831 90:301 91:5230 92:596 93:1422 94:1638 95:1225 96:417 97:324 98:972 99:39 100:23 101:263 103:1578 105:512 106:118 107:199 108:464 109:1530 110:806 111:970 112:445 113:702 114:609 115:889 116:893 117:732 118:932 119:1214 120:335 121:690 122:1634 123:1165 124:1327 125:1277 128:563 129:190 130:282 131:634 132:309 133:22 134:251 135:61 136:219 137:239 138:337 139:170 140:498 141:279 142:486 143:387 144:488 145:81 146:517 147:264 148:750 149:325 150:154 151:192 152:451 153:178 154:20 155:420 156:224 157:373 158:258 159:659 160:344 161:411 162:363 163:191 164:694 165:423 166:527 167:553 168:966 169:126 170:908 171:167 172:6 173:1681 174:627 175:444 176:789 177:1243 178:1613 180:1340 181:140 182:1058 183:296 184:605 185:6 186:2193 187:1258 188:1697 189:1587 190:6053 192:6029 193:5727 194:4559 195:3478 196:1219 197:225 198:3818 199:5024 200:6023 201:1990 202:8712 203:8719 204:4423 205:2536 206:2755 207:2856 208:4068 209:3659 210:2853 211:1529 212:1988 213:1819 214:892 215:87 216:5118 217:1570 218:569 219:313 220:1251 221:532 222:337 223:403 End of report From Valdis.Kletnieks at vt.edu Fri Sep 28 19:17:13 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 28 Sep 2012 15:17:13 -0400 Subject: RFC becomes Visio In-Reply-To: Your message of "Fri, 28 Sep 2012 14:29:50 -0400." <492796764.282895.1348856990496.JavaMail.root@network1.net> References: <492796764.282895.1348856990496.JavaMail.root@network1.net> Message-ID: <26575.1348859833@turing-police.cc.vt.edu> On Fri, 28 Sep 2012 14:29:50 -0400, Randy Carpenter said: > Just make sure to name the scanned file VisioDi~1_vsd.png, and maybe they won't notice. That's eeevil. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From richard at pedantictheory.com Fri Sep 28 19:20:58 2012 From: richard at pedantictheory.com (Richard Porter) Date: Fri, 28 Sep 2012 12:20:58 -0700 Subject: RFC becomes Visio In-Reply-To: <26575.1348859833@turing-police.cc.vt.edu> References: <492796764.282895.1348856990496.JavaMail.root@network1.net> <26575.1348859833@turing-police.cc.vt.edu> Message-ID: <7A2A4C70-A6AD-44DB-827C-0705298E3089@pedantictheory.com> On Sep 28, 2012, at 12:17 PM, Valdis.Kletnieks at vt.edu wrote: > On Fri, 28 Sep 2012 14:29:50 -0400, Randy Carpenter said: >> Just make sure to name the scanned file VisioDi~1_vsd.png, and maybe they won't notice. > > That's eeevil. ;) echo $Vladis_Statement >> evil_indeed.vsd /r From jim at reptiles.org Fri Sep 28 19:28:51 2012 From: jim at reptiles.org (Jim Mercer) Date: Fri, 28 Sep 2012 15:28:51 -0400 Subject: RFC becomes Visio In-Reply-To: References: <5065E7AE.7080504@ttec.com> <5065E9F9.9080809@rollernet.us> Message-ID: <20120928192851.GA17998@reptiles.org> On Fri, Sep 28, 2012 at 11:22:14AM -0700, Mike Lyon wrote: > On Fri, Sep 28, 2012 at 11:18 AM, Seth Mattinen wrote: > > On 9/28/12 11:08 AM, Joe Maimon wrote: > > > Just got told by a Lightpath person that in order to do BGP on a > > > customer gig circuit to them they would need a visio diagram (of what I > > > dont know). > > > > Hand draw two squares, label them "our AS" and "your AS" with a line > > between them labeled "GigE". Bonus points for pencil. > > And super duper bonus points is you draw pigeons carrying packets between > the two blocks and stating that you are RFC 1149 compliant. on a napkin. -- Jim Mercer Reptilian Research jim at reptiles.org +1 416 410-5633 "He who dies with the most toys is nonetheless dead" From wmaton at ottix.net Fri Sep 28 19:46:57 2012 From: wmaton at ottix.net (William F. Maton Sotomayor) Date: Fri, 28 Sep 2012 15:46:57 -0400 (EDT) Subject: RFC becomes Visio In-Reply-To: <5065E7AE.7080504@ttec.com> References: <5065E7AE.7080504@ttec.com> Message-ID: On Fri, 28 Sep 2012, Joe Maimon wrote: > Just got told by a Lightpath person that in order to do BGP on a customer gig > circuit to them they would need a visio diagram (of what I dont know). > > Has anybody else seen this brain damage? In my quaint little corner of the world, this was once fairly routine actually. It seems to have been more popular amonsgt the enterprise crowd than anything else. > > Joe > wfms From streiner at cluebyfour.org Fri Sep 28 20:02:58 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 28 Sep 2012 16:02:58 -0400 (EDT) Subject: RFC becomes Visio In-Reply-To: <5065E7AE.7080504@ttec.com> References: <5065E7AE.7080504@ttec.com> Message-ID: On Fri, 28 Sep 2012, Joe Maimon wrote: > Just got told by a Lightpath person that in order to do BGP on a customer gig > circuit to them they would need a visio diagram (of what I dont know). > > Has anybody else seen this brain damage? I can understand wanting to diagram a complex design, so everyone involved has a clear picture of what needs to happen, but for an ISP to bring up BGP to a customer? If that's not something that can be done in a relatively cookie-cutter fashion, there is something horribly broken with that ISP. My diagram would be something along the lines of your_router --------[GIG-E WITH BGP]-------- my_router = :) your_router --------[GIG-E WITH NO BGP]-------- my_router = :( jms From gem at rellim.com Fri Sep 28 20:07:46 2012 From: gem at rellim.com (Gary E. Miller) Date: Fri, 28 Sep 2012 13:07:46 -0700 Subject: RFC becomes Visio In-Reply-To: References: <5065E7AE.7080504@ttec.com> Message-ID: <20120928130746.00755dd6.gem@rellim.com> Yo Joe! On Fri, 28 Sep 2012, Joe Maimon wrote: > Just got told by a Lightpath person that in order to do BGP on a > customer gig circuit to them they would need a visio diagram (of > what I dont know). Network diagrams are required for PCI compliance. 1.1.2 Current network diagram with all connections to cardholder data, including any wireless networks A high-level network diagram (either obtained from the entity or created by assessor) of the entity?s networking topography that includes: - Connections into and out of the network - Critical components within the cardholder data environment, including POS devices, systems, databases, and web servers, as applicable - Other necessary payment components, as applicable RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From bmanning at vacation.karoshi.com Fri Sep 28 20:14:07 2012 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 28 Sep 2012 20:14:07 +0000 Subject: RIRs give out unique addresses (Was: something has a /8! ...) In-Reply-To: <45AD64C0-349D-48C4-968A-A18B2EA4E4C4@delong.com> References: <4bd0179a-8e3b-4e1d-b43d-b828bce9117c@mail.pelican.org> <9B9685A4-CD22-41E9-957A-23103D2C8F33@corp.arin.net> <505B23C0.4010102@unfix.org> <2A76E400AC84B845AAC35AA19F8E7A5D0C6FF97D@MUNEXBE1.medline.com> <4B327FA3-A5C3-45EB-888F-742D3A537885@delong.com> <20120928120729.GA17888@vacation.karoshi.com.> <45AD64C0-349D-48C4-968A-A18B2EA4E4C4@delong.com> Message-ID: <20120928201407.GA19450@vacation.karoshi.com.> ah... again the distinction between routed and routable. RFC 1918 space is clearly routeable and routed. one does not need ARIN to assign such space. what i -think- the NRPM section you refered to actually touches on (but does not state outright) the concept of uniqueness. In the dim mists of the past, the NIC (SRI) ran two sets of books, the "connected" database and the "unconnected" database. There was a lack of address block uniquenss between these two databases; e.g. 192.146.13.0/24 was assigned -TWICE-. This occured for hundreds of delegations I was responsible for - I can only assume there were thousands of sites affected (Impacted for the gramatically challanged). This was problematic when "unconnected" sites connected... and is why some of the admonitions in RFC 1918 exist. The section of the ARIN NRPM you quote was developed when there was: a) a shortage of globally unique IPv4 blocks available and b) NAT and RFC 1918 space was easy. Hence the admonishion to use RFC 1918 space if you were "unconnected" and when you decided to "connect", ARIN would be willing to listen to your request. Two thing have changed: a) IPv4 is nearing equalibrium ... Most of it is fielded and so it is not clear ARIN can supply IPv4 on demand as it has in the past. Yes, please tell me the IPv6 story Grandpa, I've -never- heard it before... :( b) Many networks are not "connected" or "unconnected" (begs the question, from what PoV/ASN?) but are transients - with connections being sporadic either in time or by service. What this boils down to is global uniqueness - not routed (by whom) or routability (are the headers legal)... And that (IMHO) is a key attribute of what the RIRs are trying to protect. YMMV of course. /bill On Fri, Sep 28, 2012 at 07:04:43AM -0700, Owen DeLong wrote: > Bill, I am unable to make sense of your reply. > > The question I was answering was: > > "Wouldn't you say that there is a very real expectation that when you request address space through ARIN or RIPE that it would be routable?" (Which I admit at the time I interpreted to also indicate an expectation that it would be routed, but I see now could be ambiguous). > > In that context, I believe that the policy section I quoted indicates that there is no expectation that numbers issued by ARIN or RIPE (or any other RIR) "will be routed" and other policy sections certainly convey that ARIN (and the other RIRs) have no control over routers, so I'm not sure it matters what they say about routability. > > As to your statement about legacy assignments, I fail to see any part of ARIN policy that distinguishes them from any other assignment with regards to the application of policy. However, other than the section quoted below (which essentially states that some level of connectivity is required to justify new resource allocations or assignments), I believe that the NRPM is mute with regards to connectivity on all addresses. Since there are, by definition, no new legacy allocations or assignments, I'm not sure how legacy is relevant to the discussion at hand. > > Owen > > On Sep 28, 2012, at 5:07 AM, bmanning at vacation.karoshi.com wrote: > > > > > not how i read that section Owen... > > > > "...networks require interconnectivity and the private IP address numbers are > > ineffective, globally unique addresses may be requested and used to provide this interconnectivity." > > > > One does not have to request RFC 1918 space from ARIN (or other RIR) > > > > and the NRPM is mute on legacy address assignments wrt "connectivity". > > > > /bill > > > > > > On Thu, Sep 27, 2012 at 07:32:17PM -0700, Owen DeLong wrote: > >> I believe that this section of NRPM says no. > >> > >> 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. > >> > >> Owen > >> > >> On Sep 20, 2012, at 7:56 AM, "Naslund, Steve" wrote: > >> > >>> I suppose that ARIN would say that they do not guarantee routability > >>> because they do not have operational control of Internet routers. > >>> However, Wouldn't you say that there is a very real expectation that > >>> when you request address space through ARIN or RIPE that it would be > >>> routable? I would think that what ARIN and RIPE are really saying is > >>> that they issue unique addresses and you need to get your service > >>> provider to route them. FWIW, the discussion of the military having > >>> addresses pulled back is pretty much a non-starter unless they want to > >>> give them back. When the management of IP address space was moved from > >>> the US DoD, there were memorandums of understanding that the military > >>> controlled their assigned address space and nothing would change that. > >>> I know this for a fact because I was around this discussion in the US > >>> Air Force. > >>> > >>> Steven Naslund > >>> > >>> -----Original Message----- > >>> From: John Curran [mailto:jcurran at arin.net] > >>> Sent: Thursday, September 20, 2012 9:40 AM > >>> To: Jeroen Massar > >>> Cc: NANOG list > >>> Subject: Re: RIRs give out unique addresses (Was: something has a /8! > >>> ...) > >>> > >>> On Sep 20, 2012, at 10:10 AM, Jeroen Massar > >>> wrote: > >>>> On 2012-09-20 16:01 , John Curran wrote: > >>>>> > >>>>> It's very clear in the ARIN region as well. From the ARIN Number > >>>>> Resource Policy Manual (NRPM), > >>>>> - > >>>>> > >>>>> "4.1. General Principles 4.1.1. Routability Provider independent > >>>>> (portable) addresses issued directly from ARIN or other Regional > >>>>> Registries are not guaranteed to be globally routable." > >>>> > >>>> While close, that is not the same. > >>>> > >>>> The RIPE variant solely guarantees uniqueness of the addresses. > >>>> > >>>> The ARIN variant states "we don't guarantee that you can route it > >>>> everywhere", which is on top of the uniqueness portion. > >>> > >>> Agreed - I called it out because ARIN, like RIPE, does not assert that > >>> the address blocks issued are "publicly routable address space" > >>> (i.e. which was Tim Franklin's original statement, but he did not have > >>> on hand the comparable ARIN reference for that point.) > >>> > >>> FYI, > >>> /John > >>> > >>> > >>> > >>> > >> > >> > From streiner at cluebyfour.org Fri Sep 28 20:22:18 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 28 Sep 2012 16:22:18 -0400 (EDT) Subject: RFC becomes Visio In-Reply-To: <20120928130746.00755dd6.gem@rellim.com> References: <5065E7AE.7080504@ttec.com> <20120928130746.00755dd6.gem@rellim.com> Message-ID: On Fri, 28 Sep 2012, Gary E. Miller wrote: >> Just got told by a Lightpath person that in order to do BGP on a >> customer gig circuit to them they would need a visio diagram (of >> what I dont know). > > Network diagrams are required for PCI compliance. I can understand (and fully support) the need for customers to have detailed diagrams of their network for (insert-requirement-here) compliance, but a provider requiring a customer to supply a diagram for basic connectivity? Seems sketchy (no pun indended) to me. jms From jmaimon at ttec.com Fri Sep 28 21:35:02 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Fri, 28 Sep 2012 17:35:02 -0400 Subject: RFC becomes Visio In-Reply-To: References: <5065E7AE.7080504@ttec.com> Message-ID: <50661806.4020602@ttec.com> Justin M. Streiner wrote: > On Fri, 28 Sep 2012, Joe Maimon wrote: > >> Just got told by a Lightpath person that in order to do BGP on a >> customer gig circuit to them they would need a visio diagram (of what >> I dont know). >> >> Has anybody else seen this brain damage? > > I can understand wanting to diagram a complex design, so everyone > involved has a clear picture of what needs to happen, but for an ISP to > bring up BGP to a customer? If that's not something that can be done in > a relatively cookie-cutter fashion, there is something horribly broken > with that ISP. > > My diagram would be something along the lines of > > your_router --------[GIG-E WITH BGP]-------- my_router = :) > > your_router --------[GIG-E WITH NO BGP]-------- my_router = :( > > jms > I figured they are expecting something other than cookie cutter, so I gave them a multi session + multi hop. 4 boxes with labels, 4 lines and some router commands in vendor 'C' language in a text box. If they dont like that, they can provide me with their own diagram. Someone did mention that perhaps its a vetting/hoop-jumping process. My takeaway is that it is always easier to not accept the circuit until BGP is up, rather then saving that for a step 2. Joe From bmah at kitchenlab.org Fri Sep 28 21:50:26 2012 From: bmah at kitchenlab.org (Bruce A. Mah) Date: Fri, 28 Sep 2012 14:50:26 -0700 Subject: RFC becomes Visio In-Reply-To: <5065E9F9.9080809@rollernet.us> References: <5065E7AE.7080504@ttec.com> <5065E9F9.9080809@rollernet.us> Message-ID: <50661BA2.6000202@kitchenlab.org> If memory serves me right, Seth Mattinen wrote: > Hand draw two squares, label them "our AS" and "your AS" with a line > between them labeled "GigE". Bonus points for pencil. Double-bonus for crayon (why yes I do have a young child, why do you ask?). Bruce. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature URL: From jason at thebaughers.com Fri Sep 28 21:58:55 2012 From: jason at thebaughers.com (Jason Baugher) Date: Fri, 28 Sep 2012 16:58:55 -0500 Subject: RFC becomes Visio In-Reply-To: <5065E7AE.7080504@ttec.com> References: <5065E7AE.7080504@ttec.com> Message-ID: <50661D9F.3040008@thebaughers.com> On 9/28/2012 1:08 PM, Joe Maimon wrote: > Just got told by a Lightpath person that in order to do BGP on a > customer gig circuit to them they would need a visio diagram (of what > I dont know). > > Has anybody else seen this brain damage? > > Joe > > > Regardless of all the other comments here making fun of the request, I can somewhat understand why they might do this. Some of the requests I have gotten from customers are so misguided and confusing that a simple diagram can go far to clear things up. I know it seems crazy to everyone here that can set up BGP peering in their sleep, but when you're getting a new request from someone who hasn't gotten an ASN yet, and has never heard of a routing registry? All they know is a consultant told them they needed to "do BGP" with their ISP? Jason From cidr-report at potaroo.net Fri Sep 28 22:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 28 Sep 2012 22:00:00 GMT Subject: The Cidr Report Message-ID: <201209282200.q8SM00Uv021844@wattle.apnic.net> This report has been generated at Fri Sep 28 21:13:05 2012 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 21-09-12 430248 247201 22-09-12 430292 247204 23-09-12 430355 247399 24-09-12 430537 247542 25-09-12 430165 248082 26-09-12 430853 248401 27-09-12 430947 248124 28-09-12 429749 247960 AS Summary 42330 Number of ASes in routing system 17613 Number of ASes announcing only one prefix 3290 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 113770720 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'). --- 28Sep12 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 429943 247849 182094 42.4% All ASes AS6389 3290 180 3110 94.5% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2141 57 2084 97.3% NET Servicos de Comunicao S.A. AS4766 2984 943 2041 68.4% KIXS-AS-KR Korea Telecom AS17974 2356 612 1744 74.0% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS7029 3164 1478 1686 53.3% WINDSTREAM - Windstream Communications Inc AS18566 2084 423 1661 79.7% COVAD - Covad Communications Co. AS22773 1888 285 1603 84.9% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS10620 2190 807 1383 63.2% Telmex Colombia S.A. AS2118 1399 97 1302 93.1% RELCOM-AS OOO "NPO Relcom" AS4323 1580 393 1187 75.1% TWTC - tw telecom holdings, inc. AS7303 1561 449 1112 71.2% Telecom Argentina S.A. AS1785 1921 823 1098 57.2% AS-PAETEC-NET - PaeTec Communications, Inc. AS4755 1624 550 1074 66.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7552 1108 182 926 83.6% VIETEL-AS-AP Vietel Corporation AS8151 1600 730 870 54.4% Uninet S.A. de C.V. AS18101 1016 172 844 83.1% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1124 352 772 68.7% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7545 1762 1023 739 41.9% TPG-INTERNET-AP TPG Internet Pty Ltd AS13977 859 120 739 86.0% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS855 686 52 634 92.4% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS3356 1113 485 628 56.4% LEVEL3 Level 3 Communications AS17676 711 87 624 87.8% GIGAINFRA Softbank BB Corp. AS36998 772 148 624 80.8% SDN-MOBITEL AS22561 1038 434 604 58.2% DIGITAL-TELEPORT - Digital Teleport Inc. AS19262 1002 404 598 59.7% VZGNI-TRANSIT - Verizon Online LLC AS24560 1039 443 596 57.4% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS3549 1026 438 588 57.3% GBLX Global Crossing Ltd. AS4780 852 277 575 67.5% SEEDNET Digital United Inc. AS6458 600 38 562 93.7% Telgua AS4804 653 97 556 85.1% MPX-AS Microplex PTY LTD Total 45143 12579 32564 72.1% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 14.192.0.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.4.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.8.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.12.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.16.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.20.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.24.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.28.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 41.220.80.0/24 AS38925 DAC-AS G.I.T. TELECOM LIMITED 41.220.81.0/24 AS38925 DAC-AS G.I.T. TELECOM LIMITED 41.220.94.0/23 AS42235 IDC-AS Intra Data Communication 41.222.80.0/21 AS37110 moztel-as 41.223.108.0/22 AS36966 EDL_AS Edgenet AS 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.66.32.0/20 AS18864 64.187.208.0/24 AS174 COGENT Cogent/PSI 64.187.209.0/24 AS23005 SWITCH-COMMUNICATIONS - SWITCH Communications Group LLC 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 70.34.112.0/20 AS27589 MOJOHOST - MOJOHOST 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.115.124.0/23 AS46540 74.115.126.0/24 AS11260 EASTLINK-HSI - EastLink 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 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 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 172.120.16.0/21 AS19891 BML-AS Bill Me Later, Inc 192.0.0.0/24 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 198.18.0.0/15 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 198.51.100.0/24 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.6.49.0/24 AS23148 TERREMARK Terremark 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 200.58.248.0/21 AS27849 200.75.184.0/21 AS52390 Administradora de Redes, S.A. 200.75.184.0/24 AS14754 Telgua 200.75.185.0/24 AS14754 Telgua 200.75.186.0/24 AS14754 Telgua 200.75.187.0/24 AS14754 Telgua 200.75.188.0/24 AS14754 Telgua 200.75.189.0/24 AS14754 Telgua 200.75.190.0/24 AS14754 Telgua 200.75.191.0/24 AS14754 Telgua 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 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.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 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.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.0.113.0/24 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 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.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.142.219.0/24 AS45149 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.14.0.0/21 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 204.14.0.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 204.14.2.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 204.14.3.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 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.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.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.93.144.0/21 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 208.93.151.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.21.160.0/20 AS27876 American Data Networks 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.194.160.0/20 AS27876 American Data Networks 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org 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 Sep 28 22:00:01 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 28 Sep 2012 22:00:01 GMT Subject: BGP Update Report Message-ID: <201209282200.q8SM01PP021850@wattle.apnic.net> BGP Update Report Interval: 20-Sep-12 -to- 27-Sep-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS8402 102990 5.0% 62.8 -- CORBINA-AS OJSC "Vimpelcom" 2 - AS1637 29779 1.4% 391.8 -- DNIC-AS-01637 - Headquarters, USAISC 3 - AS9829 26912 1.3% 32.1 -- BSNL-NIB National Internet Backbone 4 - AS11081 26535 1.3% 603.1 -- United Telecommunication Services (UTS) 5 - AS22561 23401 1.1% 172.1 -- DIGITAL-TELEPORT - Digital Teleport Inc. 6 - AS13118 19358 0.9% 403.3 -- ASN-YARTELECOM OJSC Rostelecom 7 - AS24560 18482 0.9% 95.3 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 8 - AS23966 17138 0.8% 49.2 -- LDN-AS-PK LINKdotNET Telecom Limited 9 - AS38547 16790 0.8% 38.6 -- WITRIBE-AS-AP WITRIBE PAKISTAN LIMITED 10 - AS27947 16669 0.8% 22.1 -- Telconet S.A 11 - AS2118 11325 0.6% 8.0 -- RELCOM-AS OOO "NPO Relcom" 12 - AS9583 11278 0.6% 10.9 -- SIFY-AS-IN Sify Limited 13 - AS7029 11245 0.5% 5.7 -- WINDSTREAM - Windstream Communications Inc 14 - AS10620 10971 0.5% 5.2 -- Telmex Colombia S.A. 15 - AS21599 10586 0.5% 135.7 -- NETDIRECT S.A. 16 - AS21299 10526 0.5% 75.2 -- ORBITA-PLUS-AS ORBITA-PLUS Autonomous System 17 - AS7552 10505 0.5% 8.2 -- VIETEL-AS-AP Vietel Corporation 18 - AS20115 10413 0.5% 12.4 -- CHARTER-NET-HKY-NC - Charter Communications 19 - AS2697 10298 0.5% 156.0 -- ERX-ERNET-AS Education and Research Network 20 - AS38264 10017 0.5% 34.1 -- WATEEN-IMS-PK-AS-AP National WiMAX/IMS environment TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS2033 8659 0.4% 8659.0 -- PANIX - Panix Network Information Center 2 - AS6629 8858 0.4% 4429.0 -- NOAA-AS - NOAA 3 - AS17762 7506 0.4% 2502.0 -- HTIL-TTML-IN-AP Tata Teleservices Maharashtra Ltd 4 - AS14680 6719 0.3% 2239.7 -- REALE-6 - Auction.com 5 - AS36411 2168 0.1% 2168.0 -- RAUXA - Rauxa Direct, LLC 6 - AS20406 1606 0.1% 1606.0 -- BRASLINK - Braslink Network Inc 7 - AS44410 4761 0.2% 1587.0 -- ENTEKHAB-AS ENTEKHAB INDUSTRIAL GROUP 8 - AS36529 2275 0.1% 1137.5 -- AXXA-RACKCO - Rackco.com 9 - AS6197 1096 0.1% 1096.0 -- BATI-ATL - BellSouth Network Solutions, Inc 10 - AS19858 2022 0.1% 1011.0 -- GENSLER - Gensler and Associates Architects 11 - AS25600 939 0.1% 939.0 -- MATRIKON-1 - Matrikon Inc. 12 - AS48696 924 0.0% 924.0 -- TEMP-AS TEMP Ltd. 13 - AS39915 5443 0.3% 907.2 -- PREM-AS Premiere Global Services 14 - AS29564 865 0.0% 865.0 -- ASN-ITALDATA Italdata S.p.A 15 - AS38857 1613 0.1% 806.5 -- ESOFT-TRANSIT-AS-AP e.Soft Technologies Ltd. 16 - AS33158 771 0.0% 771.0 -- DATA-SERVICES-INC - Data Services Incorporated 17 - AS29126 725 0.0% 725.0 -- DATIQ-AS Datiq B.V. 18 - AS44240 642 0.0% 642.0 -- ALGORYTHM-AS Algoritm LLC 19 - AS26407 3698 0.2% 616.3 -- GUILFORD-COMMUNICATIONS - Guilford Communications, Inc. 20 - AS11081 26535 1.3% 603.1 -- United Telecommunication Services (UTS) TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/19 19140 0.9% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 184.159.130.0/23 11557 0.5% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. 3 - 184.157.224.0/19 10598 0.5% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. 4 - 200.46.0.0/19 10392 0.5% AS21599 -- NETDIRECT S.A. 5 - 209.48.168.0/24 8659 0.4% AS2033 -- PANIX - Panix Network Information Center 6 - 190.60.31.0/24 7612 0.3% AS18747 -- IFX-NW - IFX Communication Ventures, Inc. 7 - 202.41.70.0/24 7236 0.3% AS2697 -- ERX-ERNET-AS Education and Research Network 8 - 182.64.0.0/16 6864 0.3% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 9 - 122.161.0.0/16 6449 0.3% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 10 - 12.139.133.0/24 5409 0.2% AS14680 -- REALE-6 - Auction.com 11 - 95.128.195.0/24 5397 0.2% AS39915 -- PREM-AS Premiere Global Services 12 - 194.63.9.0/24 4901 0.2% AS1273 -- CW Cable and Wireless Worldwide plc 13 - 192.58.2.0/24 4452 0.2% AS6629 -- NOAA-AS - NOAA 14 - 192.58.232.0/24 4406 0.2% AS6629 -- NOAA-AS - NOAA 15 - 49.248.72.0/21 4352 0.2% AS17762 -- HTIL-TTML-IN-AP Tata Teleservices Maharashtra Ltd 16 - 69.38.178.0/24 4132 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 17 - 77.235.147.0/24 4093 0.2% AS16130 -- FiberLink Networks 18 - 190.4.128.0/20 3887 0.2% AS11081 -- United Telecommunication Services (UTS) 19 - 202.56.215.0/24 3875 0.2% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 20 - 190.88.192.0/20 3754 0.2% AS11081 -- United Telecommunication Services (UTS) Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From mfidelman at meetinghouse.net Fri Sep 28 22:09:18 2012 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Fri, 28 Sep 2012 18:09:18 -0400 Subject: RFC becomes Visio In-Reply-To: <50661D9F.3040008@thebaughers.com> References: <5065E7AE.7080504@ttec.com> <50661D9F.3040008@thebaughers.com> Message-ID: <5066200E.4090207@meetinghouse.net> Jason Baugher wrote: > On 9/28/2012 1:08 PM, Joe Maimon wrote: >> Just got told by a Lightpath person that in order to do BGP on a >> customer gig circuit to them they would need a visio diagram (of what >> I dont know). >> >> Has anybody else seen this brain damage? > Regardless of all the other comments here making fun of the request, I > can somewhat understand why they might do this. Some of the requests I > have gotten from customers are so misguided and confusing that a > simple diagram can go far to clear things up. I know it seems crazy to > everyone here that can set up BGP peering in their sleep, but when > you're getting a new request from someone who hasn't gotten an ASN > yet, and has never heard of a routing registry? All they know is a > consultant told them they needed to "do BGP" with their ISP? Isn't it a role of sales engineering/support to help customers through this process? I know that, if a vendor told me that I had to jump through hoops to do business with them, I'd be complaining to my sales rep., and looking for another vendor. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From chuckchurch at gmail.com Sat Sep 29 02:26:35 2012 From: chuckchurch at gmail.com (Chuck Church) Date: Fri, 28 Sep 2012 22:26:35 -0400 Subject: RFC becomes Visio In-Reply-To: <50661D9F.3040008@thebaughers.com> References: <5065E7AE.7080504@ttec.com> <50661D9F.3040008@thebaughers.com> Message-ID: <00cf01cd9de9$dc2b79f0$94826dd0$@gmail.com> I agree. Perhaps the ISP goes a little above and beyond most, and will provide configuration assistance to the downstream if they have issues. Useful info they might want to see on the diagram could be your AS (duh), ASes downstream from you, are you multihomed, and with who, what prefixes and or communities would you want? Sure this info can be put in a text form, but a diagram can help the ISP understand what the customer is wanting to do, and can get a clue-level about the customer from such documentation. Chuck -----Original Message----- From: Jason Baugher [mailto:jason at thebaughers.com] Sent: Friday, September 28, 2012 5:59 PM To: nanog at nanog.org Subject: Re: RFC becomes Visio On 9/28/2012 1:08 PM, Joe Maimon wrote: > Just got told by a Lightpath person that in order to do BGP on a > customer gig circuit to them they would need a visio diagram (of what > I dont know). > > Has anybody else seen this brain damage? > > Joe > > > Regardless of all the other comments here making fun of the request, I can somewhat understand why they might do this. Some of the requests I have gotten from customers are so misguided and confusing that a simple diagram can go far to clear things up. I know it seems crazy to everyone here that can set up BGP peering in their sleep, but when you're getting a new request from someone who hasn't gotten an ASN yet, and has never heard of a routing registry? All they know is a consultant told them they needed to "do BGP" with their ISP? Jason From bonomi at mail.r-bonomi.com Sat Sep 29 02:41:25 2012 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Fri, 28 Sep 2012 21:41:25 -0500 (CDT) Subject: RFC becomes Visio In-Reply-To: Message-ID: <201209290241.q8T2fPND088353@mail.r-bonomi.com> > Mike Lyon wrote: > On Fri, Sep 28, 2012 at 11:18 AM, Seth Mattinen wrote: > > On 9/28/12 11:08 AM, Joe Maimon wrote: > > > Just got told by a Lightpath person that in order to do BGP on a > > > customer gig circuit to them they would need a visio diagram (of what I > > > dont know). > > > > > > Has anybody else seen this brain damage? > > > > Hand draw two squares, label them "our AS" and "your AS" with a line > > between them labeled "GigE". Bonus points for pencil. > > > > And super duper bonus points is you draw pigeons carrying packets between > the two blocks and stating that you are RFC 1149 compliant. > No, no, *NO*!! The proper approach is to ask the vendor for RFC 1149 trasport for the BGP session, and whether it terminates in a shared cage, or if a fully private one is required. Including an 'envionmental impact statement'. Explaining that this info is required in order to produce an accurate Visio diagram. From james.cutler at consultant.com Sat Sep 29 03:15:14 2012 From: james.cutler at consultant.com (Cutler James R) Date: Fri, 28 Sep 2012 23:15:14 -0400 Subject: RFC becomes Visio In-Reply-To: <201209290241.q8T2fPND088353@mail.r-bonomi.com> References: <201209290241.q8T2fPND088353@mail.r-bonomi.com> Message-ID: On Sep 28, 2012, at 10:41 PM, Robert Bonomi wrote: > > > The proper approach is to ask the vendor for RFC 1149 trasport for the BGP > session, and whether it terminates in a shared cage, or if a fully private > one is required. Including an 'envionmental impact statement'. Explaining > that this info is required in order to produce an accurate Visio diagram. > Ladies and gentlemen, it seems that we have a winner! From tomb at byrneit.net Sat Sep 29 05:27:34 2012 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Fri, 28 Sep 2012 22:27:34 -0700 Subject: IPv6 Ignorance In-Reply-To: References: <20120917233210.61755.qmail@joyce.lan> Message-ID: <72F9A69DCF990443B2CEC064E605CE064A8252@Pascal.zaphodb.org> You won't have enough addresses for Dark Matter, Neutrinos, etc. Atoms wind up using up about 63 bits (2^10^82) based on the current SWAG. The missing mass is 84% of the universe. > -----Original Message----- > From: Randy Bush [mailto:randy at psg.com] > Sent: Monday, September 17, 2012 8:30 PM > To: John Levine > Cc: nanog at nanog.org > Subject: Re: IPv6 Ignorance > > > In technology, not much. But I'd be pretty surprised if the laws of > > arithmetic were to change, or if we were to find it useful to assign > > IP addresses to objects smaller than a single atom. > > we assign them /64s From johnl at iecc.com Sat Sep 29 05:31:15 2012 From: johnl at iecc.com (John R. Levine) Date: 29 Sep 2012 01:31:15 -0400 Subject: IPv6 Ignorance In-Reply-To: <72F9A69DCF990443B2CEC064E605CE064A8252@Pascal.zaphodb.org> References: <20120917233210.61755.qmail@joyce.lan> <72F9A69DCF990443B2CEC064E605CE064A8252@Pascal.zaphodb.org> Message-ID: > You won't have enough addresses for Dark Matter, Neutrinos, etc. Atoms > wind up using up about 63 bits (2^10^82) based on the current SWAG. The > missing mass is 84% of the universe. Fortunately, until we find it, it doesn't need addresses. > >> -----Original Message----- >> From: Randy Bush [mailto:randy at psg.com] >> Sent: Monday, September 17, 2012 8:30 PM >> To: John Levine >> Cc: nanog at nanog.org >> Subject: Re: IPv6 Ignorance >> >>> In technology, not much. But I'd be pretty surprised if the laws of >>> arithmetic were to change, or if we were to find it useful to assign >>> IP addresses to objects smaller than a single atom. >> >> we assign them /64s 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 george.herbert at gmail.com Sat Sep 29 06:17:15 2012 From: george.herbert at gmail.com (George Herbert) Date: Fri, 28 Sep 2012 23:17:15 -0700 Subject: IPv6 Ignorance In-Reply-To: References: <20120917233210.61755.qmail@joyce.lan> <72F9A69DCF990443B2CEC064E605CE064A8252@Pascal.zaphodb.org> Message-ID: My customer the Dark Matter local galaxy group beg to disagree; just because you cannot see them does not mean that you cannot feel them gravitationally. Or route to them. George William Herbert Sent from my iPhone On Sep 28, 2012, at 10:31 PM, "John R. Levine" wrote: >> You won't have enough addresses for Dark Matter, Neutrinos, etc. Atoms >> wind up using up about 63 bits (2^10^82) based on the current SWAG. The >> missing mass is 84% of the universe. > > Fortunately, until we find it, it doesn't need addresses. > >> >>> -----Original Message----- >>> From: Randy Bush [mailto:randy at psg.com] >>> Sent: Monday, September 17, 2012 8:30 PM >>> To: John Levine >>> Cc: nanog at nanog.org >>> Subject: Re: IPv6 Ignorance >>> >>>> In technology, not much. But I'd be pretty surprised if the laws of >>>> arithmetic were to change, or if we were to find it useful to assign >>>> IP addresses to objects smaller than a single atom. >>> >>> we assign them /64s > > 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 leschnik at gmail.com Sat Sep 29 06:53:42 2012 From: leschnik at gmail.com (Jason Leschnik) Date: Sat, 29 Sep 2012 16:53:42 +1000 Subject: IPv6 Ignorance In-Reply-To: References: <20120917233210.61755.qmail@joyce.lan> <72F9A69DCF990443B2CEC064E605CE064A8252@Pascal.zaphodb.org> Message-ID: To address everything in the Universe wouldn't you then get stuck in some kinda of loop of having to address the matter that is used by the addresses... i.e. to address everything in the Universe you need more matter than the Universe? *brain* pop On Sat, Sep 29, 2012 at 4:17 PM, George Herbert wrote: > My customer the Dark Matter local galaxy group beg to disagree; just > because you cannot see them does not mean that you cannot feel them > gravitationally. > > Or route to them. > > > George William Herbert > Sent from my iPhone > > On Sep 28, 2012, at 10:31 PM, "John R. Levine" wrote: > > >> You won't have enough addresses for Dark Matter, Neutrinos, etc. Atoms > >> wind up using up about 63 bits (2^10^82) based on the current SWAG. The > >> missing mass is 84% of the universe. > > > > Fortunately, until we find it, it doesn't need addresses. > > > >> > >>> -----Original Message----- > >>> From: Randy Bush [mailto:randy at psg.com] > >>> Sent: Monday, September 17, 2012 8:30 PM > >>> To: John Levine > >>> Cc: nanog at nanog.org > >>> Subject: Re: IPv6 Ignorance > >>> > >>>> In technology, not much. But I'd be pretty surprised if the laws of > >>>> arithmetic were to change, or if we were to find it useful to assign > >>>> IP addresses to objects smaller than a single atom. > >>> > >>> we assign them /64s > > > > 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 > > > > -- Regards, Jason Leschnik. [m] 0432 35 4224 [w@] jason dot leschnik ansto dot gov dot au [U@] jml974 at uow.edu.au From mohta at necom830.hpcl.titech.ac.jp Sat Sep 29 10:24:55 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 29 Sep 2012 19:24:55 +0900 Subject: /. Terabit Ethernet is Dead, for Now In-Reply-To: <23047F2D-0BD7-4DDB-ADC3-54AE56684BEE@puck.nether.net> References: <20120927125157.GT9750@leitl.org> <23047F2D-0BD7-4DDB-ADC3-54AE56684BEE@puck.nether.net> Message-ID: <5066CC77.1050609@necom830.hpcl.titech.ac.jp> Jared Mauch wrote: > There is also a problem in the 100GbE space where the market > pricing hasn't yet reached an amount whereby the economics > are "close enough" to push people beyond N*10G. The problem is that physical layer of 100GE (with 10*10G) and 10*10GE are identical (if same plug and cable are used both for 100GE and 10*10GE). Both 100GE and 10*10GE use trunking. The difference is whether trunking is done below (100GE) or above (10*10GE) L2 framing. While 100GE has lower HOL delay (though already negligible with 10GE), 10*10GE is more flexible. Still, for 100GE, under some circumstances, 100GE with 4*25G may become less expensive than 10*10GE. But, as it is unlikely that 1TE will be 4*250G or 400GE will be 2*200G, faster Ethernet has little, if any, economical merit. Masataka Ohta From joseph.snyder at gmail.com Fri Sep 28 12:41:56 2012 From: joseph.snyder at gmail.com (joseph.snyder at gmail.com) Date: Fri, 28 Sep 2012 08:41:56 -0400 Subject: guys != gender neutral In-Reply-To: <013501cd9cf7$e495cc50$adc164f0$@hathcock.org> References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> <20120927153408.GA11650@nic.fr> <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> <20120927162055.GA75762@reptiles.org> <2DE28166-3AEB-451D-80E6-FA00331D8D45@delong.com> <013501cd9cf7$e495cc50$adc164f0$@hathcock.org> Message-ID: Intention is everything, words are only part of it. If you can't determine intention and you get upset then it is you that has the problem. Ask or let it go and assume the best intentions. The world be a lot better off if we all did this. Lorell Hathcock wrote: >We may not all be guys. We may not all be gals. But we are definitely >all >CLOWNS. This is a substitution that should be acceptable to all and it >really works. > >Sales-clown. Yep! >Mail-clown. Yep! >Fire-clown. Yep! >Police-clown. Yep! >Congress-clown. Yep! Yep! > >-----Original Message----- >From: Landon Stewart [mailto:lstewart at superb.net] >Sent: Thursday, September 27, 2012 3:56 PM >To: Owen DeLong >Cc: nanog at nanog.org >Subject: Re: guys != gender neutral > >On 27 September 2012 11:34, Owen DeLong wrote: > >> When did "people" stop being an acceptable gender-neutral substitute >> for {guys,gals}? >> >> Owen >> >> >Using the word 'people' is good but I like to say 'humans'. > >What's up humans? >Can I get you humans to drink? > >This rarely offends anyone. > >-- >Landon Stewart >Sr. Administrator >Systems Engineering >Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead >of >the Rest": http://www.superbhosting.net -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From mysidia at gmail.com Sun Sep 30 00:30:37 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 29 Sep 2012 19:30:37 -0500 Subject: guys != gender neutral In-Reply-To: References: <506468FE.15908.A42E19D@mmata.intercom.com.sv> <20120927153408.GA11650@nic.fr> <0D63F120-5BAE-4887-9BBC-88781CC167F1@ianai.net> <20120927162055.GA75762@reptiles.org> <2DE28166-3AEB-451D-80E6-FA00331D8D45@delong.com> <013501cd9cf7$e495cc50$adc164f0$@hathcock.org> Message-ID: On 9/28/12, joseph.snyder at gmail.com wrote: > Intention is everything, words are only part of it. If you can't determine > intention and you get upset then it is you that has the problem. Ask or let > it go and assume the best intentions. The world be a lot better off if we > all did this. Exactly. In protest against all the pedantry, in the selection of "neutral" terms; I suggest making a habit of doing the opposite of what pedants want.... in other words: just ignore the reaching-out-on-a-limb-and-trying-to-dictate-what-the-sky-means arguments about if-word-x-is-really-neutral. Use the neutral terms we are already familiar with, that are understood, convenient, and "natural"; If you think "Guys" is neutral, for cases where the distinction between gender isn't important, then that's how it is; it's not something that can be dictated otherwise by anyone other than the speaker. The understood part is most important, especially on mailing lists. And lo.... the OP has opened up a can of worms here on NANOG, which are crawling around, all over the place and setting up nests, creating infestations. Please kindly get every single one of the worms released, packed up immediately, reseal the can-o-worms, and ship them back to their natural habitat in the US, Washington DC, before Monday, so we can have fewer distractions from legit operational matters. Thanks, -- -JH From kmedcalf at dessus.com Sun Sep 30 03:59:02 2012 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sat, 29 Sep 2012 21:59:02 -0600 Subject: guys != gender neutral In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8B017E12@ocsbs.ocosa.com> Message-ID: <6cc996cbe4aaa340951963ad1d3012f3@mail.dessus.com> Ugly bags of mostly water? --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org > -----Original Message----- > From: Otis L. Surratt, Jr. [mailto:otis at ocosa.com] > Sent: Friday, 28 September, 2012 05:33 > To: nanog at nanog.org > Subject: RE: guys != gender neutral > > Maybe the OP for "really nasty attacks" in hindsight wishes "NANOGers" was > used instead to address the list. :) > > Having "all walks of life" essentially all around, it really makes one > careful to truly think before speaking. Sometimes we miss this with > everything we have going on, but no one is perfect. > > The bottomline is, no one can really sastifisfy any indivdual and their > preference of how they would liked to be addressed. If one is to be offended > or looks for offense they will capitalize on it period. I try much as > possible to avoid those situations. > > When we refer to our clients in a mass communication we either utilize our > tools to auto fix their name to the letter or we address them as "OCOSA > Family" or "All" or "Clients". We are a very family-oriented business and > are "down to Earth." We'd like to believe our clients are apart of our family > and some may take offense but you might or never would know unless an > opportunity presented itself. > > Personally, I practice using the person's name, I am in communication > with...not "buddy", "bud", "pal", "man", "guys", "gal" "y'all" and etc. When > addressing mixed gender groups, I simply speak or address as "all". Thus, no > mistakes. > > When addressing both genders you have to be extremely careful. Ultimately, It > depends on the audience and treating all with respect seems to work for me. > > For example: You could address a group a men and call them "boys". Well, that > might offend some, especially if they are older than you. > For example: You could address a group of young adults and call them "kids". > Well, that might offend some. > > As Owen mentioned saying "human" seems okay and true but then again, because > it's not the norm it raises some question. (Internal thinking process, "Oh > I'm a HUMAN!!!!, well I that is true" then your temperature gets back to > normal) :) > > In general, this is life and I simply have fun and enjoy it because it's too > short. > > > Otis From aaron.glenn at gmail.com Sun Sep 30 06:57:54 2012 From: aaron.glenn at gmail.com (Aaron Glenn) Date: Sun, 30 Sep 2012 10:57:54 +0400 Subject: Angled Polish Connectors and DWDM Message-ID: dear peoples of NANOG, I've always held the -- possibly completely false -- notion that angled connectors (APC) were not idea for fiber spans carrying multiple dense/DWDM wavelengths. However, after copious amounts of googling and duckduckgo'ing I cannot find an opinion or tech note one way or the other. Are there situations when angled connectors are not to be used? Are they 'safe' or even recommended for any kind of DWDM application? I know they're not meant for mating directly with optics, but for panels, x-conns, and distribution frames...? I have this sinking feeling I've been misunderstanding angled connectors all these years. cluebats are appreciated. please be gentle. thanks, aaron From igor at ergens.org Sun Sep 30 07:52:08 2012 From: igor at ergens.org (Igor Ybema) Date: Sun, 30 Sep 2012 09:52:08 +0200 Subject: Angled Polish Connectors and DWDM In-Reply-To: References: Message-ID: Hi Aaron, > Are there situations when angled connectors are not > to be used? Are they 'safe' or even recommended for any kind of DWDM > application? To my knowledge APC is always better than PC connectors. APC are used to eliminate back reflections. Due to the angled connector reflections are sent mostly towards the cladding and not the core and therefore. The effecs of back reflections are great. Read this http://documents.exfo.com/appnotes/anote044-ang.pdf I can not see why APC connectors are not to be used, even with DWDM. The only problem with APC is that there are different kinds of angles (8 degrees and 9 degrees) and polishments of the tip. When using the wrong connectors (for example a 8 degrees against a 9 degrees in a coupler) you will introduce more loss. This would be the reasons why some people fear to use APC. regards, Igor From swmike at swm.pp.se Sun Sep 30 09:59:17 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 30 Sep 2012 11:59:17 +0200 (CEST) Subject: Angled Polish Connectors and DWDM In-Reply-To: References: Message-ID: On Sun, 30 Sep 2012, Igor Ybema wrote: > To my knowledge APC is always better than PC connectors. APC are used to > eliminate back reflections. Due to the angled connector reflections are > sent mostly towards the cladding and not the core and therefore. I've been told this is very important in HFC solutions (hybrid fibre coax). Operationally though, having APC is a hassle. I know of companies who mandated APC for a few years for all installations, but then reverted back to UPC due to operational problems (people putting UPC cables into APC ODFs etc). So while APC might be technically superior when properly installed, it's not always better when looking at the whole "system". -- Mikael Abrahamsson email: swmike at swm.pp.se From aaron.glenn at gmail.com Sun Sep 30 10:14:45 2012 From: aaron.glenn at gmail.com (Aaron Glenn) Date: Sun, 30 Sep 2012 14:14:45 +0400 Subject: Angled Polish Connectors and DWDM In-Reply-To: References: Message-ID: On Sun, Sep 30, 2012 at 11:52 AM, Igor Ybema wrote: > Hi Aaron, > >> Are there situations when angled connectors are not >> to be used? Are they 'safe' or even recommended for any kind of DWDM >> application? > > To my knowledge APC is always better than PC connectors. APC are used > to eliminate back reflections. Due to the angled connector reflections > are sent mostly towards the cladding and not the core and therefore. Indeed. I have always held the idea that APC connectors induced greater chromatic and/or polarization mode dispersion -- yet can't find any resources that claim so, nor does that fit in with my working mental model of how light propagates. Just something I picked up during the hellish days of trying to deploy 10GbE before it was cool; now I'd like to know if it is grounded in any science (-: Thanks aaron From ebais at a2b-internet.com Sun Sep 30 13:48:12 2012 From: ebais at a2b-internet.com (Erik Bais) Date: Sun, 30 Sep 2012 15:48:12 +0200 Subject: need help about 40G In-Reply-To: References: Message-ID: <000601cd9f12$3ea87eb0$bbf97c10$@a2b-internet.com> Hi Deric, On the part of 40G, there is a clear financial benefit instead of moving currently towards 100G. If you don't need 100G yet, there is a lot of money to be saved by skipping first generation 100G. 40G ports will only set you back around 1500 US$ per port. Optics are also quite cheap and because of that, it is a nice solution. As already mentioned by Adam in his reply. Extreme Networks has a device (the BD X8) that can fit 192 - 40G ports in 14.5U (or 1/3) rack space. These can also be used as 768 10G ports, if you split the 40G into 4*10G. Which you can by just putting other cabling to the optic. If you don't require such a large quantity of ports, there are also smaller (1U switches) with have 4*40G option boards, like the X670V from Extreme. These boxes are not expensive, stable and provide a great price to port density ratio. Also something which is very interesting, these boxes have both a very low latency, which makes them ideal for storage, cloud and trading scenarios. There are some tests reports you can find online if you are not only looking for 40G but specifically in combination with very low latency. I personally haven't used the Mellanox 40G nics yet, but I have been told that these have been tested by other customers and work like a charm with the Extreme kit. If you have more specific questions, please let me know (can also off-list). Regards, Erik Bais From ml at kenweb.org Sun Sep 30 15:08:58 2012 From: ml at kenweb.org (ML) Date: Sun, 30 Sep 2012 11:08:58 -0400 Subject: Angled Polish Connectors and DWDM In-Reply-To: References: Message-ID: <5068608A.70606@kenweb.org> On 9/30/2012 6:14 AM, Aaron Glenn wrote: > sent mostly towards the cladding and not the core and therefore. > Indeed. I have always held the idea that APC connectors induced > greater chromatic and/or polarization mode dispersion -- yet can't > find any resources that claim so, nor does that fit in with my working > mental model of how light propagates. Just something I picked up > during the hellish days of trying to deploy 10GbE before it was cool; > now I'd like to know if it is grounded in any science (-: > > Thanks > aaron > Just tossing this in here. I don't claim to know either way. On the current project I'm working on all of the panels are LC-APC. This seems to have not been a problem for our DWDM vendor, who we have been working very closely with, and I assume know about our use of APC. So far our PMD testing has come back clear. From adrian at olddog.co.uk Sun Sep 30 16:23:50 2012 From: adrian at olddog.co.uk (Adrian Farrel) Date: Sun, 30 Sep 2012 17:23:50 +0100 Subject: IETF's PIM Working Group conducting deployment survey Message-ID: <0a8801cd9f27$fa943410$efbc9c30$@olddog.co.uk> Hi, After a snafu, the PIM working group has restarted its survey into PIM sparse mode deployments. Please see the email at http://www.ietf.org/mail-archive/web/pim/current/msg02479.html for more information. responses will be anonymised. Many thanks to all operators who are able to respond. Adrian From swmike at swm.pp.se Sun Sep 30 16:46:08 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 30 Sep 2012 18:46:08 +0200 (CEST) Subject: Angled Polish Connectors and DWDM In-Reply-To: <5068608A.70606@kenweb.org> References: <5068608A.70606@kenweb.org> Message-ID: On Sun, 30 Sep 2012, ML wrote: > So far our PMD testing has come back clear. How have you done the PMD testing? For verifying PMD and CD through an actual wavelength (not per-fiber, but through all the ADMs etc), I haven't really been able to find a good solution. Suggestions welcome. -- Mikael Abrahamsson email: swmike at swm.pp.se From ml at kenweb.org Sun Sep 30 17:15:44 2012 From: ml at kenweb.org (ML) Date: Sun, 30 Sep 2012 13:15:44 -0400 Subject: Angled Polish Connectors and DWDM In-Reply-To: References: <5068608A.70606@kenweb.org> Message-ID: <50687E40.4070604@kenweb.org> On 9/30/2012 12:46 PM, Mikael Abrahamsson wrote: > On Sun, 30 Sep 2012, ML wrote: > >> So far our PMD testing has come back clear. > > How have you done the PMD testing? > > For verifying PMD and CD through an actual wavelength (not per-fiber, > but through all the ADMs etc), I haven't really been able to find a > good solution. Suggestions welcome. > All tests done per span on dark fiber. CDs via a Nettest FD440: 1520nm to 1640nm PMD via a PerkinElmer* device: Just at 1550nm. -ML Couldn't find a model number in the test results. Just a reference to PerkinElmer. From mysidia at gmail.com Sun Sep 30 19:05:15 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 30 Sep 2012 14:05:15 -0500 Subject: /. Terabit Ethernet is Dead, for Now In-Reply-To: <5066CC77.1050609@necom830.hpcl.titech.ac.jp> References: <20120927125157.GT9750@leitl.org> <23047F2D-0BD7-4DDB-ADC3-54AE56684BEE@puck.nether.net> <5066CC77.1050609@necom830.hpcl.titech.ac.jp> Message-ID: On 9/29/12, Masataka Ohta wrote: > Jared Mauch wrote: ... > The problem is that physical layer of 100GE (with 10*10G) and > 10*10GE are identical (if same plug and cable are used both for > 100GE and 10*10GE). Interesting. Well, I would say if there are no technical improvements that will significantly improve performance over the best possible carrier Ethernet bonding implementation and no cost savings at the physical layer over picking the higher data rate physical layer standard, _after_ considering the increased hardware costs due to newly manufactured components for a standard that is just newer. E.g. If no fewer transceivers and fewer strands of fiber required, or shorter wavelength required, so it doesn't enable you to achieve greater throughput over the same amount of light spectrum on your cabling, and therefore lower cost at sufficient density, then: in that case, there will probably be fairly little point in having the higher rate standard exist in the first place, as long as the bonding mechanisms available are good for the previous standard. Just keep bonding together more and more data links at basic units of 10GE, until the required throughput capacity has been achieved. It's not as if a newer 1 Tbit standard, will make the bits you send get read at the other end faster than the speed of light. Newer standard does not necessarily mean more reliable, technically better, or more efficient, so it is prudent to consider what is actually achieved that would benefit networks considered to be potential candidates for implementation of the new standard, before actually making it a standard... -- -JH From owen at delong.com Sun Sep 30 21:47:12 2012 From: owen at delong.com (Owen DeLong) Date: Sun, 30 Sep 2012 14:47:12 -0700 Subject: guys != gender neutral In-Reply-To: <6cc996cbe4aaa340951963ad1d3012f3@mail.dessus.com> References: <6cc996cbe4aaa340951963ad1d3012f3@mail.dessus.com> Message-ID: Ugly would usually be considered pejorative. Owen On Sep 29, 2012, at 20:59 , Keith Medcalf wrote: > > Ugly bags of mostly water? > > > --- > () ascii ribbon campaign against html e-mail > /\ www.asciiribbon.org > > >> -----Original Message----- >> From: Otis L. Surratt, Jr. [mailto:otis at ocosa.com] >> Sent: Friday, 28 September, 2012 05:33 >> To: nanog at nanog.org >> Subject: RE: guys != gender neutral >> >> Maybe the OP for "really nasty attacks" in hindsight wishes "NANOGers" was >> used instead to address the list. :) >> >> Having "all walks of life" essentially all around, it really makes one >> careful to truly think before speaking. Sometimes we miss this with >> everything we have going on, but no one is perfect. >> >> The bottomline is, no one can really sastifisfy any indivdual and their >> preference of how they would liked to be addressed. If one is to be offended >> or looks for offense they will capitalize on it period. I try much as >> possible to avoid those situations. >> >> When we refer to our clients in a mass communication we either utilize our >> tools to auto fix their name to the letter or we address them as "OCOSA >> Family" or "All" or "Clients". We are a very family-oriented business and >> are "down to Earth." We'd like to believe our clients are apart of our family >> and some may take offense but you might or never would know unless an >> opportunity presented itself. >> >> Personally, I practice using the person's name, I am in communication >> with...not "buddy", "bud", "pal", "man", "guys", "gal" "y'all" and etc. When >> addressing mixed gender groups, I simply speak or address as "all". Thus, no >> mistakes. >> >> When addressing both genders you have to be extremely careful. Ultimately, It >> depends on the audience and treating all with respect seems to work for me. >> >> For example: You could address a group a men and call them "boys". Well, that >> might offend some, especially if they are older than you. >> For example: You could address a group of young adults and call them "kids". >> Well, that might offend some. >> >> As Owen mentioned saying "human" seems okay and true but then again, because >> it's not the norm it raises some question. (Internal thinking process, "Oh >> I'm a HUMAN!!!!, well I that is true" then your temperature gets back to >> normal) :) >> >> In general, this is life and I simply have fun and enjoy it because it's too >> short. >> >> >> Otis > > > > From joelja at bogus.com Sun Sep 30 21:58:21 2012 From: joelja at bogus.com (joel jaeggli) Date: Sun, 30 Sep 2012 14:58:21 -0700 Subject: /. Terabit Ethernet is Dead, for Now In-Reply-To: References: <20120927125157.GT9750@leitl.org> <23047F2D-0BD7-4DDB-ADC3-54AE56684BEE@puck.nether.net> <5066CC77.1050609@necom830.hpcl.titech.ac.jp> Message-ID: <5068C07D.2060203@bogus.com> On 9/30/12 12:05 PM, Jimmy Hess wrote: > On 9/29/12, Masataka Ohta wrote: >> Jared Mauch wrote: > ... >> The problem is that physical layer of 100GE (with 10*10G) and >> 10*10GE are identical (if same plug and cable are used both for >> 100GE and 10*10GE). > Interesting. Well, I would say if there are no technical > improvements that will significantly improve performance over the best > possible carrier Ethernet bonding implementation and no cost savings > at the physical layer over picking the higher data rate physical > layer standard, _after_ considering the increased hardware costs > due to newly manufactured components for a standard that is just > newer. There is a real-estate problem. 10 sfp+ connectors takes a lot more space than one qsfp+. mtp/mpo connectors and the associated trunk ribbon cables are a lot more compact than the equivalent 10Gbe footprint terminated as LC. When you add cwdm as 40Gb/s lr4 does the fiber count drops by a lot. > E.g. If no fewer transceivers and fewer strands of fiber required, > or shorter wavelength required, so it doesn't enable you to achieve > greater throughput over the same amount of light spectrum on your > cabling, and therefore lower cost at sufficient density, then: in > that case, there will probably be fairly little point in having the > higher rate standard exist in the first place, as long as the > bonding mechanisms available are good for the previous standard. > > Just keep bonding together more and more data links at basic units of > 10GE, until the required throughput capacity has been achieved. > > > It's not as if a newer 1 Tbit standard, will make the bits you send > get read at the other end faster than the speed of light. Newer > standard does not necessarily mean more reliable, technically better, > or more efficient, so it is prudent to consider what is actually > achieved that would benefit networks considered to be potential > candidates for implementation of the new standard, before actually > making it a standard... > > -- > -JH > From mohta at necom830.hpcl.titech.ac.jp Sun Sep 30 22:36:39 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 01 Oct 2012 07:36:39 +0900 Subject: /. Terabit Ethernet is Dead, for Now In-Reply-To: <5068C07D.2060203@bogus.com> References: <20120927125157.GT9750@leitl.org> <23047F2D-0BD7-4DDB-ADC3-54AE56684BEE@puck.nether.net> <5066CC77.1050609@necom830.hpcl.titech.ac.jp> <5068C07D.2060203@bogus.com> Message-ID: <5068C977.70307@necom830.hpcl.titech.ac.jp> joel jaeggli wrote: >>> The problem is that physical layer of 100GE (with 10*10G) and >>> 10*10GE are identical (if same plug and cable are used both for >>> 100GE and 10*10GE). >> Interesting. Well, I would say if there are no technical >> improvements that will significantly improve performance over the best >> possible carrier Ethernet bonding implementation and no cost savings >> at the physical layer over picking the higher data rate physical >> layer standard, _after_ considering the increased hardware costs >> due to newly manufactured components for a standard that is just >> newer. > There is a real-estate problem. 10 sfp+ connectors takes a lot more > space than one qsfp+. mtp/mpo connectors and the associated trunk ribbon > cables are a lot more compact than the equivalent 10Gbe footprint > terminated as LC. That's why I wrote: >>> (if same plug and cable are used both for >>> 100GE and 10*10GE). As is mentioned in 40G thread, 24 Port 40GE interface module of Extreme BD X8 can be used as 96 port 10GE. > When you add cwdm as 40Gb/s lr4 does the fiber count > drops by a lot. That's also possible with 4*10GE and 4*10GE is a lot more flexible to enable 3*10GE failure mode trivially and allows for very large skew. Masataka Ohta From tom at ninjabadger.net Sun Sep 30 22:49:16 2012 From: tom at ninjabadger.net (Tom Hill) Date: Sun, 30 Sep 2012 23:49:16 +0100 Subject: /. Terabit Ethernet is Dead, for Now In-Reply-To: References: <20120927125157.GT9750@leitl.org> <23047F2D-0BD7-4DDB-ADC3-54AE56684BEE@puck.nether.net> <5066CC77.1050609@necom830.hpcl.titech.ac.jp> Message-ID: <5068CC6C.50001@ninjabadger.net> On 30/09/12 20:05, Jimmy Hess wrote: > On 9/29/12, Masataka Ohta wrote: >> >Jared Mauch wrote: > ... >> >The problem is that physical layer of 100GE (with 10*10G) and >> >10*10GE are identical (if same plug and cable are used both for >> >100GE and 10*10GE). > Interesting. Well, I would say if there are no technical > improvements that will significantly improve performance over the best > possible carrier Ethernet bonding implementation and no cost savings > at the physical layer over picking the higher data rate physical > layer standard,_after_ considering the increased hardware costs > due to newly manufactured components for a standard that is just > newer. > > E.g. If no fewer transceivers and fewer strands of fiber required, > or shorter wavelength required, so it doesn't enable you to achieve > greater throughput over the same amount of light spectrum on your > cabling, and therefore lower cost at sufficient density, then: in > that case, there will probably be fairly little point in having the > higher rate standard exist in the first place, as long as the > bonding mechanisms available are good for the previous standard. When you consider 100GBASE-LR4 (with its 4x25G form factor) there is some efficiency to be gained. ADVA & others now support the running of each channel on their DWDM muxes at ~28G, to suit carrying 100GBASE-LR4 over four of your existing waves. CFPs with 4xSFP+ tunable optics in the front are out there for this reason. Once you get your head (and wallet) around that, there becomes a case for running each of your waves at 2.5x the rate they're employed at now. The remaining question is then to decide if that's cheaper than running more fibre. Still a hard one to justify though, I agree. I've recently seen a presentation from EPF** (by Juniper) that was *very* interesting in the >100G race, from a technical perspective. Well worth hunting that one down if you can, as it details a lot about optic composition in future standards, optic densities/backplanes, etc. Tom ** I couldn't justify going, but the nerd porn is hard to turn down. :) From delfes at gmail.com Fri Sep 28 19:33:59 2012 From: delfes at gmail.com (dale) Date: Fri, 28 Sep 2012 14:33:59 -0500 Subject: Charter Business IPv6 Contact? Message-ID: <5065FBA7.2020504@gmail.com> Apologies, as this was discussed recently. There was an engineer from Charter Business who was setting up IPv6 trials for Charter Business customers recently. If he is still lurking the list, can I ask that you contact me off-list to discuss this? Thank You. Dale Elfes From eaptech at gmail.com Sat Sep 29 03:05:09 2012 From: eaptech at gmail.com (Eric Adler) Date: Fri, 28 Sep 2012 23:05:09 -0400 Subject: RFC becomes Visio In-Reply-To: <201209290241.q8T2fPND088353@mail.r-bonomi.com> References: <201209290241.q8T2fPND088353@mail.r-bonomi.com> Message-ID: Why not RFC 5514 over RFC 2410 encryption over RFC2549 enhanced RFC1149 with all sessions padded with a number (generated by a server compliant with RFC3091) of the packets described in RFC6592? Oh, and don't forget to set the bit described in RFC3514 as appropriate. Or, ya know, one could just draw up a quick document or a note stating the frivolous nature of such. Eric On 9/28/12, Robert Bonomi wrote: > >> Mike Lyon wrote: >> On Fri, Sep 28, 2012 at 11:18 AM, Seth Mattinen >> wrote: >> > On 9/28/12 11:08 AM, Joe Maimon wrote: >> > > Just got told by a Lightpath person that in order to do BGP on a >> > > customer gig circuit to them they would need a visio diagram (of what >> > > I >> > > dont know). >> > > >> > > Has anybody else seen this brain damage? >> > >> > Hand draw two squares, label them "our AS" and "your AS" with a line >> > between them labeled "GigE". Bonus points for pencil. >> > >> >> And super duper bonus points is you draw pigeons carrying packets between >> the two blocks and stating that you are RFC 1149 compliant. >> > > No, no, *NO*!! > > The proper approach is to ask the vendor for RFC 1149 trasport for the BGP > session, and whether it terminates in a shared cage, or if a fully private > one is required. Including an 'envionmental impact statement'. Explaining > that this info is required in order to produce an accurate Visio diagram. > > > > > -- Sent from my mobile device From yang.yu.list at gmail.com Fri Sep 28 23:09:59 2012 From: yang.yu.list at gmail.com (Yang Yu) Date: Fri, 28 Sep 2012 19:09:59 -0400 Subject: is CERNET part of the Internet? In-Reply-To: <20120927092334.GY9750@leitl.org> References: <20120927092334.GY9750@leitl.org> Message-ID: Most networks have some sort of firewall (hopefully...) Isn't CERNET kind of similar to Internet2/NLR? Members own their network Free to join Serve education&research community Members encourage their users to use "the free network" instead of public network when possible Please correct me if I am wrong. Yang On Thu, Sep 27, 2012 at 5:23 AM, Eugen Leitl wrote: > > I'm trying to figure out whether CERNET > http://en.wikipedia.org/wiki/CERNET > is part of the official Internet, or is behind the Great Firewall where > access to invididual networks on the public Internet must be explicitly > granted. Anyone in the know? > >