From jsw at inconcepts.biz Thu Dec 1 02:36:13 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Thu, 1 Dec 2011 03:36:13 -0500 Subject: Link local for P-t-P links? (Was: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?) In-Reply-To: References: Message-ID: On Wed, Nov 30, 2011 at 9:15 PM, Mike Jones wrote: > Link-Local? > > For "true" P-t-P links I guess you don't need any addresses on the Point-to-point links in your backbone are by far the easiest thing to defend against this attack. I wish we would steer the discussion away from point-to-point links that are entirely within the control of the operator, as this is really quite well understood. Major ISPs including Level3 are already doing /126 to their customers today as well. In fact, Level3 does not even reserve a /64, they will hand out ::0/126 to one customer on a given access router, ::4/126 to the next. It clearly works. The access layer for non point-to-point customers, on the other hand, is less well-understood. That's why we keep having these discussions. Getting customers (and their device/software) to work correctly with link-local addressing and DHCP-PD or similar is going to be an uphill battle in a hosting environment. It also breaks down immediately if the hosting customer, for example, wishes to use ND to be able to provision addresses on two or more servers from a common subnet. So there are both perception and practical problems / limitations with this approach. I'm not saying it's a bad idea, but it won't work in some instances. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From doctorchd at gmail.com Thu Dec 1 04:11:12 2011 From: doctorchd at gmail.com (Dmitry Cherkasov) Date: Thu, 1 Dec 2011 12:11:12 +0200 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: References: Message-ID: John, Due to your note I carefully read again Cable Labs specs and found that really SLAAC is not prohibited. According to CM-SP-MULPIv3.0: * If the M bit in the RA is set to 1, the CM (cable modem) MUST use DHCPv6 ...; * If there are no prefix information options in the RA, the CM MUST NOT perform SLAAC; * If the RA contains a prefix advertisement with the A bit set to 0, the CM MUST NOT perform SLAAC on that prefix. That means that if M bit in the RA is set to 0 and RA contains a prefix advertisement with the A bit set to 1 nothing prevents CM from SLAAC. And if so we probably better reserve /64 per network just in case we may use SLAAC in it in the future. While we do not use SLAAC we can shorten the range of actually used IPv6 addresses by using longer then /64 prefix. You are completely right that prefix delegation enforce DHCPv6 so SLAAC mentioned above can be used only for CMs, not for CPE. Just a note: as far as I can see available DOCSIS 3.0 CMTSes do not support the ability of SLAAC for CMs currently (checked Casa and Cisco uBR10K). Dmitry Cherkasov 2011/11/30 Brzozowski, John : > Technically this is not true. ?SLAAC is not prohibited, it does come with > side affects that complicate the deployment of IPv6. ?It is technically > feasible to use SLAAC, it is just not practical in most cases. > > Stateful DHCPv6 is the preferred mechanism for address and configuration > assignment. ?Prefix delegation requires the use of stateful DHCPv6 in > DOCSIS networks. > > John > ========================================= > John Jason Brzozowski > Comcast Cable > e) mailto:john_brzozowski at cable.comcast.com > o) 609-377-6594 > m) 484-962-0060 > w) http://www.comcast6.net > ========================================= > > > > > On 11/29/11 7:09 AM, "Dmitry Cherkasov" wrote: > >>Steven, >> >>SLAAC is prohibited for using in DOCSIS networks, router >>advertisements that allow SLAAC must be ignored by end-devices, >>therefore DHCPv6 is the only way of configuring (if not talking about >>statical assignment). I have seen at least Windows7 handling this >>properly in its default configuration: it starts DHCPv6 negotiation >>instead of auto-configuration. >> >>Dmitry Cherkasov >> >> >> >>2011/11/29 Steven Bellovin : >>> >>> On Nov 28, 2011, at 4:51 52PM, Owen DeLong wrote: >>> >>>> >>>> On Nov 28, 2011, at 7:29 AM, Ray Soucy wrote: >>>> >>>>> It's a good practice to reserve a 64-bit prefix for each network. >>>>> That's a good general rule. ?For point to point or link networks you >>>>> can use something as small as a 126-bit prefix (we do). >>>>> >>>> >>>> Technically, absent buggy {firm,soft}ware, you can use a /127. There's >>>>no >>>> actual benefit to doing anything longer than a /64 unless you have >>>> buggy *ware (ping pong attacks only work against buggy *ware), >>>> and there can be some advantages to choosing addresses other than >>>> ::1 and ::2 in some cases. If you're letting outside packets target >>>>your >>>> point-to-point links, you have bigger problems than neighbor table >>>> attacks. If not, then the neighbor table attack is a bit of a >>>>red-herring. >>>> >>> >>> The context is DOCSIS, i.e., primarily residential cable modem users, >>>and >>> the cable company ISPs do not want to spend time on customer care and >>> hand-holding. ?How are most v6 machines configured by default? ?That is, >>> what did Microsoft do for Windows Vista and Windows 7? ?If they're set >>>for >>> stateless autoconfig, I strongly suspect that most ISPs will want to >>>stick >>> with that and hand out /64s to each network. ?(That's apart from the >>>larger >>> question of why they should want to do anything else...) >>> >>> >>> ? ? ? ? ? ? ? ?--Steve Bellovin, https://www.cs.columbia.edu/~smb >>> >>> >>> >>> >>> >>> >> > From bjohnson at drtel.com Thu Dec 1 08:10:02 2011 From: bjohnson at drtel.com (Brian Johnson) Date: Thu, 1 Dec 2011 14:10:02 +0000 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B60F4BF@ex-mb-1.corp.atlasnetworks.us> References: <8BE79149-2378-4B8D-AB4D-E2ECB6CF3E0E@cisco.com> <1A82EDD0-EB67-45FD-B601-1456ECC0BD5D@delong.com> <4ED52053.5040102@bogus.com> <36213AC7-884E-4673-BBF0-565958BAAB45@delong.com> <77B5EFBB-FBD3-496B-8C7F-42BA1370075F@delong.com> <52B9067E-E0EA-41F8-A28E-8B5FE7321DD4@exonetric.com> <8C26A4FDAE599041A13EB499117D3C286B60F4BF@ex-mb-1.corp.atlasnetworks.us> Message-ID: Nathan, I respect your positions, but you presume too much. I'm in no way an evangelist, but I agree with most of the points made by those you categorize as such. I'll reply specifically in-line. >-----Original Message----- >From: Nathan Eisenberg [mailto:nathan at atlasnetworks.us] >Sent: Wednesday, November 30, 2011 4:05 PM >To: nanog at nanog.org >Subject: RE: IPv6 prefixes longer then /64: are they possible in DOCSIS >networks? > > >Or you might do what a lot of us have done: get sick of arguing with the >evangelists about how /64's don't make sense for everyone in every scenario. >Get sick of trying to argue that every home's CPE doesn't need a /48 >delegated to it so that it can automatically subdelegate longer networks to >devices which will in turn subdelegate even longer prefixes to devices which >"something that hasn't been invented yet will use, and if you don't set it up >this way, history will prove that you're an unimaginative fool". Get sick of >hearing "It's a huge address space, so don't worry about being conservative - >sitting 'on the shelf' or sitting unused in a network are the same thing" (I guess >we'll migrate to an even bigger address space if we someday have other >stellar bodies in our local star system to send packets to, despite the average >home network utilizing far, far less than .00[...]01% of their address space... - >add a lot more 0's if the /48 guys win out...) It sounds like you are still in the IPv4 paradigm. I agree with your statements, but not your tone or implications. I think you misread people who have immense knowledge on the subject matter and care deeply with people who are grinding an axe for political or emotional purposes. If someone argued with you on the subtleties of gravity and doesn't accept the basic premise of gravity, you would likely respond similarly. > >This new IPv6 world is full of lazy evangelists, who are so excited about same- >sized subnets, stateless address configuration and globally unique and >routable addresses for purposes that no one can quite imagine yet, that they >cannot engage in a logical and rational discussion with the rest of us. Instead, >we go back and forth over the same concerns, until the patience of the list has >been utterly worn out - at which point, these individuals always throw their >hands in the air, and exclaim: "You're wrong, and your customers will tell you >that with their feet", and presume that they have then proven you wrong. I'm rubber your glue.... Never mind. The things you are minimalizing are some of the design specifications of the protocol. It's like arguing about the fact that IPv4 has certain headers and they are dumb. GET OVER IT! And no one will ever prove you wrong. It's that everyone else will do one thing and you will do something else. Live with your decision. This debate result can be seen in situations where people are too far apart at the start. This may be due to the paradigm shift to IPv6 from IPv4. > >As has been pointed out, there is a lot of human nature at work here: these >individuals have made low-level emotional investments in their arguments, >and divided the IPv6-think world into two categories: Us (right), and Not Us >(wrong). When someone does this, it can take a significant amount of >psychology to get the conversation to a rational place, and unless you have a >real need to see eye to eye with them, it's often easier to move on. In any >case, do the research and testing, and make sure that at least your own >deployments have rational addressing policies (whatever you determine that >might be). I wish you hadn't gone into the psychological babble here. You are right about this though. Do what you think is best for you. Please do not denigrate others for not coming to the same conclusions as you. When you ask for an opinion on this type of medium, about a controversial topic, you will get this type of thread. Live it.... Love it! - Brian Johnson From jra at baylink.com Thu Dec 1 08:41:35 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 1 Dec 2011 09:41:35 -0500 (EST) Subject: Wired mag piece on the Water Utility SCADA 'Attack' In-Reply-To: <14351735.1125.1322750472895.JavaMail.root@benjamin.baylink.com> Message-ID: <21004746.1127.1322750495937.JavaMail.root@benjamin.baylink.com> Damn that was quick: http://j.mp/rvWnEC (hat tip: lauren at vortex) 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 http://photo.imageinc.us +1 727 647 1274 From cra at WPI.EDU Thu Dec 1 08:42:07 2011 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 1 Dec 2011 09:42:07 -0500 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: References: <1A82EDD0-EB67-45FD-B601-1456ECC0BD5D@delong.com> <4ED52053.5040102@bogus.com> <36213AC7-884E-4673-BBF0-565958BAAB45@delong.com> <77B5EFBB-FBD3-496B-8C7F-42BA1370075F@delong.com> Message-ID: <20111201144207.GN9465@angus.ind.WPI.EDU> On Wed, Nov 30, 2011 at 06:55:56PM -0600, Jimmy Hess wrote: > On Wed, Nov 30, 2011 at 2:13 PM, Owen DeLong wrote: > > On Nov 30, 2011, at 9:10 AM, Ray Soucy wrote: > > I do believe that there is no benefit to longer prefixes than /64. > > Nobody has provided any convincing evidence to the contrary. > > Yes they have, thoroughly; mitigation of this one particular issue, ND table > overflow is a benefit. You simply don't have to worry about this issue in > the most important place it arises if you implement long prefixes for all > P-t-P links from the start. > > I do believe there is no benefit to prefixes shorter than /126 for P-t-P links. > Nobody has provided convincing evidence to the contrary. > > > There are better ways to mitigate ND than longer prefixes. > > Please explain. What are the better ways that you would propose > of mitigating ND table overflows? > If you can show a rational alternative, then it would be persuasive as > a better option. Jumping in here, how about static ND entries? Then you can use the /64 for P-t-P, but set the few static ND entries you need, and turn off dynamic ND. An out-of-band provisioning system could add static ND entries as needed. Another idea, perhaps more useful for client LANs, would be to have a fixed mapping between IPv6 IID and MAC address. Use DHCPv6 to force clients' lower 64 bits to be equal to their MAC address (EUI-64 or similar) and program the router to use this directly instead of using NDP, or statically program the ND table on the router from the DHCPv6 lease data--there is already precedent for doing this with IPv4 & ARP using DHCP Snooping or Relay or Proxy on the router. From nanog at data102.com Thu Dec 1 09:17:08 2011 From: nanog at data102.com (randal k) Date: Thu, 1 Dec 2011 08:17:08 -0700 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: References: <48778.1321883369@turing-police.cc.vt.edu> <4ECAB566.5070408@blakjak.net> Message-ID: This is a huge point. We've had a LOT of trouble finding good network engineers who have all of the previously mentioned "soft" attributes - attitude, team player, can write, can speak, can run a small project - and are more than just Cisco pimps. I cannot explain how frustrating it is to meet a newly minted CCNP who has zero Linux experience, can't script anything, can't setup a syslog server, doesn't understand AD much less LDAP, etc. Imagine, an employee who can help themselves 90% of the time ... Finding the diamond that has strong niche skill, networking, with a broad & just-deep-enough sysadmin background has been very, very hard. I cannot emphasize enough the importance of cross-training. Immensely valuable. Randal On Wed, Nov 30, 2011 at 4:39 PM, Bill Stewart wrote: > And yeah, sometimes it means that you need to go > learn technologies like Active Directory > [snip] > > In addition to learning scripting languages > From jra at baylink.com Thu Dec 1 09:24:59 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 1 Dec 2011 10:24:59 -0500 (EST) Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: Message-ID: <17004148.1137.1322753099098.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "randal k" > Finding the diamond that has strong niche skill, networking, with a broad & > just-deep-enough sysadmin background has been very, very hard. I cannot > emphasize enough the importance of cross-training. Immensely valuable. A relatively serviceable argument can be made that that guy who knows every parameter of every command of every version of IOS ever shipped, and which bugs are in which ones... is like that cause he's an Aspie, and you're not gonna *get* the other stuff from him or her, no matter how hard you try. Luckily, by the time you get to the point where you *need* that person, your staff is usually large enough that you can absorb some savants. 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 http://photo.imageinc.us +1 727 647 1274 From leigh.porter at ukbroadband.com Thu Dec 1 09:21:17 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Thu, 1 Dec 2011 15:21:17 +0000 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: References: <48778.1321883369@turing-police.cc.vt.edu> <4ECAB566.5070408@blakjak.net> Message-ID: I am looking for just such a person now. Good Juniper, some Cisco and Sysadmin experience with an ISP background.. I expect it will be immensely difficult to find somebody. What makes it even more frustrating is that just such a person was not all that long ago made redundant! So if anybody is looking for something to do around London... -- Leigh > -----Original Message----- > From: randal k [mailto:nanog at data102.com] > Sent: 01 December 2011 15:19 > To: Bill Stewart > Cc: nanog at nanog.org > Subject: Re: Looking for a Tier 1 ISP Mentor for career advice. > > This is a huge point. We've had a LOT of trouble finding good network > engineers who have all of the previously mentioned "soft" attributes - > attitude, team player, can write, can speak, can run a small project - > and > are more than just Cisco pimps. I cannot explain how frustrating it is > to > meet a newly minted CCNP who has zero Linux experience, can't script > anything, can't setup a syslog server, doesn't understand AD much less > LDAP, etc. Imagine, an employee who can help themselves 90% of the time > ... > > Finding the diamond that has strong niche skill, networking, with a > broad & > just-deep-enough sysadmin background has been very, very hard. I cannot > emphasize enough the importance of cross-training. Immensely valuable. > > Randal > > On Wed, Nov 30, 2011 at 4:39 PM, Bill Stewart > wrote: > > > And yeah, sometimes it means that you need to go > > learn technologies like Active Directory > > > [snip] > > > > > In addition to learning scripting languages > > > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud > service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From manager at monmouth.com Thu Dec 1 09:52:39 2011 From: manager at monmouth.com (Mark Stevens) Date: Thu, 01 Dec 2011 10:52:39 -0500 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: References: <48778.1321883369@turing-police.cc.vt.edu> <4ECAB566.5070408@blakjak.net> Message-ID: <4ED7A2C7.7010105@monmouth.com> It takes me years to find such people and when I do, I try very hard to keep them! I have 3 key people that fit the "soft" attribute criteria Randal mentioned, but with a premium skill set in their specific function. Good luck with your task Leigh! Mark Stevens On 12/1/2011 10:21 AM, Leigh Porter wrote: > I am looking for just such a person now. Good Juniper, some Cisco and Sysadmin experience with an ISP background.. > > I expect it will be immensely difficult to find somebody. What makes it even more frustrating is that just such a person was not all that long ago made redundant! > > So if anybody is looking for something to do around London... > > -- > Leigh > > >> -----Original Message----- >> From: randal k [mailto:nanog at data102.com] >> Sent: 01 December 2011 15:19 >> To: Bill Stewart >> Cc: nanog at nanog.org >> Subject: Re: Looking for a Tier 1 ISP Mentor for career advice. >> >> This is a huge point. We've had a LOT of trouble finding good network >> engineers who have all of the previously mentioned "soft" attributes - >> attitude, team player, can write, can speak, can run a small project - >> and >> are more than just Cisco pimps. I cannot explain how frustrating it is >> to >> meet a newly minted CCNP who has zero Linux experience, can't script >> anything, can't setup a syslog server, doesn't understand AD much less >> LDAP, etc. Imagine, an employee who can help themselves 90% of the time >> ... >> >> Finding the diamond that has strong niche skill, networking, with a >> broad& >> just-deep-enough sysadmin background has been very, very hard. I cannot >> emphasize enough the importance of cross-training. Immensely valuable. >> >> Randal >> >> On Wed, Nov 30, 2011 at 4:39 PM, Bill Stewart >> wrote: >> >>> And yeah, sometimes it means that you need to go >>> learn technologies like Active Directory >>> >> [snip] >> >>> In addition to learning scripting languages >>> >> ______________________________________________________________________ >> This email has been scanned by the Symantec Email Security.cloud >> service. >> For more information please visit http://www.symanteccloud.com >> ______________________________________________________________________ > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ > > > From igor at ergens.org Thu Dec 1 10:07:15 2011 From: igor at ergens.org (Igor Ybema) Date: Thu, 1 Dec 2011 17:07:15 +0100 Subject: bgp update destroying transit on redback routers ? Message-ID: Hi there, Since about 15:00u GMT we receive bgp updates from our transit which destroys the bgp sessions with them with message: send NOTIFICATION: 3/9 (update: optional attribute error) with 11 byte data. mxReadMs=610 We use redback smartedge routers (SE100) currently for BGP. Anyone who have seen this also? regards, Igor From bicknell at ufp.org Thu Dec 1 10:13:18 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 1 Dec 2011 08:13:18 -0800 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: References: <48778.1321883369@turing-police.cc.vt.edu> <4ECAB566.5070408@blakjak.net> Message-ID: <20111201161317.GA66722@ussenterprise.ufp.org> In a message written on Thu, Dec 01, 2011 at 08:17:08AM -0700, randal k wrote: > This is a huge point. We've had a LOT of trouble finding good network > engineers who have all of the previously mentioned "soft" attributes - > attitude, team player, can write, can speak, can run a small project - and > are more than just Cisco pimps. I cannot explain how frustrating it is to > meet a newly minted CCNP who has zero Linux experience, can't script > anything, can't setup a syslog server, doesn't understand AD much less > LDAP, etc. Imagine, an employee who can help themselves 90% of the time ... I've been on both sides of this coin, looking for folks with these sorts of skills and finding them very difficult to find but also looking for employers who valued this base of skills when I have been job hunting in the past. My observation is that most ISP's want this broad base of skills, but won't pay for it. The folks with these skills promptly move in one of a few directions. They become consultants making huge money but dealing with the clueless. They become SE's for vendors and VAR's, where their skills can earn them comissions. The few lucky ones become Architects or Principal Engineers and provide vision and run key projects, but then they aren't doing much day to day work. More interestingly, the people with these sorts of skills got them because they like touching everything and maintaining their end to end knowledge. While it's more a problem on the corporate side, a lot of folks want to hire this knowledge and then put them in a role where their hands are tied, unable to access all of these parts. Obstensibly the goal is to have them lead and mentor the clueless in control of the various elements, but the few folks I've seen try it quickly get frustrated, see no future in it, and leave. No where is this more true than when these sorts of folks are brought in to manage outsourced arrangements. It's a wonderful double edged sword. Someone who can think their way out of a myriad of technical problems is also smart enough to evaluate the orginizational structure and dynamics, predict their own future (or lack thereof), predict the success and failure rates of the current envornment and leave if they don't think it's a net positive. I do think NANOG as a community could do a better job in helping employers and potential employees in this industry find each other. I know nanog-jobs exists, but it doesn't seem to have traction with either side of the problem. -- 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 leigh.porter at ukbroadband.com Thu Dec 1 10:36:39 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Thu, 1 Dec 2011 16:36:39 +0000 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: <20111201161317.GA66722@ussenterprise.ufp.org> References: <48778.1321883369@turing-police.cc.vt.edu> <4ECAB566.5070408@blakjak.net> <20111201161317.GA66722@ussenterprise.ufp.org> Message-ID: > -----Original Message----- > From: Leo Bicknell [mailto:bicknell at ufp.org] > Sent: 01 December 2011 16:15 > To: nanog at nanog.org > Subject: Re: Looking for a Tier 1 ISP Mentor for career advice. > It's a wonderful double edged sword. Someone who can think their way > out of a myriad of technical problems is also smart enough to evaluate > the orginizational structure and dynamics, predict their own future (or > lack thereof), predict the success and failure rates of the current > envornment and leave if they don't think it's a net positive. An excellent analysis of the situation. -- Leigh ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From snar at snar.spb.ru Thu Dec 1 10:38:03 2011 From: snar at snar.spb.ru (Alexandre Snarskii) Date: Thu, 1 Dec 2011 20:38:03 +0400 Subject: bgp update destroying transit on redback routers ? In-Reply-To: References: Message-ID: <20111201163803.GA50110@snar.spb.ru> On Thu, Dec 01, 2011 at 05:07:15PM +0100, Igor Ybema wrote: > Hi there, > Since about 15:00u GMT we receive bgp updates from our transit which > destroys the bgp sessions with them with message: > > send NOTIFICATION: 3/9 (update: optional attribute error) with 11 byte > data. mxReadMs=610 > > We use redback smartedge routers (SE100) currently for BGP. > > Anyone who have seen this also? Have a complaint from our customer too. On our side (juniper) this is logged as: NOTIFICATION received from (External AS ): code 3 (Update Message Error) subcode 9 (error with optional attribute), Data: c0 07 08 00 00 00 As far as I can decode this attribute this is: c0: optional, transitive, no partial, no extended-length 07: AGGREGATOR 08: attribute length is 8 bytes. I think attribute length may be a problem here, because per RFC AGGREGATOR is an optional transitive attribute of length 6. -- In theory, there is no difference between theory and practice. But, in practice, there is. From igor at ergens.org Thu Dec 1 11:03:17 2011 From: igor at ergens.org (Igor Ybema) Date: Thu, 1 Dec 2011 18:03:17 +0100 Subject: bgp update destroying transit on redback routers ? In-Reply-To: <20111201163803.GA50110@snar.spb.ru> References: <20111201163803.GA50110@snar.spb.ru> Message-ID: > > AGGREGATOR is an optional transitive attribute of length 6. > > -- > In theory, there is no difference between theory and practice. > But, in practice, there is. Typical, because: AGGREGATOR is an optional transitive attribute of length 6. The attribute contains the last AS number that formed the aggregate route (encoded as 2 octets), followed by the IP address of the BGP speaker that formed the aggregate route (encoded as 4 octets). Usage of this attribute is described in 5.1.7 And what to do with 4-byte AS-numbers then? That would explain the 8 bytes. regards, Igor From igor at ergens.org Thu Dec 1 11:08:54 2011 From: igor at ergens.org (Igor Ybema) Date: Thu, 1 Dec 2011 18:08:54 +0100 Subject: bgp update destroying transit on redback routers ? In-Reply-To: References: <20111201163803.GA50110@snar.spb.ru> Message-ID: > And what to do with 4-byte AS-numbers then? That would explain the 8 bytes. > Looking futher: Two new attributes, AS4_PATH and AS4_AGGREGATOR, are introduced that can be used to propagate four-octet based AS path information cross BGP speakers that do not support the four-octet AS numbers. However this router is AS4 capable, but probably fails to understand a 4-byte AS in the normal AGGREGATOR attribute. If I understand correctly a AS4 capable router should understand when announcing that to it's peer. I'm I correct? Should I file this as a bug? (redback/ericsson is already looking also) regards, Igor From dholmes at mwdh2o.com Thu Dec 1 11:26:13 2011 From: dholmes at mwdh2o.com (Holmes,David A) Date: Thu, 1 Dec 2011 09:26:13 -0800 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: <4ED7A2C7.7010105@monmouth.com> References: <48778.1321883369@turing-police.cc.vt.edu> <4ECAB566.5070408@blakjak.net> <4ED7A2C7.7010105@monmouth.com> Message-ID: <922ACC42D498884AA02B3565688AF995340255F3F3@USEXMBS01.mwd.h2o> Personally, I have worked in places where I have performed all of the skills below (router/switch/Unix/Linux/AD/firewall/proxy/web admin/sendmail admin, etc.), and also in places where just router/switch/architect layer 1-3 skills were the primary focus. I prefer the latter, and find this to be a personal choice as to what makes for a meaningful and fulfilling job. The fact that so few network engineers are to be found with all of these skills, I think, speaks for itself in that many network engineers have made the choice, and that choice is to be focused on layers 1-3, which, with DWDM through BGP, offers many challenging, different, and varied technology complexities the mastery of which makes work meaningful and rewarding. -----Original Message----- From: Mark Stevens [mailto:manager at monmouth.com] Sent: Thursday, December 01, 2011 7:53 AM To: nanog at nanog.org Subject: Re: Looking for a Tier 1 ISP Mentor for career advice. It takes me years to find such people and when I do, I try very hard to keep them! I have 3 key people that fit the "soft" attribute criteria Randal mentioned, but with a premium skill set in their specific function. Good luck with your task Leigh! Mark Stevens On 12/1/2011 10:21 AM, Leigh Porter wrote: > I am looking for just such a person now. Good Juniper, some Cisco and Sysadmin experience with an ISP background.. > > I expect it will be immensely difficult to find somebody. What makes it even more frustrating is that just such a person was not all that long ago made redundant! > > So if anybody is looking for something to do around London... > > -- > Leigh > > >> -----Original Message----- >> From: randal k [mailto:nanog at data102.com] >> Sent: 01 December 2011 15:19 >> To: Bill Stewart >> Cc: nanog at nanog.org >> Subject: Re: Looking for a Tier 1 ISP Mentor for career advice. >> >> This is a huge point. We've had a LOT of trouble finding good network >> engineers who have all of the previously mentioned "soft" attributes - >> attitude, team player, can write, can speak, can run a small project - >> and >> are more than just Cisco pimps. I cannot explain how frustrating it is >> to >> meet a newly minted CCNP who has zero Linux experience, can't script >> anything, can't setup a syslog server, doesn't understand AD much less >> LDAP, etc. Imagine, an employee who can help themselves 90% of the time >> ... >> >> Finding the diamond that has strong niche skill, networking, with a >> broad& >> just-deep-enough sysadmin background has been very, very hard. I cannot >> emphasize enough the importance of cross-training. Immensely valuable. >> >> Randal >> >> On Wed, Nov 30, 2011 at 4:39 PM, Bill Stewart >> wrote: >> >>> And yeah, sometimes it means that you need to go >>> learn technologies like Active Directory >>> >> [snip] >> >>> In addition to learning scripting languages >>> >> ______________________________________________________________________ >> This email has been scanned by the Symantec Email Security.cloud >> service. >> For more information please visit http://www.symanteccloud.com >> ______________________________________________________________________ > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ > > > This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system. From sakamura at gmail.com Thu Dec 1 11:30:18 2011 From: sakamura at gmail.com (Ishmael Rufus) Date: Thu, 1 Dec 2011 11:30:18 -0600 Subject: Broadband providers in downtown Chicago Message-ID: Our company is in a building at 200 w. Monroe and we have difficulty finding an internet service provider that could at least provide 1Mbps+ Upload bandwidth that is not Cogent Communications. Is it really this difficult finding a decent internet service provider in downtown Chicago? From david at davidradcliffe.org Thu Dec 1 12:26:56 2011 From: david at davidradcliffe.org (David Radcliffe) Date: Thu, 1 Dec 2011 13:26:56 -0500 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: <4ED7A2C7.7010105@monmouth.com> References: <4ED7A2C7.7010105@monmouth.com> Message-ID: <201112011326.57351.david@davidradcliffe.org> I keep running into cases where people do not know how to adequately use my talents so the compensation is too light... Or they require relocation, even though the nature of the job is virtual (hands on not really required). At least it is nice to see some folks out there who do need people like me. Over the years I've been a (very good) coder, sysadmin, DBA, network engineer, etc. with strong Cisco and some Juniper (of course a couple days self training and I am pretty strong on anything). I'm not a job hopper so I have to either really hate my position or get an offer too good to refuse, for me to change companies. For me the "too good" includes things like telecommute (I am well set up for that), good salary/package (have that now..the salary part anyway), limited paperwork a plus (we pay you salary, you provide results...no pointy haired bosses here), a company who's motto is not "Panic! Because planning is just too much effort." I guess my advice is: Don't miss out on someone who might be your star employee just to keep doing things the old way. Telecommuting can be very effective with the proper management tools. Obviously, working from home is not for everyone so the employee needs to be dedicated to the process. The best technical people can be quirky. I once had a guy on my team who customers thought was rude so I had to handle sites where people had met him before. I recognized he was desperately shy and did not deal with people well. He was a very talented technician so rather than loose him I was able to redeploy his abilities to projects not involving humans. Worked out well. For me it's lists. I do way better when I have lists I can check off. I make lists for everything and get a warm feeling when I check off an items. I like the word "check" because it brings up a picture in my head of a list with check marks. Freaky, huh? On Thursday, December 01, 2011 10:52:39 AM Mark Stevens wrote: > It takes me years to find such people and when I do, I try very hard to > keep them! I have 3 key people that fit the "soft" attribute criteria > Randal mentioned, but with a premium skill set in their specific > function. Good luck with your task Leigh! > > Mark Stevens > > On 12/1/2011 10:21 AM, Leigh Porter wrote: > > I am looking for just such a person now. Good Juniper, some Cisco and > > Sysadmin experience with an ISP background.. > > > > I expect it will be immensely difficult to find somebody. What makes it > > even more frustrating is that just such a person was not all that long > > ago made redundant! > > > > So if anybody is looking for something to do around London... > > > > -- > > Leigh > > > >> -----Original Message----- > >> From: randal k [mailto:nanog at data102.com] > >> Sent: 01 December 2011 15:19 > >> To: Bill Stewart > >> Cc: nanog at nanog.org > >> Subject: Re: Looking for a Tier 1 ISP Mentor for career advice. > >> > >> This is a huge point. We've had a LOT of trouble finding good network > >> engineers who have all of the previously mentioned "soft" attributes - > >> attitude, team player, can write, can speak, can run a small project - > >> and > >> are more than just Cisco pimps. I cannot explain how frustrating it is > >> to > >> meet a newly minted CCNP who has zero Linux experience, can't script > >> anything, can't setup a syslog server, doesn't understand AD much less > >> LDAP, etc. Imagine, an employee who can help themselves 90% of the time > >> ... > >> > >> Finding the diamond that has strong niche skill, networking, with a > >> broad& > >> just-deep-enough sysadmin background has been very, very hard. I cannot > >> emphasize enough the importance of cross-training. Immensely valuable. > >> > >> Randal > >> > >> On Wed, Nov 30, 2011 at 4:39 PM, Bill Stewart > >> > >> wrote: > >>> And yeah, sometimes it means that you need to go > >>> > >>> learn technologies like Active Directory > >>> > >> [snip] > >>> > >>> In addition to learning scripting languages > >> > >> ______________________________________________________________________ > >> This email has been scanned by the Symantec Email Security.cloud > >> service. > >> For more information please visit http://www.symanteccloud.com > >> ______________________________________________________________________ > > > > ______________________________________________________________________ > > This email has been scanned by the Symantec Email Security.cloud service. > > For more information please visit http://www.symanteccloud.com > > ______________________________________________________________________ -- David Radcliffe Network Engineer/Linux Specialist david at davidradcliffe.org www.davidradcliffe.org Nothing ever gets solved better with panic. If you do not know the answer, it is probably "42." From surfer at mauigateway.com Thu Dec 1 12:47:22 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 1 Dec 2011 10:47:22 -0800 Subject: Looking for a Tier 1 ISP Mentor for career advice. Message-ID: <20111201104722.F5796A6A@resin09.mta.everyone.net> ---- On 12/1/2011 10:21 AM, Leigh Porter wrote: --------- > I am looking for just such a person now. Good Juniper, some Cisco and Sysadmin experience with an ISP background.. [...] > So if anybody is looking for something to do around London... ----------------------------------------------------- Something I'd like to tell hiring folks lurking out there based on my experiences from living on an island far from population centers where all the jobs are... :-) One way to get such folks, as described in the previous posts, is to allow telecommuting. Have them come into the main office immediately after hiring them for 3-4 months, evaluate them and show them what's expected. Then let them go home to telecommute and have them come into the office a couple/few times a year for a week or two each time. They can even be required to work the same hours as the location where all the other engineers are. Or, on the big networks folks living in places like Hawaii can be the carry-over shift from US timezone to Asian timezones. This allows for a more productive employee many times because they are enjoying life where they live, rather than be forced into the larger population centers. In our industry, especially with all the tools we have today, it would seem that telecommuting would be more accepted, but it's not and I don't understand why. scott From olivier.benghozi at wifirst.fr Thu Dec 1 13:03:06 2011 From: olivier.benghozi at wifirst.fr (Olivier Benghozi) Date: Thu, 1 Dec 2011 20:03:06 +0100 Subject: bgp update destroying transit on redback routers ? Message-ID: Alexandre Snarskii wrote: > AGGREGATOR is an optional transitive attribute of length 6. > The attribute contains the last AS number that formed the > aggregate route (encoded as 2 octets), followed by the IP > address of the BGP speaker that formed the aggregate route > (encoded as 4 octets). Usage of this attribute is described > in 5.1.7 > > And what to do with 4-byte AS-numbers then? That would explain the 8 bytes. Hi, we also have some issues with this here, the update message the Redback logged is: ffff ffff ffff ffff ffff ffff ffff ffff 0049 02 0000 002e 4001 01 00 4002 12 02 04 00000513 00000d1c 0000b611 0000b611 4003 04 50ef82c1 4006 00 c007 08 00 0000 0000 0000 00 16 ce7d a4 The prefix is 206.125.164.0/22, AS-PATH is 1299 3356 46609 46609 (Telia, Level3, and finally Hostlogistic with one prepend). The AGGREGATOR is full of 0. I guess this could be what bothers the Redback/Ericsson code. I see the same route by other sessions, and the aggregator looks OK, since the sh bgp says: 206.125.164.0/22 [...] 8218 4436 46609 46609 [...] Origin incomplete, localpref 100, med 100, weight 100, external, best aggregator: 206.125.165.242, AS 46609, atomic-aggregate So Hostlogistic route to Level3 is malformed (according to the RFC, the AGGREGATOR content is mandatory if the attribute is present), but their route to NLayer is OK. Or maybe a Level3 router has a problem? Anyway, our Redback/Ericsson routers are the problem now, since the other vendors don't throw away the BGP sessions... I've opened a case at Ericsson, still waiting for an answer :-/ regards, Olivier Benghozi Wifirst From igor at ergens.org Thu Dec 1 13:06:29 2011 From: igor at ergens.org (Igor Ybema) Date: Thu, 1 Dec 2011 20:06:29 +0100 Subject: bgp update destroying transit on redback routers ? In-Reply-To: References: Message-ID: > So Hostlogistic route to Level3 is malformed (according to the RFC, the AGGREGATOR content is mandatory if the attribute is present), but their route to NLayer is OK. Or maybe a Level3 router has a problem? > Anyway, our Redback/Ericsson routers are the problem now, since the other vendors don't throw away the BGP sessions... > I've opened a case at Ericsson, still waiting for an answer :-/ Correct. This was pointed out to me just now off-list by another reader. Ericsson coder also contacted me and noted that is fixed a few months ago, but he is not sure which release has the fix. I hope he will respond on-list about this for everyone to read. regards, Igor From frnkblk at iname.com Thu Dec 1 13:42:31 2011 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 1 Dec 2011 13:42:31 -0600 Subject: IPv6 version of www.qwest.com/www.centurylink.com has been down for 10 days In-Reply-To: References: <000001cc5d68$93fc01d0$bbf40570$@iname.com> <0C6A4A8DD60DBF4A99C300DDA771BFAB01E8192746C7@server3.MUTUALTEL.MTCNET.NET> Message-ID: <000a01ccb061$5d60c100$18224300$@iname.com> AAAA and IPv6 access to www.centurylink.com were restored around 11:30 am U.S. Central. Frank -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Wednesday, November 30, 2011 6:59 AM To: 'nanog at nanog.org' Subject: RE: IPv6 version of www.qwest.com/www.centurylink.com has been down for 10 days Well, sometime yesterday www.centurylink.com removed it AAAA record(s). www.qwest.com still has them. Frank -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Monday, October 24, 2011 1:47 PM To: 'nanog at nanog.org' Subject: RE: IPv6 version of www.qwest.com/www.centurylink.com has been down for 10 days Good news: access to the v6 version of www.qwest.com came up at 12:30 pm today -- it redirects to www.centurylink.com, but at least it's working. Only www.savvis.com remains in my list of service provider websites that have non-working IPv6. Frank -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Thursday, August 18, 2011 12:35 AM To: nanog at nanog.org Subject: IPv6 version of www.qwest.com/www.centurylink.com has been down for 10 days The IPv6 version of www.qwest.com has been down for 10 days. Wget shows a 301 to www.centurylink.com, but that also fails. Emails to the nocs at both companies have gone unanswered. Unless HE is deployed in a web browser, this behavior leads to a bad end-user experience. If anyone can prod either of these two companies that would be much appreciated. Frank nagios:/home/fbulk# wget -6 www.qwest.com --2011-08-18 00:32:40-- http://www.qwest.com/ Resolving www.qwest.com... 2001:428:b21:1::20 Connecting to www.qwest.com|2001:428:b21:1::20|:80... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: http://www.centurylink.com/ [following] --2011-08-18 00:32:40-- http://www.centurylink.com/ Resolving www.centurylink.com... 2001:428:b21:1::22 Connecting to www.centurylink.com|2001:428:b21:1::22|:80... failed: Connection timed out. Retrying. --2011-08-18 00:33:02-- (try: 2) http://www.centurylink.com/ Connecting to www.centurylink.com|2001:428:b21:1::22|:80... failed: Connection timed out. Retrying. --2011-08-18 00:33:25-- (try: 3) http://www.centurylink.com/ Connecting to www.centurylink.com|2001:428:b21:1::22|:80... failed: Connection timed out. Retrying. --2011-08-18 00:33:49-- (try: 4) http://www.centurylink.com/ Connecting to www.centurylink.com|2001:428:b21:1::22|:80... failed: Connection timed out. Retrying. Etc... From jsw at inconcepts.biz Thu Dec 1 14:13:51 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Thu, 1 Dec 2011 15:13:51 -0500 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: <20111201144207.GN9465@angus.ind.WPI.EDU> References: <1A82EDD0-EB67-45FD-B601-1456ECC0BD5D@delong.com> <4ED52053.5040102@bogus.com> <36213AC7-884E-4673-BBF0-565958BAAB45@delong.com> <77B5EFBB-FBD3-496B-8C7F-42BA1370075F@delong.com> <20111201144207.GN9465@angus.ind.WPI.EDU> Message-ID: On Thu, Dec 1, 2011 at 9:42 AM, Chuck Anderson wrote: > Jumping in here, how about static ND entries? ?Then you can use the > /64 for P-t-P, but set the few static ND entries you need, and turn > off dynamic ND. ?An out-of-band provisioning system could add static > ND entries as needed. > > Another idea, perhaps more useful for client LANs, would be to have a > fixed mapping between IPv6 IID and MAC address. ?Use DHCPv6 to force Chuck, you are certainly correct that if ND resolution can be deactivated for an interface, there won't be an ND exhaustion problem on it. That's why I characterize the problem as ND exhaustion. :-) Whether or not this is practical for a given environment is up to the operators to decide. I, for example, know it is much easier for me to configure a /126 P-t-P than keep static ND entries and disable ND on those links. In my own backbone, your suggestion can be practical, but what about customer links? If the customer changes his device, he may present a different MAC address to my interface. Then I've got a static ND entry pointing to his old MAC address... resulting in a ticket, and ops work, which would not have been necessary with a simple /126. DHCPv6 with snooping and learning disabled would be great for the datacenter LAN if I thought I could get customers to bite off on it. When vendors begin delivering this feature it is something we will strongly consider. I don't know if customers will prefer to have this and need to run a DHCPv6 client, or prefer to have a /120 (or similar) for the approximate number of addresses they plan to use. I am not closed to alternatives. I want to give my customers /64s as soon as it becomes practical and production-ready. That is why we always reserve a /64 for each subnet, even though it is provisioned as a longer subnet. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From igor at ergens.org Thu Dec 1 14:15:48 2011 From: igor at ergens.org (Igor Ybema) Date: Thu, 1 Dec 2011 21:15:48 +0100 Subject: bgp update destroying transit on redback routers ? In-Reply-To: References: Message-ID: Hi all, A new update. A coder from ericsson told me that the problem is not 4-byte asn related. It is related to aggregator-asn=0 and aggregator-ip=0.0.0.0. Ericsson does not accept this as valid ASN and IP-address. The question is now, are all other vendors wrong in accepting this attribute (clearly ASN=0 and IP=0.0.0.0 isn't corresponding to the RFC stating 'which shall contain its own AS number and IP address') or is Ericsson being to strict? regards, Igor From morrowc.lists at gmail.com Thu Dec 1 14:19:22 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 1 Dec 2011 15:19:22 -0500 Subject: bgp update destroying transit on redback routers ? In-Reply-To: References: Message-ID: On Thu, Dec 1, 2011 at 3:15 PM, Igor Ybema wrote: > Hi all, > > A new update. A coder from ericsson told me that the problem is not > 4-byte asn related. It is related to aggregator-asn=0 and > aggregator-ip=0.0.0.0. Ericsson does not accept this as valid ASN and > IP-address. > > The question is now, are all other vendors wrong in accepting this > attribute (clearly ASN=0 and IP=0.0.0.0 isn't corresponding to the RFC > stating 'which shall contain its own AS number and IP address') or is > Ericsson being to strict? one of the reasons the above was written... > > regards, Igor > From igor at ergens.org Thu Dec 1 14:23:16 2011 From: igor at ergens.org (Igor Ybema) Date: Thu, 1 Dec 2011 21:23:16 +0100 Subject: bgp update destroying transit on redback routers ? In-Reply-To: References: Message-ID: > > > one of the reasons the above was written... That does not include when ASN=0 is used in the aggregator attribute. Could you add that? regards, Igor From morrowc.lists at gmail.com Thu Dec 1 14:36:26 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 1 Dec 2011 15:36:26 -0500 Subject: bgp update destroying transit on redback routers ? In-Reply-To: References: Message-ID: On Thu, Dec 1, 2011 at 3:23 PM, Igor Ybema wrote: >> >> >> one of the reasons the above was written... > > That does not include when ASN=0 is used in the aggregator attribute. > Could you add that? that's a warren question... From dave at temk.in Thu Dec 1 14:42:11 2011 From: dave at temk.in (Dave Temkin) Date: Thu, 01 Dec 2011 15:42:11 -0500 Subject: [NANOG-announce] NANOG54 (San Diego, Feb 5-8, 2012): Early Bird Registration Expiring on Sunday, 12/4 Message-ID: <4ED7E6A3.2020703@temk.in> Please note that the Early Bird registration for NANOG54 expires on Sunday, 12/4. Register now and save $75 off the regular registration fee! Also, as a reminder, the Call for Presentations is still open! Have something that you think is relevant to the NANOG community and would like to have the chance to present it? Please see http://www.nanog.org/meetings/nanog54/callforpresentations.html for more information. Looking forward to seeing you in sunny San Diego! -Dave (For the NANOG Program Committee) _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From david at davidradcliffe.org Thu Dec 1 15:35:27 2011 From: david at davidradcliffe.org (David Radcliffe) Date: Thu, 1 Dec 2011 16:35:27 -0500 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: <20111201104722.F5796A6A@resin09.mta.everyone.net> References: <20111201104722.F5796A6A@resin09.mta.everyone.net> Message-ID: <201112011635.27951.david@davidradcliffe.org> The reason it is not more accepted is too many people still think "If I cannot see you you must not be working." Since I like to work and code (I spend 10 hours a day on the computer at the office, think about work related stuff in the shower, and often write Perl code at home to deal with various household tasks) I work quite well at home. There are more distractions at the office and my productivity is greater in my home computer room during those times I have to put in some extra for the office. Actually, the best reason I have for working from home is I work much better when naked and they have asked me to stop showing up that way at the office. On Thursday, December 01, 2011 01:47:22 PM Scott Weeks wrote: > ---- On 12/1/2011 10:21 AM, Leigh Porter wrote: --------- > > > I am looking for just such a person now. Good Juniper, some Cisco and > > Sysadmin experience with an ISP background.. > > [...] > > > So if anybody is looking for something to do around London... > > ----------------------------------------------------- > > > Something I'd like to tell hiring folks lurking out there based on my > experiences from living on an island far from population centers where > all the jobs are... :-) > > One way to get such folks, as described in the previous posts, is to allow > telecommuting. Have them come into the main office immediately after > hiring them for 3-4 months, evaluate them and show them what's expected. > Then let them go home to telecommute and have them come into the office a > couple/few times a year for a week or two each time. They can even be > required to work the same hours as the location where all the other > engineers are. Or, on the big networks folks living in places like Hawaii > can be the carry-over shift from US timezone to Asian timezones. This > allows for a more productive employee many times because they are enjoying > life where they live, rather than be forced into the larger population > centers. > > In our industry, especially with all the tools we have today, it would seem > that telecommuting would be more accepted, but it's not and I don't > understand why. > > scott -- David Radcliffe Network Engineer/Linux Specialist david at davidradcliffe.org www.davidradcliffe.org Nothing ever gets solved better with panic. If you do not know the answer, it is probably "42." From jeff.tantsura at ericsson.com Thu Dec 1 15:56:43 2011 From: jeff.tantsura at ericsson.com (Jeff Tantsura) Date: Thu, 1 Dec 2011 16:56:43 -0500 Subject: bgp update destroying transit on redback routers ? Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF6181C25624E@EUSAACMS0701.eamcs.ericsson.se> Hi, Let me take it over from now on, I'm the IP Routing/MPLS Product Manager at Ericsson responsible for all routing protocols. There's nothing wrong in checking ASN in AGGREGATOR, we don't really want see ASN 0 anywhere, that's how draft-wkumari-idr-as0 (draft-ietf-idr-as0-00) came into the worlds. To my knowledge - the only vendor which allows changing ASN in AGGREGATOR is Juniper, see "no-aggregator-id", in the past I've tried to talk to Yakov about it, without any results though. So for those who have it configured - please rethink whether you really need it. As for SEOS - understanding that this badly affects our customers and not having draft-ietf-idr-error-handling fully implemented yet, we will temporarily disable this check in our code. Patch will be made available. Please contact me for any further clarifications. Regards, Jeff P.S. Warren has recently included AGGREGATOR in the draft, please see 2. Behavior This document specifies that a BGP speaker MUST NOT originate or propagate a route with an AS number of zero. If a BGP speaker receives a route which has an AS number of zero in the AS_PATH (or AS4_PATH) attribute, it SHOULD be logged and treated as a WITHDRAW. This same behavior applies to routes containing zero as the Aggregator or AS4 Aggregator. From bmanning at vacation.karoshi.com Thu Dec 1 16:22:12 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 1 Dec 2011 22:22:12 +0000 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: <201112011635.27951.david@davidradcliffe.org> References: <20111201104722.F5796A6A@resin09.mta.everyone.net> <201112011635.27951.david@davidradcliffe.org> Message-ID: <20111201222212.GA5671@vacation.karoshi.com.> On Thu, Dec 01, 2011 at 04:35:27PM -0500, David Radcliffe wrote: > The reason it is not more accepted is too many people still think "If I cannot > see you you must not be working." > actually, i've heard the real reason is corporate liability ... that said, there is an advantage for team f2f mtgs on a periodic basis. /bill From warren at kumari.net Thu Dec 1 17:04:52 2011 From: warren at kumari.net (Warren Kumari) Date: Thu, 1 Dec 2011 18:04:52 -0500 Subject: bgp update destroying transit on redback routers ? In-Reply-To: References: Message-ID: On Dec 1, 2011, at 3:36 PM, Christopher Morrow wrote: > On Thu, Dec 1, 2011 at 3:23 PM, Igor Ybema wrote: >>> >>> >>> one of the reasons the above was written... >> >> That does not include when ASN=0 is used in the aggregator attribute. >> Could you add that? > > that's a warren question... http://tools.ietf.org/html/draft-wkumari-idr-as0-01 has been replaced with http://tools.ietf.org/html/draft-ietf-idr-as0-00 -- which does include it. Thanks all, W From jeff.tantsura at ericsson.com Thu Dec 1 18:01:42 2011 From: jeff.tantsura at ericsson.com (Jeff Tantsura) Date: Thu, 1 Dec 2011 19:01:42 -0500 Subject: bgp update destroying transit on redback routers ? In-Reply-To: References: Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF6181C256342@EUSAACMS0701.eamcs.ericsson.se> Thanks Warren! I have already brought this to the list. Regards, Jeff -----Original Message----- From: Warren Kumari [mailto:warren at kumari.net] Sent: Thursday, December 01, 2011 3:05 PM To: Christopher Morrow Cc: nanog at nanog.org Subject: Re: bgp update destroying transit on redback routers ? On Dec 1, 2011, at 3:36 PM, Christopher Morrow wrote: > On Thu, Dec 1, 2011 at 3:23 PM, Igor Ybema wrote: >>> >>> >>> one of the reasons the above was written... >> >> That does not include when ASN=0 is used in the aggregator attribute. >> Could you add that? > > that's a warren question... http://tools.ietf.org/html/draft-wkumari-idr-as0-01 has been replaced with http://tools.ietf.org/html/draft-ietf-idr-as0-00 -- which does include it. Thanks all, W From tom+nanog at oneshoeco.com Thu Dec 1 18:26:43 2011 From: tom+nanog at oneshoeco.com (Tom Lanyon) Date: Fri, 2 Dec 2011 10:56:43 +1030 Subject: Link local for P-t-P links? (Was: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?) In-Reply-To: References: Message-ID: <3C80F0BD-1B61-4664-8B7E-F29C90C664CF@oneshoeco.com> Hi, On 01/12/2011, at 12:45 PM, Mike Jones wrote: > Link-Local? > [snip] > Am I a complete idiot missing some obvious major issues with link > locals, or am i just the only one not thinking IPv4-think? Opinions? > :) In a DC / hosting provider context, we're doing this. We started out assigning all of our PtP links (where we had /31s in the IPv4 world) IPv6 /64s and addressing using ::1 and ::2 with /127 masks from these /64s (to address potential ND table overflow concerns), but have now settled on using automatic link-local addresses instead. Our IGP propagates the routers' /128 loopbacks and these are used for routing user traffic. Having the IGP table only contain the /128 loopbacks, and none of the PtP networks is nice. :) On 01/12/2011, at 12:52 PM, Ray Soucy wrote: > I for one get really irritated when my traceroutes and pings are > broken and I need to troubleshoot things. ;-) But I guess something > has to give. You don't have to give up working traceroute / ping to use link-local on your PtPs. Our traffic routes through globally reachable router loopbacks which looks pretty in traceroutes, are pingable and doesn't break PMTUD. Tom From John_Brzozowski at Cable.Comcast.com Thu Dec 1 20:33:43 2011 From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John) Date: Fri, 2 Dec 2011 02:33:43 +0000 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: Message-ID: See below. On 12/1/11 5:11 AM, "Dmitry Cherkasov" wrote: >John, > >Due to your note I carefully read again Cable Labs specs and found >that really SLAAC is not prohibited. According to CM-SP-MULPIv3.0: [jjmb] I was part of the team that wrote IPv6 for DOCSIS, so I know the history well. ;) > >* If the M bit in the RA is set to 1, the CM (cable modem) MUST use >DHCPv6 ...; >* If there are no prefix information options in the RA, the CM MUST >NOT perform SLAAC; [jjmb] even if there are PIOs and the A bit is set to 0, the CM will not/must not perform SLAAC. >* If the RA contains a prefix advertisement with the A bit set to 0, >the CM MUST NOT perform SLAAC on that prefix. [jjmb] yes, see above. > >That means that if M bit in the RA is set to 0 and RA contains a >prefix advertisement with the A bit set to 1 nothing prevents CM from >SLAAC. [jjmb] correct. >And if so we probably better reserve /64 per network just in case we >may use SLAAC in it in the future. While we do not use SLAAC we can >shorten the range of actually used IPv6 addresses by using longer then >/64 prefix. [jjmb] I suppose, again not sure why you would want to take this route. This also assumes no PIOs in the RA. Please note there are other operational reason why SLAAC is not a truly deployable alternative. We can discuss off list if you are interested. > >You are completely right that prefix delegation enforce DHCPv6 so >SLAAC mentioned above can be used only for CMs, not for CPE. [jjmb] similar to cable modems, CPEs that only request or require IA_NA could conceivably use SLAAC. Same caveat and comments as above. > >Just a note: as far as I can see available DOCSIS 3.0 CMTSes do not >support the ability of SLAAC for CMs currently (checked Casa and Cisco >uBR10K). [jjmb] I am sure you make it work on at least one of the above. :) > > >Dmitry Cherkasov > > > >2011/11/30 Brzozowski, John : >> Technically this is not true. SLAAC is not prohibited, it does come >>with >> side affects that complicate the deployment of IPv6. It is technically >> feasible to use SLAAC, it is just not practical in most cases. >> >> Stateful DHCPv6 is the preferred mechanism for address and configuration >> assignment. Prefix delegation requires the use of stateful DHCPv6 in >> DOCSIS networks. >> >> John >> ========================================= >> John Jason Brzozowski >> Comcast Cable >> e) mailto:john_brzozowski at cable.comcast.com >> o) 609-377-6594 >> m) 484-962-0060 >> w) http://www.comcast6.net >> ========================================= >> >> >> >> >> On 11/29/11 7:09 AM, "Dmitry Cherkasov" wrote: >> >>>Steven, >>> >>>SLAAC is prohibited for using in DOCSIS networks, router >>>advertisements that allow SLAAC must be ignored by end-devices, >>>therefore DHCPv6 is the only way of configuring (if not talking about >>>statical assignment). I have seen at least Windows7 handling this >>>properly in its default configuration: it starts DHCPv6 negotiation >>>instead of auto-configuration. >>> >>>Dmitry Cherkasov >>> >>> >>> >>>2011/11/29 Steven Bellovin : >>>> >>>> On Nov 28, 2011, at 4:51 52PM, Owen DeLong wrote: >>>> >>>>> >>>>> On Nov 28, 2011, at 7:29 AM, Ray Soucy wrote: >>>>> >>>>>> It's a good practice to reserve a 64-bit prefix for each network. >>>>>> That's a good general rule. For point to point or link networks you >>>>>> can use something as small as a 126-bit prefix (we do). >>>>>> >>>>> >>>>> Technically, absent buggy {firm,soft}ware, you can use a /127. >>>>>There's >>>>>no >>>>> actual benefit to doing anything longer than a /64 unless you have >>>>> buggy *ware (ping pong attacks only work against buggy *ware), >>>>> and there can be some advantages to choosing addresses other than >>>>> ::1 and ::2 in some cases. If you're letting outside packets target >>>>>your >>>>> point-to-point links, you have bigger problems than neighbor table >>>>> attacks. If not, then the neighbor table attack is a bit of a >>>>>red-herring. >>>>> >>>> >>>> The context is DOCSIS, i.e., primarily residential cable modem users, >>>>and >>>> the cable company ISPs do not want to spend time on customer care and >>>> hand-holding. How are most v6 machines configured by default? That >>>>is, >>>> what did Microsoft do for Windows Vista and Windows 7? If they're set >>>>for >>>> stateless autoconfig, I strongly suspect that most ISPs will want to >>>>stick >>>> with that and hand out /64s to each network. (That's apart from the >>>>larger >>>> question of why they should want to do anything else...) >>>> >>>> >>>> --Steve Bellovin, https://www.cs.columbia.edu/~smb >>>> >>>> >>>> >>>> >>>> >>>> >>> >> From malayter at gmail.com Thu Dec 1 20:57:58 2011 From: malayter at gmail.com (Ryan Malayter) Date: Thu, 1 Dec 2011 18:57:58 -0800 (PST) Subject: Broadband providers in downtown Chicago In-Reply-To: References: Message-ID: <681d5b9d-cc1d-4238-9972-73f381b8f282@w1g2000vba.googlegroups.com> On Dec 1, 11:30?am, Ishmael Rufus wrote: > Our company is in a building at 200 w. Monroe and we have difficulty > finding an internet service provider that could at least provide > 1Mbps+ Upload bandwidth that is not Cogent Communications. > > Is it really this difficult finding a decent internet service provider > in downtown Chicago? No, it isn't. Unless your building management has an exclusive deal with Cogent. We have our choice of basically every national Tier-1 and all the larger regional players around the corner on Monroe. From wayne at staff.msen.com Thu Dec 1 22:04:23 2011 From: wayne at staff.msen.com (Michael R. Wayne) Date: Thu, 1 Dec 2011 23:04:23 -0500 Subject: IP addresses are now assets Message-ID: <20111202040423.GL1397@manor.msen.com> >From http://www.detnews.com/article/20111201/BIZ/112010483/1361/Borders-selling-Internet-addresses-for-$786-000 Borders selling Internet addresses for $786,000 Bill Rochelle/ Bloomberg News Borders Group Inc., the liquidated Ann Arbor-based bookseller, will generate $786,000 by selling Internet addresses, thanks to the current shortage. In September, Borders was authorized to sell most of the intellectual property to Barnes & Noble Inc. for $13.9 million. Borders' block of 65,536 IPv4 Internet protocol numbers weren't sold. After negotiating with multiple prospective buyers, Cerner Corp. agreed to buy the Internet addresses for $12 each. Other bids were as low as $1.50 each, according to a bankruptcy court filing. The sale to Cerner is scheduled for approval at the Dec. 20 hearing where Borders also hopes the bankruptcy court will confirm the liquidating Chapter 11 plan. The plan distributes assets in the order of priority called for in bankruptcy law. The disclosure statement says unsecured creditors with $812 million to $850 million in claims can expect to recover from 4 percent to 10 percent. The projected recovery doesn't include proceeds from lawsuits. Borders completed liquidating the remaining stores in September and separately sold store leases and intellectual property. Borders had 642 stores on entering bankruptcy in February and was operating 399 when the final liquidations began. It listed assets of $1.28 billion and liabilities totaling $1.29 billion. From jcurran at arin.net Thu Dec 1 23:20:39 2011 From: jcurran at arin.net (John Curran) Date: Fri, 2 Dec 2011 05:20:39 +0000 Subject: IP addresses are now assets Message-ID: Wayne - Your subject line (IP addresses are now assets) could mislead folks, so I'd advise waiting to review the actual sale order once approved by the court before making summary conclusions. ARIN holds that IP address space is not property but is managed as a public resource. Address holders may have certain rights (such as the right to be the registrant of the address block, the right to transfer the registration, etc.) but these rights intersect with additional rights to the same address blocks which are held by the community (such as the right of visibility to the public portion of registrations). The registry policies (set by the community via open and transparent processes) govern the intersection and application of these rights. For this reason, ARIN works with parties transferring their rights in IP address space to make sure that the documents reflect that sales of rights are subject to the transfer policies in the region, including in this particular case. A party may transfer their rights to IP addresses, and such rights may have value to an estate, but this does not make the IP addresses "property" per se. Thanks! /John John Curran President and CEO ARIN From paul at paulgraydon.co.uk Thu Dec 1 23:55:56 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Thu, 01 Dec 2011 19:55:56 -1000 Subject: IP addresses are now assets In-Reply-To: References: Message-ID: <4ED8686C.6020803@paulgraydon.co.uk> On 12/1/2011 7:20 PM, John Curran wrote: > Wayne - > > Your subject line (IP addresses are now assets) could mislead folks, > so I'd advise waiting to review the actual sale order once approved by > the court before making summary conclusions. > > ARIN holds that IP address space is not property but is managed as a > public resource. Address holders may have certain rights (such as the > right to be the registrant of the address block, the right to transfer the > registration, etc.) but these rights intersect with additional rights to the > same address blocks which are held by the community (such as the right > of visibility to the public portion of registrations). The registry policies > (set by the community via open and transparent processes) govern the > intersection and application of these rights. > > For this reason, ARIN works with parties transferring their rights in IP > address space to make sure that the documents reflect that sales of > rights are subject to the transfer policies in the region, including in this > particular case. A party may transfer their rights to IP addresses, and > such rights may have value to an estate, but this does not make the > IP addresses "property" per se. > > Thanks! > /John > Why'd you have to spoil the fun? You're supposed to wait a few days, let the pointless righteous fury build up and then step in and try to do the firefighting thing. It's must have been all but a month since the last time this flared up, it's surely about time it flared up again? Wouldn't want anyone to miss out on the fun ;) Paul From Valdis.Kletnieks at vt.edu Fri Dec 2 01:48:31 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 02 Dec 2011 02:48:31 -0500 Subject: IP addresses are now assets In-Reply-To: Your message of "Fri, 02 Dec 2011 05:20:39 GMT." References: Message-ID: <44762.1322812111@turing-police.cc.vt.edu> On Fri, 02 Dec 2011 05:20:39 GMT, John Curran said: > ARIN holds that IP address space is not property but is managed as a > public resource. Address holders may have certain rights (such as the > right to be the registrant of the address block, the right to transfer the > registration, etc.) but these rights intersect with additional rights to the > same address blocks which are held by the community (such as the right > of visibility to the public portion of registrations). The registry policies > (set by the community via open and transparent processes) govern the > intersection and application of these rights. Would it be correct to summarize the ARIN position as "It's murkier than Cerner makes it out to be, and some lawyers are gonna get stinking filthy rich litigating this one"? :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From rjs at rob.sh Fri Dec 2 01:55:29 2011 From: rjs at rob.sh (Rob Shakir) Date: Fri, 2 Dec 2011 07:55:29 +0000 Subject: bgp update destroying transit on redback routers ? In-Reply-To: References: Message-ID: <37A1C204-8DB0-4452-A7D5-9C5A12542E03@rob.sh> On 1 Dec 2011, at 23:04, Warren Kumari wrote: > tp://tools.ietf.org/html/draft-wkumari-idr-as0-01 has been replaced with http://tools.ietf.org/html/draft-ietf-idr-as0-00 -- which does include it. Whilst we are on the subject of relevant drafts - it should be noted that situations like this provide significant motivation for the work presented in both [0] and [1] (full disclosure: I am the editor of [0]). I'd really encourage the community to review both documents and comment on whether they provide benefit in this problem space. I'm very happy to take feedback on the requirements draft [0] particularly - since this aimed to describe this problem from an operator perspective. Essentially, until something is done in a more general sense in the protocol, we will continue to see threads liked this one popping up every few months. I'll post a further update to the nanog list when we have requested a working group last-call on the requirements draft asking for reviews. Thanks for your time, r. [0]: http://tools.ietf.org/html/draft-ietf-grow-ops-reqs-for-bgp-error-handling-02 [1]: http://tools.ietf.org/html/draft-ietf-idr-error-handling-00 From eugen at leitl.org Fri Dec 2 03:18:12 2011 From: eugen at leitl.org (Eugen Leitl) Date: Fri, 2 Dec 2011 10:18:12 +0100 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: <20111201104722.F5796A6A@resin09.mta.everyone.net> References: <20111201104722.F5796A6A@resin09.mta.everyone.net> Message-ID: <20111202091812.GG31847@leitl.org> On Thu, Dec 01, 2011 at 10:47:22AM -0800, Scott Weeks wrote: > In our industry, especially with all the tools we have today, it would seem > that telecommuting would be more accepted, but it's not and I don't understand > why. People are social primates, alphas like access to nonverbal cues for reading and control of their supposed underlings. Same reasons for concentrations in big cities: interaction density is higher for business dinners while underlings are not too far away. Net ops are more like hunter-gatherers than anything, so there's considerable culture clash. From rs at seastrom.com Fri Dec 2 05:52:44 2011 From: rs at seastrom.com (Robert E. Seastrom) Date: Fri, 02 Dec 2011 06:52:44 -0500 Subject: IP addresses are now assets In-Reply-To: <44762.1322812111@turing-police.cc.vt.edu> (Valdis Kletnieks's message of "Fri, 02 Dec 2011 02:48:31 -0500") References: <44762.1322812111@turing-police.cc.vt.edu> Message-ID: <86r50n42cz.fsf@seastrom.com> Valdis.Kletnieks at vt.edu writes: > Would it be correct to summarize the ARIN position as "It's murkier than Cerner > makes it out to be, and some lawyers are gonna get stinking filthy rich > litigating this one"? > > :) In any litigation, Counsel always wins. I often remind myself that there's still time to go to law school. :-) -r From t.dahm at resolution.de Fri Dec 2 06:25:41 2011 From: t.dahm at resolution.de (Thorsten Dahm) Date: Fri, 02 Dec 2011 12:25:41 +0000 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: <201112011635.27951.david@davidradcliffe.org> References: <20111201104722.F5796A6A@resin09.mta.everyone.net> <201112011635.27951.david@davidradcliffe.org> Message-ID: <4ED8C3C5.2010404@resolution.de> Am 12/1/11 9:35 PM, schrieb David Radcliffe: > Since I like to work and code (I spend 10 hours a day on the computer at the > office, think about work related stuff in the shower, and often write Perl code > at home to deal with various household tasks) I work quite well at home. > There are more distractions at the office and my productivity is greater in my > home computer room during those times I have to put in some extra for the > office. The downside of this is that you are not around in the office in case someone wants to talk to you. I often end up with guys from our operations team or other teams stopping at my desk and ask questions. Or guys who want to have a quick chat about a problem and want to ask for an advice or idea. Or people who want to learn Perl and have a question that you can answer in 30 seconds. Yes, I know, they can call you, or send an Email, but nothing beats the good old "Let's go for a coffee, I'd like to ask you a question". cheers, Thorsten From eugen at leitl.org Fri Dec 2 06:34:07 2011 From: eugen at leitl.org (Eugen Leitl) Date: Fri, 2 Dec 2011 13:34:07 +0100 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: <4ED8C3C5.2010404@resolution.de> References: <20111201104722.F5796A6A@resin09.mta.everyone.net> <201112011635.27951.david@davidradcliffe.org> <4ED8C3C5.2010404@resolution.de> Message-ID: <20111202123407.GK31847@leitl.org> On Fri, Dec 02, 2011 at 12:25:41PM +0000, Thorsten Dahm wrote: > Yes, I know, they can call you, or send an Email, but nothing beats the > good old "Let's go for a coffee, I'd like to ask you a question". Some people just put up a dedicated netbook with a permanent video/audio link (can be a problem with limited residential upstram) for a poor man's telepresence. What could potentially work even better is to build a virtual office using e.g. OpenQwaq http://code.google.com/p/openqwaq/ (not sure the codes are fully done in the open sourced version yet, but they'll be there in a few months). From leigh.porter at ukbroadband.com Fri Dec 2 06:39:37 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Fri, 2 Dec 2011 12:39:37 +0000 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: <4ED8C3C5.2010404@resolution.de> References: <20111201104722.F5796A6A@resin09.mta.everyone.net> <201112011635.27951.david@davidradcliffe.org> <4ED8C3C5.2010404@resolution.de> Message-ID: > -----Original Message----- > From: Thorsten Dahm [mailto:t.dahm at resolution.de] > Sent: 02 December 2011 12:28 > To: nanog at nanog.org > Subject: Re: Looking for a Tier 1 ISP Mentor for career advice. > > Am 12/1/11 9:35 PM, schrieb David Radcliffe: > > Since I like to work and code (I spend 10 hours a day on the computer > at the > > office, think about work related stuff in the shower, and often write > Perl code > > at home to deal with various household tasks) I work quite well at > home. > > There are more distractions at the office and my productivity is > greater in my > > home computer room during those times I have to put in some extra for > the > > office. > > The downside of this is that you are not around in the office in case > someone wants to talk to you. I often end up with guys from our > operations team or other teams stopping at my desk and ask questions. > Or > guys who want to have a quick chat about a problem and want to ask for > an advice or idea. Or people who want to learn Perl and have a question > that you can answer in 30 seconds. And it means you do not get 'noticed' as much. I work from home when I have a task to get done that benefits from not having to talk to people. A specific document that needs completing or some more PowerPoint waffle for a pointless meeting with people who won't get it anyway. Other than that, I try to be in the office. -- Leigh ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From jcurran at arin.net Fri Dec 2 06:42:03 2011 From: jcurran at arin.net (John Curran) Date: Fri, 2 Dec 2011 12:42:03 +0000 Subject: IP addresses are now assets In-Reply-To: <44762.1322812111@turing-police.cc.vt.edu> References: <44762.1322812111@turing-police.cc.vt.edu> Message-ID: On Dec 2, 2011, at 2:48 AM, wrote: > Would it be correct to summarize the ARIN position as "It's murkier than Cerner > makes it out to be, and some lawyers are gonna get stinking filthy rich > litigating this one"? It's pretty simple: you can write a contract to transfer IP addresses in accordance with policy, and we are now seeing most parties come to us in advance either to prequalify or make the sale conditional on approval. FYI, /John John Curran President and CEO ARIN From joly at punkcast.com Fri Dec 2 06:57:26 2011 From: joly at punkcast.com (Joly MacFie) Date: Fri, 2 Dec 2011 07:57:26 -0500 Subject: IP addresses are now assets In-Reply-To: References: <44762.1322812111@turing-police.cc.vt.edu> Message-ID: Hi John, I'm sorry to be thick, but can you explain "right of visibility to the public portion of registrations" a little further?. Under what circumstances might ARIN deny approval? j On Fri, Dec 2, 2011 at 7:42 AM, John Curran wrote: > On Dec 2, 2011, at 2:48 AM, wrote: > > > Would it be correct to summarize the ARIN position as "It's murkier than > Cerner > > makes it out to be, and some lawyers are gonna get stinking filthy rich > > litigating this one"? > > It's pretty simple: you can write a contract to transfer IP > addresses in accordance with policy, and we are now seeing > most parties come to us in advance either to prequalify or > make the sale conditional on approval. > > FYI, > /John > > John Curran > President and CEO > ARIN > > > -- --------------------------------------------------------------- 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 dbg at net-geek.org Fri Dec 2 07:12:48 2011 From: dbg at net-geek.org (Daniel Ginsburg) Date: Fri, 2 Dec 2011 17:12:48 +0400 Subject: draft-ietf-idr-as0-00 (bgp update destroying transit on redback routers ?) In-Reply-To: <0ED867EB33AB2B45AAB470D5A64CDBF6181C25624E@EUSAACMS0701.eamcs.ericsson.se> References: <0ED867EB33AB2B45AAB470D5A64CDBF6181C25624E@EUSAACMS0701.eamcs.ericsson.se> Message-ID: <26E0D18F-F80E-4EF0-B49A-6FF59957B0C3@net-geek.org> Hi, This is true that "no-aggregator-id" knob zeroes out the AGGREGATOR attribute. The knob, as far as I was able to find out, dates back to gated and there's a reason why it was introduced - it helps to avoid unnecessary updates. Assume that an aggregate route is generated by two (or more) speakers in the network. These two aggregates differ only in AGGREGATOR attribute. One of the aggregates is preferred within the network (due to IGP metric, for instance, or any other reasons) and is announced out. Now if something changes within the network and the other instance of the aggregate becomes preferred, the network has to issue an outward update different from the previous only in AGGREGATOR attribute, which is completely superfluous. If the network employs the "no-aggregator-id" knob to zero out the AGGREGATOR attribute, both instances of the aggregate route are completely equivalent, and no redundant outward updates have to be send if one instance becomes better than another due to some internal event, which nobody in the Internet cares about. In other words, the "no-aggregator-id" knob has valid operational reasons to be used. And, IMHO, the draft-ietf-idr-as0-00 should not prohibit AS0 in AGGREGATOR attribute. On 02.12.2011, at 1:56, Jeff Tantsura wrote: > Hi, > > Let me take it over from now on, I'm the IP Routing/MPLS Product Manager at Ericsson responsible for all routing protocols. > There's nothing wrong in checking ASN in AGGREGATOR, we don't really want see ASN 0 anywhere, that's how draft-wkumari-idr-as0 (draft-ietf-idr-as0-00) came into the worlds. > > To my knowledge - the only vendor which allows changing ASN in AGGREGATOR is Juniper, see "no-aggregator-id", in the past I've tried to talk to Yakov about it, without any results though. > So for those who have it configured - please rethink whether you really need it. > > As for SEOS - understanding that this badly affects our customers and not having draft-ietf-idr-error-handling fully implemented yet, we will temporarily disable this check in our code. > Patch will be made available. > > Please contact me for any further clarifications. > > Regards, > Jeff > > P.S. Warren has recently included AGGREGATOR in the draft, please see > > 2. Behavior > This document specifies that a BGP speaker MUST NOT originate or > propagate a route with an AS number of zero. If a BGP speaker > receives a route which has an AS number of zero in the AS_PATH (or > AS4_PATH) attribute, it SHOULD be logged and treated as a WITHDRAW. > This same behavior applies to routes containing zero as the > Aggregator or AS4 Aggregator. > From jcurran at arin.net Fri Dec 2 07:18:45 2011 From: jcurran at arin.net (John Curran) Date: Fri, 2 Dec 2011 13:18:45 +0000 Subject: IP addresses are now assets In-Reply-To: References: <44762.1322812111@turing-police.cc.vt.edu> Message-ID: <236167AF-4DEB-48D5-A7ED-ED0A1F0DEEA5@arin.net> On Dec 2, 2011, at 7:57 AM, Joly MacFie wrote: > Hi John, > > I'm sorry to be thick, but can you explain "right of visibility to the > public portion of registrations" a little further?. > > Under what circumstances might ARIN deny approval? Joly - Requests are processed according the transfer policies . If a request doesn't meet the transfer policy (e.g. the sale is not to an actual entity that has an operational need for address space or it is more space than needed for the next twelve months), then it will be denied. If you think that ARIN should operate under different policies in the management of the IP address space in the region, you can submit a policy proposal to change the policy as desired: Thanks! /John John Curran President and CEO ARIN From leigh.porter at ukbroadband.com Fri Dec 2 07:23:49 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Fri, 2 Dec 2011 13:23:49 +0000 Subject: IP addresses are now assets In-Reply-To: <236167AF-4DEB-48D5-A7ED-ED0A1F0DEEA5@arin.net> References: <44762.1322812111@turing-police.cc.vt.edu> <236167AF-4DEB-48D5-A7ED-ED0A1F0DEEA5@arin.net> Message-ID: > -----Original Message----- > From: John Curran [mailto:jcurran at arin.net] > Joly - > > Requests are processed according the transfer policies > . If a > request doesn't meet the transfer policy (e.g. the sale > is not to an actual entity that has an operational need > for address space or it is more space than needed for the > next twelve months), then it will be denied. Presumably organisations will check this and fake the appropriate paperwork and come up with some plausible excuse for requiring the space within the next 12 months BEFORE they part with their cash. It would be most amusing for somebody to buy space, hand over the money and then have ARIN deny the transfer. So I do wonder, how is this policy is being enforced and will ARIN be investigating this current news item? -- Leigh Porter ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From jgreco at ns.sol.net Fri Dec 2 07:16:20 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 2 Dec 2011 07:16:20 -0600 (CST) Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: <4ED8C3C5.2010404@resolution.de> Message-ID: <201112021316.pB2DGKGm014444@aurora.sol.net> > Am 12/1/11 9:35 PM, schrieb David Radcliffe: > > Since I like to work and code (I spend 10 hours a day on the computer at the > > office, think about work related stuff in the shower, and often write Perl code > > at home to deal with various household tasks) I work quite well at home. > > There are more distractions at the office and my productivity is greater in my > > home computer room during those times I have to put in some extra for the > > office. > > The downside of this is that you are not around in the office in case > someone wants to talk to you. I often end up with guys from our > operations team or other teams stopping at my desk and ask questions. Or > guys who want to have a quick chat about a problem and want to ask for > an advice or idea. Or people who want to learn Perl and have a question > that you can answer in 30 seconds. > > Yes, I know, they can call you, or send an Email, but nothing beats the > good old "Let's go for a coffee, I'd like to ask you a question". Which really stops being practical once you exceed (approx) one building in size. It was interesting during the early days to note that there were certain people who did a lot of their interaction on IRC, even when in the office, even when sitting a few cubes away from each other sometimes. It definitely enabled telepresence - obviously not as good as "being there", but it was funny every now and then when you'd go looking for that person and find out they were out today at a different office, or telecommuting. It seems to me that we've not been as successful as we might at this whole telecommuting thing, because people - especially at small companies - ARE used to being able to grab a coffee, and there's a reluctance to lose that. ... 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 randy at psg.com Fri Dec 2 08:02:48 2011 From: randy at psg.com (Randy Bush) Date: Fri, 02 Dec 2011 23:02:48 +0900 Subject: bgp update destroying transit on redback routers ? In-Reply-To: References: Message-ID: >> >> one of the reasons the above was written... > That does not include when ASN=0 is used in the aggregator attribute. > Could you add that? next rev From gary.buhrmaster at gmail.com Fri Dec 2 08:08:03 2011 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Fri, 2 Dec 2011 06:08:03 -0800 Subject: IP addresses are now assets In-Reply-To: <86r50n42cz.fsf@seastrom.com> References: <44762.1322812111@turing-police.cc.vt.edu> <86r50n42cz.fsf@seastrom.com> Message-ID: On Fri, Dec 2, 2011 at 03:52, Robert E. Seastrom wrote: .... > In any litigation, Counsel always wins. ?I often remind myself that > there's still time to go to law school. ?:-) It may be too late. The glory days of getting a JD and then racking in the money are apparently over. I remember reading recently (in the NYTimes?) that newly minted lawyers are having a hard time finding employment, as the customers of the law firms are pushing back on the ever higher fees, and the firms are responding by a combination of outsourcing some research, and using non-lawyers for other work, reducing the demand for (and hiring of) new lawyers. Exceptions noted for the Harvard grads due to the OBN. From bicknell at ufp.org Fri Dec 2 08:11:51 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 2 Dec 2011 06:11:51 -0800 Subject: IP addresses are now assets In-Reply-To: <20111202040423.GL1397@manor.msen.com> References: <20111202040423.GL1397@manor.msen.com> Message-ID: <20111202141151.GA20138@ussenterprise.ufp.org> In a message written on Thu, Dec 01, 2011 at 11:04:23PM -0500, Michael R. Wayne wrote: > After negotiating with multiple prospective buyers, Cerner Corp. > agreed to buy the Internet addresses for $12 each. Other bids were > as low as $1.50 each, according to a bankruptcy court filing. Someone should tell Cerner Corp you can still get them for free, and thus they overpaid by oh, $12 an address! -- 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 snar at snar.spb.ru Fri Dec 2 08:35:54 2011 From: snar at snar.spb.ru (Alexandre Snarskii) Date: Fri, 2 Dec 2011 18:35:54 +0400 Subject: bgp update destroying transit on redback routers ? In-Reply-To: <0ED867EB33AB2B45AAB470D5A64CDBF6181C25624E@EUSAACMS0701.eamcs.ericsson.se> References: <0ED867EB33AB2B45AAB470D5A64CDBF6181C25624E@EUSAACMS0701.eamcs.ericsson.se> Message-ID: <20111202143554.GA66539@snar.spb.ru> On Thu, Dec 01, 2011 at 04:56:43PM -0500, Jeff Tantsura wrote: > Hi, > > Let me take it over from now on, I'm the IP Routing/MPLS Product Manager > at Ericsson responsible for all routing protocols. > There's nothing wrong in checking ASN in AGGREGATOR, we don't really want > see ASN 0 anywhere, that's how draft-wkumari-idr-as0 (draft-ietf-idr-as0-00) > came into the worlds. This draft says that If a BGP speaker receives a route which has an AS number of zero in the AS_PATH (or AS4_PATH) attribute, it SHOULD be logged and treated as a WITHDRAW. This same behavior applies to routes containing zero as the Aggregator or AS4 Aggregator. but observed behaviour was more like following: If a BGP speaker receives [bad route] it MUST close session immediately with NOTIFICATION Error Code 'Update Message Error' and subcode 'Error with optional attribute'. -- In theory, there is no difference between theory and practice. But, in practice, there is. From mtinka at globaltransit.net Fri Dec 2 08:57:42 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Fri, 2 Dec 2011 22:57:42 +0800 Subject: ATT GigE issue on 11/19 in Kansas City In-Reply-To: <922ACC42D498884AA02B3565688AF995340255F31F@USEXMBS01.mwd.h2o> References: <20111130021700.BDLG8.157079.root@hrndva-web07-z01> <7BE0B126-8F07-43C5-8081-1AC0CFB0DF0F@gmail.com> <922ACC42D498884AA02B3565688AF995340255F31F@USEXMBS01.mwd.h2o> Message-ID: <201112022257.47727.mtinka@globaltransit.net> On Thursday, December 01, 2011 02:56:37 AM Holmes,David A wrote: > What I have seen lately with telco's building and > operating Metro Ethernet Forum (MEF) based Ethernet > networks is that relatively inexperienced telco staff > are in charge of configuring and operating the networks, > where telco operational staff are unaware of layer 2 > Ethernet network nuances, nuances that in an Enterprise > environment network engineers must know, or else. We use RANCID here, quite heavily, to help guide provisioning engineers so they are better prepared for the future, and actually understand what it is they are configuring. Pre-provisioning training is all good and well, but hands-on experience always has the chance of "going the other way". While RANCID is after-the-fact, it's a great tool for refining what the folk on the ground know. It certainly has helped us a great deal, over the years. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From ryan at u13.net Fri Dec 2 09:02:56 2011 From: ryan at u13.net (Ryan Rawdon) Date: Fri, 2 Dec 2011 10:02:56 -0500 Subject: Recent DNS attacks from China? In-Reply-To: References: <02F7D865-8803-4662-818C-9332163730F1@taranta.discpro.org> <1322677461.68582.YahooMailNeo@web162104.mail.bf1.yahoo.com> <4288131ED5E3024C9CD4782CECCAD2C70B53079D@LMC-MAIL2.exempla.org> <3454EA54E9F18A4993A4B99F07A01D9D014D53F62FC5@W2055.kpnnl.local> Message-ID: <38E75725-9FD3-4468-9425-2B5B19C684C9@u13.net> On Nov 30, 2011, at 3:12 PM, Drew Weaver wrote: > > -----Original Message----- > From: Rob.Vercouteren at kpn.com [mailto:Rob.Vercouteren at kpn.com] > Sent: Wednesday, November 30, 2011 3:05 PM > To: MatlockK at exempla.org; richard.barnes at gmail.com; andrew.wallace at rocketmail.com > Cc: nanog at nanog.org; leland at taranta.discpro.org > Subject: RE: Recent DNS attacks from China? > > Yes it is, but the problem is that our servers are "attacking" the so called source address. All the answers are going back to the "source". It is huge amplification attacks. (some sort of smurf if you want) The ip addresses are spoofed (We did a capture and saw all different ttl's so coming from behind different hops) And yes we saw the ANY queries for all the domains. > > I still wonder how it is still possible that ip addresses can be spoofed nowadays We're a smaller shop and started receiving these queries last night, roughly 1000 queries per minute or less. We're seeing that the source (victim) addresses are changing every few minutes, the TTLs vary within a given source address, and while most of the source/victim addresses have been Chinese we are seeing a few which are not, such as 74.125.90.83 (Google). The queries are coming in to ns1.traffiq.com (perhaps ns2 also, I haven't checked) and are for traffiq.com/ANY which unfortunately gives a 492 byte response. > > ================= > > Rob, > > Transit providers can bill for the denial of service traffic and they claim it's too expensive to run URPF because of the extra lookup. > > -Drew > From hannigan at gmail.com Fri Dec 2 09:16:55 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Fri, 2 Dec 2011 10:16:55 -0500 Subject: IP addresses are now assets In-Reply-To: References: <44762.1322812111@turing-police.cc.vt.edu> <236167AF-4DEB-48D5-A7ED-ED0A1F0DEEA5@arin.net> Message-ID: On Fri, Dec 2, 2011 at 8:23 AM, Leigh Porter wrote: > > >> -----Original Message----- >> From: John Curran [mailto:jcurran at arin.net] >> Joly - >> >> ? Requests are processed according the transfer policies >> ? . ?If a >> ? request doesn't meet the transfer policy (e.g. the sale >> ? is not to an actual entity that has an operational need >> ? for address space or it is more space than needed for the >> ? next twelve months), then it will be denied. > > > Presumably organisations will check this and fake the appropriate paperwork and come up with some plausible excuse for requiring the space within the next 12 months BEFORE they part with their cash. > > It would be most amusing for somebody to buy space, hand over the money and then have ARIN deny the transfer. > > So I do wonder, how is this policy is being enforced and will ARIN be investigating this current news item? > ARIN, on many occasions, has stated that they have no authority over legacy address space. They made this declaration in the Kamens/sex.com case. I haven't heard that anything has changed since then. Nortel/MSN was the first, big, public transaction. There have been others prior to Nortel. There will be more after Borders. Circuit City: http://www.slideshare.net/Streambank/offering-memo-ip-addresses-92111final Best. -M< From leland at taranta.discpro.org Fri Dec 2 09:17:22 2011 From: leland at taranta.discpro.org (Leland Vandervort) Date: Fri, 2 Dec 2011 16:17:22 +0100 Subject: Recent DNS attacks from China? In-Reply-To: <38E75725-9FD3-4468-9425-2B5B19C684C9@u13.net> References: <02F7D865-8803-4662-818C-9332163730F1@taranta.discpro.org> <1322677461.68582.YahooMailNeo@web162104.mail.bf1.yahoo.com> <4288131ED5E3024C9CD4782CECCAD2C70B53079D@LMC-MAIL2.exempla.org> <3454EA54E9F18A4993A4B99F07A01D9D014D53F62FC5@W2055.kpnnl.local> <38E75725-9FD3-4468-9425-2B5B19C684C9@u13.net> Message-ID: Yup.. they're all "ANY" requests. The varying TTLs indicates that they're most likely spoofed. We are also now seeing similar traffic from RFC1918 "source" addresses trying to ingress our network (but being stopped by our border filters). Looks like the kiddies are playing.... On 2 Dec 2011, at 16:02, Ryan Rawdon wrote: > > On Nov 30, 2011, at 3:12 PM, Drew Weaver wrote: > >> >> -----Original Message----- >> From: Rob.Vercouteren at kpn.com [mailto:Rob.Vercouteren at kpn.com] >> Sent: Wednesday, November 30, 2011 3:05 PM >> To: MatlockK at exempla.org; richard.barnes at gmail.com; andrew.wallace at rocketmail.com >> Cc: nanog at nanog.org; leland at taranta.discpro.org >> Subject: RE: Recent DNS attacks from China? >> >> Yes it is, but the problem is that our servers are "attacking" the so called source address. All the answers are going back to the "source". It is huge amplification attacks. (some sort of smurf if you want) The ip addresses are spoofed (We did a capture and saw all different ttl's so coming from behind different hops) And yes we saw the ANY queries for all the domains. >> >> I still wonder how it is still possible that ip addresses can be spoofed nowadays > > We're a smaller shop and started receiving these queries last night, roughly 1000 queries per minute or less. We're seeing that the source (victim) addresses are changing every few minutes, the TTLs vary within a given source address, and while most of the source/victim addresses have been Chinese we are seeing a few which are not, such as 74.125.90.83 (Google). The queries are coming in to ns1.traffiq.com (perhaps ns2 also, I haven't checked) and are for traffiq.com/ANY which unfortunately gives a 492 byte response. > > >> >> ================= >> >> Rob, >> >> Transit providers can bill for the denial of service traffic and they claim it's too expensive to run URPF because of the extra lookup. >> >> -Drew >> From david at davidradcliffe.org Fri Dec 2 09:20:19 2011 From: david at davidradcliffe.org (David Radcliffe) Date: Fri, 2 Dec 2011 10:20:19 -0500 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: <4ED8C3C5.2010404@resolution.de> References: <20111201104722.F5796A6A@resin09.mta.everyone.net> <201112011635.27951.david@davidradcliffe.org> <4ED8C3C5.2010404@resolution.de> Message-ID: <201112021020.20348.david@davidradcliffe.org> On Friday, December 02, 2011 07:25:41 AM Thorsten Dahm wrote: > Am 12/1/11 9:35 PM, schrieb David Radcliffe: > > Since I like to work and code (I spend 10 hours a day on the computer at > > the office, think about work related stuff in the shower, and often > > write Perl code at home to deal with various household tasks) I work > > quite well at home. There are more distractions at the office and my > > productivity is greater in my home computer room during those times I > > have to put in some extra for the office. > > The downside of this is that you are not around in the office in case > someone wants to talk to you. I often end up with guys from our > operations team or other teams stopping at my desk and ask questions. Or > guys who want to have a quick chat about a problem and want to ask for > an advice or idea. Or people who want to learn Perl and have a question > that you can answer in 30 seconds. > > Yes, I know, they can call you, or send an Email, but nothing beats the > good old "Let's go for a coffee, I'd like to ask you a question". > > cheers, > Thorsten Actually, that is the upside. Everywhere I have worked there are the people who will come to you before they even try to think of an answer. Your work gets interrupted because they did not have to send an email and wanted an excuse to socialize. It's much better to have a record (email) of most conversations especially when there are technical points which may be helpful to refer to in the future. F2F is fine when you are working on pushing your point as it is easier to create "presence" but 99% of all meetings and impromptu discussions in the office waste more time than provide any real benefit. I know plenty of people (my wife included) who disagree and feel there is great benefit in F2F but I contended they are just more comfortable with the old fashioned way they have always done things. There are people even today who will print and bring me an email to discuss the reported problem rather than forward information electronically. That is just because it is difficult for people to break their comfort molds to see a more productive method. I do not say it is easy. I understand people think the way they do things, the things which make them comfortable, seem best but in this case F2F is not best for everyone. If someone says to me "Let's go for a coffee, I'd like to ask you a question" what I hear is "Gee, you are not busy. Why are you getting a paycheck? Let's go talk shop and other non-work related stuff. I have a legitimate question and I want to socialize." I have a better idea, send email. If the question is too deep we can "meet" on the phone. I have a TeamSpeak server. Want to get together? Let's grab a beer after work or we can chat on TS while wandering through Left4Dead. F2F is for semi-work related activities. If you need to paint a picture we can bounce a diagram back and forth (please use open standards -- .odg, .dia, etc. -- and not proprietary -- .vsd) or we can draw simple stuff in Coccinella or OpenMeeting (I have servers set up). We can use email. We can use chat (I have Coccinella and a local server for our in-house and use Pidgin for AIM, Yahoo, MSN for my outside contacts). I have Logitech 9000 cameras so if you really, really want to see me I will configure my VoIP (Asterisk server at home) so we can look at each other. The whole "I have to be in your space in an office for work to be effective" is so nineteenth century. Seriously: "You talked to Ted the other day about the NetFlow based bandwidth billing project. What were the details and decisions? Can you remember the important points?" "No. But the discussion was electronic so I will pass you the email chain/chat log/etc." My dream is roll out of bed, make coffee, walk upstairs into my computer room and begin work. Deal with conversations via email/work the online job queue. Maybe attend a quarterly face-time meeting with the company. Maybe the people are nice. That would be cool. Maybe a monthly meeting at the home office in Atlanta on the 3rd Friday because the company provides tickets to Jazz at the High Museum. I can dream... -- David Radcliffe Network Engineer/Linux Specialist david at davidradcliffe.org www.davidradcliffe.org Nothing ever gets solved better with panic. If you do not know the answer, it is probably "42." From mtinka at globaltransit.net Fri Dec 2 09:19:28 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Fri, 2 Dec 2011 23:19:28 +0800 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: References: <193BA8AA-22C3-4682-954B-B0A25A762647@exonetric.com> Message-ID: <201112022319.32328.mtinka@globaltransit.net> On Thursday, December 01, 2011 08:19:51 AM Ray Soucy wrote: > There is a lot of talk about "buggy" systems that are > unable to handle prefixes longer than 64; but I've yet > to encounter one. I imagine if I did it would be > treated as a bug and fixed. So to the question of > supporting different prefix lengths: Yes. You should > support any valid IPv6 prefix length; it takes a few > extra lines of code in the beginning; but will save you > a lot of re-coding in the end. Exactly. /126's for point-to-points, and /112's for router LAN's here, 6 years and counting. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From jmaslak at antelope.net Fri Dec 2 09:23:56 2011 From: jmaslak at antelope.net (Joel Maslak) Date: Fri, 2 Dec 2011 08:23:56 -0700 Subject: Recent DNS attacks from China? In-Reply-To: References: <02F7D865-8803-4662-818C-9332163730F1@taranta.discpro.org> <1322677461.68582.YahooMailNeo@web162104.mail.bf1.yahoo.com> <4288131ED5E3024C9CD4782CECCAD2C70B53079D@LMC-MAIL2.exempla.org> <3454EA54E9F18A4993A4B99F07A01D9D014D53F62FC5@W2055.kpnnl.local> <38E75725-9FD3-4468-9425-2B5B19C684C9@u13.net> Message-ID: Other than being non-compliant, is an "ANY" query used by any major software? Could someone rate limit ANY responses to mitigate this particular issue? On Fri, Dec 2, 2011 at 8:17 AM, Leland Vandervort < leland at taranta.discpro.org> wrote: > Yup.. they're all "ANY" requests. The varying TTLs indicates that they're > most likely spoofed. We are also now seeing similar traffic from RFC1918 > "source" addresses trying to ingress our network (but being stopped by our > border filters). > > Looks like the kiddies are playing.... > > > On 2 Dec 2011, at 16:02, Ryan Rawdon wrote: > > > > > On Nov 30, 2011, at 3:12 PM, Drew Weaver wrote: > > > >> > >> -----Original Message----- > >> From: Rob.Vercouteren at kpn.com [mailto:Rob.Vercouteren at kpn.com] > >> Sent: Wednesday, November 30, 2011 3:05 PM > >> To: MatlockK at exempla.org; richard.barnes at gmail.com; > andrew.wallace at rocketmail.com > >> Cc: nanog at nanog.org; leland at taranta.discpro.org > >> Subject: RE: Recent DNS attacks from China? > >> > >> Yes it is, but the problem is that our servers are "attacking" the so > called source address. All the answers are going back to the "source". It > is huge amplification attacks. (some sort of smurf if you want) The ip > addresses are spoofed (We did a capture and saw all different ttl's so > coming from behind different hops) And yes we saw the ANY queries for all > the domains. > >> > >> I still wonder how it is still possible that ip addresses can be > spoofed nowadays > > > > We're a smaller shop and started receiving these queries last night, > roughly 1000 queries per minute or less. We're seeing that the source > (victim) addresses are changing every few minutes, the TTLs vary within a > given source address, and while most of the source/victim addresses have > been Chinese we are seeing a few which are not, such as 74.125.90.83 > (Google). The queries are coming in to ns1.traffiq.com (perhaps ns2 > also, I haven't checked) and are for traffiq.com/ANY which unfortunately > gives a 492 byte response. > > > > > >> > >> ================= > >> > >> Rob, > >> > >> Transit providers can bill for the denial of service traffic and they > claim it's too expensive to run URPF because of the extra lookup. > >> > >> -Drew > >> > > > From jcurran at arin.net Fri Dec 2 09:33:25 2011 From: jcurran at arin.net (John Curran) Date: Fri, 2 Dec 2011 15:33:25 +0000 Subject: IP addresses are now assets In-Reply-To: References: <44762.1322812111@turing-police.cc.vt.edu> <236167AF-4DEB-48D5-A7ED-ED0A1F0DEEA5@arin.net> Message-ID: <38B33D90-8E1E-46D5-B08E-6207CAD8E3B8@arin.net> On Dec 2, 2011, at 8:23 AM, Leigh Porter wrote: > So I do wonder, how is this policy is being enforced and will ARIN be investigating this current news item? Leigh - No investigation is needed, as I already noted the parties have sought out ARIN in advance. Note that original sales solicitation states: "Sale may be subject to compliance with certain requirements of the American Registry of Internet Numbers ("ARIN") and the court materials to date reflect this. FYI, /John John Curran President and CEO ARIN From cmadams at hiwaay.net Fri Dec 2 09:36:25 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 2 Dec 2011 09:36:25 -0600 Subject: Recent DNS attacks from China? In-Reply-To: References: <02F7D865-8803-4662-818C-9332163730F1@taranta.discpro.org> <1322677461.68582.YahooMailNeo@web162104.mail.bf1.yahoo.com> <4288131ED5E3024C9CD4782CECCAD2C70B53079D@LMC-MAIL2.exempla.org> <3454EA54E9F18A4993A4B99F07A01D9D014D53F62FC5@W2055.kpnnl.local> <38E75725-9FD3-4468-9425-2B5B19C684C9@u13.net> Message-ID: <20111202153625.GB3207@hiwaay.net> Once upon a time, Joel Maslak said: > Other than being non-compliant, is an "ANY" query used by any major > software? Could someone rate limit ANY responses to mitigate this > particular issue? I believe qmail still uses ANY lookups. -- 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 Dec 2 09:37:08 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 2 Dec 2011 07:37:08 -0800 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: <4ED8C3C5.2010404@resolution.de> References: <20111201104722.F5796A6A@resin09.mta.everyone.net> <201112011635.27951.david@davidradcliffe.org> <4ED8C3C5.2010404@resolution.de> Message-ID: <20111202153708.GA23268@ussenterprise.ufp.org> In a message written on Fri, Dec 02, 2011 at 12:25:41PM +0000, Thorsten Dahm wrote: > The downside of this is that you are not around in the office in case > someone wants to talk to you. I often end up with guys from our > operations team or other teams stopping at my desk and ask questions. Or > guys who want to have a quick chat about a problem and want to ask for > an advice or idea. Or people who want to learn Perl and have a question > that you can answer in 30 seconds. I've both delt with remote employees and been a telecommuter. After those experiences, and reading a few books I've decided the hardest thing about having successful telecommuters is dealing with the folks in the office. Telecommuters quickly turn to technology, they want to video-chat with collegues. Are eager to pick up the phone and talk. They reach out (generally). It's the folks in the office that are reluctant. They don't see the point of figuring out how the video chat software works, of setting their status to indicate what they are doing, and so on. The "water cooler" conversations can be moved to Skype, FaceTime, Google Hangouts, or any number of other solutions, but it requires everyone to be in that mindset. If you have telecommuters _everyone_ in the office should be forced to work from home at least 2 weeks a year, including the manager. It's only from that experience you learn to deal with your telecommuting co-workers in a way that raises everyone's productivity. Once over that hump there are huge rewards to having telecommuters. You can pay lower salaries as people can live in cheaper locations. People in multiple timezones provide better natural coverage. People are much more willing to do off hour work when they can roll out of bed at 5AM and be working at 5:05 in their PJ's, rather than getting up at 4 and getting dressed to drive in and do the work. -- 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 Rob.Vercouteren at kpn.com Fri Dec 2 09:40:52 2011 From: Rob.Vercouteren at kpn.com (Rob.Vercouteren at kpn.com) Date: Fri, 2 Dec 2011 16:40:52 +0100 Subject: Recent DNS attacks from China? In-Reply-To: References: <02F7D865-8803-4662-818C-9332163730F1@taranta.discpro.org> <1322677461.68582.YahooMailNeo@web162104.mail.bf1.yahoo.com> <4288131ED5E3024C9CD4782CECCAD2C70B53079D@LMC-MAIL2.exempla.org> <3454EA54E9F18A4993A4B99F07A01D9D014D53F62FC5@W2055.kpnnl.local> <38E75725-9FD3-4468-9425-2B5B19C684C9@u13.net> Message-ID: <3454EA54E9F18A4993A4B99F07A01D9D014D53F63976@W2055.kpnnl.local> Since it is spoofed traffic we block the "source", so not participating in flooding the real ip address. The real issue is verify unicast reverse path not being implemented. So that the ip addresses cannot be spoofed! (unless we are dealing with some major unknown vurlnerabilities in our infrastructure) After a few days we will unblock again. Regards, Rob Vercouteren From t.dahm at resolution.de Fri Dec 2 10:40:51 2011 From: t.dahm at resolution.de (Thorsten Dahm) Date: Fri, 02 Dec 2011 16:40:51 +0000 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: <201112021316.pB2DGKGm014444@aurora.sol.net> References: <201112021316.pB2DGKGm014444@aurora.sol.net> Message-ID: <4ED8FF93.1050603@resolution.de> Am 12/2/11 1:16 PM, schrieb Joe Greco: >> Thorsten Dahm: >> The downside of this is that you are not around in the office in case >> someone wants to talk to you. I often end up with guys from our >> operations team or other teams stopping at my desk and ask questions. Or >> guys who want to have a quick chat about a problem and want to ask for >> an advice or idea. Or people who want to learn Perl and have a question >> that you can answer in 30 seconds. > > Which really stops being practical once you exceed (approx) one building > in size. I think it often depends on how you define practical. Normally, you sit with your own team, that means it is a practical solution for the network engineers, but perhaps not for the server admins and the network engineers anymore, since the server admins may sit in a different building, different city, different continent, .... cheers, Thorsten From cjp at 0x1.net Fri Dec 2 11:18:25 2011 From: cjp at 0x1.net (Christopher J. Pilkington) Date: Fri, 2 Dec 2011 12:18:25 -0500 Subject: IP addresses are now assets In-Reply-To: <20111202040423.GL1397@manor.msen.com> References: <20111202040423.GL1397@manor.msen.com> Message-ID: <-2177556483850811793@unknownmsgid> On Dec 1, 2011, at 23:04, "Michael R. Wayne" wrote: > After negotiating with multiple prospective buyers, Cerner Corp. > agreed to buy the Internet addresses for $12 each. Other bids were > as low as $1.50 each, according to a bankruptcy court filing. Clearly the addresses with the last octet of 00 and ff should be discounted, since no one wants to be zero, and ff just seems to get everyone's attention. -cjp From sakamura at gmail.com Fri Dec 2 11:21:04 2011 From: sakamura at gmail.com (Ishmael Rufus) Date: Fri, 2 Dec 2011 11:21:04 -0600 Subject: IP addresses are now assets In-Reply-To: <-2177556483850811793@unknownmsgid> References: <20111202040423.GL1397@manor.msen.com> <-2177556483850811793@unknownmsgid> Message-ID: I have acres on the moon that are up for sale. On Fri, Dec 2, 2011 at 11:18 AM, Christopher J. Pilkington wrote: > On Dec 1, 2011, at 23:04, "Michael R. Wayne" wrote: > >> After negotiating with multiple prospective buyers, Cerner Corp. >> ? agreed to buy the Internet addresses for $12 each. Other bids were >> ? as low as $1.50 each, according to a bankruptcy court filing. > > Clearly the addresses with the last octet of 00 and ff should be > discounted, since no one wants to be zero, and ff just seems to get > everyone's attention. > > -cjp > From jcurran at arin.net Fri Dec 2 11:46:30 2011 From: jcurran at arin.net (John Curran) Date: Fri, 2 Dec 2011 17:46:30 +0000 Subject: IP addresses are now assets In-Reply-To: References: <44762.1322812111@turing-police.cc.vt.edu> <236167AF-4DEB-48D5-A7ED-ED0A1F0DEEA5@arin.net> Message-ID: <787B2512-1152-42DB-8022-D28C13CFD9A6@corp.arin.net> On Dec 2, 2011, at 10:16 AM, Martin Hannigan wrote: > ARIN, on many occasions, has stated that they have no authority over > legacy address space. They made this declaration in the Kamens/sex.com > case. I haven't heard that anything has changed since then. Martin - ARIN will maintain the registry in accordance with community policy for all addresses and that includes legacy address space. Thanks, /John John Curran President and CEO ARIN From cscora at apnic.net Fri Dec 2 13:21:11 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 3 Dec 2011 05:21:11 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201112021921.pB2JLBYO010309@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 03 Dec, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 383257 Prefixes after maximum aggregation: 167342 Deaggregation factor: 2.29 Unique aggregates announced to Internet: 188231 Total ASes present in the Internet Routing Table: 39463 Prefixes per ASN: 9.71 Origin-only ASes present in the Internet Routing Table: 32445 Origin ASes announcing only one prefix: 15489 Transit ASes present in the Internet Routing Table: 5326 Transit-only ASes present in the Internet Routing Table: 142 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 33 Max AS path prepend of ASN (48687) 24 Prefixes from unregistered ASNs in the Routing Table: 1825 Unregistered ASNs in the Routing Table: 938 Number of 32-bit ASNs allocated by the RIRs: 2031 Number of 32-bit ASNs visible in the Routing Table: 1692 Prefixes from 32-bit ASNs in the Routing Table: 4000 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 86 Number of addresses announced to Internet: 2497290368 Equivalent to 148 /8s, 217 /16s and 160 /24s Percentage of available address space announced: 67.4 Percentage of allocated address space announced: 67.4 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 91.7 Total number of prefixes smaller than registry allocations: 161883 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 95145 Total APNIC prefixes after maximum aggregation: 31175 APNIC Deaggregation factor: 3.05 Prefixes being announced from the APNIC address blocks: 91627 Unique aggregates announced from the APNIC address blocks: 38267 APNIC Region origin ASes present in the Internet Routing Table: 4600 APNIC Prefixes per ASN: 19.92 APNIC Region origin ASes announcing only one prefix: 1249 APNIC Region transit ASes present in the Internet Routing Table: 727 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 18 Number of APNIC region 32-bit ASNs visible in the Routing Table: 116 Number of APNIC addresses announced to Internet: 631205216 Equivalent to 37 /8s, 159 /16s and 109 /24s Percentage of available APNIC address space announced: 80.0 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-132095, 132096-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, 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: 146116 Total ARIN prefixes after maximum aggregation: 74691 ARIN Deaggregation factor: 1.96 Prefixes being announced from the ARIN address blocks: 118285 Unique aggregates announced from the ARIN address blocks: 48671 ARIN Region origin ASes present in the Internet Routing Table: 14775 ARIN Prefixes per ASN: 8.01 ARIN Region origin ASes announcing only one prefix: 5644 ARIN Region transit ASes present in the Internet Routing Table: 1574 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 25 Number of ARIN region 32-bit ASNs visible in the Routing Table: 12 Number of ARIN addresses announced to Internet: 803370432 Equivalent to 47 /8s, 226 /16s and 117 /24s Percentage of available ARIN address space announced: 63.8 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 92913 Total RIPE prefixes after maximum aggregation: 51424 RIPE Deaggregation factor: 1.81 Prefixes being announced from the RIPE address blocks: 85148 Unique aggregates announced from the RIPE address blocks: 54728 RIPE Region origin ASes present in the Internet Routing Table: 16155 RIPE Prefixes per ASN: 5.27 RIPE Region origin ASes announcing only one prefix: 7997 RIPE Region transit ASes present in the Internet Routing Table: 2543 Average RIPE Region AS path length visible: 4.7 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1186 Number of RIPE addresses announced to Internet: 492772928 Equivalent to 29 /8s, 95 /16s and 30 /24s Percentage of available RIPE address space announced: 79.4 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 36582 Total LACNIC prefixes after maximum aggregation: 7943 LACNIC Deaggregation factor: 4.61 Prefixes being announced from the LACNIC address blocks: 36006 Unique aggregates announced from the LACNIC address blocks: 18774 LACNIC Region origin ASes present in the Internet Routing Table: 1554 LACNIC Prefixes per ASN: 23.17 LACNIC Region origin ASes announcing only one prefix: 442 LACNIC Region transit ASes present in the Internet Routing Table: 286 Average LACNIC Region AS path length visible: 4.5 Max LACNIC Region AS path length visible: 18 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 374 Number of LACNIC addresses announced to Internet: 94397312 Equivalent to 5 /8s, 160 /16s and 99 /24s Percentage of available LACNIC address space announced: 62.5 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 8338 Total AfriNIC prefixes after maximum aggregation: 2041 AfriNIC Deaggregation factor: 4.09 Prefixes being announced from the AfriNIC address blocks: 6390 Unique aggregates announced from the AfriNIC address blocks: 2012 AfriNIC Region origin ASes present in the Internet Routing Table: 504 AfriNIC Prefixes per ASN: 12.68 AfriNIC Region origin ASes announcing only one prefix: 157 AfriNIC Region transit ASes present in the Internet Routing Table: 110 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 4 Number of AfriNIC addresses announced to Internet: 30034432 Equivalent to 1 /8s, 202 /16s and 74 /24s Percentage of available AfriNIC address space announced: 44.8 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2510 11105 973 Korea Telecom (KIX) 17974 1652 503 38 PT TELEKOMUNIKASI INDONESIA 7545 1626 303 87 TPG Internet Pty Ltd 4755 1511 381 157 TATA Communications formerly 7552 1386 1064 7 Vietel Corporation 9829 1166 989 28 BSNL National Internet Backbo 9583 1095 80 494 Sify Limited 4808 1079 2038 305 CNCGROUP IP network: China169 24560 985 390 151 Bharti Airtel Ltd., Telemedia 18101 958 121 155 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 3483 3814 218 bellsouth.net, inc. 7029 2912 1016 199 Windstream Communications Inc 18566 2093 383 177 Covad Communications 1785 1852 680 120 PaeTec Communications, Inc. 4323 1616 1073 386 Time Warner Telecom 20115 1603 1546 625 Charter Communications 22773 1507 2909 104 Cox Communications, Inc. 30036 1435 257 675 Mediacom Communications Corp 19262 1388 4683 401 Verizon Global Networks 7018 1314 7029 860 AT&T WorldNet Services 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 1552 480 15 Corbina telecom 6830 645 1927 412 UPC Distribution Services 34984 616 116 195 BILISIM TELEKOM 20940 546 174 437 Akamai Technologies European 3320 517 8168 390 Deutsche Telekom AG 12479 494 601 13 Uni2 Autonomous System 3292 480 2106 407 TDC Tele Danmark 8866 462 133 26 Bulgarian Telecommunication C 8551 451 366 45 Bezeq International 31148 413 22 115 FreeNet ISP 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 1702 315 180 TVCABLE BOGOTA 28573 1537 1059 72 NET Servicos de Comunicao S.A 8151 1334 2985 345 UniNet S.A. de C.V. 7303 1239 751 174 Telecom Argentina Stet-France 27947 606 72 89 Telconet S.A 22047 582 322 17 VTR PUNTO NET S.A. 7738 553 1050 31 Telecomunicacoes da Bahia S.A 6503 552 434 68 AVANTEL, S.A. 3816 547 237 89 Empresa Nacional de Telecomun 11172 527 85 95 Servicios Alestra S.A de C.V Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 926 958 13 TEDATA 24863 785 146 35 LINKdotNET AS number 3741 281 939 230 The Internet Solution 15706 242 32 6 Sudatel Internet Exchange Aut 6713 235 519 14 Itissalat Al-MAGHRIB 33776 231 13 10 Starcomms Nigeria Limited 29571 217 17 13 Ci Telecom Autonomous system 12258 195 28 60 Vodacom Internet Company 24835 190 80 8 RAYA Telecom - Egypt 16637 160 662 82 MTN Network Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3483 3814 218 bellsouth.net, inc. 7029 2912 1016 199 Windstream Communications Inc 4766 2510 11105 973 Korea Telecom (KIX) 18566 2093 383 177 Covad Communications 1785 1852 680 120 PaeTec Communications, Inc. 10620 1702 315 180 TVCABLE BOGOTA 17974 1652 503 38 PT TELEKOMUNIKASI INDONESIA 7545 1626 303 87 TPG Internet Pty Ltd 4323 1616 1073 386 Time Warner Telecom 20115 1603 1546 625 Charter Communications 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 2912 2713 Windstream Communications Inc 18566 2093 1916 Covad Communications 1785 1852 1732 PaeTec Communications, Inc. 17974 1652 1614 PT TELEKOMUNIKASI INDONESIA 7545 1626 1539 TPG Internet Pty Ltd 4766 2510 1537 Korea Telecom (KIX) 8402 1552 1537 Corbina telecom 10620 1702 1522 TVCABLE BOGOTA 28573 1537 1465 NET Servicos de Comunicao S.A 22773 1507 1403 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 14764 UNALLOCATED 12.108.237.0/24 7018 AT&T WorldNet Servic 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.0.0/21 12654 RIPE NCC RIS Project 128.0.24.0/24 12654 RIPE NCC RIS Project Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 41.222.79.0/24 37345 MEDALLION Communications 41.223.92.0/22 36936 >>UNKNOWN<< 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.21.192.0/20 11610 Internet Nebraska Corporation 64.21.212.0/22 11610 Internet Nebraska Corporation 64.21.216.0/21 11610 Internet Nebraska Corporation 66.171.32.0/20 705 UUNET Technologies, Inc. 66.175.222.0/23 30058 FDC Servers.net, LLC 66.180.239.0/24 35888 VIGNETTE CORPORATION Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:12 /10:27 /11:81 /12:236 /13:463 /14:807 /15:1437 /16:12055 /17:6113 /18:10143 /19:20053 /20:27738 /21:28008 /22:38142 /23:35692 /24:198843 /25:1181 /26:1400 /27:785 /28:14 /29:3 /30:0 /31:0 /32:5 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 2541 2912 Windstream Communications Inc 6389 2126 3483 bellsouth.net, inc. 18566 2042 2093 Covad Communications 10620 1597 1702 TVCABLE BOGOTA 8402 1527 1552 Corbina telecom 30036 1395 1435 Mediacom Communications Corp 11492 1119 1156 Cable One 1785 1058 1852 PaeTec Communications, Inc. 7011 1048 1165 Citizens Utilities 22773 967 1507 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:442 2:489 4:15 5:1 6:3 8:359 12:1947 13:1 14:548 15:11 16:3 17:7 20:9 23:69 24:1694 27:1059 31:717 32:67 33:2 34:2 36:4 38:770 39:1 40:114 41:2860 42:66 43:1 44:3 46:1111 47:3 49:292 50:450 52:13 55:6 56:2 57:49 58:939 59:486 60:358 61:1178 62:913 63:1968 64:4049 65:2308 66:4368 67:1998 68:1174 69:3147 70:904 71:361 72:1772 74:2641 75:430 76:320 77:907 78:890 79:438 80:1142 81:834 82:523 83:527 84:471 85:1164 86:410 87:907 88:341 89:1587 90:246 91:4314 92:532 93:1423 94:1327 95:1096 96:397 97:285 98:764 99:37 101:121 103:523 106:7 107:103 108:88 109:1120 110:668 111:818 112:367 113:487 114:622 115:700 116:896 117:708 118:870 119:1229 120:349 121:667 122:1567 123:1019 124:1348 125:1349 128:278 129:185 130:183 131:632 132:155 133:21 134:222 135:54 136:212 137:146 138:287 139:123 140:491 141:253 142:379 143:405 144:498 145:62 146:475 147:221 148:643 149:270 150:166 151:192 152:449 153:171 154:7 155:381 156:209 157:359 158:156 159:523 160:333 161:214 162:364 163:176 164:521 165:385 166:542 167:453 168:823 169:146 170:822 171:87 172:4 173:1767 174:586 175:418 176:329 177:411 178:1150 180:1178 181:39 182:669 183:242 184:399 185:1 186:1478 187:784 188:947 189:1164 190:5286 192:5965 193:5118 194:3555 195:3119 196:1283 197:169 198:3624 199:4235 200:5523 201:1696 202:8474 203:8494 204:4322 205:2409 206:2668 207:2839 208:4011 209:3551 210:2730 211:1473 212:1991 213:1804 214:813 215:92 216:4933 217:1486 218:577 219:340 220:1252 221:525 222:325 223:229 End of report From streiner at cluebyfour.org Fri Dec 2 13:23:54 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 2 Dec 2011 14:23:54 -0500 (EST) Subject: IP addresses are now assets In-Reply-To: <20111202141151.GA20138@ussenterprise.ufp.org> References: <20111202040423.GL1397@manor.msen.com> <20111202141151.GA20138@ussenterprise.ufp.org> Message-ID: On Fri, 2 Dec 2011, Leo Bicknell wrote: > In a message written on Thu, Dec 01, 2011 at 11:04:23PM -0500, Michael R. Wayne wrote: >> After negotiating with multiple prospective buyers, Cerner Corp. >> agreed to buy the Internet addresses for $12 each. Other bids were >> as low as $1.50 each, according to a bankruptcy court filing. > > Someone should tell Cerner Corp you can still get them for free, > and thus they overpaid by oh, $12 an address! I'm waiting for someone to come back and balk at $12/address, and try to reduce the number of addresses they buy, forgetting that pesky powers-of-two business: "In the interest of containing the cost of the deal, XYZ Corp has agreed to buy 27,000 addresses instead of the original 65,536." That will be a definite facepalm moment. jms From leigh.porter at ukbroadband.com Fri Dec 2 13:29:43 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Fri, 2 Dec 2011 19:29:43 +0000 Subject: IP addresses are now assets In-Reply-To: References: <20111202040423.GL1397@manor.msen.com> <20111202141151.GA20138@ussenterprise.ufp.org> Message-ID: > -----Original Message----- > From: Justin M. Streiner [mailto:streiner at cluebyfour.org] > Sent: 02 December 2011 19:26 > To: Leo Bicknell > Cc: NANOG > Subject: Re: IP addresses are now assets > > On Fri, 2 Dec 2011, Leo Bicknell wrote: > > > In a message written on Thu, Dec 01, 2011 at 11:04:23PM -0500, > Michael R. Wayne wrote: > >> After negotiating with multiple prospective buyers, Cerner Corp. > >> agreed to buy the Internet addresses for $12 each. Other bids > were > >> as low as $1.50 each, according to a bankruptcy court filing. > > > > Someone should tell Cerner Corp you can still get them for free, > > and thus they overpaid by oh, $12 an address! > > I'm waiting for someone to come back and balk at $12/address, and try > to > reduce the number of addresses they buy, forgetting that pesky powers- > of-two > business: "In the interest of containing the cost of the deal, XYZ > Corp has > agreed to buy 27,000 addresses instead of the original 65,536." > > That will be a definite facepalm moment. > > jms So about a /18 a /19 a /21 and a /23 then ;-) -- Leigh ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From jsahala at gmail.com Fri Dec 2 13:37:29 2011 From: jsahala at gmail.com (joshua sahala) Date: Fri, 2 Dec 2011 12:37:29 -0700 Subject: IP addresses are now assets In-Reply-To: <38B33D90-8E1E-46D5-B08E-6207CAD8E3B8@arin.net> References: <44762.1322812111@turing-police.cc.vt.edu> <236167AF-4DEB-48D5-A7ED-ED0A1F0DEEA5@arin.net> <38B33D90-8E1E-46D5-B08E-6207CAD8E3B8@arin.net> Message-ID: On Thu, Dec 1, 2011 at 10:20 PM, John Curran wrote:[cut] > Your subject line (IP addresses are now assets) could mislead folks, [cut] ianal, but the treatment of ip addresses by the bankruptcy court would tend to agree with the definition of an asset from webster's new world law dictionary (http://law.yourdictionary.com/asset): Any property or right that is owned by a person or entity and has monetary value. See also liability. All of the property of a person or entity or its total value; entries on a balance sheet listing such property. intangible asset An asset that is not a physical thing and only evidenced by a written document. the addresses are being exchanged for money, in order to pay a debt...how is this not a sale of an asset? > ARIN holds that IP address space is not property but is managed as a> public resource. imho, if it were truly a 'public resource' and managed as such, it would be returned to the appropriate rir for reassignment, rather than being auctioned off to the highest bidder by a (commodities) broker...administrative and processing fees are one thing, but this is pure commoditisation of a so-called 'public resource' by speculators. i am, unfortunately, in the minority on this topic On Fri, Dec 2, 2011 at 8:33 AM, John Curran wrote: [cut] > ?"Sale may be subject to compliance with certain requirements of > the American Registry of Internet Numbers ("ARIN") and the court > materials to date reflect this. MAY versus WILL -- rfc2119 contains a pretty clear definition of each, which i am pretty sure echoes legal precedent..but again, ianal, so, ymmv, etc, etc the speculative market exists and is growing, why do certain factions of the community keep trying to pretend that it doesn't? /joshua From surfer at mauigateway.com Fri Dec 2 13:47:46 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 2 Dec 2011 11:47:46 -0800 Subject: IP addresses are now assets Message-ID: <20111202114746.BA3898EE@resin04.mta.everyone.net> --- jsahala at gmail.com wrote: the speculative market exists and is growing, why do certain factions of the community keep trying to pretend that it doesn't? ------------------------------------------- Because they're busy getting ipv6 up and that will make these things less important? >;-) scott From jfbeam at gmail.com Fri Dec 2 13:49:39 2011 From: jfbeam at gmail.com (Ricky Beam) Date: Fri, 02 Dec 2011 14:49:39 -0500 Subject: IP addresses are now assets In-Reply-To: References: <44762.1322812111@turing-police.cc.vt.edu> <236167AF-4DEB-48D5-A7ED-ED0A1F0DEEA5@arin.net> <38B33D90-8E1E-46D5-B08E-6207CAD8E3B8@arin.net> Message-ID: On Fri, 02 Dec 2011 14:37:29 -0500, joshua sahala wrote: > Any property or right that is owned by a person or entity and has > monetary value. See also liability. If it was a RIR assignment, it's not "owned". It's more akin to a "lease". That said, there are documented rules/proceedures for transfering assignments. I'm not entirely sure they apply here. Legacy assignments are, obviously, a very different story. --Ricky From jlightfoot at gmail.com Fri Dec 2 13:53:43 2011 From: jlightfoot at gmail.com (John Lightfoot) Date: Fri, 2 Dec 2011 14:53:43 -0500 Subject: IP addresses are now assets In-Reply-To: <-2177556483850811793@unknownmsgid> References: <20111202040423.GL1397@manor.msen.com> <-2177556483850811793@unknownmsgid> Message-ID: <00c601ccb12c$1b3b72e0$51b258a0$@gmail.com> I have a boatload of IPv6 addresses I'm willing to sell at the low, low price of $.01 each. -----Original Message----- From: Christopher J. Pilkington [mailto:cjp at 0x1.net] Sent: Friday, December 02, 2011 12:18 PM To: Michael R. Wayne Cc: NANOG Subject: Re: IP addresses are now assets On Dec 1, 2011, at 23:04, "Michael R. Wayne" wrote: > After negotiating with multiple prospective buyers, Cerner Corp. > agreed to buy the Internet addresses for $12 each. Other bids were > as low as $1.50 each, according to a bankruptcy court filing. Clearly the addresses with the last octet of 00 and ff should be discounted, since no one wants to be zero, and ff just seems to get everyone's attention. -cjp From bonomi at mail.r-bonomi.com Fri Dec 2 13:56:35 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Fri, 2 Dec 2011 13:56:35 -0600 (CST) Subject: IP addresses are now assets In-Reply-To: Message-ID: <201112021956.pB2JuZDg012655@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Fri Dec 2 13:29:31 2011 > From: Leigh Porter > To: "Justin M. Streiner" , > Leo Bicknell > > Subject: RE: IP addresses are now assets > Date: Fri, 2 Dec 2011 19:29:43 +0000 > Cc: NANOG > > > > > -----Original Message----- > > From: Justin M. Streiner [mailto:streiner at cluebyfour.org] > > Sent: 02 December 2011 19:26 > > To: Leo Bicknell > > Cc: NANOG > > Subject: Re: IP addresses are now assets > > > > On Fri, 2 Dec 2011, Leo Bicknell wrote: > > > > > In a message written on Thu, Dec 01, 2011 at 11:04:23PM -0500, > > Michael R. Wayne wrote: > > >> After negotiating with multiple prospective buyers, Cerner Corp. > > >> agreed to buy the Internet addresses for $12 each. Other bids > > were > > >> as low as $1.50 each, according to a bankruptcy court filing. > > > > > > Someone should tell Cerner Corp you can still get them for free, > > > and thus they overpaid by oh, $12 an address! > > > > I'm waiting for someone to come back and balk at $12/address, and try > > to > > reduce the number of addresses they buy, forgetting that pesky powers- > > of-two > > business: "In the interest of containing the cost of the deal, XYZ > > Corp has > > agreed to buy 27,000 addresses instead of the original 65,536." > > > > That will be a definite facepalm moment. > > > > jms > > > So about a /18 a /19 a /21 and a /23 then ;-) Methinks it ought to be restricted to some combination of a /17, a /19, a /23, a /29, and a /31. It's all 'prime' number-space, after all. References: <44762.1322812111@turing-police.cc.vt.edu> <236167AF-4DEB-48D5-A7ED-ED0A1F0DEEA5@arin.net> <38B33D90-8E1E-46D5-B08E-6207CAD8E3B8@arin.net> Message-ID: <20111202200131.GT29174@nntp.AegisInfoSys.com> On Fri, Dec 02, 2011 at 12:37:29PM -0700, joshua sahala wrote: > On Thu, Dec 1, 2011 at 10:20 PM, John Curran wrote:[cut] > > Your subject line (IP addresses are now assets) could mislead folks, > [cut] > ianal, but the treatment of ip addresses by the bankruptcy court would > tend to agree with the definition of an asset from webster's new world > law dictionary (http://law.yourdictionary.com/asset): > > Any property or right that is owned by a person or entity and has > monetary value. See also liability. > > All of the property of a person or entity or its total value; > entries on a balance sheet listing such property. > > intangible asset > An asset that is not a physical thing and only evidenced by a > written document. > > > the addresses are being exchanged for money, in order to pay a > debt...how is this not a sale of an asset? I guess I'm in the same minority in that I agree with you. Note that "Asset" !== "Property". The IP addresses in question are unquestionably "Assets" (albeit "Restricted assets" or hard-to-value assets), but not so evidently "Property". So, the original subject line "IP addresses are now assets" seems accurate; it does not say "IP addresses are now property". Conflation of the two terms is in the mind of the reader, and perhaps that's what John Curran was seeking to clarify. -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York From bonomi at mail.r-bonomi.com Fri Dec 2 14:06:58 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Fri, 2 Dec 2011 14:06:58 -0600 (CST) Subject: IP addresses are now assets In-Reply-To: <00c601ccb12c$1b3b72e0$51b258a0$@gmail.com> Message-ID: <201112022006.pB2K6wAr012733@mail.r-bonomi.com> "John Lightfoot" wrote; > I have a boatload of IPv6 addresses I'm willing to sell at the low, low price of $.01 each. Good for you. _I_ have somewhat over 17.8 million IPv4 addresses, in 3 large blocks, for which I will sell my 'right to use', at half your offering price. From surfer at mauigateway.com Fri Dec 2 14:05:37 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 2 Dec 2011 12:05:37 -0800 Subject: Looking for a Tier 1 ISP Mentor for career advice. Message-ID: <20111202120537.BA389A4C@resin04.mta.everyone.net> --- david at davidradcliffe.org wrote: From: David Radcliffe Actually, the best reason I have for working from home is I work much better when naked and they have asked me to stop showing up that way at the office. ------------------------------------------------ Woah, woah, woah! The absolute painnnnn of that image is breaking my mind apart! >;-) scott From mike at mikejones.in Fri Dec 2 14:14:58 2011 From: mike at mikejones.in (Mike Jones) Date: Fri, 2 Dec 2011 20:14:58 +0000 Subject: IP addresses are now assets In-Reply-To: <20111202200131.GT29174@nntp.AegisInfoSys.com> References: <44762.1322812111@turing-police.cc.vt.edu> <236167AF-4DEB-48D5-A7ED-ED0A1F0DEEA5@arin.net> <38B33D90-8E1E-46D5-B08E-6207CAD8E3B8@arin.net> <20111202200131.GT29174@nntp.AegisInfoSys.com> Message-ID: On 2 December 2011 20:01, Henry Yen wrote: > On Fri, Dec 02, 2011 at 12:37:29PM -0700, joshua sahala wrote: >> On Thu, Dec 1, 2011 at 10:20 PM, John Curran wrote:[cut] >> > Your subject line (IP addresses are now assets) could mislead folks, >> [cut] >> ianal, but the treatment of ip addresses by the bankruptcy court would >> tend to agree with the definition of an asset from webster's new world >> law dictionary (http://law.yourdictionary.com/asset): >> >> ? ?Any property or right that is owned by a person or entity and has >> ? ?monetary value. See also liability. >> >> ? ?All of the property of a person or entity or its total value; >> ? ?entries on a balance sheet listing such property. >> >> ? ?intangible asset >> ? ? ? An asset that is not a physical thing and only evidenced by a >> ? ? ? written document. >> >> >> the addresses are being exchanged for money, in order to pay a >> debt...how is this not a sale of an asset? > > I guess I'm in the same minority in that I agree with you. > > Note that "Asset" !== "Property". > > The IP addresses in question are unquestionably "Assets" (albeit > "Restricted assets" or hard-to-value assets), but not so evidently > "Property". ?So, the original subject line "IP addresses are now assets" > seems accurate; it does not say "IP addresses are now property". > Conflation of the two terms is in the mind of the reader, and perhaps > that's what John Curran was seeking to clarify. > What about land? it's a public resource that you've paid money to someone in exchange for transferring their rights over that public resource to you. That said, I think in the case of land shortages there is an argument that land no longer being used by someone should be freed up for use by new people. Although i'm not entirely sure how to justify a "instead of selling it you have to return it so it can be allocated to whoever has a need for it" policy without also justifying the same for my house, which has spare rooms that I don't need. - Mike From jloiacon at csc.com Fri Dec 2 14:28:22 2011 From: jloiacon at csc.com (Joe Loiacono) Date: Fri, 2 Dec 2011 15:28:22 -0500 Subject: IP addresses are now assets In-Reply-To: References: <44762.1322812111@turing-police.cc.vt.edu> <236167AF-4DEB-48D5-A7ED-ED0A1F0DEEA5@arin.net> <38B33D90-8E1E-46D5-B08E-6207CAD8E3B8@arin.net> <20111202200131.GT29174@nntp.AegisInfoSys.com> Message-ID: Mike Jones wrote on 12/02/2011 03:14:58 PM: > What about land? it's a public resource that you've paid money to > someone in exchange for transferring their rights over that public > resource to you. Land is private property. Joe From surfer at mauigateway.com Fri Dec 2 14:30:53 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 2 Dec 2011 12:30:53 -0800 Subject: Looking for a Tier 1 ISP Mentor for career advice. Message-ID: <20111202123053.BA389EAF@resin04.mta.everyone.net> --- bicknell at ufp.org wrote: From: Leo Bicknell If you have telecommuters _everyone_ in the office should be forced to work from home at least 2 weeks a year, including the manager. It's only from that experience you learn to deal with your telecommuting co-workers in a way that raises everyone's productivity. --------------------------------------------- I have been bemoaning the lack of telecommuting positions available since I last did that permanently from 1998-2002. I could never figure out how to get the managers since then to understand how to manage remote workers effectively, as that's what I think the problem is. The manager's ability to value an employee in this century's methodology, rather than the old way: "wow, he was in the office 10 hours today. He must've gotten a lot of work done". When, actually, the person played around for 6 of those hours while looking busy. Having the manager work from home, even temporarily, would solve this. Now if I can just get them to actually do that... :-) --------------------------------------------------- Once over that hump there are huge rewards to having telecommuters. You can pay lower salaries as people can live in cheaper locations. --------------------------------------------------- The company gets to pay for less space, too. Have a "hot cube" where everyone uses it for the day(s) they need to work in the office. I really hope manager-types are listening. You limit yourselves to those available in your immediate area and the skills they have. Opening yourselves to telecommuting allows you to hire folks with skills that may match your needs more effectively. Personally, I am working at smaller networks than I would like to, but I get to live on Kauai and surf places like this every day: www.imagemania.net/data/media/22/Polihale%20Beach,%20Kauai,%20Hawaii.jpg when I'd rather get back into BGP and operating large networks because I enjoy it. However, I will not give up life's fun things just to do that for a living. I know I'm not the only one out there who thinks this way. scott --- bicknell at ufp.org wrote: From: Leo Bicknell To: nanog at nanog.org Subject: Re: Looking for a Tier 1 ISP Mentor for career advice. Date: Fri, 2 Dec 2011 07:37:08 -0800 In a message written on Fri, Dec 02, 2011 at 12:25:41PM +0000, Thorsten Dahm wrote: > The downside of this is that you are not around in the office in case > someone wants to talk to you. I often end up with guys from our > operations team or other teams stopping at my desk and ask questions. Or > guys who want to have a quick chat about a problem and want to ask for > an advice or idea. Or people who want to learn Perl and have a question > that you can answer in 30 seconds. I've both delt with remote employees and been a telecommuter. After those experiences, and reading a few books I've decided the hardest thing about having successful telecommuters is dealing with the folks in the office. Telecommuters quickly turn to technology, they want to video-chat with collegues. Are eager to pick up the phone and talk. They reach out (generally). It's the folks in the office that are reluctant. They don't see the point of figuring out how the video chat software works, of setting their status to indicate what they are doing, and so on. The "water cooler" conversations can be moved to Skype, FaceTime, Google Hangouts, or any number of other solutions, but it requires everyone to be in that mindset. If you have telecommuters _everyone_ in the office should be forced to work from home at least 2 weeks a year, including the manager. It's only from that experience you learn to deal with your telecommuting co-workers in a way that raises everyone's productivity. Once over that hump there are huge rewards to having telecommuters. You can pay lower salaries as people can live in cheaper locations. People in multiple timezones provide better natural coverage. People are much more willing to do off hour work when they can roll out of bed at 5AM and be working at 5:05 in their PJ's, rather than getting up at 4 and getting dressed to drive in and do the work. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From surfer at mauigateway.com Fri Dec 2 14:33:12 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 2 Dec 2011 12:33:12 -0800 Subject: Looking for a Tier 1 ISP Mentor for career advice. Message-ID: <20111202123312.BA389E70@resin04.mta.everyone.net> Apologies for the rapid-shot email. It's Friday... :-) --- bmanning at vacation.karoshi.com wrote: From: bmanning at vacation.karoshi.com On Thu, Dec 01, 2011 at 04:35:27PM -0500, David Radcliffe wrote: > The reason it is not more accepted is too many people still think "If I cannot > see you you must not be working." > actually, i've heard the real reason is corporate liability ... that said, there is an advantage for team f2f mtgs on a periodic basis. ---------------------------------------------- I don't follow. Could you elaborate? What is the liability? scott From jgreco at ns.sol.net Fri Dec 2 14:36:38 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 2 Dec 2011 14:36:38 -0600 (CST) Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: <4ED8FF93.1050603@resolution.de> Message-ID: <201112022036.pB2Kacxg019907@aurora.sol.net> > Am 12/2/11 1:16 PM, schrieb Joe Greco: > >> Thorsten Dahm: > >> The downside of this is that you are not around in the office in case > >> someone wants to talk to you. I often end up with guys from our > >> operations team or other teams stopping at my desk and ask questions. Or > >> guys who want to have a quick chat about a problem and want to ask for > >> an advice or idea. Or people who want to learn Perl and have a question > >> that you can answer in 30 seconds. > > > > Which really stops being practical once you exceed (approx) one building > > in size. > > I think it often depends on how you define practical. Normally, you sit > with your own team, that means it is a practical solution for the > network engineers, but perhaps not for the server admins and the network > engineers anymore, since the server admins may sit in a different > building, different city, different continent, .... While any absolute rule would be silly, of course, I would have thought my point was sufficiently clear. There comes a point at which all the people you may want to talk to are no longer sitting in the same building. That doesn't mean all buildings will successfully allow F2F meetings (Pentagon) or that having groups within the same building will encourage F2F meetings. It's a simple fact that once you *must* deal with someone in another building, the amount of time and effort involved gets much higher and more inconvenient. If you manage to find a way to keep your group small and all in the same building, then what I said doesn't apply, but that can itself become impractical as a company grows. ... 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 bicknell at ufp.org Fri Dec 2 14:51:32 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 2 Dec 2011 12:51:32 -0800 Subject: IP addresses are now assets In-Reply-To: References: <44762.1322812111@turing-police.cc.vt.edu> <236167AF-4DEB-48D5-A7ED-ED0A1F0DEEA5@arin.net> <38B33D90-8E1E-46D5-B08E-6207CAD8E3B8@arin.net> <20111202200131.GT29174@nntp.AegisInfoSys.com> Message-ID: <20111202205132.GA35186@ussenterprise.ufp.org> In a message written on Fri, Dec 02, 2011 at 03:28:22PM -0500, Joe Loiacono wrote: > Mike Jones wrote on 12/02/2011 03:14:58 PM: > > What about land? it's a public resource that you've paid money to > > someone in exchange for transferring their rights over that public > > resource to you. > > Land is private property. Some land in some countries is private property. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From morrowc.lists at gmail.com Fri Dec 2 15:06:31 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 2 Dec 2011 16:06:31 -0500 Subject: bgp update destroying transit on redback routers ? In-Reply-To: <20111202143554.GA66539@snar.spb.ru> References: <0ED867EB33AB2B45AAB470D5A64CDBF6181C25624E@EUSAACMS0701.eamcs.ericsson.se> <20111202143554.GA66539@snar.spb.ru> Message-ID: On Fri, Dec 2, 2011 at 9:35 AM, Alexandre Snarskii wrote: > This draft says that ...note it's a DRAFT, not a STANDARD... > > If a BGP speaker receives a route which has an AS number of zero in the > AS_PATH (or AS4_PATH) attribute, it SHOULD be logged and treated as a > WITHDRAW. This same behavior applies to routes containing zero as the > Aggregator or AS4 Aggregator. > > but observed behaviour was more like following: > > If a BGP speaker receives [bad route] it MUST close session immediately > with NOTIFICATION Error Code 'Update Message Error' and subcode 'Error with > optional attribute'. hence this old behavor From jcurran at arin.net Fri Dec 2 15:08:58 2011 From: jcurran at arin.net (John Curran) Date: Fri, 2 Dec 2011 21:08:58 +0000 Subject: IP addresses are now assets In-Reply-To: References: <44762.1322812111@turing-police.cc.vt.edu> <236167AF-4DEB-48D5-A7ED-ED0A1F0DEEA5@arin.net> Message-ID: <787B2512-1152-42DB-8022-D28C13CFD9A6@corp.arin.net> On Dec 2, 2011, at 10:16 AM, Martin Hannigan wrote: > ARIN, on many occasions, has stated that they have no authority over > legacy address space. They made this declaration in the Kamens/sex.com > case. I haven't heard that anything has changed since then. Martin - ARIN will maintain the registry in accordance with community policy for all addresses and that includes legacy address space. Thanks, /John John Curran President and CEO ARIN From tvhawaii at shaka.com Fri Dec 2 15:12:22 2011 From: tvhawaii at shaka.com (Michael Painter) Date: Fri, 2 Dec 2011 11:12:22 -1000 Subject: Wired mag piece on the Water Utility SCADA 'Attack' References: <21004746.1127.1322750495937.JavaMail.root@benjamin.baylink.com> Message-ID: <769C9B4F0AAD420E9E776AA03EFDBDB2@owner59e1f1502> Jay Ashworth wrote: > Damn that was quick: > > http://j.mp/rvWnEC And more FUD from the FBI? http://www.information-age.com/channels/security-and-continuity/news/1676243/hackers-accessed-city-infrastructure-via-scada-fbi.thtml From jsahala at gmail.com Fri Dec 2 15:12:53 2011 From: jsahala at gmail.com (joshua sahala) Date: Fri, 2 Dec 2011 14:12:53 -0700 Subject: IP addresses are now assets In-Reply-To: References: <44762.1322812111@turing-police.cc.vt.edu> <236167AF-4DEB-48D5-A7ED-ED0A1F0DEEA5@arin.net> <38B33D90-8E1E-46D5-B08E-6207CAD8E3B8@arin.net> <20111202200131.GT29174@nntp.AegisInfoSys.com> Message-ID: >> On Fri, Dec 02, 2011 at 12:37:29PM -0700, joshua sahala wrote: >>> ? ?Any property or right that is owned by a person or entity and has >>> ? ?monetary value. See also liability. >>> >>> ? ?All of the property of a person or entity or its total value; >>> ? ?entries on a balance sheet listing such property. >>> >>> ? ?intangible asset >>> ? ? ? An asset that is not a physical thing and only evidenced by a >>> ? ? ? written document. >>> > On 2 December 2011 20:01, Henry Yen wrote: >> Note that "Asset" !== "Property". reread the definition: an asset is property. an intangible asset is merely one type of asset. On Fri, Dec 2, 2011 at 1:14 PM, Mike Jones wrote: > What about land? it's a public resource that you've paid money to > someone in exchange for transferring their rights over that public > resource to you. land is a tangible asset, and has largely been privatised when it comes to ownership. you can lease public lands, but when your lease ends, it is returned to the "owner" (the government), and any "improvements" (if allowed at all) are torn down or given over. sometimes you can sublet your lease, but this doesn't make it a new contract or change the original terms. > That said, I think in the case of land shortages there is an argument > that land no longer being used by someone should be freed up for use > by new people. this starts drifting into a philosophical debate on privatisation and the use, control, and management of 'the commons' (land, water, air, etc.) and something which is largely (further) offtopic for this list. but, i digress...and the various dead horses here have all been beaten beyond recognition /joshua -- A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. ? ? ? ? - Douglas Adams - From tayeb.meftah at gmail.com Thu Dec 1 13:40:58 2011 From: tayeb.meftah at gmail.com (Meftah Tayeb) Date: Thu, 1 Dec 2011 21:40:58 +0200 Subject: MPLS based routing Message-ID: <9534BC585E6B42998E44A47A5FBC0730@work> hello guys, if i want to label my routes in a cisco router i did run through ldp configuration step now i see that labels are distributed, but if i traceroute it from another router i didn't see the icmp arg for the mpls label did i miss anything? atached my configuration :) Meftah Tayeb IT Consulting http://www.tmvoip.com/ phone: +21321656139 Mobile: +213660347746 __________ Information from ESET NOD32 Antivirus, version of virus signature database 6678 (20111202) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com -------------- next part -------------- A non-text attachment was scrubbed... Name: c2800 Type: application/octet-stream Size: 4106 bytes Desc: not available URL: From jcurran at arin.net Fri Dec 2 15:39:19 2011 From: jcurran at arin.net (John Curran) Date: Fri, 2 Dec 2011 21:39:19 +0000 Subject: IP addresses are now assets In-Reply-To: References: <44762.1322812111@turing-police.cc.vt.edu> <236167AF-4DEB-48D5-A7ED-ED0A1F0DEEA5@arin.net> <38B33D90-8E1E-46D5-B08E-6207CAD8E3B8@arin.net> Message-ID: <7B8BD3E7-7CFB-4056-AE9A-6B99506245C5@corp.arin.net> On Dec 2, 2011, at 2:37 PM, joshua sahala wrote: > intangible asset > An asset that is not a physical thing and only evidenced by a > written document. > > the addresses are being exchanged for money, in order to pay a > debt...how is this not a sale of an asset? Joshua - Rights to addresses (in the registration database) are being transferred for money. Those rights may indeed be "assets" (although that's likely a question better suited for lawyers) Perhaps "Rights to IP addresses can be sold!" would be a better title, but it's not exactly newsworthy since we've all known that for some time: >> ARIN holds that IP address space is not property but is managed as a> public resource. > > imho, if it were truly a 'public resource' and managed as such, it > would be returned to the appropriate rir for reassignment, rather than > being auctioned off to the highest bidder by a (commodities) broker... Agreed. However, attempting fairly to administrate a resource as it becomes increasingly scarce is quite problematic, and yet there is a real need emerging among network operators for IPv4 space as the regional free pool diminishes. The limited market mechanism provides a motivation for getting these resources back into use, while still taking the communities need for accurate record keeping and avoidance of deaggregation into consideration. > administrative and processing fees are one thing, but this is > pure commoditisation of a so-called 'public resource' by speculators. > > i am, unfortunately, in the minority on this topic It shouldn't be speculators, unless they're particularly skilled at faking the operational need for the space they're obtaining and willing to risk losing the entire investment if detected. > On Fri, Dec 2, 2011 at 8:33 AM, John Curran wrote: > [cut] >> "Sale may be subject to compliance with certain requirements of >> the American Registry of Internet Numbers ("ARIN") and the court >> materials to date reflect this. > > MAY versus WILL -- rfc2119 contains a pretty clear definition of each, > which i am pretty sure echoes legal precedent..but again, ianal, so, > ymmv, etc, etc I referenced that language because it is in the public solicitation. Actual legal documents on transfers to date have been quite explicit on this point. > the speculative market exists and is growing, why do certain factions > of the community keep trying to pretend that it doesn't? Again, there is a limited market emerging in IPv4 address space, one in which the transfer recipient must demonstrate an operational need. Attempting to use the transfer policy to speculate would be rather adventurous (since one must agree contractually to compliance with the registry policies and to the veracity of the information on the transfer request...) That doesn't mean it won't happen, only that we hope that it will not get materially in the way of service providers who do need additional address space. FYI, /John John Curran President and CEO ARIN From cidr-report at potaroo.net Fri Dec 2 16:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 2 Dec 2011 22:00:00 GMT Subject: BGP Update Report Message-ID: <201112022200.pB2M00w8061222@wattle.apnic.net> BGP Update Report Interval: 24-Nov-11 -to- 01-Dec-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS42116 155829 8.6% 2554.6 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 2 - AS17974 56880 3.1% 29.3 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 3 - AS9829 51998 2.9% 76.9 -- BSNL-NIB National Internet Backbone 4 - AS7552 35758 2.0% 25.7 -- VIETEL-AS-AP Vietel Corporation 5 - AS8402 34317 1.9% 23.4 -- CORBINA-AS OJSC "Vimpelcom" 6 - AS19743 31349 1.7% 5224.8 -- 7 - AS32528 23173 1.3% 5793.2 -- ABBOTT Abbot Labs 8 - AS5800 23021 1.3% 93.2 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 9 - AS20632 19705 1.1% 2463.1 -- PETERSTAR-AS PeterStar 10 - AS27738 17426 1.0% 51.3 -- Ecuadortelecom S.A. 11 - AS24560 15430 0.8% 19.3 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 12 - AS31148 14932 0.8% 36.2 -- FREENET-AS FreeNet ISP 13 - AS19223 12750 0.7% 12750.0 -- NTEGRATED-SOLUTIONS - Ntegrated Solutions 14 - AS6316 11179 0.6% 2235.8 -- AS-PAETEC-NET - PaeTec Communications, Inc. 15 - AS45595 10053 0.6% 60.9 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited 16 - AS16322 8751 0.5% 71.1 -- PARSONLINE PARSONLINE Autonomous System 17 - AS3255 8074 0.5% 49.8 -- UARNET-AS Ukrainian Academic and Research Network 18 - AS4 8066 0.5% 6.0 -- Maria Irma Salazar 19 - AS9583 7792 0.4% 9.5 -- SIFY-AS-IN Sify Limited 20 - AS14522 7656 0.4% 37.3 -- Satnet TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS19223 12750 0.7% 12750.0 -- NTEGRATED-SOLUTIONS - Ntegrated Solutions 2 - AS32528 23173 1.3% 5793.2 -- ABBOTT Abbot Labs 3 - AS19743 31349 1.7% 5224.8 -- 4 - AS42116 155829 8.6% 2554.6 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 5 - AS20632 19705 1.1% 2463.1 -- PETERSTAR-AS PeterStar 6 - AS6316 11179 0.6% 2235.8 -- AS-PAETEC-NET - PaeTec Communications, Inc. 7 - AS4 8066 0.5% 6.0 -- Maria Irma Salazar 8 - AS39353 3701 0.2% 1233.7 -- PRINCAST-AS Gobierno del Principado de Asturias 9 - AS40329 1142 0.1% 1142.0 -- REH-PROPERTY - REH Property 10 - AS38528 977 0.1% 977.0 -- LANIC-AS-AP Lao National Internet Committee 11 - AS53362 961 0.1% 961.0 -- MIXIT-AS - Mixit, Inc. 12 - AS8163 848 0.1% 848.0 -- METROTEL REDES S.A. 13 - AS10099 732 0.0% 732.0 -- HKUNICOM1-AP China Unicom (Hong Kong) Operations Limited 14 - AS57282 612 0.0% 612.0 -- SOPREX-AS SOPREX D.o.o. 15 - AS55696 596 0.0% 596.0 -- SCOM-AS-ID Starcom Solusindo PT. 16 - AS48068 566 0.0% 566.0 -- VISONIC Visonic Ltd 17 - AS11943 533 0.0% 533.0 -- GLOBE - Globe Wireless 18 - AS33076 505 0.0% 505.0 -- ISC-TGD1 Internet Systems Consortium, Inc. 19 - AS24562 493 0.0% 493.0 -- UNESCAP-AS-AP The United Nations Economic and Social Commission for Asia and the Pacific (ESCAP) 20 - AS10445 1878 0.1% 469.5 -- HTG - Huntleigh Telcom TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 84.204.132.0/24 19656 1.0% AS20632 -- PETERSTAR-AS PeterStar 2 - 67.97.156.0/24 12750 0.7% AS19223 -- NTEGRATED-SOLUTIONS - Ntegrated Solutions 3 - 130.36.34.0/24 11582 0.6% AS32528 -- ABBOTT Abbot Labs 4 - 130.36.35.0/24 11582 0.6% AS32528 -- ABBOTT Abbot Labs 5 - 176.213.100.0/22 7269 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 6 - 65.122.196.0/24 7193 0.4% AS19743 -- 7 - 190.96.120.0/21 6725 0.3% AS4 -- Maria Irma Salazar 8 - 66.248.104.0/21 6487 0.3% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 9 - 95.78.100.0/22 6364 0.3% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 10 - 95.78.104.0/22 6364 0.3% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 11 - 95.78.108.0/22 6357 0.3% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 12 - 95.78.88.0/22 6357 0.3% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 13 - 95.78.84.0/22 6351 0.3% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 14 - 46.147.92.0/22 6328 0.3% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 15 - 46.147.120.0/22 6320 0.3% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 16 - 95.78.0.0/22 6303 0.3% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 17 - 95.78.20.0/22 6294 0.3% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 18 - 95.78.8.0/22 6264 0.3% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 19 - 95.78.80.0/22 6264 0.3% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 20 - 95.78.16.0/22 6262 0.3% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 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 cidr-report at potaroo.net Fri Dec 2 16:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 2 Dec 2011 22:00:00 GMT Subject: The Cidr Report Message-ID: <201112022200.pB2M00ba061216@wattle.apnic.net> This report has been generated at Fri Dec 2 21:12:17 2011 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 25-11-11 385336 226339 26-11-11 385360 226218 27-11-11 385375 226061 28-11-11 385468 226133 29-11-11 385372 226417 30-11-11 385256 226157 01-12-11 385044 226357 02-12-11 385297 226059 AS Summary 39564 Number of ASes in routing system 16668 Number of ASes announcing only one prefix 3484 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 108964864 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'). --- 02Dec11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 385422 226094 159328 41.3% All ASes AS6389 3484 221 3263 93.7% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS18566 2094 406 1688 80.6% COVAD - Covad Communications Co. AS4766 2514 996 1518 60.4% KIXS-AS-KR Korea Telecom AS7029 2953 1527 1426 48.3% WINDSTREAM - Windstream Communications Inc AS22773 1507 113 1394 92.5% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1508 212 1296 85.9% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS4323 1617 388 1229 76.0% TWTC - tw telecom holdings, inc. AS28573 1538 391 1147 74.6% NET Servicos de Comunicao S.A. AS1785 1856 783 1073 57.8% AS-PAETEC-NET - PaeTec Communications, Inc. AS19262 1388 402 986 71.0% VZGNI-TRANSIT - Verizon Online LLC AS10620 1703 726 977 57.4% Telmex Colombia S.A. AS7552 1386 415 971 70.1% VIETEL-AS-AP Vietel Corporation AS7303 1239 359 880 71.0% Telecom Argentina S.A. AS18101 959 156 803 83.7% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS8151 1338 546 792 59.2% Uninet S.A. de C.V. AS8402 1492 709 783 52.5% CORBINA-AS OJSC "Vimpelcom" AS30036 1435 681 754 52.5% MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp AS4808 1079 336 743 68.9% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7545 1626 947 679 41.8% TPG-INTERNET-AP TPG Internet Pty Ltd AS17974 1653 974 679 41.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS3356 1102 455 647 58.7% LEVEL3 Level 3 Communications AS17676 673 72 601 89.3% GIGAINFRA Softbank BB Corp. AS24560 985 392 593 60.2% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS20115 1603 1029 574 35.8% CHARTER-NET-HKY-NC - Charter Communications AS4804 664 95 569 85.7% MPX-AS Microplex PTY LTD AS22561 931 376 555 59.6% DIGITAL-TELEPORT - Digital Teleport Inc. AS22047 582 33 549 94.3% VTR BANDA ANCHA S.A. AS17488 945 413 532 56.3% HATHWAY-NET-AP Hathway IP Over Cable Internet AS3549 951 422 529 55.6% GBLX Global Crossing Ltd. AS7011 1169 647 522 44.7% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. Total 43974 15222 28752 65.4% 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- 41.222.79.0/24 AS37345 MEDALLION 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.175.222.0/23 AS30058 FDCSERVERS - FDCservers.net 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 69.6.80.0/24 AS13442 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 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 80.88.10.0/24 AS33774 DJAWEB 98.159.96.0/20 AS46975 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 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 Inc. 172.45.1.0/24 AS29571 CITelecom-AS 172.45.2.0/24 AS29571 CITelecom-AS 172.45.3.0/24 AS29571 CITelecom-AS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 176.227.144.0/20 AS29119 SERVIHOSTING-AS ServiHosting Networks S.L. 190.104.32.0/21 AS27882 Telef?nica Celular de Bolivia S.A. 200.6.93.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.94.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.95.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.23.84.0/24 AS8151 Uninet S.A. de C.V. 200.24.73.0/24 AS26061 Equant Colombia 200.33.40.0/24 AS11172 Alestra, S. de R.L. de C.V. 200.34.0.0/20 AS6342 Instituto Tecnol?gico y de Estudios Superiores de Monterrey 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 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.9.55.0/24 AS2764 AAPT AAPT Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 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.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.160.152.0/22 AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 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.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 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 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 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 209.222.240.0/22 AS19747 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From jeff.tantsura at ericsson.com Fri Dec 2 16:14:35 2011 From: jeff.tantsura at ericsson.com (Jeff Tantsura) Date: Fri, 2 Dec 2011 17:14:35 -0500 Subject: bgp update destroying transit on redback routers ? In-Reply-To: <20111202143554.GA66539@snar.spb.ru> References: <0ED867EB33AB2B45AAB470D5A64CDBF6181C25624E@EUSAACMS0701.eamcs.ericsson.se> <20111202143554.GA66539@snar.spb.ru> Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF6181C2EDEB6@EUSAACMS0701.eamcs.ericsson.se> Hi Alexandre, You are right, the behavior is exactly as per RFC4271 section 6: "When any of the conditions described here are detected, a NOTIFICATION message, with the indicated Error Code, Error Subcode, and Data fields, is sent, and the BGP connection is closed. So because ASN 0 in AGGREGATOR is seen as a malformed UPDATE we send 3/9 and close the connection. Ideally it should be treated as "treat-as-withdraw" as per draft-chen-ebgp-error-handling, however please note - this is still a draft, not a normative document and with all my support it takes time to implement. Once again, we understand the implications for our customers and hence going to disable ASN 0 check. P.S. We have strong evidence that the update in question was caused by a bug on a freshly updated router (I'm not going to disclose the vendor) Regards, Jeff -----Original Message----- From: Alexandre Snarskii [mailto:snar at snar.spb.ru] Sent: Friday, December 02, 2011 6:36 AM To: Jeff Tantsura Cc: nanog at nanog.org Subject: Re: bgp update destroying transit on redback routers ? On Thu, Dec 01, 2011 at 04:56:43PM -0500, Jeff Tantsura wrote: > Hi, > > Let me take it over from now on, I'm the IP Routing/MPLS Product > Manager at Ericsson responsible for all routing protocols. > There's nothing wrong in checking ASN in AGGREGATOR, we don't really > want see ASN 0 anywhere, that's how draft-wkumari-idr-as0 > (draft-ietf-idr-as0-00) came into the worlds. This draft says that If a BGP speaker receives a route which has an AS number of zero in the AS_PATH (or AS4_PATH) attribute, it SHOULD be logged and treated as a WITHDRAW. This same behavior applies to routes containing zero as the Aggregator or AS4 Aggregator. but observed behaviour was more like following: If a BGP speaker receives [bad route] it MUST close session immediately with NOTIFICATION Error Code 'Update Message Error' and subcode 'Error with optional attribute'. -- In theory, there is no difference between theory and practice. But, in practice, there is. From Valdis.Kletnieks at vt.edu Fri Dec 2 16:56:17 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 02 Dec 2011 17:56:17 -0500 Subject: IP addresses are now assets In-Reply-To: Your message of "Fri, 02 Dec 2011 12:37:29 MST." References: <44762.1322812111@turing-police.cc.vt.edu> <236167AF-4DEB-48D5-A7ED-ED0A1F0DEEA5@arin.net> <38B33D90-8E1E-46D5-B08E-6207CAD8E3B8@arin.net> Message-ID: <12129.1322866577@turing-police.cc.vt.edu> On Fri, 02 Dec 2011 12:37:29 MST, joshua sahala said: > the speculative market exists and is growing, why do certain factions > of the community keep trying to pretend that it doesn't? I'm sure at least some of those factions pretend it doesn't because admitting it does would be a game changer. I'm sure that *somebody* has a business model that assumes the non-existence of the speculatie market. And everybody knows that you never admit the business model is crap until *after* the IPO. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From owen at delong.com Fri Dec 2 17:01:56 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 2 Dec 2011 15:01:56 -0800 Subject: IP addresses are now assets In-Reply-To: <12129.1322866577@turing-police.cc.vt.edu> References: <44762.1322812111@turing-police.cc.vt.edu> <236167AF-4DEB-48D5-A7ED-ED0A1F0DEEA5@arin.net> <38B33D90-8E1E-46D5-B08E-6207CAD8E3B8@arin.net> <12129.1322866577@turing-police.cc.vt.edu> Message-ID: <4B760F89-5969-4EE1-B111-E9BF0B9F20B0@delong.com> On Dec 2, 2011, at 2:56 PM, Valdis.Kletnieks at vt.edu wrote: > On Fri, 02 Dec 2011 12:37:29 MST, joshua sahala said: >> the speculative market exists and is growing, why do certain factions >> of the community keep trying to pretend that it doesn't? > > I'm sure at least some of those factions pretend it doesn't because admitting > it does would be a game changer. I'm sure that *somebody* has a business model > that assumes the non-existence of the speculatie market. And everybody knows > that you never admit the business model is crap until *after* the IPO. ;) > I admit it exists, but, I think it is currently relatively small and would hate to provide it any additional incentives to grow. I think it has the potential to be very harmful to the IPv4 internet in general. As long as it is relatively small, it's like a mosquito. Turning it into a B-17 would be bad. Just my $0.02. Owen From bonomi at mail.r-bonomi.com Fri Dec 2 17:55:23 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Fri, 2 Dec 2011 17:55:23 -0600 (CST) Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: <20111202123312.BA389E70@resin04.mta.everyone.net> Message-ID: <201112022355.pB2NtNCh014147@mail.r-bonomi.com> "Scott Weeks" wrote: > > Apologies for the rapid-shot email. It's Friday... :-) > > bmanning at vacation.karoshi.com wrote: > >> On Thu, Dec 01, 2011 at 04:35:27PM -0500, David Radcliffe wrote: >> > The reason it is not more accepted is too many people still think "If I >> > cannot see you you must not be working." >> >> actually, i've heard the real reason is corporate liability ... >> that said, there is an advantage for team f2f mtgs on a periodic >> basis. > > I don't follow. Could you elaborate? What is the liability? I don't know for certain, but I expect "work at home' employeees fall under the scope of the employers "Workmans Compenstation" liability covrerage, with regard to injuries sustained "on the job". Now, consider what happens if the employee sustains an 'on the job' injury, due to something in the 'workplace' (done by the homeowner on his own time) that is _NOT_ "OHSA-compliant". At that point, as it is sometimes put in U.S. Dept. of Ag. bureaucratese: 'A large quantity of organic waste/byproducts forcefully impacted the high-speed rotary impeller." From eric at roxanne.org Fri Dec 2 18:09:55 2011 From: eric at roxanne.org (Eric Gauthier) Date: Fri, 2 Dec 2011 19:09:55 -0500 Subject: ISP access in Ogden, UT Message-ID: <20111203000954.GA27743@roxanne.org> looking for 100 mbps access to a new office in Ogden, UT but don't know who the decent players are who already have fiber locally so we can avoid huge build out costs. Suggestions off list would be appreciated! - Eric :) From bret at getjive.com Fri Dec 2 18:26:13 2011 From: bret at getjive.com (Bret Palsson) Date: Fri, 2 Dec 2011 17:26:13 -0700 Subject: ISP access in Ogden, UT In-Reply-To: <20111203000954.GA27743@roxanne.org> References: <20111203000954.GA27743@roxanne.org> Message-ID: <-8215472759514631341@unknownmsgid> Xmission if they service there. Sent from my iPhone On Dec 2, 2011, at 5:10 PM, Eric Gauthier wrote: > looking for 100 mbps access to a new office in Ogden, UT but don't > know who the decent players are who already have fiber locally so > we can avoid huge build out costs. Suggestions off list would be > appreciated! > > - Eric :) > From mysidia at gmail.com Fri Dec 2 18:26:48 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 2 Dec 2011 18:26:48 -0600 Subject: IP addresses are now assets In-Reply-To: <20111202040423.GL1397@manor.msen.com> References: <20111202040423.GL1397@manor.msen.com> Message-ID: On Thu, Dec 1, 2011 at 10:04 PM, Michael R. Wayne wrote: > From http://www.detnews.com/article/20111201/BIZ/112010483/1361/Borders-selling-Internet-addresses-for-$786-000 > ? Borders selling Internet addresses for $786,000 Your IP address is an "asset" like the office you rent to setup a business in. Happening to be the occupant gives you certain rights, but it doesn't automatically make the space some property that the occupant automatically gains ownership of. If your lease permits it, you can probably re-sell your right to occupy the space, so long as the lease says you can do that, and you follow all the terms and requirements agreed upon. So there's no issue with Borders "selling" addresses, so long as the proper policies are being followed for transfer of addresses. What underlies all the "occupants" of IP address space, are agreements with IP address registries, and the community, to provide unique usage of IP addresses. The existence of unique IP addresses exist only because of the community and the address registries' efforts; the community "owns" the uniqueness of IP addresses, which is a kind of intangible property, because they built this, and you own what you build. That is... uniqueness of IP address entries in an address registry you operate doesn't happen by accident. -- -JH From jra at baylink.com Fri Dec 2 18:44:39 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 2 Dec 2011 19:44:39 -0500 (EST) Subject: IP addresses are now assets In-Reply-To: Message-ID: <1892326.1279.1322873079245.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "John Curran" > On Dec 2, 2011, at 2:48 AM, wrote: > > Would it be correct to summarize the ARIN position as "It's murkier than Cerner > > makes it out to be, and some lawyers are gonna get stinking filthy rich > > litigating this one"? > > It's pretty simple: you can write a contract to transfer IP > addresses in accordance with policy, and we are now seeing > most parties come to us in advance either to prequalify or > make the sale conditional on approval. No, Valdis, the ARIN position is "if we wanted Curran to have a sense of humor, we'd have issued him one". :-) 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 http://photo.imageinc.us +1 727 647 1274 From jtowne at slic.com Fri Dec 2 18:47:34 2011 From: jtowne at slic.com (Jonathan Towne) Date: Fri, 2 Dec 2011 19:47:34 -0500 Subject: Overall Netflix bandwidth usage numbers on a network? Message-ID: <20111203004732.GH13315@hijacked.us> Been lurking for a while and posed a question to a few folks without much response, figured someone here might've done something like this already. So, before I go about building wheels that already exist: I'm interested in doing a bit of a passive survey of bandwidth usage on my network (smallish isp, a few thousand DSL/FTTx customers) to understand the percentage of average/overall traffic generated by Netflix streaming. What I have available is a few gigabit transport switches providing me with mirror ports, a juniper MX series router running 10.4 code, plenty of BSD machines and libpcap-fu. What I'm looking for is either a timed-average or moments-glance number of the traffic. For instance, on an interface moving 150mbit/sec total, 50mbit/sec of it is attributed to Netflix right now. I'm pretty handy with RRDtool, so that isn't out of the question, either. I've really only spent dinnertime considering this, but have come up with two potential approaches so far, and haven't actively investigated either of them: * firewall terms and counters on the MX router + snmp * writing a quick libpcap application to filter and count in a completely out-of-band way on one of my monitoring hosts Some challenges I can see: * Nailing down the streaming source for Netflix, that is, IP ranges etc. * Making assumptions about CDN source IPs that could be used for something else, and further, should I care? Happy to hear thoughts about this, helpful or not! I know Netflix themselves have probably done plenty of studies like this, but pretty likely not limited to my customer base. Not aiming for anything creepy or crazy, just some vague understanding of what's going on, and the ability to do some trending for future planning. -- Jonathan Towne From andy-nanog at bash.sh Fri Dec 2 18:56:34 2011 From: andy-nanog at bash.sh (Andrew Mulholland) Date: Sat, 3 Dec 2011 00:56:34 +0000 Subject: Overall Netflix bandwidth usage numbers on a network? In-Reply-To: <20111203004732.GH13315@hijacked.us> References: <20111203004732.GH13315@hijacked.us> Message-ID: Surely this is what Netflow is for. no need to re-invent the wheel. Andrew On Sat, Dec 3, 2011 at 12:47 AM, Jonathan Towne wrote: > Been lurking for a while and posed a question to a few folks without much > response, figured someone here might've done something like this already. > > So, before I go about building wheels that already exist: > > I'm interested in doing a bit of a passive survey of bandwidth usage on > my network (smallish isp, a few thousand DSL/FTTx customers) to understand > the percentage of average/overall traffic generated by Netflix streaming. > > What I have available is a few gigabit transport switches providing me with > mirror ports, a juniper MX series router running 10.4 code, plenty of BSD > machines and libpcap-fu. > > What I'm looking for is either a timed-average or moments-glance number > of the traffic. For instance, on an interface moving 150mbit/sec total, > 50mbit/sec of it is attributed to Netflix right now. I'm pretty handy with > RRDtool, so that isn't out of the question, either. > > I've really only spent dinnertime considering this, but have come up with > two potential approaches so far, and haven't actively investigated either > of them: > > * firewall terms and counters on the MX router + snmp > * writing a quick libpcap application to filter and count in a completely > out-of-band way on one of my monitoring hosts > > Some challenges I can see: > > * Nailing down the streaming source for Netflix, that is, IP ranges etc. > * Making assumptions about CDN source IPs that could be used for something > else, and further, should I care? > > Happy to hear thoughts about this, helpful or not! I know Netflix > themselves > have probably done plenty of studies like this, but pretty likely not > limited > to my customer base. Not aiming for anything creepy or crazy, just some > vague understanding of what's going on, and the ability to do some trending > for future planning. > > -- Jonathan Towne > > From jtowne at slic.com Fri Dec 2 18:58:48 2011 From: jtowne at slic.com (Jonathan Towne) Date: Fri, 2 Dec 2011 19:58:48 -0500 Subject: Overall Netflix bandwidth usage numbers on a network? In-Reply-To: References: <20111203004732.GH13315@hijacked.us> Message-ID: <20111203005847.GI13315@hijacked.us> Wow.. not sure how I missed that option. Exactly why I posted before dumping a bunch of time into a bottomless bucket! Thanks.. :) -- Jonathan Towne On Sat, Dec 03, 2011 at 12:56:34AM +0000, Andrew Mulholland scribbled: # Surely this is what Netflow is for. # # # no need to re-invent the wheel. # # # Andrew # # # On Sat, Dec 3, 2011 at 12:47 AM, Jonathan Towne wrote: # # > Been lurking for a while and posed a question to a few folks without much # > response, figured someone here might've done something like this already. # > # > So, before I go about building wheels that already exist: # > # > I'm interested in doing a bit of a passive survey of bandwidth usage on # > my network (smallish isp, a few thousand DSL/FTTx customers) to understand # > the percentage of average/overall traffic generated by Netflix streaming. # > # > What I have available is a few gigabit transport switches providing me with # > mirror ports, a juniper MX series router running 10.4 code, plenty of BSD # > machines and libpcap-fu. # > # > What I'm looking for is either a timed-average or moments-glance number # > of the traffic. For instance, on an interface moving 150mbit/sec total, # > 50mbit/sec of it is attributed to Netflix right now. I'm pretty handy with # > RRDtool, so that isn't out of the question, either. # > # > I've really only spent dinnertime considering this, but have come up with # > two potential approaches so far, and haven't actively investigated either # > of them: # > # > * firewall terms and counters on the MX router + snmp # > * writing a quick libpcap application to filter and count in a completely # > out-of-band way on one of my monitoring hosts # > # > Some challenges I can see: # > # > * Nailing down the streaming source for Netflix, that is, IP ranges etc. # > * Making assumptions about CDN source IPs that could be used for something # > else, and further, should I care? # > # > Happy to hear thoughts about this, helpful or not! I know Netflix # > themselves # > have probably done plenty of studies like this, but pretty likely not # > limited # > to my customer base. Not aiming for anything creepy or crazy, just some # > vague understanding of what's going on, and the ability to do some trending # > for future planning. # > # > -- Jonathan Towne # > # > From mpalmer at hezmatt.org Fri Dec 2 19:01:26 2011 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Sat, 3 Dec 2011 12:01:26 +1100 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: <201112022355.pB2NtNCh014147@mail.r-bonomi.com> References: <20111202123312.BA389E70@resin04.mta.everyone.net> <201112022355.pB2NtNCh014147@mail.r-bonomi.com> Message-ID: <20111203010126.GO3707@hezmatt.org> On Fri, Dec 02, 2011 at 05:55:23PM -0600, Robert Bonomi wrote: > > "Scott Weeks" wrote: > > > > Apologies for the rapid-shot email. It's Friday... :-) > > > > bmanning at vacation.karoshi.com wrote: > > > >> On Thu, Dec 01, 2011 at 04:35:27PM -0500, David Radcliffe wrote: > >> > The reason it is not more accepted is too many people still think "If I > >> > cannot see you you must not be working." > >> > >> actually, i've heard the real reason is corporate liability ... > >> that said, there is an advantage for team f2f mtgs on a periodic > >> basis. > > > > I don't follow. Could you elaborate? What is the liability? > > I don't know for certain, but I expect "work at home' employeees fall under > the scope of the employers "Workmans Compenstation" liability covrerage, > with regard to injuries sustained "on the job". "There are those who say this has already happened" http://www.news.com.au/business/telstra-forced-to-pay-costs-compensation-after-worker-dale-hargreaves-slips-while-working-at-home/story-e6frfm1i-1226081649913 Now, I'm sure the facts of the matter haven't gotten in the way of the story there, but I'm struggling to come up with a set of circumstances which *don't* involve an application of palm to face. - Matt -- You know you have a distributed system when the crash of a computer you?ve never heard of stops you from getting any work done. -- Leslie Lamport "Security Engineering: A Guide to Building Dependable Distributed Systems" From jcurran at arin.net Fri Dec 2 21:33:55 2011 From: jcurran at arin.net (John Curran) Date: Sat, 3 Dec 2011 03:33:55 +0000 Subject: IP addresses are now assets In-Reply-To: <1892326.1279.1322873079245.JavaMail.root@benjamin.baylink.com> References: <1892326.1279.1322873079245.JavaMail.root@benjamin.baylink.com> Message-ID: <5CE133DA-64F6-4E95-B010-FA1684D45743@corp.arin.net> On Dec 2, 2011, at 7:44 PM, Jay Ashworth wrote: > > No, Valdis, the ARIN position is "if we wanted Curran to have a sense of humor, > we'd have issued him one". Changes in this area may be proposed via the ARIN Consultation and Suggestion Process - ;-) /John John Curran President and CEO ARIN From bmanning at vacation.karoshi.com Fri Dec 2 22:01:29 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 3 Dec 2011 04:01:29 +0000 Subject: IP addresses are now assets In-Reply-To: <5CE133DA-64F6-4E95-B010-FA1684D45743@corp.arin.net> References: <1892326.1279.1322873079245.JavaMail.root@benjamin.baylink.com> <5CE133DA-64F6-4E95-B010-FA1684D45743@corp.arin.net> Message-ID: <20111203040129.GA16517@vacation.karoshi.com.> On Sat, Dec 03, 2011 at 03:33:55AM +0000, John Curran wrote: > On Dec 2, 2011, at 7:44 PM, Jay Ashworth wrote: > > > > No, Valdis, the ARIN position is "if we wanted Curran to have a sense of humor, > > we'd have issued him one". > > > Changes in this area may be proposed via the ARIN Consultation and > Suggestion Process - > > ;-) > /John > > John Curran > President and CEO > ARIN > Mischief Managed. The text of the submitted suggestion is included below. Sincerely, Communications and Member Services American Registry for Internet Numbers (ARIN) -------------------------------------------------------------------------------- Suggestion received and needing confirmation: That ARIN or a party it designates assign one or more sense(s) of humour to the CEO. -------------------------------------------------------------------------------- The ARIN Consultation and Suggestion Process (ACSP) is available at: http://www.arin.net/participate/acsp/index.html /bill From jra at baylink.com Fri Dec 2 22:05:09 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 02 Dec 2011 23:05:09 -0500 Subject: IP addresses are now assets In-Reply-To: <20111203040129.GA16517@vacation.karoshi.com.> References: <1892326.1279.1322873079245.JavaMail.root@benjamin.baylink.com> <5CE133DA-64F6-4E95-B010-FA1684D45743@corp.arin.net> <20111203040129.GA16517@vacation.karoshi.com.> Message-ID: <21f7b846-4603-4b4b-9219-c457b47ccb66@email.android.com> Ah... *this* is the Whacky Weekend thread. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. bmanning at vacation.karoshi.com wrote: On Sat, Dec 03, 2011 at 03:33:55AM +0000, John Curran wrote: > On Dec 2, 2011, at 7:44 PM, Jay Ashworth wrote: > > > > No, Valdis, the ARIN position is "if we wanted Curran to have a sense of humor, > > we'd have issued him one". > > > Changes in this area may be proposed via the ARIN Consultation and > Suggestion Process - ; > > ;-) > /John > > John Curran > President and CEO > ARIN > Mischief Managed. The text of the submitted suggestion is included below. Sincerely, Communications and Member Services American Registry for Internet Numbers (ARIN) _____________________________________________ Suggestion received and needing confirmation: That ARIN or a party it designates assign one or more sense(s) of humour to the CEO. _____________________________________________ The ARIN Consultation and Suggestion Process (ACSP) is available at: http://www.arin.net/participate/acsp/index.html /bill From jay at west.net Sat Dec 3 00:06:11 2011 From: jay at west.net (Jay Hennigan) Date: Fri, 02 Dec 2011 22:06:11 -0800 Subject: RFOs, was:ATT GigE issue... In-Reply-To: References: <20111130021700.BDLG8.157079.root@hrndva-web07-z01> <56C0B9C7-937A-465B-B8C4-65D9E690EDB6@gmail.com> <4ED650E4.3050705@ispn.net> <4ED66BD3.3050603@ttec.com> Message-ID: <4ED9BC53.9050900@west.net> On 11/30/11 11:35 AM, Mike Jones wrote: > On 30 November 2011 17:45, Joe Maimon wrote: > "The outage was caused by an engineer turning off the wrong router, it > has been turned back on and service restored" > "The outage appears to have been caused by a bug in the routers > firmware, we are working with the vendor on a fix" > "There was an outage, now service is back up again" When the RFO gets filtered through the marketing department, it gets interesting, and totally useless. This is what we got as an official RFO for an outsourced hosted VoIP service (carrier shall remain nameless) that was for all practical purposes down hard for two DAYS due to a botched planned software upgrade, verbatim and in its entirety: "Coincident with this upgrade, we experienced an Operating System-level failure on the underlying application server platform which had the effect of defeating the redundancy paradigm designed into our service architecture." -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From jeff.tantsura at ericsson.com Sat Dec 3 02:21:33 2011 From: jeff.tantsura at ericsson.com (Jeff Tantsura) Date: Sat, 3 Dec 2011 03:21:33 -0500 Subject: draft-ietf-idr-as0-00 (bgp update destroying transit on redback routers ?) In-Reply-To: <26E0D18F-F80E-4EF0-B49A-6FF59957B0C3@net-geek.org> References: <0ED867EB33AB2B45AAB470D5A64CDBF6181C25624E@EUSAACMS0701.eamcs.ericsson.se> <26E0D18F-F80E-4EF0-B49A-6FF59957B0C3@net-geek.org> Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF6181C2EDF8A@EUSAACMS0701.eamcs.ericsson.se> Hi Daniel, I do understand the use of it however have my doubts about usability as such, I'd really like to see anyone using it for the reason below. All of updates with ASN 0 I have seen in the past few years were there due to software bugs, not explicit configuration - same as this one. Warren/ idr - I do support addition of AGGREGATOR in the draft Regards, Jeff P.S. Jeffrey/John - this draft makes use of "no-aggregator-id" de facto illigal, are you (your customers) OK with it? Thanks! -----Original Message----- From: Daniel Ginsburg [mailto:dbg at net-geek.org] Sent: Friday, December 02, 2011 5:13 AM To: Jeff Tantsura; Warren Kumari Cc: nanog at nanog.org; idr at ietf.org Subject: draft-ietf-idr-as0-00 (bgp update destroying transit on redback routers ?) Hi, This is true that "no-aggregator-id" knob zeroes out the AGGREGATOR attribute. The knob, as far as I was able to find out, dates back to gated and there's a reason why it was introduced - it helps to avoid unnecessary updates. Assume that an aggregate route is generated by two (or more) speakers in the network. These two aggregates differ only in AGGREGATOR attribute. One of the aggregates is preferred within the network (due to IGP metric, for instance, or any other reasons) and is announced out. Now if something changes within the network and the other instance of the aggregate becomes preferred, the network has to issue an outward update different from the previous only in AGGREGATOR attribute, which is completely superfluous. If the network employs the "no-aggregator-id" knob to zero out the AGGREGATOR attribute, both instances of the aggregate route are completely equivalent, and no redundant outward updates have to be send if one instance becomes better than another due to some internal event, which nobody in the Internet cares about. In other words, the "no-aggregator-id" knob has valid operational reasons to be used. And, IMHO, the draft-ietf-idr-as0-00 should not prohibit AS0 in AGGREGATOR attribute. On 02.12.2011, at 1:56, Jeff Tantsura wrote: > Hi, > > Let me take it over from now on, I'm the IP Routing/MPLS Product Manager at Ericsson responsible for all routing protocols. > There's nothing wrong in checking ASN in AGGREGATOR, we don't really want see ASN 0 anywhere, that's how draft-wkumari-idr-as0 (draft-ietf-idr-as0-00) came into the worlds. > > To my knowledge - the only vendor which allows changing ASN in AGGREGATOR is Juniper, see "no-aggregator-id", in the past I've tried to talk to Yakov about it, without any results though. > So for those who have it configured - please rethink whether you really need it. > > As for SEOS - understanding that this badly affects our customers and not having draft-ietf-idr-error-handling fully implemented yet, we will temporarily disable this check in our code. > Patch will be made available. > > Please contact me for any further clarifications. > > Regards, > Jeff > > P.S. Warren has recently included AGGREGATOR in the draft, please see > > 2. Behavior > This document specifies that a BGP speaker MUST NOT originate or > propagate a route with an AS number of zero. If a BGP speaker > receives a route which has an AS number of zero in the AS_PATH (or > AS4_PATH) attribute, it SHOULD be logged and treated as a WITHDRAW. > This same behavior applies to routes containing zero as the > Aggregator or AS4 Aggregator. > From maxsec at gmail.com Sat Dec 3 02:36:11 2011 From: maxsec at gmail.com (Martin Hepworth) Date: Sat, 3 Dec 2011 08:36:11 +0000 Subject: Overall Netflix bandwidth usage numbers on a network? In-Reply-To: <20111203005847.GI13315@hijacked.us> References: <20111203004732.GH13315@hijacked.us> <20111203005847.GI13315@hijacked.us> Message-ID: Also checkout Adrian Cockcroft presentations on their architecture which describes how they use aws and CDns etc Martin On Saturday, 3 December 2011, Jonathan Towne wrote: > Wow.. not sure how I missed that option. Exactly why I posted before dumping > a bunch of time into a bottomless bucket! > > Thanks.. :) > > -- Jonathan Towne > > > On Sat, Dec 03, 2011 at 12:56:34AM +0000, Andrew Mulholland scribbled: > # Surely this is what Netflow is for. > # > # > # no need to re-invent the wheel. > # > # > # Andrew > # > # > # On Sat, Dec 3, 2011 at 12:47 AM, Jonathan Towne wrote: > # > # > Been lurking for a while and posed a question to a few folks without much > # > response, figured someone here might've done something like this already. > # > > # > So, before I go about building wheels that already exist: > # > > # > I'm interested in doing a bit of a passive survey of bandwidth usage on > # > my network (smallish isp, a few thousand DSL/FTTx customers) to understand > # > the percentage of average/overall traffic generated by Netflix streaming. > # > > # > What I have available is a few gigabit transport switches providing me with > # > mirror ports, a juniper MX series router running 10.4 code, plenty of BSD > # > machines and libpcap-fu. > # > > # > What I'm looking for is either a timed-average or moments-glance number > # > of the traffic. For instance, on an interface moving 150mbit/sec total, > # > 50mbit/sec of it is attributed to Netflix right now. I'm pretty handy with > # > RRDtool, so that isn't out of the question, either. > # > > # > I've really only spent dinnertime considering this, but have come up with > # > two potential approaches so far, and haven't actively investigated either > # > of them: > # > > # > * firewall terms and counters on the MX router + snmp > # > * writing a quick libpcap application to filter and count in a completely > # > out-of-band way on one of my monitoring hosts > # > > # > Some challenges I can see: > # > > # > * Nailing down the streaming source for Netflix, that is, IP ranges etc. > # > * Making assumptions about CDN source IPs that could be used for something > # > else, and further, should I care? > # > > # > Happy to hear thoughts about this, helpful or not! I know Netflix > # > themselves > # > have probably done plenty of studies like this, but pretty likely not > # > limited > # > to my customer base. Not aiming for anything creepy or crazy, just some > # > vague understanding of what's going on, and the ability to do some trending > # > for future planning. > # > > # > -- Jonathan Towne > # > > # > > > -- -- Martin Hepworth Oxford, UK From jra at baylink.com Sat Dec 3 10:40:54 2011 From: jra at baylink.com (Jay Ashworth) Date: Sat, 3 Dec 2011 11:40:54 -0500 (EST) Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: <4ED8C3C5.2010404@resolution.de> Message-ID: <4415664.1377.1322930454781.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Thorsten Dahm" > The downside of this is that you are not around in the office in case > someone wants to talk to you. I often end up with guys from our > operations team or other teams stopping at my desk and ask questions. > Or guys who want to have a quick chat about a problem and want to ask for > an advice or idea. Or people who want to learn Perl and have a > question that you can answer in 30 seconds. > > Yes, I know, they can call you, or send an Email, but nothing beats > the good old "Let's go for a coffee, I'd like to ask you a question". "Private IRC 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 http://photo.imageinc.us +1 727 647 1274 From brian.peter.dickson at gmail.com Sat Dec 3 11:22:56 2011 From: brian.peter.dickson at gmail.com (Brian Dickson) Date: Sat, 3 Dec 2011 12:22:56 -0500 Subject: [Idr] draft-ietf-idr-as0-00 (bgp update destroying transit on redback routers ?) In-Reply-To: <26E0D18F-F80E-4EF0-B49A-6FF59957B0C3@net-geek.org> References: <0ED867EB33AB2B45AAB470D5A64CDBF6181C25624E@EUSAACMS0701.eamcs.ericsson.se> <26E0D18F-F80E-4EF0-B49A-6FF59957B0C3@net-geek.org> Message-ID: Can anyone familiar with this knob and its usage, answer a question: Would anything break, in terms of use of that knob, if instead of "zeroing" the AGGREGATOR, the local AS (as seen from the outside world, in the case of confederations) were used? Would the functionality of the knob, in reducing updates, be preserved? Would routes be considered malformed or would it trigger any other bad behavior? Perhaps this is a way of resolving the conflict between this knob and the AS0 draft? Brian On Fri, Dec 2, 2011 at 8:12 AM, Daniel Ginsburg wrote: > Hi, > > This is true that "no-aggregator-id" knob zeroes out the AGGREGATOR attribute. > > The knob, as far as I was able to find out, dates back to gated and there's a reason why it was introduced - it helps to avoid unnecessary updates. Assume that an aggregate route is generated by two (or more) speakers in the network. These two aggregates differ only in AGGREGATOR attribute. One of the aggregates is preferred within the network (due to IGP metric, for instance, or any other reasons) and is announced out. Now if something changes within the network and the other instance of the aggregate becomes preferred, the network has to issue an outward update different from the previous only in AGGREGATOR attribute, which is completely superfluous. > > If the network employs the "no-aggregator-id" knob to zero out the AGGREGATOR attribute, both instances of the aggregate route are completely equivalent, and no redundant outward updates have to be send if one instance becomes better than another due to some internal event, which nobody in the Internet cares about. > > In other words, the "no-aggregator-id" knob has valid operational reasons to be used. And, IMHO, the draft-ietf-idr-as0-00 should not prohibit AS0 in AGGREGATOR attribute. > > On 02.12.2011, at 1:56, Jeff Tantsura wrote: > >> Hi, >> >> Let me take it over from now on, I'm the IP Routing/MPLS Product Manager at Ericsson responsible for all routing protocols. >> There's nothing wrong in checking ASN in AGGREGATOR, we don't really want see ASN 0 anywhere, that's how draft-wkumari-idr-as0 (draft-ietf-idr-as0-00) came into the worlds. >> >> To my knowledge - the only vendor which allows changing ASN in AGGREGATOR is Juniper, see "no-aggregator-id", in the past I've tried to talk to Yakov about it, without any results though. >> So for those who have it configured - please rethink whether you really need it. >> >> As for SEOS - understanding that this badly affects our customers and not having draft-ietf-idr-error-handling fully implemented yet, we will temporarily disable this check in our code. >> Patch will be made available. >> >> Please contact me for any further clarifications. >> >> Regards, >> Jeff >> >> P.S. Warren has recently ?included AGGREGATOR in the draft, please see >> >> 2. Behavior >> ? This document specifies that a BGP speaker MUST NOT originate or >> ? propagate a route with an AS number of zero. ?If a BGP speaker >> ? receives a route which has an AS number of zero in the AS_PATH (or >> ? AS4_PATH) attribute, it SHOULD be logged and treated as a WITHDRAW. >> ? This same behavior applies to routes containing zero as the >> ? Aggregator or AS4 Aggregator. >> > > _______________________________________________ > Idr mailing list > Idr at ietf.org > https://www.ietf.org/mailman/listinfo/idr From nickellman at gmail.com Sat Dec 3 12:28:26 2011 From: nickellman at gmail.com (brian nikell) Date: Sat, 3 Dec 2011 11:28:26 -0700 Subject: book to buy Message-ID: The filter bubble. Eli pariser -- -B From joly at punkcast.com Sat Dec 3 13:23:13 2011 From: joly at punkcast.com (Joly MacFie) Date: Sat, 3 Dec 2011 14:23:13 -0500 Subject: book to buy In-Reply-To: References: Message-ID: (to save googling and, perhaps, book reading) http://www.thefilterbubble.com/ On Sat, Dec 3, 2011 at 1:28 PM, brian nikell wrote: > The filter bubble. Eli pariser > > -- > -B > -- --------------------------------------------------------------- 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 gary.buhrmaster at gmail.com Sat Dec 3 14:26:55 2011 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Sat, 3 Dec 2011 12:26:55 -0800 Subject: IP addresses are now assets In-Reply-To: <4ed99f4d.8569e70a.7cd1.4ddcSMTPIN_ADDED@mx.google.com> References: <1892326.1279.1322873079245.JavaMail.root@benjamin.baylink.com> <5CE133DA-64F6-4E95-B010-FA1684D45743@corp.arin.net> <4ed99f4d.8569e70a.7cd1.4ddcSMTPIN_ADDED@mx.google.com> Message-ID: On Fri, Dec 2, 2011 at 20:01, wrote: ..... > -------------------------------------------------------------------------------- > Suggestion received and needing confirmation: > > That ARIN or a party it designates assign one or more sense(s) of humour to the CEO. > I believe this suggestion suffers from being too non-specific, and could lead to unintended consequences. ARIN could, for example, assign John a slapstick comedy sense of humor and all the chairs at the next meeting would have a whoopee cushion. And do you really want John taking on the role of a Don Rickles as an insult comedian? And, of course 87% percentage of the population believes that they already have an above average sense of humor (and 62% of the population believes any statement with a statistic in it). I would recommend that this suggestion be revised with community input into what type of humor can achieve a community consensus. Gary From surfer at mauigateway.com Sat Dec 3 15:14:49 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Sat, 3 Dec 2011 13:14:49 -0800 Subject: Looking for a Tier 1 ISP Mentor for career advice. Message-ID: <20111203131449.2DA7AE1@resin03.mta.everyone.net> ------- bonomi at mail.r-bonomi.com wrote: ------- "Scott Weeks" wrote: > bmanning at vacation.karoshi.com wrote: >> >> actually, i've heard the real reason is corporate liability ... >> that said, there is an advantage for team f2f mtgs on a periodic >> basis. > > I don't follow. Could you elaborate? What is the liability? I don't know for certain, but I expect "work at home' employeees fall under the scope of the employers "Workmans Compenstation" liability covrerage, with regard to injuries sustained "on the job". Now, consider what happens if the employee sustains an 'on the job' injury, due to something in the 'workplace' (done by the homeowner on his own time) that is _NOT_ "OHSA-compliant". ------------------------------------------------- Well, if that's a big issue for companies and managers it seems like something easy to write up in the contract for work. Even other things they worry about could be written to protect them and I think we'd still sign up if we didn't have to up root our lives to do work we enjoy. That is unless the gov't forces companies to treat the home as a workplace when telecommuting. I still have the sneaking suspicion that many managers don't feel they have enough control when one telecommutes as well as the other things discussed in this thread. scott 'A large quantity of organic waste/byproducts forcefully impacted the high-speed rotary impeller." I'm going to steal that one... :-) From jra at baylink.com Sat Dec 3 15:25:58 2011 From: jra at baylink.com (Jay Ashworth) Date: Sat, 3 Dec 2011 16:25:58 -0500 (EST) Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: <20111203131449.2DA7AE1@resin03.mta.everyone.net> Message-ID: <23213419.1407.1322947558601.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Scott Weeks" > That is unless the gov't forces companies to treat the home as a workplace > when telecommuting. I still have the sneaking suspicion that many managers > don't feel they have enough control when one telecommutes as well as > the other things discussed in this thread. They tried, a couple years ago. The fecal matter hit the rotary impeller. 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 http://photo.imageinc.us +1 727 647 1274 From mpetach at netflight.com Sat Dec 3 16:24:45 2011 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 3 Dec 2011 14:24:45 -0800 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: <20111202123053.BA389EAF@resin04.mta.everyone.net> References: <20111202123053.BA389EAF@resin04.mta.everyone.net> Message-ID: On Fri, Dec 2, 2011 at 12:30 PM, Scott Weeks wrote: > --- bicknell at ufp.org wrote: > From: Leo Bicknell > > If you have telecommuters _everyone_ in the office should be forced > to work from home at least 2 weeks a year, including the manager. > It's only from that experience you learn to deal with your telecommuting > co-workers in a way that raises everyone's productivity. > --------------------------------------------- > > I have been bemoaning the lack of telecommuting positions available > since I last did that permanently from 1998-2002. ?I could never > figure out how to get the managers since then to understand how to > manage remote workers effectively, as that's what I think the problem > is. ?The manager's ability to value an employee in this century's > methodology, rather than the old way: "wow, he was in the office 10 > hours today. ?He must've gotten a lot of work done". ?When, actually, > the person played around for 6 of those hours while looking busy. > > Having the manager work from home, even temporarily, would solve this. > Now if I can just get them to actually do that... ?:-) Easy. Have the managers manage people halfway around the planet. Only a tiny minority of my team works in the same timezone I do; if I made my team members fit to my office-day work schedule, they'd quickly mutiny. Working from home lets me interact with them at more reasonable hours for them, without causing too much undue impact to my life schedule. It also helps when you're managing people 12,000 miles away; there's almost zero chance of "face to face" time in the office, so you quickly learn to use IRC, IM, and remote access voice conference bridges to do realtime or near-realtime interaction when needed, and email for longer-term threads. > I really hope manager-types are listening. ?You limit yourselves to > those available in your immediate area and the skills they have. > Opening yourselves to telecommuting allows you to hire folks with > skills that may match your needs more effectively. Some of us are; unfortunately, we're not the ones with open headcount for hiring, because nobody on our teams ever wants to leave. ;-P > Personally, I am working at smaller networks than I would like to, > but I get to live on Kauai and surf places like this every day: > > www.imagemania.net/data/media/22/Polihale%20Beach,%20Kauai,%20Hawaii.jpg > > when I'd rather get back into BGP and operating large networks because I > enjoy it. ?However, I will not give up life's fun things just to do that > for a living. ?I know I'm not the only one out there who thinks this way. Totally agree; I've been courted by companies that are eager to hire me, but once the subject of telecommuting is broached, they suddenly backpedal; to me, that's a clear sign there's an impedance mismatch, at which point I usually politely end the conversation. > scott Matt From bensons at queuefull.net Sat Dec 3 16:28:07 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Sat, 3 Dec 2011 16:28:07 -0600 Subject: IP addresses are now assets In-Reply-To: References: <1892326.1279.1322873079245.JavaMail.root@benjamin.baylink.com> <5CE133DA-64F6-4E95-B010-FA1684D45743@corp.arin.net> <4ed99f4d.8569e70a.7cd1.4ddcSMTPIN_ADDED@mx.google.com> Message-ID: <6F188E67-5F10-4312-942C-9D7343C79016@queuefull.net> It's hard to sustain that kind of commitment... so we need to form a Humor Advisory Committee. Their job would be to determine which behaviors the community finds most humorous. When the community doesn't produce enough material, the comedy HAC would write jokes on our behalf (for adoption by John following legal assessment, board approval, etc). Cheers, -Benson On Dec 3, 2011, at 2:26 PM, Gary Buhrmaster wrote: > On Fri, Dec 2, 2011 at 20:01, wrote: > ..... >> -------------------------------------------------------------------------------- >> Suggestion received and needing confirmation: >> >> That ARIN or a party it designates assign one or more sense(s) of humour to the CEO. >> > > I believe this suggestion suffers from being too non-specific, > and could lead to unintended consequences. ARIN could, > for example, assign John a slapstick comedy sense of humor > and all the chairs at the next meeting would have a whoopee > cushion. And do you really want John taking on the role > of a Don Rickles as an insult comedian? > > And, of course 87% percentage of the population believes > that they already have an above average sense of humor > (and 62% of the population believes any statement with > a statistic in it). > > I would recommend that this suggestion be revised > with community input into what type of humor can > achieve a community consensus. > > Gary > From Valdis.Kletnieks at vt.edu Sat Dec 3 17:59:00 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 03 Dec 2011 18:59:00 -0500 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: Your message of "Sat, 03 Dec 2011 11:40:54 EST." <4415664.1377.1322930454781.JavaMail.root@benjamin.baylink.com> References: <4415664.1377.1322930454781.JavaMail.root@benjamin.baylink.com> Message-ID: <41372.1322956740@turing-police.cc.vt.edu> On Sat, 03 Dec 2011 11:40:54 EST, Jay Ashworth said: > "Private IRC server". Amen to that. I've decided that our private Jabber server has resulted in an order of magnitude improvement in dealing with "quick question for ya" requests, as you can cut/paste to/from as needed (it's still kinda hard to cut-n-paste what the co-worker said over coffee or over the phone ;) with less overhead than e-mail (especially for things that take 3-4 RTTs to resolve). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From thegameiam at yahoo.com Sat Dec 3 20:18:48 2011 From: thegameiam at yahoo.com (David Barak) Date: Sat, 3 Dec 2011 18:18:48 -0800 (PST) Subject: IP addresses are now assets Message-ID: <1322965128.70594.YahooMailMobile@web31802.mail.mud.yahoo.com> Should the HAC be expected to manage the transition to HumorV6? David From bonomi at mail.r-bonomi.com Sun Dec 4 00:21:41 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Sun, 4 Dec 2011 00:21:41 -0600 (CST) Subject: IP addresses are now assets In-Reply-To: <1322965128.70594.YahooMailMobile@web31802.mail.mud.yahoo.com> Message-ID: <201112040621.pB46Lf8v025406@mail.r-bonomi.com> From: David Barak > > Should the HAC be expected to manage the transition to HumorV6? > BEFORE that is introduced, one needs a mailing-list designated for discussion of the potential problems an dangers associated therewith, similar to the ACM's discussion list on computer technoogy. May I propose that it be called the "Humor-esque Digest". An approprite 'publisher' would be the I.S.P.F.[1], with the editor required to use Alfred E. Neuman as his professional psuedonym. "if you're going to do a thing, do it RIGHT!!" "Anything worth doing, is worth over-doing." Footnotes: [1] International 'Save the Pun' Foundation -- yes, they -really- exist. From david at davidswafford.com Sun Dec 4 04:59:06 2011 From: david at davidswafford.com (David Swafford) Date: Sun, 4 Dec 2011 05:59:06 -0500 Subject: Broadband providers in downtown Chicago In-Reply-To: References: Message-ID: When you say "broadband", are you trying to source a residential provider in downtown? I could see that being a challenge.... Take a look around for a metro-eth based Internet pipes, I'm sure they are plenty in that area. TWTC might be one to check out if you're against Cogent [Level3]. David. On Thu, Dec 1, 2011 at 12:30 PM, Ishmael Rufus wrote: > Our company is in a building at 200 w. Monroe and we have difficulty > finding an internet service provider that could at least provide > 1Mbps+ Upload bandwidth that is not Cogent Communications. > > Is it really this difficult finding a decent internet service provider > in downtown Chicago? > From gary.buhrmaster at gmail.com Sun Dec 4 09:15:01 2011 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Sun, 4 Dec 2011 07:15:01 -0800 Subject: IP addresses are now assets In-Reply-To: <1322965128.70594.YahooMailMobile@web31802.mail.mud.yahoo.com> References: <1322965128.70594.YahooMailMobile@web31802.mail.mud.yahoo.com> Message-ID: On Sat, Dec 3, 2011 at 18:18, David Barak wrote: > Should the HAC be expected to manage the transition to HumorV6? > I am not that familiar with Humorv6. Has Hv6 had sufficient operational input, or is it based on a philosophically pure redesign of humor making it theoretically funny, but in practice most of the humor falls flat. Does it require a redesign of the existing infrastructure (i.e. comedy clubs) in order to get the joke? And, of course, is the British implementation of HumourV6 compatible the American implementation of HumorV6? Gary From jra at baylink.com Sun Dec 4 11:58:08 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 4 Dec 2011 12:58:08 -0500 (EST) Subject: IP addresses are now assets In-Reply-To: <201112040621.pB46Lf8v025406@mail.r-bonomi.com> Message-ID: <20692863.1531.1323021488787.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Robert Bonomi" > "if you're going to do a thing, do it RIGHT!!" > > "Anything worth doing, is worth over-doing." I love a good self-referential posting; don't 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 http://photo.imageinc.us +1 727 647 1274 From jra at baylink.com Sun Dec 4 12:12:32 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 4 Dec 2011 13:12:32 -0500 (EST) Subject: On Working Remotely Message-ID: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com> Some more thoughts on telecommuting, from the guy who built Stack Overflow. http://www.codinghorror.com/blog/2010/05/on-working-remotely.html 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 http://photo.imageinc.us +1 727 647 1274 From keegan.holley at sungard.com Sun Dec 4 12:46:51 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Sun, 4 Dec 2011 13:46:51 -0500 Subject: On Working Remotely In-Reply-To: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com> References: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com> Message-ID: Maybe I have a different personality, but I find it much easier to work from home (provided home is empty). I think "networking" from home, which I do periodically during the week is different from coding from home which I do on the weekends. It does take some getting used to. I find I'm much more productive from home. (again as long as home is empty) I spend less time talking about sports (professional, college and little league) TV, the opposite sex, hunting... etc. etc. I also tend to make healthier choices since the coffee and cigarettes aren't free and no one invites me to order pizza for lunch when I'm at home. To each his own though. 2011/12/4 Jay Ashworth > Some more thoughts on telecommuting, from the guy who built Stack Overflow. > > http://www.codinghorror.com/blog/2010/05/on-working-remotely.html > > 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 http://photo.imageinc.us +1 727 647 > 1274 > > > From leigh.porter at ukbroadband.com Sun Dec 4 12:54:53 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Sun, 4 Dec 2011 18:54:53 +0000 Subject: On Working Remotely In-Reply-To: References: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com> Message-ID: This pretty much says it all, I think: http://www.youtube.com/watch?v=co_DNpTMKXk -- Leigh > -----Original Message----- > From: Keegan Holley [mailto:keegan.holley at sungard.com] > Sent: 04 December 2011 18:50 > To: Jay Ashworth > Cc: NANOG > Subject: Re: On Working Remotely > > Maybe I have a different personality, but I find it much easier to work > from home (provided home is empty). I think "networking" from home, > which > I do periodically during the week is different from coding from home > which > I do on the weekends. It does take some getting used to. I find I'm > much > more productive from home. (again as long as home is empty) I spend > less > time talking about sports (professional, college and little league) TV, > the > opposite sex, hunting... etc. etc. I also tend to make healthier > choices > since the coffee and cigarettes aren't free and no one invites me to > order > pizza for lunch when I'm at home. To each his own though. > > 2011/12/4 Jay Ashworth > > > Some more thoughts on telecommuting, from the guy who built Stack > Overflow. > > > > http://www.codinghorror.com/blog/2010/05/on-working-remotely.html > > > > 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 http://photo.imageinc.us +1 727 > 647 > > 1274 > > > > > > > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud > service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From excelsio at gmx.com Sun Dec 4 13:21:02 2011 From: excelsio at gmx.com (excelsio at gmx.com) Date: Sun, 04 Dec 2011 20:21:02 +0100 Subject: HP IPv6 RA Guard Message-ID: <20111204192104.37340@gmx.com> Hi, sorry to disappoint you, but there?s a reason why HP bought H3C/3Com. And of course, those switches have some advanced features, as well: - IPV6 DHCP snooping - IPV6 ND detection - IPV6 ND snooping - SAVI (Source Address Validation), http://tools.ietf.org/wg/savi/ Christian >I wonder if this is evidence that they plan to continue to develop the >Procurve line and eventually abandon the 3Com line. Uncertainty of >which line would win out has kept me (and others I'm sure) from >wanting to invest in anything HP. From morrowc.lists at gmail.com Sun Dec 4 16:53:36 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 4 Dec 2011 17:53:36 -0500 Subject: HP IPv6 RA Guard In-Reply-To: <20111204192104.37340@gmx.com> References: <20111204192104.37340@gmx.com> Message-ID: On Sun, Dec 4, 2011 at 2:21 PM, wrote: > Hi, > > ?sorry to disappoint you, but there?s a reason why HP bought H3C/3Com. And of course, those switches have some advanced features, as well: > does the set of 'advanced features' include: "A cli that is scriptable" ? cause the HPOS interface is fraught with crappy scriptable bits :( (yes there are rancid hp-login-like things, yes they all suck rocks) -chris From cdel at firsthand.net Mon Dec 5 02:27:48 2011 From: cdel at firsthand.net (cdel.firsthand.net) Date: Mon, 5 Dec 2011 08:27:48 +0000 Subject: IP addresses are now assets In-Reply-To: References: <1322965128.70594.YahooMailMobile@web31802.mail.mud.yahoo.com> Message-ID: <30AF119C-F83E-469B-8E49-73DF7330D773@firsthand.net> The British have been using the correct six character word length for humour ad memoriam. Christian de Larrinaga On 4 Dec 2011, at 15:15, Gary Buhrmaster wrote: > On Sat, Dec 3, 2011 at 18:18, David Barak wrote: > >> Should the HAC be expected to manage the transition to HumorV6? >> > > I am not that familiar with Humorv6. Has Hv6 had sufficient > operational input, or is it based on a philosophically pure > redesign of humor making it theoretically funny, but > in practice most of the humor falls flat. Does it require a > redesign of the existing infrastructure (i.e. comedy clubs) > in order to get the joke? And, of course, is the British > implementation of HumourV6 compatible the American > implementation of HumorV6? > > Gary From owen at delong.com Mon Dec 5 04:17:08 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 5 Dec 2011 02:17:08 -0800 Subject: IP addresses are now assets In-Reply-To: <30AF119C-F83E-469B-8E49-73DF7330D773@firsthand.net> References: <1322965128.70594.YahooMailMobile@web31802.mail.mud.yahoo.com> <30AF119C-F83E-469B-8E49-73DF7330D773@firsthand.net> Message-ID: <9895F3A7-847D-44BA-A2E2-43418BE3E677@delong.com> Extra and unnecessary characters do not a correct word make. Owen On Dec 5, 2011, at 12:27 AM, cdel.firsthand.net wrote: > The British have been using the correct six character word length for humour ad memoriam. > > > Christian de Larrinaga > > > On 4 Dec 2011, at 15:15, Gary Buhrmaster wrote: > >> On Sat, Dec 3, 2011 at 18:18, David Barak wrote: >> >>> Should the HAC be expected to manage the transition to HumorV6? >>> >> >> I am not that familiar with Humorv6. Has Hv6 had sufficient >> operational input, or is it based on a philosophically pure >> redesign of humor making it theoretically funny, but >> in practice most of the humor falls flat. Does it require a >> redesign of the existing infrastructure (i.e. comedy clubs) >> in order to get the joke? And, of course, is the British >> implementation of HumourV6 compatible the American >> implementation of HumorV6? >> >> Gary From david at davidradcliffe.org Mon Dec 5 09:09:08 2011 From: david at davidradcliffe.org (David Radcliffe) Date: Mon, 5 Dec 2011 10:09:08 -0500 Subject: On Working Remotely In-Reply-To: References: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com> Message-ID: <201112051009.09009.david@davidradcliffe.org> Same here. I like isolation just fine and work much more productively and usually for a longer time at home. I don't have kids and my wife has learned when she is home if I say I will be working, don't bother me. It actually works quite well. I like socializing but not when my mind is on work. I can code very effectively for hours without breaking because I get in the zone easily at home. I do have to say to anyone planning to work from home, make sure you have a proper work space. I have a computer room. It contains a dozen systems, electronics gear and parts (I used to have time for that hobby), and comfortable and ergonomic work spaces. There is no TV. No reason for one because this is the work room. The mind set should be "I am now in the work room, so I am at work." Really works for me. On Sunday, December 04, 2011 01:46:51 PM Keegan Holley wrote: > Maybe I have a different personality, but I find it much easier to work > from home (provided home is empty). I think "networking" from home, which > I do periodically during the week is different from coding from home which > I do on the weekends. It does take some getting used to. I find I'm much > more productive from home. (again as long as home is empty) I spend less > time talking about sports (professional, college and little league) TV, the > opposite sex, hunting... etc. etc. I also tend to make healthier choices > since the coffee and cigarettes aren't free and no one invites me to order > pizza for lunch when I'm at home. To each his own though. > > 2011/12/4 Jay Ashworth > > > Some more thoughts on telecommuting, from the guy who built Stack > > Overflow. > > > > http://www.codinghorror.com/blog/2010/05/on-working-remotely.html > > > > 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 http://photo.imageinc.us +1 727 647 > > 1274 -- David Radcliffe Network Engineer/Linux Specialist david at davidradcliffe.org www.davidradcliffe.org Nothing ever gets solved better with panic. If you do not know the answer, it is probably "42." From paul at blacknight.com Mon Dec 5 09:20:57 2011 From: paul at blacknight.com (Paul Kelly :: Blacknight) Date: Mon, 5 Dec 2011 15:20:57 +0000 Subject: yahoo mail admin(s) Message-ID: <08EEEAD796731546A6662E346C71CA3825036A6B@bkexchmbx01.blacknight.local> Hi There, Could a yahoo.com mail admin contact me offlist please? We get calls from customers saying that e-mails from their yahoo.com e-mail address to us bounce back due to a DNS lookup issue. The issue seems intermittent but it's at a level that is sufficient enough to raise some eyebrows by the head of our customer service team. Cheers, Paul Paul Kelly Technical Director Microsoft Gold Certified Partner Blacknight Internet Solutions ltd 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 mike at mtcc.com Mon Dec 5 09:22:43 2011 From: mike at mtcc.com (Michael Thomas) Date: Mon, 05 Dec 2011 07:22:43 -0800 Subject: On Working Remotely In-Reply-To: <201112051009.09009.david@davidradcliffe.org> References: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com> <201112051009.09009.david@davidradcliffe.org> Message-ID: <4EDCE1C3.2070208@mtcc.com> What the heck... I've been working on a project for the last three years at home and mostly by myself. It has been one of the more productive times of my life codingwise precisely because I am at home and can juggle life's responsibilities as needed all without really having one. When you go into the office day-in day-out you have artificial bounds of work/life -- even though we all know they're blurry these days. I don't know... I really don't relish those bounds all that much anymore because inspirations hit when they do, not when you happen to be in the office (like, oh say, after the morning shower). The downside is not having somebody to bounce ideas off of, even if it's mostly a soliloquy. I've worked around that by having a weekly meeting with others working on the project which works ok, but it's not always adequate. On the other hand given that my project is related to skiing, the lift conversations are terrifyingly geeky for the poor souls riding with us :) MIke On 12/05/2011 07:09 AM, David Radcliffe wrote: > Same here. I like isolation just fine and work much more productively and > usually for a longer time at home. I don't have kids and my wife has learned > when she is home if I say I will be working, don't bother me. > > It actually works quite well. I like socializing but not when my mind is on > work. I can code very effectively for hours without breaking because I get in > the zone easily at home. > > I do have to say to anyone planning to work from home, make sure you have a > proper work space. I have a computer room. It contains a dozen systems, > electronics gear and parts (I used to have time for that hobby), and > comfortable and ergonomic work spaces. There is no TV. No reason for one > because this is the work room. The mind set should be "I am now in the work > room, so I am at work." Really works for me. > > On Sunday, December 04, 2011 01:46:51 PM Keegan Holley wrote: >> Maybe I have a different personality, but I find it much easier to work >> from home (provided home is empty). I think "networking" from home, which >> I do periodically during the week is different from coding from home which >> I do on the weekends. It does take some getting used to. I find I'm much >> more productive from home. (again as long as home is empty) I spend less >> time talking about sports (professional, college and little league) TV, the >> opposite sex, hunting... etc. etc. I also tend to make healthier choices >> since the coffee and cigarettes aren't free and no one invites me to order >> pizza for lunch when I'm at home. To each his own though. >> >> 2011/12/4 Jay Ashworth >> >>> Some more thoughts on telecommuting, from the guy who built Stack >>> Overflow. >>> >>> http://www.codinghorror.com/blog/2010/05/on-working-remotely.html >>> >>> 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 http://photo.imageinc.us +1 727 647 >>> 1274 From sean at seanharlow.info Mon Dec 5 09:35:27 2011 From: sean at seanharlow.info (Sean Harlow) Date: Mon, 5 Dec 2011 10:35:27 -0500 Subject: On Working Remotely In-Reply-To: <201112051009.09009.david@davidradcliffe.org> References: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com> <201112051009.09009.david@davidradcliffe.org> Message-ID: <5E35BA1B-0B09-4E3E-8F45-B9A4F2EDEDBC@seanharlow.info> I can not agree with this more. I have been working from home for two years now and unfortunately live in a small apartment where I do not have a dedicated space to assign for "work". My "workstation" is also my gaming machine and my servers sit right next to my game consoles. It's impossible to get entirely in to a work mindset when your bed is literally two feet from where you sit. This one's hard to solve when you don't have the space, I can certainly say there's a reason I have the most time put in to Skyrim out of all of my friends. Another thing you might not think about is how much it can interfere with anything you consider part of a morning routine. Where you used to get up at 8, shower, eat breakfast, get dressed, etc. before heading in to start work at 9 it doesn't take long before you realize you can instead wake up at 8:59, put on whatever pants might be within arm's reach, and sit down at your chair. Next thing you know it's 6 PM and you haven't eaten or showered yet. I've started setting an alarm and trying to work out in the morning to counter this and it works pretty well, but it took some effort. tl;dr version: Working in an office provides structure that you may depend on without realizing it. Be prepared to replicate as much of that structure as needed to remain productive and not turn in to a slob. ---------- Sean Harlow sean at seanharlow.info On Dec 5, 2011, at 10:09 AM, David Radcliffe wrote: > I do have to say to anyone planning to work from home, make sure you have a > proper work space. I have a computer room. It contains a dozen systems, > electronics gear and parts (I used to have time for that hobby), and > comfortable and ergonomic work spaces. There is no TV. No reason for one > because this is the work room. The mind set should be "I am now in the work > room, so I am at work." Really works for me. From jschauma at netmeister.org Mon Dec 5 09:40:04 2011 From: jschauma at netmeister.org (Jan Schaumann) Date: Mon, 5 Dec 2011 10:40:04 -0500 Subject: On Working Remotely In-Reply-To: <201112051009.09009.david@davidradcliffe.org> References: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com> <201112051009.09009.david@davidradcliffe.org> Message-ID: <20111205154003.GP22948@netmeister.org> David Radcliffe wrote: > I do have to say to anyone planning to work from home, make sure you have a > proper work space. For whatever it's worth: I have been working from home for the last 3.5 years. I live in Manhattan in a one-bedroom with a 4 year and now a 2 months old daughter, meaning I work on my laptop in the middle of the livingroom with all my life around me. I context-switch a lot; I put down the laptop to read my daughters a story or play for a few minutes, I go shopping, cook etc. But: when I go to visit the office (about once a quarter or so), I wonder how on earth my colleagues get any work done. They are constantly interrupted, asked to have coffee, lunch, breakfast, a snack, go for a walk and just chew the fat. Yes, I work a lot at night and on the weekends. That is the one thing that people who do not work from home are not aware of: you have no more distinction between "home" and "office", which usually means that when I'm home, I'm working. I could see how having a "home office" with a closed door could create this impression of "going to the office" and "coming home", but I don't find it either desirable nor (in Manhattan) practical. -Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 478 bytes Desc: not available URL: From lists at mtin.net Mon Dec 5 09:55:00 2011 From: lists at mtin.net (Justin Wilson) Date: Mon, 05 Dec 2011 10:55:00 -0500 Subject: On Working Remotely In-Reply-To: <20111205154003.GP22948@netmeister.org> Message-ID: I have been working from my home on a regular basis for almost 4 years now. I visit clients and routinely travel for projects. However, I work 80% out of my home office. I have instant messenger for clients who want to ask a quick question. Sometimes we just end up chewing the fat, which is a nice distraction. I agree with a dedicated workspace as much as possible. Doesn't have to be a separate room or whatever. Just a place set aside where you can keep work things separate from everything else. Even if you have 2 desks side by side. Buddy of mine lives in a small flat and has 2 small desks side by side. The second desk is for gaming and other activities. This way he can just "walk away" from work and not have to move things out of the way. When he returns things are right where they were. My breaks consist of going downstairs and playing a round of some online game for 10 minutes or so. I find myself much more productive as well. No more hour long commute one way. I can use that hour much more productive or simply sleep in because I was up late working on a router. Justin -- Justin Wilson Aol & Yahoo IM: j2sw http://www.mtin.net/blog ? xISP News http://www.twitter.com/j2sw ? Follow me on Twitter From bblackford at gmail.com Mon Dec 5 10:13:19 2011 From: bblackford at gmail.com (Bill Blackford) Date: Mon, 5 Dec 2011 08:13:19 -0800 Subject: On Working Remotely In-Reply-To: <20111205154003.GP22948@netmeister.org> References: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com> <201112051009.09009.david@davidradcliffe.org> <20111205154003.GP22948@netmeister.org> Message-ID: Reading this thread, is encouraging to me. My whole team are remote workers and for myself, I've asked to maintain a cube in a nearby POP. I have small ones at home who don't understand why dad can't be as available to them as they wish. For me, I can't focus well with these kind of distractions especially if I'm on a call or can't drop what I'm doing, but I admire those who can. Also, at this point, I don't have a dedicated "office" area at home and find myself huddled over a work bench in the garage next to my server rack. Not the most ergo setting. That said, unlike my co-workers, I don't get a home office stipend, I spend more in gas and my days are longer when I add the commute time into the mix. Ideally, I would like to transition to working more at home. I also perceive it's going to take some time for me to change the paradigm of 9-5, (6-4) and transition to a model where I can work the same amount of hours and be just as productive by logging in these hours in non-contiguous chunks. Having the ability to "context-switch" as Jan has labeled it, I believe is key here. This is a helpful thread, thanks you all for sharing. -b On Mon, Dec 5, 2011 at 7:40 AM, Jan Schaumann wrote: > David Radcliffe wrote: > >> I do have to say to anyone planning to work from home, make sure you have a >> proper work space. > > For whatever it's worth: > > I have been working from home for the last 3.5 years. ?I live in > Manhattan in a one-bedroom with a 4 year and now a 2 months old > daughter, meaning I work on my laptop in the middle of the livingroom > with all my life around me. > > I context-switch a lot; I put down the laptop to read my daughters a > story or play for a few minutes, I go shopping, cook etc. ?But: when I > go to visit the office (about once a quarter or so), I wonder how on > earth my colleagues get any work done. ?They are constantly interrupted, > asked to have coffee, lunch, breakfast, a snack, go for a walk and just > chew the fat. > > Yes, I work a lot at night and on the weekends. ?That is the one thing > that people who do not work from home are not aware of: you have no more > distinction between "home" and "office", which usually means that when > I'm home, I'm working. > > I could see how having a "home office" with a closed door could create > this impression of "going to the office" and "coming home", but I don't > find it either desirable nor (in Manhattan) practical. > > -Jan > -- Bill Blackford Network Engineer Logged into reality and abusing my sudo privileges..... From david at davidradcliffe.org Mon Dec 5 10:49:40 2011 From: david at davidradcliffe.org (David Radcliffe) Date: Mon, 5 Dec 2011 11:49:40 -0500 Subject: On Working Remotely In-Reply-To: <5E35BA1B-0B09-4E3E-8F45-B9A4F2EDEDBC@seanharlow.info> References: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com> <201112051009.09009.david@davidradcliffe.org> <5E35BA1B-0B09-4E3E-8F45-B9A4F2EDEDBC@seanharlow.info> Message-ID: <201112051149.40594.david@davidradcliffe.org> Yes, it is easier (I think) if you have the space to dedicate a work room. My game system is in my computer room but I only game twice a week and only with my friends. I have no doubt I might be diagnosed with a little OCD (or something) but Q: Game? A: It's not Wednesday night. Q: But you could run the game now? A: Yes. Q: But? A: It's not Wednesday. I could force myself but the universe would feel odd. I guess it's really about the mindset. I suspect I would still work effectively in a smaller, non-dedicated workspace. I have before in hotel rooms. Not at my mother's house. She doesn't get "Gee, mom, I need to focus for a while." Obviously, there is no one solution for everyone but I hope to find a way (with current employer, but most likely will have to change employers) for me to work from home. Part of my goal is actually to find someone who will more deeply use my talents. As you say, you can find yourself rolling out of bed and dropping into work without eating or showering. I have often done this and am quite comfortable with it. On Monday, December 05, 2011 10:35:27 AM Sean Harlow wrote: > I can not agree with this more. I have been working from home for two > years now and unfortunately live in a small apartment where I do not have > a dedicated space to assign for "work". My "workstation" is also my > gaming machine and my servers sit right next to my game consoles. It's > impossible to get entirely in to a work mindset when your bed is literally > two feet from where you sit. This one's hard to solve when you don't have > the space, I can certainly say there's a reason I have the most time put > in to Skyrim out of all of my friends. > > Another thing you might not think about is how much it can interfere with > anything you consider part of a morning routine. Where you used to get up > at 8, shower, eat breakfast, get dressed, etc. before heading in to start > work at 9 it doesn't take long before you realize you can instead wake up > at 8:59, put on whatever pants might be within arm's reach, and sit down > at your chair. Next thing you know it's 6 PM and you haven't eaten or > showered yet. I've started setting an alarm and trying to work out in the > morning to counter this and it works pretty well, but it took some effort. > > tl;dr version: Working in an office provides structure that you may depend > on without realizing it. Be prepared to replicate as much of that > structure as needed to remain productive and not turn in to a slob. > ---------- > Sean Harlow > sean at seanharlow.info > -- David Radcliffe Network Engineer/Linux Specialist david at davidradcliffe.org www.davidradcliffe.org Nothing ever gets solved better with panic. If you do not know the answer, it is probably "42." From david at davidradcliffe.org Mon Dec 5 11:00:25 2011 From: david at davidradcliffe.org (David Radcliffe) Date: Mon, 5 Dec 2011 12:00:25 -0500 Subject: On Working Remotely In-Reply-To: <20111205154003.GP22948@netmeister.org> References: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com> <201112051009.09009.david@davidradcliffe.org> <20111205154003.GP22948@netmeister.org> Message-ID: <201112051200.25542.david@davidradcliffe.org> I know many people who can work as you and we all adjust to our setting. I just also know people who gravitate to their distractions and need the wall to define work. It's best for me even though I will work as effectively at midnight as in the middle of the day. I have to say I am impressed. Working with a 4 year old and 2 month old around. Wow. On Monday, December 05, 2011 10:40:04 AM Jan Schaumann wrote: > > For whatever it's worth: > > I have been working from home for the last 3.5 years. I live in > Manhattan in a one-bedroom with a 4 year and now a 2 months old > daughter, meaning I work on my laptop in the middle of the livingroom > with all my life around me. > > I context-switch a lot; I put down the laptop to read my daughters a > story or play for a few minutes, I go shopping, cook etc. But: when I > go to visit the office (about once a quarter or so), I wonder how on > earth my colleagues get any work done. They are constantly interrupted, > asked to have coffee, lunch, breakfast, a snack, go for a walk and just > chew the fat. > > Yes, I work a lot at night and on the weekends. That is the one thing > that people who do not work from home are not aware of: you have no more > distinction between "home" and "office", which usually means that when > I'm home, I'm working. > > I could see how having a "home office" with a closed door could create > this impression of "going to the office" and "coming home", but I don't > find it either desirable nor (in Manhattan) practical. > > -Jan -- David Radcliffe Network Engineer/Linux Specialist david at davidradcliffe.org www.davidradcliffe.org Nothing ever gets solved better with panic. If you do not know the answer, it is probably "42." From mtinka at globaltransit.net Fri Dec 2 09:03:52 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Fri, 2 Dec 2011 23:03:52 +0800 Subject: APRICOT-2012: Call for Papers Message-ID: <201112022303.52917.mtinka@globaltransit.net> Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT) 21 February - 2 March 2012, New Delhi, India http://www.apricot2012.net CALL FOR PAPERS =============== The APRICOT 2012 Programme Committee is now seeking contributions for Presentations and Tutorials for APRICOT 2012. We are looking for people and proposals that would: - Offer a technical tutorial on an appropriate topic; and/or - Participate in the technical conference sessions as a speaker; and/or - Convene and chair a Birds of a Feather (BOF) session. Please submit proposals on-line at: http://submission.apnic.net/ CONFERENCE MILESTONES --------------------- Call for Papers Opens: 22 November 2011 First Draft Program Published: 19 December 2011 Final Deadline for Submissions: 10 February 2012 Final Program Published: 17 February 2012 Final Slides Received: 25 February 2012 PROGRAM MATERIAL ---------------- The APRICOT Programme is organised in three parts, including workshops, tutorials and the conference. The APNIC Policy SIG and Annual Members Meeting will be held during the APRICOT conference. Topics for tutorials and conference would include amongst others relevant to Internet Operations and Technologies: - IPv4 / IPv6 Routing and operations - IPv4 address runout / IPv6 deployment and transition technologies - Backbone operations - ISP and Carrier services - Network security issues (NSP-SEC, DDoS Anti-Spam, Anti-Malware) - Peering / IXPs - DNS / DNSSEC - Internet policy (Security, Regulation, Content Management, Addressing, etc) - Access and Transport Technologies, including broadband deployment, Cable/DSL, wireless, WiMax, metro ethernet, fiber network, MPLS - Content & Service Delivery (Multicast, Voice, Video, "telepresence", Gaming) CfP SUBMISSION -------------- All draft and complete slides must be submitted in PDF format only. Draft slides for both tutorials and conference sessions MUST be provided with CfP submissions otherwise the Programme Committee will be unable to review the submission. For work in progress, the most current information available at time of submission is acceptable. Final slides are to be provided by the specified deadline for publication on the APRICOT website. While the majority of speaking slots will be filled by the first submission deadline, a limited number of slots may be available up to the final submission deadline for presentations that are exceptionally timely, important, or of critical operational importance. Please submit on-line at: http://submission.apnic.net/ Any questions or concerns should be addressed to the Programme Committee by e-mail at: pc-chairs at apricot.net We look forward to receiving your presentation proposals. Mark Tinka & Jonny Martin Co-Chairs, APRICOT Programme Committee program at apricot.net -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From alexlh at ripe.net Mon Dec 5 09:20:27 2011 From: alexlh at ripe.net (Alex Le Heux) Date: Mon, 5 Dec 2011 16:20:27 +0100 Subject: 128.0.0.0/16 configured as martians in some routers Message-ID: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> Dear Colleagues, The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline that this /16 should no longer be reserved as specialised address space. All allocations that were already issued have been exchanged and for now we will hold this space in quarantine. We urge everyone to change the default behaviour of their Juniper routers: set routing-options martians 128.0.0.0/16 orlonger allow set routing-options martians 191.255.0.0/16 orlonger allow set routing-options martians 223.255.255.0/24 exact allow 128.0.0.0/16 has been added to the RIPE NCC's Debogonising Project: http://www.ris.ripe.net/debogon/ To facilitate testing, the following prefixes are being announced: prefix pinagble address 128.0.0.0/16 128.0.0.1 128.0.8.0/21 128.0.8.1 128.0.24.0/24 128.0.24.1 Best regards, Alex Le Heux Policy Implementation Co-ordinator RIPE NCC From alexlh at ripe.net Mon Dec 5 09:20:27 2011 From: alexlh at ripe.net (Alex Le Heux) Date: Mon, 5 Dec 2011 16:20:27 +0100 Subject: [ncc-announce] 128.0.0.0/16 configured as martians in some routers Message-ID: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> Dear Colleagues, The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline that this /16 should no longer be reserved as specialised address space. All allocations that were already issued have been exchanged and for now we will hold this space in quarantine. We urge everyone to change the default behaviour of their Juniper routers: set routing-options martians 128.0.0.0/16 orlonger allow set routing-options martians 191.255.0.0/16 orlonger allow set routing-options martians 223.255.255.0/24 exact allow 128.0.0.0/16 has been added to the RIPE NCC's Debogonising Project: http://www.ris.ripe.net/debogon/ To facilitate testing, the following prefixes are being announced: prefix pinagble address 128.0.0.0/16 128.0.0.1 128.0.8.0/21 128.0.8.1 128.0.24.0/24 128.0.24.1 Best regards, Alex Le Heux Policy Implementation Co-ordinator RIPE NCC From alexlh at ripe.net Mon Dec 5 09:48:39 2011 From: alexlh at ripe.net (Alex Le Heux) Date: Mon, 5 Dec 2011 16:48:39 +0100 Subject: 128.0.0.0/16 configured as martians in some routers In-Reply-To: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> References: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> Message-ID: <45D79898-3854-4671-AC9E-317A65C28FC7@ripe.net> Dear Colleagues, The correct prefix and pingable address list for the Debogonising Project is: prefix pinagble address 128.0.0.0/21 128.0.0.1 128.0.24.0/24 128.0.24.1 Our apologies for the oversight. Best regards, Alex Le Heux Policy Implementation Co-ordinator RIPE NCC On Dec 5, 2011, at 16:20, Alex Le Heux wrote: > Dear Colleagues, > > The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline that this /16 should no longer be reserved as specialised address space. > > All allocations that were already issued have been exchanged and for now we will hold this space in quarantine. > > We urge everyone to change the default behaviour of their Juniper routers: > > set routing-options martians 128.0.0.0/16 orlonger allow > set routing-options martians 191.255.0.0/16 orlonger allow > set routing-options martians 223.255.255.0/24 exact allow > > 128.0.0.0/16 has been added to the RIPE NCC's Debogonising Project: > > http://www.ris.ripe.net/debogon/ > > To facilitate testing, the following prefixes are being announced: > > prefix pinagble address > > 128.0.0.0/16 128.0.0.1 > 128.0.8.0/21 128.0.8.1 > 128.0.24.0/24 128.0.24.1 > > Best regards, > > Alex Le Heux > Policy Implementation Co-ordinator > RIPE NCC From alexlh at ripe.net Mon Dec 5 09:20:27 2011 From: alexlh at ripe.net (Alex Le Heux) Date: Mon, 5 Dec 2011 16:20:27 +0100 Subject: [ncc-announce] 128.0.0.0/16 configured as martians in some routers Message-ID: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> Dear Colleagues, The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline that this /16 should no longer be reserved as specialised address space. All allocations that were already issued have been exchanged and for now we will hold this space in quarantine. We urge everyone to change the default behaviour of their Juniper routers: set routing-options martians 128.0.0.0/16 orlonger allow set routing-options martians 191.255.0.0/16 orlonger allow set routing-options martians 223.255.255.0/24 exact allow 128.0.0.0/16 has been added to the RIPE NCC's Debogonising Project: http://www.ris.ripe.net/debogon/ To facilitate testing, the following prefixes are being announced: prefix pinagble address 128.0.0.0/16 128.0.0.1 128.0.8.0/21 128.0.8.1 128.0.24.0/24 128.0.24.1 Best regards, Alex Le Heux Policy Implementation Co-ordinator RIPE NCC From alexlh at ripe.net Mon Dec 5 09:20:27 2011 From: alexlh at ripe.net (Alex Le Heux) Date: Mon, 5 Dec 2011 16:20:27 +0100 Subject: [ncc-announce] 128.0.0.0/16 configured as martians in some routers Message-ID: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> Dear Colleagues, The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline that this /16 should no longer be reserved as specialised address space. All allocations that were already issued have been exchanged and for now we will hold this space in quarantine. We urge everyone to change the default behaviour of their Juniper routers: set routing-options martians 128.0.0.0/16 orlonger allow set routing-options martians 191.255.0.0/16 orlonger allow set routing-options martians 223.255.255.0/24 exact allow 128.0.0.0/16 has been added to the RIPE NCC's Debogonising Project: http://www.ris.ripe.net/debogon/ To facilitate testing, the following prefixes are being announced: prefix pinagble address 128.0.0.0/16 128.0.0.1 128.0.8.0/21 128.0.8.1 128.0.24.0/24 128.0.24.1 Best regards, Alex Le Heux Policy Implementation Co-ordinator RIPE NCC From alexlh at ripe.net Mon Dec 5 09:20:27 2011 From: alexlh at ripe.net (Alex Le Heux) Date: Mon, 5 Dec 2011 16:20:27 +0100 Subject: [ncc-announce] 128.0.0.0/16 configured as martians in some routers Message-ID: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> Dear Colleagues, The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline that this /16 should no longer be reserved as specialised address space. All allocations that were already issued have been exchanged and for now we will hold this space in quarantine. We urge everyone to change the default behaviour of their Juniper routers: set routing-options martians 128.0.0.0/16 orlonger allow set routing-options martians 191.255.0.0/16 orlonger allow set routing-options martians 223.255.255.0/24 exact allow 128.0.0.0/16 has been added to the RIPE NCC's Debogonising Project: http://www.ris.ripe.net/debogon/ To facilitate testing, the following prefixes are being announced: prefix pinagble address 128.0.0.0/16 128.0.0.1 128.0.8.0/21 128.0.8.1 128.0.24.0/24 128.0.24.1 Best regards, Alex Le Heux Policy Implementation Co-ordinator RIPE NCC From alexlh at ripe.net Mon Dec 5 09:20:27 2011 From: alexlh at ripe.net (Alex Le Heux) Date: Mon, 5 Dec 2011 16:20:27 +0100 Subject: [ncc-announce] 128.0.0.0/16 configured as martians in some routers Message-ID: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> Dear Colleagues, The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline that this /16 should no longer be reserved as specialised address space. All allocations that were already issued have been exchanged and for now we will hold this space in quarantine. We urge everyone to change the default behaviour of their Juniper routers: set routing-options martians 128.0.0.0/16 orlonger allow set routing-options martians 191.255.0.0/16 orlonger allow set routing-options martians 223.255.255.0/24 exact allow 128.0.0.0/16 has been added to the RIPE NCC's Debogonising Project: http://www.ris.ripe.net/debogon/ To facilitate testing, the following prefixes are being announced: prefix pinagble address 128.0.0.0/16 128.0.0.1 128.0.8.0/21 128.0.8.1 128.0.24.0/24 128.0.24.1 Best regards, Alex Le Heux Policy Implementation Co-ordinator RIPE NCC From alexlh at ripe.net Mon Dec 5 09:20:27 2011 From: alexlh at ripe.net (Alex Le Heux) Date: Mon, 5 Dec 2011 16:20:27 +0100 Subject: [ncc-announce] 128.0.0.0/16 configured as martians in some routers Message-ID: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> Dear Colleagues, The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline that this /16 should no longer be reserved as specialised address space. All allocations that were already issued have been exchanged and for now we will hold this space in quarantine. We urge everyone to change the default behaviour of their Juniper routers: set routing-options martians 128.0.0.0/16 orlonger allow set routing-options martians 191.255.0.0/16 orlonger allow set routing-options martians 223.255.255.0/24 exact allow 128.0.0.0/16 has been added to the RIPE NCC's Debogonising Project: http://www.ris.ripe.net/debogon/ To facilitate testing, the following prefixes are being announced: prefix pinagble address 128.0.0.0/16 128.0.0.1 128.0.8.0/21 128.0.8.1 128.0.24.0/24 128.0.24.1 Best regards, Alex Le Heux Policy Implementation Co-ordinator RIPE NCC From alexlh at ripe.net Mon Dec 5 09:48:39 2011 From: alexlh at ripe.net (Alex Le Heux) Date: Mon, 5 Dec 2011 16:48:39 +0100 Subject: [ncc-announce] 128.0.0.0/16 configured as martians in somerouters In-Reply-To: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> References: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> Message-ID: <45D79898-3854-4671-AC9E-317A65C28FC7@ripe.net> Dear Colleagues, The correct prefix and pingable address list for the Debogonising Project is: prefix pinagble address 128.0.0.0/21 128.0.0.1 128.0.24.0/24 128.0.24.1 Our apologies for the oversight. Best regards, Alex Le Heux Policy Implementation Co-ordinator RIPE NCC On Dec 5, 2011, at 16:20, Alex Le Heux wrote: > Dear Colleagues, > > The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline that this /16 should no longer be reserved as specialised address space. > > All allocations that were already issued have been exchanged and for now we will hold this space in quarantine. > > We urge everyone to change the default behaviour of their Juniper routers: > > set routing-options martians 128.0.0.0/16 orlonger allow > set routing-options martians 191.255.0.0/16 orlonger allow > set routing-options martians 223.255.255.0/24 exact allow > > 128.0.0.0/16 has been added to the RIPE NCC's Debogonising Project: > > http://www.ris.ripe.net/debogon/ > > To facilitate testing, the following prefixes are being announced: > > prefix pinagble address > > 128.0.0.0/16 128.0.0.1 > 128.0.8.0/21 128.0.8.1 > 128.0.24.0/24 128.0.24.1 > > Best regards, > > Alex Le Heux > Policy Implementation Co-ordinator > RIPE NCC From macsaorsa at gmail.com Mon Dec 5 11:52:57 2011 From: macsaorsa at gmail.com (Paul Brown) Date: Mon, 05 Dec 2011 12:52:57 -0500 Subject: High latency/dropped packets on Mitel circuit in LA Message-ID: <4EDD04F9.8010407@gmail.com> I'm having some pretty bad connection issues with one of my remote offices in LA. I figured it was probably wind-related last week but it's still going on today. The vendor (Mitel) is saying that they're testing the circuit as good to the router, but I doubt it because I'm seeing the same missed pings on both the outside and inside interfaces from here (Richmond, VA) across the MPLS network. I know it's possible that it could be the router, but my gut tells me it's a circuit issue. Does anybody know of anything going on out there? Thanks, Paul From victoresposito at yahoo.com Mon Dec 5 12:41:42 2011 From: victoresposito at yahoo.com (Victor Esposito) Date: Mon, 5 Dec 2011 10:41:42 -0800 (PST) Subject: Global BGP and Google Message-ID: <1323110502.64552.YahooMailNeo@web160104.mail.bf1.yahoo.com> Has anyone had any experience with a Global? ASN, and Google inappropriately associating IP's to the wrong countries? ? We have our AS registered in Argentina, with ARIN space under it.? From time to time, Google thinks the IP's are in Argentina, even though they are in the US.? We have this issue elsewhere across the globe as well. ? I was pondering multiple ASN's, but I was not sure if there was a better method for dealing with this. ? ? Thanks in advance! Victor Esposito From cmadams at hiwaay.net Mon Dec 5 13:44:22 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 5 Dec 2011 13:44:22 -0600 Subject: 128.0.0.0/16 configured as martians in some routers In-Reply-To: <45D79898-3854-4671-AC9E-317A65C28FC7@ripe.net> References: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> <45D79898-3854-4671-AC9E-317A65C28FC7@ripe.net> Message-ID: <20111205194422.GC26078@hiwaay.net> Once upon a time, Alex Le Heux said: > Dear Colleagues, > > The correct prefix and pingable address list for the Debogonising Project is: > > prefix pinagble address > > 128.0.0.0/21 128.0.0.1 > 128.0.24.0/24 128.0.24.1 > > Our apologies for the oversight. Are these prefixes being announced widely? I don't see anything for 128.0.0.0/16 from my upstreams, nor at many public looking glasses. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From bmanning at vacation.karoshi.com Mon Dec 5 13:50:17 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 5 Dec 2011 19:50:17 +0000 Subject: On Working Remotely In-Reply-To: <201112051200.25542.david@davidradcliffe.org> References: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com> <201112051009.09009.david@davidradcliffe.org> <20111205154003.GP22948@netmeister.org> <201112051200.25542.david@davidradcliffe.org> Message-ID: <20111205195017.GA1454@vacation.karoshi.com.> the problem w/ working from home is that not everyone appreciates "Those Darned Accordians" or "Insane Clown Posse" or "Donny and Marie Osmand" at 0330 local cranked up to 11... Much easier to pull off in a remote, mostly empty office building. And no one complains about my singing off key. /bill From tayeb.meftah at gmail.com Sun Dec 4 12:27:21 2011 From: tayeb.meftah at gmail.com (Meftah Tayeb) Date: Sun, 4 Dec 2011 20:27:21 +0200 Subject: 128.0.0.0/16 configured as martians in some routers References: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> <45D79898-3854-4671-AC9E-317A65C28FC7@ripe.net> <20111205194422.GC26078@hiwaay.net> Message-ID: <2E68B0902E15414AA2CFD150B36AD438@work> We do have it from Level3: C:\Documents and Settings\TAYEB>tracert 128.0.0.1 D?termination de l'itin?raire vers 128.0.0.1 avec un maximum de 30 sauts. 1 1 ms 3 ms 3 ms 172.28.0.1 2 3 ms 3 ms 3 ms 10.16.0.1 3 13 ms 15 ms 16 ms 41.200.0.1 4 32 ms 12 ms 16 ms 172.17.2.25 5 15 ms 16 ms 16 ms 213.140.58.10 6 35 ms 40 ms 34 ms 212.73.253.65 7 39 ms 39 ms 39 ms ae-5-6.bar2.Marseille1.Level3.net [4.69.151.13] 8 52 ms 76 ms 54 ms ae-15-15.ebr1.Frankfurt1.Level3.net [4.69.143.24 6] 9 56 ms 56 ms 55 ms ae-81-81.csw3.Frankfurt1.Level3.net [4.69.140.10 ] 10 55 ms 55 ms 57 ms ae-82-82.ebr2.Frankfurt1.Level3.net [4.69.140.25 ] 11 58 ms 67 ms 62 ms ae-46-46.ebr1.Dusseldorf1.Level3.net [4.69.143.1 69] 12 55 ms 55 ms 56 ms ae-24-24.ebr2.Dusseldorf1.Level3.net [4.69.143.1 94] 13 172 ms 58 ms 57 ms ae-48-48.ebr1.Amsterdam1.Level3.net [4.69.143.20 9] 14 58 ms 58 ms 67 ms ae-59-114.csw1.Amsterdam1.Level3.net [4.69.153.1 98] 15 60 ms 62 ms 62 ms ae-19-51.sar1.Amsterdam1.Level3.net [4.69.139.14 6] 16 * 56 ms 58 ms 128.0.0.1 Itin?raire d?termin?. C:\Documents and Settings\TAYEB> ----- Original Message ----- From: "Chris Adams" To: "Alex Le Heux" Cc: Sent: Monday, December 05, 2011 9:44 PM Subject: Re: 128.0.0.0/16 configured as martians in some routers > Once upon a time, Alex Le Heux said: >> Dear Colleagues, >> >> The correct prefix and pingable address list for the Debogonising Project >> is: >> >> prefix pinagble address >> >> 128.0.0.0/21 128.0.0.1 >> 128.0.24.0/24 128.0.24.1 >> >> Our apologies for the oversight. > > Are these prefixes being announced widely? I don't see anything for > 128.0.0.0/16 from my upstreams, nor at many public looking glasses. > > -- > Chris Adams > Systems and Network Administrator - HiWAAY Internet Services > I don't speak for anybody but myself - that's enough trouble. > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 6686 (20111205) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 6686 (20111205) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From pixitha.kyle at gmail.com Mon Dec 5 16:09:11 2011 From: pixitha.kyle at gmail.com (Kyle Duren) Date: Mon, 5 Dec 2011 14:09:11 -0800 Subject: 128.0.0.0/16 configured as martians in some routers In-Reply-To: <20111205194422.GC26078@hiwaay.net> References: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> <45D79898-3854-4671-AC9E-317A65C28FC7@ripe.net> <20111205194422.GC26078@hiwaay.net> Message-ID: I'm see them from NTT. -Kyle On Mon, Dec 5, 2011 at 11:44 AM, Chris Adams wrote: > Once upon a time, Alex Le Heux said: > > Dear Colleagues, > > > > The correct prefix and pingable address list for the Debogonising > Project is: > > > > prefix pinagble address > > > > 128.0.0.0/21 128.0.0.1 > > 128.0.24.0/24 128.0.24.1 > > > > Our apologies for the oversight. > > Are these prefixes being announced widely? I don't see anything for > 128.0.0.0/16 from my upstreams, nor at many public looking glasses. > > -- > Chris Adams > Systems and Network Administrator - HiWAAY Internet Services > I don't speak for anybody but myself - that's enough trouble. > > From andy at andy.net Mon Dec 5 16:19:12 2011 From: andy at andy.net (Andy Warner) Date: Tue, 6 Dec 2011 06:19:12 +0800 Subject: Global BGP and Google In-Reply-To: <1323110502.64552.YahooMailNeo@web160104.mail.bf1.yahoo.com> References: <1323110502.64552.YahooMailNeo@web160104.mail.bf1.yahoo.com> Message-ID: On Tue, Dec 6, 2011 at 2:41 AM, Victor Esposito wrote: > Has anyone had any experience with a Global? ASN, and Google inappropriately associating IP's to the wrong countries? > > We have our AS registered in Argentina, with ARIN space under it.? From time to time, Google thinks the IP's are in Argentina, even though they are in the US.? We have this issue elsewhere across the globe as well. > > I was pondering multiple ASN's, but I was not sure if there was a better method for dealing with this. > > > Thanks in advance! > > Victor Esposito Maintaining IP-Geolocation mappings in inherently hard so they're not perfect. You'll probably need to update multiple IP Geolocation providers, but you can provide corrections to Google using this form: http://www.google.com/support/websearch/bin/request.py?contact_type=ip -- Andy From jbates at brightok.net Mon Dec 5 16:25:11 2011 From: jbates at brightok.net (Jack Bates) Date: Mon, 05 Dec 2011 16:25:11 -0600 Subject: On Working Remotely In-Reply-To: <201112051200.25542.david@davidradcliffe.org> References: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com> <201112051009.09009.david@davidradcliffe.org> <20111205154003.GP22948@netmeister.org> <201112051200.25542.david@davidradcliffe.org> Message-ID: <4EDD44C7.4060506@brightok.net> On 12/5/2011 11:00 AM, David Radcliffe wrote: > I know many people who can work as you and we all adjust to our setting. I > just also know people who gravitate to their distractions and need the wall to > define work. It's best for me even though I will work as effectively at > midnight as in the middle of the day. > > I have to say I am impressed. Working with a 4 year old and 2 month old > around. Wow. > Being a forced office worker, I can honestly say that I still get more done at home at night than I do during the day at the office. I'm most productive when I have scheduled maintenance, as I'm permitted to sleep in, which puts me working during my comfortable time frames (I hate getting up early). When I was younger, I did my best work at the applebee's bar. Even had my own brass plate on the bar. C++ and tequila worked well together. For the record, my home schooling son does more work late at night as well. Jack From jbates at brightok.net Mon Dec 5 16:33:16 2011 From: jbates at brightok.net (Jack Bates) Date: Mon, 05 Dec 2011 16:33:16 -0600 Subject: 128.0.0.0/16 configured as martians in some routers In-Reply-To: <20111205194422.GC26078@hiwaay.net> References: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> <45D79898-3854-4671-AC9E-317A65C28FC7@ripe.net> <20111205194422.GC26078@hiwaay.net> Message-ID: <4EDD46AC.60909@brightok.net> On 12/5/2011 1:44 PM, Chris Adams wrote: > Once upon a time, Alex Le Heux said: >> Dear Colleagues, >> >> The correct prefix and pingable address list for the Debogonising Project is: >> >> prefix pinagble address >> >> 128.0.0.0/21 128.0.0.1 >> 128.0.24.0/24 128.0.24.1 >> >> Our apologies for the oversight. > > Are these prefixes being announced widely? I don't see anything for > 128.0.0.0/16 from my upstreams, nor at many public looking glasses. > Once I updated junos 10.4R7.5 martian list, I saw them both from level3 and qwest, but not from Sprint. Jack From cmadams at hiwaay.net Mon Dec 5 16:36:54 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 5 Dec 2011 16:36:54 -0600 Subject: 128.0.0.0/16 configured as martians in some routers In-Reply-To: <4EDD46AC.60909@brightok.net> References: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> <45D79898-3854-4671-AC9E-317A65C28FC7@ripe.net> <20111205194422.GC26078@hiwaay.net> <4EDD46AC.60909@brightok.net> Message-ID: <20111205223654.GD26078@hiwaay.net> Once upon a time, Jack Bates said: > On 12/5/2011 1:44 PM, Chris Adams wrote: > >Once upon a time, Alex Le Heux said: > >>Dear Colleagues, > >> > >>The correct prefix and pingable address list for the Debogonising Project > >>is: > >> > >>prefix pinagble address > >> > >>128.0.0.0/21 128.0.0.1 > >>128.0.24.0/24 128.0.24.1 > >> > >>Our apologies for the oversight. > > > >Are these prefixes being announced widely? I don't see anything for > >128.0.0.0/16 from my upstreams, nor at many public looking glasses. > > Once I updated junos 10.4R7.5 martian list, I saw them both from level3 > and qwest, but not from Sprint. Sorry, I should have said where I looked. I'm not seeing them from Sprint or CenturyLink, nor am I seeing them at route-views/looking glasses from AT&T or TWTC. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From richard.barnes at gmail.com Mon Dec 5 17:24:35 2011 From: richard.barnes at gmail.com (Richard Barnes) Date: Mon, 5 Dec 2011 18:24:35 -0500 Subject: Global BGP and Google In-Reply-To: References: <1323110502.64552.YahooMailNeo@web160104.mail.bf1.yahoo.com> Message-ID: See also this: https://labs.ripe.net/Members/denis/geolocation-prototype-for-ripe-database Speak up if you want something similar in the ARIN or LACNIC regions. --Richard On Dec 5, 2011 5:19 PM, "Andy Warner" wrote: On Tue, Dec 6, 2011 at 2:41 AM, Victor Esposito wrote: > Has anyone had a... Maintaining IP-Geolocation mappings in inherently hard so they're not perfect. You'll probably need to update multiple IP Geolocation providers, but you can provide corrections to Google using this form: http://www.google.com/support/websearch/bin/request.py?contact_type=ip -- Andy From bmanning at vacation.karoshi.com Mon Dec 5 17:44:19 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 5 Dec 2011 23:44:19 +0000 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] Message-ID: <20111205234419.GD1454@vacation.karoshi.com.> With permission.... ----- Forwarded message from Fyodor ----- Date: Mon, 5 Dec 2011 14:35:30 -0800 Hi Folks. I've just discovered that C|Net's Download.Com site has started wrapping their Nmap downloads (as well as other free software like VLC) in a trojan installer which does things like installing a sketchy "StartNow" toolbar, changing the user's default search engine to Microsoft Bing, and changing their home page to Microsoft's MSN. The way it works is that C|Net's download page (screenshot attached) offers what they claim to be Nmap's Windows installer. They even provide the correct file size for our official installer. But users actually get a Cnet-created trojan installer. That program does the dirty work before downloading and executing Nmap's real installer. Of course the problem is that users often just click through installer screens, trusting that download.com gave them the real installer and knowing that the Nmap project wouldn't put malicious code in our installer. Then the next time the user opens their browser, they find that their computer is hosed with crappy toolbars, Bing searches, Microsoft as their home page, and whatever other shenanigans the software performs! The worst thing is that users will think we (Nmap Project) did this to them! I took and attached a screen shot of the C|Net trojan Nmap installer in action. Note how they use our registered "Nmap" trademark in big letters right above the malware "special offer" as if we somehow endorsed or allowed this. Of course they also violated our trademark by claiming this download is an Nmap installer when we have nothing to do with the proprietary trojan installer. In addition to the deception and trademark violation, and potential violation of the Computer Fraud and Abuse Act, this clearly violates Nmap's copyright. This is exactly why Nmap isn't under the plain GPL. Our license (http://nmap.org/book/man-legal.html) specifically adds a clause forbidding software which "integrates/includes/aggregates Nmap into a proprietary executable installer" unless that software itself conforms to various GPL requirements (this proprietary C|Net download.com software and the toolbar don't). We've long known that malicious parties might try to distribute a trojan Nmap installer, but we never thought it would be C|Net's Download.com, which is owned by CBS! And we never thought Microsoft would be sponsoring this activity! It is worth noting that C|Net's exact schemes vary. Here is a story about their shenanigans: http://www.extremetech.com/computing/93504-download-com-wraps-downloads-in-bloatware-lies-about-motivations It is interesting to compare the trojaned VLC screenshot in that article with the Nmap one I've attached. In that case, the user just clicks "Next step" to have their machine infected. And they wrote "SAFE, TRUSTED, AND SPYWARE FREE" in the trojan-VLC title bar. It is telling that they decided to remove that statement in their newer trojan installer. In fact, if we UPX-unpack the Trojan CNet executable and send it to VirusTotal.com, it is detected as malware by Panda, McAfee, F-Secure, etc: http://bit.ly/cnet-nmap-vt According to Download.com's own stats, hundreds of people download the trojan Nmap installer every week! So the first order of business is to notify the community so that nobody else falls for this scheme. Please help spread the word. Of course the next step is to go after C|Net until they stop doing this for ALL of the software they distribute. So far, the most they have offered is: "If you would like to opt out of the Download.com Installer you can submit a request to cnet-installer at cbsinteractive.com. All opt-out requests are carefully reviewed on a case-by-case basis." In other words, "we'll violate your trademarks and copyright and squandering your goodwill until you tell us to stop, and then we'll consider your request 'on a case-by-case basis' depending on how much money we make from infecting your users and how scary your legal threat is. F*ck them! If anyone knows a great copyright attorney in the U.S., please send me the details or ask them to get in touch with me. Also, shame on Microsoft for paying C|Net to trojan open source software! Cheers, Fyodor ----- End forwarded message ----- From jay at west.net Mon Dec 5 18:39:55 2011 From: jay at west.net (Jay Hennigan) Date: Mon, 05 Dec 2011 16:39:55 -0800 Subject: Flapping POS Interface on Frame-relay between a Juniper and Cisco In-Reply-To: References: Message-ID: <4EDD645B.6070001@west.net> On 11/19/11 8:11 AM, Righa Shake wrote: > Hi, > > Am having a problem that is buffling. > > I recently changed a POS link encapsulation from PPP to Frame-relay. > Since that time the POS interface keeps resetting from time to time. > > On my BGP session am receiving cease notifications from my upstream > provider. > > The setup is such that we have a cisco on one end and a Juniper on the > other. > > interface POS0/0/0 > mtu 4474 Does this match the other end? > no ip address > no ip unreachables > encapsulation frame-relay You might try "encapsulation frame-relay ietf" for full compatibility with non-Cisco gear at the other end. > logging event link-status > crc 32 > pos scramble-atm > frame-relay lmi-type ansi > end > > ROUTERshow run int pos0/0/0.101 > Building configuration... [snippage] > ! > interface POS0/0/0.101 point-to-point > LMI enq sent 81981, LMI stat recvd 77480, LMI upd recvd 0, DTE LMI up ^^^^^ ^^^^^ Something is dropping frames. [snippage] > Last clearing of "show interface" counters 1w2d [snippage] > 6970870 runts, 2179 giants, 0 throttles > 0 parity > 892493293 input errors, 882184781 CRC, 0 frame, 0 overrun, 0 ignored, > 3335463 abort Lots of CRC line errors, runts, giants, LMI dropped frames. Kind of looks like you could have a physical problem with the link itself. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From surfer at mauigateway.com Mon Dec 5 18:55:04 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 5 Dec 2011 16:55:04 -0800 Subject: Flapping POS Interface on Frame-relay between a Juniper and Cisco Message-ID: <20111205165504.2DC0C71@m0005297.ppops.net> On 11/19/11 8:11 AM, Righa Shake wrote: > Hi, > > Am having a problem that is buffling. > > I recently changed a POS link encapsulation from PPP to Frame-relay. > Since that time the POS interface keeps resetting from time to time. > > On my BGP session am receiving cease notifications from my upstream > provider. > > The setup is such that we have a cisco on one end and a Juniper on the > other. ------------------------------------------------------- Were you not able to get it going after the discussion on AfNOG? http://afnog.org/pipermail/afnog/2011-November/000016.html What else is happening? Still seeing alarms and flapping at the reduced rate? If so, what alarms and how often is it flapping? scott From jsaxe at briworks.com Mon Dec 5 19:20:56 2011 From: jsaxe at briworks.com (Jeff Saxe) Date: Tue, 6 Dec 2011 01:20:56 +0000 Subject: Flapping POS Interface on Frame-relay between a Juniper and Cisco In-Reply-To: References: Message-ID: Ah, memories are flooding back from my Voice over Frame Relay days on a Cisco MC3810. We would crush compressed G.729a voice and barely-enough data for 24 remote call center employees into, I believe, two quarter-T1 frame DLCI's to keep costs down. Anyway, I believe this is the explanation for your flapping: a PPP link is intended to go between two routers over, for instance, a private leased line, so both of the devices are peers, neither one particularly special. Frame-relay, by contrast, was originally designed so that your router was an "end user" device and its directly-connected partner device was not your other router, which you control, but the frame carrier's frame-relay switch. Your router was a DTE device, and their switch, which was in a more "important" position in control of the frame-relay NBMA cloud, was the DCE device. Your router then slaved to the frame switch via LMI signaling, so that the upstream switch instructed you which DLCIs existed and were up at the moment. So if you connect up two routers with frame-relay encap and each thinks it is the DTE, and neither one is taking the role of the frame switch, then when you bring them up, they will initially optimistically think their DLCIs are up and working, and the routing protocol and traffic will come up... but both of them will be waiting for the frame switch to send them LMI indicating that their idea of the DLCI up/down status is correct. When a couple minutes go by and they don't hear the responses to their LMI enquiries, they will bring all the DLCI's down. I thought they would then stay down forever, i.e., not flap, but maybe you are shutting / no shutting the POS circuit to try again. Anyway, I believe the very simple fix is interface POS0/0/0 frame-relay intf-type dce So this will turn your Cisco side of the circuit into "DCE" mode, and if the Juniper side stays in "DTE" mode (the default, so probably not listed in the config), then the LMI should start behaving between the two. And yes, as Jay Hennigan suggested, you might need to use "encap frame-relay ietf" to be compatible with non-Cisco gear, or you might need to adjust the frame-relay lmi-type -- one type sends the LMI on DLCI number 0, one of them on DLCI 1023, whatever. I think you'll need to adjust the two ends until you see LMI enquiries both sent and received; right now the "show interface" from the Cisco side shows it has not received any LMI enq yet. Good luck, and I hope it's that simple. :-) Jeff Saxe blue ridge internetworks 321 east main st ? suite 200 charlottesville va 22902 434.817.0707 x 2024 www.briworks.com Central Virginia?s technology authority since 2000. ________________________________________ From: Righa Shake [righa.shake at gmail.com] Sent: Saturday, November 19, 2011 11:11 AM To: afnog at afnog.org Subject: Flapping POS Interface on Frame-relay between a Juniper and Cisco Hi, Am having a problem that is buffling. I recently changed a POS link encapsulation from PPP to Frame-relay. Since that time the POS interface keeps resetting from time to time. On my BGP session am receiving cease notifications from my upstream provider. The setup is such that we have a cisco on one end and a Juniper on the other. interface POS0/0/0 mtu 4474 no ip address no ip unreachables encapsulation frame-relay logging event link-status crc 32 pos scramble-atm frame-relay lmi-type ansi end ROUTERshow run int pos0/0/0.101 Building configuration... ! interface POS0/0/0.101 point-to-point ip address X.X.X.X 255.255.255.252 frame-relay interface-dlci 101 end ROUTER#show int pos0/0/0 POS0/0/0 is up, line protocol is up Hardware is SPA-2XOC12-POS MTU 4474 bytes, BW 622000 Kbit/sec, DLY 100 usec, reliability 255/255, txload 6/255, rxload 38/255 Encapsulation FRAME-RELAY, crc 32, loopback not set Keepalive set (10 sec) Scramble enabled LMI enq sent 81981, LMI stat recvd 77480, LMI upd recvd 0, DTE LMI up LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 LMI DLCI 0 LMI type is ANSI Annex D frame relay DTE segmentation inactive FR SVC disabled, LAPF state down Broadcast queue 0/256, broadcasts sent/dropped 26/0, interface broadcasts 0 Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters 1w2d Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 94336000 bits/sec, 13151 packets/sec 5 minute output rate 16470000 bits/sec, 7049 packets/sec 12211574207 packets input, 10967607038364 bytes, 0 no buffer Received 0 broadcasts (0 IP multicasts) 6970870 runts, 2179 giants, 0 throttles 0 parity 892493293 input errors, 882184781 CRC, 0 frame, 0 overrun, 0 ignored, 3335463 abort 6379191154 packets output, 1614018181446 bytes, 0 underruns 0 output errors, 0 applique, 4 interface resets 0 unknown protocol drops 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions Any assistance on this will be greatly appreciated. Regards, Righa Shake From smb at cs.columbia.edu Mon Dec 5 19:29:51 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Mon, 5 Dec 2011 20:29:51 -0500 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: <20111205234419.GD1454@vacation.karoshi.com.> References: <20111205234419.GD1454@vacation.karoshi.com.> Message-ID: <7C3EC9B8-0A33-4382-B21E-3905BB986428@cs.columbia.edu> > > > F*ck them! If anyone knows a great copyright attorney in the U.S., > please send me the details or ask them to get in touch with me. Hmm -- did you say "copyright"? I wonder what would happen if you sent them a DMCA takedown notice. To quote Salvor Hardin, "It's a poor atom blaster that doesn't point both ways." (And there's another Hardin quote that seems particularly apt when talking about wielding the DMCA: "Never let your sense of morals prevent you from doing what is right.") --Steve Bellovin, https://www.cs.columbia.edu/~smb From jra at baylink.com Mon Dec 5 20:07:49 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 5 Dec 2011 21:07:49 -0500 (EST) Subject: IP addresses are now assets In-Reply-To: <9895F3A7-847D-44BA-A2E2-43418BE3E677@delong.com> Message-ID: <30536137.1671.1323137269092.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > On Dec 5, 2011, at 12:27 AM, cdel.firsthand.net wrote: > > The British have been using the correct six character word length > > for humour ad memoriam. > > Extra and unnecessary characters do not a correct word make. The u is silent. Like the 3 in Hen3ry. Cheers, -- jr 'Stein with an "e-i" and Styne with a "y".' a -- 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 http://photo.imageinc.us +1 727 647 1274 From jra at baylink.com Mon Dec 5 20:12:19 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 5 Dec 2011 21:12:19 -0500 (EST) Subject: On Working Remotely In-Reply-To: <20111205195017.GA1454@vacation.karoshi.com.> Message-ID: <25162019.1673.1323137539364.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: bmanning at vacation.karoshi.com > the problem w/ working from home is that not everyone appreciates "Those > Darned Accordians" or "Insane Clown Posse" or "Donny and Marie Osmand" at > 0330 local cranked up to 11... Nope, Manning; sorry: if you're gonna cop to Donny and Marie, you gotta spell their last name right. :-) Cheers, -- jr 'at least he didn't spell it Donnie' a -- 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 http://photo.imageinc.us +1 727 647 1274 From jra at baylink.com Mon Dec 5 20:16:35 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 5 Dec 2011 21:16:35 -0500 (EST) Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: <20111205234419.GD1454@vacation.karoshi.com.> Message-ID: <16796209.1677.1323137795128.JavaMail.root@benjamin.baylink.com> Fyodor: > F*ck them! If anyone knows a great copyright attorney in the U.S., > please send me the details or ask them to get in touch with me. Larry Lessig? Mike Godwin? Might as well start at the top, dude. 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 http://photo.imageinc.us +1 727 647 1274 From jcurran at arin.net Mon Dec 5 21:09:50 2011 From: jcurran at arin.net (John Curran) Date: Tue, 6 Dec 2011 03:09:50 +0000 Subject: IP addresses are now assets In-Reply-To: <4ED8686C.6020803@paulgraydon.co.uk> References: <4ED8686C.6020803@paulgraydon.co.uk> Message-ID: <457C7781-E2B7-4AD0-BE26-8EB8A1EF7AF4@corp.arin.net> On Dec 2, 2011, at 1:55 AM, Paul Graydon wrote: > On 12/1/2011 7:20 PM, John Curran wrote: >> Wayne - >> >> Your subject line (IP addresses are now assets) could mislead folks, >> so I'd advise waiting to review the actual sale order once approved by >> the court before making summary conclusions. >> >> ARIN holds that IP address space is not property but is managed as a >> public resource. Address holders may have certain rights (such as the >> right to be the registrant of the address block, the right to transfer the >> registration, etc.) but these rights intersect with additional rights to the >> same address blocks which are held by the community (such as the right >> of visibility to the public portion of registrations). The registry policies >> (set by the community via open and transparent processes) govern the >> intersection and application of these rights. >> >> For this reason, ARIN works with parties transferring their rights in IP >> address space to make sure that the documents reflect that sales of >> rights are subject to the transfer policies in the region, including in this >> particular case. A party may transfer their rights to IP addresses, and >> such rights may have value to an estate, but this does not make the >> IP addresses "property" per se. >> >> Thanks! >> /John >> > > Why'd you have to spoil the fun? You're supposed to wait a few days, let the pointless righteous fury build up and then step in and try to do the firefighting thing. It's must have been all but a month since the last time this flared up, it's surely about time it flared up again? Wouldn't want anyone to miss out on the fun ;) That's okay... it will happen anyway. ;-) For those who are following this matter, there are some more complete articles now (including pointers to the court documents filed) - FYI, /John John Curran President and CEO ARIN From daniel.unam.ipv6 at gmail.com Mon Dec 5 21:35:35 2011 From: daniel.unam.ipv6 at gmail.com (Daniel Espejel) Date: Mon, 05 Dec 2011 21:35:35 -0600 Subject: HP IPv6 RA Guard In-Reply-To: References: Message-ID: <4EDD8D87.30208@gmail.com> So,still assuming the fact that attackers will use the same "traditional ipv4" methods to alter the correct functioning over a network?...Well, maybe. Toda's IPv6 expertise for some network andmins and security experts is minimal. So most trainning and understanding before implementing its a good idea. For example, the RA-Guard method has a significant vulnerability: It's not designed to identify a "complex" IPv6-many extension headers formed packet (F. Gont - 6Networks). Some other security oriented mechanisms may fail because of the low IPv6 compliance. Regards. -- Daniel Espejel P?rez T?cnico Acad?mico D.G.T.I.C. - U.N.A.M. GT-IPv6 CLARA / GT-IPv6 U.N.A.M. From streiner at cluebyfour.org Mon Dec 5 22:01:04 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 5 Dec 2011 23:01:04 -0500 (EST) Subject: On Working Remotely In-Reply-To: <201112051009.09009.david@davidradcliffe.org> References: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com> <201112051009.09009.david@davidradcliffe.org> Message-ID: On Mon, 5 Dec 2011, David Radcliffe wrote: > I do have to say to anyone planning to work from home, make sure you have a > proper work space. I have a computer room. It contains a dozen systems, > electronics gear and parts (I used to have time for that hobby), and > comfortable and ergonomic work spaces. There is no TV. No reason for one > because this is the work room. The mind set should be "I am now in the work > room, so I am at work." Really works for me. That's one of the reasons that I don't work from home very much at this point - I don't have a proper office, however I'm hoping to fix that some time next year. The other reasons I don't work from home very much are that my job still has a lot of hands-on responsibilities (which I don't mind - pulling cable or racking equipment is a nice break from staring at a screen for long periods of time), and, unfortunately, upper managements' perceptions of things like teleworking and flex/comp time have not caught up with the times :( jms From bill at herrin.us Mon Dec 5 22:20:04 2011 From: bill at herrin.us (William Herrin) Date: Mon, 5 Dec 2011 18:20:04 -1000 Subject: On Working Remotely In-Reply-To: References: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com> Message-ID: I teleworked for a few years back in the '90s. I would share a couple of thoughts: 1. You have to have the disposition for it. For a coder, you have to be the kind of person who sits down at a computer and writes code, just because. If it would "require discipline" for you to work from a home office, telework may not be right for you. 2. If most of the team works in an office, full time telework for any member of the team is hard. Folks working together in an office develop a social dynamic. Folks who aren't there aren't a part of that dynamic. Teleworking is most likely to work out when most or all of the team teleworks, not just particular members. 2a. You can still telework two days a week and spend the other three in an office. But not Monday or Friday. Especially not Friday -- after the rest of the week working in the office, you just won't do it. Your brain will turn off if you try to work from home Friday after Thursday in the office. 3. Beware tracking hours. Try to select work which is goal and deadline based. Your supervisor won't see you in your seat; he can only judge your performance on what you actually accomplish. When I teleworked, I found myself taking breaks to mow the lawn, ride a bike on a nice day or tinker with a personal server. Tracking hours under such circumstances is almost impossibly hard. Measuring progress towards a goal is less so. -Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From frnkblk at iname.com Tue Dec 6 00:11:42 2011 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 6 Dec 2011 00:11:42 -0600 Subject: Email from AssetAuctions Message-ID: <017501ccb3dd$ec6e7cf0$c54b76d0$@iname.com> Did anyone else received unsolicited an email from AssetAuctions? Our CFO received an email from them selling two full /16's and a partial /16. There is an unsubscribe feature, but I thought it was interesting, in light of the Border's IP sale event. I was encouraged by this language, This opportunity is available to a company with justifiable need to acquire large contiguous blocks of IP addresses. The Buyer must ensure compliance with certain requirements of the American Registry of Internet Numbers ("ARIN"). Transfer of these IP addresses may be subject to approval by "ARIN" and contingent on verification the transfer request meets the requirements of NRPM 8.3 (https://www.arin.net/policy/nrpm.html#eight). Frank From andrew.wallace at rocketmail.com Tue Dec 6 00:14:48 2011 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Mon, 5 Dec 2011 22:14:48 -0800 (PST) Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: <20111205234419.GD1454@vacation.karoshi.com.> References: <20111205234419.GD1454@vacation.karoshi.com.> Message-ID: <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> Using fruitful language and acting like a child isn't going to see you taken seriously. Andrew > ----- Forwarded message from Fyodor ----- > F*ck them!? If anyone knows a great copyright attorney in the U.S., > please send me the details or ask them to get in touch with me. > > Also, shame on Microsoft for paying C|Net to trojan open source > software! > > Cheers, > Fyodor > > ----- End forwarded message ----- From jvanoppen at spectrumnet.us Tue Dec 6 00:15:44 2011 From: jvanoppen at spectrumnet.us (John van Oppen) Date: Tue, 6 Dec 2011 06:15:44 +0000 Subject: 128.0.0.0/16 configured as martians in some routers In-Reply-To: <20111205223654.GD26078@hiwaay.net> References: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> <45D79898-3854-4671-AC9E-317A65C28FC7@ripe.net> <20111205194422.GC26078@hiwaay.net> <4EDD46AC.60909@brightok.net> <20111205223654.GD26078@hiwaay.net> Message-ID: Here is my little table for 128.0.0.0/21 based on our upstreams: AS7922: Yes AS174: No AS2914: Yes AS3257: Yes AS2914: Yes AS2828: No AS209: Yes John @ AS11404 From mtinka at globaltransit.net Tue Dec 6 00:19:00 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Tue, 6 Dec 2011 14:19:00 +0800 Subject: On Working Remotely In-Reply-To: <4EDD44C7.4060506@brightok.net> References: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com> <201112051200.25542.david@davidradcliffe.org> <4EDD44C7.4060506@brightok.net> Message-ID: <201112061419.03657.mtinka@globaltransit.net> On Tuesday, December 06, 2011 06:25:11 AM Jack Bates wrote: > Being a forced office worker, I can honestly say that I > still get more done at home at night than I do during > the day at the office. I'm most productive when I have > scheduled maintenance, as I'm permitted to sleep in, > which puts me working during my comfortable time frames > (I hate getting up early). Agree, I get more work done at home as well, be it at night or during the day, than I do during office hours as the a good chunk of the week normally ends up being full of face- to-face meetings, and then it's over. It is harder to work at home becuse of the distractions, but when I can, it is more effective. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From eyeronic.design at gmail.com Tue Dec 6 00:23:41 2011 From: eyeronic.design at gmail.com (Mike Hale) Date: Mon, 5 Dec 2011 22:23:41 -0800 Subject: High latency/dropped packets on Mitel circuit in LA In-Reply-To: <4EDD04F9.8010407@gmail.com> References: <4EDD04F9.8010407@gmail.com> Message-ID: I've had some odd issues with Level 3 in LA, but that was due to an issue with their TWOceanic interconnect. Other than that, I haven't heard of anything. Do you see any errors on your interface? - Mike On Mon, Dec 5, 2011 at 9:52 AM, Paul Brown wrote: > I'm having some pretty bad connection issues with one of my remote > offices in LA. I figured it was probably wind-related last week but it's > still going on today. The vendor (Mitel) is saying that they're testing > the circuit as good to the router, but I doubt it because I'm seeing the > same missed pings on both the outside and inside interfaces from here > (Richmond, VA) across the MPLS network. > > I know it's possible that it could be the router, but my gut tells me > it's a circuit issue. Does anybody know of anything going on out there? > > Thanks, > Paul > > -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From lstewart at superb.net Tue Dec 6 00:45:56 2011 From: lstewart at superb.net (Landon Stewart) Date: Mon, 5 Dec 2011 22:45:56 -0800 Subject: On Working Remotely In-Reply-To: <5E35BA1B-0B09-4E3E-8F45-B9A4F2EDEDBC@seanharlow.info> References: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com> <201112051009.09009.david@davidradcliffe.org> <5E35BA1B-0B09-4E3E-8F45-B9A4F2EDEDBC@seanharlow.info> Message-ID: This thread reminded me of a The Oatmeal comic I saw not too long ago. This explains the *good* and *horrible* about working from home. http://theoatmeal.com/comics/working_home -- Landon Stewart Manager of Systems and Engineering Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead of the Rest": http://www.superbhosting.net From fweimer at bfk.de Tue Dec 6 02:50:46 2011 From: fweimer at bfk.de (Florian Weimer) Date: Tue, 06 Dec 2011 08:50:46 +0000 Subject: 128.0.0.0/16 configured as martians in some routers In-Reply-To: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> (Alex Le Heux's message of "Mon, 5 Dec 2011 16:20:27 +0100") References: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> Message-ID: <82zkf6t76h.fsf@mid.bfk.de> * Alex Le Heux: > The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by > default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline > that this /16 should no longer be reserved as specialised address > space. Would someone please clarify the impact? Will it result in a blackhole, or will the entire announcement be suppressed? I suspect the latter, given what we see and what Chris Adams has reported. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From mtinka at globaltransit.net Tue Dec 6 03:23:53 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Tue, 6 Dec 2011 17:23:53 +0800 Subject: 128.0.0.0/16 configured as martians in some routers In-Reply-To: <82zkf6t76h.fsf@mid.bfk.de> References: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> <82zkf6t76h.fsf@mid.bfk.de> Message-ID: <201112061723.56243.mtinka@globaltransit.net> On Tuesday, December 06, 2011 04:50:46 PM Florian Weimer wrote: > Would someone please clarify the impact? Will it result in a blackhole, > or will the entire announcement be suppressed? I suspect the latter, > given what we see and what Chris Adams has reported. This is what we see on Cisco IOS and IOS XR boxes: lab#sh ip bgp 128.0.0.0 BGP routing table entry for 128.0.0.0/21, version 260804693 Paths: (2 available, best #1, table default) Advertised to update-groups: 2 3491 3257 1103 12654 61.11.xxx.yy (metric 34400) from 61.11.xxx.zz (61.11.xxx.zz) Origin IGP, metric 0, localpref 100, valid, internal, best Community: 24218:1 Originator: 61.11.xxx.yy, Cluster list: 0.0.0.2 3491 3257 1103 12654 61.11.xxx.yy (metric 34400) from 61.11.xxx.ww (61.11.xxx.ww) Origin IGP, metric 0, localpref 100, valid, internal Community: 24218:1 Originator: 61.11.xxx.yy, Cluster list: 0.0.0.2 lab# RP/0/RSP0/CPU0:lab#sh route 128.0.0.0 Tue Dec 6 17:09:13.439 MYT Routing entry for 128.0.0.0/21 Known via "bgp 24218", distance 200, metric 0 Tag 3491, type internal Installed Dec 4 20:00:33.089 for 1d21h Routing Descriptor Blocks 61.11.xxx.yy, from 61.11.yyy.zz Route metric is 0 No advertising protos. RP/0/RSP0/CPU0:lab# This is what we see on an unfixed Juniper: tinka at lab# run show route 128.0.0.0 inet.0: 384214 destinations, 768288 routes (384212 active, 0 holddown, 4 hidden) Restart Complete + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[Static/5] 20w2d 13:21:14 Discard [edit] tinka at lab# tinka at lab# run show route 128.0.0.0/21 inet.0: 384218 destinations, 768296 routes (384216 active, 0 holddown, 4 hidden) Restart Complete [edit] tinka at lab# tinka at edge-gw-1-sin-pip.sg# run show route 128.0.0.0/21 hidden inet.0: 384224 destinations, 768308 routes (384222 active, 0 holddown, 4 hidden) Restart Complete + = Active Route, - = Last Active, * = Both 128.0.0.0/21 [BGP/170] 1d 21:17:54, MED 0, localpref 100, from 61.11.xxx.ww AS path: 3491 3257 1103 12654 I > to 124.158.xxx.uu via ge-0/0/0.0, Push 16052 to 124.158.xxx.vv via ge-0/0/0.0, Push 16017 to 124.158.xxx.ww via ge-0/1/0.0, Push 16052 to 124.158.xxx.xx via ge-0/1/0.0, Push 16017 [BGP/170] 1d 21:17:54, MED 0, localpref 100, from 61.11.xxx.zz AS path: 3491 3257 1103 12654 I > to 124.158.xxx.uu via ge-0/0/0.0, Push 16052 to 124.158.xxx.vv via ge-0/0/0.0, Push 16017 to 124.158.xxx.ww via ge-0/1/0.0, Push 16052 to 124.158.xxx.xx via ge-0/1/0.0, Push 16017 [edit] tinka at edge-gw-1-sin-pip.sg# tinka at lab# run show route 128.0.0.0/21 hidden extensive | match State State: State: [edit] tinka at lab# tinka at lab# run show interfaces terse ... fxp1 up up fxp1.0 up up inet 10.0.0.1/8 10.0.0.4/8 128.0.0.1/2 128.0.0.4/2 inet6 fe80::200:ff:fe00:4/64 fec0::a:0:0:4/64 tnp 0x4 ... [edit] tinka at lab# This is what we see on a Cisco router which lives behind an unfixed Juniper router that is peering externally: lab#sh ip bgp 128.0.0.0 % Network not in table lab# So our deduction - if a Juniper router is in the data path, it will blackhole traffic destined to this address. If a Juniper is in the control plane path, it will filter this prefix and not send it to the rest of the network. Either way, you're screwed :-). Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From rps at maine.edu Tue Dec 6 07:46:22 2011 From: rps at maine.edu (Ray Soucy) Date: Tue, 6 Dec 2011 08:46:22 -0500 Subject: HP IPv6 RA Guard In-Reply-To: <4EDD8D87.30208@gmail.com> References: <4EDD8D87.30208@gmail.com> Message-ID: I think of RA Guard as a Layer-2 stability feature, rather than a security feature. You're correct that it is unable to deal with RA crafted in a fragmented packet on the majority (if not all) of implementations. The issue of rogue RA exists on every network, regardless of whether or not the IT group has deployed IPv6 or is aware of the IPv6 traffic on that network. Windows ICS is the most common "accidental" cause of rogue RA on a LAN. On Mon, Dec 5, 2011 at 10:35 PM, Daniel Espejel wrote: > So,still assuming the fact that attackers will use the same "traditional > ipv4" methods to alter the correct functioning over a network?...Well, > maybe. Toda's IPv6 expertise for some network andmins and security > experts is minimal. So most trainning and understanding before > implementing its a good idea. > > For example, the RA-Guard method has a significant vulnerability: It's > not designed to identify a "complex" IPv6-many extension headers formed > packet (F. Gont - 6Networks). Some other security oriented mechanisms > may fail because of the low IPv6 compliance. > > Regards. > > > -- > Daniel Espejel P?rez > T?cnico Acad?mico > D.G.T.I.C. - U.N.A.M. > GT-IPv6 CLARA / GT-IPv6 U.N.A.M. > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From jloiacon at csc.com Tue Dec 6 08:22:55 2011 From: jloiacon at csc.com (Joe Loiacono) Date: Tue, 6 Dec 2011 09:22:55 -0500 Subject: On Working Remotely In-Reply-To: References: <21788078.1535.1323022352902.JavaMail.root@benjamin.baylink.com> Message-ID: Beware the office with an Internet connection too: http://xkcd.com/862/ Don't forget to 'mouseover' the graphic. Joe William Herrin wrote on 12/05/2011 11:20:04 PM: > 3. Beware tracking hours. Try to select work which is goal and > deadline based. Your supervisor won't see you in your seat; he can > only judge your performance on what you actually accomplish. When I > teleworked, I found myself taking breaks to mow the lawn, ride a bike > on a nice day or tinker with a personal server. Tracking hours under > such circumstances is almost impossibly hard. Measuring progress > towards a goal is less so. From mir at ripe.net Tue Dec 6 08:49:33 2011 From: mir at ripe.net (Mirjam Kuehne) Date: Tue, 06 Dec 2011 15:49:33 +0100 Subject: New on RIPE Labs: The Curious Case of 128.0/16 Message-ID: <4EDE2B7D.9050603@ripe.net> Dear colleagues, Related to the discussion about 128.0/16, we did some measurements. The details can be found on RIPE Labs: https://labs.ripe.net/Members/emileaben/the-curious-case-of-128.0-16 Kind regards, Mirjam Kuehne RIPE NCC From cmadams at hiwaay.net Tue Dec 6 09:38:31 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 6 Dec 2011 09:38:31 -0600 Subject: New on RIPE Labs: The Curious Case of 128.0/16 In-Reply-To: <4EDE2B7D.9050603@ripe.net> References: <4EDE2B7D.9050603@ripe.net> Message-ID: <20111206153831.GA22818@hiwaay.net> Once upon a time, Mirjam Kuehne said: > Dear colleagues, > > Related to the discussion about 128.0/16, we did some measurements. The > details can be found on RIPE Labs: > > https://labs.ripe.net/Members/emileaben/the-curious-case-of-128.0-16 > > Kind regards, > Mirjam Kuehne > RIPE NCC Using RIPE's traceroute web interface, I can see that Sprint is filtering 128.0.0.0/16: from 128.0.0.1 traceroute to 216.180.54.1 (216.180.54.1), 30 hops max, 40 byte packets 1 gw.nik-guest.nikrtr.ripe.net (193.0.0.234) 0.803 ms 1.005 ms 1.061 ms 2 ams16-core-1.gigabiteth8-1-0.swip.net (195.69.145.139) 0.551 ms 0.466 ms 0.641 ms 3 ams-core-1.tengige0-0-0-6.tele2.net (130.244.49.198) 3.378 ms 3.467 ms 3.624 ms 4 nyc9-core-1.pos8-0-0.tele2.net (130.244.218.214) 76.618 ms 76.683 ms 76.746 ms 5 * * * from 193.0.0.232 traceroute to 216.180.54.1 (216.180.54.1), 30 hops max, 40 byte packets 1 gw.nik-guest.nikrtr.ripe.net (193.0.0.234) 0.466 ms 0.514 ms 0.608 ms 2 ams16-core-1.gigabiteth8-1-0.swip.net (195.69.145.139) 0.684 ms 0.581 ms 0.563 ms 3 ams-core-1.tengige0-0-0-6.tele2.net (130.244.49.198) 3.890 ms 3.919 ms 3.912 ms 4 nyc9-core-1.pos8-0-0.tele2.net (130.244.218.214) 76.292 ms 76.317 ms 76.304 ms 5 144.223.26.73 (144.223.26.73) 76.639 ms 76.475 ms 76.511 ms (and on to my IP) I believe that Sprint is using Cisco, not Juniper. This is either a manual filter or there is another (unidentified) issue with some Cisco configurations. I've opened a ticket with Sprint, although I don't know how far it will go, since I'm getting a MySQL syntax error trying to view the ticket in their web interface (somebody must not understand SQL injection security issues). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jbates at brightok.net Tue Dec 6 09:47:21 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 06 Dec 2011 09:47:21 -0600 Subject: New on RIPE Labs: The Curious Case of 128.0/16 In-Reply-To: <20111206153831.GA22818@hiwaay.net> References: <4EDE2B7D.9050603@ripe.net> <20111206153831.GA22818@hiwaay.net> Message-ID: <4EDE3909.6040105@brightok.net> On 12/6/2011 9:38 AM, Chris Adams wrote: > > I believe that Sprint is using Cisco, not Juniper. This is either a > manual filter or there is another (unidentified) issue with some Cisco > configurations. > People are less likely to read an RFC changing the reserved addresses. Even people who didn't filter unassigned addressing, might filter RFC reserved addressing. The fact that it's built into some routers automatically kind of makes the point. Jack From tdurack at gmail.com Tue Dec 6 10:02:28 2011 From: tdurack at gmail.com (Tim Durack) Date: Tue, 6 Dec 2011 11:02:28 -0500 Subject: Mexico City IP/Ethernet/Wave/Fiber/Colo/IXP etc... Message-ID: I'm looking for connectivity options in the Mexico City area. Initial impressions suggest Mexico has a fairly closed market. That being said: Who offers good IP/BGP connectivity in and around Mexico City?Who offers good Ethernet connectivity in and around Mexico City?Who offers wave/fiber services in and around Mexico City.Where are the colo/IXPs located? Feedback on or off-list appreciated. I'm not looking for a salesman. Thanks, -- Tim:> From joelja at bogus.com Tue Dec 6 10:04:01 2011 From: joelja at bogus.com (Joel jaeggli) Date: Tue, 06 Dec 2011 08:04:01 -0800 Subject: 128.0.0.0/16 configured as martians in some routers In-Reply-To: <82zkf6t76h.fsf@mid.bfk.de> References: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> <82zkf6t76h.fsf@mid.bfk.de> Message-ID: <4EDE3CF1.2070005@bogus.com> On 12/6/11 00:50 , Florian Weimer wrote: > * Alex Le Heux: > >> The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by >> default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline >> that this /16 should no longer be reserved as specialised address >> space. > > Would someone please clarify the impact? Will it result in a blackhole, > or will the entire announcement be suppressed? I suspect the latter, > given what we see and what Chris Adams has reported. http://www.juniper.net/techpubs/en_US/junos10.2/topics/usage-guidelines/routing-configuring-martian-addresses.html From keegan.holley at sungard.com Tue Dec 6 10:07:44 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Tue, 6 Dec 2011 11:07:44 -0500 Subject: Writable SNMP Message-ID: For a few years now I been wondering why more networks do not use writable SNMP. Most automation solutions actually script a login to the various equipment. This comes with extra code for different vendors, different prompts and any quirk that the developer is aware of and constant patches as new ones come up. Writable SNMP seems like an easier way to deal with scripted configuration changes as well as information gathering. Admittedly, you will have to deal with proprietary mibs and reformat the data once it's returned. Most people consider it insecure, but in reality it's no worse than any other management protocol. Yes I know netconf is better, but in most circles I'd have problems explaining what netconf is, why it's better and that I'm not making it up. So I'll take what I can get. From jared at puck.nether.net Tue Dec 6 10:16:02 2011 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 6 Dec 2011 11:16:02 -0500 Subject: Writable SNMP In-Reply-To: References: Message-ID: On Dec 6, 2011, at 11:07 AM, Keegan Holley wrote: > For a few years now I been wondering why more networks do not use writable > SNMP. Most automation solutions actually script a login to the various > equipment. This comes with extra code for different vendors, different > prompts and any quirk that the developer is aware of and constant patches > as new ones come up. Writable SNMP seems like an easier way to deal with > scripted configuration changes as well as information gathering. > Admittedly, you will have to deal with proprietary mibs and reformat the > data once it's returned. Most people consider it insecure, but in reality > it's no worse than any other management protocol. Yes I know netconf is > better, but in most circles I'd have problems explaining what netconf is, > why it's better and that I'm not making it up. So I'll take what I can get. Some of the problems is the bulk nature of some config changes (or transactional nature on those that support atomic operations) have been harder to automate. Anyone that has spent any quantity of time with ASN.1 generally would agree. I recall some bay networks gear you could only program with the proper OID as the cli was basically a SNMP-SET operation on the device. The errors/feedback tends to be very poor over SNMP as well as you may need to walk/revisit a large number of elements to make things happen properly. Have you had a good experience with using SNMP-Write? I have not. - Jared From morrowc.lists at gmail.com Tue Dec 6 10:28:04 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 6 Dec 2011 11:28:04 -0500 Subject: Writable SNMP In-Reply-To: References: Message-ID: On Tue, Dec 6, 2011 at 11:16 AM, Jared Mauch wrote: > > On Dec 6, 2011, at 11:07 AM, Keegan Holley wrote: > >> For a few years now I been wondering why more networks do not use writable >> SNMP. ?Most automation solutions actually script a login to the various >> equipment. ?This comes with extra code for different vendors, different >> prompts and any quirk that the developer is aware of and constant patches >> as new ones come up. ?Writable SNMP seems like an easier way to deal with >> scripted configuration changes as well as information gathering. >> Admittedly, you will have to deal with proprietary mibs and reformat the >> data once it's returned. ?Most people consider it insecure, but in reality >> it's no worse than any other management protocol. ?Yes I know netconf is >> better, but in most circles I'd have problems explaining what netconf is, >> why it's better and that I'm not making it up. ?So I'll take what I can get. > > Some of the problems is the bulk nature of some config changes (or transactional > nature on those that support atomic operations) have been harder to automate. > > Anyone that has spent any quantity of time with ASN.1 generally would agree. > > I recall some bay networks gear you could only program with the proper OID > as the cli was basically a SNMP-SET operation on the device. yea... same with cascade devices... icky things (both bay and cascade!) > The errors/feedback tends to be very poor over SNMP as well as you may need > to walk/revisit a large number of elements to make things happen properly. fun story/fact, you can send an snmp write to the broadcast address of a network of NT (at least, probably also post-nt versions of the OS) machines, and set their default-ttl to some arbitrary number. "Your network is too chatty... not anymore! now your internet is 5 hops across!" > Have you had a good experience with using SNMP-Write? ?I have not. long ago, in a network far away (not on the interwebs) we used snmp write to trigger a tftp config load. It worked nicely... I'm fairly certain I'd not do this on an internet connected network today though. Also, who tests snmp WRITE in their code? at scale? for daily operations tasks? ... (didn't the snmp incident in 2002 teach us something?) -chris From Valdis.Kletnieks at vt.edu Tue Dec 6 10:48:06 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 06 Dec 2011 11:48:06 -0500 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: Your message of "Mon, 05 Dec 2011 22:14:48 PST." <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> References: <20111205234419.GD1454@vacation.karoshi.com> <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> Message-ID: <9523.1323190086@turing-police.cc.vt.edu> On Mon, 05 Dec 2011 22:14:48 PST, "andrew.wallace" said: > Using fruitful language and acting like a child isn't going to see you taken seriously. No, he *does* want fruitful language - one that produces results. I think you meant some other word instead. As far as "acting like a child", I'm reasonably sure that if CNet was doing the same thing to the good name of your consulting company, you'd react similarly. > ----- Forwarded message from Fyodor On the other hand, just being Fyodor is sufficient to get him taken seriously. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From keegan.holley at sungard.com Tue Dec 6 10:49:05 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Tue, 6 Dec 2011 11:49:05 -0500 Subject: Writable SNMP In-Reply-To: References: Message-ID: 2011/12/6 Christopher Morrow > On Tue, Dec 6, 2011 at 11:16 AM, Jared Mauch > wrote: > > > > On Dec 6, 2011, at 11:07 AM, Keegan Holley wrote: > > > >> For a few years now I been wondering why more networks do not use > writable > >> SNMP. Most automation solutions actually script a login to the various > >> equipment. This comes with extra code for different vendors, different > >> prompts and any quirk that the developer is aware of and constant > patches > >> as new ones come up. Writable SNMP seems like an easier way to deal > with > >> scripted configuration changes as well as information gathering. > >> Admittedly, you will have to deal with proprietary mibs and reformat the > >> data once it's returned. Most people consider it insecure, but in > reality > >> it's no worse than any other management protocol. Yes I know netconf is > >> better, but in most circles I'd have problems explaining what netconf > is, > >> why it's better and that I'm not making it up. So I'll take what I can > get. > > > > Some of the problems is the bulk nature of some config changes (or > transactional > > nature on those that support atomic operations) have been harder to > automate. > > > > Anyone that has spent any quantity of time with ASN.1 generally would > agree. > > > > I recall some bay networks gear you could only program with the proper > OID > > as the cli was basically a SNMP-SET operation on the device. > > yea... same with cascade devices... icky things (both bay and cascade!) > > > The errors/feedback tends to be very poor over SNMP as well as you may > need > > to walk/revisit a large number of elements to make things happen > properly. > > fun story/fact, you can send an snmp write to the broadcast address of > a network of NT (at least, probably also post-nt versions of the OS) > machines, and set their default-ttl to some arbitrary number. "Your > network is too chatty... not anymore! now your internet is 5 hops > across!" > Let's leave the legacy boxes out of this. Remember that SNMP bug that could keel over a cisco router? I forget the details other than the guy who wrote c code at black hat to kill routers after cisco refused to patch. > > > Have you had a good experience with using SNMP-Write? I have not. > > long ago, in a network far away (not on the interwebs) we used snmp > write to trigger a tftp config load. It worked nicely... I'm fairly > certain I'd not do this on an internet connected network today though. > I can see the other comments about interactive commands and bulk read/writes, but what's the harm of doing it on internet connected boxes vs. non-internet boxes. Just about everyone uses snmp reads in the interwebs and as such filters it at their edges and hopefully on each platform. You'd secure it the same way you'd secure readable SNMP I assume. > > Also, who tests snmp WRITE in their code? at scale? for daily > operations tasks? lol, that could be a problem. > ... (didn't the snmp incident in 2002 teach us > something?) > > Please elaborate. > -chris > > From bkain1 at ford.com Tue Dec 6 11:00:45 2011 From: bkain1 at ford.com (Kain, Rebecca (.)) Date: Tue, 6 Dec 2011 17:00:45 +0000 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: <9523.1323190086@turing-police.cc.vt.edu> References: <20111205234419.GD1454@vacation.karoshi.com> <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> <9523.1323190086@turing-police.cc.vt.edu> Message-ID: <7DB845D64966DC44A1CC592780539B4B028C43@naembx40.exchange.ford.com> Not that anyone cares but personally, I'm happy fyodor posted this and I'm forwarding it to anyone that I think might use download.com. I think it's crap anyone changes anyone's code like that -----Original Message----- From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] Sent: Tuesday, December 06, 2011 11:48 AM To: andrew.wallace Cc: fyodor at insecure.org; nanog at nanog.org Subject: Re: [fyodor at insecure.org: C|Net Download.Com is now bundling Nmap with malware!] On Mon, 05 Dec 2011 22:14:48 PST, "andrew.wallace" said: > Using fruitful language and acting like a child isn't going to see you taken seriously. No, he *does* want fruitful language - one that produces results. I think you meant some other word instead. As far as "acting like a child", I'm reasonably sure that if CNet was doing the same thing to the good name of your consulting company, you'd react similarly. > ----- Forwarded message from Fyodor On the other hand, just being Fyodor is sufficient to get him taken seriously. From eric-list at truenet.com Tue Dec 6 11:00:47 2011 From: eric-list at truenet.com (Eric Tykwinski) Date: Tue, 6 Dec 2011 12:00:47 -0500 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmapwith malware!] In-Reply-To: <9523.1323190086@turing-police.cc.vt.edu> References: <20111205234419.GD1454@vacation.karoshi.com><1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> <9523.1323190086@turing-police.cc.vt.edu> Message-ID: <018b01ccb438$99cd0420$cd670c60$@truenet.com> Maybe it's just me, but I would think that simply getting them listed on stopbadware.org and other similar sites would probably have much more of an effect. The bad publicity can cause them to change tactics, but it takes some time. I've seen much quicker results from blacklisting on Google and other search engines. Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 F: 610-429-3222 -----Original Message----- From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] Sent: Tuesday, December 06, 2011 11:48 AM To: andrew.wallace Cc: fyodor at insecure.org; nanog at nanog.org Subject: Re: [fyodor at insecure.org: C|Net Download.Com is now bundling Nmapwith malware!] On Mon, 05 Dec 2011 22:14:48 PST, "andrew.wallace" said: > Using fruitful language and acting like a child isn't going to see you taken seriously. No, he *does* want fruitful language - one that produces results. I think you meant some other word instead. As far as "acting like a child", I'm reasonably sure that if CNet was doing the same thing to the good name of your consulting company, you'd react similarly. > ----- Forwarded message from Fyodor On the other hand, just being Fyodor is sufficient to get him taken seriously. From pixitha.kyle at gmail.com Tue Dec 6 11:14:17 2011 From: pixitha.kyle at gmail.com (Kyle Duren) Date: Tue, 6 Dec 2011 09:14:17 -0800 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmapwith malware!] In-Reply-To: <018b01ccb438$99cd0420$cd670c60$@truenet.com> References: <20111205234419.GD1454@vacation.karoshi.com> <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> <9523.1323190086@turing-police.cc.vt.edu> <018b01ccb438$99cd0420$cd670c60$@truenet.com> Message-ID: http://krebsonsecurity.com/2011/12/download-com-bundling-toolbars-trojans/ Its already getting some press... He could always send them a Cease and Desist letter like Wireshark had to do.... -Kyle On Tue, Dec 6, 2011 at 9:00 AM, Eric Tykwinski wrote: > Maybe it's just me, but I would think that simply getting them listed on > stopbadware.org and other similar sites would probably have much more of > an > effect. > The bad publicity can cause them to change tactics, but it takes some time. > I've seen much quicker results from blacklisting on Google and other search > engines. > > Sincerely, > > Eric Tykwinski > TrueNet, Inc. > P: 610-429-8300 > F: 610-429-3222 > > > -----Original Message----- > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > Sent: Tuesday, December 06, 2011 11:48 AM > To: andrew.wallace > Cc: fyodor at insecure.org; nanog at nanog.org > Subject: Re: [fyodor at insecure.org: C|Net Download.Com is now bundling > Nmapwith malware!] > > On Mon, 05 Dec 2011 22:14:48 PST, "andrew.wallace" said: > > Using fruitful language and acting like a child isn't going to see you > taken seriously. > > No, he *does* want fruitful language - one that produces results. I think > you meant some other word instead. > > As far as "acting like a child", I'm reasonably sure that if CNet was doing > the same thing to the good name of your consulting company, you'd react > similarly. > > > ----- Forwarded message from Fyodor > > On the other hand, just being Fyodor is sufficient to get him taken > seriously. > > > > > > > From jared at puck.nether.net Tue Dec 6 11:15:35 2011 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 6 Dec 2011 12:15:35 -0500 Subject: Writable SNMP In-Reply-To: References: Message-ID: <1AB264E2-E1BC-41BF-BF9B-89BF642FFC4E@puck.nether.net> On Dec 6, 2011, at 11:28 AM, Christopher Morrow wrote: > long ago, in a network far away (not on the interwebs) we used snmp > write to trigger a tftp config load. It worked nicely... I'm fairly > certain I'd not do this on an internet connected network today though. Many vendors have poor TFTP implementations, such that any additional latency creates very slow transfer rates. This is why things like the RCPD were done, and others use FTP/HTTP even. I am not sure if you can tell it to trigger some protocol other than TFTP in IOS. As someone who has moved large configs around in the past (1-16MB in cases) transfer speeds do matter. > Also, who tests snmp WRITE in their code? at scale? for daily > operations tasks? ... (didn't the snmp incident in 2002 teach us > something?) This is also a whole other interesting problem. Part of it is lack of exposure to it. Part of it is ease of operation. Many people still telnet over when they should use ssh. (feedback is more immediate if you are not in the VTY ACL for example). People revert to what they are comfortable with. Some it's scripts, others its typing configure or conf t and hitting ? a lot. There's no reason one can't program a device with SNMP, the main issue IMHO has always been what I dubbed "config drift". You have your desired configuration and variances that happen over time. If you don't force a 'wr mem' or similar event after you trigger a 'copy tftp run' operation, you may have troubles that are not apparent if there is a power failure or other lossage. The boot-time parser doesn't interpret SNMP, it parses text. This and other reasons have made people fail-safe to using the language most easily interpreted by the device. - Jared From william.allen.simpson at gmail.com Tue Dec 6 11:34:31 2011 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Tue, 06 Dec 2011 12:34:31 -0500 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmapwith malware!] In-Reply-To: <018b01ccb438$99cd0420$cd670c60$@truenet.com> References: <20111205234419.GD1454@vacation.karoshi.com><1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> <9523.1323190086@turing-police.cc.vt.edu> <018b01ccb438$99cd0420$cd670c60$@truenet.com> Message-ID: <4EDE5227.7030409@gmail.com> On 12/6/11 12:00 PM, Eric Tykwinski wrote: > Maybe it's just me, but I would think that simply getting them listed on > stopbadware.org and other similar sites would probably have much more of an > effect. > The bad publicity can cause them to change tactics, but it takes some time. > I've seen much quicker results from blacklisting on Google and other search > engines. > I've reported it as a malware site via Firefox. Have you? But the whole site should be scanned for other/similar malware, and blocked accordingly. Probably a harder problem, as it gives different downloads depending on browser and OS. From streiner at cluebyfour.org Tue Dec 6 11:35:35 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 6 Dec 2011 12:35:35 -0500 (EST) Subject: Writable SNMP In-Reply-To: References: Message-ID: On Tue, 6 Dec 2011, Jared Mauch wrote: > I recall some bay networks gear you could only program with the proper OID > as the cli was basically a SNMP-SET operation on the device. The mere mention of Bay Networks and Site Manager (read: Site Mangler or Site Damager) is enough to get my blood pressure up a few points, and I haven't touched that stuff since probably 1999 or 2000. The CLI was quite horrible, and their somewhat IOS-like command shell (BCC) was not much better. > Have you had a good experience with using SNMP-Write? I have not. The most I've done using SNMP SETs is backed up configurations from network devices at my old job. That part worked (and works) very well, but I never tried pushing config changes out to devices that way. jms From dorian at blackrose.org Tue Dec 6 11:39:34 2011 From: dorian at blackrose.org (Dorian Kim) Date: Tue, 6 Dec 2011 12:39:34 -0500 Subject: Writable SNMP In-Reply-To: <1AB264E2-E1BC-41BF-BF9B-89BF642FFC4E@puck.nether.net> References: <1AB264E2-E1BC-41BF-BF9B-89BF642FFC4E@puck.nether.net> Message-ID: <20111206173934.GK21378@blackrose.org> On Tue, Dec 06, 2011 at 12:15:35PM -0500, Mauch, Jared wrote: > > Also, who tests snmp WRITE in their code? at scale? for daily > > operations tasks? ... (didn't the snmp incident in 2002 teach us > > something?) > > There's no reason one can't program a device with SNMP, the main issue IMHO There is one good reason. Every vendor seem to assign a junior intern to maintanining SNMP code, so you are interfacing with your router via a very suspect interface. -dorian From surfer at mauigateway.com Tue Dec 6 11:40:03 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 6 Dec 2011 09:40:03 -0800 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] Message-ID: <20111206094003.2DB8579@resin04.mta.everyone.net> -----Original Message----- From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > ----- Forwarded message from Fyodor On the other hand, just being Fyodor is sufficient to get him taken seriously. ---------------------------- ------- bkain1 at ford.com wrote: ------- From: "Kain, Rebecca (.)" Not that anyone cares but personally, I'm happy fyodor posted this and I'm forwarding it to anyone that I think might use download.com. I think it's crap anyone changes anyone's code like that --------------------------------------- I used to use download.com a lot. I trusted them. I told friends they were trustworthy. What Valdis said. That's all it took for me to stop using them and to tell everyone I know to stop. Hope someone at download.com is listening. scott From smb at cs.columbia.edu Tue Dec 6 12:09:57 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Tue, 6 Dec 2011 13:09:57 -0500 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmapwith malware!] In-Reply-To: <4EDE5227.7030409@gmail.com> References: <20111205234419.GD1454@vacation.karoshi.com><1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> <9523.1323190086@turing-police.cc.vt.edu> <018b01ccb438$99cd0420$cd670c60$@truenet.com> <4EDE5227.7030409@gmail.com> Message-ID: <5FF36843-3075-4EFB-BA3F-621AA1B3E03F@cs.columbia.edu> On Dec 6, 2011, at 12:34 31PM, William Allen Simpson wrote: > On 12/6/11 12:00 PM, Eric Tykwinski wrote: >> Maybe it's just me, but I would think that simply getting them listed on >> stopbadware.org and other similar sites would probably have much more of an >> effect. >> The bad publicity can cause them to change tactics, but it takes some time. >> I've seen much quicker results from blacklisting on Google and other search >> engines. >> > I've reported it as a malware site via Firefox. Have you? > > But the whole site should be scanned for other/similar malware, and blocked > accordingly. Probably a harder problem, as it gives different downloads > depending on browser and OS. > > Per the Krebs on Security link that Kyle just posted (and beat me to it), the installer is already flagged as malware by a number of different scanners. --Steve Bellovin, https://www.cs.columbia.edu/~smb From andrew.wallace at rocketmail.com Tue Dec 6 12:30:20 2011 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Tue, 6 Dec 2011 10:30:20 -0800 (PST) Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: <9523.1323190086@turing-police.cc.vt.edu> References: <20111205234419.GD1454@vacation.karoshi.com> <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> <9523.1323190086@turing-police.cc.vt.edu> Message-ID: <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com> On Tue, Dec 6, 2011 at 4:48 PM,? wrote: > On the other hand, just being Fyodor is sufficient to get him taken seriously. It could be argued that Nmap is malware, and such software has already been called to be made illegal. If I was Cnet, I would stop distributing his software altogether. Link: http://nmap.org/book/legal-issues.html Andrew From ikiris at gmail.com Tue Dec 6 12:42:48 2011 From: ikiris at gmail.com (Blake Dunlap) Date: Tue, 6 Dec 2011 12:42:48 -0600 Subject: Writable SNMP In-Reply-To: References: Message-ID: Yes, Site Mangler. Do not stir that nest. Thar be dragons. -Blake On Tue, Dec 6, 2011 at 11:35, Justin M. Streiner wrote: > On Tue, 6 Dec 2011, Jared Mauch wrote: > > I recall some bay networks gear you could only program with the proper OID >> as the cli was basically a SNMP-SET operation on the device. >> > > The mere mention of Bay Networks and Site Manager (read: Site Mangler or > Site Damager) is enough to get my blood pressure up a few points, and I > haven't touched that stuff since probably 1999 or 2000. The CLI was quite > horrible, and their somewhat IOS-like command shell (BCC) was not much > better. > > > Have you had a good experience with using SNMP-Write? I have not. >> > > The most I've done using SNMP SETs is backed up configurations from > network devices at my old job. That part worked (and works) very well, but > I never tried pushing config changes out to devices that way. > > jms > > From nathan at atlasnetworks.us Tue Dec 6 12:54:34 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Tue, 6 Dec 2011 18:54:34 +0000 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com> References: <20111205234419.GD1454@vacation.karoshi.com> <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> <9523.1323190086@turing-police.cc.vt.edu> <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B619CD6@ex-mb-1.corp.atlasnetworks.us> > It could be argued that Nmap is malware, and such software has already > been called to be made illegal. > > If I was Cnet, I would stop distributing his software altogether. > > Link: http://nmap.org/book/legal-issues.html It could. But making such an argument calls the arguer's grasp of reality into question. Nmap is a tool, like any other. It has no more ethical value than a nail gun or a hammer. In the hands of an engineer, it is a valuable addition to a toolkit. In the hands of an attacker, it can become a weapon. If it could be argued that Nmap is malware, then it could be argued that hammers are weapons; therefore, we should call on Home Depot to stop carrying these deadly instruments with all due alacrity - or at least have governments step in and create licensing programs for hand tools. Nathan Eisenberg From owen at delong.com Tue Dec 6 12:50:40 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 6 Dec 2011 10:50:40 -0800 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com> References: <20111205234419.GD1454@vacation.karoshi.com> <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> <9523.1323190086@turing-police.cc.vt.edu> <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com> Message-ID: <58A8514A-94C8-48A2-A0EC-2A0AE4F0D4C7@delong.com> On Dec 6, 2011, at 10:30 AM, andrew.wallace wrote: > On Tue, Dec 6, 2011 at 4:48 PM, wrote: >> On the other hand, just being Fyodor is sufficient to get him taken seriously. > > It could be argued that Nmap is malware, and such software has already been called to be made illegal. > > If I was Cnet, I would stop distributing his software altogether. > > Link: http://nmap.org/book/legal-issues.html > > Andrew > That's a stretch. Malware generally, IMHO, means software which does something other than what it claims to do. I don't believe that nmap does anything other than what it claims. I understand you may not like the idea of having such a tool available to users of your network. Personally, I'd rather that the users had access to such a tool than live without it myself. Kind of a double-edged sword, I know, but, nmap is a tool. In and of itself, neither bad nor good. Malice is in the intent of the user. This distinguishes it from malware in that with malware, malice is in the intent of the author and not the user. Malware, once installed, does what its author wants it to do regardless of the intent of the user. Sure, you can do things with nmap that are at best antisocial and at worst potentially illegal. I can do things with a Bowie Knife that are as well. However, used properly in the right context, both can be very useful tools. I don't think we should outlaw either one. Then again, I'm rather liberal in that regard. I believe that we should not ban something if it has both legitimate and nefarious uses, but, rather, should only ban those things which pose a public hazard and have no legitimate use. I suspect that he would rather Cnet stop distributing his software altogether than do what they are doing. I appreciate the warning and have stopped using CNET as a result. Owen From rps at maine.edu Tue Dec 6 12:56:36 2011 From: rps at maine.edu (Ray Soucy) Date: Tue, 6 Dec 2011 13:56:36 -0500 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com> References: <20111205234419.GD1454@vacation.karoshi.com> <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> <9523.1323190086@turing-police.cc.vt.edu> <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com> Message-ID: I'm pretty sure nmap is the exact opposite of Malware. It's an essential information security tool. Fyodor, Reach out to the Free Software Foundation and EFF. They may not be able to help directly, but I'm sure that they could put you in touch with some pro bono legal experts that could give you the right advice on how to act. As mentioned, both Lessig, and Eben Moglen, would be good starting points. On Tue, Dec 6, 2011 at 1:30 PM, andrew.wallace wrote: > On Tue, Dec 6, 2011 at 4:48 PM,? wrote: >> On the other hand, just being Fyodor is sufficient to get him taken seriously. > > It could be argued that Nmap is malware, and such software has already been called to be made illegal. > > If I was Cnet, I would stop distributing his software altogether. > > Link: http://nmap.org/book/legal-issues.html > > Andrew > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From bkain1 at ford.com Tue Dec 6 12:57:34 2011 From: bkain1 at ford.com (Kain, Rebecca (.)) Date: Tue, 6 Dec 2011 18:57:34 +0000 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B619CD6@ex-mb-1.corp.atlasnetworks.us> References: <20111205234419.GD1454@vacation.karoshi.com> <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> <9523.1323190086@turing-police.cc.vt.edu> <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com> <8C26A4FDAE599041A13EB499117D3C286B619CD6@ex-mb-1.corp.atlasnetworks.us> Message-ID: <7DB845D64966DC44A1CC592780539B4B02910C@naembx40.exchange.ford.com> Having seen the previous owner of my house's cabinet building skills, and living with them, I'm all for licensing! -----Original Message----- From: Nathan Eisenberg [mailto:nathan at atlasnetworks.us] Sent: Tuesday, December 06, 2011 1:55 PM To: nanog at nanog.org Subject: RE: [fyodor at insecure.org: C|Net Download.Com is now bundling Nmap with malware!] > It could be argued that Nmap is malware, and such software has already > been called to be made illegal. > > If I was Cnet, I would stop distributing his software altogether. > > Link: http://nmap.org/book/legal-issues.html It could. But making such an argument calls the arguer's grasp of reality into question. Nmap is a tool, like any other. It has no more ethical value than a nail gun or a hammer. In the hands of an engineer, it is a valuable addition to a toolkit. In the hands of an attacker, it can become a weapon. If it could be argued that Nmap is malware, then it could be argued that hammers are weapons; therefore, we should call on Home Depot to stop carrying these deadly instruments with all due alacrity - or at least have governments step in and create licensing programs for hand tools. Nathan Eisenberg From henry at AegisInfoSys.com Tue Dec 6 13:05:48 2011 From: henry at AegisInfoSys.com (Henry Yen) Date: Tue, 6 Dec 2011 14:05:48 -0500 Subject: New on RIPE Labs: The Curious Case of 128.0/16 In-Reply-To: <20111206153831.GA22818@hiwaay.net> References: <4EDE2B7D.9050603@ripe.net> <20111206153831.GA22818@hiwaay.net> Message-ID: <20111206190548.GJ29174@nntp.AegisInfoSys.com> On Tue, Dec 06, 2011 at 09:38:31AM -0600, Chris Adams wrote: > Using RIPE's traceroute web interface, I can see that Sprint is > filtering 128.0.0.0/16: > I believe that Sprint is using Cisco, not Juniper. This is either a > manual filter or there is another (unidentified) issue with some Cisco > configurations. I've been getting spam from NTT for several days in that range; a Sprint-based traceroute: 2 sl-gw28-nyc-15-1-3-28-ts0.sprintlink.net (160.81.237.61) 10.880 ms 10.604 ms 9.359 ms 3 sl-crs1-nyc-0-6-3-0.sprintlink.net (144.232.3.188) 10.345 ms 10.559 ms 11.802 ms 4 144.232.4.87 (144.232.4.87) 9.178 ms 7.928 ms 144.232.4.91 (144.232.4.91) 9.304 ms 5 xe-0-2-0-2.r06.nycmny01.us.bb.gin.ntt.net (129.250.8.73) 8.841 ms 9.977 ms 7.947 ms 6 ae-2.r22.nycmny01.us.bb.gin.ntt.net (129.250.4.174) 11.497 ms 10.610 ms 11.682 ms 7 ae-4.r21.sttlwa01.us.bb.gin.ntt.net (129.250.2.51) 85.541 ms 86.744 ms 84.994 ms 8 ae-0.r20.sttlwa01.us.bb.gin.ntt.net (129.250.2.53) 88.498 ms 87.313 ms 88.387 ms 9 ae-3.r20.snjsca04.us.bb.gin.ntt.net (129.250.3.53) 95.862 ms 96.692 ms 96.558 ms 10 ae-2.r20.mlpsca01.us.bb.gin.ntt.net (129.250.5.6) 97.193 ms 96.742 ms 97.046 ms 11 * * * 12 ae-0.r01.mlpsca01.us.wh.verio.net (129.250.26.170) 98.053 ms 97.402 ms 95.332 ms 13 ge-26.a0410i.mlpsca01.us.wh.verio.net (204.202.1.226) 99.151 ms 99.001 ms 96.926 ms 14 ca1-lam00092.vwh.net (192.217.122.217) 95.274 ms 97.104 ms 96.247 ms 15 arnmarkt.org (128.121.86.33) 90.872 ms 91.109 ms 91.995 ms -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York From harbor235 at gmail.com Tue Dec 6 13:11:49 2011 From: harbor235 at gmail.com (harbor235) Date: Tue, 6 Dec 2011 14:11:49 -0500 Subject: vrf address familiy upgrade Message-ID: I was wondering if anyone has had experience with the vrf cli upgrade command that upgrades an existing V4 only VRf to a multi-protocol vrf? command: (config)# vrf upgrade-cli multi-af-mode ........ My issue is that it fails to upgrade the my, one of the pre-requisites is that the vrf must exist, it does?????? thanx as always, Mike From jsw at inconcepts.biz Tue Dec 6 13:18:52 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Tue, 6 Dec 2011 14:18:52 -0500 Subject: Writable SNMP In-Reply-To: References: Message-ID: On Tue, Dec 6, 2011 at 11:07 AM, Keegan Holley wrote: > For a few years now I been wondering why more networks do not use writable > SNMP. ?Most automation solutions actually script a login to the various I've spent enough time writing code to deal with SNMP (our own stack, not using Net-SNMP or friends) to have a more in-depth understanding of SNMP's pitfalls than most people. It is TERRIBLE and should be totally gutted and replaced with something more sane, less likely to have bugs, etc. There is a good reason why many major bugs have popped up over the years allowing devices to be crashed with crafted SNMP packets -- it's honestly not that easy to get right, especially if you really implement every possible encoding so some random customer with a brain-damaged SNMP client stack won't come crying to you that his client won't work. Juniper does not support writing via SNMP. I am glad. Hopefully that is the first step toward not supporting SNMP at all. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From jra at baylink.com Tue Dec 6 13:31:58 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 6 Dec 2011 14:31:58 -0500 (EST) Subject: get IP address on login In-Reply-To: Message-ID: <8659180.1785.1323199917885.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Bob Rasmussen" > > >On my OSR5 test system, I see SSH_CLIENT and SSH_CONNECTION set in > > >the environment upon login. Does that help? > These are set by the SSH daemon, only if you're running an SSH > connection. If you're not, you should be :-) Well, on a disconnected internal system, telnet's probably ok; there's a way to get it in telnet as well, but you have to do some guessing. 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 http://photo.imageinc.us +1 727 647 1274 From jhoppes at cfunet.net Tue Dec 6 13:52:20 2011 From: jhoppes at cfunet.net (Josh V. Hoppes) Date: Tue, 6 Dec 2011 19:52:20 +0000 Subject: GPON Vendors Message-ID: Hello NANOG, Due to unforeseen circumstances we need to consider alternative vendors for our GPON system, moving away from Motorola. We wanted to throw out a line and find out what other networks have deployed and what experiences they have had positive or negative with them. Thanks in advance for any replies. Josh Hoppes Network Engineer Cedar Falls Utilities From jethro.binks at strath.ac.uk Tue Dec 6 13:56:38 2011 From: jethro.binks at strath.ac.uk (Jethro R Binks) Date: Tue, 6 Dec 2011 19:56:38 +0000 (GMT) Subject: Writable SNMP In-Reply-To: References: Message-ID: On Tue, 6 Dec 2011, Jeff Wheeler wrote: > On Tue, Dec 6, 2011 at 11:07 AM, Keegan Holley > wrote: > > For a few years now I been wondering why more networks do not use writable > > SNMP. ?Most automation solutions actually script a login to the various > ... > Juniper does not support writing via SNMP. I am glad. Hopefully that > is the first step toward not supporting SNMP at all. So what are the alternatives these days then for automation or batch operations? clogin etc from shrubbery's rancid? Net::Appliance::Session ... ? . . . . . . . . . . . . . . . . . . . . . . . . . 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 morrowc.lists at gmail.com Tue Dec 6 13:57:54 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 6 Dec 2011 14:57:54 -0500 Subject: Writable SNMP In-Reply-To: <1AB264E2-E1BC-41BF-BF9B-89BF642FFC4E@puck.nether.net> References: <1AB264E2-E1BC-41BF-BF9B-89BF642FFC4E@puck.nether.net> Message-ID: On Tue, Dec 6, 2011 at 12:15 PM, Jared Mauch wrote: > > On Dec 6, 2011, at 11:28 AM, Christopher Morrow wrote: > >> long ago, in a network far away (not on the interwebs) we used snmp >> write to trigger a tftp config load. It worked nicely... I'm fairly >> certain I'd not do this on an internet connected network today though. > > Many vendors have poor TFTP implementations, such that any additional > latency creates very slow transfer rates. ?This is why things like the > RCPD were done, and others use FTP/HTTP even. ?I am not sure if you can > tell it to trigger some protocol other than TFTP in IOS. agreed, I did say 'long time ago' :) (like before 2000 long time ago) I get the impression we could have said copy http:// instead of tftp though. (if it were supported at the time, http I mean) > As someone who has moved large configs around in the past (1-16MB in cases) > transfer speeds do matter. agreed >> Also, who tests snmp WRITE in their code? at scale? for daily >> operations tasks? ... (didn't the snmp incident in 2002 teach us >> something?) > > This is also a whole other interesting problem. ?Part of it is lack of > exposure to it. ?Part of it is ease of operation. ?Many people still > telnet over when they should use ssh. ?(feedback is more immediate if > you are not in the VTY ACL for example). ?People revert to what they > are comfortable with. ?Some it's scripts, others its typing configure > or conf t and hitting ? a lot. > > There's no reason one can't program a device with SNMP, the main issue IMHO > has always been what I dubbed "config drift". ?You have your desired > configuration and variances that happen over time. ?If you don't force > a 'wr mem' or similar event after you trigger a 'copy tftp run' operation, > you may have troubles that are not apparent if there is a power failure > or other lossage. ?The boot-time parser doesn't interpret SNMP, it parses > text. ?This and other reasons have made people fail-safe to using the language > most easily interpreted by the device. Yup, I think the OP was maybe getting at: "Why can't I snmp configure my cisco/juniper/alteon device?" I took that to mean (probably naively?) that they also would validate configs and update drift out of the configuration. You CAN force a 'wr mem' via snmp as well, of course (in cisco world). From morrowc.lists at gmail.com Tue Dec 6 14:00:27 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 6 Dec 2011 15:00:27 -0500 Subject: Writable SNMP In-Reply-To: References: Message-ID: On Tue, Dec 6, 2011 at 11:49 AM, Keegan Holley wrote: > 2011/12/6 Christopher Morrow >> >> On Tue, Dec 6, 2011 at 11:16 AM, Jared Mauch >> wrote: >> > >> > On Dec 6, 2011, at 11:07 AM, Keegan Holley wrote: >> > >> >> For a few years now I been wondering why more networks do not use >> >> writable >> >> SNMP. ?Most automation solutions actually script a login to the various >> >> equipment. ?This comes with extra code for different vendors, different >> >> prompts and any quirk that the developer is aware of and constant >> >> patches >> >> as new ones come up. ?Writable SNMP seems like an easier way to deal >> >> with >> >> scripted configuration changes as well as information gathering. >> >> Admittedly, you will have to deal with proprietary mibs and reformat >> >> the >> >> data once it's returned. ?Most people consider it insecure, but in >> >> reality >> >> it's no worse than any other management protocol. ?Yes I know netconf >> >> is >> >> better, but in most circles I'd have problems explaining what netconf >> >> is, >> >> why it's better and that I'm not making it up. ?So I'll take what I can >> >> get. >> > >> > Some of the problems is the bulk nature of some config changes (or >> > transactional >> > nature on those that support atomic operations) have been harder to >> > automate. >> > >> > Anyone that has spent any quantity of time with ASN.1 generally would >> > agree. >> > >> > I recall some bay networks gear you could only program with the proper >> > OID >> > as the cli was basically a SNMP-SET operation on the device. >> >> yea... same with cascade devices... icky things (both bay and cascade!) >> >> > The errors/feedback tends to be very poor over SNMP as well as you may >> > need >> > to walk/revisit a large number of elements to make things happen >> > properly. >> >> fun story/fact, you can send an snmp write to the broadcast address of >> a network of NT (at least, probably also post-nt versions of the OS) >> machines, and set their default-ttl to some arbitrary number. "Your >> network is too chatty... not anymore! now your internet is 5 hops >> across!" > > > Let's leave the legacy boxes out of this.? Remember that SNMP bug that could > keel over a cisco router?? I forget the details other than the guy who wrote > c code at black hat to kill routers after cisco refused to patch. >> >> >> > Have you had a good experience with using SNMP-Write? ?I have not. >> >> long ago, in a network far away (not on the interwebs) we used snmp >> write to trigger a tftp config load. It worked nicely... I'm fairly >> certain I'd not do this on an internet connected network today though. > > > I can see the other comments about interactive commands and bulk > read/writes, but what's the harm of doing it on internet connected boxes vs. > non-internet boxes.? Just about everyone uses snmp reads in the interwebs I think the general feeling is that snmp is udp so it's spoofable and your perimeter acls will never be 100% (or rather, are you willing to risk them not being 100%?) > and as such filters it at their edges and hopefully on each platform.? You'd > secure it the same way you'd secure readable SNMP I assume. read is 'painful', write can be downright deadly (to your SLAs). >> >> Also, who tests snmp WRITE in their code? at scale? for daily >> operations tasks? > > > lol, that could be a problem. yea, I bet the number of people that test, at scale/operations-pace, snmp WRITE is countable on a single hand. >> >> ... (didn't the snmp incident in 2002 teach us >> something?) >> > Please elaborate. oh, 2001... memory lag :( From morrowc.lists at gmail.com Tue Dec 6 14:01:26 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 6 Dec 2011 15:01:26 -0500 Subject: Writable SNMP In-Reply-To: <20111206173934.GK21378@blackrose.org> References: <1AB264E2-E1BC-41BF-BF9B-89BF642FFC4E@puck.nether.net> <20111206173934.GK21378@blackrose.org> Message-ID: On Tue, Dec 6, 2011 at 12:39 PM, Dorian Kim wrote: > On Tue, Dec 06, 2011 at 12:15:35PM -0500, Mauch, Jared wrote: >> > Also, who tests snmp WRITE in their code? at scale? for daily >> > operations tasks? ... (didn't the snmp incident in 2002 teach us >> > something?) >> >> There's no reason one can't program a device with SNMP, the main issue IMHO > > There is one good reason. Every vendor seem to assign a junior intern to > maintanining SNMP code, so you are interfacing with your router via a very > suspect interface. this is exactly my 'testing' commment... and you thought bgp bugs were painful :) From morrowc.lists at gmail.com Tue Dec 6 14:04:19 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 6 Dec 2011 15:04:19 -0500 Subject: Writable SNMP In-Reply-To: References: Message-ID: On Tue, Dec 6, 2011 at 2:56 PM, Jethro R Binks wrote: > So what are the alternatives these days then for automation or batch > operations? > > clogin etc from shrubbery's rancid? > > Net::Appliance::Session netconf! From bicknell at ufp.org Tue Dec 6 14:13:38 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 6 Dec 2011 12:13:38 -0800 Subject: Writable SNMP In-Reply-To: References: Message-ID: <20111206201338.GA47906@ussenterprise.ufp.org> In a message written on Tue, Dec 06, 2011 at 11:16:02AM -0500, Jared Mauch wrote: > Anyone that has spent any quantity of time with ASN.1 generally would agree. SNMP has two fatal flaws for large scale write based configuration. ASN.1 was basically obsolete before it was written. It was designed to be a compact data transfer format in the days of 56k lines, and is nothing but annoying in practice. Hard to write, hard to debug, hard to understand to save a little bandwidth which no longer matters. (Note, there is apparently an XML version of ASN.1 which may or may not make things better, but I have never seen a single bit of gear anywhere that implemented it.) But then on top of ASN.1, the transaction model is all wrong. No way to group writes together (e.g. commit a series of changes at once). One RTT incurred for each write/read-back (for verification, since it's UDP). If you try and configure a device with SNMP over a 500ms link it might take longer than the lifespan of the gear! :) Jared also makes a good point about the device not reading SNMP on boot, it reads a text file, and being able to alter that directly makes more sense. Lastly, let's not forget that at most vendors SNMP seems to be a low priority item. How many years was it after we had IPv6 BGP before there was an IPv6 BGP MIB actually implemented? I actually would submit SNMP was never the right tool for the job, just the tool we had. Even today where it's most popular use is to poll interfaces for statistics it would be easier on the device, programmer, and operator to make one tcp connection, send a list of things to poll, and get back a blob of text. I hesitate to say XML + Restful, becuse I think it need not be that specific solution, but that is a solution that meets the criteria. The only thing SNMP has going for it at this point in time is inertia. -- 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 thegameiam at yahoo.com Tue Dec 6 14:28:36 2011 From: thegameiam at yahoo.com (David Barak) Date: Tue, 6 Dec 2011 12:28:36 -0800 (PST) Subject: Writable SNMP In-Reply-To: References: Message-ID: <1323203316.14305.YahooMailNeo@web31806.mail.mud.yahoo.com> From: Jeff Wheeler >Juniper does not support writing via SNMP.? I am glad.? Hopefully that >is the first step toward not supporting SNMP at all. If I recall correctly, wasn't the old FORE CLI implemented via localhost SNMP? ?I liked using them, but that's a special case... David Barak Need Geek Rock? Try The Franchise:? http://www.listentothefranchise.com From jared at puck.nether.net Tue Dec 6 14:38:13 2011 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 6 Dec 2011 14:38:13 -0600 Subject: Writable SNMP In-Reply-To: <20111206201338.GA47906@ussenterprise.ufp.org> References: <20111206201338.GA47906@ussenterprise.ufp.org> Message-ID: <0A93187E-1D91-4A16-AE59-AA156A56C91C@puck.nether.net> What SNMP does have for it is it is lightweight (to some extent) vs XML that can get quite bulky, and certainly is the case when trying to do many interfaces at once. I have seen better precision with snmp vs cli interaction/tcp based interaction. snmpbulkwalk has been my cruel mistress for several years... But does provide the detail/accuracy most days. Also keep in mind most hardware only pulls or pushes counters every 5s anyways... Jared Mauch On Dec 6, 2011, at 2:13 PM, Leo Bicknell wrote: > > I actually would submit SNMP was never the right tool for the job, > just the tool we had. Even today where it's most popular use is > to poll interfaces for statistics it would be easier on the device, > programmer, and operator to make one tcp connection, send a list > of things to poll, and get back a blob of text. I hesitate to say > XML + Restful, becuse I think it need not be that specific solution, > but that is a solution that meets the criteria. The only thing SNMP has > going for it at this point in time is inertia. From bstengel at kinber.org Tue Dec 6 15:01:21 2011 From: bstengel at kinber.org (Brian Stengel) Date: Tue, 6 Dec 2011 16:01:21 -0500 Subject: CMDB on the cheap... Message-ID: Any recommendations for CMDB software on the cheap? Building out nodes at a few commercial co-los and a number of non-commercial (member) spaces. thanks, brian -- Brian Stengel KINBER Director of Operations bstengel at kinber.org M: 412.398.2333 GV: 412.254.3481 Skype: brian_stengel KINBER - Keystone Initiative for Network Based Education and Research - www.kinber.org PennREN - Pennsylvania's Research and Education Network From surfer at mauigateway.com Tue Dec 6 15:05:39 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 6 Dec 2011 13:05:39 -0800 Subject: Flapping POS Interface on Frame-relay between a Juniper and Cisco Message-ID: <20111206130539.2DBEED9@resin04.mta.everyone.net> Did Jeff's suggestion work? : interface POS0/0/0 : frame-relay intf-type dce If so, please let the list know, so when someone comes across this thread while searching for the fix they can figure it out without having to email the list. If it didn't help contact me off-line and I will be happy to troubleshoot it with you. scott ________________________________________ From: Righa Shake [righa.shake at gmail.com] Sent: Saturday, November 19, 2011 11:11 AM To: afnog at afnog.org Subject: Flapping POS Interface on Frame-relay between a Juniper and Cisco Hi, Am having a problem that is buffling. I recently changed a POS link encapsulation from PPP to Frame-relay. Since that time the POS interface keeps resetting from time to time. On my BGP session am receiving cease notifications from my upstream provider. The setup is such that we have a cisco on one end and a Juniper on the other. interface POS0/0/0 mtu 4474 no ip address no ip unreachables encapsulation frame-relay logging event link-status crc 32 pos scramble-atm frame-relay lmi-type ansi end ROUTERshow run int pos0/0/0.101 Building configuration... ! interface POS0/0/0.101 point-to-point ip address X.X.X.X 255.255.255.252 frame-relay interface-dlci 101 end ROUTER#show int pos0/0/0 POS0/0/0 is up, line protocol is up Hardware is SPA-2XOC12-POS MTU 4474 bytes, BW 622000 Kbit/sec, DLY 100 usec, reliability 255/255, txload 6/255, rxload 38/255 Encapsulation FRAME-RELAY, crc 32, loopback not set Keepalive set (10 sec) Scramble enabled LMI enq sent 81981, LMI stat recvd 77480, LMI upd recvd 0, DTE LMI up LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 LMI DLCI 0 LMI type is ANSI Annex D frame relay DTE segmentation inactive FR SVC disabled, LAPF state down Broadcast queue 0/256, broadcasts sent/dropped 26/0, interface broadcasts 0 Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters 1w2d Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 94336000 bits/sec, 13151 packets/sec 5 minute output rate 16470000 bits/sec, 7049 packets/sec 12211574207 packets input, 10967607038364 bytes, 0 no buffer Received 0 broadcasts (0 IP multicasts) 6970870 runts, 2179 giants, 0 throttles 0 parity 892493293 input errors, 882184781 CRC, 0 frame, 0 overrun, 0 ignored, 3335463 abort 6379191154 packets output, 1614018181446 bytes, 0 underruns 0 output errors, 0 applique, 4 interface resets 0 unknown protocol drops 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions Any assistance on this will be greatly appreciated. --- jsaxe at briworks.com wrote: From: Jeff Saxe I believe this is the explanation for your flapping: a PPP link is intended to go between two routers over, for instance, a private leased line, so both of the devices are peers, neither one particularly special. Frame-relay, by contrast, was originally designed so that your router was an "end user" device and its directly-connected partner device was not your other router, which you control, but the frame carrier's frame-relay switch. Your router was a DTE device, and their switch, which was in a more "important" position in control of the frame-relay NBMA cloud, was the DCE device. Your router then slaved to the frame switch via LMI signaling, so that the upstream switch instructed you which DLCIs existed and were up at the moment. So if you connect up two routers with frame-relay encap and each thinks it is the DTE, and neither one is taking the role of the frame switch, then when you bring them up, they will initially optimistically think their DLCIs are up and working, and the routing protocol and traffic will come up... but both of them will be waiting for the frame switch to send them LMI indicating that their idea of the DLCI up/down status is correct. When a couple minutes go by and they don't hear the responses to their LMI enquiries, they will bring all the DLCI's down. I thought they would then stay down forever, i.e., not flap, but maybe you are shutting / no shutting the POS circuit to try again. Anyway, I believe the very simple fix is interface POS0/0/0 frame-relay intf-type dce So this will turn your Cisco side of the circuit into "DCE" mode, and if the Juniper side stays in "DTE" mode (the default, so probably not listed in the config), then the LMI should start behaving between the two. And yes, as Jay Hennigan suggested, you might need to use "encap frame-relay ietf" to be compatible with non-Cisco gear, or you might need to adjust the frame-relay lmi-type -- one type sends the LMI on DLCI number 0, one of them on DLCI 1023, whatever. I think you'll need to adjust the two ends until you see LMI enquiries both sent and received; right now the "show interface" from the Cisco side shows it has not received any LMI enq yet. Good luck, and I hope it's that simple. :-) From swm at emanon.com Tue Dec 6 15:14:32 2011 From: swm at emanon.com (Scott Morris) Date: Tue, 06 Dec 2011 16:14:32 -0500 Subject: Flapping POS Interface on Frame-relay between a Juniper and Cisco In-Reply-To: <20111206130539.2DBEED9@resin04.mta.everyone.net> References: <20111206130539.2DBEED9@resin04.mta.everyone.net> Message-ID: <4EDE85B8.9080801@emanon.com> From dholmes at mwdh2o.com Tue Dec 6 15:16:00 2011 From: dholmes at mwdh2o.com (Holmes,David A) Date: Tue, 6 Dec 2011 13:16:00 -0800 Subject: Internet Edge and Defense in Depth Message-ID: <922ACC42D498884AA02B3565688AF995340255F77F@USEXMBS01.mwd.h2o> Some firewall vendors are proposing to collapse all Internet edge functions into a single device (border router, firewall, IPS, caching engine, proxy, etc.). A general Internet edge design principle has been the "defense in depth" concept. Is anyone collapsing all Internet edge functions into one device? Regards, David ________________________________ This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system. From george.herbert at gmail.com Tue Dec 6 15:16:32 2011 From: george.herbert at gmail.com (George Herbert) Date: Tue, 6 Dec 2011 13:16:32 -0800 Subject: CMDB on the cheap... In-Reply-To: References: Message-ID: Everyone I know has either paid through the nose or written one from scratch. No good open source projects that worked out. Most people couldn't build well from scratch. I have been a couple of places that did, it was man-year of senior grade guy effort range. On Tue, Dec 6, 2011 at 1:01 PM, Brian Stengel wrote: > Any recommendations for CMDB software on the cheap? ?Building out nodes at > a few commercial co-los and a number of non-commercial (member) spaces. > > thanks, > brian > > -- > Brian Stengel > KINBER Director of Operations > bstengel at kinber.org > M: 412.398.2333 > GV: 412.254.3481 > Skype: brian_stengel > > KINBER - Keystone Initiative for Network Based Education and Research - > www.kinber.org > PennREN - Pennsylvania's Research and Education Network -- -george william herbert george.herbert at gmail.com From swm at emanon.com Tue Dec 6 15:17:44 2011 From: swm at emanon.com (Scott Morris) Date: Tue, 06 Dec 2011 16:17:44 -0500 Subject: Flapping POS Interface on Frame-relay between a Juniper and Cisco In-Reply-To: <20111206130539.2DBEED9@resin04.mta.everyone.net> References: <20111206130539.2DBEED9@resin04.mta.everyone.net> Message-ID: <4EDE8678.4070507@emanon.com> The mismatch problem of DCE/DTE should definitely indicate that your PVCs aren't up. But that shouldn't result in the high quantity of CRC errors in the interface counters. That should just result in your LMI enquiry count increasing with LMI response sitting at zero. I have to say I've never tried running frame-relay on a SONET interface. And if you're only using a single PVC there, I'd certainly love to know WHY you're doing that! :) But setting one side to DCE so that it'll respond to LMI will certainly make the frame-relay (L2) portion of things operate properly. But if you have something else occurring causing the CRCs along the way, then that's not really going to help at all! Did anything else coincide with you changing the encapsulation? Scott On 12/6/11 4:05 PM, Scott Weeks wrote: > Did Jeff's suggestion work? > > : interface POS0/0/0 > : frame-relay intf-type dce > > If so, please let the list know, so when someone comes > across this thread while searching for the fix they can > figure it out without having to email the list. If it > didn't help contact me off-line and I will be happy to > troubleshoot it with you. > > scott > > > > > > ________________________________________ > From: Righa Shake [righa.shake at gmail.com] > Sent: Saturday, November 19, 2011 11:11 AM > To: afnog at afnog.org > Subject: Flapping POS Interface on Frame-relay between a Juniper and Cisco > > Hi, > > Am having a problem that is buffling. > > I recently changed a POS link encapsulation from PPP to Frame-relay. > Since that time the POS interface keeps resetting from time to time. > > On my BGP session am receiving cease notifications from my upstream > provider. > > The setup is such that we have a cisco on one end and a Juniper on the > other. > > interface POS0/0/0 > mtu 4474 > no ip address > no ip unreachables > encapsulation frame-relay > logging event link-status > crc 32 > pos scramble-atm > frame-relay lmi-type ansi > end > > ROUTERshow run int pos0/0/0.101 > Building configuration... > > > ! > interface POS0/0/0.101 point-to-point > ip address X.X.X.X 255.255.255.252 > frame-relay interface-dlci 101 > end > > ROUTER#show int pos0/0/0 > POS0/0/0 is up, line protocol is up > Hardware is SPA-2XOC12-POS > MTU 4474 bytes, BW 622000 Kbit/sec, DLY 100 usec, > reliability 255/255, txload 6/255, rxload 38/255 > Encapsulation FRAME-RELAY, crc 32, loopback not set > Keepalive set (10 sec) > Scramble enabled > LMI enq sent 81981, LMI stat recvd 77480, LMI upd recvd 0, DTE LMI up > LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 > LMI DLCI 0 LMI type is ANSI Annex D frame relay DTE segmentation > inactive > FR SVC disabled, LAPF state down > Broadcast queue 0/256, broadcasts sent/dropped 26/0, interface broadcasts > 0 > Last input 00:00:00, output 00:00:00, output hang never > Last clearing of "show interface" counters 1w2d > Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0 > Queueing strategy: fifo > Output queue: 0/40 (size/max) > 5 minute input rate 94336000 bits/sec, 13151 packets/sec > 5 minute output rate 16470000 bits/sec, 7049 packets/sec > 12211574207 packets input, 10967607038364 bytes, 0 no buffer > Received 0 broadcasts (0 IP multicasts) > 6970870 runts, 2179 giants, 0 throttles > 0 parity > 892493293 input errors, 882184781 CRC, 0 frame, 0 overrun, 0 ignored, > 3335463 abort > 6379191154 packets output, 1614018181446 bytes, 0 underruns > 0 output errors, 0 applique, 4 interface resets > 0 unknown protocol drops > 0 output buffer failures, 0 output buffers swapped out > 0 carrier transitions > > > Any assistance on this will be greatly appreciated. > > > > > > > --- jsaxe at briworks.com wrote: > > From: Jeff Saxe > > I believe this is the explanation for your flapping: a PPP link is intended to go between two routers over, for instance, a private leased line, so both of the devices are peers, neither one particularly special. Frame-relay, by contrast, was originally designed so that your router was an "end user" device and its directly-connected partner device was not your other router, which you control, but the frame carrier's frame-relay switch. Your router was a DTE device, and their switch, which was in a more "important" position in control of the frame-relay NBMA cloud, was the DCE device. Your router then slaved to the frame switch via LMI signaling, so that the upstream switch instructed you which DLCIs existed and were up at the moment. > > So if you connect up two routers with frame-relay encap and each thinks it is the DTE, and neither one is taking the role of the frame switch, then when you bring them up, they will initially optimistically think their DLCIs are up and working, and the routing protocol and traffic will come up... but both of them will be waiting for the frame switch to send them LMI indicating that their idea of the DLCI up/down status is correct. When a couple minutes go by and they don't hear the responses to their LMI enquiries, they will bring all the DLCI's down. I thought they would then stay down forever, i.e., not flap, but maybe you are shutting / no shutting the POS circuit to try again. Anyway, I believe the very simple fix is > > interface POS0/0/0 > frame-relay intf-type dce > > So this will turn your Cisco side of the circuit into "DCE" mode, and if the Juniper side stays in "DTE" mode (the default, so probably not listed in the config), then the LMI should start behaving between the two. And yes, as Jay Hennigan suggested, you might need to use "encap frame-relay ietf" to be compatible with non-Cisco gear, or you might need to adjust the frame-relay lmi-type -- one type sends the LMI on DLCI number 0, one of them on DLCI 1023, whatever. I think you'll need to adjust the two ends until you see LMI enquiries both sent and received; right now the "show interface" from the Cisco side shows it has not received any LMI enq yet. > > > Good luck, and I hope it's that simple. :-) > > > From bhmccie at gmail.com Tue Dec 6 15:25:38 2011 From: bhmccie at gmail.com (-Hammer-) Date: Tue, 06 Dec 2011 15:25:38 -0600 Subject: Internet Edge and Defense in Depth In-Reply-To: <922ACC42D498884AA02B3565688AF995340255F77F@USEXMBS01.mwd.h2o> References: <922ACC42D498884AA02B3565688AF995340255F77F@USEXMBS01.mwd.h2o> Message-ID: <4EDE8852.30506@gmail.com> I personally have not seen it done in large environments. Hardware isn't there yet. I've seen it done in small business environments. Not a fan of the idea. -Hammer- "I was a normal American nerd" -Jack Herer On 12/06/2011 03:16 PM, Holmes,David A wrote: > Some firewall vendors are proposing to collapse all Internet edge functions into a single device (border router, firewall, IPS, caching engine, proxy, etc.). A general Internet edge design principle has been the "defense in depth" concept. Is anyone collapsing all Internet edge functions into one device? > > Regards, > > David > > > > ________________________________ > This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system. > From jim at miltonsecurity.com Tue Dec 6 15:32:04 2011 From: jim at miltonsecurity.com (JAMES MCMURRY) Date: Tue, 6 Dec 2011 13:32:04 -0800 Subject: Internet Edge and Defense in Depth In-Reply-To: <4EDE8852.30506@gmail.com> References: <922ACC42D498884AA02B3565688AF995340255F77F@USEXMBS01.mwd.h2o> <4EDE8852.30506@gmail.com> Message-ID: <4C0D4D97-780B-4F04-A8EE-E4FD204B03D6@miltonsecurity.com> I have seen at quite a few of our customers locations, starting out with a lofty goal of putting everything in a single box (UTM) and turning every single option on. In ~ 30% of the firms who do so it works out ok (not great, but it works). In the majority, the customer winds up turning features off one by one, and moving those to another system. Jim On Dec 6, 2011, at 1:25 PM, -Hammer- wrote: > I personally have not seen it done in large environments. Hardware isn't there yet. I've seen it done in small business environments. Not a fan of the idea. > > -Hammer- > > "I was a normal American nerd" > -Jack Herer > > > > On 12/06/2011 03:16 PM, Holmes,David A wrote: >> Some firewall vendors are proposing to collapse all Internet edge functions into a single device (border router, firewall, IPS, caching engine, proxy, etc.). A general Internet edge design principle has been the "defense in depth" concept. Is anyone collapsing all Internet edge functions into one device? >> >> Regards, >> >> David >> >> >> >> ________________________________ >> This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system. >> From david at davidswafford.com Tue Dec 6 15:37:24 2011 From: david at davidswafford.com (David Swafford) Date: Tue, 6 Dec 2011 16:37:24 -0500 Subject: Internet Edge and Defense in Depth In-Reply-To: <922ACC42D498884AA02B3565688AF995340255F77F@USEXMBS01.mwd.h2o> References: <922ACC42D498884AA02B3565688AF995340255F77F@USEXMBS01.mwd.h2o> Message-ID: They're proposing that so you buy their device, not renew support on your existing ones :-D Personally we just went through this w/ Palo Alto Networks. We bought a handful of their all-in-one firewalls simply for their web-filtering functionality (replacing Bluecoats). They pitched repetitively that we should replace all of our firewalls with just their box and collapse it. I must say, from a support perspective, the concept of "this box does web filtering, and that box handles the firewall of our public facing servers" is worth it's weight in gold. Web filtering alone can get stupid complex if you let it. Do you really want to troubleshoot an inbound web server issue while trying to sort through rules like "Jeff is allowed to get to Facebook, Marketing can get to Twitter, HR can see everything, oh wait here's the DMZ rules....". Boxes are cheap in an environment where staffing is lean. In SoHo, and smaller SMBs I could see it being different... we're on the larger of the "medium business" / small Enterprise side of the fence. David. On Tue, Dec 6, 2011 at 4:16 PM, Holmes,David A wrote: > Some firewall vendors are proposing to collapse all Internet edge functions into a single device (border router, firewall, IPS, caching engine, proxy, etc.). A general Internet edge design principle has been the "defense in depth" concept. Is anyone collapsing all Internet edge functions into one device? > > Regards, > > David > > > > ?________________________________ > This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system. From techgrrl at gmail.com Tue Dec 6 15:37:53 2011 From: techgrrl at gmail.com (Elle Plato) Date: Tue, 6 Dec 2011 13:37:53 -0800 Subject: CMDB on the cheap... In-Reply-To: References: Message-ID: On Tue, Dec 6, 2011 at 1:16 PM, George Herbert wrote: > Everyone I know has either paid through the nose or written one from > scratch. ?No good open source projects that worked out. > > Most people couldn't build well from scratch. ?I have been a couple of > places that did, it was man-year of senior grade guy effort range. > And 10-20% (or more) of an FTE in support. New devices need to be onboarded, new OS versions make subtle changes in the code, etc. The upside is that they can be powerful tools to automate mass config changes, and along with config parsing code, they can be powerful tools to standardize networks. Elle Janet Plato From jof at thejof.com Tue Dec 6 15:44:05 2011 From: jof at thejof.com (Jonathan Lassoff) Date: Tue, 6 Dec 2011 13:44:05 -0800 Subject: Internet Edge and Defense in Depth In-Reply-To: References: <922ACC42D498884AA02B3565688AF995340255F77F@USEXMBS01.mwd.h2o> Message-ID: I would argue that collapsing all of your policy evaluation and routing for a size/zone/area/whatever into one box is actually somewhat detrimental to stability (and consequently, security to a certain extent). Cramming every little feature under the sun into one appliance makes for great glossy brochures and Powerpoint decks, but I just don't think it's practical. Take a LAMP hosting operation for example. Which will scale the furthest to handle the most amount of traffic and stateful sessions: iptables and snort on each multi-core server, or one massive central box with some interface hardware and Cavium Octeons. If built properly, my money's on the distributed setup. Cheers, jof From Valdis.Kletnieks at vt.edu Tue Dec 6 15:45:51 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 06 Dec 2011 16:45:51 -0500 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: Your message of "Tue, 06 Dec 2011 10:30:20 PST." <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com> References: <20111205234419.GD1454@vacation.karoshi.com> <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> <9523.1323190086@turing-police.cc.vt.edu> <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com> Message-ID: <36733.1323207951@turing-police.cc.vt.edu> On Tue, 06 Dec 2011 10:30:20 PST, "andrew.wallace" said: > It could be argued that Nmap is malware, and such software has already been called to be made illegal. Called by whom, other than yourself? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From streiner at cluebyfour.org Tue Dec 6 16:06:08 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 6 Dec 2011 17:06:08 -0500 (EST) Subject: Internet Edge and Defense in Depth In-Reply-To: <922ACC42D498884AA02B3565688AF995340255F77F@USEXMBS01.mwd.h2o> References: <922ACC42D498884AA02B3565688AF995340255F77F@USEXMBS01.mwd.h2o> Message-ID: On Tue, 6 Dec 2011, Holmes,David A wrote: > Some firewall vendors are proposing to collapse all Internet edge > functions into a single device (border router, firewall, IPS, caching > engine, proxy, etc.). A general Internet edge design principle has been > the "defense in depth" concept. Is anyone collapsing all Internet edge > functions into one device? As others have said, this could make sense at the smaller end of the scale (SOHO, branch offices, small shops, etc), but I haven't see an all-in-one box that scales up to the traffic loads or handles things like routing protcools especially well in a large network. The marketing folks will often dance around the issue of throughput dropping as services or modules are turned on, but that's a big problem. I'm perfectly happy having border routers sitting at my borders, doing the routing, and firewalls elsewhere, doing the firewalling :) Another thing to remember is that existing router manufacturers have gotten pretty good (a few exceptions aside) at building pretty stable routing implementations. All-in-one box manufacturers that claim to be able to handle IPv6, BGP, OSPF(v2/v3), etc are basically starting out from scratch and don't have the benefit of the 10+ years of experience that Cisco/Juniper/et al have in building routers. jms From enwpst47 at gmail.com Tue Dec 6 16:07:47 2011 From: enwpst47 at gmail.com (Dan Collins) Date: Tue, 6 Dec 2011 17:07:47 -0500 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: <36733.1323207951@turing-police.cc.vt.edu> References: <20111205234419.GD1454@vacation.karoshi.com> <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> <9523.1323190086@turing-police.cc.vt.edu> <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com> <36733.1323207951@turing-police.cc.vt.edu> Message-ID: On Tue, Dec 6, 2011 at 4:45 PM, wrote: > On Tue, 06 Dec 2011 10:30:20 PST, "andrew.wallace" said: >> It could be argued that Nmap is malware, and such software has already been called to be made illegal. > > Called by whom, other than yourself? Germany? http://www.schneier.com/blog/archives/2007/08/new_german_hack.html -- Dan Collins From jsaxe at briworks.com Tue Dec 6 16:18:07 2011 From: jsaxe at briworks.com (Jeff Saxe) Date: Tue, 6 Dec 2011 22:18:07 +0000 Subject: GPON Vendors In-Reply-To: References: Message-ID: Here at Blue Ridge InternetWorks we evaluated a few vendors (a couple of years ago) and are extremely happy with our choice of Calix E7. The engineering is top-notch, optical components are good quality, boot time is very fast, decent GUI (not perfect, but improves with each software release), software upgrades have been (knock wood) seamless every time, etc. And the E7 line is easy to use -- I hear tell that the C7 line had a horrible CLI and cryptic GUI and was powerful-but-demanding, but the E7 just acts like a big Ethernet switch with VLANs, customer-side rate-limiting, and a little bit of DHCP snooping, security, and multicast processing. And their tech support, both pre-sales and on-demand, have been responsive and very helpful every time I've called on them. I don't think they are cheap, and we wish they made an ONT model with many Ethernet ports but no POTS and RF video, but that's just a product mix suggestion. Overall we are really happy, and it's easy to deploy and making us actual money. We have a rather small network, with a 2-slot (thin) E7 chassis. They also have a 20-slot large chassis. Only reservations I would have about it: - Currently runs only RSTP, but not MST. So difficult to load-balance redundant links into our switching core. I don't remember if MST is on the planned feature list. - Currently no true IPv6 support. You can hand off IPv6 over a "straight transparent LAN" connection, but you can't use the DHCP snooping / IP source verify features, which they have in v4, to ensure that a customer must use DHCPv6 to get their address and then cannot impersonate another customer with a manual IPv6 address. Calix says full IPv6 support is planned. - We had a few 711GX ONTs that developed optical transceiver failures in the field. It could be something that we did, but it seemed to me that it was just a bad batch of components in that specific product, since the 710GX and 711GE and 716GE's were all fine. All were replaced under warranty just fine, so no complaints other than customer downtime and our time to repair. Feel free to ping me off-list for any other questions. Jeff Saxe blue ridge internetworks 321 east main st ? suite 200 charlottesville va 22902 434.817.0707 x 2024 www.briworks.com Central Virginia?s technology authority since 2000. ________________________________________ From: Josh V. Hoppes [jhoppes at cfunet.net] Sent: Tuesday, December 06, 2011 2:52 PM To: nanog at nanog.org Subject: GPON Vendors Hello NANOG, Due to unforeseen circumstances we need to consider alternative vendors for our GPON system, moving away from Motorola. We wanted to throw out a line and find out what other networks have deployed and what experiences they have had positive or negative with them. Thanks in advance for any replies. Josh Hoppes Network Engineer Cedar Falls Utilities From ncolton at allophone.net Tue Dec 6 16:30:03 2011 From: ncolton at allophone.net (Nick Colton) Date: Tue, 6 Dec 2011 15:30:03 -0700 Subject: GPON Vendors In-Reply-To: References: Message-ID: We have a Calix C7 as well as some E7-2's in a few markets for a little over a year. We only deal with GPON/AE deployments and the C7 worked to get us started but the E7 is definitely more purpose built for ethernet & fiber services. Just started several major build-outs which pushed us to re-evaluate vendors and after looking at a few other vendors we ended up going back to the Calix E7 platform. Due to price and features vs other vendors. We have three E7-20's that we're turning up. I would agree with Jeff's positives. They are starting to roll out indoor ONT's which will shave some cost off of the ONT & Battery for the CPE. - They do only support RSTP now, not MST but in our deployment we have 2 x 10 GE LAG ports on two separate line switching cards. MST will be coming in a future release. - True IPv6 support is coming next year - Quite a few other new features coming in the next year that we're excited to see. Feel free to ping me off-list if you have any other questions. Nick Colton Director of Network Operations ALLO Communications On Tue, Dec 6, 2011 at 12:52 PM, Josh V. Hoppes wrote: > Hello NANOG, > > Due to unforeseen circumstances we need to consider alternative vendors > for our GPON system, moving away from Motorola. We wanted to throw out a > line and find out what other networks have deployed and what experiences > they have had positive or negative with them. Thanks in advance for any > replies. > > Josh Hoppes > Network Engineer > Cedar Falls Utilities > > > > From Valdis.Kletnieks at vt.edu Tue Dec 6 16:39:57 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 06 Dec 2011 17:39:57 -0500 Subject: Writable SNMP In-Reply-To: Your message of "Tue, 06 Dec 2011 14:18:52 EST." References: Message-ID: <39027.1323211197@turing-police.cc.vt.edu> On Tue, 06 Dec 2011 14:18:52 EST, Jeff Wheeler said: > I've spent enough time writing code to deal with SNMP (our own stack, > not using Net-SNMP or friends) to have a more in-depth understanding > of SNMP's pitfalls than most people. It is TERRIBLE and should be > totally gutted and replaced with something more sane, less likely to > have bugs, etc. A number of years ago, I pointed out that the official rfc-index.txt listed the publication date of RFC1442 as April 1, 1993 rather than April 1993. Draw your own conclusions. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From paul at paulgraydon.co.uk Tue Dec 6 17:02:45 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Tue, 06 Dec 2011 13:02:45 -1000 Subject: Internet Edge and Defense in Depth In-Reply-To: <922ACC42D498884AA02B3565688AF995340255F77F@USEXMBS01.mwd.h2o> References: <922ACC42D498884AA02B3565688AF995340255F77F@USEXMBS01.mwd.h2o> Message-ID: <4EDE9F15.2020601@paulgraydon.co.uk> On 12/06/2011 11:16 AM, Holmes,David A wrote: > Some firewall vendors are proposing to collapse all Internet edge functions into a single device (border router, firewall, IPS, caching engine, proxy, etc.). A general Internet edge design principle has been the "defense in depth" concept. Is anyone collapsing all Internet edge functions into one device? > > Regards, > > David > > Yikes... single point of failure. I really dislike the notion that all the security comes down to a single potentially compromisable point. Our security functions like IPS run separate to centralised logging, etc. etc. so that if someone does happen to break in to a particular point there are still further things they need to try to compromise before they can have their wicked way, or whatever it is they want to do. Sure the economies of a centralised box and the convenience are probably tempting, and it's better than nothing, but I can't picture it actually being an improvement over split out functions. Paul From edward.dore at freethought-internet.co.uk Tue Dec 6 17:12:13 2011 From: edward.dore at freethought-internet.co.uk (Edward Dore) Date: Tue, 6 Dec 2011 23:12:13 +0000 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: References: <20111205234419.GD1454@vacation.karoshi.com> <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> <9523.1323190086@turing-police.cc.vt.edu> <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com> <36733.1323207951@turing-police.cc.vt.edu> Message-ID: <094787A0-3840-48E5-B837-9B73AFE98EC0@freethought-internet.co.uk> On 6 Dec 2011, at 22:07, Dan Collins wrote: > On Tue, Dec 6, 2011 at 4:45 PM, wrote: >> On Tue, 06 Dec 2011 10:30:20 PST, "andrew.wallace" said: >>> It could be argued that Nmap is malware, and such software has already been called to be made illegal. >> >> Called by whom, other than yourself? > > Germany? > > http://www.schneier.com/blog/archives/2007/08/new_german_hack.html > > -- > Dan Collins > There's a big difference between "hacking tools" and malware. Edward Dore Freethought Internet From xmin0s at gmail.com Tue Dec 6 17:13:14 2011 From: xmin0s at gmail.com (Tim Eberhard) Date: Tue, 6 Dec 2011 17:13:14 -0600 Subject: Internet Edge and Defense in Depth In-Reply-To: <4C0D4D97-780B-4F04-A8EE-E4FD204B03D6@miltonsecurity.com> References: <922ACC42D498884AA02B3565688AF995340255F77F@USEXMBS01.mwd.h2o> <4EDE8852.30506@gmail.com> <4C0D4D97-780B-4F04-A8EE-E4FD204B03D6@miltonsecurity.com> Message-ID: To echo what James has already said.. I would say it's possible on the low/medium size enterprise network market. With that stated 70-80% of the time it's not designed correctly or a vendor issue pops up causing them to disable the feature. Careful planning must be done ahead of time. When looking at the spec sheets you can't look at the numbers and take them for face value. In most cases those numbers were achieved when *only* running that specific feature. So if a vendor claims 90meg of IPS throughput, 500meg of firewall throughput and 100meg of UTM. Chances are that 90meg of IPS traffic will take the box to it's knees. So if you're planning using the data sheet numbers you've most likely already failed. Plan carefully, test throughly, and in the end..you still may hit a bug or unexpected show stopper. I'd rather use the best tool for the job rather than jam everything into once box so I can share a chassis... Just my two cents, -Tim Eberhard On Tue, Dec 6, 2011 at 3:32 PM, JAMES MCMURRY wrote: > I have seen at quite a few of our customers locations, starting out with a lofty goal of putting everything in a single box (UTM) and turning every single option on. > > In ~ 30% of the firms who do so it works out ok (not great, but it works). ?In the majority, the customer winds up turning features off one by one, and moving those to another system. > > > Jim > > > On Dec 6, 2011, at 1:25 PM, -Hammer- wrote: > >> I personally have not seen it done in large environments. Hardware isn't there yet. I've seen it done in small business environments. Not a fan of the idea. >> >> -Hammer- >> >> "I was a normal American nerd" >> -Jack Herer >> >> >> >> On 12/06/2011 03:16 PM, Holmes,David A wrote: >>> Some firewall vendors are proposing to collapse all Internet edge functions into a single device (border router, firewall, IPS, caching engine, proxy, etc.). A general Internet edge design principle has been the "defense in depth" concept. Is anyone collapsing all Internet edge functions into one device? >>> >>> Regards, >>> >>> David >>> >>> >>> >>> ? ________________________________ >>> This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system. >>> > > From robert at timetraveller.org Tue Dec 6 17:20:05 2011 From: robert at timetraveller.org (Robert Brockway) Date: Wed, 7 Dec 2011 09:20:05 +1000 (EST) Subject: Internet Edge and Defense in Depth In-Reply-To: <922ACC42D498884AA02B3565688AF995340255F77F@USEXMBS01.mwd.h2o> References: <922ACC42D498884AA02B3565688AF995340255F77F@USEXMBS01.mwd.h2o> Message-ID: On Tue, 6 Dec 2011, Holmes,David A wrote: > Some firewall vendors are proposing to collapse all Internet edge > functions into a single device (border router, firewall, IPS, caching > engine, proxy, etc.). A general Internet edge design principle has been > the "defense in depth" concept. Is anyone collapsing all Internet edge > functions into one device? Hi David. A principle of network firewall design has long been that you want to minimise services (proxy, etc) running there as they can be a vector for attack against the firewall itself. In the end this is about risk analysis. In most cases I would recommend against loading the firewall with additional functionality, for a variety of reasons. In some cases it may make sense to do so. This is completely separate to whether servers should even have a firewall or IPS in front of them. That's another (interesting) discussion :) Cheers, Rob -- Email: robert at timetraveller.org Linux counter ID #16440 IRC: Solver (OFTC & Freenode) Web: http://www.practicalsysadmin.com Director, Software in the Public Interest (http://spi-inc.org/) Free & Open Source: The revolution that quietly changed the world "One ought not to believe anything, save that which can be proven by nature and the force of reason" -- Frederick II (26 December 1194 ? 13 December 1250) From Bryan at bryanfields.net Tue Dec 6 17:24:25 2011 From: Bryan at bryanfields.net (Bryan Fields) Date: Tue, 06 Dec 2011 18:24:25 -0500 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com> References: <20111205234419.GD1454@vacation.karoshi.com> <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> <9523.1323190086@turing-police.cc.vt.edu> <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com> Message-ID: <4EDEA429.2000709@bryanfields.net> On 12/6/2011 13:30, andrew.wallace wrote: > It could be argued that Nmap is malware, and such software has already been called to be made illegal. > > If I was Cnet, I would stop distributing his software altogether. > > Link: http://nmap.org/book/legal-issues.html If this is not trolling and you actually believe this, just wow..... Nmap is just a tool, and any tool can be misused by people for criminal acts. It's really no different than a gun in that regard. Both are incredibly useful things in the right hands, mere tools to further security. However in the wrong hands they can be used to commit crimes and break other peoples security. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From jtowne at slic.com Tue Dec 6 17:28:43 2011 From: jtowne at slic.com (Jonathan Towne) Date: Tue, 6 Dec 2011 18:28:43 -0500 Subject: GPON Vendors In-Reply-To: References: Message-ID: <20111206232841.GS13315@hijacked.us> Another vote for Calix here, but we started with Occam B-series gear (DSL+POTS) and kept buying their gear into the GPON times. Calix bought them.. so the vote is for Calix, even though I haven't used their C or E series gear. I do a fair amount of scripting for various tasks and have been fairly happy with their EPS ring protection.. not exactly like running [M|R]STP, but really quite resilient, at any rate. Their software is all running on a Linux core, has a decent (but not great) Cisco-ish CLI, and a very good web-UI. It seems like they're focusing more on the web-UI than the CLI, these days, but both are built on the same internals. We use B-6322 GPON blades (and quite a few of them, adding more on a daily basis..) and mainly their 12 blade chassis'. These chassis only have an option for -48VDC power, but are very well built overall, and the software is getting better on every new release. I expect we're nearing a sort of magic period of time when the Calix engineers and the Occam engineers are on the same page and really making progress, copying the best features from each platform onto the other. It seems to be showing in the early OccamOS 7.x releases, I can't speak for the C/E OS', I've never used them. -- Jonathan Towne On Tue, Dec 06, 2011 at 07:52:20PM +0000, Josh V. Hoppes scribbled: # Hello NANOG, # # Due to unforeseen circumstances we need to consider alternative vendors for our GPON system, moving away from Motorola. We wanted to throw out a line and find out what other networks have deployed and what experiences they have had positive or negative with them. Thanks in advance for any replies. # # Josh Hoppes # Network Engineer # Cedar Falls Utilities # # # From andrew.wallace at rocketmail.com Tue Dec 6 17:49:29 2011 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Tue, 6 Dec 2011 15:49:29 -0800 (PST) Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: <4EDEA429.2000709@bryanfields.net> References: <20111205234419.GD1454@vacation.karoshi.com> <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> <9523.1323190086@turing-police.cc.vt.edu> <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com> <4EDEA429.2000709@bryanfields.net> Message-ID: <1323215369.82533.YahooMailNeo@web162112.mail.bf1.yahoo.com> A trojan can be used for good if in the right hands as a remote access tool for business use. Andrew ________________________________ From: Bryan Fields To: "nanog at nanog.org" Sent: Tuesday, December 6, 2011 11:24 PM Subject: Re: [fyodor at insecure.org: C|Net Download.Com is now bundling Nmap with malware!] On 12/6/2011 13:30, andrew.wallace wrote: > It could be argued that Nmap is malware, and such software has already been called to be made illegal. > > If I was Cnet, I would stop distributing his software altogether. > > Link: http://nmap.org/book/legal-issues.html If this is not trolling and you actually believe this, just wow..... Nmap is just a tool, and any tool can be misused by people for criminal acts. It's really no different than a gun in that regard.? Both are incredibly useful things in the right hands, mere tools to further security.? However in the wrong hands they can be used to commit crimes and break other peoples security. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From tshaw at oitc.com Tue Dec 6 17:55:06 2011 From: tshaw at oitc.com (TR Shaw) Date: Tue, 6 Dec 2011 18:55:06 -0500 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: <1323215369.82533.YahooMailNeo@web162112.mail.bf1.yahoo.com> References: <20111205234419.GD1454@vacation.karoshi.com> <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> <9523.1323190086@turing-police.cc.vt.edu> <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com> <4EDEA429.2000709@bryanfields.net> <1323215369.82533.YahooMailNeo@web162112.mail.bf1.yahoo.com> Message-ID: <311C806B-2E39-453A-ADCC-612C8A531FE1@oitc.com> I can't believe this... Andrew, please check the dictionary second definition of Trojan before proceeding. A "remote access tool" is ssh, VNC and others and these are definitely not trojans. Get a grip. Trojan Horse noun noun Greek Mythology a hollow wooden statue of a horse in which the Greeks concealed themselves in order to enter Troy. ? (also Trojan horse) figurative a person or thing intended secretly to undermine or bring about the downfall of an enemy or opponent : the rebels may use this peace accord as a Trojan horse to try and take over. ? (also Trojan horse) Computing a program designed to breach the security of a computer system while ostensibly performing some innocuous function. Tom On Dec 6, 2011, at 6:49 PM, andrew.wallace wrote: > A trojan can be used for good if in the right hands as a remote access tool for business use. > > > Andrew > > > ________________________________ > From: Bryan Fields > To: "nanog at nanog.org" > Sent: Tuesday, December 6, 2011 11:24 PM > Subject: Re: [fyodor at insecure.org: C|Net Download.Com is now bundling Nmap with malware!] > > On 12/6/2011 13:30, andrew.wallace wrote: >> It could be argued that Nmap is malware, and such software has already been called to be made illegal. >> >> If I was Cnet, I would stop distributing his software altogether. >> >> Link: http://nmap.org/book/legal-issues.html > > If this is not trolling and you actually believe this, just wow..... > > Nmap is just a tool, and any tool can be misused by people for criminal acts. > It's really no different than a gun in that regard. Both are incredibly > useful things in the right hands, mere tools to further security. However in > the wrong hands they can be used to commit crimes and break other peoples > security. > > -- > Bryan Fields > > 727-409-1194 - Voice > 727-214-2508 - Fax > http://bryanfields.net From Valdis.Kletnieks at vt.edu Tue Dec 6 17:59:59 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 06 Dec 2011 18:59:59 -0500 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: Your message of "Tue, 06 Dec 2011 17:07:47 EST." References: <20111205234419.GD1454@vacation.karoshi.com> <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> <9523.1323190086@turing-police.cc.vt.edu> <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com> <36733.1323207951@turing-police.cc.vt.edu> Message-ID: <42091.1323215999@turing-police.cc.vt.edu> On Tue, 06 Dec 2011 17:07:47 EST, Dan Collins said: > On Tue, Dec 6, 2011 at 4:45 PM, wrote: > > On Tue, 06 Dec 2011 10:30:20 PST, "andrew.wallace" said: > >> It could be argued that Nmap is malware, and such software has already been called to be made illegal. > > > > Called by whom, other than yourself? > > Germany? > > http://www.schneier.com/blog/archives/2007/08/new_german_hack.html I rest my case. ;) Anybody know if they ever fixed their law? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From rdobbins at arbor.net Tue Dec 6 18:36:05 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 7 Dec 2011 00:36:05 +0000 Subject: Internet Edge and Defense in Depth In-Reply-To: References: <922ACC42D498884AA02B3565688AF995340255F77F@USEXMBS01.mwd.h2o> Message-ID: <2321C0A3-264A-4460-94BE-8A7F1214F3C3@arbor.net> On Dec 7, 2011, at 6:20 AM, Robert Brockway wrote: > This is completely separate to whether servers should even have a firewall or IPS in front of them. That's another (interesting) discussion :) ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From mvh at hosteurope.de Tue Dec 6 18:44:10 2011 From: mvh at hosteurope.de (Malte von dem Hagen) Date: Wed, 07 Dec 2011 01:44:10 +0100 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: <42091.1323215999@turing-police.cc.vt.edu> References: <20111205234419.GD1454@vacation.karoshi.com> <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> <9523.1323190086@turing-police.cc.vt.edu> <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com> <36733.1323207951@turing-police.cc.vt.edu> <42091.1323215999@turing-police.cc.vt.edu> Message-ID: <4EDEB6DA.9010100@hosteurope.de> Hi, Valdis.Kletnieks at vt.edu wrote on Mi, 2011-12-07 at 00:59+0100: > On Tue, 06 Dec 2011 17:07:47 EST, Dan Collins said: >> On Tue, Dec 6, 2011 at 4:45 PM, wrote: >>> On Tue, 06 Dec 2011 10:30:20 PST, "andrew.wallace" said: >>>> It could be argued that Nmap is malware, and such software has already been called to be made illegal. >>> >>> Called by whom, other than yourself? >> >> Germany? >> >> http://www.schneier.com/blog/archives/2007/08/new_german_hack.html > > I rest my case. ;) > > Anybody know if they ever fixed their law? not really. There have been some highest court decisions regarding this law saying the criminal liability depends on the intention someone produces or owns such tools - German jurisprudence is much more than the wording of the written law (though we have a lot of written laws, including many very strange ones). ;-) De facto, everybody in the industry continues to use "dual use" tools without fear of punishment and I am not aware of any dubious court decisions - the law was created for clearly illegal uses of such tools. Nontheless, as said by others, "hacker tools" != "malware". Regards, Malte -- Malte von dem Hagen Head of Network Engineering & Operations ----------------------------------------------------------------------- Host Europe GmbH - http://www.hosteurope.de Welserstra?e 14 - 51149 K?ln - Germany Telefon: 0800 467 8387 - Fax: +49 180 5 66 3233 (*) HRB 28495 Amtsgericht K?ln - USt-IdNr.: DE187370678 Gesch?ftsf?hrer: Patrick Pulverm?ller, Thomas Vollrath (*) 0,14 EUR/Min. aus dem dt. Festnetz; maximal 0,42 EUR/Min. aus den dt. Mobilfunknetzen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From Valdis.Kletnieks at vt.edu Tue Dec 6 19:03:15 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 06 Dec 2011 20:03:15 -0500 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: Your message of "Tue, 06 Dec 2011 15:49:29 PST." <1323215369.82533.YahooMailNeo@web162112.mail.bf1.yahoo.com> References: <20111205234419.GD1454@vacation.karoshi.com> <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> <9523.1323190086@turing-police.cc.vt.edu> <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com> <4EDEA429.2000709@bryanfields.net> <1323215369.82533.YahooMailNeo@web162112.mail.bf1.yahoo.com> Message-ID: <44850.1323219795@turing-police.cc.vt.edu> On Tue, 06 Dec 2011 15:49:29 PST, "andrew.wallace" said: > A trojan can be used for good if in the right hands as a remote access tool for business use. Best troll line since n3td3v got banned from full-disclosure. Well played, I've been outclassed, I'm outta here. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From mike at mtcc.com Tue Dec 6 19:09:54 2011 From: mike at mtcc.com (Michael Thomas) Date: Tue, 06 Dec 2011 17:09:54 -0800 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: <44850.1323219795@turing-police.cc.vt.edu> References: <20111205234419.GD1454@vacation.karoshi.com> <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> <9523.1323190086@turing-police.cc.vt.edu> <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com> <4EDEA429.2000709@bryanfields.net> <1323215369.82533.YahooMailNeo@web162112.mail.bf1.yahoo.com> <44850.1323219795@turing-police.cc.vt.edu> Message-ID: <4EDEBCE2.4010405@mtcc.com> On 12/06/2011 05:03 PM, Valdis.Kletnieks at vt.edu wrote: > On Tue, 06 Dec 2011 15:49:29 PST, "andrew.wallace" said: >> A trojan can be used for good if in the right hands as a remote access tool for business use. > Best troll line since n3td3v got banned from full-disclosure. Well played, I've been > outclassed, I'm outta here. > I had assumed that he meant this in terms of red light districts. Mike From tvhawaii at shaka.com Tue Dec 6 19:36:08 2011 From: tvhawaii at shaka.com (Michael Painter) Date: Tue, 6 Dec 2011 15:36:08 -1000 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] References: <20111205234419.GD1454@vacation.karoshi.com> <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> <9523.1323190086@turing-police.cc.vt.edu> <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com> <4EDEA429.2000709@bryanfields.net> <1323215369.82533.YahooMailNeo@web162112.mail.bf1.yahoo.com> <44850.1323219795@turing-police.cc.vt.edu> Message-ID: <6598045046084577A2247C7C114441E0@owner59e1f1502> ----- Original Message ----- From: To: Sent: Tuesday, December 06, 2011 3:03 PM Subject: Re: [fyodor at insecure.org: C|Net Download.Com is now bundling Nmap with malware!] On Tue, 06 Dec 2011 15:49:29 PST, "andrew.wallace" said: >> A trojan can be used for good if in the right hands as a remote access tool for business use. >Best troll line since n3td3v got banned from full-disclosure. Well played, I've been >outclassed, I'm outta here. Maybe andrew's been reading http://wikileaks.org/the-spyfiles.html ? From owen at delong.com Tue Dec 6 20:10:14 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 6 Dec 2011 18:10:14 -0800 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: <1323215369.82533.YahooMailNeo@web162112.mail.bf1.yahoo.com> References: <20111205234419.GD1454@vacation.karoshi.com> <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> <9523.1323190086@turing-police.cc.vt.edu> <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com> <4EDEA429.2000709@bryanfields.net> <1323215369.82533.YahooMailNeo@web162112.mail.bf1.yahoo.com> Message-ID: Carrier IQ does not qualify as a good use of a Trojan and comes about as close to your definition as I can think of. No, a Trojan is malware. Any software which operates without the knowledge or consent of the user to engage in operations the user would not reasonably expect is not being used for good, no matter how well intentioned. Owen On Dec 6, 2011, at 3:49 PM, andrew.wallace wrote: > A trojan can be used for good if in the right hands as a remote access tool for business use. > > > Andrew > > > ________________________________ > From: Bryan Fields > To: "nanog at nanog.org" > Sent: Tuesday, December 6, 2011 11:24 PM > Subject: Re: [fyodor at insecure.org: C|Net Download.Com is now bundling Nmap with malware!] > > On 12/6/2011 13:30, andrew.wallace wrote: >> It could be argued that Nmap is malware, and such software has already been called to be made illegal. >> >> If I was Cnet, I would stop distributing his software altogether. >> >> Link: http://nmap.org/book/legal-issues.html > > If this is not trolling and you actually believe this, just wow..... > > Nmap is just a tool, and any tool can be misused by people for criminal acts. > It's really no different than a gun in that regard. Both are incredibly > useful things in the right hands, mere tools to further security. However in > the wrong hands they can be used to commit crimes and break other peoples > security. > > -- > Bryan Fields > > 727-409-1194 - Voice > 727-214-2508 - Fax > http://bryanfields.net From Valdis.Kletnieks at vt.edu Tue Dec 6 20:20:52 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 06 Dec 2011 21:20:52 -0500 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: Your message of "Tue, 06 Dec 2011 17:09:54 PST." <4EDEBCE2.4010405@mtcc.com> References: <20111205234419.GD1454@vacation.karoshi.com> <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> <9523.1323190086@turing-police.cc.vt.edu> <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com> <4EDEA429.2000709@bryanfields.net> <1323215369.82533.YahooMailNeo@web162112.mail.bf1.yahoo.com> <44850.1323219795@turing-police.cc.vt.edu> <4EDEBCE2.4010405@mtcc.com> Message-ID: <48657.1323224452@turing-police.cc.vt.edu> On Tue, 06 Dec 2011 17:09:54 PST, Michael Thomas said: > On 12/06/2011 05:03 PM, Valdis.Kletnieks at vt.edu wrote: > > On Tue, 06 Dec 2011 15:49:29 PST, "andrew.wallace" said: > >> A trojan can be used for good if in the right hands as a remote access tool for business use. > I had assumed that he meant this in terms of red light districts. But then it's not exactly remote access, is it? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Tue Dec 6 20:20:03 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 06 Dec 2011 21:20:03 -0500 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: Your message of "Tue, 06 Dec 2011 18:10:14 PST." References: <20111205234419.GD1454@vacation.karoshi.com> <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> <9523.1323190086@turing-police.cc.vt.edu> <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com> <4EDEA429.2000709@bryanfields.net> <1323215369.82533.YahooMailNeo@web162112.mail.bf1.yahoo.com> Message-ID: <48621.1323224403@turing-police.cc.vt.edu> On Tue, 06 Dec 2011 18:10:14 PST, Owen DeLong said: > No, a Trojan is malware. Any software which operates without the > knowledge or consent of the user to engage in operations the user would > not reasonably expect is not being used for good, no matter how well > intentioned. Strictly speaking, it's "without the knowledge or consent of the *owner*". Especially in corporate environments, "owner" != "user". -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From mtinka at globaltransit.net Tue Dec 6 21:25:19 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Wed, 7 Dec 2011 11:25:19 +0800 Subject: GPON Vendors In-Reply-To: References: Message-ID: <201112071125.22810.mtinka@globaltransit.net> On Wednesday, December 07, 2011 03:52:20 AM Josh V. Hoppes wrote: > Due to unforeseen circumstances we need to consider > alternative vendors for our GPON system, moving away > from Motorola. We wanted to throw out a line and find > out what other networks have deployed and what > experiences they have had positive or negative with > them. Thanks in advance for any replies. We're using Huawei for this. It's a stable system, and they do this quite well. Watch out for the EMS though; it's great for management and provisioning, but customer migration is not supported (yet). The ONU that ships from Huawei is also not terribly good as a clever CPE. So if you're thinking of doing interesting things, suggest you use their ONU as a bridge and have something else terminating the PPPoE/DHCP sessions. Otherwise, I'd certainly recommend looking at Huawei for this. We've been reasonably happy using them for our FTTH and IPTv deployment. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From daniel.unam.ipv6 at gmail.com Tue Dec 6 21:39:32 2011 From: daniel.unam.ipv6 at gmail.com (Daniel Espejel) Date: Tue, 06 Dec 2011 21:39:32 -0600 Subject: HP IPv6 RA Guard In-Reply-To: References: <4EDD8D87.30208@gmail.com> Message-ID: <4EDEDFF4.9030606@gmail.com> Well, as a stability feature may work if better understanding of the internet protocols is given to all the network specialist (almost a paradox, all those documents are free to be checked for all the people). Of course, the problem with the rogue IPv6 packets and "malformed" packets will exists as long as IPv6 is being deployed wide spread, and the proposed mechanisms on how to deal with those problems is, as it seems, a passion for some guys, and a job for other ones, but always thinking on the Internet growth is the main focus of those whom participate actively to reach that objective. For Rogue V6's maybe some ACLs could work, but increases complexity. Maybe some mechanisms in the receiving nodes could work too, but requires a lot of computer resources and in that situations the LoWPAN will suffer its own success; so actually a solution should be adequate to each situation. BR On 06/12/11 07:46, Ray Soucy wrote: > I think of RA Guard as a Layer-2 stability feature, rather than a > security feature. > > You're correct that it is unable to deal with RA crafted in a > fragmented packet on the majority (if not all) of implementations. > > The issue of rogue RA exists on every network, regardless of whether > or not the IT group has deployed IPv6 or is aware of the IPv6 traffic > on that network. > > Windows ICS is the most common "accidental" cause of rogue RA on a LAN. > > On Mon, Dec 5, 2011 at 10:35 PM, Daniel Espejel > wrote: >> So,still assuming the fact that attackers will use the same "traditional >> ipv4" methods to alter the correct functioning over a network?...Well, >> maybe. Toda's IPv6 expertise for some network andmins and security >> experts is minimal. So most trainning and understanding before >> implementing its a good idea. >> >> For example, the RA-Guard method has a significant vulnerability: It's >> not designed to identify a "complex" IPv6-many extension headers formed >> packet (F. Gont - 6Networks). Some other security oriented mechanisms >> may fail because of the low IPv6 compliance. >> >> Regards. >> >> >> -- >> Daniel Espejel P?rez >> T?cnico Acad?mico >> D.G.T.I.C. - U.N.A.M. >> GT-IPv6 CLARA / GT-IPv6 U.N.A.M. >> >> > > -- Daniel Espejel P?rez T?cnico Acad?mico D.G.T.I.C. - U.N.A.M. GT-IPv6 CLARA / GT-IPv6 U.N.A.M. From mtinka at globaltransit.net Tue Dec 6 21:45:13 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Wed, 7 Dec 2011 11:45:13 +0800 Subject: GPON Vendors In-Reply-To: References: Message-ID: <201112071145.16217.mtinka@globaltransit.net> On Wednesday, December 07, 2011 06:18:07 AM Jeff Saxe wrote: > - Currently runs only RSTP, but not MST. So difficult to > load-balance redundant links into our switching core. I > don't remember if MST is on the planned feature list. We run LACP either to the same or different routers depending on a few internal factors. For LACP to different routers, we use MC-LAG. Don't want to have to deal with "Spamming" Tree :-). > - Currently no true IPv6 support. You can hand off IPv6 > over a "straight transparent LAN" connection, but you > can't use the DHCP snooping / IP source verify features, > which they have in v4, to ensure that a customer must > use DHCPv6 to get their address and then cannot > impersonate another customer with a manual IPv6 address. > Calix says full IPv6 support is planned. Same problem on the Huawei, too. Full support is planned for mid-to-late 2013. Of course, that puts a dent in our plans. > - We had a few 711GX ONTs that developed optical > transceiver failures in the field. It could be something > that we did, but it seemed to me that it was just a bad > batch of components in that specific product, since the > 710GX and 711GE and 716GE's were all fine. All were > replaced under warranty just fine, so no complaints > other than customer downtime and our time to repair. We've found that the Huawei works well with other vendor optics too. Cisco, Juniper, OEM's. All good. Of course, for 10Gbps uplinks, the SFP+ units are bought from Huawei. We have some SPF+ modules from Cisco and their OEM's, but haven't tried them on the Huawei. Experience suggests it would work, but they're quite premium that we always need them for the Cisco's anyway :-). Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mtinka at globaltransit.net Tue Dec 6 21:58:59 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Wed, 7 Dec 2011 11:58:59 +0800 Subject: Internet Edge and Defense in Depth In-Reply-To: References: <922ACC42D498884AA02B3565688AF995340255F77F@USEXMBS01.mwd.h2o> Message-ID: <201112071159.02647.mtinka@globaltransit.net> We've been fairly against centralizing functions, even though marketing scripts suggest it is worth doing. Not security-related per se, but for smaller PoP's, we'll collapse P/PE functions into a single box. As others have mentioned, this makes sense when scale is small. But on a large scale, we've not been one to buy into multi- chassis-type arrangements. With boxes getting smaller and more powerful due to Ethernet being the implicitly agreed- upon medium, it's still cheaper (and more resilient) to buy smaller boxes and distribute services than take one large one and stick them all in there. I'm hoping the OP can draw a parallel for their own situation, if this is useful. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From fyodor at insecure.org Tue Dec 6 22:18:53 2011 From: fyodor at insecure.org (Fyodor) Date: Tue, 6 Dec 2011 20:18:53 -0800 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> References: <20111205234419.GD1454@vacation.karoshi.com.> <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> Message-ID: <20111207041853.GL24540@syn.titan.net> On Mon, Dec 05, 2011 at 10:14:48PM -0800, andrew.wallace wrote: > > Using fruitful language and acting like a child isn't going to see > you taken seriously. I'm sorry that my language offended you. But if you ever spend more than 14 years creating free software as a gift to the community, only to have it used as bait by a giant corporation to infect your users with malware, then you may understand my rage. The good news is that many users are sick and tired of having their machines hijacked by malware. Especially by CNET Download.Com, which still says on their own adware policy page: "In your letters, user reviews, and polls, you told us bundled adware was unacceptable--no matter how harmless it might be. We want you to know what you're getting when you download from CNET Download.com, and no other download site can promise that." --http://www.cnet.com/2723-13403_1-461-16.html Um, what people WANT when they download Nmap is Nmap itself. Not to have their searches redirected to Bing and their home page changed to Microsoft's MSN. Speaking of which, Microsoft emailed me today. They said that they didn't know they were sponsoring CNET to trojan open source software, and that they have stopped doing it. But the trojan installer uses your Internet connection to obtain more "special offers" from CNET, and they immediately switched to installing a "Babylon toolbar" and search engine redirect instead. Then CNET removed that and are now promoting their own "techtracker" tool. Apparently the heat is so high that even malware vendors are refusing to have any more part in CNET's antics! But if CNET isn't stopped, the malware vendors will come crawling back eventually and CNET will be there to receive them. There have been dozens of news articles in the last day and hundreds of outraged comments on blogs, Twitter, Facebook, etc. In the midst of all this terrible PR, Download.com went in last night and quietly switched their Nmap downloads back to our real installer. At least for now. But that isn't enough--they are still infecting the installers for thousands of other packages! For example, they have currently infected the installer for a children's coloring book app: http://download.cnet.com/Kea-Coloring-Book/3000-2102_4-10360620.html Have they no shame at all??! I've created a page with the situation background, links to the news articles, and the latest updates: http://insecure.org/news/download-com-fiasco.html Feel free to share it. Together, I hope we can get Download.Com to apologize and cease this reprehensible behavior! Cheers, Fyodor From tvhawaii at shaka.com Tue Dec 6 22:53:08 2011 From: tvhawaii at shaka.com (Michael Painter) Date: Tue, 6 Dec 2011 18:53:08 -1000 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] References: <20111205234419.GD1454@vacation.karoshi.com.> <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> <20111207041853.GL24540@syn.titan.net> Message-ID: <765968889B724C4896CE5E38559C5E11@owner59e1f1502> Fyodor wrote: > On Mon, Dec 05, 2011 at 10:14:48PM -0800, andrew.wallace wrote: >> >> Using fruitful language and acting like a child isn't going to see >> you taken seriously. > > I'm sorry that my language offended you. But if you ever spend more > than 14 years creating free software as a gift to the community, only > to have it used as bait by a giant corporation to infect your users > with malware, then you may understand my rage. > > The good news is that many users are sick and tired of having their > machines hijacked by malware. Especially by CNET Download.Com, which > still says on their own adware policy page: > > "In your letters, user reviews, and polls, you told us bundled > adware was unacceptable--no matter how harmless it might be. We want > you to know what you're getting when you download from CNET > Download.com, and no other download site can promise that." > --http://www.cnet.com/2723-13403_1-461-16.html > > Um, what people WANT when they download Nmap is Nmap itself. Not to > have their searches redirected to Bing and their home page changed to > Microsoft's MSN. > > Speaking of which, Microsoft emailed me today. They said that they > didn't know they were sponsoring CNET to trojan open source software, > and that they have stopped doing it. But the trojan installer uses > your Internet connection to obtain more "special offers" from CNET, > and they immediately switched to installing a "Babylon toolbar" and > search engine redirect instead. Then CNET removed that and are now > promoting their own "techtracker" tool. Apparently the heat is so > high that even malware vendors are refusing to have any more part in > CNET's antics! But if CNET isn't stopped, the malware vendors will > come crawling back eventually and CNET will be there to receive them. > > There have been dozens of news articles in the last day and hundreds > of outraged comments on blogs, Twitter, Facebook, etc. In the midst > of all this terrible PR, Download.com went in last night and quietly > switched their Nmap downloads back to our real installer. At least > for now. But that isn't enough--they are still infecting the > installers for thousands of other packages! For example, they have > currently infected the installer for a children's coloring book app: > > http://download.cnet.com/Kea-Coloring-Book/3000-2102_4-10360620.html > > Have they no shame at all??! > > I've created a page with the situation background, links to the news > articles, and the latest updates: > > http://insecure.org/news/download-com-fiasco.html > > Feel free to share it. Together, I hope we can get Download.Com to > apologize and cease this reprehensible behavior! > > Cheers, > Fyodor No, there's no shame when money's involved. Do Unto Others as they would do unto you...sue the fsck out of them. --Michael From wjhns61 at hardakers.net Tue Dec 6 23:21:50 2011 From: wjhns61 at hardakers.net (Wes Hardaker) Date: Tue, 06 Dec 2011 21:21:50 -0800 Subject: Writable SNMP In-Reply-To: (Keegan Holley's message of "Tue, 6 Dec 2011 11:07:44 -0500") References: Message-ID: <0lehwh9csx.fsf@wjh.hardakers.net> >>>>> On Tue, 6 Dec 2011 11:07:44 -0500, Keegan Holley said: KH> Admittedly, you will have to deal with proprietary mibs and reformat KH> the data once it's returned. That's the nail in the coffin of just about every configuration protocol. Until multiple vendors implement a common model, no technology is going to work. SNMP certainly suffered from multiple vendors doing different things in their private MIBs while also implementing the standard MIBs is a standard way. You could probably get two vendors (X and Y) to agree that all devices have N interfaces with M-bit counters to represent traffic. The problem, especially with configuration, comes when vendor X uses virtual interfaces (eth0:1) to model interfaces with multiple addresses and vendor Y uses a single interface identifier with a sub-tail to list all the addresses assigned to the interface. Now this problem is at least solvable, given enough code, to take a configuration set from one device and covert it to the other, which in part is the goal of netconf: to enable a language that will hopefully allow a transformation process to succeed and thus bring about the holy grail of a singular management protocol. But in the end, every problem will still end up in the odd case where vendor X produces a config set with 2 "rows" and vendor Y produces a config set with 3 "rows" and no magical transformation can possibly get from point A to point B because the data models simply don't align. At all. When the internals aren't compatable, there isn't a data model to be written. No matter if it's in txt, SMIv2, XML, yang or moon dust. And hence the reason homogeneous networks with rdist distributed config files were born. -- Wes Hardaker From wjhns61 at hardakers.net Tue Dec 6 23:37:44 2011 From: wjhns61 at hardakers.net (Wes Hardaker) Date: Tue, 06 Dec 2011 21:37:44 -0800 Subject: Writable SNMP In-Reply-To: <20111206173934.GK21378@blackrose.org> (Dorian Kim's message of "Tue, 6 Dec 2011 12:39:34 -0500") References: <1AB264E2-E1BC-41BF-BF9B-89BF642FFC4E@puck.nether.net> <20111206173934.GK21378@blackrose.org> Message-ID: <0laa759c2f.fsf@wjh.hardakers.net> >>>>> On Tue, 6 Dec 2011 12:39:34 -0500, Dorian Kim said: DK> There is one good reason. Every vendor seem to assign a junior intern to DK> maintanining SNMP code, so you are interfacing with your router via a very DK> suspect interface. The marking folks believed that when X dollars had to be spent, most folks would rather buy a box where .99X was spent on a "new spiffy routing feature" rather than on a manageable device. To change that, people need to start writing RFPs very very differently so that more points (dollars) are given to boxes that have consistent, standardized management interfaces rather than to boxes with new feature Z. Unfortunately, I don't have high hopes for that as institutions don't make money from having manageable networks. They make money from having fast and furious networks and that's what drives industry progress. [note: I'm not saying this is right or wrong; just that it's true. I could argue, and have, both sides quite effectively] -- Wes Hardaker From mtinka at globaltransit.net Wed Dec 7 00:56:15 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Wed, 7 Dec 2011 14:56:15 +0800 Subject: Internet Edge and Defense in Depth In-Reply-To: <201112071159.02647.mtinka@globaltransit.net> References: <922ACC42D498884AA02B3565688AF995340255F77F@USEXMBS01.mwd.h2o> <201112071159.02647.mtinka@globaltransit.net> Message-ID: <201112071456.19899.mtinka@globaltransit.net> On Wednesday, December 07, 2011 11:58:59 AM Mark Tinka wrote: > But on a large scale, we've not been one to buy into > multi- chassis-type arrangements. s/multi-chassis-type/logical routers. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From owen at delong.com Wed Dec 7 01:35:06 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 6 Dec 2011 23:35:06 -0800 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: <48621.1323224403@turing-police.cc.vt.edu> References: <20111205234419.GD1454@vacation.karoshi.com> <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> <9523.1323190086@turing-police.cc.vt.edu> <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com> <4EDEA429.2000709@bryanfields.net> <1323215369.82533.YahooMailNeo@web162112.mail.bf1.yahoo.com> <48621.1323224403@turing-police.cc.vt.edu> Message-ID: On Dec 6, 2011, at 6:20 PM, wrote: > On Tue, 06 Dec 2011 18:10:14 PST, Owen DeLong said: > >> No, a Trojan is malware. Any software which operates without the >> knowledge or consent of the user to engage in operations the user would >> not reasonably expect is not being used for good, no matter how well >> intentioned. > > Strictly speaking, it's "without the knowledge or consent of the *owner*". Especially > in corporate environments, "owner" != "user". I would argue that the superset applies in a proper definition here. Software which operates with the knowledge and consent of the owner, but, not the knowledge or consent of the end-user is still, IMHO, nefarious at best. Owen From owen at delong.com Wed Dec 7 01:43:20 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 6 Dec 2011 23:43:20 -0800 Subject: GPON Vendors In-Reply-To: <201112071125.22810.mtinka@globaltransit.net> References: <201112071125.22810.mtinka@globaltransit.net> Message-ID: <50C7EBA9-A4E7-46E2-BEBA-F6C11005E8E6@delong.com> In any such vendor choice, I'd say make sure that they have workable IPv6 before making any major investments. Otherwise, you've got a dead-end platform that won't serve you very well for very many years. Owen On Dec 6, 2011, at 7:25 PM, Mark Tinka wrote: > On Wednesday, December 07, 2011 03:52:20 AM Josh V. Hoppes > wrote: > >> Due to unforeseen circumstances we need to consider >> alternative vendors for our GPON system, moving away >> from Motorola. We wanted to throw out a line and find >> out what other networks have deployed and what >> experiences they have had positive or negative with >> them. Thanks in advance for any replies. > > We're using Huawei for this. > > It's a stable system, and they do this quite well. Watch out > for the EMS though; it's great for management and > provisioning, but customer migration is not supported (yet). > > The ONU that ships from Huawei is also not terribly good as > a clever CPE. So if you're thinking of doing interesting > things, suggest you use their ONU as a bridge and have > something else terminating the PPPoE/DHCP sessions. > > Otherwise, I'd certainly recommend looking at Huawei for > this. We've been reasonably happy using them for our FTTH > and IPTv deployment. > > Cheers, > > Mark. From owen at delong.com Wed Dec 7 01:47:41 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 6 Dec 2011 23:47:41 -0800 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: <765968889B724C4896CE5E38559C5E11@owner59e1f1502> References: <20111205234419.GD1454@vacation.karoshi.com.> <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> <20111207041853.GL24540@syn.titan.net> <765968889B724C4896CE5E38559C5E11@owner59e1f1502> Message-ID: <4781EB66-BFD6-4AED-B028-BAE727F3F26B@delong.com> Could he send their hosting company a take-down order for the download.com site? On Dec 6, 2011, at 8:53 PM, Michael Painter wrote: > Fyodor wrote: >> On Mon, Dec 05, 2011 at 10:14:48PM -0800, andrew.wallace wrote: >>> Using fruitful language and acting like a child isn't going to see >>> you taken seriously. >> I'm sorry that my language offended you. But if you ever spend more >> than 14 years creating free software as a gift to the community, only >> to have it used as bait by a giant corporation to infect your users >> with malware, then you may understand my rage. >> The good news is that many users are sick and tired of having their >> machines hijacked by malware. Especially by CNET Download.Com, which >> still says on their own adware policy page: >> "In your letters, user reviews, and polls, you told us bundled >> adware was unacceptable--no matter how harmless it might be. We want >> you to know what you're getting when you download from CNET >> Download.com, and no other download site can promise that." >> --http://www.cnet.com/2723-13403_1-461-16.html >> Um, what people WANT when they download Nmap is Nmap itself. Not to >> have their searches redirected to Bing and their home page changed to >> Microsoft's MSN. >> Speaking of which, Microsoft emailed me today. They said that they >> didn't know they were sponsoring CNET to trojan open source software, >> and that they have stopped doing it. But the trojan installer uses >> your Internet connection to obtain more "special offers" from CNET, >> and they immediately switched to installing a "Babylon toolbar" and >> search engine redirect instead. Then CNET removed that and are now >> promoting their own "techtracker" tool. Apparently the heat is so >> high that even malware vendors are refusing to have any more part in >> CNET's antics! But if CNET isn't stopped, the malware vendors will >> come crawling back eventually and CNET will be there to receive them. >> There have been dozens of news articles in the last day and hundreds >> of outraged comments on blogs, Twitter, Facebook, etc. In the midst >> of all this terrible PR, Download.com went in last night and quietly >> switched their Nmap downloads back to our real installer. At least >> for now. But that isn't enough--they are still infecting the >> installers for thousands of other packages! For example, they have >> currently infected the installer for a children's coloring book app: >> http://download.cnet.com/Kea-Coloring-Book/3000-2102_4-10360620.html >> Have they no shame at all??! >> I've created a page with the situation background, links to the news >> articles, and the latest updates: >> http://insecure.org/news/download-com-fiasco.html >> Feel free to share it. Together, I hope we can get Download.Com to >> apologize and cease this reprehensible behavior! >> Cheers, >> Fyodor > > No, there's no shame when money's involved. > Do Unto Others as they would do unto you...sue the fsck out of them. > --Michael > From jared at puck.nether.net Wed Dec 7 01:55:47 2011 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 7 Dec 2011 02:55:47 -0500 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: <4781EB66-BFD6-4AED-B028-BAE727F3F26B@delong.com> References: <20111205234419.GD1454@vacation.karoshi.com.> <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> <20111207041853.GL24540@syn.titan.net> <765968889B724C4896CE5E38559C5E11@owner59e1f1502> <4781EB66-BFD6-4AED-B028-BAE727F3F26B@delong.com> Message-ID: <741ADD38-9F5C-4CD6-BAB8-DC571133A4DB@puck.nether.net> On Dec 7, 2011, at 2:47 AM, Owen DeLong wrote: > > > Could he send their hosting company a take-down order for the download.com site? > > Might be feasible to take over the domain if SOPA were passed :) I am glad that CBS Interactive/CNET has started to see the light, here is hoping there will be subsequent corrective actions taken. - Jared From mtinka at globaltransit.net Wed Dec 7 02:45:59 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Wed, 7 Dec 2011 16:45:59 +0800 Subject: GPON Vendors In-Reply-To: <50C7EBA9-A4E7-46E2-BEBA-F6C11005E8E6@delong.com> References: <201112071125.22810.mtinka@globaltransit.net> <50C7EBA9-A4E7-46E2-BEBA-F6C11005E8E6@delong.com> Message-ID: <201112071646.02408.mtinka@globaltransit.net> On Wednesday, December 07, 2011 03:43:20 PM Owen DeLong wrote: > In any such vendor choice, I'd say make sure that they > have workable IPv6 before making any major investments. > Otherwise, you've got a dead-end platform that won't > serve you very well for very many years. GPON deployment for FTTH tends to be, really, an Ethernet switch. There is just additional intelligence thrown in to keep the thing from being suicidal at Layer 2 for that many customers when doing typical consumer broadband. If you're using the GPON AN as as a regular switch, i.e., one VLAN per customer, then you can roll IPv6 to your FTTH customers just as you would on a Cisco Catalyst switch, for example. But most operators are using them for broadband deployments, and the split horizon mechanisms implemented as part of the Broadband Forum spec. for GPON make it unintuitive that v6 be supported off the bat for DHCP and PPPoE. Of course, this isn't rocket science, and just needs to be added in software - a problem many vendors are suffering from. As we do with all of them, keep pushing for support for the features you need in v6. Just make sure you don't buy a dud. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mtinka at globaltransit.net Wed Dec 7 03:10:35 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Wed, 7 Dec 2011 17:10:35 +0800 Subject: Martian 128.0.0.0/16 - Fixed Releases in Junos In-Reply-To: <4EDE3CF1.2070005@bogus.com> References: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> <82zkf6t76h.fsf@mid.bfk.de> <4EDE3CF1.2070005@bogus.com> Message-ID: <201112071710.35618.mtinka@globaltransit.net> For those who might not be aware, an OS-level fix has been integrated into the following Junos releases: - 10.0R5 - 10.4R8 - 10.4R9 - 11.1R7 - 11.2R4 - 11.3R3 - 11.4R1 - 11.4R2 - 12.1R1 Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From Valdis.Kletnieks at vt.edu Wed Dec 7 06:37:03 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 07 Dec 2011 07:37:03 -0500 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: Your message of "Tue, 06 Dec 2011 23:35:06 PST." References: <20111205234419.GD1454@vacation.karoshi.com> <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> <9523.1323190086@turing-police.cc.vt.edu> <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com> <4EDEA429.2000709@bryanfields.net> <1323215369.82533.YahooMailNeo@web162112.mail.bf1.yahoo.com> <48621.1323224403@turing-police.cc.vt.edu> Message-ID: <16296.1323261423@turing-police.cc.vt.edu> On Tue, 06 Dec 2011 23:35:06 PST, Owen DeLong said: > Software which operates with the knowledge and consent of the owner, but, not the > knowledge or consent of the end-user is still, IMHO, nefarious at best. Yeah well... that horse left the barn once this company in Redmon released an operating system that allows the AD admins to push GPO policy. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From owen at delong.com Wed Dec 7 08:23:50 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 7 Dec 2011 06:23:50 -0800 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: <16296.1323261423@turing-police.cc.vt.edu> References: <20111205234419.GD1454@vacation.karoshi.com> <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> <9523.1323190086@turing-police.cc.vt.edu> <1323196220.28950.YahooMailNeo@web162102.mail.bf1.yahoo.com> <4EDEA429.2000709@bryanfields.net> <1323215369.82533.YahooMailNeo@web162112.mail.bf1.yahoo.com> <48621.1323224403@turing-police.cc.vt.edu> <16296.1323261423@turing-police.cc.vt.edu> Message-ID: <4977146B-6BC1-4D1D-ADD3-EE4EAFD30C8C@delong.com> On Dec 7, 2011, at 4:37 AM, Valdis.Kletnieks at vt.edu wrote: > On Tue, 06 Dec 2011 23:35:06 PST, Owen DeLong said: >> Software which operates with the knowledge and consent of the owner, but, not the >> knowledge or consent of the end-user is still, IMHO, nefarious at best. > > Yeah well... that horse left the barn once this company in Redmon released > an operating system that allows the AD admins to push GPO policy. ;) > > > What makes you think I don't consider Windows to be malware? Owen From asmith at ursinus.edu Wed Dec 7 08:34:58 2011 From: asmith at ursinus.edu (Smith, C. Aaron) Date: Wed, 7 Dec 2011 09:34:58 -0500 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: <20111207041853.GL24540@syn.titan.net> References: <20111205234419.GD1454@vacation.karoshi.com.> <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> <20111207041853.GL24540@syn.titan.net> Message-ID: <2246F8B902DEFB44B0A83C82D366F5521E70B1A33D@Exchange02.ursinus.local> Fyodor, Thanks for taking the fight to them. A simple fan of nmap, Aaron Smith Ursinus College From graham at g-rock.net Wed Dec 7 08:39:08 2011 From: graham at g-rock.net (Graham Wooden) Date: Wed, 07 Dec 2011 09:39:08 -0500 Subject: [OT] Domain Name broker Message-ID: <20111207093908.z32zln7lco4kc8ko@webmail.iamforeverme.com> Hi there, Through one of our recent acquisitions, we have a domain name that we will be phasing out. We believe there is some value to it and have already identified a fortune 100 company's business unit that is using the same name, who is using their country based tld. Now, they may be completely happy with that, who knows - but would like to investigate with a broker to help reach out to them or help identify other potential buyers. A simple request out to them for a marketing contact has gone unaswered. Anyone have any experience in selling a domain name through a broker service that helps identifing potential buyers? Replies off list are welcomed. Thanks, -graham From caldcv at gmail.com Wed Dec 7 09:02:56 2011 From: caldcv at gmail.com (Chris) Date: Wed, 7 Dec 2011 10:02:56 -0500 Subject: [OT] Domain Name broker In-Reply-To: <20111207093908.z32zln7lco4kc8ko@webmail.iamforeverme.com> References: <20111207093908.z32zln7lco4kc8ko@webmail.iamforeverme.com> Message-ID: Auction it on Sedo because they will handle the escrow. I would avoid selling it yourself because you'll just get scam artists and if it's Fortune 500, definitely cash in. From cmadams at hiwaay.net Wed Dec 7 09:12:40 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 7 Dec 2011 09:12:40 -0600 Subject: New on RIPE Labs: The Curious Case of 128.0/16 In-Reply-To: <20111206153831.GA22818@hiwaay.net> References: <4EDE2B7D.9050603@ripe.net> <20111206153831.GA22818@hiwaay.net> Message-ID: <20111207151240.GA20080@hiwaay.net> Once upon a time, Chris Adams said: > Using RIPE's traceroute web interface, I can see that Sprint is > filtering 128.0.0.0/16: Sprint is now passing routes and traffic in 128.0.0.0/16. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From graham at g-rock.net Wed Dec 7 09:16:49 2011 From: graham at g-rock.net (=?utf-8?B?Z3JhaGFtQGctcm9jay5uZXQ=?=) Date: Wed, 07 Dec 2011 10:16:49 -0500 Subject: =?utf-8?B?UmU6IFtPVF0gRG9tYWluIE5hbWUgYnJva2Vy?= Message-ID: Looking at that path as well. Thanks Chris. Parent company of the target business unit is a fortune 100. Sent from my HTC on the Now Network from Sprint! ----- Reply message ----- From: "Chris" Date: Wed, Dec 7, 2011 9:02 am Subject: [OT] Domain Name broker To: Auction it on Sedo because they will handle the escrow. I would avoid selling it yourself because you'll just get scam artists and if it's Fortune 500, definitely cash in. From david at davidswafford.com Tue Dec 6 05:16:10 2011 From: david at davidswafford.com (David Swafford) Date: Tue, 6 Dec 2011 06:16:10 -0500 Subject: 128.0.0.0/16 configured as martians in some routers In-Reply-To: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> References: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> Message-ID: Hi Alex, In Dayton, Ohio, US, we are not seeing any 128... routes from TWTC (AS 4323). In St. Louis, Ohio, US, we are seeing the 128.0.0.0/21 via Level 3 (AS 3356). David Swafford, Sr. Network Engineer, CareSource On Mon, Dec 5, 2011 at 10:20 AM, Alex Le Heux wrote: > Dear Colleagues, > > The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline that this /16 should no longer be reserved as specialised address space. > > All allocations that were already issued have been exchanged and for now we will hold this space in quarantine. > > We urge everyone to change the default behaviour of their Juniper routers: > > set routing-options martians 128.0.0.0/16 orlonger allow > set routing-options martians 191.255.0.0/16 orlonger allow > set routing-options martians 223.255.255.0/24 exact allow > > 128.0.0.0/16 has been added to the RIPE NCC's Debogonising Project: > > http://www.ris.ripe.net/debogon/ > > To facilitate testing, the following prefixes are being announced: > > prefix ?pinagble address > > 128.0.0.0/16 ? ?128.0.0.1 > 128.0.8.0/21 ? ?128.0.8.1 > 128.0.24.0/24 ? 128.0.24.1 > > Best regards, > > Alex Le Heux > Policy Implementation Co-ordinator > RIPE NCC From alexlh at ripe.net Mon Dec 5 09:48:39 2011 From: alexlh at ripe.net (Alex Le Heux) Date: Mon, 5 Dec 2011 16:48:39 +0100 Subject: [ncc-announce] 128.0.0.0/16 configured as martians in some routers In-Reply-To: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> References: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> Message-ID: <45D79898-3854-4671-AC9E-317A65C28FC7@ripe.net> Dear Colleagues, The correct prefix and pingable address list for the Debogonising Project is: prefix pinagble address 128.0.0.0/21 128.0.0.1 128.0.24.0/24 128.0.24.1 Our apologies for the oversight. Best regards, Alex Le Heux Policy Implementation Co-ordinator RIPE NCC On Dec 5, 2011, at 16:20, Alex Le Heux wrote: > Dear Colleagues, > > The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline that this /16 should no longer be reserved as specialised address space. > > All allocations that were already issued have been exchanged and for now we will hold this space in quarantine. > > We urge everyone to change the default behaviour of their Juniper routers: > > set routing-options martians 128.0.0.0/16 orlonger allow > set routing-options martians 191.255.0.0/16 orlonger allow > set routing-options martians 223.255.255.0/24 exact allow > > 128.0.0.0/16 has been added to the RIPE NCC's Debogonising Project: > > http://www.ris.ripe.net/debogon/ > > To facilitate testing, the following prefixes are being announced: > > prefix pinagble address > > 128.0.0.0/16 128.0.0.1 > 128.0.8.0/21 128.0.8.1 > 128.0.24.0/24 128.0.24.1 > > Best regards, > > Alex Le Heux > Policy Implementation Co-ordinator > RIPE NCC From alexlh at ripe.net Mon Dec 5 09:20:27 2011 From: alexlh at ripe.net (Alex Le Heux) Date: Mon, 5 Dec 2011 16:20:27 +0100 Subject: [ncc-announce] 128.0.0.0/16 configured as martians in some routers Message-ID: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> Dear Colleagues, The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline that this /16 should no longer be reserved as specialised address space. All allocations that were already issued have been exchanged and for now we will hold this space in quarantine. We urge everyone to change the default behaviour of their Juniper routers: set routing-options martians 128.0.0.0/16 orlonger allow set routing-options martians 191.255.0.0/16 orlonger allow set routing-options martians 223.255.255.0/24 exact allow 128.0.0.0/16 has been added to the RIPE NCC's Debogonising Project: http://www.ris.ripe.net/debogon/ To facilitate testing, the following prefixes are being announced: prefix pinagble address 128.0.0.0/16 128.0.0.1 128.0.8.0/21 128.0.8.1 128.0.24.0/24 128.0.24.1 Best regards, Alex Le Heux Policy Implementation Co-ordinator RIPE NCC From keegan.holley at sungard.com Wed Dec 7 10:19:24 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Wed, 7 Dec 2011 11:19:24 -0500 Subject: Writable SNMP In-Reply-To: References: <1AB264E2-E1BC-41BF-BF9B-89BF642FFC4E@puck.nether.net> Message-ID: > > > There's no reason one can't program a device with SNMP, the main issue > IMHO > > has always been what I dubbed "config drift". You have your desired > > configuration and variances that happen over time. If you don't force > > a 'wr mem' or similar event after you trigger a 'copy tftp run' > operation, > > you may have troubles that are not apparent if there is a power failure > > or other lossage. The boot-time parser doesn't interpret SNMP, it parses > > text. This and other reasons have made people fail-safe to using the > language > > most easily interpreted by the device. > > Yup, I think the OP was maybe getting at: > "Why can't I snmp configure my cisco/juniper/alteon device?" > > I took that to mean (probably naively?) that they also would validate > configs and update drift out of the configuration. You CAN force a 'wr > mem' via snmp as well, of course (in cisco world). > It was more curiosity. I'm looking in to scripting and starting to get tired of having to account for ssh/telnet, credentials, differences in platforms and code from the same vendor and my various failed attempts to do all of the above. Most of the automation suites I've seen work via logins, rancid,HP NA etc etc. Although there are better programmers that can and have made it work it still seems cumbersome to me. I've pretty much made the assumption that writable SNMP was a bad idea but have never actually tried it. I was curious what others were using, netconf or just scripted logins. I'm also fighting a losing battle to convince people that netconf isn't evil. It strikes me as odd that if I wanted to talk to a database/website full of credit card and billing info there's a long list of API's I could use, but if I wanted to talk to the router or firewall in front of it I can only use ssh or telnet. From keegan.holley at sungard.com Wed Dec 7 10:29:46 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Wed, 7 Dec 2011 11:29:46 -0500 Subject: Writable SNMP In-Reply-To: References: Message-ID: > > > > I can see the other comments about interactive commands and bulk > > read/writes, but what's the harm of doing it on internet connected boxes > vs. > > non-internet boxes. Just about everyone uses snmp reads in the interwebs > > I think the general feeling is that snmp is udp so it's spoofable and > your perimeter acls will never be 100% (or rather, are you willing to > risk them not being 100%?) > That's a given even though there's still the string to deny the spoofed traffic someone could cause a fair amount of trouble if they knew what your acl's look like. That being said I don't think I've ever seen a company that doesn't at least use SNMP for billing and basic monitoring and many don't think to block it at their edge. It's hard to convince someone to change something that's been around for years though. SNMP is flawed though and enabling writes just makes it worse. > > > and as such filters it at their edges and hopefully on each platform. > You'd > > secure it the same way you'd secure readable SNMP I assume. > > read is 'painful', write can be downright deadly (to your SLAs). > > >> > >> Also, who tests snmp WRITE in their code? at scale? for daily > >> operations tasks? > > > > > > lol, that could be a problem. > > yea, I bet the number of people that test, at scale/operations-pace, > snmp WRITE is countable on a single hand. > > >> > >> ... (didn't the snmp incident in 2002 teach us > >> something?) > >> > > Please elaborate. > > < > http://www.cisco.com/warp/public/707/cisco-sa-20010227-ios-snmp-ilmi.shtml > > > > oh, 2001... memory lag :( > I don't remember hearing about this causing issues in a production network. According to the article you can just filter SNMP by IP which should be in place anyway. It's triggered by some sort of hidden string which would make it malicious, unless I'm missing something. In lieu of a software upgrade, a workaround can be applied to certain IOS releases by disabling the ILMI community or "**ilmi*" view and applying an access list to prevent unauthorized access to SNMP. Any affected system, regardless of software release, may be protected by filtering SNMP traffic at a network perimeter or on individual devices. From blake at ispn.net Wed Dec 7 10:57:13 2011 From: blake at ispn.net (Blake Hudson) Date: Wed, 07 Dec 2011 10:57:13 -0600 Subject: Overall Netflix bandwidth usage numbers on a network? In-Reply-To: References: <20111203004732.GH13315@hijacked.us> <20111203005847.GI13315@hijacked.us> Message-ID: <4EDF9AE9.9040700@ispn.net> Yeah, that's an interesting one. We currently utilize netflow for this, but you also need to consider that netflix streaming is just port 80 www traffic. Because netflix uses CDNs, its difficult to pin down the traffic to specific hosts in the CDN and say that this traffic was netflix, while this traffic was the latest windows update (remember this is often a shared hosting platform). We've done our own testing and have come to a good solution which uses a combination of nbar, packet marking, and netflow to come to a conclusion. On a ~160Mbps link, netflix peaks out between 30-50Mbps around 8-10PM each evening. The rest of the traffic is predominantly other forms of HTTP traffic (including other video streaming services). Martin Hepworth wrote the following on 12/3/2011 2:36 AM: > Also checkout Adrian Cockcroft presentations on their architecture which > describes how they use aws and CDns etc > > Martin > > From gcroft at shoremortgage.com Wed Dec 7 11:31:46 2011 From: gcroft at shoremortgage.com (Gregory Croft) Date: Wed, 7 Dec 2011 12:31:46 -0500 Subject: BGP and Firewalls... Message-ID: <1F4D60B00DE5FB42AD4BB2BC06DC3092207090B9@mail.shoremortgage.com> Hi All, Does anyone have any experience with using firewalls as edge devices when BGP is concerned? Specifically the Palo Alto series of devices. If so please contact me off list. Thank you. Thank you, Gregory S. Croft From morrowc.lists at gmail.com Wed Dec 7 11:43:55 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 7 Dec 2011 12:43:55 -0500 Subject: BGP and Firewalls... In-Reply-To: <1F4D60B00DE5FB42AD4BB2BC06DC3092207090B9@mail.shoremortgage.com> References: <1F4D60B00DE5FB42AD4BB2BC06DC3092207090B9@mail.shoremortgage.com> Message-ID: On Wed, Dec 7, 2011 at 12:31 PM, Gregory Croft wrote: > Hi All, > > > > Does anyone have any experience with using firewalls as edge devices > when BGP is concerned? > > Specifically the Palo Alto series of devices. nokia/checkpoint has done this for ages. what's the problem you have? From morrowc.lists at gmail.com Wed Dec 7 11:51:29 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 7 Dec 2011 12:51:29 -0500 Subject: Writable SNMP In-Reply-To: References: Message-ID: On Wed, Dec 7, 2011 at 11:29 AM, Keegan Holley wrote: >> >> > I can see the other comments about interactive commands and bulk >> > read/writes, but what's the harm of doing it on internet connected boxes >> > vs. >> > non-internet boxes.? Just about everyone uses snmp reads in the >> > interwebs >> >> I think the general feeling is that snmp is udp so it's spoofable and >> your perimeter acls will never be 100% (or rather, are you willing to >> risk them not being 100%?) > > > That's a given even though there's still the string to deny the spoofed > traffic someone could cause a fair amount of trouble if they knew what your so... be cautious here, the 'acl' on the community string is really 'who can use this string' you have to still process the packet to some extent before you decide that the string doesn't match NMS1's ip address :( you need also to traffic filter (in Cisco CoPP, in Juniper LoopbackFilter)... that said, someone can bomb your loopback with 'public' and just spoof the src to your NMS, or your NOC or ... all easy to figure out :( (well the noc is at least :) ). > acl's look like. ?That being said I don't think I've ever seen a company > that doesn't at least use SNMP for billing and basic monitoring and many > don't think to block it at their edge. ?It's hard to convince someone to yea, RO though, at least... though still, you process the packets to see 'oh yea, not my string' :( > change something that's been around for years though. ?SNMP is flawed though > and enabling writes just makes it worse. yes. >> >> >> > and as such filters it at their edges and hopefully on each platform. >> > You'd >> > secure it the same way you'd secure readable SNMP I assume. >> >> read is 'painful', write can be downright deadly (to your SLAs). >> >> >> >> >> Also, who tests snmp WRITE in their code? at scale? for daily >> >> operations tasks? >> > >> > >> > lol, that could be a problem. >> >> yea, I bet the number of people that test, at scale/operations-pace, >> snmp WRITE is countable on a single hand. >> >> >> >> >> ... (didn't the snmp incident in 2002 teach us >> >> something?) >> >> >> > Please elaborate. >> >> >> >> >> oh, 2001... memory lag :( > > > I don't remember hearing about this causing issues in a production network. There were lots of people with things changing on their devices without their knowledge :( > ?According to the article you can just filter SNMP by IP which should be in > place anyway. ?It's triggered by some sort of hidden string which would make > it malicious, unless I'm missing something. yep, just 'hey there's a hidden community string, which isn't supposed to actually be available outside the local box, and is RW... whoops! the intern made it available :(' coupled with the fact that 90% of the industry had the same roots for snmp code;( > In lieu of a software upgrade, a workaround can be applied to certain IOS > releases by disabling the ILMI community or "*ilmi" view and applying an > access list to prevent unauthorized access to SNMP. Any affected system, > regardless of software release, may be protected by filtering SNMP traffic > at a network perimeter or on individual devices. right, but as I said above, the community-string restrictions don't help you in cases where you haven't filtered source-addresses in loopback/copp :( people still get to grind on your router's snmp process, maybe there's another way in, maybe there's a bug in the snmpd :( -chris From morrowc.lists at gmail.com Wed Dec 7 11:53:01 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 7 Dec 2011 12:53:01 -0500 Subject: Writable SNMP In-Reply-To: References: <1AB264E2-E1BC-41BF-BF9B-89BF642FFC4E@puck.nether.net> Message-ID: On Wed, Dec 7, 2011 at 11:19 AM, Keegan Holley wrote: > It was more curiosity. ?I'm looking in to scripting and starting to get > tired of having to account for ssh/telnet, credentials, differences in 'write a library'... someone once said. > platforms and code from the same vendor and my various failed attempts to do > all of the above. ?Most of the automation suites I've seen work via logins, > rancid,HP NA etc etc. ?Although there are better programmers that can and > have made it work it still seems cumbersome to me. I've pretty much made the it is, somewhat, yes. > assumption that writable SNMP was a bad idea but have never actually tried > it. ?I was curious what others were using, netconf or just scripted logins. > I'm also fighting a losing battle to convince people that netconf isn't > evil. ?It strikes me as odd that if I wanted to talk to a database/website > full of credit card and billing info there's a long list of API's I could > use, but if I wanted to talk to the router or firewall in front of it I can > only use ssh or telnet. sad, right? there are millions of restful program writers, only a few thousand network device programmers, and the vast majority of 'network management' is done by people perfectly happy with 'cisco-works' :( From gcroft at shoremortgage.com Wed Dec 7 12:04:10 2011 From: gcroft at shoremortgage.com (Gregory Croft) Date: Wed, 7 Dec 2011 13:04:10 -0500 Subject: BGP and Firewalls... In-Reply-To: References: <1F4D60B00DE5FB42AD4BB2BC06DC3092207090B9@mail.shoremortgage.com> Message-ID: <1F4D60B00DE5FB42AD4BB2BC06DC3092207092FB@mail.shoremortgage.com> I'm not having problems... Well, not yet anyways. :) Just investigating to see if there is a reason I shouldn't use a firewall at the edge versus a dedicated router as well as to see if anyone can share their specific experience with the PAN devices. Thanks everyone! Greg -----Original Message----- From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow Sent: Wednesday, December 07, 2011 12:44 PM To: Gregory Croft Cc: nanog at nanog.org Subject: Re: BGP and Firewalls... On Wed, Dec 7, 2011 at 12:31 PM, Gregory Croft wrote: > Hi All, > > > > Does anyone have any experience with using firewalls as edge devices > when BGP is concerned? > > Specifically the Palo Alto series of devices. nokia/checkpoint has done this for ages. what's the problem you have? From dholmes at mwdh2o.com Wed Dec 7 12:19:58 2011 From: dholmes at mwdh2o.com (Holmes,David A) Date: Wed, 7 Dec 2011 10:19:58 -0800 Subject: BGP and Firewalls... In-Reply-To: <1F4D60B00DE5FB42AD4BB2BC06DC3092207092FB@mail.shoremortgage.com> References: <1F4D60B00DE5FB42AD4BB2BC06DC3092207090B9@mail.shoremortgage.com> <1F4D60B00DE5FB42AD4BB2BC06DC3092207092FB@mail.shoremortgage.com> Message-ID: <922ACC42D498884AA02B3565688AF995340255F8A3@USEXMBS01.mwd.h2o> My concern is whether or not consolidating border router and firewall functions in the same device violates, if not explicitly, then the spirit of the "defense in depth" Internet edge design principle. Here is a link to a Department of Homeland Security document where this is discussed (for control systems, but has general application), but not addressed directly: http://www.inl.gov/technicalpublications/Documents/3375141.pdf The old Checkpoint/Nokia firewalls consolidated routing and firewall functions, but the question is one of layered defenses, such that it seems intuitive that it is inherently more difficult for the bad actor to penetrate network defenses the more devices that have to be penetrated. -----Original Message----- From: Gregory Croft [mailto:gcroft at shoremortgage.com] Sent: Wednesday, December 07, 2011 10:04 AM To: Christopher Morrow Cc: nanog at nanog.org Subject: RE: BGP and Firewalls... I'm not having problems... Well, not yet anyways. :) Just investigating to see if there is a reason I shouldn't use a firewall at the edge versus a dedicated router as well as to see if anyone can share their specific experience with the PAN devices. Thanks everyone! Greg -----Original Message----- From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow Sent: Wednesday, December 07, 2011 12:44 PM To: Gregory Croft Cc: nanog at nanog.org Subject: Re: BGP and Firewalls... On Wed, Dec 7, 2011 at 12:31 PM, Gregory Croft wrote: > Hi All, > > > > Does anyone have any experience with using firewalls as edge devices > when BGP is concerned? > > Specifically the Palo Alto series of devices. nokia/checkpoint has done this for ages. what's the problem you have? This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system. From bicknell at ufp.org Wed Dec 7 12:36:53 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 7 Dec 2011 10:36:53 -0800 Subject: BGP and Firewalls... In-Reply-To: <922ACC42D498884AA02B3565688AF995340255F8A3@USEXMBS01.mwd.h2o> References: <1F4D60B00DE5FB42AD4BB2BC06DC3092207090B9@mail.shoremortgage.com> <1F4D60B00DE5FB42AD4BB2BC06DC3092207092FB@mail.shoremortgage.com> <922ACC42D498884AA02B3565688AF995340255F8A3@USEXMBS01.mwd.h2o> Message-ID: <20111207183653.GA98645@ussenterprise.ufp.org> In a message written on Wed, Dec 07, 2011 at 10:19:58AM -0800, Holmes,David A wrote: > My concern is whether or not consolidating border router and firewall functions in the same device violates, if not explicitly, then the spirit of the "defense in depth" Internet edge design principle. Here is a link to a Department of Homeland Security document where this is discussed (for control systems, but has general application), but not addressed directly: http://www.inl.gov/technicalpublications/Documents/3375141.pdf I don't think you're looking at defense in depth in the right way, and thus your question doesn't quite make sense. If you look at the attack vector described in the paper you link it shows what many of us in the ISP world call the "soft gooey center". As you see the attacker finds a way to bypass the corporate firewall, and once inside the network there are no further controls to prevent the attacker from hopping between corporate desktops, corporate servers, and eventually a SCADA network. Defense in depth is about internal compartmentalization. The diagram shows deploying additional firewalls between corporate LAN users and corporate servers, and then again between corproate servers and SCADA networks. The idea is even if the attacker is able to bypass one firewall, they have to pass through a second to get to another zone. Even with a defense in depth design with these multiple firewalls (really, access control points), there is still the question you ask, should the checkpoint devices be multiple boxes (e.g. firewall and IDS in separate chassis) or unified boxes (firewall+IDS in a single box). It's really a totally orthogonal question. What defense in depth does not allow you to do (from my understanding) is consolidate these multiple firewall functions into one large virtual firewall, because then you're back to a single point of failure/control. To summarize, "defense in depth" requires access control and monitoring between different security zones, and that those access control devices be not shared with devices handling other zones. The devices themselves can include multiple functions on a single device without affecting the strategy. Is stacking functions on one device a good idea? Well, millions of residential users do it (firewall+ids+ips all in one), and plenty of corporate users have had trouble scaling all in one devices. Multiple devices provides greater opportunity to select best in breed, but adds more failure points and more things to manage and coorolate. Which tradeoffs are best for you and your network is something that can't be easily answered with a rule, or by someone else on the Internet. -- 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 frnkblk at iname.com Wed Dec 7 13:10:31 2011 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 7 Dec 2011 13:10:31 -0600 Subject: GPON Vendors In-Reply-To: <201112071646.02408.mtinka@globaltransit.net> References: <201112071125.22810.mtinka@globaltransit.net> <50C7EBA9-A4E7-46E2-BEBA-F6C11005E8E6@delong.com> <201112071646.02408.mtinka@globaltransit.net> Message-ID: <01cf01ccb513$e3f54590$abdfd0b0$@iname.com> In late August Calix came to our site and tested their IPv6 support on the C7 platform for their upcoming 8.0 release. They tested both on GPON and VDSL2 using the N:1 (VLAN per service) approach. There were some issues that prevented all the CPE I had from working, but since then they've taken it back and completed that work. I've invited them back onsite to re-test so we can validate before they begin their controlled release. Frank -----Original Message----- From: Mark Tinka [mailto:mtinka at globaltransit.net] Sent: Wednesday, December 07, 2011 2:46 AM To: Owen DeLong Cc: nanog at nanog.org Subject: Re: GPON Vendors On Wednesday, December 07, 2011 03:43:20 PM Owen DeLong wrote: > In any such vendor choice, I'd say make sure that they > have workable IPv6 before making any major investments. > Otherwise, you've got a dead-end platform that won't > serve you very well for very many years. GPON deployment for FTTH tends to be, really, an Ethernet switch. There is just additional intelligence thrown in to keep the thing from being suicidal at Layer 2 for that many customers when doing typical consumer broadband. If you're using the GPON AN as as a regular switch, i.e., one VLAN per customer, then you can roll IPv6 to your FTTH customers just as you would on a Cisco Catalyst switch, for example. But most operators are using them for broadband deployments, and the split horizon mechanisms implemented as part of the Broadband Forum spec. for GPON make it unintuitive that v6 be supported off the bat for DHCP and PPPoE. Of course, this isn't rocket science, and just needs to be added in software - a problem many vendors are suffering from. As we do with all of them, keep pushing for support for the features you need in v6. Just make sure you don't buy a dud. Mark. From morrowc.lists at gmail.com Wed Dec 7 14:43:44 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 7 Dec 2011 15:43:44 -0500 Subject: BGP and Firewalls... In-Reply-To: <1F4D60B00DE5FB42AD4BB2BC06DC3092207092FB@mail.shoremortgage.com> References: <1F4D60B00DE5FB42AD4BB2BC06DC3092207090B9@mail.shoremortgage.com> <1F4D60B00DE5FB42AD4BB2BC06DC3092207092FB@mail.shoremortgage.com> Message-ID: On Wed, Dec 7, 2011 at 1:04 PM, Gregory Croft wrote: > I'm not having problems... Well, not yet anyways. ?:) > > Just investigating to see if there is a reason I shouldn't use a > firewall at the edge versus a dedicated router as well as to see if > anyone can share their specific experience with the PAN devices. do you have power or space concerns? do you want to have a single point of failure? do you want to have some limitations in what your devices can effectively do? you probably want to be able to fail the firewall and maintain some level of access to the site (the router), you may want to fail the router but still maintain local network services from the router south. don't put all your eggs in one basket, unless you only have 1 U of space and 1 power plug. From rcarpen at network1.net Wed Dec 7 15:54:13 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Wed, 07 Dec 2011 16:54:13 -0500 (EST) Subject: Juniper <-> Cisco IPv6 BGP peering In-Reply-To: <43c838e2-d866-4d4b-ac6c-31b8f90c7246@zimbra.network1.net> Message-ID: Does anyone have any suggestions on setting up BGP peering between Juniper (SRX) and Cisco? I successfully have cisco-cisco and juniper-juniper without problems. When I am trying to peer to one of my upstreams (who has cisco) with my Juniper SRX, They are seeing the link-local address as the next-hop, but are unable to get an ND entry for it, and thus cannot forward traffic to me. -Randy -- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1 ---- From randy at psg.com Wed Dec 7 16:02:30 2011 From: randy at psg.com (Randy Bush) Date: Thu, 08 Dec 2011 07:02:30 +0900 Subject: Juniper <-> Cisco IPv6 BGP peering In-Reply-To: References: <43c838e2-d866-4d4b-ac6c-31b8f90c7246@zimbra.network1.net> Message-ID: > When I am trying to peer to one of my upstreams (who has cisco) with > my Juniper SRX, They are seeing the link-local address as the > next-hop use global v6 addresses From rcarpen at network1.net Wed Dec 7 16:09:48 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Wed, 07 Dec 2011 17:09:48 -0500 (EST) Subject: Juniper <-> Cisco IPv6 BGP peering In-Reply-To: Message-ID: We are using global addresses, but on the Cisco side, it is seeing the Link-Local as the next-hop. -Randy -- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1 ---- ----- Original Message ----- > > When I am trying to peer to one of my upstreams (who has cisco) > > with > > my Juniper SRX, They are seeing the link-local address as the > > next-hop > > use global v6 addresses > > From galu at packetdam.com Wed Dec 7 16:27:49 2011 From: galu at packetdam.com (Vlad Galu) Date: Wed, 07 Dec 2011 22:27:49 +0000 Subject: Juniper <-> Cisco IPv6 BGP peering In-Reply-To: References: Message-ID: <4EDFE865.2040304@packetdam.com> Randy Carpenter wrote: > Does anyone have any suggestions on setting up BGP peering between Juniper (SRX) and Cisco? > > I successfully have cisco-cisco and juniper-juniper without problems. > > When I am trying to peer to one of my upstreams (who has cisco) with my Juniper SRX, They are seeing the link-local address as the next-hop, but are unable to get an ND entry for it, and thus cannot forward traffic to me. > Any reasons against exchanging v6 prefixes over a v4 session? From rcarpen at network1.net Wed Dec 7 16:30:24 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Wed, 07 Dec 2011 17:30:24 -0500 (EST) Subject: Juniper <-> Cisco IPv6 BGP peering In-Reply-To: <4EDFE865.2040304@packetdam.com> Message-ID: <28bcf7c7-cdf1-4e81-b419-c6807109400f@zimbra.network1.net> BGP is working fine, it is when they are trying to forward the packets back to me. They are seeing the Link-Local as the next-hop, which, for some reason, they cannot get to. -Randy -- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1 ---- ----- Original Message ----- > Randy Carpenter wrote: > > Does anyone have any suggestions on setting up BGP peering between > > Juniper (SRX) and Cisco? > > > > I successfully have cisco-cisco and juniper-juniper without > > problems. > > > > When I am trying to peer to one of my upstreams (who has cisco) > > with my Juniper SRX, They are seeing the link-local address as the > > next-hop, but are unable to get an ND entry for it, and thus > > cannot forward traffic to me. > > > > Any reasons against exchanging v6 prefixes over a v4 session? > > From jeroen at mompl.net Wed Dec 7 16:32:32 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 07 Dec 2011 14:32:32 -0800 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: <20111207041853.GL24540@syn.titan.net> References: <20111205234419.GD1454@vacation.karoshi.com.> <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> <20111207041853.GL24540@syn.titan.net> Message-ID: <4EDFE980.10407@mompl.net> Fyodor wrote: > switched their Nmap downloads back to our real installer. At least > for now. But that isn't enough--they are still infecting the > installers for thousands of other packages! I am sorry about these problems, it is unacceptable. Sourceforge, at least a year or 2 ago, did something that was only slightly less unacceptable. They had (or still have?) ads that would display when you click a donwload link at some site, say http://www.clamwin.com/content/view/18/46/ In this example (and clamwin had no part in that) the redirect of the download link would show an add for another virus scanner (but in fact it was malware, or, so broken it'd behave like malware). I know of actual cases where someone accidentally downloaded the software from the add, and messed up their computer. So much for pointing them to a free virus scanner... -- Earthquake Magnitude: 3.1 Date: Wednesday, December 7, 2011 15:57:44 UTC Location: northern Alaska Latitude: 65.9462; Longitude: -148.7381 Depth: 30.90 km From galu at packetdam.com Wed Dec 7 16:34:51 2011 From: galu at packetdam.com (Vlad Galu) Date: Wed, 07 Dec 2011 22:34:51 +0000 Subject: Juniper <-> Cisco IPv6 BGP peering In-Reply-To: <28bcf7c7-cdf1-4e81-b419-c6807109400f@zimbra.network1.net> References: <28bcf7c7-cdf1-4e81-b419-c6807109400f@zimbra.network1.net> Message-ID: <4EDFEA0B.8040506@packetdam.com> Randy Carpenter wrote: > BGP is working fine, it is when they are trying to forward the packets back to me. They are seeing the Link-Local as the next-hop, which, for some reason, they cannot get to. > > > -Randy Sorry Randy, I'd skimmed through your initial mail too quickly and missed the point. From jbates at brightok.net Wed Dec 7 16:42:33 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 07 Dec 2011 16:42:33 -0600 Subject: Juniper <-> Cisco IPv6 BGP peering In-Reply-To: <28bcf7c7-cdf1-4e81-b419-c6807109400f@zimbra.network1.net> References: <28bcf7c7-cdf1-4e81-b419-c6807109400f@zimbra.network1.net> Message-ID: <4EDFEBD9.7060806@brightok.net> On 12/7/2011 4:30 PM, Randy Carpenter wrote: > > BGP is working fine, it is when they are trying to forward the packets back to me. They are seeing the Link-Local as the next-hop, which, for some reason, they cannot get to. > > Your subject is misleading. It appears to be an NDP problem. Check configs and firewall rules on both sides to make sure NDP isn't being interrupted. I've not seen any NDP compatibility problems between IOS 12.2SR, 12.3T, and Junos 9.3, 9.6, 10.4. However, there are several vendor commands as well as firewall rulesets, which could NDP itself. Jack From bicknell at ufp.org Wed Dec 7 16:50:48 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 7 Dec 2011 14:50:48 -0800 Subject: Juniper <-> Cisco IPv6 BGP peering In-Reply-To: <4EDFEBD9.7060806@brightok.net> References: <28bcf7c7-cdf1-4e81-b419-c6807109400f@zimbra.network1.net> <4EDFEBD9.7060806@brightok.net> <43c838e2-d866-4d4b-ac6c-31b8f90c7246@zimbra.network1.net> Message-ID: <20111207225048.GA8250@ussenterprise.ufp.org> In a message written on Wed, Dec 07, 2011 at 04:54:13PM -0500, Randy Carpenter wrote: > Does anyone have any suggestions on setting up BGP peering between Juniper (SRX) and Cisco? In a message written on Wed, Dec 07, 2011 at 04:42:33PM -0600, Jack Bates wrote: > Your subject is misleading. It appears to be an NDP problem. Check > configs and firewall rules on both sides to make sure NDP isn't being > interrupted. +1, although the original post may have a clue. For those used to M and T series boxes configuring an SRX on the command line you may be surprised to find a security {} top level section with all new never seen before security policies that may, for instance, block NDP. -- 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 jeroen at mompl.net Wed Dec 7 16:52:31 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 07 Dec 2011 14:52:31 -0800 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: <20111207041853.GL24540@syn.titan.net> References: <20111205234419.GD1454@vacation.karoshi.com.> <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> <20111207041853.GL24540@syn.titan.net> Message-ID: <4EDFEE2F.5090803@mompl.net> Fyodor wrote: > switched their Nmap downloads back to our real installer. At least > for now. But that isn't enough--they are still infecting the > installers for thousands of other packages! I am sorry about these problems, it is unacceptable. Sourceforge, at least a year or 2 ago, did something that was only slightly less unacceptable. They had (or still have?) ads that would display when you click a donwload link at some site, say http://www.clamwin.com/content/view/18/46/ In this example (and clamwin had no part in that) the redirect of the download link would show an add for another virus scanner (but in fact it was malware, or, so broken it'd behave like malware). I know of actual cases where someone accidentally downloaded the software from the add, and messed up their computer. So much for pointing them to a free virus scanner... -- Earthquake Magnitude: 3.1 Date: Wednesday, December 7, 2011 15:57:44 UTC Location: northern Alaska Latitude: 65.9462; Longitude: -148.7381 Depth: 30.90 km From peter216 at gmail.com Wed Dec 7 16:49:13 2011 From: peter216 at gmail.com (Peter Rubenstein) Date: Wed, 7 Dec 2011 17:49:13 -0500 Subject: Juniper <-> Cisco IPv6 BGP peering In-Reply-To: References: Message-ID: <-5313560550570988594@unknownmsgid> Try setting local-address in the bgp neighbor config on the Juniper side? --Peter On Dec 7, 2011, at 4:54 PM, Randy Carpenter wrote: > > Does anyone have any suggestions on setting up BGP peering between Juniper (SRX) and Cisco? > > I successfully have cisco-cisco and juniper-juniper without problems. > > When I am trying to peer to one of my upstreams (who has cisco) with my Juniper SRX, They are seeing the link-local address as the next-hop, but are unable to get an ND entry for it, and thus cannot forward traffic to me. > > > -Randy > > -- > | Randy Carpenter > | Vice President - IT Services > | Red Hat Certified Engineer > | First Network Group, Inc. > | (800)578-6381, Opt. 1 > ---- > > From owen at delong.com Wed Dec 7 17:10:33 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 7 Dec 2011 15:10:33 -0800 Subject: Juniper <-> Cisco IPv6 BGP peering In-Reply-To: <4EDFE865.2040304@packetdam.com> References: <4EDFE865.2040304@packetdam.com> Message-ID: <3CBC089D-6B61-405B-BF42-F38E951AF85C@delong.com> On Dec 7, 2011, at 2:27 PM, Vlad Galu wrote: > Randy Carpenter wrote: >> Does anyone have any suggestions on setting up BGP peering between Juniper (SRX) and Cisco? >> >> I successfully have cisco-cisco and juniper-juniper without problems. >> >> When I am trying to peer to one of my upstreams (who has cisco) with my Juniper SRX, They are seeing the link-local address as the next-hop, but are unable to get an ND entry for it, and thus cannot forward traffic to me. >> > > Any reasons against exchanging v6 prefixes over a v4 session? Multiple single points of failure. Complexity of the configuration More difficult to troubleshoot Unnecessary cross-protocol dependencies. Just to name the ones that come to mind instantly. Any reason for it? Owen From jra at baylink.com Wed Dec 7 17:24:53 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 7 Dec 2011 18:24:53 -0500 (EST) Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: Message-ID: <25640550.1899.1323300293410.JavaMail.root@benjamin.baylink.com> Isn't it a little early for Whacky Weekend? ----- Original Message ----- > From: "Dan Collins" > On Tue, Dec 6, 2011 at 4:45 PM, wrote: > > On Tue, 06 Dec 2011 10:30:20 PST, "andrew.wallace" said: > >> It could be argued that Nmap is malware, and such software has > >> already been called to be made illegal. > > > > Called by whom, other than yourself? > > Germany? > > http://www.schneier.com/blog/archives/2007/08/new_german_hack.html Perhaps. But Valdis and you both misinterpreted what Andrew said: he said that "malware" has already been called to be made illegal -- he really only invited you to infer that he was in fact *making* the argument that nmap was indeed malware, and you both bit beautifully. Now PDFTT, people. 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 http://photo.imageinc.us +1 727 647 1274 From rcarpen at network1.net Wed Dec 7 18:53:33 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Wed, 07 Dec 2011 19:53:33 -0500 (EST) Subject: Juniper <-> Cisco IPv6 BGP peering In-Reply-To: <-5313560550570988594@unknownmsgid> References: <-5313560550570988594@unknownmsgid> Message-ID: <8CD46A88-DE73-4C13-B18B-087640C6CAA0@network1.net> Tried that. I agree with others that it is an NDP issue. NDP for the GUA is fine, but just not for the link local. Is there something that would block only link local by default? I should add that I have another uplink to a different provider that works perfectly. The other end is Juniper for that one. -Randy On Dec 7, 2011, at 17:53, Peter Rubenstein wrote: > Try setting local-address in the bgp neighbor config on the Juniper side? > > --Peter > > On Dec 7, 2011, at 4:54 PM, Randy Carpenter wrote: > >> >> Does anyone have any suggestions on setting up BGP peering between Juniper (SRX) and Cisco? >> >> I successfully have cisco-cisco and juniper-juniper without problems. >> >> When I am trying to peer to one of my upstreams (who has cisco) with my Juniper SRX, They are seeing the link-local address as the next-hop, but are unable to get an ND entry for it, and thus cannot forward traffic to me. >> >> >> -Randy >> >> -- >> | Randy Carpenter >> | Vice President - IT Services >> | Red Hat Certified Engineer >> | First Network Group, Inc. >> | (800)578-6381, Opt. 1 >> ---- >> >> > From rdobbins at arbor.net Wed Dec 7 21:03:27 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 8 Dec 2011 03:03:27 +0000 Subject: BGP and Firewalls... In-Reply-To: <1F4D60B00DE5FB42AD4BB2BC06DC3092207092FB@mail.shoremortgage.com> References: <1F4D60B00DE5FB42AD4BB2BC06DC3092207090B9@mail.shoremortgage.com> <1F4D60B00DE5FB42AD4BB2BC06DC3092207092FB@mail.shoremortgage.com> Message-ID: <9113804F-09D0-44D4-8FF5-0564865785FA@arbor.net> On Dec 8, 2011, at 1:04 AM, Gregory Croft wrote: > Just investigating to see if there is a reason I shouldn't use a firewall at the edge versus a dedicated router You should only use a dedicate router if you want your network to remain available. ;> ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From streiner at cluebyfour.org Wed Dec 7 21:35:43 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 7 Dec 2011 22:35:43 -0500 (EST) Subject: Juniper <-> Cisco IPv6 BGP peering In-Reply-To: <8CD46A88-DE73-4C13-B18B-087640C6CAA0@network1.net> References: <-5313560550570988594@unknownmsgid> <8CD46A88-DE73-4C13-B18B-087640C6CAA0@network1.net> Message-ID: On Wed, 7 Dec 2011, Randy Carpenter wrote: > Tried that. I agree with others that it is an NDP issue. NDP for the > GUA is fine, but just not for the link local. Is there something that > would block only link local by default? Do you have any possibly-overly-strict firewall filters applied to the interface on the Juniper box? > I should add that I have another uplink to a different provider that > works perfectly. The other end is Juniper for that one. I have IPv6 BGP sessions, using v6 addresses, up and traffic moving, using Juniper M-series on my end, and various gear on the remote end, including some Cisco devices. Haven't run into any funky NDP-ish issues in the 3 years it's been running. have you opened a case with JTAC? jms From rdobbins at arbor.net Wed Dec 7 21:43:34 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 8 Dec 2011 03:43:34 +0000 Subject: BGP and Firewalls... In-Reply-To: <20111207183653.GA98645@ussenterprise.ufp.org> References: <1F4D60B00DE5FB42AD4BB2BC06DC3092207090B9@mail.shoremortgage.com> <1F4D60B00DE5FB42AD4BB2BC06DC3092207092FB@mail.shoremortgage.com> <922ACC42D498884AA02B3565688AF995340255F8A3@USEXMBS01.mwd.h2o> <20111207183653.GA98645@ussenterprise.ufp.org> Message-ID: On Dec 8, 2011, at 1:36 AM, Leo Bicknell wrote: > I don't think you're looking at defense in depth in the right way, Actually, it sometimes seems as if nobody in the industry understands what 'defense in depth' really means, heh. 'Defense in depth' is a military term of art which equates to 'trading space for time in order to facilitate attrition of enemy forces'. It does not have any real relevance to infosec/opsec; unfortunately, its original meaning has been corrupted and so it is widely (and incorrectly) used in place of the more appropriate 'combined arms approach' or 'jointness' or 'mutual support' or 'layered defense' metaphors. Hannibal's tactics at Cannae are generally cited as the canonical (pardon the pun) example of actual military defense in depth. ;> ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From cb.list6 at gmail.com Wed Dec 7 22:13:12 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Wed, 7 Dec 2011 20:13:12 -0800 Subject: BGP and Firewalls... In-Reply-To: References: <1F4D60B00DE5FB42AD4BB2BC06DC3092207090B9@mail.shoremortgage.com> <1F4D60B00DE5FB42AD4BB2BC06DC3092207092FB@mail.shoremortgage.com> <922ACC42D498884AA02B3565688AF995340255F8A3@USEXMBS01.mwd.h2o> <20111207183653.GA98645@ussenterprise.ufp.org> Message-ID: On Dec 7, 2011 7:49 PM, "Dobbins, Roland" wrote: > > > On Dec 8, 2011, at 1:36 AM, Leo Bicknell wrote: > > > I don't think you're looking at defense in depth in the right way, > > Actually, it sometimes seems as if nobody in the industry understands what 'defense in depth' really means, heh. > On a personal note , it is one of my least favorite terms because it is overused and generally used by people selling things, and defense in depth means throw eveything and the kitchen sink at the problem instead of matching threats / risks / vulnerabilities with security controls and threat mitigation and management. Defense in depth = blank check , in too many instances Yes, layers of security are good. No, a car with mattresses strapped to both ends is not safer to drive. Cb > 'Defense in depth' is a military term of art which equates to 'trading space for time in order to facilitate attrition of enemy forces'. It does not have any real relevance to infosec/opsec; unfortunately, its original meaning has been corrupted and so it is widely (and incorrectly) used in place of the more appropriate 'combined arms approach' or 'jointness' or 'mutual support' or 'layered defense' metaphors. Hannibal's tactics at Cannae are generally cited as the canonical (pardon the pun) example of actual military defense in depth. > > ;> > > ----------------------------------------------------------------------- > Roland Dobbins // > > The basis of optimism is sheer terror. > > -- Oscar Wilde > > From streiner at cluebyfour.org Wed Dec 7 22:50:43 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 7 Dec 2011 23:50:43 -0500 (EST) Subject: BGP and Firewalls... In-Reply-To: References: <1F4D60B00DE5FB42AD4BB2BC06DC3092207090B9@mail.shoremortgage.com> <1F4D60B00DE5FB42AD4BB2BC06DC3092207092FB@mail.shoremortgage.com> <922ACC42D498884AA02B3565688AF995340255F8A3@USEXMBS01.mwd.h2o> <20111207183653.GA98645@ussenterprise.ufp.org> Message-ID: On Wed, 7 Dec 2011, Cameron Byrne wrote: > On a personal note , it is one of my least favorite terms because it is > overused and generally used by people selling things, and defense in depth > means throw eveything and the kitchen sink at the problem instead of > matching threats / risks / vulnerabilities with security controls and > threat mitigation and management. It's something that is used all too often as a handy verbal crutch in sales pitches. I'm wondering how long it is before the text below is lifted verbatim and put into some vendors' sales/marketing materials. "Our security products are truly best-of-breed - we take defense in depth to a whole new level that none of our competitors can match. We have the breadth and depth of knowledge and a proven track record in the security space to exceed our customers' expectations and deliver the optimum user experience. We can leverage the synergies and cohesion that exist across our product line to tailor a set of deliverables to meet virtually any need." *ducks* ;) jms From mtinka at globaltransit.net Wed Dec 7 22:55:52 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Thu, 8 Dec 2011 12:55:52 +0800 Subject: GPON Vendors In-Reply-To: <01cf01ccb513$e3f54590$abdfd0b0$@iname.com> References: <201112071646.02408.mtinka@globaltransit.net> <01cf01ccb513$e3f54590$abdfd0b0$@iname.com> Message-ID: <201112081255.58300.mtinka@globaltransit.net> On Thursday, December 08, 2011 03:10:31 AM Frank Bulk wrote: > In late August Calix came to our site and tested their > IPv6 support on the C7 platform for their upcoming 8.0 > release. They tested both on GPON and VDSL2 using the > N:1 (VLAN per service) approach. There were some issues > that prevented all the CPE I had from working, but since > then they've taken it back and completed that work. > I've invited them back onsite to re-test so we can > validate before they begin their controlled release. Sounds great. Keep us posted as they develop the software. It would be interesting to see what issues arise in this area. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From jtowne at slic.com Wed Dec 7 22:58:03 2011 From: jtowne at slic.com (Jonathan Towne) Date: Wed, 7 Dec 2011 23:58:03 -0500 Subject: GPON Vendors In-Reply-To: <201112081255.58300.mtinka@globaltransit.net> References: <201112071646.02408.mtinka@globaltransit.net> <01cf01ccb513$e3f54590$abdfd0b0$@iname.com> <201112081255.58300.mtinka@globaltransit.net> Message-ID: <20111208045801.GB13315@hijacked.us> Indeed, I'm very interested in the outcome of this, as well. I've been pestering my Calix SE for a long while about proper IPv6 support. -- Jonathan Towne On Thu, Dec 08, 2011 at 12:55:52PM +0800, Mark Tinka scribbled: # On Thursday, December 08, 2011 03:10:31 AM Frank Bulk wrote: # # > In late August Calix came to our site and tested their # > IPv6 support on the C7 platform for their upcoming 8.0 # > release. They tested both on GPON and VDSL2 using the # > N:1 (VLAN per service) approach. There were some issues # > that prevented all the CPE I had from working, but since # > then they've taken it back and completed that work. # > I've invited them back onsite to re-test so we can # > validate before they begin their controlled release. # # Sounds great. # # Keep us posted as they develop the software. It would be # interesting to see what issues arise in this area. # # Mark. From jbates at brightok.net Thu Dec 8 00:42:26 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 08 Dec 2011 00:42:26 -0600 Subject: Juniper <-> Cisco IPv6 BGP peering In-Reply-To: <8CD46A88-DE73-4C13-B18B-087640C6CAA0@network1.net> References: <-5313560550570988594@unknownmsgid> <8CD46A88-DE73-4C13-B18B-087640C6CAA0@network1.net> Message-ID: <4EE05C52.7020607@brightok.net> On 12/7/2011 6:53 PM, Randy Carpenter wrote: > Tried that. I agree with others that it is an NDP issue. NDP for the GUA is fine, but just not for the link local. Is there something that would block only link local by default? > > I should add that I have another uplink to a different provider that works perfectly. The other end is Juniper for that one. > Might check the cisco provider to see if they have something weird on your interface filtering/config. port mirroring ndp traffic or running ndp tracing flags might provide you with more clues. You also mentioned success with cisco to cisco, but you were unclear if that was with the same cisco provider you are having problems with. Another possibility for a workaround or additional testing is them placing a manual neighbor entry into the cisco. I've never tried it with a link-local, though. Jack From Skeeve at eintellego.net Thu Dec 8 01:29:37 2011 From: Skeeve at eintellego.net (Skeeve Stevens) Date: Thu, 8 Dec 2011 07:29:37 +0000 Subject: Juniper MX80 Virtual Chassis Message-ID: Hey all, Thought I'd ask here to see if anyone has heard. In May 2010 Juniper announced that Virtual Chassis would be available in the MX80 platform in the second half of 2011. Anyone know if it is still being planned for release or if its been removed from the platform features? ?Skeeve -- Skeeve Stevens, CEO - eintellego Pty Ltd skeeve at eintellego.net ; www.eintellego.net Phone: 1300 753 383 ; Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellego twitter.com/networkceoau ; www.linkedin.com/in/skeeve PO Box 7726, Baulkham Hills, NSW 1755 Australia -- eintellego - The Experts Who The Experts Call Juniper - HP Networking - Cisco - Brocade From vicky at geeks.net.np Thu Dec 8 01:47:22 2011 From: vicky at geeks.net.np (Vicky Shrestha) Date: Wed, 7 Dec 2011 23:47:22 -0800 Subject: Juniper <-> Cisco IPv6 BGP peering In-Reply-To: <8CD46A88-DE73-4C13-B18B-087640C6CAA0@network1.net> References: <-5313560550570988594@unknownmsgid> <8CD46A88-DE73-4C13-B18B-087640C6CAA0@network1.net> Message-ID: <7E5ED5CC-121A-45F4-8315-47EB79703F2F@geeks.net.np> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Dec 7, 2011, at 4:53 PM, Randy Carpenter wrote: > Tried that. I agree with others that it is an NDP issue. NDP for the GUA is fine, but just not for the link local. Is there something that would block only link local by default? We faced a problem with Cisco routers where it will have partial reachability over IPv6, in the same LAN. Looking further, We found that it was having problem with Neighbor solicitations. The solution then was to remove the IPv6 configs from the interface and putting them back. This problem was quite unpredictable and we were unable to reproduce. > I should add that I have another uplink to a different provider that works perfectly. The other end is Juniper for that one. > > -Randy > > On Dec 7, 2011, at 17:53, Peter Rubenstein wrote: > >> Try setting local-address in the bgp neighbor config on the Juniper side? >> >> --Peter >> >> On Dec 7, 2011, at 4:54 PM, Randy Carpenter wrote: >> >>> >>> Does anyone have any suggestions on setting up BGP peering between Juniper (SRX) and Cisco? >>> >>> I successfully have cisco-cisco and juniper-juniper without problems. >>> >>> When I am trying to peer to one of my upstreams (who has cisco) with my Juniper SRX, They are seeing the link-local address as the next-hop, but are unable to get an ND entry for it, and thus cannot forward traffic to me. >>> >>> >>> -Randy >>> >>> -- >>> | Randy Carpenter >>> | Vice President - IT Services >>> | Red Hat Certified Engineer >>> | First Network Group, Inc. >>> | (800)578-6381, Opt. 1 >>> ---- >>> >>> >> > Regards, Vicky Shrestha -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iQEcBAEBAgAGBQJO4GuKAAoJEGi4SIJCvhMLpjYIAIhTUjsmoy9TSqKayfITZFJZ DtDaNq+l/GUxmfUecsacbmEQmS0iXbj66Lm400JvKsO9hPjUbpN73jJM/GqT45Gl DWF6+jqVfC+Nes/FUylS0kcWxWDjehETpfo3IO3kuA5hJQ0ELHyiVU1ReHwtCkoV Zy4HHP0spfO4g6KORZqEtHa6tM13QGZg7CLOCHaUJi8IVl3quCnrn/oUyjcl1PFI dNwlY1pr22ArA4TgKzKUimUNNxLhjld+UsIdAdyf7xN3HN9Ki6gqsnXiuAqFWPqW E2lA4ViKwOHwyaE82iSAGl9A9qcrPJd7lCVGbiP9aW9Y2ZcS4kVEZkc3gXPkiAg= =253w -----END PGP SIGNATURE----- From jeroen at mompl.net Thu Dec 8 03:32:06 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Thu, 08 Dec 2011 01:32:06 -0800 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: <20111207041853.GL24540@syn.titan.net> References: <20111205234419.GD1454@vacation.karoshi.com.> <1323152088.99127.YahooMailNeo@web162109.mail.bf1.yahoo.com> <20111207041853.GL24540@syn.titan.net> Message-ID: <4EE08416.3020702@mompl.net> Fyodor wrote: > switched their Nmap downloads back to our real installer. At least > for now. But that isn't enough--they are still infecting the > installers for thousands of other packages! I am sorry about these problems, it is unacceptable. Sourceforge, at least a year or 2 ago, did something that was only slightly less unacceptable. They had (or still have?) ads that would display when you click a donwload link at some site, say http://www.clamwin.com/content/view/18/46/ In this example (and clamwin had no part in that) the redirect of the download link would show an add for another virus scanner (but in fact it was malware, or, so broken it'd behave like malware). I know of actual cases where someone accidentally downloaded the software from the add, and messed up their computer. So much for pointing them to a free virus scanner... -- Earthquake Magnitude: 3.1 Date: Wednesday, December 7, 2011 15:57:44 UTC Location: northern Alaska Latitude: 65.9462; Longitude: -148.7381 Depth: 30.90 km From bhmccie at gmail.com Thu Dec 8 08:24:29 2011 From: bhmccie at gmail.com (-Hammer-) Date: Thu, 08 Dec 2011 08:24:29 -0600 Subject: BGP and Firewalls... In-Reply-To: References: <1F4D60B00DE5FB42AD4BB2BC06DC3092207090B9@mail.shoremortgage.com> <1F4D60B00DE5FB42AD4BB2BC06DC3092207092FB@mail.shoremortgage.com> <922ACC42D498884AA02B3565688AF995340255F8A3@USEXMBS01.mwd.h2o> <20111207183653.GA98645@ussenterprise.ufp.org> Message-ID: <4EE0C89D.3040400@gmail.com> Roland, While I understand that the definition has nothing to do with IT Security there is no question that many folks use the phrase to summarize a layered IT security model. Edge routers with ACLs to filter white noise go to edge L3/4 firewalls to filter their layer go to load balancers to terminate SSL (not really security I know) which go to L7 firewalls to inspect HTTP just to get to the web server. Then you have the whole layered DMZs for the WEBs/APPs/DBs/inside etc. We employ "defense in depth" and everyone is familiar with the concept even if they are using the phrase incorrectly. And our wonderful federal auditors expect it and call it the same thing. -Hammer- "I was a normal American nerd" -Jack Herer On 12/07/2011 09:43 PM, Dobbins, Roland wrote: > On Dec 8, 2011, at 1:36 AM, Leo Bicknell wrote: > > >> I don't think you're looking at defense in depth in the right way, >> > Actually, it sometimes seems as if nobody in the industry understands what 'defense in depth' really means, heh. > > 'Defense in depth' is a military term of art which equates to 'trading space for time in order to facilitate attrition of enemy forces'. It does not have any real relevance to infosec/opsec; unfortunately, its original meaning has been corrupted and so it is widely (and incorrectly) used in place of the more appropriate 'combined arms approach' or 'jointness' or 'mutual support' or 'layered defense' metaphors. Hannibal's tactics at Cannae are generally cited as the canonical (pardon the pun) example of actual military defense in depth. > > ;> > > ----------------------------------------------------------------------- > Roland Dobbins // > > The basis of optimism is sheer terror. > > -- Oscar Wilde > > > From david at davidswafford.com Thu Dec 8 08:49:36 2011 From: david at davidswafford.com (David) Date: Thu, 8 Dec 2011 09:49:36 -0500 Subject: BGP and Firewalls... In-Reply-To: <1F4D60B00DE5FB42AD4BB2BC06DC3092207090B9@mail.shoremortgage.com> References: <1F4D60B00DE5FB42AD4BB2BC06DC3092207090B9@mail.shoremortgage.com> Message-ID: <76238EAE-2B76-41A1-9AB8-90A66DFB66CE@davidswafford.com> I wouldn't do it. We have 8 x PA-2050s and run into a lot of wierd bugs.... (just doing web filtering) David Sent from an email server. On Dec 7, 2011, at 12:31 PM, "Gregory Croft" wrote: > Hi All, > > > > Does anyone have any experience with using firewalls as edge devices > when BGP is concerned? > > Specifically the Palo Alto series of devices. > > > > If so please contact me off list. > > > > Thank you. > > > > > > Thank you, > > Gregory S. Croft > > > > > From righa.shake at gmail.com Thu Dec 8 09:02:00 2011 From: righa.shake at gmail.com (Righa Shake) Date: Thu, 8 Dec 2011 18:02:00 +0300 Subject: Flapping POS Interface on Frame-relay between a Juniper and Cisco In-Reply-To: <4EDE8678.4070507@emanon.com> References: <20111206130539.2DBEED9@resin04.mta.everyone.net> <4EDE8678.4070507@emanon.com> Message-ID: The interface finally stabalised. This after performing segment by segment loop tests at SDH level. We found errors which were sorted after which the service has been better the random flaps have since disappeared. Now dealing with random BGP cease notifications I receive from my upstream. Thank you all for your assistance in helping solve this. Regards, Righa Shake On Wed, Dec 7, 2011 at 12:17 AM, Scott Morris wrote: > The mismatch problem of DCE/DTE should definitely indicate that your > PVCs aren't up. But that shouldn't result in the high quantity of CRC > errors in the interface counters. That should just result in your LMI > enquiry count increasing with LMI response sitting at zero. > > I have to say I've never tried running frame-relay on a SONET > interface. And if you're only using a single PVC there, I'd certainly > love to know WHY you're doing that! :) > > But setting one side to DCE so that it'll respond to LMI will certainly > make the frame-relay (L2) portion of things operate properly. But if > you have something else occurring causing the CRCs along the way, then > that's not really going to help at all! > > Did anything else coincide with you changing the encapsulation? > > Scott > > > > On 12/6/11 4:05 PM, Scott Weeks wrote: > > Did Jeff's suggestion work? > > > > : interface POS0/0/0 > > : frame-relay intf-type dce > > > > If so, please let the list know, so when someone comes > > across this thread while searching for the fix they can > > figure it out without having to email the list. If it > > didn't help contact me off-line and I will be happy to > > troubleshoot it with you. > > > > scott > > > > > > > > > > > > ________________________________________ > > From: Righa Shake [righa.shake at gmail.com] > > Sent: Saturday, November 19, 2011 11:11 AM > > To: afnog at afnog.org > > Subject: Flapping POS Interface on Frame-relay between a Juniper and > Cisco > > > > Hi, > > > > Am having a problem that is buffling. > > > > I recently changed a POS link encapsulation from PPP to Frame-relay. > > Since that time the POS interface keeps resetting from time to time. > > > > On my BGP session am receiving cease notifications from my upstream > > provider. > > > > The setup is such that we have a cisco on one end and a Juniper on the > > other. > > > > interface POS0/0/0 > > mtu 4474 > > no ip address > > no ip unreachables > > encapsulation frame-relay > > logging event link-status > > crc 32 > > pos scramble-atm > > frame-relay lmi-type ansi > > end > > > > ROUTERshow run int pos0/0/0.101 > > Building configuration... > > > > > > ! > > interface POS0/0/0.101 point-to-point > > ip address X.X.X.X 255.255.255.252 > > frame-relay interface-dlci 101 > > end > > > > ROUTER#show int pos0/0/0 > > POS0/0/0 is up, line protocol is up > > Hardware is SPA-2XOC12-POS > > MTU 4474 bytes, BW 622000 Kbit/sec, DLY 100 usec, > > reliability 255/255, txload 6/255, rxload 38/255 > > Encapsulation FRAME-RELAY, crc 32, loopback not set > > Keepalive set (10 sec) > > Scramble enabled > > LMI enq sent 81981, LMI stat recvd 77480, LMI upd recvd 0, DTE LMI up > > LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 > > LMI DLCI 0 LMI type is ANSI Annex D frame relay DTE segmentation > > inactive > > FR SVC disabled, LAPF state down > > Broadcast queue 0/256, broadcasts sent/dropped 26/0, interface > broadcasts > > 0 > > Last input 00:00:00, output 00:00:00, output hang never > > Last clearing of "show interface" counters 1w2d > > Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0 > > Queueing strategy: fifo > > Output queue: 0/40 (size/max) > > 5 minute input rate 94336000 bits/sec, 13151 packets/sec > > 5 minute output rate 16470000 bits/sec, 7049 packets/sec > > 12211574207 packets input, 10967607038364 bytes, 0 no buffer > > Received 0 broadcasts (0 IP multicasts) > > 6970870 runts, 2179 giants, 0 throttles > > 0 parity > > 892493293 input errors, 882184781 CRC, 0 frame, 0 overrun, 0 > ignored, > > 3335463 abort > > 6379191154 packets output, 1614018181446 bytes, 0 underruns > > 0 output errors, 0 applique, 4 interface resets > > 0 unknown protocol drops > > 0 output buffer failures, 0 output buffers swapped out > > 0 carrier transitions > > > > > > Any assistance on this will be greatly appreciated. > > > > > > > > > > > > > > --- jsaxe at briworks.com wrote: > > > > From: Jeff Saxe > > > > I believe this is the explanation for your flapping: a PPP link is > intended to go between two routers over, for instance, a private leased > line, so both of the devices are peers, neither one particularly special. > Frame-relay, by contrast, was originally designed so that your router was > an "end user" device and its directly-connected partner device was not your > other router, which you control, but the frame carrier's frame-relay > switch. Your router was a DTE device, and their switch, which was in a more > "important" position in control of the frame-relay NBMA cloud, was the DCE > device. Your router then slaved to the frame switch via LMI signaling, so > that the upstream switch instructed you which DLCIs existed and were up at > the moment. > > > > So if you connect up two routers with frame-relay encap and each thinks > it is the DTE, and neither one is taking the role of the frame switch, then > when you bring them up, they will initially optimistically think their > DLCIs are up and working, and the routing protocol and traffic will come > up... but both of them will be waiting for the frame switch to send them > LMI indicating that their idea of the DLCI up/down status is correct. When > a couple minutes go by and they don't hear the responses to their LMI > enquiries, they will bring all the DLCI's down. I thought they would then > stay down forever, i.e., not flap, but maybe you are shutting / no shutting > the POS circuit to try again. Anyway, I believe the very simple fix is > > > > interface POS0/0/0 > > frame-relay intf-type dce > > > > So this will turn your Cisco side of the circuit into "DCE" mode, and if > the Juniper side stays in "DTE" mode (the default, so probably not listed > in the config), then the LMI should start behaving between the two. And > yes, as Jay Hennigan suggested, you might need to use "encap frame-relay > ietf" to be compatible with non-Cisco gear, or you might need to adjust the > frame-relay lmi-type -- one type sends the LMI on DLCI number 0, one of > them on DLCI 1023, whatever. I think you'll need to adjust the two ends > until you see LMI enquiries both sent and received; right now the "show > interface" from the Cisco side shows it has not received any LMI enq yet. > > > > > > Good luck, and I hope it's that simple. :-) > > > > > > > > > From betty at newnog.org Thu Dec 8 12:44:58 2011 From: betty at newnog.org (Betty Burke ) Date: Thu, 8 Dec 2011 13:44:58 -0500 Subject: [NANOG-announce] NANOG 54 Hotel Update Message-ID: Dear NANOG Community, On behalf of the Board of Directors, I am happy to share some wonderful news regarding hotel accommodations for our NANOG 54 meeting in San Diego. The hotel has been undergoing renovations and recently completed remodeling of all its guest rooms and meeting space. The last phase of the hotel remodel will include the main lobby, which they plan to complete before our meeting. The Board has been working closely with the hotel to ensure the remodel will have no effect on NANOG 54, scheduled for February 5 - 8, 2012. As a result of our conversations, the hotel has agreed to reduce the individual guest room rate from $199 +tax/ night to $169 + tax/night. For reservations already made, the hotel will make an adjustment to your daily rate, reflecting the new NANOG 54 rate. In addition, if you make your reservation by January 4th, 2012, you will be entered into a drawing to win 10,000 Starwood Preferred Guest points! For your reference, below please find a copy of the original letter from the hotel. We look forward to seeing you all in San Diego! Sincerely, Betty Burke, Executive Director Greetings from San Diego! We are looking forward to welcoming you to America?s Finest City for the NANOG Annual Meeting in February 2012. Over the last year, The Westin Gaslamp Quarter has completed a refresh of our guest rooms, meeting space and WestinWORKOUT?, and we are in the final phase of our lobby renovation. To celebrate and to help manage your travel expense, we are happy to offer a discounted conference rate of $169 plus tax (originally $199!) For any reservations that have already been made, we will reduce your confirmed rate for you. Early Bird Special: If you make your reservation by January 4, 2012, you will be entered into a drawing to win 10,000 Starwood Preferred Guest points! Be well, Keri Robinson General Manager -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From bogus@does.not.exist.com Wed Dec 7 16:23:30 2011 From: bogus@does.not.exist.com () Date: Wed, 07 Dec 2011 22:23:30 -0000 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] Message-ID: Fyodor wrote: > switched their Nmap downloads back to our real installer. At least > for now. But that isn't enough--they are still infecting the > installers for thousands of other packages! I am sorry about these problems, it is unacceptable. Sourceforge, at least a year or 2 ago, did something that was only slightly less unacceptable. They had (or still have?) ads that would display when you click a donwload link at some site, say http://www.clamwin.com/content/view/18/46/ In this example (and clamwin had no part in that) the redirect of the download link would show an add for another virus scanner (but in fact it was malware, or, so broken it'd behave like malware). I know of actual cases where someone accidentally downloaded the software from the add, and messed up their computer. So much for pointing them to a free virus scanner... -- Earthquake Magnitude: 3.1 Date: Wednesday, December 7, 2011 15:57:44 UTC Location: northern Alaska Latitude: 65.9462; Longitude: -148.7381 Depth: 30.90 km From tayeb.meftah at gmail.com Wed Dec 7 13:12:42 2011 From: tayeb.meftah at gmail.com (Meftah Tayeb) Date: Wed, 7 Dec 2011 21:12:42 +0200 Subject: Traceroute explanation Message-ID: <1FA371D2FA554B7C9D99157E3AA7E8D4@work> Hey folks, i see a strange traceroute there D?termination de l'itin?raire vers www.rri.ro [193.231.72.52] avec un maximum de 30 sauts : 1 2 ms 1 ms 1 ms 172.28.0.1 2 1 ms 1 ms 1 ms localhost [10.16.0.2] 3 10 ms 10 ms 13 ms 41.200.16.1 4 11 ms 10 ms 11 ms 172.17.2.25 5 21 ms 21 ms 21 ms 213.140.58.10 6 34 ms 31 ms 55 ms pos14-0.palermo9.pal.seabone.net [195.22.197.125 ] 7 34 ms 33 ms 35 ms ae-5-6.bar2.marseille1.level3.net [4.69.151.13] 8 106 ms 68 ms 67 ms xe-1-1-0.mil10.ip4.tinet.net [213.200.68.61] 9 74 ms 73 ms 74 ms ae-1-12.bar1.budapest1.level3.net [4.69.141.249] 10 63 ms 63 ms 79 ms euroweb-gw.ip4.tinet.net [77.67.66.154] 11 85 ms 84 ms 84 ms v15-core1.stsisp.ro [193.151.28.1] 12 100 ms 100 ms 102 ms inet-crli1.qrli1.buh.ew.ro [81.24.28.226] 13 81 ms 81 ms 81 ms 193.231.72.10 14 92 ms 92 ms 93 ms ip4-89-238-225-90.euroweb.ro [89.238.225.90] 15 89 ms 89 ms 89 ms webrri.rri.ro.72.231.193.in-addr.arpa [193.231.7 2.52] Itin?raire d?termin?. C:\Documents and Settings\TAYEB> Seabone, then level3, then Tinet, then level3, then tinet ? if is that a routing stufs that i don't know, please let me know :) i never saw that befaure Meftah Tayeb IT Consulting http://www.tmvoip.com/ phone: +21321656139 Mobile: +213660347746 __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From ristic.sasa at gmail.com Thu Dec 8 14:58:44 2011 From: ristic.sasa at gmail.com (Sasa Ristic) Date: Thu, 8 Dec 2011 21:58:44 +0100 Subject: Traceroute explanation In-Reply-To: <1FA371D2FA554B7C9D99157E3AA7E8D4@work> References: <1FA371D2FA554B7C9D99157E3AA7E8D4@work> Message-ID: Hi, nothing surprises me from Tinet any more... at one time all my traffic from Europe was routed through some Hong Kong router of theirs... but, enough jokes... this could be the path the packets are traversing through, nothing wrong with it, as long as everything is working fine... ie. packet gets delivered to destination, and reply comes back, within reasonable time frame... not like traveling across the globe... :) Regards, On Wed, Dec 7, 2011 at 20:12, Meftah Tayeb wrote: > Hey folks, > i see a strange traceroute there > > D?termination de l'itin?raire vers www.rri.ro [193.231.72.52] > avec un maximum de 30 sauts : > > ?1 ? ? 2 ms ? ? 1 ms ? ? 1 ms ?172.28.0.1 > ?2 ? ? 1 ms ? ? 1 ms ? ? 1 ms ?localhost [10.16.0.2] > ?3 ? ?10 ms ? ?10 ms ? ?13 ms ?41.200.16.1 > ?4 ? ?11 ms ? ?10 ms ? ?11 ms ?172.17.2.25 > ?5 ? ?21 ms ? ?21 ms ? ?21 ms ?213.140.58.10 > ?6 ? ?34 ms ? ?31 ms ? ?55 ms ?pos14-0.palermo9.pal.seabone.net [195.22.197.125 > ] > ?7 ? ?34 ms ? ?33 ms ? ?35 ms ?ae-5-6.bar2.marseille1.level3.net [4.69.151.13] > ?8 ? 106 ms ? ?68 ms ? ?67 ms ?xe-1-1-0.mil10.ip4.tinet.net [213.200.68.61] > ?9 ? ?74 ms ? ?73 ms ? ?74 ms ?ae-1-12.bar1.budapest1.level3.net [4.69.141.249] > ?10 ? ?63 ms ? ?63 ms ? ?79 ms ?euroweb-gw.ip4.tinet.net [77.67.66.154] > ?11 ? ?85 ms ? ?84 ms ? ?84 ms ?v15-core1.stsisp.ro [193.151.28.1] > ?12 ? 100 ms ? 100 ms ? 102 ms ?inet-crli1.qrli1.buh.ew.ro [81.24.28.226] > ?13 ? ?81 ms ? ?81 ms ? ?81 ms ?193.231.72.10 > ?14 ? ?92 ms ? ?92 ms ? ?93 ms ?ip4-89-238-225-90.euroweb.ro [89.238.225.90] > ?15 ? ?89 ms ? ?89 ms ? ?89 ms ?webrri.rri.ro.72.231.193.in-addr.arpa [193.231.7 > 2.52] > Itin?raire d?termin?. > C:\Documents and Settings\TAYEB> > Seabone, then level3, then Tinet, then level3, then tinet ? > if is that a routing stufs that i don't know, please let me know :) > i never saw that befaure > > ? ?Meftah Tayeb > IT Consulting > http://www.tmvoip.com/ > phone: +21321656139 > Mobile: +213660347746 > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > -- ricky From tayeb.meftah at gmail.com Wed Dec 7 13:28:29 2011 From: tayeb.meftah at gmail.com (Meftah Tayeb) Date: Wed, 7 Dec 2011 21:28:29 +0200 Subject: Traceroute explanation References: <1FA371D2FA554B7C9D99157E3AA7E8D4@work> Message-ID: <2FD6D432C9294AC48791EA12083DA975@work> yeah, i'm ok with you for that but the hell surprise is that i am going to telecom italia that i realy don't like anymore, Level3 aguin, then tinet, then level3, then tinet ? that strange. ----- Original Message ----- From: "Sasa Ristic" To: Sent: Thursday, December 08, 2011 10:58 PM Subject: Re: Traceroute explanation Hi, nothing surprises me from Tinet any more... at one time all my traffic from Europe was routed through some Hong Kong router of theirs... but, enough jokes... this could be the path the packets are traversing through, nothing wrong with it, as long as everything is working fine... ie. packet gets delivered to destination, and reply comes back, within reasonable time frame... not like traveling across the globe... :) Regards, On Wed, Dec 7, 2011 at 20:12, Meftah Tayeb wrote: > Hey folks, > i see a strange traceroute there > > D?termination de l'itin?raire vers www.rri.ro [193.231.72.52] > avec un maximum de 30 sauts : > > 1 2 ms 1 ms 1 ms 172.28.0.1 > 2 1 ms 1 ms 1 ms localhost [10.16.0.2] > 3 10 ms 10 ms 13 ms 41.200.16.1 > 4 11 ms 10 ms 11 ms 172.17.2.25 > 5 21 ms 21 ms 21 ms 213.140.58.10 > 6 34 ms 31 ms 55 ms pos14-0.palermo9.pal.seabone.net [195.22.197.125 > ] > 7 34 ms 33 ms 35 ms ae-5-6.bar2.marseille1.level3.net [4.69.151.13] > 8 106 ms 68 ms 67 ms xe-1-1-0.mil10.ip4.tinet.net [213.200.68.61] > 9 74 ms 73 ms 74 ms ae-1-12.bar1.budapest1.level3.net [4.69.141.249] > 10 63 ms 63 ms 79 ms euroweb-gw.ip4.tinet.net [77.67.66.154] > 11 85 ms 84 ms 84 ms v15-core1.stsisp.ro [193.151.28.1] > 12 100 ms 100 ms 102 ms inet-crli1.qrli1.buh.ew.ro [81.24.28.226] > 13 81 ms 81 ms 81 ms 193.231.72.10 > 14 92 ms 92 ms 93 ms ip4-89-238-225-90.euroweb.ro [89.238.225.90] > 15 89 ms 89 ms 89 ms webrri.rri.ro.72.231.193.in-addr.arpa [193.231.7 > 2.52] > Itin?raire d?termin?. > C:\Documents and Settings\TAYEB> > Seabone, then level3, then Tinet, then level3, then tinet ? > if is that a routing stufs that i don't know, please let me know :) > i never saw that befaure > > Meftah Tayeb > IT Consulting > http://www.tmvoip.com/ > phone: +21321656139 > Mobile: +213660347746 > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 6695 (20111208) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > -- ricky __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From fred at cisco.com Thu Dec 8 15:23:43 2011 From: fred at cisco.com (Fred Baker) Date: Thu, 8 Dec 2011 14:23:43 -0700 Subject: Traceroute explanation In-Reply-To: <1FA371D2FA554B7C9D99157E3AA7E8D4@work> References: <1FA371D2FA554B7C9D99157E3AA7E8D4@work> Message-ID: This is just a guess, but I'll bet the route changed while you were measuring it. Traceroute sends a request, awaits a response, sends a request, ... Suppose that the route was 172.28.0.1 -> 10.16.0.2 -> 41.200.16.1 -> 172.17.2.25 -> 213.140.58.10 -> 195.22.195.125 -> 4.69.151.13 -> 213.200.68.61 -> somewhere else and after the test got that far, two systems got inserted into the path before level3, resulting in the route entering level3 at a different point, 4.69.141.249. What you now have is 172.28.0.1 -> 10.16.0.2 -> 41.200.16.1 -> 172.17.2.25 -> 213.140.58.10 -> 195.22.195.125 -> unknown -> unknown -> 4.69.141.249 -> 77.67.66.154 -> and so on The effect would be to get a result like this. Next time you see something like this, suggestion: repeat the traceroute and see what you get. On Dec 7, 2011, at 12:12 PM, Meftah Tayeb wrote: > Hey folks, > i see a strange traceroute there > > D?termination de l'itin?raire vers www.rri.ro [193.231.72.52] > avec un maximum de 30 sauts : > > 1 2 ms 1 ms 1 ms 172.28.0.1 > 2 1 ms 1 ms 1 ms localhost [10.16.0.2] > 3 10 ms 10 ms 13 ms 41.200.16.1 > 4 11 ms 10 ms 11 ms 172.17.2.25 > 5 21 ms 21 ms 21 ms 213.140.58.10 > 6 34 ms 31 ms 55 ms pos14-0.palermo9.pal.seabone.net [195.22.197.125 > ] > 7 34 ms 33 ms 35 ms ae-5-6.bar2.marseille1.level3.net [4.69.151.13] > 8 106 ms 68 ms 67 ms xe-1-1-0.mil10.ip4.tinet.net [213.200.68.61] > 9 74 ms 73 ms 74 ms ae-1-12.bar1.budapest1.level3.net [4.69.141.249] > 10 63 ms 63 ms 79 ms euroweb-gw.ip4.tinet.net [77.67.66.154] > 11 85 ms 84 ms 84 ms v15-core1.stsisp.ro [193.151.28.1] > 12 100 ms 100 ms 102 ms inet-crli1.qrli1.buh.ew.ro [81.24.28.226] > 13 81 ms 81 ms 81 ms 193.231.72.10 > 14 92 ms 92 ms 93 ms ip4-89-238-225-90.euroweb.ro [89.238.225.90] > 15 89 ms 89 ms 89 ms webrri.rri.ro.72.231.193.in-addr.arpa [193.231.7 > 2.52] > Itin?raire d?termin?. > C:\Documents and Settings\TAYEB> > Seabone, then level3, then Tinet, then level3, then tinet ? > if is that a routing stufs that i don't know, please let me know :) > i never saw that befaure > > Meftah Tayeb > IT Consulting > http://www.tmvoip.com/ > phone: +21321656139 > Mobile: +213660347746 > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > From tayeb.meftah at gmail.com Wed Dec 7 13:51:08 2011 From: tayeb.meftah at gmail.com (Meftah Tayeb) Date: Wed, 7 Dec 2011 21:51:08 +0200 Subject: Traceroute explanation References: <1FA371D2FA554B7C9D99157E3AA7E8D4@work> Message-ID: big thank for that but, i am testing that for one day :) ----- Original Message ----- From: "Fred Baker" To: "Meftah Tayeb" Cc: Sent: Thursday, December 08, 2011 11:23 PM Subject: Re: Traceroute explanation This is just a guess, but I'll bet the route changed while you were measuring it. Traceroute sends a request, awaits a response, sends a request, ... Suppose that the route was 172.28.0.1 -> 10.16.0.2 -> 41.200.16.1 -> 172.17.2.25 -> 213.140.58.10 -> 195.22.195.125 -> 4.69.151.13 -> 213.200.68.61 -> somewhere else and after the test got that far, two systems got inserted into the path before level3, resulting in the route entering level3 at a different point, 4.69.141.249. What you now have is 172.28.0.1 -> 10.16.0.2 -> 41.200.16.1 -> 172.17.2.25 -> 213.140.58.10 -> 195.22.195.125 -> unknown -> unknown -> 4.69.141.249 -> 77.67.66.154 -> and so on The effect would be to get a result like this. Next time you see something like this, suggestion: repeat the traceroute and see what you get. On Dec 7, 2011, at 12:12 PM, Meftah Tayeb wrote: > Hey folks, > i see a strange traceroute there > > D?termination de l'itin?raire vers www.rri.ro [193.231.72.52] > avec un maximum de 30 sauts : > > 1 2 ms 1 ms 1 ms 172.28.0.1 > 2 1 ms 1 ms 1 ms localhost [10.16.0.2] > 3 10 ms 10 ms 13 ms 41.200.16.1 > 4 11 ms 10 ms 11 ms 172.17.2.25 > 5 21 ms 21 ms 21 ms 213.140.58.10 > 6 34 ms 31 ms 55 ms pos14-0.palermo9.pal.seabone.net > [195.22.197.125 > ] > 7 34 ms 33 ms 35 ms ae-5-6.bar2.marseille1.level3.net > [4.69.151.13] > 8 106 ms 68 ms 67 ms xe-1-1-0.mil10.ip4.tinet.net > [213.200.68.61] > 9 74 ms 73 ms 74 ms ae-1-12.bar1.budapest1.level3.net > [4.69.141.249] > 10 63 ms 63 ms 79 ms euroweb-gw.ip4.tinet.net [77.67.66.154] > 11 85 ms 84 ms 84 ms v15-core1.stsisp.ro [193.151.28.1] > 12 100 ms 100 ms 102 ms inet-crli1.qrli1.buh.ew.ro [81.24.28.226] > 13 81 ms 81 ms 81 ms 193.231.72.10 > 14 92 ms 92 ms 93 ms ip4-89-238-225-90.euroweb.ro > [89.238.225.90] > 15 89 ms 89 ms 89 ms webrri.rri.ro.72.231.193.in-addr.arpa > [193.231.7 > 2.52] > Itin?raire d?termin?. > C:\Documents and Settings\TAYEB> > Seabone, then level3, then Tinet, then level3, then tinet ? > if is that a routing stufs that i don't know, please let me know :) > i never saw that befaure > > Meftah Tayeb > IT Consulting > http://www.tmvoip.com/ > phone: +21321656139 > Mobile: +213660347746 > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 6695 (20111208) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From smb at cs.columbia.edu Thu Dec 8 15:33:09 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Thu, 8 Dec 2011 16:33:09 -0500 Subject: Traceroute explanation In-Reply-To: References: <1FA371D2FA554B7C9D99157E3AA7E8D4@work> Message-ID: On Dec 7, 2011, at 2:51 08PM, Meftah Tayeb wrote: > big thank for that > but, i am testing that for one day :) Can you do an AStraceroute or manually translate those addresses into AS#s? That is, might level3 and tinet be using multiple AS#s, in which case this isn't unreasonable? > > > ----- Original Message ----- From: "Fred Baker" > To: "Meftah Tayeb" > Cc: > Sent: Thursday, December 08, 2011 11:23 PM > Subject: Re: Traceroute explanation > > > This is just a guess, but I'll bet the route changed while you were measuring it. > > Traceroute sends a request, awaits a response, sends a request, ... Suppose that the route was > > 172.28.0.1 -> 10.16.0.2 > -> 41.200.16.1 > -> 172.17.2.25 > -> 213.140.58.10 > -> 195.22.195.125 > -> 4.69.151.13 > -> 213.200.68.61 > -> somewhere else > > and after the test got that far, two systems got inserted into the path before level3, resulting in the route entering level3 at a different point, 4.69.141.249. What you now have is > > 172.28.0.1 -> 10.16.0.2 > -> 41.200.16.1 > -> 172.17.2.25 > -> 213.140.58.10 > -> 195.22.195.125 > -> unknown > -> unknown > -> 4.69.141.249 > -> 77.67.66.154 > -> and so on > > The effect would be to get a result like this. > > Next time you see something like this, suggestion: repeat the traceroute and see what you get. > > > On Dec 7, 2011, at 12:12 PM, Meftah Tayeb wrote: > >> Hey folks, >> i see a strange traceroute there >> >> D?termination de l'itin?raire vers www.rri.ro [193.231.72.52] >> avec un maximum de 30 sauts : >> >> 1 2 ms 1 ms 1 ms 172.28.0.1 >> 2 1 ms 1 ms 1 ms localhost [10.16.0.2] >> 3 10 ms 10 ms 13 ms 41.200.16.1 >> 4 11 ms 10 ms 11 ms 172.17.2.25 >> 5 21 ms 21 ms 21 ms 213.140.58.10 >> 6 34 ms 31 ms 55 ms pos14-0.palermo9.pal.seabone.net [195.22.197.125 >> ] >> 7 34 ms 33 ms 35 ms ae-5-6.bar2.marseille1.level3.net [4.69.151.13] >> 8 106 ms 68 ms 67 ms xe-1-1-0.mil10.ip4.tinet.net [213.200.68.61] >> 9 74 ms 73 ms 74 ms ae-1-12.bar1.budapest1.level3.net [4.69.141.249] >> 10 63 ms 63 ms 79 ms euroweb-gw.ip4.tinet.net [77.67.66.154] >> 11 85 ms 84 ms 84 ms v15-core1.stsisp.ro [193.151.28.1] >> 12 100 ms 100 ms 102 ms inet-crli1.qrli1.buh.ew.ro [81.24.28.226] >> 13 81 ms 81 ms 81 ms 193.231.72.10 >> 14 92 ms 92 ms 93 ms ip4-89-238-225-90.euroweb.ro [89.238.225.90] >> 15 89 ms 89 ms 89 ms webrri.rri.ro.72.231.193.in-addr.arpa [193.231.7 >> 2.52] >> Itin?raire d?termin?. >> C:\Documents and Settings\TAYEB> >> Seabone, then level3, then Tinet, then level3, then tinet ? >> if is that a routing stufs that i don't know, please let me know :) >> i never saw that befaure >> >> Meftah Tayeb >> IT Consulting >> http://www.tmvoip.com/ >> phone: +21321656139 >> Mobile: +213660347746 >> >> >> __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________ >> >> The message was checked by ESET NOD32 Antivirus. >> >> http://www.eset.com >> > > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > > > --Steve Bellovin, https://www.cs.columbia.edu/~smb From tayeb.meftah at gmail.com Wed Dec 7 13:56:16 2011 From: tayeb.meftah at gmail.com (Meftah Tayeb) Date: Wed, 7 Dec 2011 21:56:16 +0200 Subject: Traceroute explanation References: <1FA371D2FA554B7C9D99157E3AA7E8D4@work> Message-ID: <9A5844D670E44A18B87B629A9E3848C0@work> please tel me how to ? i don't know astraceroute:) ----- Original Message ----- From: "Steven Bellovin" To: "Meftah Tayeb" Cc: "Fred Baker" ; Sent: Thursday, December 08, 2011 11:33 PM Subject: Re: Traceroute explanation On Dec 7, 2011, at 2:51 08PM, Meftah Tayeb wrote: > big thank for that > but, i am testing that for one day :) Can you do an AStraceroute or manually translate those addresses into AS#s? That is, might level3 and tinet be using multiple AS#s, in which case this isn't unreasonable? > > > ----- Original Message ----- From: "Fred Baker" > To: "Meftah Tayeb" > Cc: > Sent: Thursday, December 08, 2011 11:23 PM > Subject: Re: Traceroute explanation > > > This is just a guess, but I'll bet the route changed while you were > measuring it. > > Traceroute sends a request, awaits a response, sends a request, ... > Suppose that the route was > > 172.28.0.1 -> 10.16.0.2 > -> 41.200.16.1 > -> 172.17.2.25 > -> 213.140.58.10 > -> 195.22.195.125 > -> 4.69.151.13 > -> 213.200.68.61 > -> somewhere else > > and after the test got that far, two systems got inserted into the path > before level3, resulting in the route entering level3 at a different > point, 4.69.141.249. What you now have is > > 172.28.0.1 -> 10.16.0.2 > -> 41.200.16.1 > -> 172.17.2.25 > -> 213.140.58.10 > -> 195.22.195.125 > -> unknown > -> unknown > -> 4.69.141.249 > -> 77.67.66.154 > -> and so on > > The effect would be to get a result like this. > > Next time you see something like this, suggestion: repeat the traceroute > and see what you get. > > > On Dec 7, 2011, at 12:12 PM, Meftah Tayeb wrote: > >> Hey folks, >> i see a strange traceroute there >> >> D?termination de l'itin?raire vers www.rri.ro [193.231.72.52] >> avec un maximum de 30 sauts : >> >> 1 2 ms 1 ms 1 ms 172.28.0.1 >> 2 1 ms 1 ms 1 ms localhost [10.16.0.2] >> 3 10 ms 10 ms 13 ms 41.200.16.1 >> 4 11 ms 10 ms 11 ms 172.17.2.25 >> 5 21 ms 21 ms 21 ms 213.140.58.10 >> 6 34 ms 31 ms 55 ms pos14-0.palermo9.pal.seabone.net >> [195.22.197.125 >> ] >> 7 34 ms 33 ms 35 ms ae-5-6.bar2.marseille1.level3.net >> [4.69.151.13] >> 8 106 ms 68 ms 67 ms xe-1-1-0.mil10.ip4.tinet.net >> [213.200.68.61] >> 9 74 ms 73 ms 74 ms ae-1-12.bar1.budapest1.level3.net >> [4.69.141.249] >> 10 63 ms 63 ms 79 ms euroweb-gw.ip4.tinet.net [77.67.66.154] >> 11 85 ms 84 ms 84 ms v15-core1.stsisp.ro [193.151.28.1] >> 12 100 ms 100 ms 102 ms inet-crli1.qrli1.buh.ew.ro [81.24.28.226] >> 13 81 ms 81 ms 81 ms 193.231.72.10 >> 14 92 ms 92 ms 93 ms ip4-89-238-225-90.euroweb.ro >> [89.238.225.90] >> 15 89 ms 89 ms 89 ms webrri.rri.ro.72.231.193.in-addr.arpa >> [193.231.7 >> 2.52] >> Itin?raire d?termin?. >> C:\Documents and Settings\TAYEB> >> Seabone, then level3, then Tinet, then level3, then tinet ? >> if is that a routing stufs that i don't know, please let me know :) >> i never saw that befaure >> >> Meftah Tayeb >> IT Consulting >> http://www.tmvoip.com/ >> phone: +21321656139 >> Mobile: +213660347746 >> >> >> __________ Information from ESET NOD32 Antivirus, version of virus >> signature database 6695 (20111208) __________ >> >> The message was checked by ESET NOD32 Antivirus. >> >> http://www.eset.com >> > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 6695 (20111208) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 6695 (20111208) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > > > --Steve Bellovin, https://www.cs.columbia.edu/~smb __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From harsha at cs.ucr.edu Thu Dec 8 15:37:11 2011 From: harsha at cs.ucr.edu (Harsha V. Madhyastha) Date: Thu, 8 Dec 2011 13:37:11 -0800 Subject: Traceroute explanation In-Reply-To: References: <1FA371D2FA554B7C9D99157E3AA7E8D4@work> Message-ID: <92EC0281-B08C-43EF-8694-1D470FCE60F8@cs.ucr.edu> Another explanation could be load balancing. As Fred mentioned, traceroute sends out different packets for different hops on the path and since these packets have different headers, load balancers on the path may hash packets with different TTL values on to different paths. Check out http://www.paris-traceroute.net/ for more information. --Harsha On Dec 8, 2011, at 1:23 PM, Fred Baker wrote: > This is just a guess, but I'll bet the route changed while you were measuring it. > > Traceroute sends a request, awaits a response, sends a request, ... Suppose that the route was > > 172.28.0.1 -> 10.16.0.2 > -> 41.200.16.1 > -> 172.17.2.25 > -> 213.140.58.10 > -> 195.22.195.125 > -> 4.69.151.13 > -> 213.200.68.61 > -> somewhere else > > and after the test got that far, two systems got inserted into the path before level3, resulting in the route entering level3 at a different point, 4.69.141.249. What you now have is > > 172.28.0.1 -> 10.16.0.2 > -> 41.200.16.1 > -> 172.17.2.25 > -> 213.140.58.10 > -> 195.22.195.125 > -> unknown > -> unknown > -> 4.69.141.249 > -> 77.67.66.154 > -> and so on > > The effect would be to get a result like this. > > Next time you see something like this, suggestion: repeat the traceroute and see what you get. > > > On Dec 7, 2011, at 12:12 PM, Meftah Tayeb wrote: > >> Hey folks, >> i see a strange traceroute there >> >> D?termination de l'itin?raire vers www.rri.ro [193.231.72.52] >> avec un maximum de 30 sauts : >> >> 1 2 ms 1 ms 1 ms 172.28.0.1 >> 2 1 ms 1 ms 1 ms localhost [10.16.0.2] >> 3 10 ms 10 ms 13 ms 41.200.16.1 >> 4 11 ms 10 ms 11 ms 172.17.2.25 >> 5 21 ms 21 ms 21 ms 213.140.58.10 >> 6 34 ms 31 ms 55 ms pos14-0.palermo9.pal.seabone.net [195.22.197.125 >> ] >> 7 34 ms 33 ms 35 ms ae-5-6.bar2.marseille1.level3.net [4.69.151.13] >> 8 106 ms 68 ms 67 ms xe-1-1-0.mil10.ip4.tinet.net [213.200.68.61] >> 9 74 ms 73 ms 74 ms ae-1-12.bar1.budapest1.level3.net [4.69.141.249] >> 10 63 ms 63 ms 79 ms euroweb-gw.ip4.tinet.net [77.67.66.154] >> 11 85 ms 84 ms 84 ms v15-core1.stsisp.ro [193.151.28.1] >> 12 100 ms 100 ms 102 ms inet-crli1.qrli1.buh.ew.ro [81.24.28.226] >> 13 81 ms 81 ms 81 ms 193.231.72.10 >> 14 92 ms 92 ms 93 ms ip4-89-238-225-90.euroweb.ro [89.238.225.90] >> 15 89 ms 89 ms 89 ms webrri.rri.ro.72.231.193.in-addr.arpa [193.231.7 >> 2.52] >> Itin?raire d?termin?. >> C:\Documents and Settings\TAYEB> >> Seabone, then level3, then Tinet, then level3, then tinet ? >> if is that a routing stufs that i don't know, please let me know :) >> i never saw that befaure >> >> Meftah Tayeb >> IT Consulting >> http://www.tmvoip.com/ >> phone: +21321656139 >> Mobile: +213660347746 >> >> >> __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________ >> >> The message was checked by ESET NOD32 Antivirus. >> >> http://www.eset.com >> > > From smb at cs.columbia.edu Thu Dec 8 15:39:49 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Thu, 8 Dec 2011 16:39:49 -0500 Subject: Traceroute explanation In-Reply-To: <9A5844D670E44A18B87B629A9E3848C0@work> References: <1FA371D2FA554B7C9D99157E3AA7E8D4@work> <9A5844D670E44A18B87B629A9E3848C0@work> Message-ID: <0A74E3F6-C110-4BA6-99E0-3166291CB587@cs.columbia.edu> I don't know what platform you're using, but there's a separate command. See http://www.shrubbery.net/astraceroute/ . If you're using Linux, there's probably a package in your favorite repository. There seem to be other variants floating around the net. If you're using Windows, I have no idea what's available. On Dec 7, 2011, at 2:56 16PM, Meftah Tayeb wrote: > please tel me how to ? > i don't know astraceroute:) > > ----- Original Message ----- From: "Steven Bellovin" > To: "Meftah Tayeb" > Cc: "Fred Baker" ; > Sent: Thursday, December 08, 2011 11:33 PM > Subject: Re: Traceroute explanation > > > On Dec 7, 2011, at 2:51 08PM, Meftah Tayeb wrote: > >> big thank for that >> but, i am testing that for one day :) > > > > Can you do an AStraceroute or manually translate those addresses into AS#s? > That is, might level3 and tinet be using multiple AS#s, in which case this > isn't unreasonable? > > > > > >> >> >> ----- Original Message ----- From: "Fred Baker" >> To: "Meftah Tayeb" >> Cc: >> Sent: Thursday, December 08, 2011 11:23 PM >> Subject: Re: Traceroute explanation >> >> >> This is just a guess, but I'll bet the route changed while you were measuring it. >> >> Traceroute sends a request, awaits a response, sends a request, ... Suppose that the route was >> >> 172.28.0.1 -> 10.16.0.2 >> -> 41.200.16.1 >> -> 172.17.2.25 >> -> 213.140.58.10 >> -> 195.22.195.125 >> -> 4.69.151.13 >> -> 213.200.68.61 >> -> somewhere else >> >> and after the test got that far, two systems got inserted into the path before level3, resulting in the route entering level3 at a different point, 4.69.141.249. What you now have is >> >> 172.28.0.1 -> 10.16.0.2 >> -> 41.200.16.1 >> -> 172.17.2.25 >> -> 213.140.58.10 >> -> 195.22.195.125 >> -> unknown >> -> unknown >> -> 4.69.141.249 >> -> 77.67.66.154 >> -> and so on >> >> The effect would be to get a result like this. >> >> Next time you see something like this, suggestion: repeat the traceroute and see what you get. >> >> >> On Dec 7, 2011, at 12:12 PM, Meftah Tayeb wrote: >> >>> Hey folks, >>> i see a strange traceroute there >>> >>> D?termination de l'itin?raire vers www.rri.ro [193.231.72.52] >>> avec un maximum de 30 sauts : >>> >>> 1 2 ms 1 ms 1 ms 172.28.0.1 >>> 2 1 ms 1 ms 1 ms localhost [10.16.0.2] >>> 3 10 ms 10 ms 13 ms 41.200.16.1 >>> 4 11 ms 10 ms 11 ms 172.17.2.25 >>> 5 21 ms 21 ms 21 ms 213.140.58.10 >>> 6 34 ms 31 ms 55 ms pos14-0.palermo9.pal.seabone.net [195.22.197.125 >>> ] >>> 7 34 ms 33 ms 35 ms ae-5-6.bar2.marseille1.level3.net [4.69.151.13] >>> 8 106 ms 68 ms 67 ms xe-1-1-0.mil10.ip4.tinet.net [213.200.68.61] >>> 9 74 ms 73 ms 74 ms ae-1-12.bar1.budapest1.level3.net [4.69.141.249] >>> 10 63 ms 63 ms 79 ms euroweb-gw.ip4.tinet.net [77.67.66.154] >>> 11 85 ms 84 ms 84 ms v15-core1.stsisp.ro [193.151.28.1] >>> 12 100 ms 100 ms 102 ms inet-crli1.qrli1.buh.ew.ro [81.24.28.226] >>> 13 81 ms 81 ms 81 ms 193.231.72.10 >>> 14 92 ms 92 ms 93 ms ip4-89-238-225-90.euroweb.ro [89.238.225.90] >>> 15 89 ms 89 ms 89 ms webrri.rri.ro.72.231.193.in-addr.arpa [193.231.7 >>> 2.52] >>> Itin?raire d?termin?. >>> C:\Documents and Settings\TAYEB> >>> Seabone, then level3, then Tinet, then level3, then tinet ? >>> if is that a routing stufs that i don't know, please let me know :) >>> i never saw that befaure >>> >>> Meftah Tayeb >>> IT Consulting >>> http://www.tmvoip.com/ >>> phone: +21321656139 >>> Mobile: +213660347746 >>> >>> >>> __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________ >>> >>> The message was checked by ESET NOD32 Antivirus. >>> >>> http://www.eset.com >>> >> >> >> >> __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________ >> >> The message was checked by ESET NOD32 Antivirus. >> >> http://www.eset.com >> >> >> >> >> __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________ >> >> The message was checked by ESET NOD32 Antivirus. >> >> http://www.eset.com >> >> >> >> >> > > > --Steve Bellovin, https://www.cs.columbia.edu/~smb > > > > > > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > > --Steve Bellovin, https://www.cs.columbia.edu/~smb From raymond at prolocation.net Thu Dec 8 15:40:10 2011 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Thu, 8 Dec 2011 22:40:10 +0100 Subject: Traceroute explanation In-Reply-To: <9A5844D670E44A18B87B629A9E3848C0@work> References: <1FA371D2FA554B7C9D99157E3AA7E8D4@work> <9A5844D670E44A18B87B629A9E3848C0@work> Message-ID: <89151835-9FE8-49ED-8D17-2D1E3EDF70AC@prolocation.net> Hai! Check with lft or mtr ... Thanks, Raymond Dijkxhoorn, Prolocation Op 7 dec. 2011 om 20:56 heeft "Meftah Tayeb" het volgende geschreven: > please tel me how to ? > i don't know astraceroute:) > > ----- Original Message ----- From: "Steven Bellovin" > To: "Meftah Tayeb" > Cc: "Fred Baker" ; > Sent: Thursday, December 08, 2011 11:33 PM > Subject: Re: Traceroute explanation > > > On Dec 7, 2011, at 2:51 08PM, Meftah Tayeb wrote: > >> big thank for that >> but, i am testing that for one day :) > > > > Can you do an AStraceroute or manually translate those addresses into AS#s? > That is, might level3 and tinet be using multiple AS#s, in which case this > isn't unreasonable? > > > > > >> >> >> ----- Original Message ----- From: "Fred Baker" >> To: "Meftah Tayeb" >> Cc: >> Sent: Thursday, December 08, 2011 11:23 PM >> Subject: Re: Traceroute explanation >> >> >> This is just a guess, but I'll bet the route changed while you were measuring it. >> >> Traceroute sends a request, awaits a response, sends a request, ... Suppose that the route was >> >> 172.28.0.1 -> 10.16.0.2 >> -> 41.200.16.1 >> -> 172.17.2.25 >> -> 213.140.58.10 >> -> 195.22.195.125 >> -> 4.69.151.13 >> -> 213.200.68.61 >> -> somewhere else >> >> and after the test got that far, two systems got inserted into the path before level3, resulting in the route entering level3 at a different point, 4.69.141.249. What you now have is >> >> 172.28.0.1 -> 10.16.0.2 >> -> 41.200.16.1 >> -> 172.17.2.25 >> -> 213.140.58.10 >> -> 195.22.195.125 >> -> unknown >> -> unknown >> -> 4.69.141.249 >> -> 77.67.66.154 >> -> and so on >> >> The effect would be to get a result like this. >> >> Next time you see something like this, suggestion: repeat the traceroute and see what you get. >> >> >> On Dec 7, 2011, at 12:12 PM, Meftah Tayeb wrote: >> >>> Hey folks, >>> i see a strange traceroute there >>> >>> D?termination de l'itin?raire vers www.rri.ro [193.231.72.52] >>> avec un maximum de 30 sauts : >>> >>> 1 2 ms 1 ms 1 ms 172.28.0.1 >>> 2 1 ms 1 ms 1 ms localhost [10.16.0.2] >>> 3 10 ms 10 ms 13 ms 41.200.16.1 >>> 4 11 ms 10 ms 11 ms 172.17.2.25 >>> 5 21 ms 21 ms 21 ms 213.140.58.10 >>> 6 34 ms 31 ms 55 ms pos14-0.palermo9.pal.seabone.net [195.22.197.125 >>> ] >>> 7 34 ms 33 ms 35 ms ae-5-6.bar2.marseille1.level3.net [4.69.151.13] >>> 8 106 ms 68 ms 67 ms xe-1-1-0.mil10.ip4.tinet.net [213.200.68.61] >>> 9 74 ms 73 ms 74 ms ae-1-12.bar1.budapest1.level3.net [4.69.141.249] >>> 10 63 ms 63 ms 79 ms euroweb-gw.ip4.tinet.net [77.67.66.154] >>> 11 85 ms 84 ms 84 ms v15-core1.stsisp.ro [193.151.28.1] >>> 12 100 ms 100 ms 102 ms inet-crli1.qrli1.buh.ew.ro [81.24.28.226] >>> 13 81 ms 81 ms 81 ms 193.231.72.10 >>> 14 92 ms 92 ms 93 ms ip4-89-238-225-90.euroweb.ro [89.238.225.90] >>> 15 89 ms 89 ms 89 ms webrri.rri.ro.72.231.193.in-addr.arpa [193.231.7 >>> 2.52] >>> Itin?raire d?termin?. >>> C:\Documents and Settings\TAYEB> >>> Seabone, then level3, then Tinet, then level3, then tinet ? >>> if is that a routing stufs that i don't know, please let me know :) >>> i never saw that befaure >>> >>> Meftah Tayeb >>> IT Consulting >>> http://www.tmvoip.com/ >>> phone: +21321656139 >>> Mobile: +213660347746 >>> >>> >>> __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________ >>> >>> The message was checked by ESET NOD32 Antivirus. >>> >>> http://www.eset.com >>> >> >> >> >> __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________ >> >> The message was checked by ESET NOD32 Antivirus. >> >> http://www.eset.com >> >> >> >> >> __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________ >> >> The message was checked by ESET NOD32 Antivirus. >> >> http://www.eset.com >> >> >> >> >> > > > --Steve Bellovin, https://www.cs.columbia.edu/~smb > > > > > > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > From tayeb.meftah at gmail.com Wed Dec 7 14:04:31 2011 From: tayeb.meftah at gmail.com (Meftah Tayeb) Date: Wed, 7 Dec 2011 22:04:31 +0200 Subject: Traceroute explanation References: <1FA371D2FA554B7C9D99157E3AA7E8D4@work> <9A5844D670E44A18B87B629A9E3848C0@work> <89151835-9FE8-49ED-8D17-2D1E3EDF70AC@prolocation.net> Message-ID: <2172512BA3A94DB498EDC8F9003A2856@work> Using LFT: root at debian:~# lft 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets 1 172.28.1.1 (172.28.1.1) 0.798 ms 0.711 ms 2 10.16.0.2 (10.16.0.2) 0.414 ms 0.331 ms 3 41.200.16.1 (41.200.16.1) 11.400 ms 11.474 ms 4 172.17.2.25 (172.17.2.25) 10.184 ms 11.322 ms 5 213.140.58.10 (213.140.58.10) 11.264 ms 10.623 ms 6 212.73.253.65 (212.73.253.65) 30.330 ms 32.391 ms 7 ae-4-5.bar1.Marseille1.Level3.net (4.69.151.9) 32.177 ms 32.219 ms 8 ae-7-7.ebr1.Paris1.Level3.net (4.69.143.238) 42.160 ms 42.318 ms root at debian:~# lft www.rri.ro traceroute to www.rri.ro (193.231.72.52), 30 hops max, 60 byte packets 1 172.28.1.1 (172.28.1.1) 0.819 ms 0.737 ms 2 10.16.0.2 (10.16.0.2) 0.402 ms 0.335 ms 3 41.200.16.1 (41.200.16.1) 10.592 ms 10.209 ms 4 172.17.2.25 (172.17.2.25) 10.146 ms 10.559 ms 5 213.140.58.10 (213.140.58.10) 11.258 ms 10.369 ms 6 pos14-0.palermo9.pal.seabone.net (195.22.197.125) 30.817 ms 31.439 ms 7 ae-5-6.bar2.Marseille1.Level3.net (4.69.151.13) 33.968 ms 31.395 ms 8 ge-0-0-0.mil19.ip4.tinet.net (213.200.68.145) 57.178 ms xe-1-1-0.mil10.ip4. tinet.net (213.200.68.61) 57.749 ms 9 ae-1-12.bar1.Budapest1.Level3.net (4.69.141.249) 61.835 ms 62.317 ms 10 euroweb-gw.ip4.tinet.net (77.67.66.154) 61.361 ms 60.292 ms 11 v15-core1.stsisp.ro (193.151.28.1) 163.662 ms 144.245 ms 12 inet-crli1.qrli1.buh.ew.ro (81.24.28.226) 91.309 ms 89.880 ms 13 193.231.72.10 (193.231.72.10) 80.790 ms 79.354 ms 14 ip4-89-238-225-90.euroweb.ro (89.238.225.90) 91.067 ms 90.906 ms 15 webrri.rri.ro.72.231.193.in-addr.arpa (193.231.72.52) 79.196 ms 79.389 ms root at debian:~# ----- Original Message ----- From: "Raymond Dijkxhoorn" To: "Meftah Tayeb" Cc: "Steven Bellovin" ; Sent: Thursday, December 08, 2011 11:40 PM Subject: Re: Traceroute explanation Hai! Check with lft or mtr ... Thanks, Raymond Dijkxhoorn, Prolocation Op 7 dec. 2011 om 20:56 heeft "Meftah Tayeb" het volgende geschreven: > please tel me how to ? > i don't know astraceroute:) > > ----- Original Message ----- From: "Steven Bellovin" > To: "Meftah Tayeb" > Cc: "Fred Baker" ; > Sent: Thursday, December 08, 2011 11:33 PM > Subject: Re: Traceroute explanation > > > On Dec 7, 2011, at 2:51 08PM, Meftah Tayeb wrote: > >> big thank for that >> but, i am testing that for one day :) > > > > Can you do an AStraceroute or manually translate those addresses into > AS#s? > That is, might level3 and tinet be using multiple AS#s, in which case > this > isn't unreasonable? > > > > > >> >> >> ----- Original Message ----- From: "Fred Baker" >> To: "Meftah Tayeb" >> Cc: >> Sent: Thursday, December 08, 2011 11:23 PM >> Subject: Re: Traceroute explanation >> >> >> This is just a guess, but I'll bet the route changed while you were >> measuring it. >> >> Traceroute sends a request, awaits a response, sends a request, ... >> Suppose that the route was >> >> 172.28.0.1 -> 10.16.0.2 >> -> 41.200.16.1 >> -> 172.17.2.25 >> -> 213.140.58.10 >> -> 195.22.195.125 >> -> 4.69.151.13 >> -> 213.200.68.61 >> -> somewhere else >> >> and after the test got that far, two systems got inserted into the path >> before level3, resulting in the route entering level3 at a different >> point, 4.69.141.249. What you now have is >> >> 172.28.0.1 -> 10.16.0.2 >> -> 41.200.16.1 >> -> 172.17.2.25 >> -> 213.140.58.10 >> -> 195.22.195.125 >> -> unknown >> -> unknown >> -> 4.69.141.249 >> -> 77.67.66.154 >> -> and so on >> >> The effect would be to get a result like this. >> >> Next time you see something like this, suggestion: repeat the traceroute >> and see what you get. >> >> >> On Dec 7, 2011, at 12:12 PM, Meftah Tayeb wrote: >> >>> Hey folks, >>> i see a strange traceroute there >>> >>> D?termination de l'itin?raire vers www.rri.ro [193.231.72.52] >>> avec un maximum de 30 sauts : >>> >>> 1 2 ms 1 ms 1 ms 172.28.0.1 >>> 2 1 ms 1 ms 1 ms localhost [10.16.0.2] >>> 3 10 ms 10 ms 13 ms 41.200.16.1 >>> 4 11 ms 10 ms 11 ms 172.17.2.25 >>> 5 21 ms 21 ms 21 ms 213.140.58.10 >>> 6 34 ms 31 ms 55 ms pos14-0.palermo9.pal.seabone.net >>> [195.22.197.125 >>> ] >>> 7 34 ms 33 ms 35 ms ae-5-6.bar2.marseille1.level3.net >>> [4.69.151.13] >>> 8 106 ms 68 ms 67 ms xe-1-1-0.mil10.ip4.tinet.net >>> [213.200.68.61] >>> 9 74 ms 73 ms 74 ms ae-1-12.bar1.budapest1.level3.net >>> [4.69.141.249] >>> 10 63 ms 63 ms 79 ms euroweb-gw.ip4.tinet.net [77.67.66.154] >>> 11 85 ms 84 ms 84 ms v15-core1.stsisp.ro [193.151.28.1] >>> 12 100 ms 100 ms 102 ms inet-crli1.qrli1.buh.ew.ro [81.24.28.226] >>> 13 81 ms 81 ms 81 ms 193.231.72.10 >>> 14 92 ms 92 ms 93 ms ip4-89-238-225-90.euroweb.ro >>> [89.238.225.90] >>> 15 89 ms 89 ms 89 ms webrri.rri.ro.72.231.193.in-addr.arpa >>> [193.231.7 >>> 2.52] >>> Itin?raire d?termin?. >>> C:\Documents and Settings\TAYEB> >>> Seabone, then level3, then Tinet, then level3, then tinet ? >>> if is that a routing stufs that i don't know, please let me know :) >>> i never saw that befaure >>> >>> Meftah Tayeb >>> IT Consulting >>> http://www.tmvoip.com/ >>> phone: +21321656139 >>> Mobile: +213660347746 >>> >>> >>> __________ Information from ESET NOD32 Antivirus, version of virus >>> signature database 6695 (20111208) __________ >>> >>> The message was checked by ESET NOD32 Antivirus. >>> >>> http://www.eset.com >>> >> >> >> >> __________ Information from ESET NOD32 Antivirus, version of virus >> signature database 6695 (20111208) __________ >> >> The message was checked by ESET NOD32 Antivirus. >> >> http://www.eset.com >> >> >> >> >> __________ Information from ESET NOD32 Antivirus, version of virus >> signature database 6695 (20111208) __________ >> >> The message was checked by ESET NOD32 Antivirus. >> >> http://www.eset.com >> >> >> >> >> > > > --Steve Bellovin, https://www.cs.columbia.edu/~smb > > > > > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 6695 (20111208) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 6695 (20111208) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 6695 (20111208) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From raymond at prolocation.net Thu Dec 8 16:19:57 2011 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Thu, 8 Dec 2011 23:19:57 +0100 (CET) Subject: {Spam?} Re: Traceroute explanation In-Reply-To: <2172512BA3A94DB498EDC8F9003A2856@work> References: <1FA371D2FA554B7C9D99157E3AA7E8D4@work> <9A5844D670E44A18B87B629A9E3848C0@work> <89151835-9FE8-49ED-8D17-2D1E3EDF70AC@prolocation.net> <2172512BA3A94DB498EDC8F9003A2856@work> Message-ID: Hi! > Using LFT: > root at debian:~# lft 8.8.8.8 > traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets > 1 172.28.1.1 (172.28.1.1) 0.798 ms 0.711 ms > 2 10.16.0.2 (10.16.0.2) 0.414 ms 0.331 ms > 3 41.200.16.1 (41.200.16.1) 11.400 ms 11.474 ms > 4 172.17.2.25 (172.17.2.25) 10.184 ms 11.322 ms > 5 213.140.58.10 (213.140.58.10) 11.264 ms 10.623 ms > 6 212.73.253.65 (212.73.253.65) 30.330 ms 32.391 ms > 7 ae-4-5.bar1.Marseille1.Level3.net (4.69.151.9) 32.177 ms 32.219 ms > 8 ae-7-7.ebr1.Paris1.Level3.net (4.69.143.238) 42.160 ms 42.318 ms > root at debian:~# lft www.rri.ro > traceroute to www.rri.ro (193.231.72.52), 30 hops max, 60 byte packets > 1 172.28.1.1 (172.28.1.1) 0.819 ms 0.737 ms > 2 10.16.0.2 (10.16.0.2) 0.402 ms 0.335 ms > 3 41.200.16.1 (41.200.16.1) 10.592 ms 10.209 ms > 4 172.17.2.25 (172.17.2.25) 10.146 ms 10.559 ms > 5 213.140.58.10 (213.140.58.10) 11.258 ms 10.369 ms > 6 pos14-0.palermo9.pal.seabone.net (195.22.197.125) 30.817 ms 31.439 ms > 7 ae-5-6.bar2.Marseille1.Level3.net (4.69.151.13) 33.968 ms 31.395 ms > 8 ge-0-0-0.mil19.ip4.tinet.net (213.200.68.145) 57.178 ms > xe-1-1-0.mil10.ip4. > tinet.net (213.200.68.61) 57.749 ms > 9 ae-1-12.bar1.Budapest1.Level3.net (4.69.141.249) 61.835 ms 62.317 ms > 10 euroweb-gw.ip4.tinet.net (77.67.66.154) 61.361 ms 60.292 ms > 11 v15-core1.stsisp.ro (193.151.28.1) 163.662 ms 144.245 ms > 12 inet-crli1.qrli1.buh.ew.ro (81.24.28.226) 91.309 ms 89.880 ms > 13 193.231.72.10 (193.231.72.10) 80.790 ms 79.354 ms > 14 ip4-89-238-225-90.euroweb.ro (89.238.225.90) 91.067 ms 90.906 ms > 15 webrri.rri.ro.72.231.193.in-addr.arpa (193.231.72.52) 79.196 ms 79.389 > ms > root at debian:~# lft -A snows ASN also. Example: [root at lft ~]# lft -A www.rri.ro -d 80 Tracing .....................T TTL LFT trace to webrri.rri.ro.72.231.193.in-addr.arpa (193.231.72.52):80/tcp 1 [34108] vrrp-253.bbd.prolocation.net (95.128.88.253) 0.3/0.3ms 2 [41887] breedband-delft-rc02-gige-1.prolocation.net (94.228.128.57) 11.8/1.4ms 3 [12871] gigabone10-3.prolocation.net (213.197.27.165) 1.3/1.4ms 4 [1200] amx1.fra.ew.ro (195.69.144.121) 59.5/31.5ms 5 [6663] inet-qrli1.crli1.buh.ew.ro (81.24.28.225) 38.1/38.1ms 6 [6663] inet-crli1.qrli1.buh.ew.ro (81.24.28.226) 37.4/37.5ms 7 [6663] qrli11.drli1.buh.ew.ro (81.24.28.242) 37.9/37.9ms 8 [6663] ip4-89-238-225-90.euroweb.ro (89.238.225.90) 37.7/37.7ms 9 [34808] 193.231.72.10 37.9/37.9ms 10 [34808] [target open] webrri.rri.ro.72.231.193.in-addr.arpa (193.231.72.52):80 37.8/38.0ms Bye, Raymond. From pixitha.kyle at gmail.com Thu Dec 8 17:48:46 2011 From: pixitha.kyle at gmail.com (Kyle Duren) Date: Thu, 8 Dec 2011 15:48:46 -0800 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: <4edd576f.858d2a0a.6293.6cacSMTPIN_ADDED@mx.google.com> References: <4edd576f.858d2a0a.6293.6cacSMTPIN_ADDED@mx.google.com> Message-ID: http://download.cnet.com/8301-2007_4-57338809-12/a-note-from-sean-regarding-the-download.com-installer/ In case no one saw this yet. -Kyle From tvhawaii at shaka.com Thu Dec 8 19:00:26 2011 From: tvhawaii at shaka.com (Michael Painter) Date: Thu, 8 Dec 2011 15:00:26 -1000 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] References: <4edd576f.858d2a0a.6293.6cacSMTPIN_ADDED@mx.google.com> Message-ID: <890D7664EF3C402B81F2F02D704FB6F7@owner59e1f1502> Kyle Duren wrote: > http://download.cnet.com/8301-2007_4-57338809-12/a-note-from-sean-regarding-the-download.com-installer/ > > In case no one saw this yet. > > -Kyle Sean's apology for their 'mistake' rings hollow. They've had almost 4 months to implement a solution to rectify these 'mistakes', but chose to ignore it until the uproar caused by the nmap community. http://www.extremetech.com/computing/93504-download-com-wraps-downloads-in-bloatware-lies-about-motivations It's always about the Money. --Michael From mysidia at gmail.com Thu Dec 8 20:38:11 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 8 Dec 2011 20:38:11 -0600 Subject: [fyodor@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] In-Reply-To: <890D7664EF3C402B81F2F02D704FB6F7@owner59e1f1502> References: <4edd576f.858d2a0a.6293.6cacSMTPIN_ADDED@mx.google.com> <890D7664EF3C402B81F2F02D704FB6F7@owner59e1f1502> Message-ID: On Thu, Dec 8, 2011 at 7:00 PM, Michael Painter wrote: > Sean's apology for their 'mistake' rings hollow. > They've had almost 4 months to implement a solution to rectify these > 'mistakes', but chose to ignore it until the uproar caused by the nmap [snip] I would say it doesn't read 'unhollow' It's just plain inadequate and doesn't do anything to settle the concerns, whether you accept the apology as sincere or not. Yes, it is obviously a mistake... but the clear mistake is not a technical one of "bundling an open source application"; the mistake is actually a bad decision. The decision to "bundle" anything; something they obviously haven't admitted yet is a bad practice or failure in judgement. Apparently they don't comprehend that, if you are a download repository, you don't surprise your users by tampering with files, regardless of whether the application is open source or proprietary. Oh.. that they apologized about one thing, essentially means they admit the existence of the other bad thing that they don't apologize for. Their explanation of the problem is they don't intend to bundle open source software. Well, that implies there _ARE_ things they intend to tamper with the file for by bundling in their own installer. Otherwise they wouldn't have written the bundling system in the first place. I'm saying... if Download.com wanted to continue to be a trusted download site, they shouldn't have been tampering with any author application files, whether open source or not. They got caught red-handed. The de facto admission that they do ever, has one simple implication... Download.com is simply not to be trusted, anymore, to not bundle executables with unknown software. In my book, nothing download.com does can redeem their trust at this point, they destroyed their sites and CNET's status permanently; end users need to be warned that they are no longer safe for any download, even "known programs", period. -- -JH From matthew at matthew.at Thu Dec 8 23:41:28 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 08 Dec 2011 21:41:28 -0800 Subject: seeking clueful assistance at speakeasy-now-megapath Message-ID: <4EE19F88.5070504@matthew.at> See subject. Contact me off-list please. Matthew Kaufman From furry13 at gmail.com Fri Dec 9 01:14:07 2011 From: furry13 at gmail.com (Jen Linkova) Date: Fri, 9 Dec 2011 18:14:07 +1100 Subject: Juniper <-> Cisco IPv6 BGP peering In-Reply-To: <8CD46A88-DE73-4C13-B18B-087640C6CAA0@network1.net> References: <-5313560550570988594@unknownmsgid> <8CD46A88-DE73-4C13-B18B-087640C6CAA0@network1.net> Message-ID: On Thu, Dec 8, 2011 at 11:53 AM, Randy Carpenter wrote: > Tried that. I agree with others that it is an NDP issue. NDP for the GUA is fine, but just not for the link local. Is there something that would block only link local by default? > > I should add that I have another uplink to a different provider that works perfectly. The other end is Juniper for that one. Just to begin with: 0) Does your Juniper device have the neighbor cache entry for Cisco link-local address? What is the state of the entry? Can you get packet capture on both sides? 1) is Cisco sending NS packets? 2) is your Juniper receiving them? 3) is Juniper device sending anything back? 4) are those NA reaching Cisco? Any switch on the path? [lazy mode on] I'd also suggest: - debug ipv6 nd on cisco - checking for bugs for IOS and JunOS versions you are using > On Dec 7, 2011, at 17:53, Peter Rubenstein wrote: > >> Try setting local-address in the bgp neighbor config on the Juniper side? >> >> --Peter >> >> On Dec 7, 2011, at 4:54 PM, Randy Carpenter wrote: >> >>> >>> Does anyone have any suggestions on setting up BGP peering between Juniper (SRX) and Cisco? >>> >>> I successfully have cisco-cisco and juniper-juniper without problems. >>> >>> When I am trying to peer to one of my upstreams (who has cisco) with my Juniper SRX, They are seeing the link-local address as the next-hop, but are unable to get an ND entry for it, and thus cannot forward traffic to me. >>> >>> >>> -Randy >>> >>> -- >>> | Randy Carpenter >>> | Vice President - IT Services >>> | Red Hat Certified Engineer >>> | First Network Group, Inc. >>> | (800)578-6381, Opt. 1 >>> ---- >>> >>> >> > -- SY, Jen Linkova aka Furry From furry13 at gmail.com Fri Dec 9 06:57:39 2011 From: furry13 at gmail.com (Jen Linkova) Date: Fri, 9 Dec 2011 23:57:39 +1100 Subject: Juniper <-> Cisco IPv6 BGP peering In-Reply-To: References: <43c838e2-d866-4d4b-ac6c-31b8f90c7246@zimbra.network1.net> Message-ID: On Thu, Dec 8, 2011 at 8:54 AM, Randy Carpenter wrote: > When I am trying to peer to one of my upstreams (who has cisco) with my Juniper SRX, They are seeing the link-local address as the next-hop, but are unable to get an ND entry for it, and thus cannot forward traffic to me. on second thought - why are they using link-local as the next-hop in the first place if the eBGP session is established over GUA? -- SY, Jen Linkova aka Furry From eric-list at truenet.com Fri Dec 9 08:22:29 2011 From: eric-list at truenet.com (Eric Tykwinski) Date: Fri, 9 Dec 2011 09:22:29 -0500 Subject: [ncc-announce] 128.0.0.0/16 configured as martians in some routers In-Reply-To: <45D79898-3854-4671-AC9E-317A65C28FC7@ripe.net> References: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> <45D79898-3854-4671-AC9E-317A65C28FC7@ripe.net> Message-ID: <00f701ccb67d$fbbda9e0$f338fda0$@truenet.com> If anyone on Cogent is lurking, we are not receiving the announcements yet in our BGP table. Double checked on the looking glass, and it looks company wide. http://www.cogentco.com/en/network/looking-glass The space is seen through Level3... Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 F: 610-429-3222 -----Original Message----- From: Alex Le Heux [mailto:alexlh at ripe.net] Sent: Monday, December 05, 2011 10:49 AM To: Routing WG Cc: lacnog at lacnic.net; PacNOG List; nanog at nanog.org; menog at menog.net; UKNOF List; SANOG List; ncc-announce at ripe.net; Address Policy Working Group; AfNOG List Subject: Re: [ncc-announce] 128.0.0.0/16 configured as martians in some routers Dear Colleagues, The correct prefix and pingable address list for the Debogonising Project is: prefix pinagble address 128.0.0.0/21 128.0.0.1 128.0.24.0/24 128.0.24.1 Our apologies for the oversight. Best regards, Alex Le Heux Policy Implementation Co-ordinator RIPE NCC From mtinka at globaltransit.net Fri Dec 9 08:45:03 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Fri, 9 Dec 2011 22:45:03 +0800 Subject: Juniper <-> Cisco IPv6 BGP peering In-Reply-To: References: <43c838e2-d866-4d4b-ac6c-31b8f90c7246@zimbra.network1.net> Message-ID: <201112092245.07430.mtinka@globaltransit.net> On Friday, December 09, 2011 08:57:39 PM Jen Linkova wrote: > on second thought - why are they using link-local as the > next-hop in the first place if the eBGP session is > established over GUA? This topic was heavily discussed on 'ipv6-ops' back in February. You may take a look here for all the details on this: http://lists.cluenet.de/pipermail/ipv6-ops/2011- February/004887.html Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From tayeb.meftah at gmail.com Thu Dec 8 07:15:25 2011 From: tayeb.meftah at gmail.com (Meftah Tayeb) Date: Thu, 8 Dec 2011 15:15:25 +0200 Subject: [ncc-announce] 128.0.0.0/16 configured as martians in some routers References: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> <45D79898-3854-4671-AC9E-317A65C28FC7@ripe.net> <00f701ccb67d$fbbda9e0$f338fda0$@truenet.com> Message-ID: <97DEB10E04E3448F949903181E2378A2@work> we are also receyving it through level3. ----- Original Message ----- From: "Eric Tykwinski" To: "'Alex Le Heux'" Cc: Sent: Friday, December 09, 2011 4:22 PM Subject: RE: [ncc-announce] 128.0.0.0/16 configured as martians in some routers > If anyone on Cogent is lurking, we are not receiving the announcements yet > in our BGP table. > > Double checked on the looking glass, and it looks company wide. > http://www.cogentco.com/en/network/looking-glass > > The space is seen through Level3... > > Sincerely, > > Eric Tykwinski > TrueNet, Inc. > P: 610-429-8300 > F: 610-429-3222 > > -----Original Message----- > From: Alex Le Heux [mailto:alexlh at ripe.net] > Sent: Monday, December 05, 2011 10:49 AM > To: Routing WG > Cc: lacnog at lacnic.net; PacNOG List; nanog at nanog.org; menog at menog.net; > UKNOF > List; SANOG List; ncc-announce at ripe.net; Address Policy Working Group; > AfNOG > List > Subject: Re: [ncc-announce] 128.0.0.0/16 configured as martians in some > routers > > Dear Colleagues, > > The correct prefix and pingable address list for the Debogonising Project > is: > > prefix pinagble address > > 128.0.0.0/21 128.0.0.1 > 128.0.24.0/24 128.0.24.1 > > Our apologies for the oversight. > > Best regards, > > Alex Le Heux > Policy Implementation Co-ordinator > RIPE NCC > > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 6697 (20111209) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 6697 (20111209) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From david at davidswafford.com Fri Dec 9 10:05:41 2011 From: david at davidswafford.com (David) Date: Fri, 9 Dec 2011 11:05:41 -0500 Subject: BGP and Firewalls... In-Reply-To: <1F4D60B00DE5FB42AD4BB2BC06DC309220756375@mail.shoremortgage.com> References: <1F4D60B00DE5FB42AD4BB2BC06DC3092207090B9@mail.shoremortgage.com> <76238EAE-2B76-41A1-9AB8-90A66DFB66CE@davidswafford.com> <1F4D60B00DE5FB42AD4BB2BC06DC309220756375@mail.shoremortgage.com> Message-ID: <89B4DA68-B416-4061-89FE-9FEDE97C8CDD@davidswafford.com> SSL interception was the most painful -- PaloAlto finally confirmed it as a bug in 3.1.9, havnt upgraded yet. it basicall eats ssl traffic sporadically. had another issue during go-live where a "commit" caused the box to crash (3.1.9) and anothere during that same week where a malformed ssl packet crashed the dataplane. all cases involved significant interruptions because most did not trigger ha-related failovers. palo also support was extremely slow in all cases weve had and from that perspective alone i would not put all of my eggs into it. great box for web filtering from a feature perspective, but my bluecoats were much more stabile in their 4 yr life than the first 2weeks on our 2050s david. Sent from an email server. On Dec 8, 2011, at 10:11 AM, "Gregory Croft" wrote: > What kind of Bugs are you running into? > I have two PA500's at the moment and haven't really had any issues with > web filtering. > > > > Thank you, > Gregory S. Croft > > -----Original Message----- > From: David [mailto:david at davidswafford.com] > Sent: Thursday, December 08, 2011 9:50 AM > To: Gregory Croft > Cc: > Subject: Re: BGP and Firewalls... > > I wouldn't do it. We have 8 x PA-2050s and run into a lot of wierd > bugs.... (just doing web filtering) > > David > > Sent from an email server. > > On Dec 7, 2011, at 12:31 PM, "Gregory Croft" > wrote: > >> Hi All, >> >> >> >> Does anyone have any experience with using firewalls as edge devices >> when BGP is concerned? >> >> Specifically the Palo Alto series of devices. >> >> >> >> If so please contact me off list. >> >> >> >> Thank you. >> >> >> >> >> >> Thank you, >> >> Gregory S. Croft >> >> >> >> >> From rcarpen at network1.net Fri Dec 9 10:38:44 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Fri, 09 Dec 2011 11:38:44 -0500 (EST) Subject: Juniper <-> Cisco IPv6 BGP peering In-Reply-To: Message-ID: ----- Original Message ----- > On Thu, Dec 8, 2011 at 11:53 AM, Randy Carpenter > wrote: > > Tried that. I agree with others that it is an NDP issue. NDP for > > the GUA is fine, but just not for the link local. Is there > > something that would block only link local by default? > > > > I should add that I have another uplink to a different provider > > that works perfectly. The other end is Juniper for that one. > > Just to begin with: > 0) Does your Juniper device have the neighbor cache entry for Cisco > link-local address? What is the state of the entry? Sometimes it does, sometimes I can't seem to get it. > Can you get packet capture on both sides? We have done this. > 1) is Cisco sending NS packets? Yes. > 2) is your Juniper receiving them? It does not appear to. Tracing v6 stuff on juniper seems to be hit or miss. > 3) is Juniper device sending anything back? No. (because of #2) > 4) are those NA reaching Cisco? No. (because of #2) > Any switch on the path? It is an L2 circuit that rides a couple of different pieces of gear before it lands at the other side. > [lazy mode on] I'd also suggest: > - debug ipv6 nd on cisco > - checking for bugs for IOS and JunOS versions you are using From cdl at asgaard.org Fri Dec 9 11:19:17 2011 From: cdl at asgaard.org (Christopher LILJENSTOLPE) Date: Fri, 9 Dec 2011 09:19:17 -0800 Subject: Writable SNMP In-Reply-To: <1323203316.14305.YahooMailNeo@web31806.mail.mud.yahoo.com> References: <1323203316.14305.YahooMailNeo@web31806.mail.mud.yahoo.com> Message-ID: On 06Dec2011, at 12.28, David Barak wrote: > From: Jeff Wheeler > >> Juniper does not support writing via SNMP. I am glad. Hopefully that >> is the first step toward not supporting SNMP at all. > > If I recall correctly, wasn't the old FORE CLI implemented via localhost SNMP? I liked using them, but that's a special case... Wellfleet > > David Barak > Need Geek Rock? Try The Franchise: > http://www.listentothefranchise.com -- ??? Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From fmartin at linkedin.com Fri Dec 9 12:37:09 2011 From: fmartin at linkedin.com (Franck Martin) Date: Fri, 9 Dec 2011 18:37:09 +0000 Subject: Sad IPv4 story? Message-ID: I just had a personal email from a brand new ISP in the Asia-Pacific area desperately looking for enough IPv4 to be able to run their business the way they would like? This is just a data point. From matthew at matthew.at Fri Dec 9 12:38:56 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 09 Dec 2011 10:38:56 -0800 Subject: Sad IPv4 story? In-Reply-To: References: Message-ID: <4EE255C0.1030304@matthew.at> On 12/9/2011 10:37 AM, Franck Martin wrote: > I just had a personal email from a brand new ISP in the Asia-Pacific area desperately looking for enough IPv4 to be able to run their business the way they would like? > > This is just a data point. > I hear those are $12/each. How much do they have in the budget for this? Matthew Kaufman From patrick at ianai.net Fri Dec 9 12:39:29 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 9 Dec 2011 13:39:29 -0500 Subject: Sad IPv4 story? In-Reply-To: References: Message-ID: <3BB8E3D1-5D17-4D4C-8148-727660598EBD@ianai.net> On Dec 9, 2011, at 1:37 PM, Franck Martin wrote: > I just had a personal email from a brand new ISP in the Asia-Pacific area desperately looking for enough IPv4 to be able to run their business the way they would like? > > This is just a data point. Interesting data point. Would be more interesting to find out "the way they would like". For instance, is it a "bullet-proof" hoster who promises each spammer 1K IP addresses across dozens of discontiguous /24s? Or is it a DSL provider with 10K subs, and APNIC would only give them a /22 until next year? -- TTFN, patrick From fred at cisco.com Fri Dec 9 13:07:55 2011 From: fred at cisco.com (Fred Baker) Date: Fri, 9 Dec 2011 11:07:55 -0800 Subject: Sad IPv4 story? In-Reply-To: References: Message-ID: <4971DF7F-09FC-42C0-98A9-F3C60FF146D1@cisco.com> On Dec 9, 2011, at 10:37 AM, Franck Martin wrote: > I just had a personal email from a brand new ISP in the Asia-Pacific area desperately looking for enough IPv4 to be able to run their business the way they would like? > > This is just a data point. We're going to be hearing a lot more of these. It's the nature of finite resources, and of human nature when faced with them. At some point, this will find its way into courtrooms under the rubric of a barrier to entry. It already has in terms of antitrust when a company wanted to move its PA prefix to different upstream. From fmartin at linkedin.com Fri Dec 9 13:12:39 2011 From: fmartin at linkedin.com (Franck Martin) Date: Fri, 9 Dec 2011 19:12:39 +0000 Subject: Sad IPv4 story? In-Reply-To: <3BB8E3D1-5D17-4D4C-8148-727660598EBD@ianai.net> Message-ID: Option 2) and think country wide ISP growing very fast. On 12/9/11 10:39 , "Patrick W. Gilmore" wrote: >On Dec 9, 2011, at 1:37 PM, Franck Martin wrote: > >> I just had a personal email from a brand new ISP in the Asia-Pacific >>area desperately looking for enough IPv4 to be able to run their >>business the way they would like? >> >> This is just a data point. > >Interesting data point. > >Would be more interesting to find out "the way they would like". For >instance, is it a "bullet-proof" hoster who promises each spammer 1K IP >addresses across dozens of discontiguous /24s? > >Or is it a DSL provider with 10K subs, and APNIC would only give them a >/22 until next year? > >-- >TTFN, >patrick > > From cscora at apnic.net Fri Dec 9 13:22:50 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 10 Dec 2011 05:22:50 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201112091922.pB9JMojO011592@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 10 Dec, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 384553 Prefixes after maximum aggregation: 167591 Deaggregation factor: 2.29 Unique aggregates announced to Internet: 188778 Total ASes present in the Internet Routing Table: 39528 Prefixes per ASN: 9.73 Origin-only ASes present in the Internet Routing Table: 32469 Origin ASes announcing only one prefix: 15507 Transit ASes present in the Internet Routing Table: 5346 Transit-only ASes present in the Internet Routing Table: 144 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 33 Max AS path prepend of ASN (48687) 24 Prefixes from unregistered ASNs in the Routing Table: 1864 Unregistered ASNs in the Routing Table: 973 Number of 32-bit ASNs allocated by the RIRs: 2059 Number of 32-bit ASNs visible in the Routing Table: 1713 Prefixes from 32-bit ASNs in the Routing Table: 4069 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 82 Number of addresses announced to Internet: 2499466496 Equivalent to 148 /8s, 250 /16s and 213 /24s Percentage of available address space announced: 67.4 Percentage of allocated address space announced: 67.4 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 91.7 Total number of prefixes smaller than registry allocations: 162332 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 95338 Total APNIC prefixes after maximum aggregation: 31228 APNIC Deaggregation factor: 3.05 Prefixes being announced from the APNIC address blocks: 91808 Unique aggregates announced from the APNIC address blocks: 38427 APNIC Region origin ASes present in the Internet Routing Table: 4601 APNIC Prefixes per ASN: 19.95 APNIC Region origin ASes announcing only one prefix: 1248 APNIC Region transit ASes present in the Internet Routing Table: 727 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 18 Number of APNIC region 32-bit ASNs visible in the Routing Table: 119 Number of APNIC addresses announced to Internet: 631071072 Equivalent to 37 /8s, 157 /16s and 97 /24s Percentage of available APNIC address space announced: 80.0 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-132095, 132096-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, 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: 146344 Total ARIN prefixes after maximum aggregation: 74781 ARIN Deaggregation factor: 1.96 Prefixes being announced from the ARIN address blocks: 118441 Unique aggregates announced from the ARIN address blocks: 48663 ARIN Region origin ASes present in the Internet Routing Table: 14799 ARIN Prefixes per ASN: 8.00 ARIN Region origin ASes announcing only one prefix: 5662 ARIN Region transit ASes present in the Internet Routing Table: 1579 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 25 Number of ARIN region 32-bit ASNs visible in the Routing Table: 12 Number of ARIN addresses announced to Internet: 803365568 Equivalent to 47 /8s, 226 /16s and 98 /24s Percentage of available ARIN address space announced: 63.8 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 93411 Total RIPE prefixes after maximum aggregation: 51508 RIPE Deaggregation factor: 1.81 Prefixes being announced from the RIPE address blocks: 85799 Unique aggregates announced from the RIPE address blocks: 55001 RIPE Region origin ASes present in the Internet Routing Table: 16170 RIPE Prefixes per ASN: 5.31 RIPE Region origin ASes announcing only one prefix: 7996 RIPE Region transit ASes present in the Internet Routing Table: 2557 Average RIPE Region AS path length visible: 4.7 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1199 Number of RIPE addresses announced to Internet: 493969856 Equivalent to 29 /8s, 113 /16s and 97 /24s Percentage of available RIPE address space announced: 79.6 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 36815 Total LACNIC prefixes after maximum aggregation: 7940 LACNIC Deaggregation factor: 4.64 Prefixes being announced from the LACNIC address blocks: 36277 Unique aggregates announced from the LACNIC address blocks: 18889 LACNIC Region origin ASes present in the Internet Routing Table: 1556 LACNIC Prefixes per ASN: 23.31 LACNIC Region origin ASes announcing only one prefix: 441 LACNIC Region transit ASes present in the Internet Routing Table: 289 Average LACNIC Region AS path length visible: 4.5 Max LACNIC Region AS path length visible: 18 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 379 Number of LACNIC addresses announced to Internet: 94673024 Equivalent to 5 /8s, 164 /16s and 152 /24s Percentage of available LACNIC address space announced: 62.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, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 8406 Total AfriNIC prefixes after maximum aggregation: 2062 AfriNIC Deaggregation factor: 4.08 Prefixes being announced from the AfriNIC address blocks: 6460 Unique aggregates announced from the AfriNIC address blocks: 2059 AfriNIC Region origin ASes present in the Internet Routing Table: 503 AfriNIC Prefixes per ASN: 12.84 AfriNIC Region origin ASes announcing only one prefix: 160 AfriNIC Region transit ASes present in the Internet Routing Table: 110 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 4 Number of AfriNIC addresses announced to Internet: 30395392 Equivalent to 1 /8s, 207 /16s and 204 /24s Percentage of available AfriNIC address space announced: 45.3 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2509 11104 970 Korea Telecom (KIX) 17974 1694 503 38 PT TELEKOMUNIKASI INDONESIA 7545 1631 303 86 TPG Internet Pty Ltd 4755 1511 385 158 TATA Communications formerly 7552 1392 1064 7 Vietel Corporation 9829 1170 989 28 BSNL National Internet Backbo 9583 1099 81 496 Sify Limited 4808 1076 2034 303 CNCGROUP IP network: China169 24560 982 381 162 Bharti Airtel Ltd., Telemedia 18101 960 122 155 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 3481 3814 218 bellsouth.net, inc. 7029 2916 1017 200 Windstream Communications Inc 18566 2093 383 177 Covad Communications 1785 1855 680 121 PaeTec Communications, Inc. 4323 1617 1073 385 Time Warner Telecom 20115 1602 1548 628 Charter Communications 22773 1505 2909 104 Cox Communications, Inc. 30036 1443 258 675 Mediacom Communications Corp 19262 1388 4683 401 Verizon Global Networks 7018 1309 7029 858 AT&T WorldNet Services 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 1581 480 15 Corbina telecom 6830 644 1927 412 UPC Distribution Services 34984 624 132 201 BILISIM TELEKOM 2118 550 99 14 EUnet/RELCOM Autonomous Syste 20940 544 174 434 Akamai Technologies European 3320 528 8161 394 Deutsche Telekom AG 12479 493 601 12 Uni2 Autonomous System 3292 480 2106 407 TDC Tele Danmark 8866 462 133 26 Bulgarian Telecommunication C 8551 423 366 45 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 1720 318 155 TVCABLE BOGOTA 28573 1549 1059 72 NET Servicos de Comunicao S.A 8151 1459 2985 349 UniNet S.A. de C.V. 7303 1239 751 174 Telecom Argentina Stet-France 27947 617 72 91 Telconet S.A 22047 582 322 17 VTR PUNTO NET S.A. 6503 554 434 68 AVANTEL, S.A. 7738 553 1050 31 Telecomunicacoes da Bahia S.A 3816 547 237 89 Empresa Nacional de Telecomun 11172 528 86 95 Servicios Alestra S.A de C.V Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 963 958 13 TEDATA 24863 785 146 35 LINKdotNET AS number 3741 281 939 230 The Internet Solution 15706 242 32 6 Sudatel Internet Exchange Aut 33776 240 13 8 Starcomms Nigeria Limited 6713 235 519 14 Itissalat Al-MAGHRIB 29571 217 17 13 Ci Telecom Autonomous system 12258 195 28 60 Vodacom Internet Company 24835 193 80 8 RAYA Telecom - Egypt 16637 164 664 83 MTN Network Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3481 3814 218 bellsouth.net, inc. 7029 2916 1017 200 Windstream Communications Inc 4766 2509 11104 970 Korea Telecom (KIX) 18566 2093 383 177 Covad Communications 1785 1855 680 121 PaeTec Communications, Inc. 10620 1720 318 155 TVCABLE BOGOTA 17974 1694 503 38 PT TELEKOMUNIKASI INDONESIA 7545 1631 303 86 TPG Internet Pty Ltd 4323 1617 1073 385 Time Warner Telecom 20115 1602 1548 628 Charter Communications 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 2916 2716 Windstream Communications Inc 18566 2093 1916 Covad Communications 1785 1855 1734 PaeTec Communications, Inc. 17974 1694 1656 PT TELEKOMUNIKASI INDONESIA 8402 1581 1566 Corbina telecom 10620 1720 1565 TVCABLE BOGOTA 7545 1631 1545 TPG Internet Pty Ltd 4766 2509 1539 Korea Telecom (KIX) 28573 1549 1477 NET Servicos de Comunicao S.A 22773 1505 1401 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 32873 UNALLOCATED 12.46.100.0/23 10912 InterNAP Network Ser 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.0.0/21 12654 RIPE NCC RIS Project 128.0.24.0/24 12654 RIPE NCC RIS Project Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 37.0.24.0/21 50794 AS Levira 37.1.88.0/21 50763 MCKAYCOM LTD 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.92.0/22 36936 >>UNKNOWN<< 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.21.192.0/20 11610 Internet Nebraska Corporation 64.21.212.0/22 11610 Internet Nebraska Corporation 64.21.216.0/21 11610 Internet Nebraska Corporation 66.171.32.0/20 705 UUNET Technologies, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:12 /10:27 /11:81 /12:236 /13:465 /14:812 /15:1442 /16:12042 /17:6104 /18:10146 /19:20068 /20:27797 /21:28040 /22:38213 /23:35782 /24:199713 /25:1176 /26:1417 /27:783 /28:170 /29:3 /30:0 /31:0 /32:5 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 2545 2916 Windstream Communications Inc 6389 2124 3481 bellsouth.net, inc. 18566 2042 2093 Covad Communications 10620 1615 1720 TVCABLE BOGOTA 8402 1556 1581 Corbina telecom 30036 1403 1443 Mediacom Communications Corp 11492 1116 1153 Cable One 1785 1060 1855 PaeTec Communications, Inc. 7011 1050 1166 Citizens Utilities 22773 966 1505 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:445 2:483 4:15 5:1 6:3 8:360 12:1944 13:1 14:557 15:11 16:3 17:7 20:9 23:72 24:1699 27:1113 31:721 32:67 33:2 34:2 36:4 38:771 39:1 40:114 41:2895 42:69 43:1 44:3 46:1127 47:3 49:228 50:459 52:13 55:5 56:2 57:45 58:945 59:487 60:342 61:1176 62:912 63:1970 64:4079 65:2307 66:4364 67:2004 68:1178 69:3141 70:916 71:362 72:1776 74:2639 75:431 76:319 77:937 78:886 79:439 80:1142 81:847 82:521 83:529 84:470 85:1169 86:409 87:910 88:353 89:1589 90:247 91:4340 92:539 93:1408 94:1324 95:1131 96:395 97:285 98:784 99:38 101:122 103:538 106:8 107:106 108:95 109:1096 110:670 111:823 112:375 113:485 114:617 115:703 116:876 117:712 118:878 119:1240 120:343 121:681 122:1557 123:1022 124:1365 125:1341 128:275 129:189 130:181 131:579 132:158 133:21 134:221 135:55 136:212 137:147 138:286 139:123 140:491 141:254 142:382 143:404 144:505 145:66 146:474 147:222 148:638 149:272 150:165 151:192 152:445 153:171 154:7 155:380 156:209 157:358 158:156 159:503 160:334 161:221 162:363 163:183 164:523 165:387 166:542 167:459 168:818 169:146 170:823 171:90 172:4 173:1786 174:591 175:415 176:339 177:429 178:1138 180:1173 181:38 182:675 183:253 184:399 185:1 186:1480 187:785 188:939 189:1173 190:5288 192:5969 193:5121 194:3797 195:3366 196:1273 197:172 198:3618 199:4216 200:5543 201:1702 202:8486 203:8523 204:4328 205:2404 206:2670 207:2842 208:4015 209:3558 210:2755 211:1469 212:1982 213:1795 214:822 215:92 216:4934 217:1488 218:578 219:344 220:1250 221:529 222:326 223:262 End of report From bensons at queuefull.net Fri Dec 9 14:47:06 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 9 Dec 2011 14:47:06 -0600 Subject: Sad IPv4 story? In-Reply-To: <4971DF7F-09FC-42C0-98A9-F3C60FF146D1@cisco.com> References: <4971DF7F-09FC-42C0-98A9-F3C60FF146D1@cisco.com> Message-ID: <0FCEFA7E-C7E6-4AEC-B72C-755CF3228E8E@queuefull.net> On Dec 9, 2011, at 1:07 PM, Fred Baker wrote: > On Dec 9, 2011, at 10:37 AM, Franck Martin wrote: > >> I just had a personal email from a brand new ISP in the Asia-Pacific area desperately looking for enough IPv4 to be able to run their business the way they would like? >> >> This is just a data point. > > We're going to be hearing a lot more of these. It's the nature of finite resources, and of human nature when faced with them. At some point, this will find its way into courtrooms under the rubric of a barrier to entry. It already has in terms of antitrust when a company wanted to move its PA prefix to different upstream. +1 to Fred's comments. Hopefully, the existence of an open IPv4 address market will help avoid some of the worst. (At least for a while, until the rising prices get too high for a competitive environment. And maybe by then the price of IPv4 addresses will have made IPv6 deployment a much more obvious choice to reluctant CFO-types.) Cheers, -Benson --- Disclaimers: 1. I am not a lawyer, and nothing in this message should be construed as advice. 2. I, Benson Schliesser, am an employee of Cisco Systems; however, opinions expressed in this email are my own views and not those of Cisco Systems or anybody else. From mark at exonetric.com Fri Dec 9 14:57:22 2011 From: mark at exonetric.com (Mark Blackman) Date: Fri, 9 Dec 2011 20:57:22 +0000 Subject: Sad IPv4 story? In-Reply-To: <0FCEFA7E-C7E6-4AEC-B72C-755CF3228E8E@queuefull.net> References: <4971DF7F-09FC-42C0-98A9-F3C60FF146D1@cisco.com> <0FCEFA7E-C7E6-4AEC-B72C-755CF3228E8E@queuefull.net> Message-ID: <1B40C293-E7A7-4C17-ACF0-EBE6FE4F42A4@exonetric.com> On 9 Dec 2011, at 20:47, Benson Schliesser wrote: > > On Dec 9, 2011, at 1:07 PM, Fred Baker wrote: > >> On Dec 9, 2011, at 10:37 AM, Franck Martin wrote: >> >>> I just had a personal email from a brand new ISP in the Asia-Pacific area desperately looking for enough IPv4 to be able to run their business the way they would like? >>> >>> This is just a data point. >> >> We're going to be hearing a lot more of these. It's the nature of finite resources, and of human nature when faced with them. At some point, this will find its way into courtrooms under the rubric of a barrier to entry. It already has in terms of antitrust when a company wanted to move its PA prefix to different upstream. I've had transit service pulled, so the provider can reclaim the /21 that was bundled with the transit. - Mark From bensons at queuefull.net Fri Dec 9 15:05:12 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 9 Dec 2011 15:05:12 -0600 Subject: Sad IPv4 story? In-Reply-To: <1B40C293-E7A7-4C17-ACF0-EBE6FE4F42A4@exonetric.com> References: <4971DF7F-09FC-42C0-98A9-F3C60FF146D1@cisco.com> <0FCEFA7E-C7E6-4AEC-B72C-755CF3228E8E@queuefull.net> <1B40C293-E7A7-4C17-ACF0-EBE6FE4F42A4@exonetric.com> Message-ID: <4E600760-233F-4F9F-B30D-8A3931271548@queuefull.net> On Dec 9, 2011, at 2:57 PM, Mark Blackman wrote: >> On Dec 9, 2011, at 1:07 PM, Fred Baker wrote: >>> We're going to be hearing a lot more of these. It's the nature of finite resources, and of human nature when faced with them. At some point, this will find its way into courtrooms under the rubric of a barrier to entry. It already has in terms of antitrust when a company wanted to move its PA prefix to different upstream. > > I've had transit service pulled, so the provider can reclaim the /21 that was bundled with the transit. I'm sorry to hear about that... Do you know why they reclaimed the block? E.g. was it used to support a "higher margin" service for another customer? -Benson From mark at exonetric.com Fri Dec 9 15:11:32 2011 From: mark at exonetric.com (Mark Blackman) Date: Fri, 9 Dec 2011 21:11:32 +0000 Subject: Sad IPv4 story? In-Reply-To: <4E600760-233F-4F9F-B30D-8A3931271548@queuefull.net> References: <4971DF7F-09FC-42C0-98A9-F3C60FF146D1@cisco.com> <0FCEFA7E-C7E6-4AEC-B72C-755CF3228E8E@queuefull.net> <1B40C293-E7A7-4C17-ACF0-EBE6FE4F42A4@exonetric.com> <4E600760-233F-4F9F-B30D-8A3931271548@queuefull.net> Message-ID: On 9 Dec 2011, at 21:05, Benson Schliesser wrote: > > On Dec 9, 2011, at 2:57 PM, Mark Blackman wrote: >>> On Dec 9, 2011, at 1:07 PM, Fred Baker wrote: >>>> We're going to be hearing a lot more of these. It's the nature of finite resources, and of human nature when faced with them. At some point, this will find its way into courtrooms under the rubric of a barrier to entry. It already has in terms of antitrust when a company wanted to move its PA prefix to different upstream. >> >> I've had transit service pulled, so the provider can reclaim the /21 that was bundled with the transit. > > I'm sorry to hear about that... Do you know why they reclaimed the block? E.g. was it used to support a "higher margin" service for another customer? > > -Benson Leased line customers. From Valdis.Kletnieks at vt.edu Fri Dec 9 15:12:21 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 09 Dec 2011 16:12:21 -0500 Subject: Sad IPv4 story? In-Reply-To: Your message of "Fri, 09 Dec 2011 14:47:06 CST." <0FCEFA7E-C7E6-4AEC-B72C-755CF3228E8E@queuefull.net> References: <4971DF7F-09FC-42C0-98A9-F3C60FF146D1@cisco.com> <0FCEFA7E-C7E6-4AEC-B72C-755CF3228E8E@queuefull.net> Message-ID: <14031.1323465141@turing-police.cc.vt.edu> On Fri, 09 Dec 2011 14:47:06 CST, Benson Schliesser said: > +1 to Fred's comments. Hopefully, the existence of an open IPv4 address > market will help avoid some of the worst. (At least for a while, until > the rising prices get too high for a competitive environment. And maybe > by then the price of IPv4 addresses will have made IPv6 deployment a > much more obvious choice to reluctant CFO-types.) I suspect the opposite is in fact true - if there is an open market, many sites will continue deluding themselves and make the end game that much more painful. If you haven't been able to sell the CFO types on the need to deploy IPv6 *yet* (consider that you *should* have been specifying "Ipv6-ready" on capex for at least 4-5 years already, so most of the gear on the floor should be ready to go), you're going to be *screwed* when you finally get moving. Among other things, all the *good* IPv6 experts will already have found good gigs, and it's gonna either take a bigger paycheck to headhunt one, or you'll be stuck with the dregs of the market (either way, it will cost you more). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jared at puck.nether.net Fri Dec 9 15:16:08 2011 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 9 Dec 2011 16:16:08 -0500 Subject: Sad IPv4 story? In-Reply-To: <14031.1323465141@turing-police.cc.vt.edu> References: <4971DF7F-09FC-42C0-98A9-F3C60FF146D1@cisco.com> <0FCEFA7E-C7E6-4AEC-B72C-755CF3228E8E@queuefull.net> <14031.1323465141@turing-police.cc.vt.edu> Message-ID: On Dec 9, 2011, at 4:12 PM, Valdis.Kletnieks at vt.edu wrote: > I suspect the opposite is in fact true - if there is an open market, many sites > will continue deluding themselves and make the end game that much more painful. > If you haven't been able to sell the CFO types on the need to deploy IPv6 *yet* > (consider that you *should* have been specifying "Ipv6-ready" on capex for at > least 4-5 years already, so most of the gear on the floor should be ready to > go), you're going to be *screwed* when you finally get moving. Among other > things, all the *good* IPv6 experts will already have found good gigs, and it's > gonna either take a bigger paycheck to headhunt one, or you'll be stuck with > the dregs of the market (either way, it will cost you more). I've had recruiters calling me about IPv6 related jobs for at least 2 years now. Some are full-time, others contract work. If you haven't IPv6 enabled your capable devices yet, get on it. Most providers will give you IPv6 for free now, and will allocate you space from their blocks. If you are an ARIN member, you can get your block of IPv6 address by submitting a simple form as long as you already have IPv4 space. Get on it, make them work this month and have your space already allocated prior to the start of 2012. - jared From dougb at dougbarton.us Fri Dec 9 15:20:12 2011 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 09 Dec 2011 13:20:12 -0800 Subject: Sad IPv4 story? In-Reply-To: References: <4971DF7F-09FC-42C0-98A9-F3C60FF146D1@cisco.com> <0FCEFA7E-C7E6-4AEC-B72C-755CF3228E8E@queuefull.net> <14031.1323465141@turing-police.cc.vt.edu> Message-ID: <4EE27B8C.5000707@dougbarton.us> On 12/09/2011 13:16, Jared Mauch wrote: > I've had recruiters calling me about IPv6 related jobs for at least 2 years now. > > Some are full-time, others contract work. +1, mostly contract stuff that I've had to turn down because my travel capacity is limited nowadays. From the standpoint of IPv6, it's already "next quarter." Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From tom.ammon at utah.edu Fri Dec 9 15:33:58 2011 From: tom.ammon at utah.edu (Tom Ammon) Date: Fri, 9 Dec 2011 21:33:58 +0000 Subject: best DHCPv6 server? Message-ID: <34FB1D1922F27F439B677D238AF0A4AC03A6B1@X-MB10.xds.umail.utah.edu> Hi All, I'm wondering, what would you say is the best DHCPv6 server for a large enterprise? We've played with dibbler and the ISC server, and have had some interesting (and annoying) results with the ISC server. At first blush, dibbler appears to work better. Thoughts? Tom ----------------------------------------------------------------------------- Tom Ammon Network Engineer M: (801)674-9273 tom.ammon at utah.edu Center for High Performance Computing University of Utah http://www.chpc.utah.edu ----------------------------------------------------------------------------- From deepak at ai.net Fri Dec 9 15:38:12 2011 From: deepak at ai.net (Deepak Jain) Date: Fri, 09 Dec 2011 16:38:12 -0500 Subject: Sad IPv4 story? In-Reply-To: References: <4971DF7F-09FC-42C0-98A9-F3C60FF146D1@cisco.com> <0FCEFA7E-C7E6-4AEC-B72C-755CF3228E8E@queuefull.net> <14031.1323465141@turing-police.cc.vt.edu> Message-ID: <4EE27FC4.7070201@ai.net> > If you haven't IPv6 enabled your capable devices yet, get on it. Most providers > will give you IPv6 for free now, and will allocate you space from their blocks. > > If you are an ARIN member, you can get your block of IPv6 address by submitting a simple > form as long as you already have IPv4 space. > > Get on it, make them work this month and have your space already allocated prior to the > start of 2012. > I can tell you that (as of Dec 2011) *lots and lots* of networks (big ones, even some of the biggest) are in no real position to support nearly universal customer IPv6 service yet. There are networks that have IPv6 "somewhere".. but even where we've been requesting IPv6 turned up alongside existing IPv4 sessions sometimes the turnaround is months and months with lots of repeated banging -- even where the gear and the uplinks support it. Some of this is that (esp internal) tools still aren't where they need to be. Some of this is that once we IPv6 becomes the "standard"... well, security and other concerns will challenge all the infrastructure in place. And this is all before you get into issues of inconsistent views of the IPv6 RIB, and the rest. Just my opinion, hopefully someone else has a better experience. DJ From owen at delong.com Fri Dec 9 15:37:04 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 9 Dec 2011 16:37:04 -0500 Subject: Sad IPv4 story? In-Reply-To: References: <4971DF7F-09FC-42C0-98A9-F3C60FF146D1@cisco.com> <0FCEFA7E-C7E6-4AEC-B72C-755CF3228E8E@queuefull.net> <14031.1323465141@turing-police.cc.vt.edu> Message-ID: > > > > If you are an ARIN member, you can get your block of IPv6 address by submitting a simple > form as long as you already have IPv4 space. > Not exactly... 1. You don't have to be an ARIN member. 2. Even if you don't have IPv4 space, you can still use a simple form. You just need to put a little more information on that form. Owen From cidr-report at potaroo.net Fri Dec 9 16:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 9 Dec 2011 22:00:00 GMT Subject: BGP Update Report Message-ID: <201112092200.pB9M00Mi088244@wattle.apnic.net> BGP Update Report Interval: 01-Dec-11 -to- 08-Dec-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS42116 216141 10.4% 3929.8 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 2 - AS8402 45654 2.2% 28.6 -- CORBINA-AS OJSC "Vimpelcom" 3 - AS24560 44354 2.1% 46.3 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 4 - AS9829 30074 1.4% 47.8 -- BSNL-NIB National Internet Backbone 5 - AS44568 25231 1.2% 2803.4 -- OPSOURCE-UK OpSource, Inc 6 - AS32528 25070 1.2% 6267.5 -- ABBOTT Abbot Labs 7 - AS5800 24783 1.2% 90.4 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 8 - AS7552 24639 1.2% 17.8 -- VIETEL-AS-AP Vietel Corporation 9 - AS19743 20793 1.0% 2970.4 -- 10 - AS20632 19982 1.0% 587.7 -- PETERSTAR-AS PeterStar 11 - AS11830 18116 0.9% 55.2 -- Instituto Costarricense de Electricidad y Telecom. 12 - AS31148 17299 0.8% 41.7 -- FREENET-AS FreeNet ISP 13 - AS27738 15592 0.8% 45.9 -- Ecuadortelecom S.A. 14 - AS6316 15209 0.7% 227.0 -- AS-PAETEC-NET - PaeTec Communications, Inc. 15 - AS1785 13444 0.7% 7.9 -- AS-PAETEC-NET - PaeTec Communications, Inc. 16 - AS19223 12864 0.6% 12864.0 -- NTEGRATED-SOLUTIONS - Ntegrated Solutions 17 - AS17974 12226 0.6% 8.2 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 18 - AS39353 11648 0.6% 3882.7 -- PRINCAST-AS Gobierno del Principado de Asturias 19 - AS27964 10851 0.5% 97.8 -- RSONet 20 - AS14420 10482 0.5% 21.6 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS19223 12864 0.6% 12864.0 -- NTEGRATED-SOLUTIONS - Ntegrated Solutions 2 - AS18823 8516 0.4% 8516.0 -- MEDICALERT - Medicalert Foundation 3 - AS32528 25070 1.2% 6267.5 -- ABBOTT Abbot Labs 4 - AS42116 216141 10.4% 3929.8 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 5 - AS39353 11648 0.6% 3882.7 -- PRINCAST-AS Gobierno del Principado de Asturias 6 - AS19743 20793 1.0% 2970.4 -- 7 - AS44568 25231 1.2% 2803.4 -- OPSOURCE-UK OpSource, Inc 8 - AS37378 2590 0.1% 2590.0 -- NIGERIA-AIRFORCE 9 - AS6066 3542 0.2% 1771.0 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc. 10 - AS10209 1634 0.1% 1634.0 -- SYNOPSYS-AS-JP-AP Japan HUB and Data Center 11 - AS28170 4351 0.2% 1087.8 -- 12 - AS53362 928 0.0% 928.0 -- MIXIT-AS - Mixit, Inc. 13 - AS55696 755 0.0% 755.0 -- SCOM-AS-ID Starcom Solusindo PT. 14 - AS8163 749 0.0% 749.0 -- METROTEL REDES S.A. 15 - AS6072 9646 0.5% 689.0 -- UNISYS-6072 For routing issues, email hostmaster at unisys.com 16 - AS22878 6905 0.3% 627.7 -- ASACENET1 - ACENET, INC. 17 - AS20632 19982 1.0% 587.7 -- PETERSTAR-AS PeterStar 18 - AS11943 558 0.0% 558.0 -- GLOBE - Globe Wireless 19 - AS19674 1596 0.1% 532.0 -- NAVPOINT - Navpoint Internet 20 - AS33076 524 0.0% 524.0 -- ISC-TGD1 Internet Systems Consortium, Inc. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 84.204.132.0/24 19878 0.9% AS20632 -- PETERSTAR-AS PeterStar 2 - 67.97.156.0/24 12864 0.6% AS19223 -- NTEGRATED-SOLUTIONS - Ntegrated Solutions 3 - 130.36.34.0/24 12533 0.6% AS32528 -- ABBOTT Abbot Labs 4 - 130.36.35.0/24 12533 0.6% AS32528 -- ABBOTT Abbot Labs 5 - 88.151.16.0/22 11646 0.5% AS39353 -- PRINCAST-AS Gobierno del Principado de Asturias 6 - 66.248.96.0/21 9872 0.5% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 7 - 75.141.48.0/24 8516 0.4% AS18823 -- MEDICALERT - Medicalert Foundation 8 - 95.78.100.0/22 8417 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 9 - 46.147.84.0/22 8411 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 10 - 46.147.92.0/22 8404 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 11 - 95.78.104.0/22 8391 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 12 - 95.78.88.0/22 8390 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 13 - 95.78.80.0/22 8389 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 14 - 95.78.16.0/22 8388 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 15 - 176.213.100.0/22 8388 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 16 - 95.78.108.0/22 8377 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 17 - 46.147.88.0/22 8376 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 18 - 95.78.12.0/22 8376 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 19 - 95.78.20.0/22 8376 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 20 - 46.147.80.0/22 8365 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 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 cidr-report at potaroo.net Fri Dec 9 16:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 9 Dec 2011 22:00:00 GMT Subject: The Cidr Report Message-ID: <201112092200.pB9M00JM088239@wattle.apnic.net> This report has been generated at Fri Dec 9 21:12:30 2011 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 02-12-11 385297 226100 03-12-11 385231 226034 04-12-11 385299 226287 05-12-11 385441 226550 06-12-11 385599 226848 07-12-11 385865 226928 08-12-11 385744 227259 09-12-11 386491 227289 AS Summary 39626 Number of ASes in routing system 16690 Number of ASes announcing only one prefix 3481 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 109030400 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'). --- 09Dec11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 386646 227364 159282 41.2% All ASes AS6389 3481 221 3260 93.7% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS18566 2093 412 1681 80.3% COVAD - Covad Communications Co. AS4766 2513 993 1520 60.5% KIXS-AS-KR Korea Telecom AS7029 2957 1524 1433 48.5% WINDSTREAM - Windstream Communications Inc AS22773 1505 113 1392 92.5% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1508 213 1295 85.9% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS4323 1618 387 1231 76.1% TWTC - tw telecom holdings, inc. AS28573 1549 402 1147 74.0% NET Servicos de Comunicao S.A. AS1785 1858 783 1075 57.9% AS-PAETEC-NET - PaeTec Communications, Inc. AS10620 1721 702 1019 59.2% Telmex Colombia S.A. AS19262 1388 401 987 71.1% VZGNI-TRANSIT - Verizon Online LLC AS7552 1305 421 884 67.7% VIETEL-AS-AP Vietel Corporation AS7303 1239 359 880 71.0% Telecom Argentina S.A. AS8402 1507 667 840 55.7% CORBINA-AS OJSC "Vimpelcom" AS18101 963 156 807 83.8% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS8151 1459 657 802 55.0% Uninet S.A. de C.V. AS30036 1443 681 762 52.8% MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp AS4808 1076 334 742 69.0% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7545 1630 946 684 42.0% TPG-INTERNET-AP TPG Internet Pty Ltd AS3356 1105 457 648 58.6% LEVEL3 Level 3 Communications AS17676 675 74 601 89.0% GIGAINFRA Softbank BB Corp. AS4804 663 95 568 85.7% MPX-AS Microplex PTY LTD AS17974 1694 1133 561 33.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS20115 1602 1043 559 34.9% CHARTER-NET-HKY-NC - Charter Communications AS22561 931 376 555 59.6% DIGITAL-TELEPORT - Digital Teleport Inc. AS22047 582 33 549 94.3% VTR BANDA ANCHA S.A. AS3549 959 415 544 56.7% GBLX Global Crossing Ltd. AS24560 982 448 534 54.4% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7011 1167 647 520 44.6% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS17488 931 412 519 55.7% HATHWAY-NET-AP Hathway IP Over Cable Internet Total 44104 15505 28599 64.8% 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- 37.1.88.0/21 AS50763 MCKAYCOM MCKAYCOM LTD 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.175.222.0/23 AS30058 FDCSERVERS - FDCservers.net 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 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 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 80.88.10.0/24 AS33774 DJAWEB 98.159.96.0/20 AS46975 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 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 Inc. 172.45.1.0/24 AS29571 CITelecom-AS 172.45.2.0/24 AS29571 CITelecom-AS 172.45.3.0/24 AS29571 CITelecom-AS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 190.104.32.0/21 AS27882 Telef?nica Celular de Bolivia S.A. 200.6.93.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.94.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.95.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.23.84.0/24 AS8151 Uninet S.A. de C.V. 200.24.73.0/24 AS26061 Equant Colombia 200.33.40.0/24 AS11172 Alestra, S. de R.L. de C.V. 200.34.0.0/20 AS6342 Instituto Tecnol?gico y de Estudios Superiores de Monterrey 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 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.9.55.0/24 AS2764 AAPT AAPT Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 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.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.160.152.0/22 AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 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.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 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 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 209.222.240.0/22 AS19747 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From jared at puck.nether.net Fri Dec 9 16:04:49 2011 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 9 Dec 2011 17:04:49 -0500 Subject: Sad IPv4 story? In-Reply-To: <4EE27FC4.7070201@ai.net> References: <4971DF7F-09FC-42C0-98A9-F3C60FF146D1@cisco.com> <0FCEFA7E-C7E6-4AEC-B72C-755CF3228E8E@queuefull.net> <14031.1323465141@turing-police.cc.vt.edu> <4EE27FC4.7070201@ai.net> Message-ID: <0D317931-9E45-46BF-98C4-05D7C124A3AF@puck.nether.net> On Dec 9, 2011, at 4:38 PM, Deepak Jain wrote: > I can tell you that (as of Dec 2011) *lots and lots* of networks (big ones, even some of the biggest) are in no real position to support nearly universal customer IPv6 service yet. There are networks that have IPv6 "somewhere".. but even where we've been requesting IPv6 turned up alongside existing IPv4 sessions sometimes the turnaround is months and months with lots of repeated banging -- even where the gear and the uplinks support it. I think you are working with the wrong carriers in that case perhaps? As part of a turn-up this year, IPv6 was a standard question, including the IP/BGP request form that had separate tabs for IPv6 and address space requests along-side the IPv4 BGP/space request. The cases were with Cogent and Abovenet for connections in the US. I know that NTT can also do IPv6 as well. I think that some of what you may be terming the big-guys such as at&t and verizon/uunet are still behind the curve but they are largely in the managed services and not internet space from what I can tell. Internet is a side thing they sell and not a primary line of business. > Some of this is that (esp internal) tools still aren't where they need to be. Some of this is that once we IPv6 becomes the "standard"... well, security and other concerns will challenge all the infrastructure in place. I do agree that most tools seem to be IPv4 centric these days at least for management of the device (Eg: no SNMP over IPv6 only). You can do much of the monitoring over IPv6. > And this is all before you get into issues of inconsistent views of the IPv6 RIB, and the rest. While this still exists, this is something that will resolve itself with increased adoption. > > Just my opinion, hopefully someone else has a better experience. My experience as well. - Jared From dr at cluenet.de Fri Dec 9 16:55:28 2011 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 9 Dec 2011 23:55:28 +0100 Subject: Juniper <-> Cisco IPv6 BGP peering In-Reply-To: References: Message-ID: <20111209225528.GA21768@srv03.cluenet.de> On Fri, Dec 09, 2011 at 11:38:44AM -0500, Randy Carpenter wrote: > > 1) is Cisco sending NS packets? > > Yes. > > > 2) is your Juniper receiving them? > > It does not appear to. Tracing v6 stuff on juniper seems to be hit or miss. [...] > > Any switch on the path? > > It is an L2 circuit that rides a couple of different pieces of gear before it lands at the other side. Sounds like this equipment having problems with IPv6 multicast... Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From matthew at matthew.at Fri Dec 9 17:01:06 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 09 Dec 2011 15:01:06 -0800 Subject: seeking clueful assistance at speakeasy-now-megapath In-Reply-To: <4EE19F88.5070504@matthew.at> References: <4EE19F88.5070504@matthew.at> Message-ID: <4EE29332.6030203@matthew.at> On 12/8/2011 9:41 PM, Matthew Kaufman wrote: > See subject. Contact me off-list please. > > Matthew Kaufman > Six helpful responses later and the issue is resolved. Thanks to everyone who reached out. Matthew Kaufman From furry13 at gmail.com Fri Dec 9 18:06:58 2011 From: furry13 at gmail.com (Jen Linkova) Date: Sat, 10 Dec 2011 11:06:58 +1100 Subject: Juniper <-> Cisco IPv6 BGP peering In-Reply-To: <20111209225528.GA21768@srv03.cluenet.de> References: <20111209225528.GA21768@srv03.cluenet.de> Message-ID: On Sat, Dec 10, 2011 at 9:55 AM, Daniel Roesen wrote: >> > Any switch on the path? >> >> It is an L2 circuit that rides a couple of different pieces of gear before it lands at the other side. > > Sounds like this equipment having problems with IPv6 multicast... Yep, that's why I was asking - but it doesn't explain how/why ND for GUA works in this case. -- SY, Jen Linkova aka Furry From keegan.holley at sungard.com Fri Dec 9 20:22:40 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Fri, 9 Dec 2011 21:22:40 -0500 Subject: Writable SNMP In-Reply-To: References: <1AB264E2-E1BC-41BF-BF9B-89BF642FFC4E@puck.nether.net> Message-ID: > > > > assumption that writable SNMP was a bad idea but have never actually > tried > > it. I was curious what others were using, netconf or just scripted > logins. > > I'm also fighting a losing battle to convince people that netconf isn't > > evil. It strikes me as odd that if I wanted to talk to a > database/website > > full of credit card and billing info there's a long list of API's I could > > use, but if I wanted to talk to the router or firewall in front of it I > can > > only use ssh or telnet. > > sad, right? there are millions of restful program writers, only a few > thousand network device programmers, and the vast majority of 'network > management' is done by people perfectly happy with 'cisco-works' :( > > according to the law of supply and demand, that would be.... demand? right? ;) From joelja at bogus.com Fri Dec 9 20:25:52 2011 From: joelja at bogus.com (Joel jaeggli) Date: Fri, 09 Dec 2011 18:25:52 -0800 Subject: Writable SNMP In-Reply-To: References: <1AB264E2-E1BC-41BF-BF9B-89BF642FFC4E@puck.nether.net> Message-ID: <4EE2C330.2090907@bogus.com> On 12/9/11 18:22 , Keegan Holley wrote: >> >> >>> assumption that writable SNMP was a bad idea but have never actually >> tried >>> it. I was curious what others were using, netconf or just scripted >> logins. >>> I'm also fighting a losing battle to convince people that netconf isn't >>> evil. It strikes me as odd that if I wanted to talk to a >> database/website >>> full of credit card and billing info there's a long list of API's I could >>> use, but if I wanted to talk to the router or firewall in front of it I >> can >>> only use ssh or telnet. http://www.juniper.net/support/products/netconf/ >> sad, right? there are millions of restful program writers, only a few >> thousand network device programmers, and the vast majority of 'network >> management' is done by people perfectly happy with 'cisco-works' :( >> >> > according to the law of supply and demand, that would be.... demand? right? > ;) > From keegan.holley at sungard.com Fri Dec 9 20:28:05 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Fri, 9 Dec 2011 21:28:05 -0500 Subject: Writable SNMP In-Reply-To: <4EE2C330.2090907@bogus.com> References: <1AB264E2-E1BC-41BF-BF9B-89BF642FFC4E@puck.nether.net> <4EE2C330.2090907@bogus.com> Message-ID: 2011/12/9 Joel jaeggli > On 12/9/11 18:22 , Keegan Holley wrote: > >> > >> > >>> assumption that writable SNMP was a bad idea but have never actually > >> tried > >>> it. I was curious what others were using, netconf or just scripted > >> logins. > >>> I'm also fighting a losing battle to convince people that netconf isn't > >>> evil. It strikes me as odd that if I wanted to talk to a > >> database/website > >>> full of credit card and billing info there's a long list of API's I > could > >>> use, but if I wanted to talk to the router or firewall in front of it I > >> can > >>> only use ssh or telnet. > > http://www.juniper.net/support/products/netconf/ > +1 sadly there are still those that think netconf is black magic hacker voodo though From keegan.holley at sungard.com Fri Dec 9 20:30:47 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Fri, 9 Dec 2011 21:30:47 -0500 Subject: Writable SNMP In-Reply-To: References: Message-ID: > > > > In lieu of a software upgrade, a workaround can be applied to certain IOS > > releases by disabling the ILMI community or "*ilmi" view and applying an > > access list to prevent unauthorized access to SNMP. Any affected system, > > regardless of software release, may be protected by filtering SNMP > traffic > > at a network perimeter or on individual devices. > > right, but as I said above, the community-string restrictions don't > help you in cases where you haven't filtered source-addresses in > loopback/copp :( people still get to grind on your router's snmp > process, maybe there's another way in, maybe there's a bug in the > snmpd :( > > even if you filtered you could still get spoofed traffic. What if some employee wrote code to trace route across your network and send spoofed packets with or without a good string. Provided you aren't filtering snmp at your edge, which many don't they could pretty easily melt your network with a few boxes. This is true of the ever present snmp poll as well. (conspiracy theory over) From kauer at biplane.com.au Sat Dec 10 00:17:57 2011 From: kauer at biplane.com.au (Karl Auer) Date: Sat, 10 Dec 2011 17:17:57 +1100 Subject: best DHCPv6 server? In-Reply-To: <34FB1D1922F27F439B677D238AF0A4AC03A6B1@X-MB10.xds.umail.utah.edu> References: <34FB1D1922F27F439B677D238AF0A4AC03A6B1@X-MB10.xds.umail.utah.edu> Message-ID: <1323497877.2480.105.camel@karl> On Fri, 2011-12-09 at 21:33 +0000, Tom Ammon wrote: > I'm wondering, what would you say is the best DHCPv6 server for a > large enterprise? We've played with dibbler and the ISC server, and > have had some interesting (and annoying) results with the ISC server. > At first blush, dibbler appears to work better. For capacity, speed, features, scalability, extensibility, configurability, automation, monitoring - Nominum's "DCS" software is unparalled. Oh, and it has full IPv6 support. Not to denigrate Dibbler, or ISC's DHCP server, both of which are excellent, but they do not stand comparison with DCS. It is truly industrial strength, in world where that phrase is badly over-used. The flip side - DCS is VERY expensive. I'm not a shareholder, just a very satisfied user. Happy to answer questions off-list. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: This is a digitally signed message part URL: From randy at psg.com Sat Dec 10 01:58:14 2011 From: randy at psg.com (Randy Bush) Date: Sat, 10 Dec 2011 16:58:14 +0900 Subject: Sad IPv4 story? In-Reply-To: References: Message-ID: > I just had a personal email from a brand new ISP in the Asia-Pacific > area desperately looking for enough IPv4 to be able to run their > business the way they would like? and we are supposed to be surprised or feel sorry? you're kidding, right? they're lucky to be in a/p. at least they can get a /22. i especially like the "the way they would like" part. the way i would like to run my business is to go into the office every friday and scoop up the cash that fell from the sky all week. reality is such a pain in the ass. randy From keegan.holley at sungard.com Sat Dec 10 02:15:01 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Sat, 10 Dec 2011 03:15:01 -0500 Subject: Sad IPv4 story? In-Reply-To: References: Message-ID: Sent from my iPhone On Dec 10, 2011, at 2:58 AM, Randy Bush wrote: >> I just had a personal email from a brand new ISP in the Asia-Pacific >> area desperately looking for enough IPv4 to be able to run their >> business the way they would like? > > and we are supposed to be surprised or feel sorry? you're kidding, > right? they're lucky to be in a/p. at least they can get a /22. > > i especially like the "the way they would like" part. the way i would > like to run my business is to go into the office every friday and scoop > up the cash that fell from the sky all week. > > reality is such a pain in the ass. > > randy > +1 aren't we way past all of the predicted exhaustion dates. There are slot of as's that have ignored this. > From o.calvano at gmail.com Sat Dec 10 03:03:04 2011 From: o.calvano at gmail.com (Olivier CALVANO) Date: Sat, 10 Dec 2011 10:03:04 +0100 Subject: Local Loop at Singapore Message-ID: Hi anyone have a contact of a local telco for buy a link in metro of the Singapore City ? We want connect a customer based at singapore to our rack of Equinix or * I-Advantage Thanks for your help best regards Olivier * From bmanning at vacation.karoshi.com Sat Dec 10 06:22:07 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 10 Dec 2011 12:22:07 +0000 Subject: Sad IPv4 story? In-Reply-To: References: Message-ID: <20111210122207.GA6072@vacation.karoshi.com.> On Sat, Dec 10, 2011 at 03:15:01AM -0500, Keegan Holley wrote: > > > Sent from my iPhone > > On Dec 10, 2011, at 2:58 AM, Randy Bush wrote: > > >> I just had a personal email from a brand new ISP in the Asia-Pacific > >> area desperately looking for enough IPv4 to be able to run their > >> business the way they would likeb& > > > > and we are supposed to be surprised or feel sorry? you're kidding, > > right? they're lucky to be in a/p. at least they can get a /22. > > > > i especially like the "the way they would like" part. the way i would > > like to run my business is to go into the office every friday and scoop > > up the cash that fell from the sky all week. > > > > reality is such a pain in the ass. > > > > randy > > > +1 aren't we way past all of the predicted exhaustion dates. There are slot of as's that have ignored this. > > > predictions are ... predictions! guesses. swag. nothing more/less. i will say this however. after fifteen years, I am exhausted listening to ipv6 v. ipv4 bickering. (and after five years of running native ipv6-only networks - i've re-introduced ipv4 to the mix... go figure) /bill From keegan.holley at sungard.com Sat Dec 10 10:17:32 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Sat, 10 Dec 2011 11:17:32 -0500 Subject: Sad IPv4 story? In-Reply-To: <4ee34f53.e616440a.269a.ffffd8dcSMTPIN_ADDED@mx.google.com> References: <4ee34f53.e616440a.269a.ffffd8dcSMTPIN_ADDED@mx.google.com> Message-ID: 2011/12/10 > On Sat, Dec 10, 2011 at 03:15:01AM -0500, Keegan Holley wrote: > > > > > > Sent from my iPhone > > > > On Dec 10, 2011, at 2:58 AM, Randy Bush wrote: > > > > >> I just had a personal email from a brand new ISP in the Asia-Pacific > > >> area desperately looking for enough IPv4 to be able to run their > > >> business the way they would likeb & > > > > > > and we are supposed to be surprised or feel sorry? you're kidding, > > > right? they're lucky to be in a/p. at least they can get a /22. > > > > > > i especially like the "the way they would like" part. the way i would > > > like to run my business is to go into the office every friday and scoop > > > up the cash that fell from the sky all week. > > > > > > reality is such a pain in the ass. > > > > > > randy > > > > > +1 aren't we way past all of the predicted exhaustion dates. There are > slot of as's that have ignored this. > > > > > > > predictions are ... predictions! guesses. swag. nothing > more/less. > > i will say this however. after fifteen years, I am exhausted > listening to > > ipv6 v. ipv4 bickering. (and after five years of running native > ipv6-only > > networks - i've re-introduced ipv4 to the mix... go figure) > > /bill > > I see your point. The world was supposed to end dozens of times as well. Sorry to hear you had to reintroduce v4. I suppose if dinosaurs were still around we'd have to capitulate to them too. The people who see a T-rex and say "hey I thought they were extinct?!" would just get eaten. but I digress. I'm not sure I'd open a new ISP at this point and expect to get any respectable amount of IP space from the RIR right now. From bmanning at vacation.karoshi.com Sat Dec 10 11:07:06 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 10 Dec 2011 17:07:06 +0000 Subject: Sad IPv4 story? In-Reply-To: References: <4ee34f53.e616440a.269a.ffffd8dcSMTPIN_ADDED@mx.google.com> Message-ID: <20111210170706.GA6745@vacation.karoshi.com.> On Sat, Dec 10, 2011 at 11:17:32AM -0500, Keegan Holley wrote: > 2011/12/10 > > > On Sat, Dec 10, 2011 at 03:15:01AM -0500, Keegan Holley wrote: > > > > > > > > > Sent from my iPhone > > > > > > On Dec 10, 2011, at 2:58 AM, Randy Bush wrote: > > > > > > >> I just had a personal email from a brand new ISP in the Asia-Pacific > > > >> area desperately looking for enough IPv4 to be able to run their > > > >> business the way they would likeb & > > > > > > > > and we are supposed to be surprised or feel sorry? you're kidding, > > > > right? they're lucky to be in a/p. at least they can get a /22. > > > > > > > > i especially like the "the way they would like" part. the way i would > > > > like to run my business is to go into the office every friday and scoop > > > > up the cash that fell from the sky all week. > > > > > > > > reality is such a pain in the ass. > > > > > > > > randy > > > > > > > +1 aren't we way past all of the predicted exhaustion dates. There are > > slot of as's that have ignored this. > > > > > > > > > > > predictions are ... predictions! guesses. swag. nothing > > more/less. > > > > i will say this however. after fifteen years, I am exhausted > > listening to > > > > ipv6 v. ipv4 bickering. (and after five years of running native > > ipv6-only > > > > networks - i've re-introduced ipv4 to the mix... go figure) > > > > /bill > > > > I see your point. The world was supposed to end dozens of times as well. > Sorry to hear you had to reintroduce v4. I suppose if dinosaurs were > still around we'd have to capitulate to them too. The people who see a > T-rex and say "hey I thought they were extinct?!" would just get eaten. but > I digress. I'm not sure I'd open a new ISP at this point and expect to get > any respectable amount of IP space from the RIR right now. funny thing about tools. good ones are around and used for years, decades, centuries, while others have a much shorter shelf life. the craftsman 3/16" and the 1/4" phillips I got from my grandfather and will likely end up w/ one of my grandsons. the pocket fisherman and the 87blade pocket knife are ebay fodder... its not about capitulation, its about usefullness. the only concern about IPv4 these days is one of global uniqueness. the big win, if you can call it a big win is that there is much less potential pressure on the global routing table if you stick w/ IPv4. (*) * in both v4/v6 families, the prospect of fully routing /32s scares to socks off most sane engineers. the horror of v6 is fully routing /48s!!!! /bill From netsecguy at gmail.com Sat Dec 10 13:49:01 2011 From: netsecguy at gmail.com (NetSecGuy) Date: Sat, 10 Dec 2011 14:49:01 -0500 Subject: Inaccessible network from Verizon, accessible elsewhere. Message-ID: I have a Linode VPS in Japan that I can't access from Verizon FIOS, but can access from other locations. I'm not sure who to blame. The host, 106.187.34.33, is behind the gateway 106.187.34.1: >From FIOS to 106.187.34.1 (this works). traceroute to 106.187.34.1 (106.187.34.1), 64 hops max, 52 byte packets 4 so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4) 9.960 ms 9.957 ms 6.666 ms 5 so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3) 12.298 ms 13.463 ms 13.706 ms 6 0.ae2.br1.iad8.alter.net (152.63.32.158) 14.571 ms 14.372 ms 14.003 ms 7 204.255.169.218 (204.255.169.218) 14.692 ms 14.759 ms 13.670 ms 8 sl-crs1-dc-0-1-0-0.sprintlink.net (144.232.19.229) 13.077 ms 12.577 ms 14.954 ms 9 sl-crs1-nsh-0-5-5-0.sprintlink.net (144.232.18.200) 31.443 ms sl-crs1-dc-0-5-3-0.sprintlink.net (144.232.24.37) 33.005 ms sl-crs1-nsh-0-5-5-0.sprintlink.net (144.232.18.200) 31.507 ms 10 sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112) 57.610 ms 58.322 ms 59.098 ms 11 otejbb204.kddnet.ad.jp (203.181.100.45) 196.063 ms otejbb203.kddnet.ad.jp (203.181.100.13) 188.846 ms otejbb204.kddnet.ad.jp (203.181.100.21) 195.277 ms 12 cm-fcu203.kddnet.ad.jp (124.215.194.180) 214.760 ms cm-fcu203.kddnet.ad.jp (124.215.194.164) 198.925 ms cm-fcu203.kddnet.ad.jp (124.215.194.180) 200.583 ms 13 124.215.199.122 (124.215.199.122) 193.086 ms * 194.967 ms This does not work from FIOS: traceroute to 106.187.34.33 (106.187.34.33), 64 hops max, 52 byte packets 4 so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4) 34.229 ms 8.743 ms 8.878 ms 5 so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3) 15.402 ms 13.008 ms 14.932 ms 6 0.ae2.br1.iad8.alter.net (152.63.32.158) 13.325 ms 13.245 ms 13.802 ms 7 204.255.169.218 (204.255.169.218) 14.820 ms 14.232 ms 13.491 ms 8 lap-brdr-03.inet.qwest.net (67.14.22.78) 90.170 ms 92.273 ms 145.887 ms 9 63.146.26.70 (63.146.26.70) 92.482 ms 92.287 ms 94.000 ms 10 sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112) 58.135 ms 58.520 ms 58.055 ms 11 otejbb203.kddnet.ad.jp (203.181.100.17) 205.844 ms otejbb204.kddnet.ad.jp (203.181.100.25) 189.929 ms otejbb203.kddnet.ad.jp (203.181.100.17) 204.846 ms 12 sl-crs1-oro-0-1-5-0.sprintlink.net (144.232.25.77) 87.229 ms sl-crs1-oro-0-3-3-0.sprintlink.net (144.232.25.207) 88.796 ms 88.717 ms 13 124.215.199.122 (124.215.199.122) 193.584 ms 202.208 ms 192.989 ms 14 * * * Same IP from different network: traceroute to 106.187.34.33 (106.187.34.33), 30 hops max, 60 byte packets 6 ae-8-8.ebr2.Washington1.Level3.net (4.69.134.105) 2.230 ms 1.847 ms 1.938 ms 7 ae-92-92.csw4.Washington1.Level3.net (4.69.134.158) 2.010 ms 1.985 ms ae-62-62.csw1.Washington1.Level3.net (4.69.134.146) 1.942 ms 8 ae-94-94.ebr4.Washington1.Level3.net (4.69.134.189) 12.515 ms ae-74-74.ebr4.Washington1.Level3.net (4.69.134.181) 12.519 ms 12.507 ms 9 ae-4-4.ebr3.LosAngeles1.Level3.net (4.69.132.81) 65.957 ms 65.958 ms 66.056 ms 10 ae-83-83.csw3.LosAngeles1.Level3.net (4.69.137.42) 66.063 ms ae-93-93.csw4.LosAngeles1.Level3.net (4.69.137.46) 65.985 ms ae-63-63.csw1.LosAngeles1.Level3.net (4.69.137.34) 66.026 ms 11 ae-3-80.edge2.LosAngeles9.Level3.net (4.69.144.143) 66.162 ms 66.160 ms 66.238 ms 12 KDDI-AMERIC.edge2.LosAngeles9.Level3.net (4.53.228.14) 193.317 ms 193.447 ms 193.305 ms 13 lajbb001.kddnet.ad.jp (59.128.2.101) 101.544 ms 101.543 ms lajbb002.kddnet.ad.jp (59.128.2.185) 66.563 ms 14 otejbb203.kddnet.ad.jp (203.181.100.13) 164.217 ms 164.221 ms 164.330 ms 15 cm-fcu203.kddnet.ad.jp (124.215.194.164) 180.350 ms cm-fcu203.kddnet.ad.jp (124.215.194.180) 172.779 ms cm-fcu203.kddnet.ad.jp (124.215.194.164) 185.824 ms 16 124.215.199.122 (124.215.199.122) 175.703 ms 175.700 ms 168.268 ms 17 li377-33.members.linode.com (106.187.34.33) 174.381 ms 174.383 ms 174.368 ms The last hop is KDDI, but things work from via Level3 and not sprint. Linode blames Verizon, but I'm not seeing how it's them. Any ideas? From derek at derekivey.com Sat Dec 10 15:52:01 2011 From: derek at derekivey.com (Derek Ivey) Date: Sat, 10 Dec 2011 16:52:01 -0500 Subject: Inaccessible network from Verizon, accessible elsewhere. In-Reply-To: References: Message-ID: <4EE3D481.2030007@derekivey.com> Do you have a firewall running on the Linode VPS? Any chance something like fail2ban blocked your IP for too many invalid logins? Are you able to ping your FIOS IP from the VPS? Try doing a traceroute on the VPS to your FIOS IP. Perhaps there is some issue getting back to you. Based on the traceroutes you provided, it doesn't look like Verizon's issue. Derek On 12/10/2011 2:49 PM, NetSecGuy wrote: > I have a Linode VPS in Japan that I can't access from Verizon FIOS, > but can access from other locations. I'm not sure who to blame. > > The host, 106.187.34.33, is behind the gateway 106.187.34.1: > > From FIOS to 106.187.34.1 (this works). > > traceroute to 106.187.34.1 (106.187.34.1), 64 hops max, 52 byte packets > > 4 so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4) 9.960 ms > 9.957 ms 6.666 ms > 5 so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3) > 12.298 ms 13.463 ms 13.706 ms > 6 0.ae2.br1.iad8.alter.net (152.63.32.158) 14.571 ms 14.372 ms 14.003 ms > 7 204.255.169.218 (204.255.169.218) 14.692 ms 14.759 ms 13.670 ms > 8 sl-crs1-dc-0-1-0-0.sprintlink.net (144.232.19.229) 13.077 ms > 12.577 ms 14.954 ms > 9 sl-crs1-nsh-0-5-5-0.sprintlink.net (144.232.18.200) 31.443 ms > sl-crs1-dc-0-5-3-0.sprintlink.net (144.232.24.37) 33.005 ms > sl-crs1-nsh-0-5-5-0.sprintlink.net (144.232.18.200) 31.507 ms > 10 sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112) 57.610 ms > 58.322 ms 59.098 ms > 11 otejbb204.kddnet.ad.jp (203.181.100.45) 196.063 ms > otejbb203.kddnet.ad.jp (203.181.100.13) 188.846 ms > otejbb204.kddnet.ad.jp (203.181.100.21) 195.277 ms > 12 cm-fcu203.kddnet.ad.jp (124.215.194.180) 214.760 ms > cm-fcu203.kddnet.ad.jp (124.215.194.164) 198.925 ms > cm-fcu203.kddnet.ad.jp (124.215.194.180) 200.583 ms > 13 124.215.199.122 (124.215.199.122) 193.086 ms * 194.967 ms > > This does not work from FIOS: > > traceroute to 106.187.34.33 (106.187.34.33), 64 hops max, 52 byte packets > > 4 so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4) 34.229 ms > 8.743 ms 8.878 ms > 5 so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3) > 15.402 ms 13.008 ms 14.932 ms > 6 0.ae2.br1.iad8.alter.net (152.63.32.158) 13.325 ms 13.245 ms 13.802 ms > 7 204.255.169.218 (204.255.169.218) 14.820 ms 14.232 ms 13.491 ms > 8 lap-brdr-03.inet.qwest.net (67.14.22.78) 90.170 ms 92.273 ms 145.887 ms > 9 63.146.26.70 (63.146.26.70) 92.482 ms 92.287 ms 94.000 ms > 10 sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112) 58.135 ms > 58.520 ms 58.055 ms > 11 otejbb203.kddnet.ad.jp (203.181.100.17) 205.844 ms > otejbb204.kddnet.ad.jp (203.181.100.25) 189.929 ms > otejbb203.kddnet.ad.jp (203.181.100.17) 204.846 ms > 12 sl-crs1-oro-0-1-5-0.sprintlink.net (144.232.25.77) 87.229 ms > sl-crs1-oro-0-3-3-0.sprintlink.net (144.232.25.207) 88.796 ms 88.717 ms > 13 124.215.199.122 (124.215.199.122) 193.584 ms 202.208 ms 192.989 ms > 14 * * * > > Same IP from different network: > > traceroute to 106.187.34.33 (106.187.34.33), 30 hops max, 60 byte packets > > 6 ae-8-8.ebr2.Washington1.Level3.net (4.69.134.105) 2.230 ms 1.847 > ms 1.938 ms > 7 ae-92-92.csw4.Washington1.Level3.net (4.69.134.158) 2.010 ms > 1.985 ms ae-62-62.csw1.Washington1.Level3.net (4.69.134.146) 1.942 ms > 8 ae-94-94.ebr4.Washington1.Level3.net (4.69.134.189) 12.515 ms > ae-74-74.ebr4.Washington1.Level3.net (4.69.134.181) 12.519 ms 12.507 > ms > 9 ae-4-4.ebr3.LosAngeles1.Level3.net (4.69.132.81) 65.957 ms > 65.958 ms 66.056 ms > 10 ae-83-83.csw3.LosAngeles1.Level3.net (4.69.137.42) 66.063 ms > ae-93-93.csw4.LosAngeles1.Level3.net (4.69.137.46) 65.985 ms > ae-63-63.csw1.LosAngeles1.Level3.net (4.69.137.34) 66.026 ms > 11 ae-3-80.edge2.LosAngeles9.Level3.net (4.69.144.143) 66.162 ms > 66.160 ms 66.238 ms > 12 KDDI-AMERIC.edge2.LosAngeles9.Level3.net (4.53.228.14) 193.317 ms > 193.447 ms 193.305 ms > 13 lajbb001.kddnet.ad.jp (59.128.2.101) 101.544 ms 101.543 ms > lajbb002.kddnet.ad.jp (59.128.2.185) 66.563 ms > 14 otejbb203.kddnet.ad.jp (203.181.100.13) 164.217 ms 164.221 ms 164.330 ms > 15 cm-fcu203.kddnet.ad.jp (124.215.194.164) 180.350 ms > cm-fcu203.kddnet.ad.jp (124.215.194.180) 172.779 ms > cm-fcu203.kddnet.ad.jp (124.215.194.164) 185.824 ms > 16 124.215.199.122 (124.215.199.122) 175.703 ms 175.700 ms 168.268 ms > 17 li377-33.members.linode.com (106.187.34.33) 174.381 ms 174.383 > ms 174.368 ms > > The last hop is KDDI, but things work from via Level3 and not sprint. > Linode blames Verizon, but I'm not seeing how it's them. > > Any ideas? > From stb at lassitu.de Sat Dec 10 18:11:54 2011 From: stb at lassitu.de (Stefan Bethke) Date: Sun, 11 Dec 2011 01:11:54 +0100 Subject: Inaccessible network from Verizon, accessible elsewhere. In-Reply-To: References: Message-ID: <6F2C07FD-0C60-4010-938D-E5976B513803@lassitu.de> Am 10.12.2011 um 20:49 schrieb NetSecGuy: > This does not work from FIOS: > > traceroute to 106.187.34.33 (106.187.34.33), 64 hops max, 52 byte packets > > 4 so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4) 34.229 ms > 8.743 ms 8.878 ms > 5 so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3) > 15.402 ms 13.008 ms 14.932 ms > 6 0.ae2.br1.iad8.alter.net (152.63.32.158) 13.325 ms 13.245 ms 13.802 ms > 7 204.255.169.218 (204.255.169.218) 14.820 ms 14.232 ms 13.491 ms > 8 lap-brdr-03.inet.qwest.net (67.14.22.78) 90.170 ms 92.273 ms 145.887 ms > 9 63.146.26.70 (63.146.26.70) 92.482 ms 92.287 ms 94.000 ms > 10 sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112) 58.135 ms > 58.520 ms 58.055 ms > 11 otejbb203.kddnet.ad.jp (203.181.100.17) 205.844 ms > otejbb204.kddnet.ad.jp (203.181.100.25) 189.929 ms > otejbb203.kddnet.ad.jp (203.181.100.17) 204.846 ms > 12 sl-crs1-oro-0-1-5-0.sprintlink.net (144.232.25.77) 87.229 ms > sl-crs1-oro-0-3-3-0.sprintlink.net (144.232.25.207) 88.796 ms 88.717 ms > 13 124.215.199.122 (124.215.199.122) 193.584 ms 202.208 ms 192.989 ms > 14 * * * From FIOS in BOS: 3 g14-0-7-1544.bstnma-lcr-05.verizon-gni.net (130.81.49.80) 132.408 ms 130.742 ms 139.945 ms 4 so-7-2-0-0.bos-bb-rtr1.verizon-gni.net (130.81.29.172) 132.405 ms 137.776 ms 134.929 ms 5 so-9-1-0-0.ny325-bb-rtr1.verizon-gni.net (130.81.19.70) 139.872 ms 141.344 ms 150.117 ms 6 0.so-0-0-0.xt1.nyc4.alter.net (152.63.1.41) 142.381 ms 141.256 ms 139.873 ms 7 0.ae3.br2.nyc4.alter.net (152.63.3.110) 169.904 ms 169.769 ms 167.357 ms 8 nyc-brdr-02.inet.qwest.net (63.146.27.209) 140.164 ms 142.500 ms 142.880 ms 9 lap-brdr-03.inet.qwest.net (67.14.22.78) 274.856 ms 226.176 ms 232.839 ms 10 63.146.26.70 (63.146.26.70) 224.891 ms 223.915 ms 225.082 ms 11 lajbb002.kddnet.ad.jp (59.128.2.73) 227.355 ms lajbb001.kddnet.ad.jp (59.128.2.173) 236.509 ms lajbb002.kddnet.ad.jp (59.128.2.177) 226.723 ms 12 otejbb204.kddnet.ad.jp (203.181.100.25) 324.419 ms otejbb203.kddnet.ad.jp (203.181.100.13) 336.141 ms otejbb204.kddnet.ad.jp (203.181.100.45) 330.458 ms 13 cm-fcu203.kddnet.ad.jp (124.215.194.164) 336.209 ms cm-fcu203.kddnet.ad.jp (124.215.194.180) 334.191 ms cm-fcu203.kddnet.ad.jp (124.215.194.164) 327.027 ms 14 124.215.199.122 (124.215.199.122) 334.904 ms 324.853 ms * -- Stefan Bethke Fon +49 151 14070811 From eyeronic.design at gmail.com Sat Dec 10 18:33:06 2011 From: eyeronic.design at gmail.com (Mike Hale) Date: Sat, 10 Dec 2011 16:33:06 -0800 Subject: Inaccessible network from Verizon, accessible elsewhere. In-Reply-To: <6F2C07FD-0C60-4010-938D-E5976B513803@lassitu.de> References: <6F2C07FD-0C60-4010-938D-E5976B513803@lassitu.de> Message-ID: Disable your firewall and run TCPDump on your host when you try to ping it. Does the ICMP packet get to your host? On Sat, Dec 10, 2011 at 4:11 PM, Stefan Bethke wrote: > Am 10.12.2011 um 20:49 schrieb NetSecGuy: > > > This does not work from FIOS: > > > > traceroute to 106.187.34.33 (106.187.34.33), 64 hops max, 52 byte packets > > > > 4 so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4) 34.229 ms > > 8.743 ms 8.878 ms > > 5 so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3) > > 15.402 ms 13.008 ms 14.932 ms > > 6 0.ae2.br1.iad8.alter.net (152.63.32.158) 13.325 ms 13.245 ms > 13.802 ms > > 7 204.255.169.218 (204.255.169.218) 14.820 ms 14.232 ms 13.491 ms > > 8 lap-brdr-03.inet.qwest.net (67.14.22.78) 90.170 ms 92.273 ms > 145.887 ms > > 9 63.146.26.70 (63.146.26.70) 92.482 ms 92.287 ms 94.000 ms > > 10 sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112) 58.135 ms > > 58.520 ms 58.055 ms > > 11 otejbb203.kddnet.ad.jp (203.181.100.17) 205.844 ms > > otejbb204.kddnet.ad.jp (203.181.100.25) 189.929 ms > > otejbb203.kddnet.ad.jp (203.181.100.17) 204.846 ms > > 12 sl-crs1-oro-0-1-5-0.sprintlink.net (144.232.25.77) 87.229 ms > > sl-crs1-oro-0-3-3-0.sprintlink.net (144.232.25.207) 88.796 ms > 88.717 ms > > 13 124.215.199.122 (124.215.199.122) 193.584 ms 202.208 ms 192.989 ms > > 14 * * * > > From FIOS in BOS: > 3 g14-0-7-1544.bstnma-lcr-05.verizon-gni.net (130.81.49.80) 132.408 ms > 130.742 ms 139.945 ms > 4 so-7-2-0-0.bos-bb-rtr1.verizon-gni.net (130.81.29.172) 132.405 ms > 137.776 ms 134.929 ms > 5 so-9-1-0-0.ny325-bb-rtr1.verizon-gni.net (130.81.19.70) 139.872 ms > 141.344 ms 150.117 ms > 6 0.so-0-0-0.xt1.nyc4.alter.net (152.63.1.41) 142.381 ms 141.256 ms > 139.873 ms > 7 0.ae3.br2.nyc4.alter.net (152.63.3.110) 169.904 ms 169.769 ms > 167.357 ms > 8 nyc-brdr-02.inet.qwest.net (63.146.27.209) 140.164 ms 142.500 ms > 142.880 ms > 9 lap-brdr-03.inet.qwest.net (67.14.22.78) 274.856 ms 226.176 ms > 232.839 ms > 10 63.146.26.70 (63.146.26.70) 224.891 ms 223.915 ms 225.082 ms > 11 lajbb002.kddnet.ad.jp (59.128.2.73) 227.355 ms > lajbb001.kddnet.ad.jp (59.128.2.173) 236.509 ms > lajbb002.kddnet.ad.jp (59.128.2.177) 226.723 ms > 12 otejbb204.kddnet.ad.jp (203.181.100.25) 324.419 ms > otejbb203.kddnet.ad.jp (203.181.100.13) 336.141 ms > otejbb204.kddnet.ad.jp (203.181.100.45) 330.458 ms > 13 cm-fcu203.kddnet.ad.jp (124.215.194.164) 336.209 ms > cm-fcu203.kddnet.ad.jp (124.215.194.180) 334.191 ms > cm-fcu203.kddnet.ad.jp (124.215.194.164) 327.027 ms > 14 124.215.199.122 (124.215.199.122) 334.904 ms 324.853 ms * > > -- > Stefan Bethke Fon +49 151 14070811 > > > > > -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From bzs at world.std.com Sat Dec 10 19:48:45 2011 From: bzs at world.std.com (Barry Shein) Date: Sat, 10 Dec 2011 20:48:45 -0500 Subject: Sad IPv4 story? In-Reply-To: References: Message-ID: <20196.3069.632519.601259@world.std.com> >> I just had a personal email from a brand new ISP in the Asia-Pacific >> area desperately looking for enough IPv4 to be able to run their >> business the way they would like? This sniping elicited by the above seems inappropriate and unprofessional, the request/anecdote seemed reasonable and could elicit solutions such as partnerships, etc. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From Valdis.Kletnieks at vt.edu Sat Dec 10 22:07:06 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 10 Dec 2011 23:07:06 -0500 Subject: Sad IPv4 story? In-Reply-To: Your message of "Sat, 10 Dec 2011 20:48:45 EST." <20196.3069.632519.601259@world.std.com> References: <20196.3069.632519.601259@world.std.com> Message-ID: <15282.1323576426@turing-police.cc.vt.edu> On Sat, 10 Dec 2011 20:48:45 EST, Barry Shein said: > >> I just had a personal email from a brand new ISP in the Asia-Pacific > >> area desperately looking for enough IPv4 to be able to run their > >> business the way they would like? > > This sniping elicited by the above seems inappropriate and > unprofessional, the request/anecdote seemed reasonable and could > elicit solutions such as partnerships, etc. No Barry, I respectfully disagree. It's almost 2012. The first predictions of IPv4 exhaustion were made *last century*. We've been predicting it to the month level for like 5 years now. Any business that is making business plans and models that doesn't take "we may not get IPv4 space" into account and have a contingency plan for that *deserves* to be soundly mocked and ridiculed in public. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From randy at psg.com Sat Dec 10 22:18:06 2011 From: randy at psg.com (Randy Bush) Date: Sun, 11 Dec 2011 13:18:06 +0900 Subject: Sad IPv4 story? In-Reply-To: <20196.3069.632519.601259@world.std.com> References: <20196.3069.632519.601259@world.std.com> Message-ID: >>> I just had a personal email from a brand new ISP in the Asia-Pacific >>> area desperately looking for enough IPv4 to be able to run their >>> business the way they would like? > > This sniping elicited by the above seems inappropriate and > unprofessional, the request/anecdote seemed reasonable and could > elicit solutions such as partnerships, etc. i am sure they look forward to your generous offer. randy From randy at psg.com Sat Dec 10 22:38:02 2011 From: randy at psg.com (Randy Bush) Date: Sun, 11 Dec 2011 13:38:02 +0900 Subject: Sad IPv4 story? In-Reply-To: <15282.1323576426@turing-police.cc.vt.edu> References: <20196.3069.632519.601259@world.std.com> <15282.1323576426@turing-police.cc.vt.edu> Message-ID: > No Barry, I respectfully disagree. It's almost 2012. The first > predictions of IPv4 exhaustion were made *last century*. We've been > predicting it to the month level for like 5 years now. Any business > that is making business plans and models that doesn't take "we may not > get IPv4 space" into account and have a contingency plan for that > *deserves* to be soundly mocked and ridiculed in public. mocking someone who shows up when the party is already over is not overly kind or useful. making clear to the world that the part is over is more useful. i could not decide between a number of very appropriate floyd songs, but i think 'time' says it well Ticking away the moments that make up a dull day Fritter and waste the hours in an offhand way Kicking around on a piece of ground in your home town Waiting for someone or something to show you the way Tired of lying in the sunshine staying home to watch the rain And you are young and life is long and there is time to kill today And then one day you find ten years have got behind you No one told you when to run, you missed the starting gun And you run and you run to catch up with the sun, but it's sinking Racing around to come up behind you again The sun is the same in a relative way, but you're older Shorter of breath and one day closer to death Every year is getting shorter, never seem to find the time Plans that either come to naught or half a page of scribbled lines Hanging on quiet desperation is the English way The time is gone, the song is over, thought I'd something more to say randy From joelja at bogus.com Sat Dec 10 23:42:04 2011 From: joelja at bogus.com (Joel jaeggli) Date: Sat, 10 Dec 2011 21:42:04 -0800 Subject: Sad IPv4 story? In-Reply-To: <20196.3069.632519.601259@world.std.com> References: <20196.3069.632519.601259@world.std.com> Message-ID: <4EE442AC.1020309@bogus.com> On 12/10/11 17:48 , Barry Shein wrote: > >>> I just had a personal email from a brand new ISP in the Asia-Pacific >>> area desperately looking for enough IPv4 to be able to run their >>> business the way they would like? > > This sniping elicited by the above seems inappropriate and > unprofessional, the request/anecdote seemed reasonable and could > elicit solutions such as partnerships, etc. engineering solutions work with the constraints at hand. The maximum ipv4 delegation size to be issued in apnic is a /22. one has to assume that when it's gone it's gone. given that constraint, I know how I'd build it. From tagno25 at gmail.com Sat Dec 10 23:43:11 2011 From: tagno25 at gmail.com (Philip Dorr) Date: Sat, 10 Dec 2011 21:43:11 -0800 Subject: Sad IPv4 story? In-Reply-To: References: <20196.3069.632519.601259@world.std.com> <15282.1323576426@turing-police.cc.vt.edu> Message-ID: On Sat, Dec 10, 2011 at 8:38 PM, Randy Bush wrote: >> No Barry, I respectfully disagree. ?It's almost 2012. ?The first >> predictions of IPv4 exhaustion were made *last century*. ?We've been >> predicting it to the month level for like 5 years now. ?Any business >> that is making business plans and models that doesn't take "we may not >> get IPv4 space" into account and have a contingency plan for that >> *deserves* to be soundly mocked and ridiculed in public. > > mocking someone who shows up when the party is already over is not > overly kind or useful. ?making clear to the world that the part is over > is more useful. The party is not over, it is just moving from a house to a stadium, with a large drive between. From mysidia at gmail.com Sat Dec 10 23:54:08 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 10 Dec 2011 23:54:08 -0600 Subject: Sad IPv4 story? In-Reply-To: References: <20196.3069.632519.601259@world.std.com> <15282.1323576426@turing-police.cc.vt.edu> Message-ID: On Sat, Dec 10, 2011 at 11:43 PM, Philip Dorr wrote: > On Sat, Dec 10, 2011 at 8:38 PM, Randy Bush wrote: >> mocking someone who shows up when the party is already over is not >> overly kind or useful. ?making clear to the world that the part is over > The party is not over, it is just moving from a house to a stadium, > with a large drive between. That's a different party. It doesn't really get started until people arrive at it. So far the IPv6 party's been pretty small due to the expense of the rocket ship upgrades required to reach the planet that party is going to be held on. -- -JH From joelja at bogus.com Sun Dec 11 00:03:50 2011 From: joelja at bogus.com (Joel jaeggli) Date: Sat, 10 Dec 2011 22:03:50 -0800 Subject: Sad IPv4 story? In-Reply-To: <4EE442AC.1020309@bogus.com> References: <20196.3069.632519.601259@world.std.com> <4EE442AC.1020309@bogus.com> Message-ID: <4EE447C6.8040308@bogus.com> On 12/10/11 21:42 , Joel jaeggli wrote: > On 12/10/11 17:48 , Barry Shein wrote: >> >>>> I just had a personal email from a brand new ISP in the Asia-Pacific >>>> area desperately looking for enough IPv4 to be able to run their >>>> business the way they would like? >> >> This sniping elicited by the above seems inappropriate and >> unprofessional, the request/anecdote seemed reasonable and could >> elicit solutions such as partnerships, etc. > > engineering solutions work with the constraints at hand. > > The maximum ipv4 delegation size to be issued in apnic is a /22. one has > to assume that when it's gone it's gone. > > given that constraint, I know how I'd build it. Setting aside the sad story part for the moment, Would this be a good subject for a BOF? Are there others who would be willing to participate (residendential,transit or dc operators, and potentially vendors of equipment or address transfer brokers). I'd call it something like: IPV4 runout - Doing more with less. * IPV4 runout means new entrants will from the outset deploy techniques the present operators consider undesirable. * IPV6 should be appearing as part and parcel of new greenfield projects I would think. * On the vendor side CGN hardware is becoming a mature product space. * Datacenter/ICP operators confront a similar set of problems both supporting outgoing connections for large pools and incoming termination. > From randy at psg.com Sun Dec 11 01:14:19 2011 From: randy at psg.com (Randy Bush) Date: Sun, 11 Dec 2011 16:14:19 +0900 Subject: Sad IPv4 story? In-Reply-To: References: <20196.3069.632519.601259@world.std.com> <15282.1323576426@turing-police.cc.vt.edu> Message-ID: > So far the IPv6 party's been pretty small due to the expense of the > rocket ship upgrades required to reach the planet that party is going > to be held on. for those of us who have been here on B-612 nuturing the rose for over a decade, you 'adult' geographers seem to live on a very grey and depressing asteroid. randy From jcurran at arin.net Sun Dec 11 05:52:21 2011 From: jcurran at arin.net (John Curran) Date: Sun, 11 Dec 2011 11:52:21 +0000 Subject: Sad IPv4 story? In-Reply-To: References: Message-ID: On Dec 9, 2011, at 1:37 PM, Franck Martin wrote: > I just had a personal email from a brand new ISP in the Asia-Pacific area desperately looking for enough IPv4 to be able to run their business the way they would like? > > This is just a data point. Franck - Thanks for the data point - I'm certain there are others folks out there with similar experiences that we're not hearing about. Of course, the theory was that at this point they'd be able to use IPv6 to connect customers up to the Internet. Such theory was predicated on a presumed strong motivation for everyone already connected via IPv4 to deploy IPv6 in parallel (i.e. dual-stack) and some elusive TBD transition mechanisms which were to make IPv6 customers interoperate with those that hadn't yet deployed IPv6 in parallel. Reality looks very different, in that existing organizations find it difficult to understand why to add IPv6 connectivity to their existing public-facing servers, and the state of the art in achieving transparent operation for IPv6 connected systems to the rest of the Internet running only IPv4 is still effectively a work-in-progress... While your data point may be from the Asia-Pacific region, that same story is going to repeated in every region (RIPE NCC will be running out shortly, and ARIN has 1 to 2 years depending on the actual request rate that materializes) Service providers in the ARIN region need to carefully consider their answer to that same situation, because it will be occurring here soon enough. There is one thing that everyone can do to reduce the impact of this transition, and this is getting in front of their business customers (and small business/power users who have public-facing content) to explain that the Internet is going be running IPv4 and IPv6 for quite some time in parallel and that getting their public-facing servers connected up also via IPv6 is a very good idea (if anyone wants help doing this sort of customer education ARIN's https://www.arin.net/knowledge, NRO's http://www.nro.net/ipv6, and APNIC's IPv6 Act Now http://www.ipv6actnow.org web sites are all good sources on materials for this sort of effort.) The sooner we get the content on IPv6 in addition to IPv4, the sooner that connecting new customers up via IPv6 without additional unique IPv4 address space becomes viable (and obviously if we had the vast majority of content already on IPv6, then connecting new customers via IPv6 would be simple indeed.) FYI, /John John Curran President and CEO ARIN From eric at eparsonage.com Sun Dec 11 07:41:08 2011 From: eric at eparsonage.com (Eric Parsonage) Date: Mon, 12 Dec 2011 00:11:08 +1030 Subject: Sad IPv4 story? In-Reply-To: <15282.1323576426@turing-police.cc.vt.edu> References: <20196.3069.632519.601259@world.std.com> <15282.1323576426@turing-police.cc.vt.edu> Message-ID: <3ADD5AAC-C95A-48CD-8880-F44E799C8A25@eparsonage.com> On 11/12/2011, at 2:37 PM, Valdis.Kletnieks at vt.edu wrote: > On Sat, 10 Dec 2011 20:48:45 EST, Barry Shein said: >>>> I just had a personal email from a brand new ISP in the Asia-Pacific >>>> area desperately looking for enough IPv4 to be able to run their >>>> business the way they would like? >> >> This sniping elicited by the above seems inappropriate and >> unprofessional, the request/anecdote seemed reasonable and could >> elicit solutions such as partnerships, etc. > > No Barry, I respectfully disagree. It's almost 2012. The first predictions of > IPv4 exhaustion were made *last century*. We've been predicting it to the > month level for like 5 years now. Any business that is making business plans > and models that doesn't take "we may not get IPv4 space" into account and have > a contingency plan for that *deserves* to be soundly mocked and ridiculed in > public. You could take this one step further and say any industry that has had this much warning and hasn?t taken it into account *deserves* to be soundly mocked and ridiculed in public. From ler762 at gmail.com Sun Dec 11 08:44:21 2011 From: ler762 at gmail.com (Lee) Date: Sun, 11 Dec 2011 09:44:21 -0500 Subject: Inaccessible network from Verizon, accessible elsewhere. In-Reply-To: References: Message-ID: On 12/10/11, NetSecGuy wrote: > I have a Linode VPS in Japan that I can't access from Verizon FIOS, > but can access from other locations. I'm not sure who to blame. I can't get to 106.187.34.33 or 106.187.34.1 using Verizon FIOS C:\>tracert 106.187.34.33 Tracing route to li377-33.members.linode.com [106.187.34.33] over a maximum of 30 hops: [.. snip ..] 5 23 ms 4 ms 4 ms so-14-0-0-0.RES-BB-RTR2.verizon-gni.net [130.81.22.56] 6 73 ms 6 ms 7 ms 0.ae2.BR2.IAD8.ALTER.NET [152.63.34.73] 7 8 ms 6 ms 7 ms dcp-brdr-03.inet.qwest.net [63.146.26.105] 8 8 ms 9 ms 9 ms sl-crs1-dc-0-1-0-0.sprintlink.net [144.232.19.229] 9 28 ms 26 ms 44 ms sl-crs1-dc-0-5-3-0.sprintlink.net [144.232.24.37] 10 177 ms 176 ms 177 ms lajbb001.kddnet.ad.jp [59.128.2.173] 11 43 ms 41 ms 42 ms sl-crs1-oma-0-9-2-0.sprintlink.net [144.232.2.177] 12 291 ms * 301 ms cm-fcu203.kddnet.ad.jp [124.215.194.164] 13 286 ms 279 ms 282 ms 124.215.199.122 14 81 ms 81 ms 82 ms sl-crs1-sj-0-5-3-0.sprintlink.net [144.232.20.99] 15 88 ms 86 ms 87 ms sl-st20-pa-9-0-0.sprintlink.net [144.232.8.108] 16 405 ms 406 ms 399 ms 144.223.243.126 17 364 ms 386 ms 406 ms pajbb001.kddnet.ad.jp [111.87.3.41] 18 * * * Request timed out. 19 * * * Request timed out. 20 * * * Request timed out. 21 * * * Request timed out. 22 * * * Request timed out. 23 * * ^C C:\>tracert 106.187.34.1 Tracing route to gw-li377.linode.com [106.187.34.1] over a maximum of 30 hops: [.. snip ..] 5 5 ms 24 ms 24 ms so-3-1-0-0.RES-BB-RTR2.verizon-gni.net [130.81.151.232] 6 7 ms 7 ms 7 ms 0.ae2.BR2.IAD8.ALTER.NET [152.63.34.73] 7 8 ms 7 ms 7 ms dcp-brdr-03.inet.qwest.net [63.146.26.105] 8 84 ms 84 ms 84 ms lap-brdr-03.inet.qwest.net [67.14.22.78] 9 171 ms 174 ms 176 ms 63.146.26.70 10 178 ms 177 ms 177 ms lajbb001.kddnet.ad.jp [59.128.2.173] 11 283 ms 284 ms 284 ms otejbb203.kddnet.ad.jp [203.181.100.9] 12 289 ms 287 ms 287 ms cm-fcu203.kddnet.ad.jp [124.215.194.164] 13 * * * Request timed out. 14 83 ms 81 ms 82 ms sl-crs1-sj-0-12-0-1.sprintlink.net [144.232.9.224] 15 * * * Request timed out. 16 403 ms 407 ms 404 ms 144.223.243.126 17 * * * Request timed out. 18 501 ms 499 ms 501 ms otejbb203.kddnet.ad.jp.100.181.203.in-addr.arpa [203.181.100.137] 19 * * * Request timed out. 20 * * * Request timed out. 21 * * * Request timed out. 22 * * * Request timed out. 23 * * * Request timed out. 24 * * * Request timed out. 25 * ^C Lee > > The host, 106.187.34.33, is behind the gateway 106.187.34.1: > > From FIOS to 106.187.34.1 (this works). > > traceroute to 106.187.34.1 (106.187.34.1), 64 hops max, 52 byte packets > > 4 so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4) 9.960 ms > 9.957 ms 6.666 ms > 5 so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3) > 12.298 ms 13.463 ms 13.706 ms > 6 0.ae2.br1.iad8.alter.net (152.63.32.158) 14.571 ms 14.372 ms 14.003 > ms > 7 204.255.169.218 (204.255.169.218) 14.692 ms 14.759 ms 13.670 ms > 8 sl-crs1-dc-0-1-0-0.sprintlink.net (144.232.19.229) 13.077 ms > 12.577 ms 14.954 ms > 9 sl-crs1-nsh-0-5-5-0.sprintlink.net (144.232.18.200) 31.443 ms > sl-crs1-dc-0-5-3-0.sprintlink.net (144.232.24.37) 33.005 ms > sl-crs1-nsh-0-5-5-0.sprintlink.net (144.232.18.200) 31.507 ms > 10 sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112) 57.610 ms > 58.322 ms 59.098 ms > 11 otejbb204.kddnet.ad.jp (203.181.100.45) 196.063 ms > otejbb203.kddnet.ad.jp (203.181.100.13) 188.846 ms > otejbb204.kddnet.ad.jp (203.181.100.21) 195.277 ms > 12 cm-fcu203.kddnet.ad.jp (124.215.194.180) 214.760 ms > cm-fcu203.kddnet.ad.jp (124.215.194.164) 198.925 ms > cm-fcu203.kddnet.ad.jp (124.215.194.180) 200.583 ms > 13 124.215.199.122 (124.215.199.122) 193.086 ms * 194.967 ms > > This does not work from FIOS: > > traceroute to 106.187.34.33 (106.187.34.33), 64 hops max, 52 byte packets > > 4 so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4) 34.229 ms > 8.743 ms 8.878 ms > 5 so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3) > 15.402 ms 13.008 ms 14.932 ms > 6 0.ae2.br1.iad8.alter.net (152.63.32.158) 13.325 ms 13.245 ms 13.802 > ms > 7 204.255.169.218 (204.255.169.218) 14.820 ms 14.232 ms 13.491 ms > 8 lap-brdr-03.inet.qwest.net (67.14.22.78) 90.170 ms 92.273 ms 145.887 > ms > 9 63.146.26.70 (63.146.26.70) 92.482 ms 92.287 ms 94.000 ms > 10 sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112) 58.135 ms > 58.520 ms 58.055 ms > 11 otejbb203.kddnet.ad.jp (203.181.100.17) 205.844 ms > otejbb204.kddnet.ad.jp (203.181.100.25) 189.929 ms > otejbb203.kddnet.ad.jp (203.181.100.17) 204.846 ms > 12 sl-crs1-oro-0-1-5-0.sprintlink.net (144.232.25.77) 87.229 ms > sl-crs1-oro-0-3-3-0.sprintlink.net (144.232.25.207) 88.796 ms 88.717 > ms > 13 124.215.199.122 (124.215.199.122) 193.584 ms 202.208 ms 192.989 ms > 14 * * * > > Same IP from different network: > > traceroute to 106.187.34.33 (106.187.34.33), 30 hops max, 60 byte packets > > 6 ae-8-8.ebr2.Washington1.Level3.net (4.69.134.105) 2.230 ms 1.847 > ms 1.938 ms > 7 ae-92-92.csw4.Washington1.Level3.net (4.69.134.158) 2.010 ms > 1.985 ms ae-62-62.csw1.Washington1.Level3.net (4.69.134.146) 1.942 ms > 8 ae-94-94.ebr4.Washington1.Level3.net (4.69.134.189) 12.515 ms > ae-74-74.ebr4.Washington1.Level3.net (4.69.134.181) 12.519 ms 12.507 > ms > 9 ae-4-4.ebr3.LosAngeles1.Level3.net (4.69.132.81) 65.957 ms > 65.958 ms 66.056 ms > 10 ae-83-83.csw3.LosAngeles1.Level3.net (4.69.137.42) 66.063 ms > ae-93-93.csw4.LosAngeles1.Level3.net (4.69.137.46) 65.985 ms > ae-63-63.csw1.LosAngeles1.Level3.net (4.69.137.34) 66.026 ms > 11 ae-3-80.edge2.LosAngeles9.Level3.net (4.69.144.143) 66.162 ms > 66.160 ms 66.238 ms > 12 KDDI-AMERIC.edge2.LosAngeles9.Level3.net (4.53.228.14) 193.317 ms > 193.447 ms 193.305 ms > 13 lajbb001.kddnet.ad.jp (59.128.2.101) 101.544 ms 101.543 ms > lajbb002.kddnet.ad.jp (59.128.2.185) 66.563 ms > 14 otejbb203.kddnet.ad.jp (203.181.100.13) 164.217 ms 164.221 ms 164.330 > ms > 15 cm-fcu203.kddnet.ad.jp (124.215.194.164) 180.350 ms > cm-fcu203.kddnet.ad.jp (124.215.194.180) 172.779 ms > cm-fcu203.kddnet.ad.jp (124.215.194.164) 185.824 ms > 16 124.215.199.122 (124.215.199.122) 175.703 ms 175.700 ms 168.268 ms > 17 li377-33.members.linode.com (106.187.34.33) 174.381 ms 174.383 > ms 174.368 ms > > The last hop is KDDI, but things work from via Level3 and not sprint. > Linode blames Verizon, but I'm not seeing how it's them. > > Any ideas? > > From netsecguy at gmail.com Sun Dec 11 12:02:42 2011 From: netsecguy at gmail.com (NetSecGuy) Date: Sun, 11 Dec 2011 13:02:42 -0500 Subject: Inaccessible network from Verizon, accessible elsewhere. In-Reply-To: References: Message-ID: I should have included reverse traces to begin with. No firewall on VPS. Trace from the VPS to a router close to me. traceroute to 130.81.199.4 (130.81.199.4), 64 hops max, 40 byte packets 1 106.187.33.2 (106.187.33.2) 1 ms 0 ms 0 ms 2 124.215.199.121 (124.215.199.121) 6 ms 1 ms 13 ms 3 59.128.4.121 (59.128.4.121) 2 ms otejbb204.kddnet.ad.jp (124.215.194.177) 2 ms 2 ms 4 lajbb001.kddnet.ad.jp (203.181.100.14) 126 ms 100 ms lajbb002.kddnet.ad.jp (203.181.100.22) 162 ms 5 ix-la1.kddnet.ad.jp (59.128.2.70) 108 ms ix-la1.kddnet.ad.jp (59.128.2.178) 102 ms 102 ms 6 lap-brdr-03.inet.qwest.net (63.146.26.69) 99 ms 101 ms 99 ms 7 63.146.26.210 (63.146.26.210) 99 ms 101 ms 99 ms 8 0.ae3.XL3.LAX15.ALTER.NET (152.63.113.186) 102 ms 102 ms 101 ms 9 * * * 10 * * * Tracer from VPS to a router close to my other location, not Verizon. traceroute to 4.59.244.49 (4.59.244.49), 64 hops max, 40 byte packets 1 106.187.33.2 (106.187.33.2) 1 ms 1 ms 1 ms 2 124.215.199.121 (124.215.199.121) 9 ms 1 ms 1 ms 3 59.128.4.121 (59.128.4.121) 2 ms otejbb204.kddnet.ad.jp (124.215.194.177) 9 ms 59.128.4.121 (59.128.4.121) 2 ms 4 lajbb001.kddnet.ad.jp (203.181.100.18) 108 ms lajbb002.kddnet.ad.jp (203.181.100.22) 101 ms 101 ms 5 ix-la2.kddnet.ad.jp (59.128.2.102) 116 ms 116 ms ix-la2.kddnet.ad.jp (59.128.2.186) 125 ms 6 xe-11-3-0.edge2.LosAngeles9.Level3.net (4.53.228.13) 111 ms 101 ms 101 ms 7 vlan70.csw2.LosAngeles1.Level3.net (4.69.144.126) 110 ms vlan90.csw4.LosAngeles1.Level3.net (4.69.144.254) 108 ms vlan60.csw1.LosAngeles1.Level3.net (4.69.144.62) 103 ms 8 ae-63-63.ebr3.LosAngeles1.Level3.net (4.69.137.33) 110 ms 117 ms ae-73-73.ebr3.LosAngeles1.Level3.net (4.69.137.37) 108 ms 9 ae-4-4.ebr4.Washington1.Level3.net (4.69.132.82) 178 ms 180 ms 166 ms 10 ae-64-64.csw1.Washington1.Level3.net (4.69.134.178) 174 ms 166 ms 166 ms 11 ae-62-62.ebr2.Washington1.Level3.net (4.69.134.145) 172 ms 165 ms 172 ms 12 ae-8-8.car2.Baltimore1.Level3.net (4.69.134.106) 181 ms 174 ms 174 ms 13 ae-11-11.car1.Baltimore1.Level3.net (4.69.134.109) 181 ms * 174 ms From joseph.snyder at gmail.com Sun Dec 11 14:11:01 2011 From: joseph.snyder at gmail.com (Joseph Snyder) Date: Sun, 11 Dec 2011 15:11:01 -0500 Subject: Inaccessible network from Verizon, accessible elsewhere. In-Reply-To: References: Message-ID: <421a1b73-817f-42d4-ab1e-9c5beaa96174@email.android.com> I believe 130.81 is blocked. Traceroute to your gateway address. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. NetSecGuy wrote: I should have included reverse traces to begin with. No firewall on VPS. Trace from the VPS to a router close to me. traceroute to 130.81.199.4 (130.81.199.4), 64 hops max, 40 byte packets 1 106.187.33.2 (106.187.33.2) 1 ms 0 ms 0 ms 2 124.215.199.121 (124.215.199.121) 6 ms 1 ms 13 ms 3 59.128.4.121 (59.128.4.121) 2 ms otejbb204.kddnet.ad.jp (124.215.194.177) 2 ms 2 ms 4 lajbb001.kddnet.ad.jp (203.181.100.14) 126 ms 100 ms lajbb002.kddnet.ad.jp (203.181.100.22) 162 ms 5 ix-la1.kddnet.ad.jp (59.128.2.70) 108 ms ix-la1.kddnet.ad.jp (59.128.2.178) 102 ms 102 ms 6 lap-brdr-03.inet.qwest.net (63.146.26.69) 99 ms 101 ms 99 ms 7 63.146.26.210 (63.146.26.210) 99 ms 101 ms 99 ms 8 0.ae3.XL3.LAX15.ALTER.NET (152.63.113.186) 102 ms 102 ms 101 ms 9 * * * 10 * * * Tracer from VPS to a router close to my other location, not Verizon. traceroute to 4.59.244.49 (4.59.244.49), 64 hops max, 40 byte packets 1 106.187.33.2 (106.187.33.2) 1 ms 1 ms 1 ms 2 124.215.199.121 (124.215.199.121) 9 ms 1 ms 1 ms 3 59.128.4.121 (59.128.4.121) 2 ms otejbb204.kddnet.ad.jp (124.215.194.177) 9 ms 59.128.4.121 (59.128.4.121) 2 ms 4 lajbb001.kddnet.ad.jp (203.181.100.18) 108 ms lajbb002.kddnet.ad.jp (203.181.100.22) 101 ms 101 ms 5 ix-la2.kddnet.ad.jp (59.128.2.102) 116 ms 116 ms ix-la2.kddnet.ad.jp (59.128.2.186) 125 ms 6 xe-11-3-0.edge2.LosAngeles9.Level3.net (4.53.228.13) 111 ms 101 ms 101 ms 7 vlan70.csw2.LosAngeles1.Level3.net (4.69.144.126) 110 ms vlan90.csw4.LosAngeles1.Level3.net (4.69.144.254) 108 ms vlan60.csw1.LosAngeles1.Level3.net (4.69.144.62) 103 ms 8 ae-63-63.ebr3.LosAngeles1.Level3.net (4.69.137.33) 110 ms 117 ms ae-73-73.ebr3.LosAngeles1.Level3.net (4.69.137.37) 108 ms 9 ae-4-4.ebr4.Washington1.Level3.net (4.69.132.82) 178 ms 180 ms 166 ms 10 ae-64-64.csw1.Washington1.Level3.net (4.69.134.178) 174 ms 166 ms 166 ms 11 ae-62-62.ebr2.Washington1.Level3.net (4.69.134.145) 172 ms 165 ms 172 ms 12 ae-8-8.car2.Baltimore1.Level3.net (4.69.134.106) 181 ms 174 ms 174 ms 13 ae-11-11.car1.Baltimore1.Level3.net (4.69.134.109) 181 ms * 174 ms From jof at thejof.com Sun Dec 11 14:56:52 2011 From: jof at thejof.com (Jonathan Lassoff) Date: Sun, 11 Dec 2011 12:56:52 -0800 Subject: Inaccessible network from Verizon, accessible elsewhere. In-Reply-To: References: Message-ID: On Sat, Dec 10, 2011 at 11:49 AM, NetSecGuy wrote: > I have a Linode VPS in Japan that I can't access from Verizon FIOS, > but can access from other locations. I'm not sure who to blame. > > The host, 106.187.34.33, is behind the gateway 106.187.34.1: > > From FIOS to 106.187.34.1 (this works). > > traceroute to 106.187.34.1 (106.187.34.1), 64 hops max, 52 byte packets > > 4 so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4) 9.960 ms > 9.957 ms 6.666 ms > 5 so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3) > 12.298 ms 13.463 ms 13.706 ms > 6 0.ae2.br1.iad8.alter.net (152.63.32.158) 14.571 ms 14.372 ms > 14.003 ms > 7 204.255.169.218 (204.255.169.218) 14.692 ms 14.759 ms 13.670 ms > 8 sl-crs1-dc-0-1-0-0.sprintlink.net (144.232.19.229) 13.077 ms > 12.577 ms 14.954 ms > 9 sl-crs1-nsh-0-5-5-0.sprintlink.net (144.232.18.200) 31.443 ms > sl-crs1-dc-0-5-3-0.sprintlink.net (144.232.24.37) 33.005 ms > sl-crs1-nsh-0-5-5-0.sprintlink.net (144.232.18.200) 31.507 ms > 10 sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112) 57.610 ms > 58.322 ms 59.098 ms > 11 otejbb204.kddnet.ad.jp (203.181.100.45) 196.063 ms > otejbb203.kddnet.ad.jp (203.181.100.13) 188.846 ms > otejbb204.kddnet.ad.jp (203.181.100.21) 195.277 ms > 12 cm-fcu203.kddnet.ad.jp (124.215.194.180) 214.760 ms > cm-fcu203.kddnet.ad.jp (124.215.194.164) 198.925 ms > cm-fcu203.kddnet.ad.jp (124.215.194.180) 200.583 ms > 13 124.215.199.122 (124.215.199.122) 193.086 ms * 194.967 ms > > This does not work from FIOS: > > traceroute to 106.187.34.33 (106.187.34.33), 64 hops max, 52 byte packets > > 4 so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4) 34.229 ms > 8.743 ms 8.878 ms > 5 so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3) > 15.402 ms 13.008 ms 14.932 ms > 6 0.ae2.br1.iad8.alter.net (152.63.32.158) 13.325 ms 13.245 ms > 13.802 ms > 7 204.255.169.218 (204.255.169.218) 14.820 ms 14.232 ms 13.491 ms > 8 lap-brdr-03.inet.qwest.net (67.14.22.78) 90.170 ms 92.273 ms > 145.887 ms > 9 63.146.26.70 (63.146.26.70) 92.482 ms 92.287 ms 94.000 ms > 10 sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112) 58.135 ms > 58.520 ms 58.055 ms > 11 otejbb203.kddnet.ad.jp (203.181.100.17) 205.844 ms > otejbb204.kddnet.ad.jp (203.181.100.25) 189.929 ms > otejbb203.kddnet.ad.jp (203.181.100.17) 204.846 ms > 12 sl-crs1-oro-0-1-5-0.sprintlink.net (144.232.25.77) 87.229 ms > sl-crs1-oro-0-3-3-0.sprintlink.net (144.232.25.207) 88.796 ms 88.717 > ms > 13 124.215.199.122 (124.215.199.122) 193.584 ms 202.208 ms 192.989 ms > 14 * * * > > Same IP from different network: > > traceroute to 106.187.34.33 (106.187.34.33), 30 hops max, 60 byte packets > > 6 ae-8-8.ebr2.Washington1.Level3.net (4.69.134.105) 2.230 ms 1.847 > ms 1.938 ms > 7 ae-92-92.csw4.Washington1.Level3.net (4.69.134.158) 2.010 ms > 1.985 ms ae-62-62.csw1.Washington1.Level3.net (4.69.134.146) 1.942 ms > 8 ae-94-94.ebr4.Washington1.Level3.net (4.69.134.189) 12.515 ms > ae-74-74.ebr4.Washington1.Level3.net (4.69.134.181) 12.519 ms 12.507 > ms > 9 ae-4-4.ebr3.LosAngeles1.Level3.net (4.69.132.81) 65.957 ms > 65.958 ms 66.056 ms > 10 ae-83-83.csw3.LosAngeles1.Level3.net (4.69.137.42) 66.063 ms > ae-93-93.csw4.LosAngeles1.Level3.net (4.69.137.46) 65.985 ms > ae-63-63.csw1.LosAngeles1.Level3.net (4.69.137.34) 66.026 ms > 11 ae-3-80.edge2.LosAngeles9.Level3.net (4.69.144.143) 66.162 ms > 66.160 ms 66.238 ms > 12 KDDI-AMERIC.edge2.LosAngeles9.Level3.net (4.53.228.14) 193.317 ms > 193.447 ms 193.305 ms > 13 lajbb001.kddnet.ad.jp (59.128.2.101) 101.544 ms 101.543 ms > lajbb002.kddnet.ad.jp (59.128.2.185) 66.563 ms > 14 otejbb203.kddnet.ad.jp (203.181.100.13) 164.217 ms 164.221 ms > 164.330 ms > 15 cm-fcu203.kddnet.ad.jp (124.215.194.164) 180.350 ms > cm-fcu203.kddnet.ad.jp (124.215.194.180) 172.779 ms > cm-fcu203.kddnet.ad.jp (124.215.194.164) 185.824 ms > 16 124.215.199.122 (124.215.199.122) 175.703 ms 175.700 ms 168.268 ms > 17 li377-33.members.linode.com (106.187.34.33) 174.381 ms 174.383 > ms 174.368 ms > > In doing a little probing right now, from various source addresses, I'm unable to reproduce the problem. I've seen failures similar to this one (where the source address matters; some work, some don't) when multi-port LAGs or ECMP paths have a single link in them fail, but are still detected and forwarded over as if it was up. This can happen, for example, if you run a LAG with no channeling protocol (like LACP or PAGP), that hashes source and destination IPs to pick a link (to ensure consistent paths per-path, and with ports, per-flow). If one of those links fails in the underlying media or physical path, but the link is still detected as up, packets to some IPs (but not others) will just drop on the flor. Now, in this particular case, it doesn't seem like the path to both destinations seem like they even take the same path (so that previous hypothesis is pure conjecture). Perhaps routes were actively shifting between KDDI and Sprint (which would explain weird AS paths like VZB->Qwest->Sprint->KDDI->Sprint)? The IP space belongs to KDDI and is originated by them, and they're just allocating it for Linode's use. > The last hop is KDDI, but things work from via Level3 and not sprint. > Linode blames Verizon, but I'm not seeing how it's them. > Honestly, I'd see if Linode can work with KDDI to make sure they're announcing (and others are receiving and routing) to that IP space as intended. There's not enough info here to point fingers, but I would think that they would be the organization most empowered to do anything about this. Cheers, jof From network.ipdog at gmail.com Sun Dec 11 16:46:20 2011 From: network.ipdog at gmail.com (Network IP Dog) Date: Sun, 11 Dec 2011 14:46:20 -0800 Subject: Inaccessible network from Verizon, accessible elsewhere. In-Reply-To: References: Message-ID: <4ee532c6.8908e70a.5582.ffff8e19@mx.google.com> >From 90701 - Artesia, CA. FIOS No Go here too!!! C:\WINDOWS\system32>tracert 106.187.34.1 Tracing route to gw-li377.linode.com [106.187.34.1] over a maximum of 30 hops: 1 22 ms 34 ms <1 ms Tomato [192.168.100.1] 2 49 ms 1 ms 1 ms Verizon [192.168.1.1] 3 36 ms 6 ms 6 ms L100.LSANCA-VFTTP-114.verizon-gni.net [173.58.21 1.1] 4 24 ms 9 ms 9 ms G0-9-1-4.LSANCA-LCR-21.verizon-gni.net [130.81.1 85.72] 5 24 ms 9 ms 8 ms so-4-1-0-0.LAX01-BB-RTR1.verizon-gni.net [130.81 .151.246] 6 24 ms 9 ms 8 ms 0.ae1.BR3.LAX15.ALTER.NET [152.63.2.129] 7 38 ms 8 ms 8 ms ae6.edge1.LosAngeles9.level3.net [4.68.62.169] 8 25 ms 10 ms 10 ms 63.146.26.70 9 24 ms 9 ms 8 ms lajbb001.kddnet.ad.jp [59.128.2.173] 10 24 ms 9 ms 8 ms lajbb001.kddnet.ad.jp [59.128.2.181] 11 140 ms 110 ms 108 ms otejbb203.kddnet.ad.jp [203.181.100.9] 12 140 ms 124 ms 111 ms cm-fcu203.kddnet.ad.jp [124.215.194.164] 13 * * * Request timed out. 14 * * * Request timed out. 15 * * * Request timed out. 16 * * * Request timed out. 17 * * * Request timed out. 18 * * * Request timed out. 19 * * * Request timed out. 20 * * * Request timed out. 21 * * * Request timed out. 22 * * * Request timed out. 23 * * * Request timed out. 24 * ^C C:\WINDOWS\system32>tracert 106.187.34.33 Tracing route to li377-33.members.linode.com [106.187.34.33] over a maximum of 30 hops: 1 22 ms 1 ms <1 ms Tomato [192.168.100.1] 2 31 ms 1 ms 1 ms Verizon [192.168.1.1] 3 51 ms 10 ms 11 ms L100.LSANCA-VFTTP-114.verizon-gni.net [173.58.21 1.1] 4 42 ms 9 ms 33 ms G0-9-1-4.LSANCA-LCR-21.verizon-gni.net [130.81.1 85.72] 5 40 ms 15 ms 9 ms so-4-1-0-0.LAX01-BB-RTR1.verizon-gni.net [130.81 .151.246] 6 31 ms 8 ms 8 ms 0.ae1.BR3.LAX15.ALTER.NET [152.63.2.129] 7 61 ms 10 ms 16 ms lap-brdr-03.inet.qwest.net [63.146.26.209] 8 31 ms 10 ms 10 ms 63.146.26.70 9 31 ms 9 ms 9 ms lajbb001.kddnet.ad.jp [59.128.2.173] 10 31 ms 9 ms 8 ms lajbb001.kddnet.ad.jp [59.128.2.181] 11 125 ms 118 ms 109 ms otejbb203.kddnet.ad.jp [203.181.100.9] 12 156 ms 111 ms 143 ms 124.215.199.122 13 126 ms 112 ms 137 ms 124.215.199.122 14 * * * Request timed out. 15 * * * Request timed out. 16 * * * Request timed out. 17 * * ^C C:\WINDOWS\system32> E = 4:32 & Cheers!!! -----Original Message----- From: Lee [mailto:ler762 at gmail.com] Sent: Sunday, December 11, 2011 6:44 AM To: NetSecGuy Cc: nanog at nanog.org Subject: Re: Inaccessible network from Verizon, accessible elsewhere. On 12/10/11, NetSecGuy wrote: > I have a Linode VPS in Japan that I can't access from Verizon FIOS, > but can access from other locations. I'm not sure who to blame. I can't get to 106.187.34.33 or 106.187.34.1 using Verizon FIOS C:\>tracert 106.187.34.33 Tracing route to li377-33.members.linode.com [106.187.34.33] over a maximum of 30 hops: [.. snip ..] 5 23 ms 4 ms 4 ms so-14-0-0-0.RES-BB-RTR2.verizon-gni.net [130.81.22.56] 6 73 ms 6 ms 7 ms 0.ae2.BR2.IAD8.ALTER.NET [152.63.34.73] 7 8 ms 6 ms 7 ms dcp-brdr-03.inet.qwest.net [63.146.26.105] 8 8 ms 9 ms 9 ms sl-crs1-dc-0-1-0-0.sprintlink.net [144.232.19.229] 9 28 ms 26 ms 44 ms sl-crs1-dc-0-5-3-0.sprintlink.net [144.232.24.37] 10 177 ms 176 ms 177 ms lajbb001.kddnet.ad.jp [59.128.2.173] 11 43 ms 41 ms 42 ms sl-crs1-oma-0-9-2-0.sprintlink.net [144.232.2.177] 12 291 ms * 301 ms cm-fcu203.kddnet.ad.jp [124.215.194.164] 13 286 ms 279 ms 282 ms 124.215.199.122 14 81 ms 81 ms 82 ms sl-crs1-sj-0-5-3-0.sprintlink.net [144.232.20.99] 15 88 ms 86 ms 87 ms sl-st20-pa-9-0-0.sprintlink.net [144.232.8.108] 16 405 ms 406 ms 399 ms 144.223.243.126 17 364 ms 386 ms 406 ms pajbb001.kddnet.ad.jp [111.87.3.41] 18 * * * Request timed out. 19 * * * Request timed out. 20 * * * Request timed out. 21 * * * Request timed out. 22 * * * Request timed out. 23 * * ^C C:\>tracert 106.187.34.1 Tracing route to gw-li377.linode.com [106.187.34.1] over a maximum of 30 hops: [.. snip ..] 5 5 ms 24 ms 24 ms so-3-1-0-0.RES-BB-RTR2.verizon-gni.net [130.81.151.232] 6 7 ms 7 ms 7 ms 0.ae2.BR2.IAD8.ALTER.NET [152.63.34.73] 7 8 ms 7 ms 7 ms dcp-brdr-03.inet.qwest.net [63.146.26.105] 8 84 ms 84 ms 84 ms lap-brdr-03.inet.qwest.net [67.14.22.78] 9 171 ms 174 ms 176 ms 63.146.26.70 10 178 ms 177 ms 177 ms lajbb001.kddnet.ad.jp [59.128.2.173] 11 283 ms 284 ms 284 ms otejbb203.kddnet.ad.jp [203.181.100.9] 12 289 ms 287 ms 287 ms cm-fcu203.kddnet.ad.jp [124.215.194.164] 13 * * * Request timed out. 14 83 ms 81 ms 82 ms sl-crs1-sj-0-12-0-1.sprintlink.net [144.232.9.224] 15 * * * Request timed out. 16 403 ms 407 ms 404 ms 144.223.243.126 17 * * * Request timed out. 18 501 ms 499 ms 501 ms otejbb203.kddnet.ad.jp.100.181.203.in-addr.arpa [203.181.100.137] 19 * * * Request timed out. 20 * * * Request timed out. 21 * * * Request timed out. 22 * * * Request timed out. 23 * * * Request timed out. 24 * * * Request timed out. 25 * ^C Lee > > The host, 106.187.34.33, is behind the gateway 106.187.34.1: > > From FIOS to 106.187.34.1 (this works). > > traceroute to 106.187.34.1 (106.187.34.1), 64 hops max, 52 byte packets > > 4 so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4) 9.960 ms > 9.957 ms 6.666 ms > 5 so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3) > 12.298 ms 13.463 ms 13.706 ms > 6 0.ae2.br1.iad8.alter.net (152.63.32.158) 14.571 ms 14.372 ms 14.003 > ms > 7 204.255.169.218 (204.255.169.218) 14.692 ms 14.759 ms 13.670 ms > 8 sl-crs1-dc-0-1-0-0.sprintlink.net (144.232.19.229) 13.077 ms > 12.577 ms 14.954 ms > 9 sl-crs1-nsh-0-5-5-0.sprintlink.net (144.232.18.200) 31.443 ms > sl-crs1-dc-0-5-3-0.sprintlink.net (144.232.24.37) 33.005 ms > sl-crs1-nsh-0-5-5-0.sprintlink.net (144.232.18.200) 31.507 ms > 10 sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112) 57.610 ms > 58.322 ms 59.098 ms > 11 otejbb204.kddnet.ad.jp (203.181.100.45) 196.063 ms > otejbb203.kddnet.ad.jp (203.181.100.13) 188.846 ms > otejbb204.kddnet.ad.jp (203.181.100.21) 195.277 ms > 12 cm-fcu203.kddnet.ad.jp (124.215.194.180) 214.760 ms > cm-fcu203.kddnet.ad.jp (124.215.194.164) 198.925 ms > cm-fcu203.kddnet.ad.jp (124.215.194.180) 200.583 ms > 13 124.215.199.122 (124.215.199.122) 193.086 ms * 194.967 ms > > This does not work from FIOS: > > traceroute to 106.187.34.33 (106.187.34.33), 64 hops max, 52 byte packets > > 4 so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4) 34.229 ms > 8.743 ms 8.878 ms > 5 so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3) > 15.402 ms 13.008 ms 14.932 ms > 6 0.ae2.br1.iad8.alter.net (152.63.32.158) 13.325 ms 13.245 ms 13.802 > ms > 7 204.255.169.218 (204.255.169.218) 14.820 ms 14.232 ms 13.491 ms > 8 lap-brdr-03.inet.qwest.net (67.14.22.78) 90.170 ms 92.273 ms 145.887 > ms > 9 63.146.26.70 (63.146.26.70) 92.482 ms 92.287 ms 94.000 ms > 10 sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112) 58.135 ms > 58.520 ms 58.055 ms > 11 otejbb203.kddnet.ad.jp (203.181.100.17) 205.844 ms > otejbb204.kddnet.ad.jp (203.181.100.25) 189.929 ms > otejbb203.kddnet.ad.jp (203.181.100.17) 204.846 ms > 12 sl-crs1-oro-0-1-5-0.sprintlink.net (144.232.25.77) 87.229 ms > sl-crs1-oro-0-3-3-0.sprintlink.net (144.232.25.207) 88.796 ms 88.717 > ms > 13 124.215.199.122 (124.215.199.122) 193.584 ms 202.208 ms 192.989 ms > 14 * * * > > Same IP from different network: > > traceroute to 106.187.34.33 (106.187.34.33), 30 hops max, 60 byte packets > > 6 ae-8-8.ebr2.Washington1.Level3.net (4.69.134.105) 2.230 ms 1.847 > ms 1.938 ms > 7 ae-92-92.csw4.Washington1.Level3.net (4.69.134.158) 2.010 ms > 1.985 ms ae-62-62.csw1.Washington1.Level3.net (4.69.134.146) 1.942 ms > 8 ae-94-94.ebr4.Washington1.Level3.net (4.69.134.189) 12.515 ms > ae-74-74.ebr4.Washington1.Level3.net (4.69.134.181) 12.519 ms 12.507 > ms > 9 ae-4-4.ebr3.LosAngeles1.Level3.net (4.69.132.81) 65.957 ms > 65.958 ms 66.056 ms > 10 ae-83-83.csw3.LosAngeles1.Level3.net (4.69.137.42) 66.063 ms > ae-93-93.csw4.LosAngeles1.Level3.net (4.69.137.46) 65.985 ms > ae-63-63.csw1.LosAngeles1.Level3.net (4.69.137.34) 66.026 ms > 11 ae-3-80.edge2.LosAngeles9.Level3.net (4.69.144.143) 66.162 ms > 66.160 ms 66.238 ms > 12 KDDI-AMERIC.edge2.LosAngeles9.Level3.net (4.53.228.14) 193.317 ms > 193.447 ms 193.305 ms > 13 lajbb001.kddnet.ad.jp (59.128.2.101) 101.544 ms 101.543 ms > lajbb002.kddnet.ad.jp (59.128.2.185) 66.563 ms > 14 otejbb203.kddnet.ad.jp (203.181.100.13) 164.217 ms 164.221 ms 164.330 > ms > 15 cm-fcu203.kddnet.ad.jp (124.215.194.164) 180.350 ms > cm-fcu203.kddnet.ad.jp (124.215.194.180) 172.779 ms > cm-fcu203.kddnet.ad.jp (124.215.194.164) 185.824 ms > 16 124.215.199.122 (124.215.199.122) 175.703 ms 175.700 ms 168.268 ms > 17 li377-33.members.linode.com (106.187.34.33) 174.381 ms 174.383 > ms 174.368 ms > > The last hop is KDDI, but things work from via Level3 and not sprint. > Linode blames Verizon, but I'm not seeing how it's them. > > Any ideas? > > From dave at temk.in Sun Dec 11 18:29:53 2011 From: dave at temk.in (Dave Temkin) Date: Sun, 11 Dec 2011 16:29:53 -0800 Subject: Overall Netflix bandwidth usage numbers on a network? In-Reply-To: <4EDF9AE9.9040700@ispn.net> References: <20111203004732.GH13315@hijacked.us> <20111203005847.GI13315@hijacked.us> <4EDF9AE9.9040700@ispn.net> Message-ID: <4EE54B01.6000305@temk.in> Feel free to contact peering at netflixcom - we're happy to provide you with delivery statistics for traffic terminating on your network. Regards, -Dave Temkin Netflix On 12/7/11 8:57 AM, Blake Hudson wrote: > Yeah, that's an interesting one. We currently utilize netflow for this, but you also need to consider that > netflix streaming is just port 80 www traffic. Because netflix uses CDNs, its difficult to pin down the > traffic to specific hosts in the CDN and say that this traffic was netflix, while this traffic was the > latest windows update (remember this is often a shared hosting platform). We've done our own testing and > have come to a good solution which uses a combination of nbar, packet marking, and netflow to come to a > conclusion. On a ~160Mbps link, netflix peaks out between 30-50Mbps around 8-10PM each evening. The rest > of the traffic is predominantly other forms of HTTP traffic (including other video streaming services). > > > Martin Hepworth wrote the following on 12/3/2011 2:36 AM: >> Also checkout Adrian Cockcroft presentations on their architecture which >> describes how they use aws and CDns etc >> >> Martin >> >> > From joseph.snyder at gmail.com Sun Dec 11 18:37:26 2011 From: joseph.snyder at gmail.com (Joseph Snyder) Date: Sun, 11 Dec 2011 19:37:26 -0500 Subject: Inaccessible network from Verizon, accessible elsewhere. In-Reply-To: <4ee532c6.8908e70a.5582.ffff8e19@mx.google.com> References: <4ee532c6.8908e70a.5582.ffff8e19@mx.google.com> Message-ID: I hope it's not an outdated martian problem firewall or route filter. For the Traceroute from linode to FiOS, Traceroute to the FiOS gateway address. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Network IP Dog wrote: >From 90701 - Artesia, CA. FIOS No Go here too!!! C:\WINDOWS\system32>tracert 106.187.34.1 Tracing route to gw-li377.linode.com [106.187.34.1] over a maximum of 30 hops: 1 22 ms 34 ms <1 ms Tomato [192.168.100.1] 2 49 ms 1 ms 1 ms Verizon [192.168.1.1] 3 36 ms 6 ms 6 ms L100.LSANCA-VFTTP-114.verizon-gni.net [173.58.21 1.1] 4 24 ms 9 ms 9 ms G0-9-1-4.LSANCA-LCR-21.verizon-gni.net [130.81.1 85.72] 5 24 ms 9 ms 8 ms so-4-1-0-0.LAX01-BB-RTR1.verizon-gni.net [130.81 .151.246] 6 24 ms 9 ms 8 ms 0.ae1.BR3.LAX15.ALTER.NET [152.63.2.129] 7 38 ms 8 ms 8 ms ae6.edge1.LosAngeles9.level3.net [4.68.62.169] 8 25 ms 10 ms 10 ms 63.146.26.70 9 24 ms 9 ms 8 ms lajbb001.kddnet.ad.jp [59.128.2.173] 10 24 ms 9 ms 8 ms lajbb001.kddnet.ad.jp [59.128.2.181] 11 140 ms 110 ms 108 ms otejbb203.kddnet.ad.jp [203.181.100.9] 12 140 ms 124 ms 111 ms cm-fcu203.kddnet.ad.jp [124.215.194.164] 13 * * * Request timed out. 14 * * * Request timed out. 15 * * * Request timed out. 16 * * * Request timed out. 17 * * * Request timed out. 18 * * * Request timed out. 19 * * * Request timed out. 20 * * * Request timed out. 21 * * * Request timed out. 22 * * * Request timed out. 23 * * * Request timed out. 24 * ^C C:\WINDOWS\system32>tracert 106.187.34.33 Tracing route to li377-33.members.linode.com [106.187.34.33] over a maximum of 30 hops: 1 22 ms 1 ms <1 ms Tomato [192.168.100.1] 2 31 ms 1 ms 1 ms Verizon [192.168.1.1] 3 51 ms 10 ms 11 ms L100.LSANCA-VFTTP-114.verizon-gni.net [173.58.21 1.1] 4 42 ms 9 ms 33 ms G0-9-1-4.LSANCA-LCR-21.verizon-gni.net [130.81.1 85.72] 5 40 ms 15 ms 9 ms so-4-1-0-0.LAX01-BB-RTR1.verizon-gni.net [130.81 .151.246] 6 31 ms 8 ms 8 ms 0.ae1.BR3.LAX15.ALTER.NET [152.63.2.129] 7 61 ms 10 ms 16 ms lap-brdr-03.inet.qwest.net [63.146.26.209] 8 31 ms 10 ms 10 ms 63.146.26.70 9 31 ms 9 ms 9 ms lajbb001.kddnet.ad.jp [59.128.2.173] 10 31 ms 9 ms 8 ms lajbb001.kddnet.ad.jp [59.128.2.181] 11 125 ms 118 ms 109 ms otejbb203.kddnet.ad.jp [203.181.100.9] 12 156 ms 111 ms 143 ms 124.215.199.122 13 126 ms 112 ms 137 ms 124.215.199.122 14 * * * Request timed out. 15 * * * Request timed out. 16 * * * Request timed out. 17 * * ^C C:\WINDOWS\system32> E = 4:32 & Cheers!!! -----Original Message----- From: Lee [mailto:ler762 at gmail.com] Sent: Sunday, December 11, 2011 6:44 AM To: NetSecGuy Cc: nanog at nanog.org Subject: Re: Inaccessible network from Verizon, accessible elsewhere. On 12/10/11, NetSecGuy wrote: > I have a Linode VPS in Japan that I can't access from Verizon FIOS, > but can access from other locations. I'm not sure who to blame. I can't get to 106.187.34.33 or 106.187.34.1 using Verizon FIOS C:\>tracert 106.187.34.33 Tracing route to li377-33.members.linode.com [106.187.34.33] over a maximum of 30 hops: [.. snip ..] 5 23 ms 4 ms 4 ms so-14-0-0-0.RES-BB-RTR2.verizon-gni.net [130.81.22.56] 6 73 ms 6 ms 7 ms 0.ae2.BR2.IAD8.ALTER.NET [152.63.34.73] 7 8 ms 6 ms 7 ms dcp-brdr-03.inet.qwest.net [63.146.26.105] 8 8 ms 9 ms 9 ms sl-crs1-dc-0-1-0-0.sprintlink.net [144.232.19.229] 9 28 ms 26 ms 44 ms sl-crs1-dc-0-5-3-0.sprintlink.net [144.232.24.37] 10 177 ms 176 ms 177 ms lajbb001.kddnet.ad.jp [59.128.2.173] 11 43 ms 41 ms 42 ms sl-crs1-oma-0-9-2-0.sprintlink.net [144.232.2.177] 12 291 ms * 301 ms cm-fcu203.kddnet.ad.jp [124.215.194.164] 13 286 ms 279 ms 282 ms 124.215.199.122 14 81 ms 81 ms 82 ms sl-crs1-sj-0-5-3-0.sprintlink.net [144.232.20.99] 15 88 ms 86 ms 87 ms sl-st20-pa-9-0-0.sprintlink.net [144.232.8.108] 16 405 ms 406 ms 399 ms 144.223.243.126 17 364 ms 386 ms 406 ms pajbb001.kddnet.ad.jp [111.87.3.41] 18 * * * Request timed out. 19 * * * Request timed out. 20 * * * Request timed out. 21 * * * Request timed out. 22 * * * Request timed out. 23 * * ^C C:\>tracert 106.187.34.1 Tracing route to gw-li377.linode.com [106.187.34.1] over a maximum of 30 hops: [.. snip ..] 5 5 ms 24 ms 24 ms so-3-1-0-0.RES-BB-RTR2.verizon-gni.net [130.81.151.232] 6 7 ms 7 ms 7 ms 0.ae2.BR2.IAD8.ALTER.NET [152.63.34.73] 7 8 ms 7 ms 7 ms dcp-brdr-03.inet.qwest.net [63.146.26.105] 8 84 ms 84 ms 84 ms lap-brdr-03.inet.qwest.net [67.14.22.78] 9 171 ms 174 ms 176 ms 63.146.26.70 10 178 ms 177 ms 177 ms lajbb001.kddnet.ad.jp [59.128.2.173] 11 283 ms 284 ms 284 ms otejbb203.kddnet.ad.jp [203.181.100.9] 12 289 ms 287 ms 287 ms cm-fcu203.kddnet.ad.jp [124.215.194.164] 13 * * * Request timed out. 14 83 ms 81 ms 82 ms sl-crs1-sj-0-12-0-1.sprintlink.net [144.232.9.224] 15 * * * Request timed out. 16 403 ms 407 ms 404 ms 144.223.243.126 17 * * * Request timed out. 18 501 ms 499 ms 501 ms otejbb203.kddnet.ad.jp.100.181.203.in-addr.arpa [203.181.100.137] 19 * * * Request timed out. 20 * * * Request timed out. 21 * * * Request timed out. 22 * * * Request timed out. 23 * * * Request timed out. 24 * * * Request timed out. 25 * ^C Lee > > The host, 106.187.34.33, is behind the gateway 106.187.34.1: > > From FIOS to 106.187.34.1 (this works). > > traceroute to 106.187.34.1 (106.187.34.1), 64 hops max, 52 byte packets > > 4 so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4) 9.960 ms > 9.957 ms 6.666 ms > 5 so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3) > 12.298 ms 13.463 ms 13.706 ms > 6 0.ae2.br1.iad8.alter.net (152.63.32.158) 14.571 ms 14.372 ms 14.003 > ms > 7 204.255.169.218 (204.255.169.218) 14.692 ms 14.759 ms 13.670 ms > 8 sl-crs1-dc-0-1-0-0.sprintlink.net (144.232.19.229) 13.077 ms > 12.577 ms 14.954 ms > 9 sl-crs1-nsh-0-5-5-0.sprintlink.net (144.232.18.200) 31.443 ms > sl-crs1-dc-0-5-3-0.sprintlink.net (144.232.24.37) 33.005 ms > sl-crs1-nsh-0-5-5-0.sprintlink.net (144.232.18.200) 31.507 ms > 10 sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112) 57.610 ms > 58.322 ms 59.098 ms > 11 otejbb204.kddnet.ad.jp (203.181.100.45) 196.063 ms > otejbb203.kddnet.ad.jp (203.181.100.13) 188.846 ms > otejbb204.kddnet.ad.jp (203.181.100.21) 195.277 ms > 12 cm-fcu203.kddnet.ad.jp (124.215.194.180) 214.760 ms > cm-fcu203.kddnet.ad.jp (124.215.194.164) 198.925 ms > cm-fcu203.kddnet.ad.jp (124.215.194.180) 200.583 ms > 13 124.215.199.122 (124.215.199.122) 193.086 ms * 194.967 ms > > This does not work from FIOS: > > traceroute to 106.187.34.33 (106.187.34.33), 64 hops max, 52 byte packets > > 4 so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4) 34.229 ms > 8.743 ms 8.878 ms > 5 so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3) > 15.402 ms 13.008 ms 14.932 ms > 6 0.ae2.br1.iad8.alter.net (152.63.32.158) 13.325 ms 13.245 ms 13.802 > ms > 7 204.255.169.218 (204.255.169.218) 14.820 ms 14.232 ms 13.491 ms > 8 lap-brdr-03.inet.qwest.net (67.14.22.78) 90.170 ms 92.273 ms 145.887 > ms > 9 63.146.26.70 (63.146.26.70) 92.482 ms 92.287 ms 94.000 ms > 10 sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112) 58.135 ms > 58.520 ms 58.055 ms > 11 otejbb203.kddnet.ad.jp (203.181.100.17) 205.844 ms > otejbb204.kddnet.ad.jp (203.181.100.25) 189.929 ms > otejbb203.kddnet.ad.jp (203.181.100.17) 204.846 ms > 12 sl-crs1-oro-0-1-5-0.sprintlink.net (144.232.25.77) 87.229 ms > sl-crs1-oro-0-3-3-0.sprintlink.net (144.232.25.207) 88.796 ms 88.717 > ms > 13 124.215.199.122 (124.215.199.122) 193.584 ms 202.208 ms 192.989 ms > 14 * * * > > Same IP from different network: > > traceroute to 106.187.34.33 (106.187.34.33), 30 hops max, 60 byte packets > > 6 ae-8-8.ebr2.Washington1.Level3.net (4.69.134.105) 2.230 ms 1.847 > ms 1.938 ms > 7 ae-92-92.csw4.Washington1.Level3.net (4.69.134.158) 2.010 ms > 1.985 ms ae-62-62.csw1.Washington1.Level3.net (4.69.134.146) 1.942 ms > 8 ae-94-94.ebr4.Washington1.Level3.net (4.69.134.189) 12.515 ms > ae-74-74.ebr4.Washington1.Level3.net (4.69.134.181) 12.519 ms 12.507 > ms > 9 ae-4-4.ebr3.LosAngeles1.Level3.net (4.69.132.81) 65.957 ms > 65.958 ms 66.056 ms > 10 ae-83-83.csw3.LosAngeles1.Level3.net (4.69.137.42) 66.063 ms > ae-93-93.csw4.LosAngeles1.Level3.net (4.69.137.46) 65.985 ms > ae-63-63.csw1.LosAngeles1.Level3.net (4.69.137.34) 66.026 ms > 11 ae-3-80.edge2.LosAngeles9.Level3.net (4.69.144.143) 66.162 ms > 66.160 ms 66.238 ms > 12 KDDI-AMERIC.edge2.LosAngeles9.Level3.net (4.53.228.14) 193.317 ms > 193.447 ms 193.305 ms > 13 lajbb001.kddnet.ad.jp (59.128.2.101) 101.544 ms 101.543 ms > lajbb002.kddnet.ad.jp (59.128.2.185) 66.563 ms > 14 otejbb203.kddnet.ad.jp (203.181.100.13) 164.217 ms 164.221 ms 164.330 > ms > 15 cm-fcu203.kddnet.ad.jp (124.215.194.164) 180.350 ms > cm-fcu203.kddnet.ad.jp (124.215.194.180) 172.779 ms > cm-fcu203.kddnet.ad.jp (124.215.194.164) 185.824 ms > 16 124.215.199.122 (124.215.199.122) 175.703 ms 175.700 ms 168.268 ms > 17 li377-33.members.linode.com (106.187.34.33) 174.381 ms 174.383 > ms 174.368 ms > > The last hop is KDDI, but things work from via Level3 and not sprint. > Linode blames Verizon, but I'm not seeing how it's them. > > Any ideas? > > From randy at psg.com Sun Dec 11 18:55:40 2011 From: randy at psg.com (Randy Bush) Date: Mon, 12 Dec 2011 09:55:40 +0900 Subject: Inaccessible network from Verizon, accessible elsewhere. In-Reply-To: References: <4ee532c6.8908e70a.5582.ffff8e19@mx.google.com> Message-ID: from home lan % traceroute gw-li377.linode.com traceroute to gw-li377.linode.com (106.187.34.1), 64 hops max, 52 byte packets 1 192.168.0.1 (192.168.0.1) 1.471 ms 0.725 ms 0.555 ms 2 tokyo10-f03.flets.2iij.net (210.149.34.72) 7.241 ms 6.651 ms 6.939 ms 3 tokyo10-ntteast0.flets.2iij.net (210.149.34.157) 5.573 ms 6.109 ms 5.346 ms 4 tky001lip20.iij.net (210.149.34.97) 6.410 ms 7.471 ms 7.934 ms 5 tky001bb10.iij.net (58.138.100.209) 6.670 ms 9.251 ms 5.866 ms 6 tky009bf00.iij.net (58.138.80.17) 6.730 ms tky008bf02.iij.net (58.138.80.13) 7.021 ms tky009bf00.iij.net (58.138.80.17) 8.593 ms 7 tky001ix05.iij.net (58.138.82.2) 9.767 ms tky001ix05.iij.net (58.138.82.6) 6.101 ms tky001ix01.iij.net (58.138.80.106) 8.420 ms 8 203.181.102.61 (203.181.102.61) 19.514 ms 203.181.102.21 (203.181.102.21) 6.054 ms 203.181.102.61 (203.181.102.61) 11.478 ms 9 otejbb203.kddnet.ad.jp (118.155.197.129) 7.457 ms otejbb203.kddnet.ad.jp (59.128.7.129) 7.835 ms otejbb204.kddnet.ad.jp (59.128.7.130) 7.824 ms 10 cm-fcu203.kddnet.ad.jp (124.215.194.180) 15.860 ms 16.401 ms cm-fcu203.kddnet.ad.jp (124.215.194.164) 17.519 ms 11 124.215.199.122 (124.215.199.122) 7.892 ms * 11.984 ms From brandon.kim at brandontek.com Sun Dec 11 19:06:44 2011 From: brandon.kim at brandontek.com (Brandon Kim) Date: Sun, 11 Dec 2011 20:06:44 -0500 Subject: Inaccessible network from Verizon, accessible elsewhere. In-Reply-To: References: , , <4ee532c6.8908e70a.5582.ffff8e19@mx.google.com>, , Message-ID: I too am now experiencing issues. I cannot get to www.cisco.com and various websites. Some websites work lightning quick, some take a long time to load, and some just don't load at all..... > Date: Mon, 12 Dec 2011 09:55:40 +0900 > From: randy at psg.com > To: nanog at nanog.org > Subject: Re: Inaccessible network from Verizon, accessible elsewhere. > > from home lan > > % traceroute gw-li377.linode.com > traceroute to gw-li377.linode.com (106.187.34.1), 64 hops max, 52 byte packets > 1 192.168.0.1 (192.168.0.1) 1.471 ms 0.725 ms 0.555 ms > 2 tokyo10-f03.flets.2iij.net (210.149.34.72) 7.241 ms 6.651 ms 6.939 ms > 3 tokyo10-ntteast0.flets.2iij.net (210.149.34.157) 5.573 ms 6.109 ms 5.346 ms > 4 tky001lip20.iij.net (210.149.34.97) 6.410 ms 7.471 ms 7.934 ms > 5 tky001bb10.iij.net (58.138.100.209) 6.670 ms 9.251 ms 5.866 ms > 6 tky009bf00.iij.net (58.138.80.17) 6.730 ms > tky008bf02.iij.net (58.138.80.13) 7.021 ms > tky009bf00.iij.net (58.138.80.17) 8.593 ms > 7 tky001ix05.iij.net (58.138.82.2) 9.767 ms > tky001ix05.iij.net (58.138.82.6) 6.101 ms > tky001ix01.iij.net (58.138.80.106) 8.420 ms > 8 203.181.102.61 (203.181.102.61) 19.514 ms > 203.181.102.21 (203.181.102.21) 6.054 ms > 203.181.102.61 (203.181.102.61) 11.478 ms > 9 otejbb203.kddnet.ad.jp (118.155.197.129) 7.457 ms > otejbb203.kddnet.ad.jp (59.128.7.129) 7.835 ms > otejbb204.kddnet.ad.jp (59.128.7.130) 7.824 ms > 10 cm-fcu203.kddnet.ad.jp (124.215.194.180) 15.860 ms 16.401 ms > cm-fcu203.kddnet.ad.jp (124.215.194.164) 17.519 ms > 11 124.215.199.122 (124.215.199.122) 7.892 ms * 11.984 ms > From faisal at snappydsl.net Sun Dec 11 20:06:16 2011 From: faisal at snappydsl.net (Faisal Imtiaz) Date: Sun, 11 Dec 2011 21:06:16 -0500 Subject: Overall Netflix bandwidth usage numbers on a network? In-Reply-To: <4EE54B01.6000305@temk.in> References: <20111203004732.GH13315@hijacked.us> <20111203005847.GI13315@hijacked.us> <4EDF9AE9.9040700@ispn.net> <4EE54B01.6000305@temk.in> Message-ID: <4EE56198.40307@snappydsl.net> Which leads to a question to be asked... Is netflix willing to peer directly with ISP / NSP's ? Regards. Faisal Imtiaz Snappy Internet& Telecom On 12/11/2011 7:29 PM, Dave Temkin wrote: > Feel free to contact peering at netflixcom - we're happy to provide > you with delivery statistics for traffic terminating on your network. > > Regards, > -Dave Temkin > Netflix > > On 12/7/11 8:57 AM, Blake Hudson wrote: >> Yeah, that's an interesting one. We currently utilize netflow for >> this, but you also need to consider that netflix streaming is just >> port 80 www traffic. Because netflix uses CDNs, its difficult to pin >> down the traffic to specific hosts in the CDN and say that this >> traffic was netflix, while this traffic was the latest windows update >> (remember this is often a shared hosting platform). We've done our >> own testing and have come to a good solution which uses a combination >> of nbar, packet marking, and netflow to come to a conclusion. On a >> ~160Mbps link, netflix peaks out between 30-50Mbps around 8-10PM each >> evening. The rest of the traffic is predominantly other forms of HTTP >> traffic (including other video streaming services). >> >> >> Martin Hepworth wrote the following on 12/3/2011 2:36 AM: >>> Also checkout Adrian Cockcroft presentations on their architecture >>> which >>> describes how they use aws and CDns etc >>> >>> Martin >>> >>> >> > > > From joelja at bogus.com Sun Dec 11 21:21:49 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 11 Dec 2011 19:21:49 -0800 Subject: Overall Netflix bandwidth usage numbers on a network? In-Reply-To: <4EE56198.40307@snappydsl.net> References: <20111203004732.GH13315@hijacked.us> <20111203005847.GI13315@hijacked.us> <4EDF9AE9.9040700@ispn.net> <4EE54B01.6000305@temk.in> <4EE56198.40307@snappydsl.net> Message-ID: <387BECF4-7EF9-43E6-BEEE-AA42DF1EEE19@bogus.com> Netflix uses CDNs for content delivery and the platform runs in EC2. What would peering with them achieve? Sent from my iPhone On Dec 11, 2011, at 18:06, Faisal Imtiaz wrote: > Which leads to a question to be asked... > > Is netflix willing to peer directly with ISP / NSP's ? > > Regards. > > Faisal Imtiaz > Snappy Internet& Telecom > > > On 12/11/2011 7:29 PM, Dave Temkin wrote: >> Feel free to contact peering at netflixcom - we're happy to provide you with delivery statistics for traffic terminating on your network. >> >> Regards, >> -Dave Temkin >> Netflix >> >> On 12/7/11 8:57 AM, Blake Hudson wrote: >>> Yeah, that's an interesting one. We currently utilize netflow for this, but you also need to consider that netflix streaming is just port 80 www traffic. Because netflix uses CDNs, its difficult to pin down the traffic to specific hosts in the CDN and say that this traffic was netflix, while this traffic was the latest windows update (remember this is often a shared hosting platform). We've done our own testing and have come to a good solution which uses a combination of nbar, packet marking, and netflow to come to a conclusion. On a ~160Mbps link, netflix peaks out between 30-50Mbps around 8-10PM each evening. The rest of the traffic is predominantly other forms of HTTP traffic (including other video streaming services). >>> >>> >>> Martin Hepworth wrote the following on 12/3/2011 2:36 AM: >>>> Also checkout Adrian Cockcroft presentations on their architecture which >>>> describes how they use aws and CDns etc >>>> >>>> Martin >>>> >>>> >>> >> >> >> > From mhuff at ox.com Sun Dec 11 21:28:36 2011 From: mhuff at ox.com (Matthew Huff) Date: Sun, 11 Dec 2011 22:28:36 -0500 Subject: Inaccessible network from Verizon, accessible elsewhere. In-Reply-To: References: <4ee532c6.8908e70a.5582.ffff8e19@mx.google.com> Message-ID: I'm seeing the same thing from my home lan via fios. I've run a recursive dns server for years and can't reach the roots. Had to switch to using verizon's dns servers as forwarders. Sent from my iPad On Dec 11, 2011, at 8:07 PM, "Brandon Kim" wrote: > > I too am now experiencing issues. I cannot get to www.cisco.com and various websites. > Some websites work lightning quick, some take a long time to load, and some just don't load at all..... > > > > >> Date: Mon, 12 Dec 2011 09:55:40 +0900 >> From: randy at psg.com >> To: nanog at nanog.org >> Subject: Re: Inaccessible network from Verizon, accessible elsewhere. >> >> from home lan >> >> % traceroute gw-li377.linode.com >> traceroute to gw-li377.linode.com (106.187.34.1), 64 hops max, 52 byte packets >> 1 192.168.0.1 (192.168.0.1) 1.471 ms 0.725 ms 0.555 ms >> 2 tokyo10-f03.flets.2iij.net (210.149.34.72) 7.241 ms 6.651 ms 6.939 ms >> 3 tokyo10-ntteast0.flets.2iij.net (210.149.34.157) 5.573 ms 6.109 ms 5.346 ms >> 4 tky001lip20.iij.net (210.149.34.97) 6.410 ms 7.471 ms 7.934 ms >> 5 tky001bb10.iij.net (58.138.100.209) 6.670 ms 9.251 ms 5.866 ms >> 6 tky009bf00.iij.net (58.138.80.17) 6.730 ms >> tky008bf02.iij.net (58.138.80.13) 7.021 ms >> tky009bf00.iij.net (58.138.80.17) 8.593 ms >> 7 tky001ix05.iij.net (58.138.82.2) 9.767 ms >> tky001ix05.iij.net (58.138.82.6) 6.101 ms >> tky001ix01.iij.net (58.138.80.106) 8.420 ms >> 8 203.181.102.61 (203.181.102.61) 19.514 ms >> 203.181.102.21 (203.181.102.21) 6.054 ms >> 203.181.102.61 (203.181.102.61) 11.478 ms >> 9 otejbb203.kddnet.ad.jp (118.155.197.129) 7.457 ms >> otejbb203.kddnet.ad.jp (59.128.7.129) 7.835 ms >> otejbb204.kddnet.ad.jp (59.128.7.130) 7.824 ms >> 10 cm-fcu203.kddnet.ad.jp (124.215.194.180) 15.860 ms 16.401 ms >> cm-fcu203.kddnet.ad.jp (124.215.194.164) 17.519 ms >> 11 124.215.199.122 (124.215.199.122) 7.892 ms * 11.984 ms >> > From Valdis.Kletnieks at vt.edu Sun Dec 11 21:42:48 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 11 Dec 2011 22:42:48 -0500 Subject: Overall Netflix bandwidth usage numbers on a network? In-Reply-To: Your message of "Sun, 11 Dec 2011 19:21:49 PST." <387BECF4-7EF9-43E6-BEEE-AA42DF1EEE19@bogus.com> References: <20111203004732.GH13315@hijacked.us> <20111203005847.GI13315@hijacked.us> <4EDF9AE9.9040700@ispn.net> <4EE54B01.6000305@temk.in> <4EE56198.40307@snappydsl.net> <387BECF4-7EF9-43E6-BEEE-AA42DF1EEE19@bogus.com> Message-ID: <59487.1323661368@turing-police.cc.vt.edu> On Sun, 11 Dec 2011 19:21:49 PST, Joel Jaeggli said: > Netflix uses CDNs for content delivery and the platform runs in EC2. What > would peering with them achieve? I suspect Faisal's *real* question is "Who at Netflix do I talk to in order to discuss mutually beneficial traffic engineering?" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From faisal at snappydsl.net Sun Dec 11 21:46:54 2011 From: faisal at snappydsl.net (Faisal Imtiaz) Date: Sun, 11 Dec 2011 22:46:54 -0500 Subject: Overall Netflix bandwidth usage numbers on a network? In-Reply-To: <387BECF4-7EF9-43E6-BEEE-AA42DF1EEE19@bogus.com> References: <20111203004732.GH13315@hijacked.us> <20111203005847.GI13315@hijacked.us> <4EDF9AE9.9040700@ispn.net> <4EE54B01.6000305@temk.in> <4EE56198.40307@snappydsl.net> <387BECF4-7EF9-43E6-BEEE-AA42DF1EEE19@bogus.com> Message-ID: <5ECE9281-B6CB-4669-857D-07E10A7C499C@snappydsl.net> Simple, keep traffic off paid ip transit circuits.... Faisal On Dec 11, 2011, at 10:21 PM, Joel Jaeggli wrote: > Netflix uses CDNs for content delivery and the platform runs in EC2. What would peering with them achieve? > > Sent from my iPhone > > On Dec 11, 2011, at 18:06, Faisal Imtiaz wrote: > >> Which leads to a question to be asked... >> >> Is netflix willing to peer directly with ISP / NSP's ? >> >> Regards. >> >> Faisal Imtiaz >> Snappy Internet& Telecom >> >> >> On 12/11/2011 7:29 PM, Dave Temkin wrote: >>> Feel free to contact peering at netflixcom - we're happy to provide you with delivery statistics for traffic terminating on your network. >>> >>> Regards, >>> -Dave Temkin >>> Netflix >>> >>> On 12/7/11 8:57 AM, Blake Hudson wrote: >>>> Yeah, that's an interesting one. We currently utilize netflow for this, but you also need to consider that netflix streaming is just port 80 www traffic. Because netflix uses CDNs, its difficult to pin down the traffic to specific hosts in the CDN and say that this traffic was netflix, while this traffic was the latest windows update (remember this is often a shared hosting platform). We've done our own testing and have come to a good solution which uses a combination of nbar, packet marking, and netflow to come to a conclusion. On a ~160Mbps link, netflix peaks out between 30-50Mbps around 8-10PM each evening. The rest of the traffic is predominantly other forms of HTTP traffic (including other video streaming services). >>>> >>>> >>>> Martin Hepworth wrote the following on 12/3/2011 2:36 AM: >>>>> Also checkout Adrian Cockcroft presentations on their architecture which >>>>> describes how they use aws and CDns etc >>>>> >>>>> Martin >>>>> >>>>> >>>> >>> >>> >>> >> > From morrowc.lists at gmail.com Sun Dec 11 21:46:29 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 11 Dec 2011 22:46:29 -0500 Subject: Inaccessible network from Verizon, accessible elsewhere. In-Reply-To: <421a1b73-817f-42d4-ab1e-9c5beaa96174@email.android.com> References: <421a1b73-817f-42d4-ab1e-9c5beaa96174@email.android.com> Message-ID: On Sun, Dec 11, 2011 at 3:11 PM, Joseph Snyder wrote: > I believe 130.81 is blocked. Traceroute to your gateway address. portions (at least) of that are 19262's loopback/ptp space, they block/rate-limit toward that at their edge. From morrowc.lists at gmail.com Sun Dec 11 21:48:19 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 11 Dec 2011 22:48:19 -0500 Subject: Inaccessible network from Verizon, accessible elsewhere. In-Reply-To: References: <4ee532c6.8908e70a.5582.ffff8e19@mx.google.com> Message-ID: On Sun, Dec 11, 2011 at 10:28 PM, Matthew Huff wrote: > I'm seeing the same thing from my home lan via fios. I've run a recursive dns server for years and can't reach the roots. Had to switch to using verizon's dns servers as forwarders. > business or consumer fios? 3 G0-9-4-7.WASHDC-LCR-22.verizon-gni.net (130.81.104.180) 6.662 ms 6.739 ms 6.788 ms 4 so-14-0-0-0.RES-BB-RTR2.verizon-gni.net (130.81.22.56) 6.852 ms 15.384 ms 8.184 ms 5 0.ae2.BR1.IAD8.ALTER.NET (152.63.32.158) 12.857 ms 12.927 ms 13.004 ms 6 dcp-brdr-03.inet.qwest.net (63.146.26.105) 12.429 ms 7.847 ms 6.464 ms 7 lap-brdr-03.inet.qwest.net (67.14.22.78) 89.140 ms 88.929 ms 89.032 ms 8 63.146.26.70 (63.146.26.70) 94.879 ms 94.580 ms 93.120 ms 9 sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112) 58.520 ms 58.330 ms 58.186 ms 10 144.232.25.193 (144.232.25.193) 49.950 ms sl-crs1-oma-0-9-2-0.sprintlink.net (144.232.2.177) 49.962 ms sl-crs1-oma-0-8-0-0.sprintlink.net (144.232.8.171) 47.687 ms 11 sl-crs1-oro-0-3-3-0.sprintlink.net (144.232.25.207) 84.416 ms 83.266 ms sl-crs1-oro-0-12-3-0.sprintlink.net (144.232.25.73) 84.667 ms 12 124.215.199.122 (124.215.199.122) 195.590 ms * * all of this seems to point at some kddi.net rouer gobbling packets, no? (since pretty much everyone's got the same terminating hop) - also note that while some folks traverse L3, my route is via qwest... it's interesting that 701 isn't picking their other peer (sprint) here directly, no? > Sent from my iPad > > On Dec 11, 2011, at 8:07 PM, "Brandon Kim" wrote: > >> >> I too am now experiencing issues. I cannot get to www.cisco.com and various websites. >> Some websites work lightning quick, some take a long time to load, and some just don't load at all..... >> >> >> >> >>> Date: Mon, 12 Dec 2011 09:55:40 +0900 >>> From: randy at psg.com >>> To: nanog at nanog.org >>> Subject: Re: Inaccessible network from Verizon, accessible elsewhere. >>> >>> from home lan >>> >>> % traceroute gw-li377.linode.com >>> traceroute to gw-li377.linode.com (106.187.34.1), 64 hops max, 52 byte packets >>> 1 ?192.168.0.1 (192.168.0.1) ?1.471 ms ?0.725 ms ?0.555 ms >>> 2 ?tokyo10-f03.flets.2iij.net (210.149.34.72) ?7.241 ms ?6.651 ms ?6.939 ms >>> 3 ?tokyo10-ntteast0.flets.2iij.net (210.149.34.157) ?5.573 ms ?6.109 ms ?5.346 ms >>> 4 ?tky001lip20.iij.net (210.149.34.97) ?6.410 ms ?7.471 ms ?7.934 ms >>> 5 ?tky001bb10.iij.net (58.138.100.209) ?6.670 ms ?9.251 ms ?5.866 ms >>> 6 ?tky009bf00.iij.net (58.138.80.17) ?6.730 ms >>> ? ?tky008bf02.iij.net (58.138.80.13) ?7.021 ms >>> ? ?tky009bf00.iij.net (58.138.80.17) ?8.593 ms >>> 7 ?tky001ix05.iij.net (58.138.82.2) ?9.767 ms >>> ? ?tky001ix05.iij.net (58.138.82.6) ?6.101 ms >>> ? ?tky001ix01.iij.net (58.138.80.106) ?8.420 ms >>> 8 ?203.181.102.61 (203.181.102.61) ?19.514 ms >>> ? ?203.181.102.21 (203.181.102.21) ?6.054 ms >>> ? ?203.181.102.61 (203.181.102.61) ?11.478 ms >>> 9 ?otejbb203.kddnet.ad.jp (118.155.197.129) ?7.457 ms >>> ? ?otejbb203.kddnet.ad.jp (59.128.7.129) ?7.835 ms >>> ? ?otejbb204.kddnet.ad.jp (59.128.7.130) ?7.824 ms >>> 10 ?cm-fcu203.kddnet.ad.jp (124.215.194.180) ?15.860 ms ?16.401 ms >>> ? ?cm-fcu203.kddnet.ad.jp (124.215.194.164) ?17.519 ms >>> 11 ?124.215.199.122 (124.215.199.122) ?7.892 ms * ?11.984 ms >>> >> > From morrowc.lists at gmail.com Sun Dec 11 21:49:03 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 11 Dec 2011 22:49:03 -0500 Subject: Overall Netflix bandwidth usage numbers on a network? In-Reply-To: <5ECE9281-B6CB-4669-857D-07E10A7C499C@snappydsl.net> References: <20111203004732.GH13315@hijacked.us> <20111203005847.GI13315@hijacked.us> <4EDF9AE9.9040700@ispn.net> <4EE54B01.6000305@temk.in> <4EE56198.40307@snappydsl.net> <387BECF4-7EF9-43E6-BEEE-AA42DF1EEE19@bogus.com> <5ECE9281-B6CB-4669-857D-07E10A7C499C@snappydsl.net> Message-ID: On Sun, Dec 11, 2011 at 10:46 PM, Faisal Imtiaz wrote: > Simple, keep traffic off paid ip transit circuits.... > (I think joel's point was: "peer with amazon, done-and-done") > Faisal > > On Dec 11, 2011, at 10:21 PM, Joel Jaeggli wrote: > >> Netflix uses CDNs for content delivery and the platform runs in EC2. What would peering with them achieve? >> >> Sent from my iPhone >> >> On Dec 11, 2011, at 18:06, Faisal Imtiaz wrote: >> >>> Which leads to a question to be asked... >>> >>> Is netflix willing to peer directly with ISP / NSP's ? >>> >>> Regards. >>> >>> Faisal Imtiaz >>> Snappy Internet& ?Telecom >>> >>> >>> On 12/11/2011 7:29 PM, Dave Temkin wrote: >>>> Feel free to contact peering at netflixcom - we're happy to provide you with delivery statistics for traffic terminating on your network. >>>> >>>> Regards, >>>> -Dave Temkin >>>> Netflix >>>> >>>> On 12/7/11 8:57 AM, Blake Hudson wrote: >>>>> Yeah, that's an interesting one. We currently utilize netflow for this, but you also need to consider that netflix streaming is just port 80 www traffic. Because netflix uses CDNs, its difficult to pin down the traffic to specific hosts in the CDN and say that this traffic was netflix, while this traffic was the latest windows update (remember this is often a shared hosting platform). We've done our own testing and have come to a good solution which uses a combination of nbar, packet marking, and netflow to come to a conclusion. On a ~160Mbps link, netflix peaks out between 30-50Mbps around 8-10PM each evening. The rest of the traffic is predominantly other forms of HTTP traffic (including other video streaming services). >>>>> >>>>> >>>>> Martin Hepworth wrote the following on 12/3/2011 2:36 AM: >>>>>> Also checkout Adrian Cockcroft presentations on their architecture which >>>>>> describes how they use aws and CDns etc >>>>>> >>>>>> Martin >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> >> > From mhuff at ox.com Sun Dec 11 21:54:43 2011 From: mhuff at ox.com (Matthew Huff) Date: Sun, 11 Dec 2011 22:54:43 -0500 Subject: Inaccessible network from Verizon, accessible elsewhere. In-Reply-To: References: <4ee532c6.8908e70a.5582.ffff8e19@mx.google.com> Message-ID: <0876509C-A9C4-4060-B0B1-4C46B0CBB478@ox.com> Consumer fios. Verizon forums are full of posts about it. Too tired this evening to worry about it. Sent from my iPad On Dec 11, 2011, at 10:48 PM, "Christopher Morrow" wrote: > On Sun, Dec 11, 2011 at 10:28 PM, Matthew Huff wrote: >> I'm seeing the same thing from my home lan via fios. I've run a recursive dns server for years and can't reach the roots. Had to switch to using verizon's dns servers as forwarders. >> > > business or consumer fios? > 3 G0-9-4-7.WASHDC-LCR-22.verizon-gni.net (130.81.104.180) 6.662 ms > 6.739 ms 6.788 ms > 4 so-14-0-0-0.RES-BB-RTR2.verizon-gni.net (130.81.22.56) 6.852 ms > 15.384 ms 8.184 ms > 5 0.ae2.BR1.IAD8.ALTER.NET (152.63.32.158) 12.857 ms 12.927 ms 13.004 ms > 6 dcp-brdr-03.inet.qwest.net (63.146.26.105) 12.429 ms 7.847 ms 6.464 ms > 7 lap-brdr-03.inet.qwest.net (67.14.22.78) 89.140 ms 88.929 ms 89.032 ms > 8 63.146.26.70 (63.146.26.70) 94.879 ms 94.580 ms 93.120 ms > 9 sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112) 58.520 ms > 58.330 ms 58.186 ms > 10 144.232.25.193 (144.232.25.193) 49.950 ms > sl-crs1-oma-0-9-2-0.sprintlink.net (144.232.2.177) 49.962 ms > sl-crs1-oma-0-8-0-0.sprintlink.net (144.232.8.171) 47.687 ms > 11 sl-crs1-oro-0-3-3-0.sprintlink.net (144.232.25.207) 84.416 ms > 83.266 ms sl-crs1-oro-0-12-3-0.sprintlink.net (144.232.25.73) 84.667 > ms > 12 124.215.199.122 (124.215.199.122) 195.590 ms * * > > all of this seems to point at some kddi.net rouer gobbling packets, > no? (since pretty much everyone's got the same terminating hop) - also > note that while some folks traverse L3, my route is via qwest... > > it's interesting that 701 isn't picking their other peer (sprint) here > directly, no? > >> Sent from my iPad >> >> On Dec 11, 2011, at 8:07 PM, "Brandon Kim" wrote: >> >>> >>> I too am now experiencing issues. I cannot get to www.cisco.com and various websites. >>> Some websites work lightning quick, some take a long time to load, and some just don't load at all..... >>> >>> >>> >>> >>>> Date: Mon, 12 Dec 2011 09:55:40 +0900 >>>> From: randy at psg.com >>>> To: nanog at nanog.org >>>> Subject: Re: Inaccessible network from Verizon, accessible elsewhere. >>>> >>>> from home lan >>>> >>>> % traceroute gw-li377.linode.com >>>> traceroute to gw-li377.linode.com (106.187.34.1), 64 hops max, 52 byte packets >>>> 1 192.168.0.1 (192.168.0.1) 1.471 ms 0.725 ms 0.555 ms >>>> 2 tokyo10-f03.flets.2iij.net (210.149.34.72) 7.241 ms 6.651 ms 6.939 ms >>>> 3 tokyo10-ntteast0.flets.2iij.net (210.149.34.157) 5.573 ms 6.109 ms 5.346 ms >>>> 4 tky001lip20.iij.net (210.149.34.97) 6.410 ms 7.471 ms 7.934 ms >>>> 5 tky001bb10.iij.net (58.138.100.209) 6.670 ms 9.251 ms 5.866 ms >>>> 6 tky009bf00.iij.net (58.138.80.17) 6.730 ms >>>> tky008bf02.iij.net (58.138.80.13) 7.021 ms >>>> tky009bf00.iij.net (58.138.80.17) 8.593 ms >>>> 7 tky001ix05.iij.net (58.138.82.2) 9.767 ms >>>> tky001ix05.iij.net (58.138.82.6) 6.101 ms >>>> tky001ix01.iij.net (58.138.80.106) 8.420 ms >>>> 8 203.181.102.61 (203.181.102.61) 19.514 ms >>>> 203.181.102.21 (203.181.102.21) 6.054 ms >>>> 203.181.102.61 (203.181.102.61) 11.478 ms >>>> 9 otejbb203.kddnet.ad.jp (118.155.197.129) 7.457 ms >>>> otejbb203.kddnet.ad.jp (59.128.7.129) 7.835 ms >>>> otejbb204.kddnet.ad.jp (59.128.7.130) 7.824 ms >>>> 10 cm-fcu203.kddnet.ad.jp (124.215.194.180) 15.860 ms 16.401 ms >>>> cm-fcu203.kddnet.ad.jp (124.215.194.164) 17.519 ms >>>> 11 124.215.199.122 (124.215.199.122) 7.892 ms * 11.984 ms >>>> >>> >> From faisal at snappydsl.net Sun Dec 11 22:41:23 2011 From: faisal at snappydsl.net (Faisal Imtiaz) Date: Sun, 11 Dec 2011 23:41:23 -0500 Subject: Overall Netflix bandwidth usage numbers on a network? In-Reply-To: References: <20111203004732.GH13315@hijacked.us> <20111203005847.GI13315@hijacked.us> <4EDF9AE9.9040700@ispn.net> <4EE54B01.6000305@temk.in> <4EE56198.40307@snappydsl.net> <387BECF4-7EF9-43E6-BEEE-AA42DF1EEE19@bogus.com> <5ECE9281-B6CB-4669-857D-07E10A7C499C@snappydsl.net> Message-ID: <9ECB39B8-43F2-481F-8F19-AAA44197D678@snappydsl.net> Thanks for the explanation...did not consider that before...will investigate.., any tips that can be shared will be welcome. :) Faisal On Dec 11, 2011, at 10:49 PM, Christopher Morrow wrote: > On Sun, Dec 11, 2011 at 10:46 PM, Faisal Imtiaz wrote: >> Simple, keep traffic off paid ip transit circuits.... >> > > (I think joel's point was: "peer with amazon, done-and-done") > >> Faisal >> >> On Dec 11, 2011, at 10:21 PM, Joel Jaeggli wrote: >> >>> Netflix uses CDNs for content delivery and the platform runs in EC2. What would peering with them achieve? >>> >>> Sent from my iPhone >>> >>> On Dec 11, 2011, at 18:06, Faisal Imtiaz wrote: >>> >>>> Which leads to a question to be asked... >>>> >>>> Is netflix willing to peer directly with ISP / NSP's ? >>>> >>>> Regards. >>>> >>>> Faisal Imtiaz >>>> Snappy Internet& Telecom >>>> >>>> >>>> On 12/11/2011 7:29 PM, Dave Temkin wrote: >>>>> Feel free to contact peering at netflixcom - we're happy to provide you with delivery statistics for traffic terminating on your network. >>>>> >>>>> Regards, >>>>> -Dave Temkin >>>>> Netflix >>>>> >>>>> On 12/7/11 8:57 AM, Blake Hudson wrote: >>>>>> Yeah, that's an interesting one. We currently utilize netflow for this, but you also need to consider that netflix streaming is just port 80 www traffic. Because netflix uses CDNs, its difficult to pin down the traffic to specific hosts in the CDN and say that this traffic was netflix, while this traffic was the latest windows update (remember this is often a shared hosting platform). We've done our own testing and have come to a good solution which uses a combination of nbar, packet marking, and netflow to come to a conclusion. On a ~160Mbps link, netflix peaks out between 30-50Mbps around 8-10PM each evening. The rest of the traffic is predominantly other forms of HTTP traffic (including other video streaming services). >>>>>> >>>>>> >>>>>> Martin Hepworth wrote the following on 12/3/2011 2:36 AM: >>>>>>> Also checkout Adrian Cockcroft presentations on their architecture which >>>>>>> describes how they use aws and CDns etc >>>>>>> >>>>>>> Martin >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> >> > From joelja at bogus.com Sun Dec 11 23:18:06 2011 From: joelja at bogus.com (Joel jaeggli) Date: Sun, 11 Dec 2011 21:18:06 -0800 Subject: Overall Netflix bandwidth usage numbers on a network? In-Reply-To: References: <20111203004732.GH13315@hijacked.us> <20111203005847.GI13315@hijacked.us> <4EDF9AE9.9040700@ispn.net> <4EE54B01.6000305@temk.in> <4EE56198.40307@snappydsl.net> <387BECF4-7EF9-43E6-BEEE-AA42DF1EEE19@bogus.com> <5ECE9281-B6CB-4669-857D-07E10A7C499C@snappydsl.net> Message-ID: <4EE58E8E.8000804@bogus.com> On 12/11/11 19:49 , Christopher Morrow wrote: > On Sun, Dec 11, 2011 at 10:46 PM, Faisal Imtiaz wrote: >> Simple, keep traffic off paid ip transit circuits.... >> > (I think joel's point was: "peer with amazon, done-and-done") also probably your relationships to akamai and level3 >> Faisal >> >> On Dec 11, 2011, at 10:21 PM, Joel Jaeggli wrote: >> >>> Netflix uses CDNs for content delivery and the platform runs in EC2. What would peering with them achieve? >>> >>> Sent from my iPhone >>> >>> On Dec 11, 2011, at 18:06, Faisal Imtiaz wrote: >>> >>>> Which leads to a question to be asked... >>>> >>>> Is netflix willing to peer directly with ISP / NSP's ? >>>> >>>> Regards. >>>> >>>> Faisal Imtiaz >>>> Snappy Internet& Telecom >>>> >>>> >>>> On 12/11/2011 7:29 PM, Dave Temkin wrote: >>>>> Feel free to contact peering at netflixcom - we're happy to provide you with delivery statistics for traffic terminating on your network. >>>>> >>>>> Regards, >>>>> -Dave Temkin >>>>> Netflix >>>>> >>>>> On 12/7/11 8:57 AM, Blake Hudson wrote: >>>>>> Yeah, that's an interesting one. We currently utilize netflow for this, but you also need to consider that netflix streaming is just port 80 www traffic. Because netflix uses CDNs, its difficult to pin down the traffic to specific hosts in the CDN and say that this traffic was netflix, while this traffic was the latest windows update (remember this is often a shared hosting platform). We've done our own testing and have come to a good solution which uses a combination of nbar, packet marking, and netflow to come to a conclusion. On a ~160Mbps link, netflix peaks out between 30-50Mbps around 8-10PM each evening. The rest of the traffic is predominantly other forms of HTTP traffic (including other video streaming services). >>>>>> >>>>>> >>>>>> Martin Hepworth wrote the following on 12/3/2011 2:36 AM: >>>>>>> Also checkout Adrian Cockcroft presentations on their architecture which >>>>>>> describes how they use aws and CDns etc >>>>>>> >>>>>>> Martin >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> >> > From shaun at shaun.net Sun Dec 11 23:35:52 2011 From: shaun at shaun.net (Shaun Ewing) Date: Mon, 12 Dec 2011 16:35:52 +1100 Subject: Overall Netflix bandwidth usage numbers on a network? In-Reply-To: <4EE58E8E.8000804@bogus.com> References: <20111203004732.GH13315@hijacked.us> <20111203005847.GI13315@hijacked.us> <4EDF9AE9.9040700@ispn.net> <4EE54B01.6000305@temk.in> <4EE56198.40307@snappydsl.net> <387BECF4-7EF9-43E6-BEEE-AA42DF1EEE19@bogus.com> <5ECE9281-B6CB-4669-857D-07E10A7C499C@snappydsl.net> <4EE58E8E.8000804@bogus.com> Message-ID: On 12/12/2011, at 4:18 PM, Joel jaeggli wrote: > also probably your relationships to akamai and level3 Probably want to add Limelight to that list as well (do Netflix even use Akamai these days?) -Shaun -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3626 bytes Desc: not available URL: From beckman at angryox.com Sun Dec 11 23:37:55 2011 From: beckman at angryox.com (Peter Beckman) Date: Mon, 12 Dec 2011 00:37:55 -0500 Subject: Overall Netflix bandwidth usage numbers on a network? In-Reply-To: References: <20111203004732.GH13315@hijacked.us> <20111203005847.GI13315@hijacked.us> <4EDF9AE9.9040700@ispn.net> <4EE54B01.6000305@temk.in> <4EE56198.40307@snappydsl.net> <387BECF4-7EF9-43E6-BEEE-AA42DF1EEE19@bogus.com> <5ECE9281-B6CB-4669-857D-07E10A7C499C@snappydsl.net> Message-ID: On Sun, 11 Dec 2011, Christopher Morrow wrote: > On Sun, Dec 11, 2011 at 10:46 PM, Faisal Imtiaz wrote: >> Simple, keep traffic off paid ip transit circuits.... >> > > (I think joel's point was: "peer with amazon, done-and-done") DirectConnect seems to be a good way to get a dedicated 1G or 10G link with AWS: http://aws.amazon.com/directconnect/ It's not settlement-free peering, but it's an option if you can't negotiate something. Maybe it will reduce costs in some use cases. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From morrowc.lists at gmail.com Mon Dec 12 00:02:04 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 12 Dec 2011 01:02:04 -0500 Subject: Inaccessible network from Verizon, accessible elsewhere. In-Reply-To: <0876509C-A9C4-4060-B0B1-4C46B0CBB478@ox.com> References: <4ee532c6.8908e70a.5582.ffff8e19@mx.google.com> <0876509C-A9C4-4060-B0B1-4C46B0CBB478@ox.com> Message-ID: On Sun, Dec 11, 2011 at 10:54 PM, Matthew Huff wrote: > Consumer fios. Verizon forums are full of posts about it. Too tired this evening to worry about it. :( I'll have to do some testing when I get near a consumer fios then... So, they squash all DNS NOT to their complexes, that seems rather dastardly of them... considering they deployed that hateful paxfire/nominum garbage on their recursive servers :( -chris > On Dec 11, 2011, at 10:48 PM, "Christopher Morrow" wrote: > >> On Sun, Dec 11, 2011 at 10:28 PM, Matthew Huff wrote: >>> I'm seeing the same thing from my home lan via fios. I've run a recursive dns server for years and can't reach the roots. Had to switch to using verizon's dns servers as forwarders. >>> >> >> business or consumer fios? >> 3 ?G0-9-4-7.WASHDC-LCR-22.verizon-gni.net (130.81.104.180) ?6.662 ms >> 6.739 ms ?6.788 ms >> 4 ?so-14-0-0-0.RES-BB-RTR2.verizon-gni.net (130.81.22.56) ?6.852 ms >> 15.384 ms ?8.184 ms >> 5 ?0.ae2.BR1.IAD8.ALTER.NET (152.63.32.158) ?12.857 ms ?12.927 ms ?13.004 ms >> 6 ?dcp-brdr-03.inet.qwest.net (63.146.26.105) ?12.429 ms ?7.847 ms ?6.464 ms >> 7 ?lap-brdr-03.inet.qwest.net (67.14.22.78) ?89.140 ms ?88.929 ms ?89.032 ms >> 8 ?63.146.26.70 (63.146.26.70) ?94.879 ms ?94.580 ms ?93.120 ms >> 9 ?sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112) ?58.520 ms >> 58.330 ms ?58.186 ms >> 10 ?144.232.25.193 (144.232.25.193) ?49.950 ms >> sl-crs1-oma-0-9-2-0.sprintlink.net (144.232.2.177) ?49.962 ms >> sl-crs1-oma-0-8-0-0.sprintlink.net (144.232.8.171) ?47.687 ms >> 11 ?sl-crs1-oro-0-3-3-0.sprintlink.net (144.232.25.207) ?84.416 ms >> 83.266 ms sl-crs1-oro-0-12-3-0.sprintlink.net (144.232.25.73) ?84.667 >> ms >> 12 ?124.215.199.122 (124.215.199.122) ?195.590 ms * * >> >> all of this seems to point at some kddi.net rouer gobbling packets, >> no? (since pretty much everyone's got the same terminating hop) - also >> note that while some folks traverse L3, my route is via qwest... >> >> it's interesting that 701 isn't picking their other peer (sprint) here >> directly, no? >> >>> Sent from my iPad >>> >>> On Dec 11, 2011, at 8:07 PM, "Brandon Kim" wrote: >>> >>>> >>>> I too am now experiencing issues. I cannot get to www.cisco.com and various websites. >>>> Some websites work lightning quick, some take a long time to load, and some just don't load at all..... >>>> >>>> >>>> >>>> >>>>> Date: Mon, 12 Dec 2011 09:55:40 +0900 >>>>> From: randy at psg.com >>>>> To: nanog at nanog.org >>>>> Subject: Re: Inaccessible network from Verizon, accessible elsewhere. >>>>> >>>>> from home lan >>>>> >>>>> % traceroute gw-li377.linode.com >>>>> traceroute to gw-li377.linode.com (106.187.34.1), 64 hops max, 52 byte packets >>>>> 1 ?192.168.0.1 (192.168.0.1) ?1.471 ms ?0.725 ms ?0.555 ms >>>>> 2 ?tokyo10-f03.flets.2iij.net (210.149.34.72) ?7.241 ms ?6.651 ms ?6.939 ms >>>>> 3 ?tokyo10-ntteast0.flets.2iij.net (210.149.34.157) ?5.573 ms ?6.109 ms ?5.346 ms >>>>> 4 ?tky001lip20.iij.net (210.149.34.97) ?6.410 ms ?7.471 ms ?7.934 ms >>>>> 5 ?tky001bb10.iij.net (58.138.100.209) ?6.670 ms ?9.251 ms ?5.866 ms >>>>> 6 ?tky009bf00.iij.net (58.138.80.17) ?6.730 ms >>>>> ? ?tky008bf02.iij.net (58.138.80.13) ?7.021 ms >>>>> ? ?tky009bf00.iij.net (58.138.80.17) ?8.593 ms >>>>> 7 ?tky001ix05.iij.net (58.138.82.2) ?9.767 ms >>>>> ? ?tky001ix05.iij.net (58.138.82.6) ?6.101 ms >>>>> ? ?tky001ix01.iij.net (58.138.80.106) ?8.420 ms >>>>> 8 ?203.181.102.61 (203.181.102.61) ?19.514 ms >>>>> ? ?203.181.102.21 (203.181.102.21) ?6.054 ms >>>>> ? ?203.181.102.61 (203.181.102.61) ?11.478 ms >>>>> 9 ?otejbb203.kddnet.ad.jp (118.155.197.129) ?7.457 ms >>>>> ? ?otejbb203.kddnet.ad.jp (59.128.7.129) ?7.835 ms >>>>> ? ?otejbb204.kddnet.ad.jp (59.128.7.130) ?7.824 ms >>>>> 10 ?cm-fcu203.kddnet.ad.jp (124.215.194.180) ?15.860 ms ?16.401 ms >>>>> ? ?cm-fcu203.kddnet.ad.jp (124.215.194.164) ?17.519 ms >>>>> 11 ?124.215.199.122 (124.215.199.122) ?7.892 ms * ?11.984 ms >>>>> >>>> >>> From maillist at webjogger.net Mon Dec 12 00:26:41 2011 From: maillist at webjogger.net (Adam Greene) Date: Mon, 12 Dec 2011 01:26:41 -0500 Subject: Inaccessible network from Verizon, accessible elsewhere. In-Reply-To: References: <4ee532c6.8908e70a.5582.ffff8e19@mx.google.com> <0876509C-A9C4-4060-B0B1-4C46B0CBB478@ox.com> Message-ID: <4EE59EA1.6070400@webjogger.net> We're having strange issues in NYC metropolitan area. We can trace from Verizon FIOS to some IP addresses of our ASN 11579 block. Others don't work. The IP's that don't work seem to die at 130.81.107.228 on the Verizon network. Something is rotten in Denmark. Or NY. You know what I mean. On 12/12/2011 1:02 AM, Christopher Morrow wrote: > On Sun, Dec 11, 2011 at 10:54 PM, Matthew Huff wrote: >> Consumer fios. Verizon forums are full of posts about it. Too tired this evening to worry about it. > :( I'll have to do some testing when I get near a consumer fios > then... So, they squash all DNS NOT to their complexes, that seems > rather dastardly of them... considering they deployed that hateful > paxfire/nominum garbage on their recursive servers :( > > -chris > >> On Dec 11, 2011, at 10:48 PM, "Christopher Morrow" wrote: >> >>> On Sun, Dec 11, 2011 at 10:28 PM, Matthew Huff wrote: >>>> I'm seeing the same thing from my home lan via fios. I've run a recursive dns server for years and can't reach the roots. Had to switch to using verizon's dns servers as forwarders. >>>> >>> business or consumer fios? >>> 3 G0-9-4-7.WASHDC-LCR-22.verizon-gni.net (130.81.104.180) 6.662 ms >>> 6.739 ms 6.788 ms >>> 4 so-14-0-0-0.RES-BB-RTR2.verizon-gni.net (130.81.22.56) 6.852 ms >>> 15.384 ms 8.184 ms >>> 5 0.ae2.BR1.IAD8.ALTER.NET (152.63.32.158) 12.857 ms 12.927 ms 13.004 ms >>> 6 dcp-brdr-03.inet.qwest.net (63.146.26.105) 12.429 ms 7.847 ms 6.464 ms >>> 7 lap-brdr-03.inet.qwest.net (67.14.22.78) 89.140 ms 88.929 ms 89.032 ms >>> 8 63.146.26.70 (63.146.26.70) 94.879 ms 94.580 ms 93.120 ms >>> 9 sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112) 58.520 ms >>> 58.330 ms 58.186 ms >>> 10 144.232.25.193 (144.232.25.193) 49.950 ms >>> sl-crs1-oma-0-9-2-0.sprintlink.net (144.232.2.177) 49.962 ms >>> sl-crs1-oma-0-8-0-0.sprintlink.net (144.232.8.171) 47.687 ms >>> 11 sl-crs1-oro-0-3-3-0.sprintlink.net (144.232.25.207) 84.416 ms >>> 83.266 ms sl-crs1-oro-0-12-3-0.sprintlink.net (144.232.25.73) 84.667 >>> ms >>> 12 124.215.199.122 (124.215.199.122) 195.590 ms * * >>> >>> all of this seems to point at some kddi.net rouer gobbling packets, >>> no? (since pretty much everyone's got the same terminating hop) - also >>> note that while some folks traverse L3, my route is via qwest... >>> >>> it's interesting that 701 isn't picking their other peer (sprint) here >>> directly, no? >>> >>>> Sent from my iPad >>>> >>>> On Dec 11, 2011, at 8:07 PM, "Brandon Kim" wrote: >>>> >>>>> I too am now experiencing issues. I cannot get to www.cisco.com and various websites. >>>>> Some websites work lightning quick, some take a long time to load, and some just don't load at all..... >>>>> >>>>> >>>>> >>>>> >>>>>> Date: Mon, 12 Dec 2011 09:55:40 +0900 >>>>>> From: randy at psg.com >>>>>> To: nanog at nanog.org >>>>>> Subject: Re: Inaccessible network from Verizon, accessible elsewhere. >>>>>> >>>>>> from home lan >>>>>> >>>>>> % traceroute gw-li377.linode.com >>>>>> traceroute to gw-li377.linode.com (106.187.34.1), 64 hops max, 52 byte packets >>>>>> 1 192.168.0.1 (192.168.0.1) 1.471 ms 0.725 ms 0.555 ms >>>>>> 2 tokyo10-f03.flets.2iij.net (210.149.34.72) 7.241 ms 6.651 ms 6.939 ms >>>>>> 3 tokyo10-ntteast0.flets.2iij.net (210.149.34.157) 5.573 ms 6.109 ms 5.346 ms >>>>>> 4 tky001lip20.iij.net (210.149.34.97) 6.410 ms 7.471 ms 7.934 ms >>>>>> 5 tky001bb10.iij.net (58.138.100.209) 6.670 ms 9.251 ms 5.866 ms >>>>>> 6 tky009bf00.iij.net (58.138.80.17) 6.730 ms >>>>>> tky008bf02.iij.net (58.138.80.13) 7.021 ms >>>>>> tky009bf00.iij.net (58.138.80.17) 8.593 ms >>>>>> 7 tky001ix05.iij.net (58.138.82.2) 9.767 ms >>>>>> tky001ix05.iij.net (58.138.82.6) 6.101 ms >>>>>> tky001ix01.iij.net (58.138.80.106) 8.420 ms >>>>>> 8 203.181.102.61 (203.181.102.61) 19.514 ms >>>>>> 203.181.102.21 (203.181.102.21) 6.054 ms >>>>>> 203.181.102.61 (203.181.102.61) 11.478 ms >>>>>> 9 otejbb203.kddnet.ad.jp (118.155.197.129) 7.457 ms >>>>>> otejbb203.kddnet.ad.jp (59.128.7.129) 7.835 ms >>>>>> otejbb204.kddnet.ad.jp (59.128.7.130) 7.824 ms >>>>>> 10 cm-fcu203.kddnet.ad.jp (124.215.194.180) 15.860 ms 16.401 ms >>>>>> cm-fcu203.kddnet.ad.jp (124.215.194.164) 17.519 ms >>>>>> 11 124.215.199.122 (124.215.199.122) 7.892 ms * 11.984 ms >>>>>> > > From morrowc.lists at gmail.com Mon Dec 12 01:17:06 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 12 Dec 2011 02:17:06 -0500 Subject: Inaccessible network from Verizon, accessible elsewhere. In-Reply-To: <4EE59EA1.6070400@webjogger.net> References: <4ee532c6.8908e70a.5582.ffff8e19@mx.google.com> <0876509C-A9C4-4060-B0B1-4C46B0CBB478@ox.com> <4EE59EA1.6070400@webjogger.net> Message-ID: On Mon, Dec 12, 2011 at 1:26 AM, Adam Greene wrote: > 130.81.107.228 hrm... LCR == lata-core-router... something fairly close to you, like 2 router-hops from your first L3 hop... sounds like someone ought to call the vz customer service line and ask for a fix :) From maillist at webjogger.net Mon Dec 12 01:55:39 2011 From: maillist at webjogger.net (Adam Greene) Date: Mon, 12 Dec 2011 02:55:39 -0500 Subject: Inaccessible network from Verizon, accessible elsewhere. In-Reply-To: References: <4ee532c6.8908e70a.5582.ffff8e19@mx.google.com> <0876509C-A9C4-4060-B0B1-4C46B0CBB478@ox.com> <4EE59EA1.6070400@webjogger.net> Message-ID: <4EE5B37B.70505@webjogger.net> Yep, tried that. Connected with a lower level tech who would not escalate. Anyone know a Verizon NOC direct contact #? On 12/12/2011 2:17 AM, Christopher Morrow wrote: > On Mon, Dec 12, 2011 at 1:26 AM, Adam Greene wrote: >> 130.81.107.228 > > hrm... LCR == lata-core-router... something fairly close to you, like > 2 router-hops from your first L3 hop... sounds like someone ought to > call the vz customer service line and ask for a fix :) > > From avitkovsky at emea.att.com Mon Dec 12 03:17:08 2011 From: avitkovsky at emea.att.com (Vitkovsky, Adam) Date: Mon, 12 Dec 2011 10:17:08 +0100 Subject: Sad IPv4 story? In-Reply-To: <3ADD5AAC-C95A-48CD-8880-F44E799C8A25@eparsonage.com> References: <20196.3069.632519.601259@world.std.com> <15282.1323576426@turing-police.cc.vt.edu> <3ADD5AAC-C95A-48CD-8880-F44E799C8A25@eparsonage.com> Message-ID: > and models that doesn't take "we may not get IPv4 space" into account and have > a contingency plan for that *deserves* to be soundly mocked and ridiculed in > public. That's right However the original post was concerning a fresh new ISP that can't run their business the way they would like Maybe they'd like to build an mpls core which right now is not possible with only ipv6 at hand I'd like to see the business model to build an mpls network with all the features we're used to -but solely on ipv6 -I guess the plan would be let's wait a couple years till it gets implemented and mature enough From leigh.porter at ukbroadband.com Mon Dec 12 04:05:02 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Mon, 12 Dec 2011 10:05:02 +0000 Subject: Sad IPv4 story? In-Reply-To: References: <20196.3069.632519.601259@world.std.com> <15282.1323576426@turing-police.cc.vt.edu> <3ADD5AAC-C95A-48CD-8880-F44E799C8A25@eparsonage.com> Message-ID: > -----Original Message----- > From: Vitkovsky, Adam [mailto:avitkovsky at emea.att.com] > Sent: 12 December 2011 09:19 > To: Eric Parsonage; Valdis.Kletnieks at vt.edu > Cc: nanog at nanog.org > Subject: RE: Sad IPv4 story? > > > and models that doesn't take "we may not get IPv4 space" into account > and have > > a contingency plan for that *deserves* to be soundly mocked and > ridiculed in > > public. > > That's right > > However the original post was concerning a fresh new ISP that can't run > their business the way they would like > Maybe they'd like to build an mpls core which right now is not possible > with only ipv6 at hand > I'd like to see the business model to build an mpls network with all > the features we're used to -but solely on ipv6 -I guess the plan would > be let's wait a couple years till it gets implemented and mature enough Well really this is pretty much our fault. IPv6 has been on peoples 'back burner' for far too long. Additional vendor pressure and pressure at the IETF would have pushed things forward far faster had people actually been interested in doing so. As per an earlier post, I am shocked at how I still have vendors coming to me with equipment that is nowhere near ready for commercial IPv6 deployment, it either just does not work, is half baked or is "on the roadmap". So now we will reap the consequences and it will be at the cost of new market entrants (which I am sure will please some people) and perhaps cold hard cash for those who cannot expand their business or have to 'buy' address space. I know a lot of people have been working hard to move IPv6 along both here, at NANOG and other events and with their vendors. It's because of those people, like Randy perhaps that we actually have what we do now else most people would still be stuck with their heads in the sand. Well, I am sure it'll all be OK in the end... -- Leigh ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From mtinka at globaltransit.net Mon Dec 12 06:02:14 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Mon, 12 Dec 2011 20:02:14 +0800 Subject: Sad IPv4 story? In-Reply-To: References: <3ADD5AAC-C95A-48CD-8880-F44E799C8A25@eparsonage.com> Message-ID: <201112122002.18859.mtinka@globaltransit.net> On Monday, December 12, 2011 05:17:08 PM Vitkovsky, Adam wrote: > However the original post was concerning a fresh new ISP > that can't run their business the way they would like > Maybe they'd like to build an mpls core which right now > is not possible with only ipv6 at hand I'd like to see > the business model to build an mpls network with all the > features we're used to -but solely on ipv6 -I guess the > plan would be let's wait a couple years till it gets > implemented and mature enough I've been pushing Cisco and Juniper since 2007 for LDPv6 and RSVPv6 since 2007. I kept getting non-commital "end of this year, end of this year". After catching up with Cisco during an update of the ASR9000 a couple of weeks back, I'm meant to understand support will be coming around Q1'13 on this platform (which, by association, might mean other IOS XR platforms like the CRS). It's not clear about other Cisco systems, but I'll be pleasantly surprised if they maintain the time lines. All this despite the fact that drafts have been out for years. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mhuff at ox.com Mon Dec 12 07:44:56 2011 From: mhuff at ox.com (Matthew Huff) Date: Mon, 12 Dec 2011 08:44:56 -0500 Subject: Inaccessible network from Verizon, accessible elsewhere. In-Reply-To: <4EE59EA1.6070400@webjogger.net> References: <4ee532c6.8908e70a.5582.ffff8e19@mx.google.com> <0876509C-A9C4-4060-B0B1-4C46B0CBB478@ox.com> <4EE59EA1.6070400@webjogger.net> Message-ID: <483E6B0272B0284BA86D7596C40D29F901212A80D599@PUR-EXCH07.ox.com> DSLReports Verizon forum reports routing issues in Westchester, Rockland and Nassau. I tried a few traceroutes this morning. Some went through fine, others died at the first hop within Verizon. People are reporting mixed results calling Verizon. Some techs are saying it's a known issues, others are going through the standard script (reboot router, reboot ONT, check settings on browser, i.e. clueless, even to the point of saying that the person's router is bad and they would send them a new one). ---- Matthew Huff? | 1 Manhattanville Rd Director of Operations???| Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff? | Fax:?? 914-460-4139 > -----Original Message----- > From: Adam Greene [mailto:maillist at webjogger.net] > Sent: Monday, December 12, 2011 1:27 AM > To: nanog at nanog.org > Subject: Re: Inaccessible network from Verizon, accessible elsewhere. > > We're having strange issues in NYC metropolitan area. > > We can trace from Verizon FIOS to some IP addresses of our ASN 11579 > block. Others don't work. The IP's that don't work seem to die at > 130.81.107.228 on the Verizon network. > > Something is rotten in Denmark. Or NY. You know what I mean. > > On 12/12/2011 1:02 AM, Christopher Morrow wrote: > > On Sun, Dec 11, 2011 at 10:54 PM, Matthew Huff wrote: > >> Consumer fios. Verizon forums are full of posts about it. Too tired > this evening to worry about it. > > :( I'll have to do some testing when I get near a consumer fios > > then... So, they squash all DNS NOT to their complexes, that seems > > rather dastardly of them... considering they deployed that hateful > > paxfire/nominum garbage on their recursive servers :( > > > > -chris > > > >> On Dec 11, 2011, at 10:48 PM, "Christopher > Morrow" wrote: > >> > >>> On Sun, Dec 11, 2011 at 10:28 PM, Matthew Huff > wrote: > >>>> I'm seeing the same thing from my home lan via fios. I've run a > recursive dns server for years and can't reach the roots. Had to switch > to using verizon's dns servers as forwarders. > >>>> > >>> business or consumer fios? > >>> 3 G0-9-4-7.WASHDC-LCR-22.verizon-gni.net (130.81.104.180) 6.662 > ms > >>> 6.739 ms 6.788 ms > >>> 4 so-14-0-0-0.RES-BB-RTR2.verizon-gni.net (130.81.22.56) 6.852 ms > >>> 15.384 ms 8.184 ms > >>> 5 0.ae2.BR1.IAD8.ALTER.NET (152.63.32.158) 12.857 ms 12.927 ms > >>> 13.004 ms > >>> 6 dcp-brdr-03.inet.qwest.net (63.146.26.105) 12.429 ms 7.847 ms > >>> 6.464 ms > >>> 7 lap-brdr-03.inet.qwest.net (67.14.22.78) 89.140 ms 88.929 ms > >>> 89.032 ms > >>> 8 63.146.26.70 (63.146.26.70) 94.879 ms 94.580 ms 93.120 ms > >>> 9 sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112) 58.520 ms > >>> 58.330 ms 58.186 ms > >>> 10 144.232.25.193 (144.232.25.193) 49.950 ms > >>> sl-crs1-oma-0-9-2-0.sprintlink.net (144.232.2.177) 49.962 ms > >>> sl-crs1-oma-0-8-0-0.sprintlink.net (144.232.8.171) 47.687 ms > >>> 11 sl-crs1-oro-0-3-3-0.sprintlink.net (144.232.25.207) 84.416 ms > >>> 83.266 ms sl-crs1-oro-0-12-3-0.sprintlink.net (144.232.25.73) > >>> 84.667 ms > >>> 12 124.215.199.122 (124.215.199.122) 195.590 ms * * > >>> > >>> all of this seems to point at some kddi.net rouer gobbling packets, > >>> no? (since pretty much everyone's got the same terminating hop) - > >>> also note that while some folks traverse L3, my route is via > qwest... > >>> > >>> it's interesting that 701 isn't picking their other peer (sprint) > >>> here directly, no? > >>> > >>>> Sent from my iPad > >>>> > >>>> On Dec 11, 2011, at 8:07 PM, "Brandon > Kim" wrote: > >>>> > >>>>> I too am now experiencing issues. I cannot get to www.cisco.com > and various websites. > >>>>> Some websites work lightning quick, some take a long time to > load, and some just don't load at all..... > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> Date: Mon, 12 Dec 2011 09:55:40 +0900 > >>>>>> From: randy at psg.com > >>>>>> To: nanog at nanog.org > >>>>>> Subject: Re: Inaccessible network from Verizon, accessible > elsewhere. > >>>>>> > >>>>>> from home lan > >>>>>> > >>>>>> % traceroute gw-li377.linode.com > >>>>>> traceroute to gw-li377.linode.com (106.187.34.1), 64 hops max, > 52 > >>>>>> byte packets > >>>>>> 1 192.168.0.1 (192.168.0.1) 1.471 ms 0.725 ms 0.555 ms > >>>>>> 2 tokyo10-f03.flets.2iij.net (210.149.34.72) 7.241 ms 6.651 > ms > >>>>>> 6.939 ms > >>>>>> 3 tokyo10-ntteast0.flets.2iij.net (210.149.34.157) 5.573 ms > >>>>>> 6.109 ms 5.346 ms > >>>>>> 4 tky001lip20.iij.net (210.149.34.97) 6.410 ms 7.471 ms > 7.934 > >>>>>> ms > >>>>>> 5 tky001bb10.iij.net (58.138.100.209) 6.670 ms 9.251 ms > 5.866 > >>>>>> ms > >>>>>> 6 tky009bf00.iij.net (58.138.80.17) 6.730 ms > >>>>>> tky008bf02.iij.net (58.138.80.13) 7.021 ms > >>>>>> tky009bf00.iij.net (58.138.80.17) 8.593 ms > >>>>>> 7 tky001ix05.iij.net (58.138.82.2) 9.767 ms > >>>>>> tky001ix05.iij.net (58.138.82.6) 6.101 ms > >>>>>> tky001ix01.iij.net (58.138.80.106) 8.420 ms > >>>>>> 8 203.181.102.61 (203.181.102.61) 19.514 ms > >>>>>> 203.181.102.21 (203.181.102.21) 6.054 ms > >>>>>> 203.181.102.61 (203.181.102.61) 11.478 ms > >>>>>> 9 otejbb203.kddnet.ad.jp (118.155.197.129) 7.457 ms > >>>>>> otejbb203.kddnet.ad.jp (59.128.7.129) 7.835 ms > >>>>>> otejbb204.kddnet.ad.jp (59.128.7.130) 7.824 ms > >>>>>> 10 cm-fcu203.kddnet.ad.jp (124.215.194.180) 15.860 ms 16.401 > ms > >>>>>> cm-fcu203.kddnet.ad.jp (124.215.194.164) 17.519 ms > >>>>>> 11 124.215.199.122 (124.215.199.122) 7.892 ms * 11.984 ms > >>>>>> > > > > From tknchris at gmail.com Mon Dec 12 08:57:29 2011 From: tknchris at gmail.com (chris) Date: Mon, 12 Dec 2011 09:57:29 -0500 Subject: Verizon 3G/4G Mobile Internet Sales Contact? Message-ID: Hello, If anyone has any contact info for the correct department within Verizon which handles getting a mobile internet service via 3G/4G, that would be a huge help. I am trying to avoid the usual Verizon runaround of being transferred from dept to dept because no one has any idea what I'm talking about. I also would preferably like a static IP if possible. Tried contacting Verizon Wireless and they are trying to sell me a MiFi and have no idea what a static IP is :) Thanks, chris From paul4004 at gmail.com Mon Dec 12 09:10:28 2011 From: paul4004 at gmail.com (PC) Date: Mon, 12 Dec 2011 10:10:28 -0500 Subject: Verizon 3G/4G Mobile Internet Sales Contact? In-Reply-To: References: Message-ID: >From my experience: IPV4 Static IPs nor private IP service are currently available on the 4g service (I asked). Even the routable IPV6 Static IPs can not receive remote traffic (at least they failed to get ESP traffic when I tried to build a VPN with them because the ipv4 address provided was carrier-grade natted). This, they seem too clueless to provide any further input on after many attempts (they don't know IPV6) even after calling Tier 2 support from a customer account with 2,000+ telemetry data lines. Their IPV6 clue is very low. The reps cared, they just couldn't find anyone who knew the product and gave up. For the IPV4 3g, the tech support should be able to sell you one, but it has a $500 setup fee or something similarly absurd, making it very uneconomical for a single unit. On Mon, Dec 12, 2011 at 9:57 AM, chris wrote: > Hello, > > If anyone has any contact info for the correct department within Verizon > which handles getting a mobile internet service via 3G/4G, that would be a > huge help. I am trying to avoid the usual Verizon runaround of being > transferred from dept to dept because no one has any idea what I'm talking > about. I also would preferably like a static IP if possible. Tried > contacting Verizon Wireless and they are trying to sell me a MiFi and have > no idea what a static IP is :) > > Thanks, > chris > From tknchris at gmail.com Mon Dec 12 09:43:40 2011 From: tknchris at gmail.com (chris) Date: Mon, 12 Dec 2011 10:43:40 -0500 Subject: Verizon 3G/4G Mobile Internet Sales Contact? In-Reply-To: References: Message-ID: On that note, any other carriers who do have static IP offerings at a reasonable price? Just looking for OOB really, unlimited data would be nice too so it doesnt have to be worried about On Mon, Dec 12, 2011 at 10:10 AM, PC wrote: > From my experience: > > IPV4 Static IPs nor private IP service are currently available on the 4g > service (I asked). > > Even the routable IPV6 Static IPs can not receive remote traffic (at least > they failed to get ESP traffic when I tried to build a VPN with them > because the ipv4 address provided was carrier-grade natted). This, they > seem too clueless to provide any further input on after many attempts (they > don't know IPV6) even after calling Tier 2 support from a customer account > with 2,000+ telemetry data lines. Their IPV6 clue is very low. The reps > cared, they just couldn't find anyone who knew the product and gave up. > > For the IPV4 3g, the tech support should be able to sell you one, but it > has a $500 setup fee or something similarly absurd, making it very > uneconomical for a single unit. > > On Mon, Dec 12, 2011 at 9:57 AM, chris wrote: > >> Hello, >> >> If anyone has any contact info for the correct department within Verizon >> which handles getting a mobile internet service via 3G/4G, that would be a >> huge help. I am trying to avoid the usual Verizon runaround of being >> transferred from dept to dept because no one has any idea what I'm talking >> about. I also would preferably like a static IP if possible. Tried >> contacting Verizon Wireless and they are trying to sell me a MiFi and have >> no idea what a static IP is :) >> >> Thanks, >> chris >> > > From rfinnesey at gmail.com Mon Dec 12 09:46:16 2011 From: rfinnesey at gmail.com (Ryan Finnesey) Date: Mon, 12 Dec 2011 10:46:16 -0500 Subject: Verizon 3G/4G Mobile Internet Sales Contact? In-Reply-To: References: Message-ID: I am using what is called Verizon Private Network on 4G witch gives me private Static IPs. Cheers Ryan -----Original Message----- From: PC [mailto:paul4004 at gmail.com] Sent: Monday, December 12, 2011 10:10 AM To: chris Cc: NANOG list Subject: Re: Verizon 3G/4G Mobile Internet Sales Contact? >From my experience: IPV4 Static IPs nor private IP service are currently available on the 4g service (I asked). Even the routable IPV6 Static IPs can not receive remote traffic (at least they failed to get ESP traffic when I tried to build a VPN with them because the ipv4 address provided was carrier-grade natted). This, they seem too clueless to provide any further input on after many attempts (they don't know IPV6) even after calling Tier 2 support from a customer account with 2,000+ telemetry data lines. Their IPV6 clue is very low. The reps cared, they just couldn't find anyone who knew the product and gave up. For the IPV4 3g, the tech support should be able to sell you one, but it has a $500 setup fee or something similarly absurd, making it very uneconomical for a single unit. On Mon, Dec 12, 2011 at 9:57 AM, chris wrote: > Hello, > > If anyone has any contact info for the correct department within > Verizon which handles getting a mobile internet service via 3G/4G, > that would be a huge help. I am trying to avoid the usual Verizon > runaround of being transferred from dept to dept because no one has > any idea what I'm talking about. I also would preferably like a static > IP if possible. Tried contacting Verizon Wireless and they are trying > to sell me a MiFi and have no idea what a static IP is :) > > Thanks, > chris > From rfinnesey at gmail.com Mon Dec 12 09:50:13 2011 From: rfinnesey at gmail.com (Ryan Finnesey) Date: Mon, 12 Dec 2011 10:50:13 -0500 Subject: Verizon 3G/4G Mobile Internet Sales Contact? In-Reply-To: References: Message-ID: Both At&T and Sprint have a static offering as well. Cheers Ryan -----Original Message----- From: chris [mailto:tknchris at gmail.com] Sent: Monday, December 12, 2011 10:44 AM To: PC Cc: NANOG list Subject: Re: Verizon 3G/4G Mobile Internet Sales Contact? On that note, any other carriers who do have static IP offerings at a reasonable price? Just looking for OOB really, unlimited data would be nice too so it doesnt have to be worried about On Mon, Dec 12, 2011 at 10:10 AM, PC wrote: > From my experience: > > IPV4 Static IPs nor private IP service are currently available on the > 4g service (I asked). > > Even the routable IPV6 Static IPs can not receive remote traffic (at > least they failed to get ESP traffic when I tried to build a VPN with > them because the ipv4 address provided was carrier-grade natted). > This, they seem too clueless to provide any further input on after > many attempts (they don't know IPV6) even after calling Tier 2 support > from a customer account with 2,000+ telemetry data lines. Their IPV6 > clue is very low. The reps cared, they just couldn't find anyone who knew the product and gave up. > > For the IPV4 3g, the tech support should be able to sell you one, but > it has a $500 setup fee or something similarly absurd, making it very > uneconomical for a single unit. > > On Mon, Dec 12, 2011 at 9:57 AM, chris wrote: > >> Hello, >> >> If anyone has any contact info for the correct department within >> Verizon which handles getting a mobile internet service via 3G/4G, >> that would be a huge help. I am trying to avoid the usual Verizon >> runaround of being transferred from dept to dept because no one has >> any idea what I'm talking about. I also would preferably like a >> static IP if possible. Tried contacting Verizon Wireless and they are >> trying to sell me a MiFi and have no idea what a static IP is :) >> >> Thanks, >> chris >> > > From brandon.kim at brandontek.com Mon Dec 12 10:02:25 2011 From: brandon.kim at brandontek.com (Brandon Kim) Date: Mon, 12 Dec 2011 11:02:25 -0500 Subject: Inaccessible network from Verizon, accessible elsewhere. In-Reply-To: <483E6B0272B0284BA86D7596C40D29F901212A80D599@PUR-EXCH07.ox.com> References: , , <4ee532c6.8908e70a.5582.ffff8e19@mx.google.com>, , , , , <0876509C-A9C4-4060-B0B1-4C46B0CBB478@ox.com>, , <4EE59EA1.6070400@webjogger.net>, <483E6B0272B0284BA86D7596C40D29F901212A80D599@PUR-EXCH07.ox.com> Message-ID: Yes I am in Rockland. I failed to mentioned that I was having issues with consumer FIOS. Is anyone with Verizon on this list? This morning www.cisco.com and www.nfl.com works now. They didn't last night. There are still some websites that won't load or slow to load.... > From: mhuff at ox.com > To: maillist at webjogger.net; nanog at nanog.org > Date: Mon, 12 Dec 2011 08:44:56 -0500 > Subject: RE: Inaccessible network from Verizon, accessible elsewhere. > > DSLReports Verizon forum reports routing issues in Westchester, Rockland and Nassau. I tried a few traceroutes this morning. Some went through fine, others died at the first hop within Verizon. > > People are reporting mixed results calling Verizon. Some techs are saying it's a known issues, others are going through the standard script (reboot router, reboot ONT, check settings on browser, i.e. clueless, even to the point of saying that the person's router is bad and they would send them a new one). > > > > ---- > Matthew Huff | 1 Manhattanville Rd > Director of Operations | Purchase, NY 10577 > OTA Management LLC | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-460-4139 > > > -----Original Message----- > > From: Adam Greene [mailto:maillist at webjogger.net] > > Sent: Monday, December 12, 2011 1:27 AM > > To: nanog at nanog.org > > Subject: Re: Inaccessible network from Verizon, accessible elsewhere. > > > > We're having strange issues in NYC metropolitan area. > > > > We can trace from Verizon FIOS to some IP addresses of our ASN 11579 > > block. Others don't work. The IP's that don't work seem to die at > > 130.81.107.228 on the Verizon network. > > > > Something is rotten in Denmark. Or NY. You know what I mean. > > > > On 12/12/2011 1:02 AM, Christopher Morrow wrote: > > > On Sun, Dec 11, 2011 at 10:54 PM, Matthew Huff wrote: > > >> Consumer fios. Verizon forums are full of posts about it. Too tired > > this evening to worry about it. > > > :( I'll have to do some testing when I get near a consumer fios > > > then... So, they squash all DNS NOT to their complexes, that seems > > > rather dastardly of them... considering they deployed that hateful > > > paxfire/nominum garbage on their recursive servers :( > > > > > > -chris > > > > > >> On Dec 11, 2011, at 10:48 PM, "Christopher > > Morrow" wrote: > > >> > > >>> On Sun, Dec 11, 2011 at 10:28 PM, Matthew Huff > > wrote: > > >>>> I'm seeing the same thing from my home lan via fios. I've run a > > recursive dns server for years and can't reach the roots. Had to switch > > to using verizon's dns servers as forwarders. > > >>>> > > >>> business or consumer fios? > > >>> 3 G0-9-4-7.WASHDC-LCR-22.verizon-gni.net (130.81.104.180) 6.662 > > ms > > >>> 6.739 ms 6.788 ms > > >>> 4 so-14-0-0-0.RES-BB-RTR2.verizon-gni.net (130.81.22.56) 6.852 ms > > >>> 15.384 ms 8.184 ms > > >>> 5 0.ae2.BR1.IAD8.ALTER.NET (152.63.32.158) 12.857 ms 12.927 ms > > >>> 13.004 ms > > >>> 6 dcp-brdr-03.inet.qwest.net (63.146.26.105) 12.429 ms 7.847 ms > > >>> 6.464 ms > > >>> 7 lap-brdr-03.inet.qwest.net (67.14.22.78) 89.140 ms 88.929 ms > > >>> 89.032 ms > > >>> 8 63.146.26.70 (63.146.26.70) 94.879 ms 94.580 ms 93.120 ms > > >>> 9 sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112) 58.520 ms > > >>> 58.330 ms 58.186 ms > > >>> 10 144.232.25.193 (144.232.25.193) 49.950 ms > > >>> sl-crs1-oma-0-9-2-0.sprintlink.net (144.232.2.177) 49.962 ms > > >>> sl-crs1-oma-0-8-0-0.sprintlink.net (144.232.8.171) 47.687 ms > > >>> 11 sl-crs1-oro-0-3-3-0.sprintlink.net (144.232.25.207) 84.416 ms > > >>> 83.266 ms sl-crs1-oro-0-12-3-0.sprintlink.net (144.232.25.73) > > >>> 84.667 ms > > >>> 12 124.215.199.122 (124.215.199.122) 195.590 ms * * > > >>> > > >>> all of this seems to point at some kddi.net rouer gobbling packets, > > >>> no? (since pretty much everyone's got the same terminating hop) - > > >>> also note that while some folks traverse L3, my route is via > > qwest... > > >>> > > >>> it's interesting that 701 isn't picking their other peer (sprint) > > >>> here directly, no? > > >>> > > >>>> Sent from my iPad > > >>>> > > >>>> On Dec 11, 2011, at 8:07 PM, "Brandon > > Kim" wrote: > > >>>> > > >>>>> I too am now experiencing issues. I cannot get to www.cisco.com > > and various websites. > > >>>>> Some websites work lightning quick, some take a long time to > > load, and some just don't load at all..... > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>>> Date: Mon, 12 Dec 2011 09:55:40 +0900 > > >>>>>> From: randy at psg.com > > >>>>>> To: nanog at nanog.org > > >>>>>> Subject: Re: Inaccessible network from Verizon, accessible > > elsewhere. > > >>>>>> > > >>>>>> from home lan > > >>>>>> > > >>>>>> % traceroute gw-li377.linode.com > > >>>>>> traceroute to gw-li377.linode.com (106.187.34.1), 64 hops max, > > 52 > > >>>>>> byte packets > > >>>>>> 1 192.168.0.1 (192.168.0.1) 1.471 ms 0.725 ms 0.555 ms > > >>>>>> 2 tokyo10-f03.flets.2iij.net (210.149.34.72) 7.241 ms 6.651 > > ms > > >>>>>> 6.939 ms > > >>>>>> 3 tokyo10-ntteast0.flets.2iij.net (210.149.34.157) 5.573 ms > > >>>>>> 6.109 ms 5.346 ms > > >>>>>> 4 tky001lip20.iij.net (210.149.34.97) 6.410 ms 7.471 ms > > 7.934 > > >>>>>> ms > > >>>>>> 5 tky001bb10.iij.net (58.138.100.209) 6.670 ms 9.251 ms > > 5.866 > > >>>>>> ms > > >>>>>> 6 tky009bf00.iij.net (58.138.80.17) 6.730 ms > > >>>>>> tky008bf02.iij.net (58.138.80.13) 7.021 ms > > >>>>>> tky009bf00.iij.net (58.138.80.17) 8.593 ms > > >>>>>> 7 tky001ix05.iij.net (58.138.82.2) 9.767 ms > > >>>>>> tky001ix05.iij.net (58.138.82.6) 6.101 ms > > >>>>>> tky001ix01.iij.net (58.138.80.106) 8.420 ms > > >>>>>> 8 203.181.102.61 (203.181.102.61) 19.514 ms > > >>>>>> 203.181.102.21 (203.181.102.21) 6.054 ms > > >>>>>> 203.181.102.61 (203.181.102.61) 11.478 ms > > >>>>>> 9 otejbb203.kddnet.ad.jp (118.155.197.129) 7.457 ms > > >>>>>> otejbb203.kddnet.ad.jp (59.128.7.129) 7.835 ms > > >>>>>> otejbb204.kddnet.ad.jp (59.128.7.130) 7.824 ms > > >>>>>> 10 cm-fcu203.kddnet.ad.jp (124.215.194.180) 15.860 ms 16.401 > > ms > > >>>>>> cm-fcu203.kddnet.ad.jp (124.215.194.164) 17.519 ms > > >>>>>> 11 124.215.199.122 (124.215.199.122) 7.892 ms * 11.984 ms > > >>>>>> > > > > > > > > From esavage at digitalrage.org Mon Dec 12 10:21:36 2011 From: esavage at digitalrage.org (Elijah Savage) Date: Mon, 12 Dec 2011 11:21:36 -0500 (EST) Subject: Verizon 3G/4G Mobile Internet Sales Contact? In-Reply-To: Message-ID: <30150212.374.1323706896147.JavaMail.root@ubuntu.digitalrage.org> I am using what you are looking for today with VPN connectivity and it has been discussed on this list previously. There are some things you should be aware of with static ip. Contact me offline and I may be able to put you in contact with someone. ----- Original Message ----- From: "Ryan Finnesey" To: "chris" , "PC" Cc: "NANOG list" Sent: Monday, December 12, 2011 10:50:13 AM Subject: RE: Verizon 3G/4G Mobile Internet Sales Contact? Both At&T and Sprint have a static offering as well. Cheers Ryan -----Original Message----- From: chris [mailto:tknchris at gmail.com] Sent: Monday, December 12, 2011 10:44 AM To: PC Cc: NANOG list Subject: Re: Verizon 3G/4G Mobile Internet Sales Contact? On that note, any other carriers who do have static IP offerings at a reasonable price? Just looking for OOB really, unlimited data would be nice too so it doesnt have to be worried about On Mon, Dec 12, 2011 at 10:10 AM, PC wrote: > From my experience: > > IPV4 Static IPs nor private IP service are currently available on the > 4g service (I asked). > > Even the routable IPV6 Static IPs can not receive remote traffic (at > least they failed to get ESP traffic when I tried to build a VPN with > them because the ipv4 address provided was carrier-grade natted). > This, they seem too clueless to provide any further input on after > many attempts (they don't know IPV6) even after calling Tier 2 support > from a customer account with 2,000+ telemetry data lines. Their IPV6 > clue is very low. The reps cared, they just couldn't find anyone who knew the product and gave up. > > For the IPV4 3g, the tech support should be able to sell you one, but > it has a $500 setup fee or something similarly absurd, making it very > uneconomical for a single unit. > > On Mon, Dec 12, 2011 at 9:57 AM, chris wrote: > >> Hello, >> >> If anyone has any contact info for the correct department within >> Verizon which handles getting a mobile internet service via 3G/4G, >> that would be a huge help. I am trying to avoid the usual Verizon >> runaround of being transferred from dept to dept because no one has >> any idea what I'm talking about. I also would preferably like a >> static IP if possible. Tried contacting Verizon Wireless and they are >> trying to sell me a MiFi and have no idea what a static IP is :) >> >> Thanks, >> chris >> > > From wayne at dpctech.com Mon Dec 12 10:24:38 2011 From: wayne at dpctech.com (Wayne ) Date: Mon, 12 Dec 2011 11:24:38 -0500 Subject: Inaccessible network from Verizon, accessible elsewhere. In-Reply-To: References: , , <4ee532c6.8908e70a.5582.ffff8e19@mx.google.com>, , , , , <0876509C-A9C4-4060-B0B1-4C46B0CBB478@ox.com>, , <4EE59EA1.6070400@webjogger.net>, <483E6B0272B0284BA86D7596C40D29F901212A80D599@PUR-EXCH07.ox.com> Message-ID: <009501ccb8ea$8f1a5f30$ad4f1d90$@dpctech.com> Yes www.speedtest.net & www.gotomypc are also inaccessible or very slow along with many other sites. Experiencing these problems in Nassau and Westchester County on consumer fios. -----Original Message----- From: Brandon Kim [mailto:brandon.kim at brandontek.com] Sent: Monday, December 12, 2011 11:02 AM To: nanog group Subject: RE: Inaccessible network from Verizon, accessible elsewhere. Yes I am in Rockland. I failed to mentioned that I was having issues with consumer FIOS. Is anyone with Verizon on this list? This morning www.cisco.com and www.nfl.com works now. They didn't last night. There are still some websites that won't load or slow to load.... > From: mhuff at ox.com > To: maillist at webjogger.net; nanog at nanog.org > Date: Mon, 12 Dec 2011 08:44:56 -0500 > Subject: RE: Inaccessible network from Verizon, accessible elsewhere. > > DSLReports Verizon forum reports routing issues in Westchester, Rockland and Nassau. I tried a few traceroutes this morning. Some went through fine, others died at the first hop within Verizon. > > People are reporting mixed results calling Verizon. Some techs are saying it's a known issues, others are going through the standard script (reboot router, reboot ONT, check settings on browser, i.e. clueless, even to the point of saying that the person's router is bad and they would send them a new one). > > > > ---- > Matthew Huff | 1 Manhattanville Rd > Director of Operations | Purchase, NY 10577 > OTA Management LLC | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-460-4139 > > > -----Original Message----- > > From: Adam Greene [mailto:maillist at webjogger.net] > > Sent: Monday, December 12, 2011 1:27 AM > > To: nanog at nanog.org > > Subject: Re: Inaccessible network from Verizon, accessible elsewhere. > > > > We're having strange issues in NYC metropolitan area. > > > > We can trace from Verizon FIOS to some IP addresses of our ASN 11579 > > block. Others don't work. The IP's that don't work seem to die at > > 130.81.107.228 on the Verizon network. > > > > Something is rotten in Denmark. Or NY. You know what I mean. > > > > On 12/12/2011 1:02 AM, Christopher Morrow wrote: > > > On Sun, Dec 11, 2011 at 10:54 PM, Matthew Huff wrote: > > >> Consumer fios. Verizon forums are full of posts about it. Too > > >> tired > > this evening to worry about it. > > > :( I'll have to do some testing when I get near a consumer fios > > > then... So, they squash all DNS NOT to their complexes, that seems > > > rather dastardly of them... considering they deployed that hateful > > > paxfire/nominum garbage on their recursive servers :( > > > > > > -chris > > > > > >> On Dec 11, 2011, at 10:48 PM, "Christopher > > Morrow" wrote: > > >> > > >>> On Sun, Dec 11, 2011 at 10:28 PM, Matthew Huff > > wrote: > > >>>> I'm seeing the same thing from my home lan via fios. I've run a > > recursive dns server for years and can't reach the roots. Had to > > switch to using verizon's dns servers as forwarders. > > >>>> > > >>> business or consumer fios? > > >>> 3 G0-9-4-7.WASHDC-LCR-22.verizon-gni.net (130.81.104.180) > > >>> 6.662 > > ms > > >>> 6.739 ms 6.788 ms > > >>> 4 so-14-0-0-0.RES-BB-RTR2.verizon-gni.net (130.81.22.56) 6.852 > > >>> ms > > >>> 15.384 ms 8.184 ms > > >>> 5 0.ae2.BR1.IAD8.ALTER.NET (152.63.32.158) 12.857 ms 12.927 > > >>> ms > > >>> 13.004 ms > > >>> 6 dcp-brdr-03.inet.qwest.net (63.146.26.105) 12.429 ms 7.847 > > >>> ms > > >>> 6.464 ms > > >>> 7 lap-brdr-03.inet.qwest.net (67.14.22.78) 89.140 ms 88.929 > > >>> ms > > >>> 89.032 ms > > >>> 8 63.146.26.70 (63.146.26.70) 94.879 ms 94.580 ms 93.120 ms > > >>> 9 sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112) 58.520 ms > > >>> 58.330 ms 58.186 ms > > >>> 10 144.232.25.193 (144.232.25.193) 49.950 ms > > >>> sl-crs1-oma-0-9-2-0.sprintlink.net (144.232.2.177) 49.962 ms > > >>> sl-crs1-oma-0-8-0-0.sprintlink.net (144.232.8.171) 47.687 ms > > >>> 11 sl-crs1-oro-0-3-3-0.sprintlink.net (144.232.25.207) 84.416 > > >>> ms > > >>> 83.266 ms sl-crs1-oro-0-12-3-0.sprintlink.net (144.232.25.73) > > >>> 84.667 ms > > >>> 12 124.215.199.122 (124.215.199.122) 195.590 ms * * > > >>> > > >>> all of this seems to point at some kddi.net rouer gobbling > > >>> packets, no? (since pretty much everyone's got the same > > >>> terminating hop) - also note that while some folks traverse L3, > > >>> my route is via > > qwest... > > >>> > > >>> it's interesting that 701 isn't picking their other peer > > >>> (sprint) here directly, no? > > >>> > > >>>> Sent from my iPad > > >>>> > > >>>> On Dec 11, 2011, at 8:07 PM, "Brandon > > Kim" wrote: > > >>>> > > >>>>> I too am now experiencing issues. I cannot get to > > >>>>> www.cisco.com > > and various websites. > > >>>>> Some websites work lightning quick, some take a long time to > > load, and some just don't load at all..... > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>>> Date: Mon, 12 Dec 2011 09:55:40 +0900 > > >>>>>> From: randy at psg.com > > >>>>>> To: nanog at nanog.org > > >>>>>> Subject: Re: Inaccessible network from Verizon, accessible > > elsewhere. > > >>>>>> > > >>>>>> from home lan > > >>>>>> > > >>>>>> % traceroute gw-li377.linode.com traceroute to > > >>>>>> gw-li377.linode.com (106.187.34.1), 64 hops max, > > 52 > > >>>>>> byte packets > > >>>>>> 1 192.168.0.1 (192.168.0.1) 1.471 ms 0.725 ms 0.555 ms > > >>>>>> 2 tokyo10-f03.flets.2iij.net (210.149.34.72) 7.241 ms > > >>>>>> 6.651 > > ms > > >>>>>> 6.939 ms > > >>>>>> 3 tokyo10-ntteast0.flets.2iij.net (210.149.34.157) 5.573 ms > > >>>>>> 6.109 ms 5.346 ms > > >>>>>> 4 tky001lip20.iij.net (210.149.34.97) 6.410 ms 7.471 ms > > 7.934 > > >>>>>> ms > > >>>>>> 5 tky001bb10.iij.net (58.138.100.209) 6.670 ms 9.251 ms > > 5.866 > > >>>>>> ms > > >>>>>> 6 tky009bf00.iij.net (58.138.80.17) 6.730 ms > > >>>>>> tky008bf02.iij.net (58.138.80.13) 7.021 ms > > >>>>>> tky009bf00.iij.net (58.138.80.17) 8.593 ms > > >>>>>> 7 tky001ix05.iij.net (58.138.82.2) 9.767 ms > > >>>>>> tky001ix05.iij.net (58.138.82.6) 6.101 ms > > >>>>>> tky001ix01.iij.net (58.138.80.106) 8.420 ms > > >>>>>> 8 203.181.102.61 (203.181.102.61) 19.514 ms > > >>>>>> 203.181.102.21 (203.181.102.21) 6.054 ms > > >>>>>> 203.181.102.61 (203.181.102.61) 11.478 ms > > >>>>>> 9 otejbb203.kddnet.ad.jp (118.155.197.129) 7.457 ms > > >>>>>> otejbb203.kddnet.ad.jp (59.128.7.129) 7.835 ms > > >>>>>> otejbb204.kddnet.ad.jp (59.128.7.130) 7.824 ms > > >>>>>> 10 cm-fcu203.kddnet.ad.jp (124.215.194.180) 15.860 ms > > >>>>>> 16.401 > > ms > > >>>>>> cm-fcu203.kddnet.ad.jp (124.215.194.164) 17.519 ms > > >>>>>> 11 124.215.199.122 (124.215.199.122) 7.892 ms * 11.984 ms > > >>>>>> > > > > > > > > From tknchris at gmail.com Mon Dec 12 11:03:01 2011 From: tknchris at gmail.com (chris) Date: Mon, 12 Dec 2011 12:03:01 -0500 Subject: Verizon 3G/4G Mobile Internet Sales Contact? In-Reply-To: References: Message-ID: Hello, Someone contacted me offlist and got me direct contact info to someone at VZ who know exactly what I was looking for and was very helpful. And the pricing is quite fair :) Thanks to everyone who sent me info. chris On Mon, Dec 12, 2011 at 10:10 AM, PC wrote: > From my experience: > > IPV4 Static IPs nor private IP service are currently available on the 4g > service (I asked). > > Even the routable IPV6 Static IPs can not receive remote traffic (at least > they failed to get ESP traffic when I tried to build a VPN with them > because the ipv4 address provided was carrier-grade natted). This, they > seem too clueless to provide any further input on after many attempts (they > don't know IPV6) even after calling Tier 2 support from a customer account > with 2,000+ telemetry data lines. Their IPV6 clue is very low. The reps > cared, they just couldn't find anyone who knew the product and gave up. > > For the IPV4 3g, the tech support should be able to sell you one, but it > has a $500 setup fee or something similarly absurd, making it very > uneconomical for a single unit. > > On Mon, Dec 12, 2011 at 9:57 AM, chris wrote: > >> Hello, >> >> If anyone has any contact info for the correct department within Verizon >> which handles getting a mobile internet service via 3G/4G, that would be a >> huge help. I am trying to avoid the usual Verizon runaround of being >> transferred from dept to dept because no one has any idea what I'm talking >> about. I also would preferably like a static IP if possible. Tried >> contacting Verizon Wireless and they are trying to sell me a MiFi and have >> no idea what a static IP is :) >> >> Thanks, >> chris >> > > From brandon.kim at brandontek.com Mon Dec 12 11:48:13 2011 From: brandon.kim at brandontek.com (Brandon Kim) Date: Mon, 12 Dec 2011 12:48:13 -0500 Subject: Verizon 3G/4G Mobile Internet Sales Contact? In-Reply-To: References: , , Message-ID: How much was the pricing and is it unlimited BW? I may be interested too depending on costs.... > Date: Mon, 12 Dec 2011 12:03:01 -0500 > Subject: Re: Verizon 3G/4G Mobile Internet Sales Contact? > From: tknchris at gmail.com > To: paul4004 at gmail.com > CC: nanog at nanog.org > > Hello, > > Someone contacted me offlist and got me direct contact info to someone at > VZ who know exactly what I was looking for and was very helpful. And the > pricing is quite fair :) > > Thanks to everyone who sent me info. > chris > > On Mon, Dec 12, 2011 at 10:10 AM, PC wrote: > > > From my experience: > > > > IPV4 Static IPs nor private IP service are currently available on the 4g > > service (I asked). > > > > Even the routable IPV6 Static IPs can not receive remote traffic (at least > > they failed to get ESP traffic when I tried to build a VPN with them > > because the ipv4 address provided was carrier-grade natted). This, they > > seem too clueless to provide any further input on after many attempts (they > > don't know IPV6) even after calling Tier 2 support from a customer account > > with 2,000+ telemetry data lines. Their IPV6 clue is very low. The reps > > cared, they just couldn't find anyone who knew the product and gave up. > > > > For the IPV4 3g, the tech support should be able to sell you one, but it > > has a $500 setup fee or something similarly absurd, making it very > > uneconomical for a single unit. > > > > On Mon, Dec 12, 2011 at 9:57 AM, chris wrote: > > > >> Hello, > >> > >> If anyone has any contact info for the correct department within Verizon > >> which handles getting a mobile internet service via 3G/4G, that would be a > >> huge help. I am trying to avoid the usual Verizon runaround of being > >> transferred from dept to dept because no one has any idea what I'm talking > >> about. I also would preferably like a static IP if possible. Tried > >> contacting Verizon Wireless and they are trying to sell me a MiFi and have > >> no idea what a static IP is :) > >> > >> Thanks, > >> chris > >> > > > > From cody at killsudo.info Mon Dec 12 12:07:51 2011 From: cody at killsudo.info (cody at killsudo.info) Date: Mon, 12 Dec 2011 12:07:51 -0600 Subject: Verizon[AS 19262] connectivity issues to AS7393 Message-ID: <0ec31061ff459f583f63d4b92d305289.squirrel@killsudo.info> We have a client that is complaining of connectivity issues and his trace-routes are stopping inside Verizon's network. 1 <1 ms <1 ms <1 ms Wireless_Broadband_Router.home [192.168.1.1] 2 5 ms 4 ms 4 ms L100.NYCMNY-VFTTP-151.verizon-gni.net [98.116.13 4.1] 3 8 ms 7 ms 7 ms G11-0-0-1251.NYCMNY-LCR-12.verizon-gni.net [130. 81.139.32] 4 * * * Request timed out. 5 * * * Request timed out. We have no issues reaching 98.116.134.1 from any of our providers. I asked the client to contact Verizon and Verizon tech's are responding that the issue is not Verizon. Any chance someone from Verizon could contact me so we can find the real problem? Thanks Cody From cody at killsudo.info Mon Dec 12 12:34:22 2011 From: cody at killsudo.info (cody at killsudo.info) Date: Mon, 12 Dec 2011 12:34:22 -0600 Subject: Verizon[AS 19262] connectivity issues to AS7393 In-Reply-To: <483E6B0272B0284BA86D7596C40D29F901212A80D5A0@PUR-EXCH07.ox.com> References: <0ec31061ff459f583f63d4b92d305289.squirrel@killsudo.info> <483E6B0272B0284BA86D7596C40D29F901212A80D5A0@PUR-EXCH07.ox.com> Message-ID: The client just contacted us again to say that their issue has been resolved. We are still waiting on a updated trace-route to see what has changed. Regards Cody > Not from Verizon, but Verizon's been having routing problems all weekend, > getting much worse yesterday. The nexus may be in the Verizon / Level 3 > handoff, but it may be changing as Verizon routes around the issues. > > > ---- > Matthew Huff? | 1 Manhattanville Rd > Director of Operations???| Purchase, NY 10577 > OTA Management LLC | Phone: 914-460-4039 > aim: matthewbhuff? | Fax:?? 914-460-4139 > > >> -----Original Message----- >> From: cody at killsudo.info [mailto:cody at killsudo.info] >> Sent: Monday, December 12, 2011 1:08 PM >> To: nanog at nanog.org >> Subject: Verizon[AS 19262] connectivity issues to AS7393 >> >> We have a client that is complaining of connectivity issues and his >> trace-routes are stopping inside Verizon's network. >> >> 1 <1 ms <1 ms <1 ms Wireless_Broadband_Router.home [192.168.1.1] >> 2 5 ms 4 ms 4 ms L100.NYCMNY-VFTTP-151.verizon-gni.net [98.116.13 4.1] >> 3 8 ms 7 ms 7 ms G11-0-0-1251.NYCMNY-LCR-12.verizon-gni.net [130. >> 81.139.32] >> 4 * * * Request timed out. >> 5 * * * Request timed out. >> >> We have no issues reaching 98.116.134.1 from any of our providers. I >> asked the client to contact Verizon and Verizon tech's are responding >> that the issue is not Verizon. >> >> Any chance someone from Verizon could contact me so we can find the >> real problem? >> >> Thanks >> >> Cody >> > > From eesslinger at fpu-tn.com Mon Dec 12 13:10:54 2011 From: eesslinger at fpu-tn.com (Eric J Esslinger) Date: Mon, 12 Dec 2011 13:10:54 -0600 Subject: recommendations for external montioring services? Message-ID: I'm not looking to monitor a massive infrastructure: 3 web sites, 2 mail servers (pop,imap,submission port, https webmail), 4 dns servers (including lookups to ensure they're not listening but not talking), and one inbound mx. A few network points to ping to ensure connectivity throughout my system. Scheduled notification windows (for example, during work hours I don't want my phone pinged unless it's everything going offline. Off hours I do. Secondary notifications if problem persists to other users, or in the event of many triggers. That sort of thing). Sensitivity settings (If web server 1 shows down for 5 min, that's not a big deal. Another one if it doesn't respond to repeated queries within 1 minute is a big deal) A Weekly summary of issues would be nice. (especially the 'well it was down for a short bit but we didn't notify as per settings') I don't have a lot of money to throw at this. I DO have detailed internal monitoring of our systems but sometimes that is not entirely useful, due to the fact that there are a few 'single points of failure' within our network/notification system, not to mention if the monitor itself goes offline it's not exactly going to be able to tell me about it. (and that happened once, right before the mail server decided to stop receiving mail). __________________________ Eric Esslinger Information Services Manager - Fayetteville Public Utilities http://www.fpu-tn.com/ (931)433-1522 ext 165 This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. From edward.dore at freethought-internet.co.uk Mon Dec 12 13:18:07 2011 From: edward.dore at freethought-internet.co.uk (Edward Dore) Date: Mon, 12 Dec 2011 19:18:07 +0000 Subject: recommendations for external montioring services? In-Reply-To: References: Message-ID: <8963FB5F-E5AF-4967-A220-CD6420C7E729@freethought-internet.co.uk> Take a look at Panopta - we use it to compliment our internal monitoring and find it great compared to some of the systems we've used in the past (Pingdom, Binary Canary). The interface is easy to use and responsive, we don't get false positives and there are a good range of checks. There's an API as well if you want to integrate it. I'd stay clear of the software agent though, we've had a few issues with that. For remote service checks we love it. Edward Dore Freethought Internet On 12 Dec 2011, at 19:10, Eric J Esslinger wrote: > I'm not looking to monitor a massive infrastructure: 3 web sites, 2 mail servers (pop,imap,submission port, https webmail), 4 dns servers (including lookups to ensure they're not listening but not talking), and one inbound mx. A few network points to ping to ensure connectivity throughout my system. Scheduled notification windows (for example, during work hours I don't want my phone pinged unless it's everything going offline. Off hours I do. Secondary notifications if problem persists to other users, or in the event of many triggers. That sort of thing). Sensitivity settings (If web server 1 shows down for 5 min, that's not a big deal. Another one if it doesn't respond to repeated queries within 1 minute is a big deal) A Weekly summary of issues would be nice. (especially the 'well it was down for a short bit but we didn't notify as per settings') > I don't have a lot of money to throw at this. I DO have detailed internal monitoring of our systems but sometimes that is not entirely useful, due to the fact that there are a few 'single points of failure' within our network/notification system, not to mention if the monitor itself goes offline it's not exactly going to be able to tell me about it. (and that happened once, right before the mail server decided to stop receiving mail). > > __________________________ > Eric Esslinger > Information Services Manager - Fayetteville Public Utilities > http://www.fpu-tn.com/ > (931)433-1522 ext 165 > > This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. > From patrick at ianai.net Mon Dec 12 14:10:20 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 12 Dec 2011 15:10:20 -0500 Subject: Overall Netflix bandwidth usage numbers on a network? In-Reply-To: <4EE58E8E.8000804@bogus.com> References: <20111203004732.GH13315@hijacked.us> <20111203005847.GI13315@hijacked.us> <4EDF9AE9.9040700@ispn.net> <4EE54B01.6000305@temk.in> <4EE56198.40307@snappydsl.net> <387BECF4-7EF9-43E6-BEEE-AA42DF1EEE19@bogus.com> <5ECE9281-B6CB-4669-857D-07E10A7C499C@snappydsl.net> <4EE58E8E.8000804@bogus.com> Message-ID: <22941D59-BCE0-4DB4-BC9D-BB67CEC3233D@ianai.net> On Dec 12, 2011, at 12:18 AM, Joel jaeggli wrote: > On 12/11/11 19:49 , Christopher Morrow wrote: >> On Sun, Dec 11, 2011 at 10:46 PM, Faisal Imtiaz wrote: >>> Simple, keep traffic off paid ip transit circuits.... >>> >> (I think joel's point was: "peer with amazon, done-and-done") > > also probably your relationships to akamai and level3 Netflix's EC2 instances do not speak to end users AFAIK. I believe Akamai, LLNW, & L3 are the only companies that stream movies for Netflix. Peer with the CDNs to save your transit. Happy to be educated otherwise if someone knows more than I do. Netflix's client is also _very_ intelligent. If a user cannot get high enough quality from CDN_1, it will switch to CDN_2 without interrupting the stream. Which is nice if you have good connectivity to one but not the other CDN. (Note I spoke of "good", not "inexpensive" connectivity. The NF client doesn't know how much it costs you to show a video, only whether there is packet loss.) -- TTFN, patrick >>> Faisal >>> >>> On Dec 11, 2011, at 10:21 PM, Joel Jaeggli wrote: >>> >>>> Netflix uses CDNs for content delivery and the platform runs in EC2. What would peering with them achieve? >>>> >>>> Sent from my iPhone >>>> >>>> On Dec 11, 2011, at 18:06, Faisal Imtiaz wrote: >>>> >>>>> Which leads to a question to be asked... >>>>> >>>>> Is netflix willing to peer directly with ISP / NSP's ? >>>>> >>>>> Regards. >>>>> >>>>> Faisal Imtiaz >>>>> Snappy Internet& Telecom >>>>> >>>>> >>>>> On 12/11/2011 7:29 PM, Dave Temkin wrote: >>>>>> Feel free to contact peering at netflixcom - we're happy to provide you with delivery statistics for traffic terminating on your network. >>>>>> >>>>>> Regards, >>>>>> -Dave Temkin >>>>>> Netflix >>>>>> >>>>>> On 12/7/11 8:57 AM, Blake Hudson wrote: >>>>>>> Yeah, that's an interesting one. We currently utilize netflow for this, but you also need to consider that netflix streaming is just port 80 www traffic. Because netflix uses CDNs, its difficult to pin down the traffic to specific hosts in the CDN and say that this traffic was netflix, while this traffic was the latest windows update (remember this is often a shared hosting platform). We've done our own testing and have come to a good solution which uses a combination of nbar, packet marking, and netflow to come to a conclusion. On a ~160Mbps link, netflix peaks out between 30-50Mbps around 8-10PM each evening. The rest of the traffic is predominantly other forms of HTTP traffic (including other video streaming services). >>>>>>> >>>>>>> >>>>>>> Martin Hepworth wrote the following on 12/3/2011 2:36 AM: >>>>>>>> Also checkout Adrian Cockcroft presentations on their architecture which >>>>>>>> describes how they use aws and CDns etc >>>>>>>> >>>>>>>> Martin >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > > From ryan at u13.net Mon Dec 12 14:37:33 2011 From: ryan at u13.net (Ryan Rawdon) Date: Mon, 12 Dec 2011 15:37:33 -0500 Subject: recommendations for external montioring services? In-Reply-To: References: Message-ID: <32F5E894-B48D-4A79-A9D5-CEC85A9B2341@u13.net> On Dec 12, 2011, at 2:10 PM, Eric J Esslinger wrote: > I'm not looking to monitor a massive infrastructure: 3 web sites, 2 mail servers (pop,imap,submission port, https webmail), 4 dns servers (including lookups to ensure they're not listening but not talking), and one inbound mx. A few network points to ping to ensure connectivity throughout my system. Scheduled notification windows (for example, during work hours I don't want my phone pinged unless it's everything going offline. Off hours I do. Secondary notifications if problem persists to other users, or in the event of many triggers. That sort of thing). Sensitivity settings (If web server 1 shows down for 5 min, that's not a big deal. Another one if it doesn't respond to repeated queries within 1 minute is a big deal) A Weekly summary of issues would be nice. (especially the 'well it was down for a short bit but we didn't notify as per settings') > I don't have a lot of money to throw at this. I DO have detailed internal monitoring of our systems but sometimes that is not entirely useful, due to the fact that there are a few 'single points of failure' within our network/notification system, not to mention if the monitor itself goes offline it's not exactly going to be able to tell me about it. (and that happened once, right before the mail server decided to stop receiving mail). > I have been passively looking for external monitoring with similar requirements, though I'm curious about one more requirement if people chiming in can share it - whether or not said vendor supports IPv6 for both external service checks and potentially for agent communications as well. > __________________________ > Eric Esslinger > Information Services Manager - Fayetteville Public Utilities > http://www.fpu-tn.com/ > (931)433-1522 ext 165 > > This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. > From weaselkeeper at gmail.com Mon Dec 12 14:37:39 2011 From: weaselkeeper at gmail.com (Jim Richardson) Date: Mon, 12 Dec 2011 12:37:39 -0800 Subject: recommendations for external montioring services? In-Reply-To: <8963FB5F-E5AF-4967-A220-CD6420C7E729@freethought-internet.co.uk> References: <8963FB5F-E5AF-4967-A220-CD6420C7E729@freethought-internet.co.uk> Message-ID: On Mon, Dec 12, 2011 at 11:18 AM, Edward Dore wrote: > Take a look at Panopta - we use it to compliment our internal monitoring and find it great compared to some of the systems we've used in the past (Pingdom, Binary Canary). > > The interface is easy to use and responsive, we don't get false positives and there are a good range of checks. There's an API as well if you want to integrate it. > > I'd stay clear of the software agent though, we've had a few issues with that. For remote service checks we love it. > > Edward Dore > Freethought Internet > > On 12 Dec 2011, at 19:10, Eric J Esslinger wrote: > >> I'm not looking to monitor a massive infrastructure: 3 web sites, 2 mail servers (pop,imap,submission port, https webmail), 4 dns servers (including lookups to ensure they're not listening but not talking), and one inbound mx. A few network points to ping to ensure connectivity throughout my system. Scheduled notification windows (for example, during work hours I don't want my phone pinged unless it's everything going offline. Off hours I do. Secondary notifications if problem persists to other users, or in the event of many triggers. That sort of thing). Sensitivity settings (If web server 1 shows down for 5 min, that's not a big deal. Another one if it doesn't respond to repeated queries within 1 minute is a big deal) A Weekly summary of issues would be nice. (especially the 'well it was down for a short bit but we didn't notify as per settings') >> I don't have a lot of money to throw at this. I DO have detailed internal monitoring of our systems ?but sometimes that is not entirely useful, due to the fact that there are a few 'single points of failure' within our network/notification system, not to mention if the monitor itself goes offline it's not exactly going to be able to tell me about it. (and that happened once, right before the mail server decided to stop receiving mail). >> >> _____ Nagios, or Zabbix are the ones I am most familiar with. Zabbix is a bit involved to set up, and may not be what you need in the scale of things. Nagios is a bit cumbersome to keep up with rapidly changing systems of any size, but is good for small (and large) setups that are more static. Not without it's quirks mind, and takes a bit of work to set up if you've never done it before. But doesn't require a DB backend, or any other stuff, just a server to put it on. No agent needed, as long as everything you want to check is "gettable" from the server, like checking that a mail server is available for connections, etc. But can use agent checks, or pretty much any other checks. -- http://neon-buddha.net From nanog at lacutt.com Mon Dec 12 14:47:01 2011 From: nanog at lacutt.com (Derrick H.) Date: Mon, 12 Dec 2011 14:47:01 -0600 Subject: recommendations for external montioring services? In-Reply-To: References: Message-ID: <20111212204701.GN19342@nm.lacutt> On Mon, Dec 12, 2011 at 01:10:54PM -0600, Eric J Esslinger wrote: > I'm not looking to monitor a massive infrastructure: 3 web sites, 2 > mail servers (pop,imap,submission port, https webmail), 4 dns servers > (including lookups to ensure they're not listening but not talking), > and one inbound mx. A few network points to ping to ensure > connectivity throughout my system. Scheduled notification windows (for > example, during work hours I don't want my phone pinged unless it's > everything going offline. Off hours I do. Secondary notifications if > problem persists to other users, or in the event of many triggers. > That sort of thing). Sensitivity settings (If web server 1 shows down > for 5 min, that's not a big deal. Another one if it doesn't respond to > repeated queries within 1 minute is a big deal) A Weekly summary of > issues would be nice. (especially the 'well it was down for a short > bit but we didn't notify as per settings') I don't have a lot of money > to throw at this. I DO have detailed internal monitoring of our > systems but sometimes that is not entirely useful, due to the fact > that there are a few 'single points of failure' within our > network/notification system, not to mention if the monitor itself goes > offline it's not exactly going to be able to tell me about it. (and > that happened once, right before the mail server decided to stop > receiving mail). You may want to check out http://www.panopta.com/ Works well for me with reasonable pricing. Derrick > > __________________________ > Eric Esslinger > Information Services Manager - Fayetteville Public Utilities > http://www.fpu-tn.com/ > (931)433-1522 ext 165 > > This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. > From simon at slimey.org Mon Dec 12 14:56:59 2011 From: simon at slimey.org (Simon Lockhart) Date: Mon, 12 Dec 2011 20:56:59 +0000 Subject: Overall Netflix bandwidth usage numbers on a network? In-Reply-To: <22941D59-BCE0-4DB4-BC9D-BB67CEC3233D@ianai.net> References: <20111203005847.GI13315@hijacked.us> <4EDF9AE9.9040700@ispn.net> <4EE54B01.6000305@temk.in> <4EE56198.40307@snappydsl.net> <387BECF4-7EF9-43E6-BEEE-AA42DF1EEE19@bogus.com> <5ECE9281-B6CB-4669-857D-07E10A7C499C@snappydsl.net> <4EE58E8E.8000804@bogus.com> <22941D59-BCE0-4DB4-BC9D-BB67CEC3233D@ianai.net> Message-ID: <20111212205659.GA20184@virtual.bogons.net> On Mon Dec 12, 2011 at 03:10:20PM -0500, Patrick W. Gilmore wrote: > I believe Akamai, > LLNW, & L3 are the only companies that stream movies for Netflix. Peer with > the CDNs to save your transit. That would be good if more than one of those CDNs peered openly. Simon From raymond at prolocation.net Mon Dec 12 15:11:54 2011 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Mon, 12 Dec 2011 22:11:54 +0100 (CET) Subject: Overall Netflix bandwidth usage numbers on a network? In-Reply-To: <20111212205659.GA20184@virtual.bogons.net> References: <20111203005847.GI13315@hijacked.us> <4EDF9AE9.9040700@ispn.net> <4EE54B01.6000305@temk.in> <4EE56198.40307@snappydsl.net> <387BECF4-7EF9-43E6-BEEE-AA42DF1EEE19@bogus.com> <5ECE9281-B6CB-4669-857D-07E10A7C499C@snappydsl.net> <4EE58E8E.8000804@bogus.com> <22941D59-BCE0-4DB4-BC9D-BB67CEC3233D@ianai.net> <20111212205659.GA20184@virtual.bogons.net> Message-ID: Hi! >> I believe Akamai, >> LLNW, & L3 are the only companies that stream movies for Netflix. Peer with >> the CDNs to save your transit. > That would be good if more than one of those CDNs peered openly. So what one doesnt? Akamai will peer with you anywhere and i doubt LLNW will give you trouble. L3, well, they run a superb network and even more superb pricing, so why would they peer with anyone ;) I still think, old fashioned me, that a CDN doesnt do go without peering but some feel otherwise. Bye, Raymond. From simon at slimey.org Mon Dec 12 15:22:38 2011 From: simon at slimey.org (Simon Lockhart) Date: Mon, 12 Dec 2011 21:22:38 +0000 Subject: Overall Netflix bandwidth usage numbers on a network? In-Reply-To: References: <4EDF9AE9.9040700@ispn.net> <4EE54B01.6000305@temk.in> <4EE56198.40307@snappydsl.net> <387BECF4-7EF9-43E6-BEEE-AA42DF1EEE19@bogus.com> <5ECE9281-B6CB-4669-857D-07E10A7C499C@snappydsl.net> <4EE58E8E.8000804@bogus.com> <22941D59-BCE0-4DB4-BC9D-BB67CEC3233D@ianai.net> <20111212205659.GA20184@virtual.bogons.net> Message-ID: <20111212212238.GB20184@virtual.bogons.net> On Mon Dec 12, 2011 at 10:11:54PM +0100, Raymond Dijkxhoorn wrote: > Akamai will peer with you anywhere and i doubt LLNW will give you trouble. LLNW are restictive on peering. > L3, well, they run a superb network and even more superb pricing, so why > would they peer with anyone ;) And as I use L3 for transit, they'd never peer with me. Not that they peer with anyone outside the cabal anyway. > I still think, old fashioned me, that a CDN doesnt do go without peering > but some feel otherwise. Quite so. I don't get why CDNs don't all peer openly. I guess most (i.e. those which aren't Akamai) are more concerned with making money than with delivering a good service to the end user. Simon From jason at lixfeld.ca Mon Dec 12 16:00:38 2011 From: jason at lixfeld.ca (Jason Lixfeld) Date: Mon, 12 Dec 2011 17:00:38 -0500 Subject: Overall Netflix bandwidth usage numbers on a network? In-Reply-To: <20111212212238.GB20184@virtual.bogons.net> References: <4EDF9AE9.9040700@ispn.net> <4EE54B01.6000305@temk.in> <4EE56198.40307@snappydsl.net> <387BECF4-7EF9-43E6-BEEE-AA42DF1EEE19@bogus.com> <5ECE9281-B6CB-4669-857D-07E10A7C499C@snappydsl.net> <4EE58E8E.8000804@bogus.com> <22941D59-BCE0-4DB4-BC9D-BB67CEC3233D@ianai.net> <20111212205659.GA20184@virtual.bogons.net> <20111212212238.GB20184@virtual.bogons.net> Message-ID: <77F26F9D-F271-4C37-B017-3EC4C7AF8117@lixfeld.ca> On 2011-12-12, at 4:22 PM, Simon Lockhart wrote: > I guess most (i.e. those > which aren't Akamai) are more concerned with making money than with delivering > a good service to the end user. Really? I always thought that higher profits and buying transit were mutually exclusive relative to higher profits and openly peering. So what you are saying is that one stands to make more by paying upstreams for bit swapping? How's that work? If the argument is that the opex required for maintaining peering relationships is too expensive relative to the direct and indirect cost of buying bandwidth, I love to be edumacated on how that math actually works because it makes absolutely no sense to me. -- Sent from my mobile device From patrick at ianai.net Mon Dec 12 16:21:45 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 12 Dec 2011 17:21:45 -0500 Subject: Peering vs. Transit vs. Profit [was: Overall Netflix bandwidth usage numbers on a network?] In-Reply-To: <77F26F9D-F271-4C37-B017-3EC4C7AF8117@lixfeld.ca> References: <4EDF9AE9.9040700@ispn.net> <4EE54B01.6000305@temk.in> <4EE56198.40307@snappydsl.net> <387BECF4-7EF9-43E6-BEEE-AA42DF1EEE19@bogus.com> <5ECE9281-B6CB-4669-857D-07E10A7C499C@snappydsl.net> <4EE58E8E.8000804@bogus.com> <22941D59-BCE0-4DB4-BC9D-BB67CEC3233D@ianai.net> <20111212205659.GA20184@virtual.bogons.net> <20111212212238.GB20184@virtual.bogons.net> <77F26F9D-F271-4C37-B017-3EC4C7AF8117@lixfeld.ca> Message-ID: <3802FD53-27CF-417D-8AC0-EF1F25AE414D@ianai.net> On Dec 12, 2011, at 5:00 PM, Jason Lixfeld wrote: > On 2011-12-12, at 4:22 PM, Simon Lockhart wrote: > >> I guess most (i.e. those >> which aren't Akamai) are more concerned with making money than with delivering >> a good service to the end user. > > Really? I always thought that higher profits and buying transit were mutually exclusive relative to higher profits and openly peering. > > So what you are saying is that one stands to make more by paying upstreams for bit swapping? How's that work? You are assuming that peering with $ISP will lower someone's transit bill. That is demonstrably false in the case of Level 3 who (to a first approximation - please do not argue corner cases) pays no one for transit. It is also likely false over some set of $ISP_n for some peers. As a trivial example, if $NETWORK peers with your transit, not only would it not save them money to peer with you, it may cost them money if peering with you endangers the peering with your upstream. This can happen if $NETWORK does not have enough traffic to qualify for peering with your upstream when your traffic is removed from the link. So peering does not always equal profit. Would that life were so simple! =) > If the argument is that the opex required for maintaining peering relationships is too expensive relative to the direct and indirect cost of buying bandwidth, I love to be edumacated on how that math actually works because it makes absolutely no sense to me. Peering is not free. I can easily see the cost of bringing up a port to someone with 10 Mbps costing more than it saves for some perfectly valid network topologies. And that's just the most obvious example. The one above is another obvious example. There are reasons not to peer. Assuming there are not is a bad way to enter a negotiation. Put yourself in the place of the other network, figure out what their pain points are - performance, complexity, stability, cost, slot density, spare cycles (human and machine), etc., etc. To be successful in a negotiation, I submit it is useful to help them eliminate one or more of those pain points, i.e. make it worth their while. Remember, my company's peering policy (at public exchanges) is "YES". Since I wrote the policy, you can probably guess my view on peering. But if simply I assumed no one ever had a reason to say "no", I wouldn't get very far. There are two sides to every story. Sometimes the other side is confused, or even flat out wrong, but not always. And even when the other side is wrong, it may not be useful to bash them over the head with the truth. -- TTFN, patrick P.S. I also think "giving good service" is one vital component of "making more money". But maybe I'm silly. From mpetach at netflight.com Mon Dec 12 19:43:48 2011 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 12 Dec 2011 17:43:48 -0800 Subject: Overall Netflix bandwidth usage numbers on a network? In-Reply-To: <77F26F9D-F271-4C37-B017-3EC4C7AF8117@lixfeld.ca> References: <4EDF9AE9.9040700@ispn.net> <4EE54B01.6000305@temk.in> <4EE56198.40307@snappydsl.net> <387BECF4-7EF9-43E6-BEEE-AA42DF1EEE19@bogus.com> <5ECE9281-B6CB-4669-857D-07E10A7C499C@snappydsl.net> <4EE58E8E.8000804@bogus.com> <22941D59-BCE0-4DB4-BC9D-BB67CEC3233D@ianai.net> <20111212205659.GA20184@virtual.bogons.net> <20111212212238.GB20184@virtual.bogons.net> <77F26F9D-F271-4C37-B017-3EC4C7AF8117@lixfeld.ca> Message-ID: On Mon, Dec 12, 2011 at 2:00 PM, Jason Lixfeld wrote: > > On 2011-12-12, at 4:22 PM, Simon Lockhart wrote: > >> I guess most (i.e. those >> which aren't Akamai) are more concerned with making money than with delivering >> a good service to the end user. > > Really? ?I always thought that higher profits and buying transit were mutually exclusive relative to higher profits and openly peering. > > So what you are saying is that one stands to make more by paying upstreams for bit swapping? ?How's that work? > > If the argument is that the opex required for maintaining peering relationships is too expensive relative to the direct and indirect cost of buying bandwidth, I love to be edumacated on how that math actually works because it makes absolutely no sense to me. I'm somewhat assuming you're trolling here. :/ but just in case... the lost revenue from peering with someone when you could be charging them transit prices is the tradeoff being referred to here; Level3 isn't in the business of paying upstreams for bandwidth. (well, other than comcast, but that's a different thread entirely. And yes, I suppose that would be me trolling. Bad Matt!) Matt From mailinglists at expresswebsystems.com Mon Dec 12 21:18:35 2011 From: mailinglists at expresswebsystems.com (Express Web Systems) Date: Mon, 12 Dec 2011 21:18:35 -0600 Subject: recommendations for external montioring services? In-Reply-To: <20111212204701.GN19342@nm.lacutt> References: <20111212204701.GN19342@nm.lacutt> Message-ID: <016b01ccb945$e74236a0$b5c6a3e0$@com> > > You may want to check out http://www.panopta.com/ Works well for me > with reasonable pricing. > +1 to Panopta. We have been using them for the past two years and they have been very solid. We have even put in a few feature requests (voice notifications was one we specifically requested) and they have had them implemented and pushed out for beta testing in a couple of weeks. I would highly recommend them. From scott at sberkman.net Mon Dec 12 22:06:22 2011 From: scott at sberkman.net (Scott Berkman) Date: Mon, 12 Dec 2011 23:06:22 -0500 Subject: recommendations for external montioring services? In-Reply-To: <016b01ccb945$e74236a0$b5c6a3e0$@com> References: <20111212204701.GN19342@nm.lacutt> <016b01ccb945$e74236a0$b5c6a3e0$@com> Message-ID: <053901ccb94c$93ef5350$bbcdf9f0$@sberkman.net> Two I know and have used are Alertra and SiteRecon. -----Original Message----- From: Express Web Systems [mailto:mailinglists at expresswebsystems.com] Sent: Monday, December 12, 2011 10:19 PM To: 'Derrick H.'; nanog at nanog.org Subject: RE: recommendations for external montioring services? > > You may want to check out http://www.panopta.com/ Works well for me > with reasonable pricing. > +1 to Panopta. We have been using them for the past two years and they +have been very solid. We have even put in a few feature requests (voice notifications was one we specifically requested) and they have had them implemented and pushed out for beta testing in a couple of weeks. I would highly recommend them. From joelja at bogus.com Mon Dec 12 23:51:14 2011 From: joelja at bogus.com (Joel jaeggli) Date: Mon, 12 Dec 2011 21:51:14 -0800 Subject: Sad IPv4 story? In-Reply-To: References: <20196.3069.632519.601259@world.std.com> <15282.1323576426@turing-police.cc.vt.edu> <3ADD5AAC-C95A-48CD-8880-F44E799C8A25@eparsonage.com> Message-ID: <4EE6E7D2.8060306@bogus.com> On 12/12/11 02:05 , Leigh Porter wrote: >> -----Original Message----- From: Vitkovsky, Adam >> [mailto:avitkovsky at emea.att.com] Sent: 12 December 2011 09:19 To: >> Eric Parsonage; Valdis.Kletnieks at vt.edu Cc: nanog at nanog.org >> Subject: RE: Sad IPv4 story? >> >>> and models that doesn't take "we may not get IPv4 space" into >>> account >> and have >>> a contingency plan for that *deserves* to be soundly mocked and >> ridiculed in >>> public. >> >> That's right >> >> However the original post was concerning a fresh new ISP that can't >> run their business the way they would like Maybe they'd like to >> build an mpls core which right now is not possible with only ipv6 >> at hand I'd like to see the business model to build an mpls network >> with all the features we're used to -but solely on ipv6 -I guess >> the plan would be let's wait a couple years till it gets >> implemented and mature enough > > Well really this is pretty much our fault. IPv6 has been on peoples > 'back burner' for far too long. Additional vendor pressure and > pressure at the IETF would have pushed things forward far faster had > people actually been interested in doing so. > > As per an earlier post, I am shocked at how I still have vendors > coming to me with equipment that is nowhere near ready for commercial > IPv6 deployment, it either just does not work, is half baked or is > "on the roadmap". > > So now we will reap the consequences and it will be at the cost of > new market entrants (which I am sure will please some people) and > perhaps cold hard cash for those who cannot expand their business or > have to 'buy' address space. New market entrants are the customers of existing operators, so their plight and the feasibility of being a new market entrant impacts our bottom lines. > I know a lot of people have been working hard to move IPv6 along both > here, at NANOG and other events and with their vendors. It's because > of those people, like Randy perhaps that we actually have what we do > now else most people would still be stuck with their heads in the > sand. > > Well, I am sure it'll all be OK in the end... > > -- Leigh > > > > ______________________________________________________________________ > > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ > > > From mir at ripe.net Tue Dec 13 02:10:18 2011 From: mir at ripe.net (Mirjam Kuehne) Date: Tue, 13 Dec 2011 09:10:18 +0100 Subject: 128.0.0.0/16 as seen from RIPE Atlas Message-ID: <4EE7086A.8050309@ripe.net> Dear colleagues, As a follow-up to the recent article "The Curious Case of 128.0/16", we now looked at 128.0/16 as seen from RIPE Atlas: https://labs.ripe.net/Members/dfk/128.0-16-seen-by-atlas Kind regards, Mirjam Kuehne RIPE NCC From jared at puck.nether.net Tue Dec 13 03:54:07 2011 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 13 Dec 2011 04:54:07 -0500 Subject: Sad IPv4 story? In-Reply-To: References: Message-ID: <4D3C4400-1327-41F4-B4C9-DBCBCBB60D3F@puck.nether.net> On Dec 11, 2011, at 6:52 AM, John Curran wrote: > The sooner we get the content on IPv6 in addition to IPv4, the sooner > that connecting new customers up via IPv6 without additional unique > IPv4 address space becomes viable (and obviously if we had the vast > majority of content already on IPv6, then connecting new customers > via IPv6 would be simple indeed.) Google and other content providers will whitelist you if you coordinate with them. Some may not like the social-political implications of this as it will create what some see as IPv6 islands that are overlays on the global IPv6 network. This is nothing new, there have always been private and policy based decisions that lead to reachability. We have seen great success (IMHO) in IPv6 day. We need to see this happen again with a broader number of networks having IPv6 connectivity. I look forward to seeing the continued broadband deployment of IPv6 to make the data far more interesting. I'm glad to see the major carriers doing IPv6 work in this space. It appears that the traditional/incumbent telcos in the US are behind the curve, but I'm not entirely convinced their business model is relevant in the future decades. - Jared From michiel at klaver.it Tue Dec 13 04:11:44 2011 From: michiel at klaver.it (Michiel Klaver) Date: Tue, 13 Dec 2011 11:11:44 +0100 Subject: recommendations for external montioring services? In-Reply-To: References: Message-ID: <4EE724E0.3060008@klaver.it> At 22-07-2011 20:59, Eric J Esslinger wrote: > I'm not looking to monitor a massive infrastructure: 3 web sites, 2 mail servers (pop,imap,submission port, https webmail), 4 dns servers (including lookups to ensure they're not listening but not talking), and one inbound mx. A few network points to ping to ensure connectivity throughout my system. Scheduled notification windows (for example, during work hours I don't want my phone pinged unless it's everything going offline. Off hours I do. Secondary notifications if problem persists to other users, or in the event of many triggers. That sort of thing). Sensitivity settings (If web server 1 shows down for 5 min, that's not a big deal. Another one if it doesn't respond to repeated queries within 1 minute is a big deal) A Weekly summary of issues would be nice. (especially the 'well it was down for a short bit but we didn't notify as per settings') > I don't have a lot of money to throw at this. I DO have detailed internal monitoring of our systems but sometimes that is not entirely useful, due to the fact that there are a few 'single points of failure' within our network/notification system, not to mention if the monitor itself goes offline it's not exactly going to be able to tell me about it. (and that happened once, right before the mail server decided to stop receiving mail). > Some external monitoring services I could recommend: https://circonus.com/ http://mon.itor.us/ http://pingdom.com/ From dmiller at tiggee.com Tue Dec 13 08:40:12 2011 From: dmiller at tiggee.com (David Miller) Date: Tue, 13 Dec 2011 09:40:12 -0500 Subject: recommendations for external montioring services? In-Reply-To: <4EE724E0.3060008@klaver.it> References: <4EE724E0.3060008@klaver.it> Message-ID: <4EE763CC.3050805@tiggee.com> On 12/13/2011 5:11 AM, Michiel Klaver wrote: > At 22-07-2011 20:59, Eric J Esslinger wrote: >> I'm not looking to monitor a massive infrastructure: 3 web sites, 2 mail servers (pop,imap,submission port, https webmail), 4 dns servers (including lookups to ensure they're not listening but not talking), and one inbound mx. A few network points to ping to ensure connectivity throughout my system. Scheduled notification windows (for example, during work hours I don't want my phone pinged unless it's everything going offline. Off hours I do. Secondary notifications if problem persists to other users, or in the event of many triggers. That sort of thing). Sensitivity settings (If web server 1 shows down for 5 min, that's not a big deal. Another one if it doesn't respond to repeated queries within 1 minute is a big deal) A Weekly summary of issues would be nice. (especially the 'well it was down for a short bit but we didn't notify as per settings') >> I don't have a lot of money to throw at this. I DO have detailed internal monitoring of our systems but sometimes that is not entirely useful, due to the fact that there are a few 'single points of failure' within our network/notification system, not to mention if the monitor itself goes offline it's not exactly going to be able to tell me about it. (and that happened once, right before the mail server decided to stop receiving mail). >> > Some external monitoring services I could recommend: > > https://circonus.com/ > http://mon.itor.us/ > http://pingdom.com/ > I'll throw another into the list: http://www.watchmouse.com/ They have some nice features and monitoring over IPv4 and IPv6. -DMM From graham at g-rock.net Tue Dec 13 10:49:55 2011 From: graham at g-rock.net (=?utf-8?B?Z3JhaGFtQGctcm9jay5uZXQ=?=) Date: Tue, 13 Dec 2011 10:49:55 -0600 Subject: =?utf-8?B?Q29sb3MgaW4gTWVsYm91cm5lLCBGTC4g?= Message-ID: For those with Colo space in Melbourne FL. Please reply to me offlist; looking to deploy a POP there. Thanks. Sent from my HTC on the Now Network from Sprint! From robert at timetraveller.org Tue Dec 13 19:10:05 2011 From: robert at timetraveller.org (Robert Brockway) Date: Wed, 14 Dec 2011 11:10:05 +1000 (EST) Subject: recommendations for external montioring services? In-Reply-To: References: Message-ID: On Mon, 12 Dec 2011, Eric J Esslinger wrote: > I'm not looking to monitor a massive infrastructure: 3 web sites, 2 mail > servers (pop,imap,submission port, https webmail), 4 dns servers > (including lookups to ensure they're not listening but not talking), and > one inbound mx. A few network points to ping to ensure connectivity > throughout my system. Scheduled notification windows (for example, > during work hours I don't want my phone pinged unless it's everything > going offline. Off hours I do. Secondary notifications if problem > persists to other users, or in the event of many triggers. That sort of > thing). Sensitivity settings (If web server 1 shows down for 5 min, > that's not a big deal. Another one if it doesn't respond to repeated > queries within 1 minute is a big deal) A Weekly summary of issues would > be nice. (especially the 'well it was down for a short bit but we didn't > notify as per settings') I don't have a lot of money to throw at this. I Hi Eric. The feature set you are describing should be in any monitoring system worthy of the name. I've used Nagios to good effect for the best part of the last 12 years or so. Before that I used Big Brother, which sucked in various ways. I did an evaluation on a wide variety of FOSS monitoring systems 2-3 years ago and Nagios won at the time (again). Generally I found the alternatives had problems that I considered to be quite serious (such as being overly complicated or doing checks so frequently that they loaded the systems they were supposed to be monitoring[1]). I'm currently trialing Icinga, a fork of Nagios. Puppet can be set up to manage Nagios/Icinga config which cuts down on the admin overhead. Nagios/Icinga can be hooked up to Collectd to provide performance data as well as alert monitoring. One concern about external monitoring services is the level of visibility they need to have in to your network to adequately monitor them. My recommendation is to do a proper risk assessment on the available options. > DO have detailed internal monitoring of our systems but sometimes that > is not entirely useful, due to the fact that there are a few 'single > points of failure' within our network/notification system, not to > mention if the monitor itself goes offline it's not exactly going to be > able to tell me about it. (and that happened once, right before the mail > server decided to stop receiving mail). There are a couple of ways to deal with this. Some monitoring applications can fail-over to a standby server if the primary fails. But this isn't even really necessary. You will arguably gain higher reliability by running multiple _independent_ monitors and have them monitor each other[2]. I have often used this approach. The principal aim here is to guarantee that you are alerted to any single failure (a production service, system or a monitor). Multiple simultaneous failures could still produce a blackspot. It is possible to design a system that will discover multiple simultaneous failures, but it takes more effort and resources. [1] Sometimes I wonder if the people developing certain systems have any operational experience at all. [2] A system designed to fail-over on certain conditions may fail to fail-over, ah, so to speak. Cheers, Rob -- Email: robert at timetraveller.org Linux counter ID #16440 IRC: Solver (OFTC & Freenode) Web: http://www.practicalsysadmin.com Director, Software in the Public Interest (http://spi-inc.org/) Free & Open Source: The revolution that quietly changed the world "One ought not to believe anything, save that which can be proven by nature and the force of reason" -- Frederick II (26 December 1194 ? 13 December 1250) From MGauvin at dryden.ca Tue Dec 13 19:43:35 2011 From: MGauvin at dryden.ca (Mark Gauvin) Date: Tue, 13 Dec 2011 19:43:35 -0600 Subject: recommendations for external montioring services? In-Reply-To: References: Message-ID: <85720F8A-86B8-4926-92D9-EBE2BD4006F4@dryden.ca> Solar winds as you send in the specific mib required to monitor and a week later it's general release Sent from my iPhone On 2011-12-13, at 7:11 PM, "Robert Brockway" wrote: > On Mon, 12 Dec 2011, Eric J Esslinger wrote: > >> I'm not looking to monitor a massive infrastructure: 3 web sites, 2 >> mail >> servers (pop,imap,submission port, https webmail), 4 dns servers >> (including lookups to ensure they're not listening but not >> talking), and >> one inbound mx. A few network points to ping to ensure connectivity >> throughout my system. Scheduled notification windows (for example, >> during work hours I don't want my phone pinged unless it's everything >> going offline. Off hours I do. Secondary notifications if problem >> persists to other users, or in the event of many triggers. That >> sort of >> thing). Sensitivity settings (If web server 1 shows down for 5 min, >> that's not a big deal. Another one if it doesn't respond to repeated >> queries within 1 minute is a big deal) A Weekly summary of issues >> would >> be nice. (especially the 'well it was down for a short bit but we >> didn't >> notify as per settings') I don't have a lot of money to throw at >> this. I > > Hi Eric. The feature set you are describing should be in any > monitoring > system worthy of the name. I've used Nagios to good effect for the > best > part of the last 12 years or so. Before that I used Big Brother, > which > sucked in various ways. > > I did an evaluation on a wide variety of FOSS monitoring systems 2-3 > years > ago and Nagios won at the time (again). Generally I found the > alternatives had problems that I considered to be quite serious > (such as > being overly complicated or doing checks so frequently that they > loaded > the systems they were supposed to be monitoring[1]). > > I'm currently trialing Icinga, a fork of Nagios. > > Puppet can be set up to manage Nagios/Icinga config which cuts down > on the > admin overhead. > > Nagios/Icinga can be hooked up to Collectd to provide performance > data as > well as alert monitoring. > > One concern about external monitoring services is the level of > visibility > they need to have in to your network to adequately monitor them. > > My recommendation is to do a proper risk assessment on the available > options. > >> DO have detailed internal monitoring of our systems but sometimes >> that >> is not entirely useful, due to the fact that there are a few 'single >> points of failure' within our network/notification system, not to >> mention if the monitor itself goes offline it's not exactly going >> to be >> able to tell me about it. (and that happened once, right before the >> mail >> server decided to stop receiving mail). > > There are a couple of ways to deal with this. Some monitoring > applications can fail-over to a standby server if the primary > fails. But > this isn't even really necessary. You will arguably gain higher > reliability by running multiple _independent_ monitors and have them > monitor each other[2]. I have often used this approach. > > The principal aim here is to guarantee that you are alerted to any > single > failure (a production service, system or a monitor). Multiple > simultaneous failures could still produce a blackspot. It is > possible to > design a system that will discover multiple simultaneous failures, > but it > takes more effort and resources. > > > [1] Sometimes I wonder if the people developing certain systems have > any > operational experience at all. > > [2] A system designed to fail-over on certain conditions may fail to > fail-over, ah, so to speak. > > Cheers, > > Rob > > -- > Email: robert at timetraveller.org Linux counter ID #16440 > IRC: Solver (OFTC & Freenode) > Web: http://www.practicalsysadmin.com > Director, Software in the Public Interest (http://spi-inc.org/) > Free & Open Source: The revolution that quietly changed the world > "One ought not to believe anything, save that which can be proven by > nature and the force of reason" -- Frederick II (26 December 1194 ? > 13 December 1250) From pde at eff.org Tue Dec 13 20:12:34 2011 From: pde at eff.org (Peter Eckersley) Date: Tue, 13 Dec 2011 18:12:34 -0800 Subject: EFF call for signatures from Internet engineers against censorship Message-ID: <20111214021234.GA4101@xylophonic> (Apologies for an slightly-OT posting) Last year, EFF organized an open letter from network engineers against Internet censorship legislation being considered by the US Senate (https://eff.org/deeplinks/2010/09/open-letter). Along with other activists' efforts, we successfully delayed that proposal, but the letter needs to be updated for two bills, SOPA and PIPA, that are close to passing through US Congress now. If you would like to sign, please email me at pde at eff.org, with a one-line summary of what part of the Internet you helped to helped to design, implement, debug or run. We need signatures by 8am GMT on Thursday (midnight Wednesday US Pacific, 3am US Eastern). Also feel free to forward this to colleagues who played a role in designing and building the network. The updated letter's text is below: We, the undersigned, have played various parts in building a network called the Internet. We wrote and debugged the software; we defined the standards and protocols that talk over that network. Many of us invented parts of it. We're just a little proud of the social and economic benefits that our project, the Internet, has brought with it. Last year, many of us wrote to you and your colleagues to warn about the proposed "COICA" copyright and censorship legislation. Today, we are writing again to reiterate our concerns about the SOPA and PIPA derivatives of last year's bill, that are under consideration in the House and Senate. In many respects, these proposals are worse than the one we were alarmed to read last year. If enacted, either of these bills will create an environment of tremendous fear and uncertainty for technological innovation, and seriously harm the credibility of the United States in its role as a steward of key Internet infrastructure. Regardless of recent amendments to SOPA, both bills will risk fragmenting the Internet's global domain name system (DNS) and have other capricious technical consequences. In exchange for this, such legislation would engender censorship that will simultaneously be circumvented by deliberate infringers while hampering innocent parties' right and ability to communicate and express themselves online. All censorship schemes impact speech beyond the category they were intended to restrict, but these bills are particularly egregious in that regard because they cause entire domains to vanish from the Web, not just infringing pages or files. Worse, an incredible range of useful, law-abiding sites can be blacklisted under these proposals. In fact, it seems that this has already begun to happen under the nascent DHS/ICE seizures program. Censorship of Internet infrastructure will inevitably cause network errors and security problems. This is true in China, Iran and other countries that censor the network today; it will be just as true of American censorship. It is also true regardless of whether censorship is implemented via the DNS, proxies, firewalls, or any other method. Types of network errors and insecurity that we wrestle with today will become more widespread, and will affect sites other than those blacklisted by the American government. The current bills -- SOPA explicitly and PIPA implicitly -- also threaten engineers who build Internet systems or offer services that are not readily and automatically compliant with censorship actions by the U.S. government. When we designed the Internet the first time, our priorities were reliability, robustness and minimizing central points of failure or control. We are alarmed that Congress is so close to mandating censorship-compliance as a design requirement for new Internet innovations. This can only damage the security of the network, and give authoritarian governments more power over what their citizens can read and publish. The US government has regularly claimed that it supports a free and open Internet, both domestically and abroad. We cannot have a free and open Internet unless its naming and routing systems sit above the political concerns and objectives of any one government or industry. To date, the leading role the US has played in this infrastructure has been fairly uncontroversial because America is seen as a trustworthy arbiter and a neutral bastion of free expression. If the US begins to use its central in the network for censorship that advances its political and economic agenda, the consequences will be far-reaching and destructive. Senators, Congressmen, we believe the Internet is too important and too valuable to be endangered in this way, and implore you to put these bills aside. -- Peter Eckersley pde at eff.org Technology Projects Director Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993 From ipv4brokers at gmail.com Tue Dec 13 21:13:34 2011 From: ipv4brokers at gmail.com (IPv4 Brokers) Date: Tue, 13 Dec 2011 22:13:34 -0500 Subject: Your Christmas Bonus Has Arrived Message-ID: Do you have subnets that are not in use, or only used for specific purposes? If so, please contact us. We are paying up-front (or escrow) for the use of networks that are not used. The networks are used for honeypots and other research. You do not have to modify your BGP announcements, establish a GRE tunnel to our network and forward packets over the tunnel. The networks may be used for a month or longer, you are paid an agreed upon price per each month of use. Your confidentiality is absolutely guaranteed. Only you will know that you're making money on your un-used or single/special-use networks. We do require a minimum of /24. From matt at mt.au.com Tue Dec 13 21:16:09 2011 From: matt at mt.au.com (Matt Taylor) Date: Wed, 14 Dec 2011 14:16:09 +1100 Subject: Your Christmas Bonus Has Arrived In-Reply-To: References: Message-ID: <4EE814F9.8000409@mt.au.com> On 14/12/2011 2:13 PM, IPv4 Brokers wrote: > Do you have subnets that are not in use, or only used for specific > purposes? If so, please contact us. > > We are paying up-front (or escrow) for the use of networks that are not > used. The networks are used for honeypots and other research. > > You do not have to modify your BGP announcements, establish a GRE tunnel to > our network and forward packets over the tunnel. > > The networks may be used for a month or longer, you are paid an agreed upon > price per each month of use. > > Your confidentiality is absolutely guaranteed. Only you will know that > you're making money on your un-used or single/special-use networks. > > We do require a minimum of /24. ... Heh ipv4brokers at gmail.com -.- Matt. From keegan.holley at sungard.com Tue Dec 13 22:00:12 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Tue, 13 Dec 2011 23:00:12 -0500 Subject: Your Christmas Bonus Has Arrived In-Reply-To: References: Message-ID: Do the blocks have to come from a company I still work for? If not I have a boat load.. 2011/12/13 IPv4 Brokers > Do you have subnets that are not in use, or only used for specific > purposes? If so, please contact us. > > We are paying up-front (or escrow) for the use of networks that are not > used. The networks are used for honeypots and other research. > > You do not have to modify your BGP announcements, establish a GRE tunnel to > our network and forward packets over the tunnel. > > The networks may be used for a month or longer, you are paid an agreed upon > price per each month of use. > > Your confidentiality is absolutely guaranteed. Only you will know that > you're making money on your un-used or single/special-use networks. > > We do require a minimum of /24. > > From keegan.holley at sungard.com Tue Dec 13 22:03:16 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Tue, 13 Dec 2011 23:03:16 -0500 Subject: Your Christmas Bonus Has Arrived In-Reply-To: <4EE814F9.8000409@mt.au.com> References: <4EE814F9.8000409@mt.au.com> Message-ID: ... Heh > > ipv4brokers at gmail.com > > -.- > > If domain squatting and patent trolling are both legitimate sometimes multi-million dollar businesses are you really surprised? From streiner at cluebyfour.org Tue Dec 13 22:56:19 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 13 Dec 2011 23:56:19 -0500 (EST) Subject: Your Christmas Bonus Has Arrived In-Reply-To: <4EE814F9.8000409@mt.au.com> References: <4EE814F9.8000409@mt.au.com> Message-ID: On Wed, 14 Dec 2011, Matt Taylor wrote: > On 14/12/2011 2:13 PM, IPv4 Brokers wrote: >> We are paying up-front (or escrow) for the use of networks that are not >> used. The networks are used for honeypots and other research. >> >> The networks may be used for a month or longer, you are paid an agreed >> upon price per each month of use. >> >> We do require a minimum of /24. Sounds like another middleman for 'bulletproof' hosting services for people who generally are up to no good. As far as I'm concerned, they can have as much of 10/8 as they want. My rate per /24 is very reasonable. jms From patrick at ianai.net Tue Dec 13 23:40:16 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 14 Dec 2011 00:40:16 -0500 Subject: Your Christmas Bonus Has Arrived In-Reply-To: References: <4EE814F9.8000409@mt.au.com> Message-ID: <217E1C9B-EC83-4801-BBD8-60C7777A0814@ianai.net> On Dec 13, 2011, at 11:56 PM, Justin M. Streiner wrote: > On Wed, 14 Dec 2011, Matt Taylor wrote: >> On 14/12/2011 2:13 PM, IPv4 Brokers wrote: >>> We are paying up-front (or escrow) for the use of networks that are not >>> used. The networks are used for honeypots and other research. >>> >>> The networks may be used for a month or longer, you are paid an agreed >>> upon price per each month of use. >>> >>> We do require a minimum of /24. > > Sounds like another middleman for 'bulletproof' hosting services for people who generally are up to no good. I believe this company is the one that sold the MS & Borders blocks, so they may be "legit" (whatever that means in this context). Also, they may be using a GMail account because it is likely they crossed some line with people (perhaps even the NANOG mail admins) and need a disposable account. Or maybe they really are running their business off *@gmail.com.... -- TTFN, patrick From Valdis.Kletnieks at vt.edu Wed Dec 14 00:04:29 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 14 Dec 2011 01:04:29 -0500 Subject: Your Christmas Bonus Has Arrived In-Reply-To: Your message of "Tue, 13 Dec 2011 23:56:19 EST." References: <4EE814F9.8000409@mt.au.com> Message-ID: <8258.1323842669@turing-police.cc.vt.edu> On Tue, 13 Dec 2011 23:56:19 EST, "Justin M. Streiner" said: > As far as I'm concerned, they can have as much of 10/8 as they want. My > rate per /24 is very reasonable. Oh, I don't think they'll fall for that, everbody knows 10/8 and 192.168/16 are private networks. However, I bet I can underbid Justin with some of the /24's off the end of 172.16/12 - my HPC people aren't using anywhere near the whole allocation and will never notice a bunch of /24's off the end. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From chaim.rieger at gmail.com Wed Dec 14 00:07:44 2011 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Tue, 13 Dec 2011 22:07:44 -0800 Subject: Your Christmas Bonus Has Arrived In-Reply-To: References: Message-ID: <1689b1b1-9c0c-4d7d-b1d4-4c533bfe5144@email.android.com> What do you have for those that don't do the whole Jesus thing ? From babak at farrokhi.net Wed Dec 14 00:31:46 2011 From: babak at farrokhi.net (Babak Farrokhi) Date: Wed, 14 Dec 2011 10:01:46 +0330 Subject: Your Christmas Bonus Has Arrived In-Reply-To: <217E1C9B-EC83-4801-BBD8-60C7777A0814@ianai.net> References: <4EE814F9.8000409@mt.au.com> <217E1C9B-EC83-4801-BBD8-60C7777A0814@ianai.net> Message-ID: Is there a comapny behind that gmail mailbox? And they could make a deal with MS & Borders using the same mailbox? -- Babak Farrokhi On Dec 14, 2011, at 9:10 AM, "Patrick W. Gilmore" wrote: > On Dec 13, 2011, at 11:56 PM, Justin M. Streiner wrote: >> On Wed, 14 Dec 2011, Matt Taylor wrote: >>> On 14/12/2011 2:13 PM, IPv4 Brokers wrote: >>>> We are paying up-front (or escrow) for the use of networks that are not >>>> used. The networks are used for honeypots and other research. >>>> >>>> The networks may be used for a month or longer, you are paid an agreed >>>> upon price per each month of use. >>>> >>>> We do require a minimum of /24. >> >> Sounds like another middleman for 'bulletproof' hosting services for people who generally are up to no good. > > I believe this company is the one that sold the MS & Borders blocks, so they may be "legit" (whatever that means in this context). > > Also, they may be using a GMail account because it is likely they crossed some line with people (perhaps even the NANOG mail admins) and need a disposable account. > > Or maybe they really are running their business off *@gmail.com.... > > -- > TTFN, > patrick > > From don at bowenvale.co.nz Wed Dec 14 00:36:49 2011 From: don at bowenvale.co.nz (Don Gould) Date: Wed, 14 Dec 2011 19:36:49 +1300 Subject: Sad IPv4 story? In-Reply-To: References: Message-ID: <4EE84401.1030502@bowenvale.co.nz> I really didn't follow to much of this thread, it's all a bit weird with some obvious industry under currents running that I don't follow. What I will say is that I'm currently involved with exactly this issue and would have to say that it's all just getting sillier by the day. I've been researching solutions with NAT and double NAT in mind because it's obvious that v4 space is going to become a growing problem. It's interesting to see the things that break when you use double NAT. What's also interesting is the growing competitive market place with incumbent providers, who have enough v4 space for their entire market, contracting their retail operations while their retail competitors are growing in size. I've been working on some very basic projections for my country and expect over the next decade we will see at least 30%, or more, movement in our market. So where is this going to leave v4 allocations? Will the incumbents protect their retail operations by locking up their v4 space so that smaller competitors can't grow? Will we all move to v6 to make the problem go away? (Not likely, the level of edge understanding of v6 isn't there, and you lot already had a rant about CPE this week, so I won't go there!) Will we develop smarter v4 technology and just NAT on NAT... and on NAT? The only thing that is really clear is the lack of clarity. D On 10/12/2011 7:37 a.m., Franck Martin wrote: > I just had a personal email from a brand new ISP in the Asia-Pacific area desperately looking for enough IPv4 to be able to run their business the way they would like? > > This is just a data point. > -- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699 From leigh.porter at ukbroadband.com Wed Dec 14 01:20:56 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Wed, 14 Dec 2011 07:20:56 +0000 Subject: Your Christmas Bonus Has Arrived In-Reply-To: <1689b1b1-9c0c-4d7d-b1d4-4c533bfe5144@email.android.com> References: <1689b1b1-9c0c-4d7d-b1d4-4c533bfe5144@email.android.com> Message-ID: > -----Original Message----- > From: Chaim Rieger [mailto:chaim.rieger at gmail.com] > Sent: 14 December 2011 06:10 > To: IPv4 Brokers; nanog at nanog.org > Subject: Re: Your Christmas Bonus Has Arrived > > What do you have for those that don't do the whole Jesus thing ? > That would be Hell.. -- Leigh ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From hmurray at megapathdsl.net Wed Dec 14 01:21:19 2011 From: hmurray at megapathdsl.net (Hal Murray) Date: Tue, 13 Dec 2011 23:21:19 -0800 Subject: EFF call for signatures from Internet engineers against censorship Message-ID: <20111214072119.81F79800037@ip-64-139-1-69.sjc.megapath.net> > but the letter needs to be updated for two bills, SOPA and PIPA, that are > close to passing through US Congress now. Stanford law school CIS (Center for Internet and Society) had a panel on SOPA a week ago. What's Wrong with SOPA? http://cyberlaw.stanford.edu/node/6770 That's got a link to the talk on youtube: 2 hours. I thought it was very good. (I'm may be biased. I live in Silicon Valley, not Hollywood.) The handout also has a link to a white paper on the DNS issues. htp://bit.ly/sZBJbd Security and Other Technical Concerns Raised by the DNS Filtering Requirements in the PROTECT IP Bill Authors: Steve Crocker, Shinkuro, Inc. David Dagon, Georgia Tech Dan Kaminsky, DKH Danny McPherson, Verisign, Inc. Paul Vixie, Internet Systems Consortium My opinions (US centric): Everybody agrees that Hollywood has problems with getting ripped off. The bill should be dumped rather than patched until it is good enough. (If you are a cynic, you would propose that the really terrible parts of the bill were put there so that the good guys would focus on getting them removed and ignore the parts that were only bad.) Technically, it won't work. (Spammer's have lots of practice creating domains faster than people can black list them and/or hiding in legitimate domains.) See URL above. Technically, the unintended consequences are nasty. (at least the ones we can see) Our legal quirks are already hurting US based cloud servers. http://www.politico.com/news/stories/1111/69366.html Internationally, it's shooting ourselves in the foot. Hillary Clinton is on record as saying the Internet should be open. If China did something like this we would make fun of them. If we block their domains, they can block Google and such. (They are undoubtedly better at it than we are. Google gets a lot of its income from offshore.) There is no due-process. The AG could take down Google. There is already a good example of the government taking down a legitimate domain without being willing to provide any justification: Breaking News: Feds Falsely Censor Popular Blog For Over A Year, Deny All Due Process, Hide All Details... http://j.mp/s1aS6z http://www.techdirt.com/articles/20111208/08225217010/ breaking-news-feds-falsely-censor-popular-blog-over-year-deny-all-due- process-hide-all-details.shtml This whole mess is a wonderful example of why many citizens are cynical about Congress. It looks like the MPAA/RIAA can buy whatever they want. -- These are my opinions, not necessarily my employer's. I hate spam. From bortzmeyer at nic.fr Wed Dec 14 02:07:33 2011 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 14 Dec 2011 09:07:33 +0100 Subject: EFF call for signatures from Internet engineers against censorship In-Reply-To: <20111214021234.GA4101@xylophonic> References: <20111214021234.GA4101@xylophonic> Message-ID: <20111214080733.GB32110@nic.fr> On Tue, Dec 13, 2011 at 06:12:34PM -0800, Peter Eckersley wrote a message of 86 lines which said: > To date, the leading role the US has played in this infrastructure > has been fairly uncontroversial [sic and re-sic] because America > is seen as a trustworthy arbiter and a neutral bastion of free > expression. I am just a lurker on Nanog since I do not operate a network in North America and therefore I hesitated to sign the letter but this sentence is too much: it means you cannot sign unless you endorse this ridiculous propaganda. It's bad to use the fight for freedom of speech in this way :-( From mohacsi at niif.hu Wed Dec 14 02:11:37 2011 From: mohacsi at niif.hu (Mohacsi Janos) Date: Wed, 14 Dec 2011 09:11:37 +0100 (CET) Subject: Your Christmas Bonus Has Arrived In-Reply-To: References: Message-ID: On Tue, 13 Dec 2011, IPv4 Brokers wrote: > Do you have subnets that are not in use, or only used for specific > purposes? If so, please contact us. > > We are paying up-front (or escrow) for the use of networks that are not > used. The networks are used for honeypots and other research. > > You do not have to modify your BGP announcements, establish a GRE tunnel to > our network and forward packets over the tunnel. > > The networks may be used for a month or longer, you are paid an agreed upon > price per each month of use. > > Your confidentiality is absolutely guaranteed. Only you will know that > you're making money on your un-used or single/special-use networks. > > We do require a minimum of /24. And you remain responsible for malicious activity of IPv4 Brokers ..... Regards, Janos Mohacsi From mtinka at globaltransit.net Wed Dec 14 03:06:06 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Wed, 14 Dec 2011 17:06:06 +0800 Subject: Sad IPv4 story? In-Reply-To: <4EE84401.1030502@bowenvale.co.nz> References: <4EE84401.1030502@bowenvale.co.nz> Message-ID: <201112141706.09852.mtinka@globaltransit.net> On Wednesday, December 14, 2011 02:36:49 PM Don Gould wrote: > I've been researching solutions with NAT and double NAT > in mind because it's obvious that v4 space is going to > become a growing problem. We've started playing with Stateful NAT64 on a couple of Cisco ASR1006's. In general, it works okay, save for issues with applications that have no IPv6 support, e.g., Skype, e.t.c. We hope to find more issues as more customers sign up to be guinea pigs. > The only thing that is really clear is the lack of > clarity. Indeed. We're doing what we can to be part of the solution, by picking technologies we think will be useful for us and going out and testing them at scale, with a goal to start rolling out v6 in droves as well provide usable operator feedback re: our deployment to vendors and other operators alike. As much as we'd like to see how the market unravels re: v4, e.t.c., the fact remains that v6 is the inevitable solution. So best to get cracking now with real deployments. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From ops.lists at gmail.com Wed Dec 14 04:12:51 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 14 Dec 2011 15:42:51 +0530 Subject: EFF call for signatures from Internet engineers against censorship In-Reply-To: <20111214072119.81F79800037@ip-64-139-1-69.sjc.megapath.net> References: <20111214072119.81F79800037@ip-64-139-1-69.sjc.megapath.net> Message-ID: I would strongly suggest that operators work with their legal departments to endorse this paper by Crocker and others. If other ISP organizations (such as say MAAWG) come out with something, other operators could sign on to that as well. The EFF petition has way too much propaganda and far less content than would be entirely productive in a policy discussion. --srs On Wed, Dec 14, 2011 at 12:51 PM, Hal Murray wrote: > > ?Security and Other Technical Concerns Raised by the > ? ?DNS Filtering Requirements in the PROTECT IP Bill > ?Authors: > ? ?Steve Crocker, Shinkuro, Inc. > ? ?David Dagon, Georgia Tech > ? ?Dan Kaminsky, DKH > ? ?Danny McPherson, Verisign, Inc. > ? ?Paul Vixie, Internet Systems Consortium -- Suresh Ramasubramanian (ops.lists at gmail.com) From Michael_OReirdan at Cable.Comcast.com Wed Dec 14 05:36:59 2011 From: Michael_OReirdan at Cable.Comcast.com (O'Reirdan, Michael) Date: Wed, 14 Dec 2011 11:36:59 +0000 Subject: EFF call for signatures from Internet engineers against censorship In-Reply-To: References: <20111214072119.81F79800037@ip-64-139-1-69.sjc.megapath.net>, Message-ID: MAAWG has written voicing its concerns on SOPA and PIPA. http://www.maawg.org/sites/maawg/files/news/MAAWG_US_Congress_S968-HR3261_Comments_2011-12.pdf Mike ________________________________________ From: Suresh Ramasubramanian [ops.lists at gmail.com] Sent: 14 December 2011 05:12 To: Hal Murray Cc: nanog at nanog.org Subject: Re: EFF call for signatures from Internet engineers against censorship I would strongly suggest that operators work with their legal departments to endorse this paper by Crocker and others. If other ISP organizations (such as say MAAWG) come out with something, other operators could sign on to that as well. The EFF petition has way too much propaganda and far less content than would be entirely productive in a policy discussion. --srs On Wed, Dec 14, 2011 at 12:51 PM, Hal Murray wrote: > > Security and Other Technical Concerns Raised by the > DNS Filtering Requirements in the PROTECT IP Bill > Authors: > Steve Crocker, Shinkuro, Inc. > David Dagon, Georgia Tech > Dan Kaminsky, DKH > Danny McPherson, Verisign, Inc. > Paul Vixie, Internet Systems Consortium -- Suresh Ramasubramanian (ops.lists at gmail.com) From jcurran at arin.net Wed Dec 14 06:18:56 2011 From: jcurran at arin.net (John Curran) Date: Wed, 14 Dec 2011 12:18:56 +0000 Subject: Recognized Address Transfer Facilitators (was: Your Christmas Bonus Has Arrived) In-Reply-To: <217E1C9B-EC83-4801-BBD8-60C7777A0814@ianai.net> References: <4EE814F9.8000409@mt.au.com> <217E1C9B-EC83-4801-BBD8-60C7777A0814@ianai.net> Message-ID: <131B2DA4-7C99-4DB8-924A-EBCB27EF9BF0@arin.net> On Dec 14, 2011, at 12:40 AM, Patrick W. Gilmore wrote: > I believe this company is the one that sold the MS & Borders blocks, so they may be "legit" (whatever that means in this context). I also do not know what "legit" means in this context, but will note that we have added a public list of all recognized specified transfer facilitators to the ARIN web site: Facilitators are aware of ARIN's address transfer policies and agree to comply with same. Note that any qualifying parties may transfer space in compliance with policy, but folks may find it easier to work with one of these facilitators to find a matching party for transfer. Facilitators may make use of information in the optional Specified Transfer Listing Service (which lists those who have space available or prequalify as a recipient) but not required to do so. Similarly, parties which may have space available for transfer or wish to prequalify in advance to receive address space via transfer may also register in the Specified Transfer Listing Service (STLS). More information is available on the ARIN web site under "IPv4 SPECIFIED TRANSFER OPTIONS" section. FYI (and Happy Holidays :-) /John John Curran President and CEO ARIN From leigh.porter at ukbroadband.com Wed Dec 14 06:30:06 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Wed, 14 Dec 2011 12:30:06 +0000 Subject: Recognized Address Transfer Facilitators (was: Your Christmas Bonus Has Arrived) In-Reply-To: <131B2DA4-7C99-4DB8-924A-EBCB27EF9BF0@arin.net> References: <4EE814F9.8000409@mt.au.com> <217E1C9B-EC83-4801-BBD8-60C7777A0814@ianai.net>, <131B2DA4-7C99-4DB8-924A-EBCB27EF9BF0@arin.net> Message-ID: <8C3137B6-7690-4CF5-85B2-594E450CDB7B@ukbroadband.com> I love the anti v6 stuff on some of their sites! http://www.iptrading.com/news/news.htm -- Leigh On 14 Dec 2011, at 12:21, "John Curran" wrote: > On Dec 14, 2011, at 12:40 AM, Patrick W. Gilmore wrote: > >> I believe this company is the one that sold the MS & Borders blocks, so they may be "legit" (whatever that means in this context). > > I also do not know what "legit" means in this context, but will note > that we have added a public list of all recognized specified transfer > facilitators to the ARIN web site: > > > > Facilitators are aware of ARIN's address transfer policies and agree to > comply with same. Note that any qualifying parties may transfer space in > compliance with policy, but folks may find it easier to work with one of > these facilitators to find a matching party for transfer. Facilitators may > make use of information in the optional Specified Transfer Listing Service > (which lists those who have space available or prequalify as a recipient) > but not required to do so. Similarly, parties which may have space available > for transfer or wish to prequalify in advance to receive address space via > transfer may also register in the Specified Transfer Listing Service (STLS). > More information is available on the ARIN web site under > "IPv4 SPECIFIED TRANSFER OPTIONS" section. > > FYI (and Happy Holidays :-) > /John > > John Curran > President and CEO > ARIN > > > > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From ops.lists at gmail.com Wed Dec 14 06:31:06 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 14 Dec 2011 18:01:06 +0530 Subject: EFF call for signatures from Internet engineers against censorship In-Reply-To: References: <20111214072119.81F79800037@ip-64-139-1-69.sjc.megapath.net> Message-ID: Wonderful. I would urge SPs based stateside to strongly consider endorsing the MAAWG comments. thanks suresh On Wed, Dec 14, 2011 at 5:06 PM, O'Reirdan, Michael wrote: > MAAWG has written voicing its concerns on SOPA and PIPA. > > http://www.maawg.org/sites/maawg/files/news/MAAWG_US_Congress_S968-HR3261_Comments_2011-12.pdf > > Mike > ________________________________________ > From: Suresh Ramasubramanian [ops.lists at gmail.com] > Sent: 14 December 2011 05:12 > To: Hal Murray > Cc: nanog at nanog.org > Subject: Re: EFF call for signatures from Internet engineers against censorship > > I would strongly suggest that operators work with their legal > departments to endorse this paper by Crocker and others. > > If other ISP organizations (such as say MAAWG) come out with > something, other operators could sign on to that as well. > > The EFF petition has way too much propaganda and far less content than > would be entirely productive in a policy discussion. > > --srs > > > On Wed, Dec 14, 2011 at 12:51 PM, Hal Murray wrote: >> >> ?Security and Other Technical Concerns Raised by the >> ? ?DNS Filtering Requirements in the PROTECT IP Bill >> ?Authors: >> ? ?Steve Crocker, Shinkuro, Inc. >> ? ?David Dagon, Georgia Tech >> ? ?Dan Kaminsky, DKH >> ? ?Danny McPherson, Verisign, Inc. >> ? ?Paul Vixie, Internet Systems Consortium > > > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) > -- Suresh Ramasubramanian (ops.lists at gmail.com) From bmanning at vacation.karoshi.com Wed Dec 14 08:10:52 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 14 Dec 2011 14:10:52 +0000 Subject: Your Christmas Bonus Has Arrived In-Reply-To: <1689b1b1-9c0c-4d7d-b1d4-4c533bfe5144@email.android.com> References: <1689b1b1-9c0c-4d7d-b1d4-4c533bfe5144@email.android.com> Message-ID: <20111214141052.GA7933@vacation.karoshi.com.> On Tue, Dec 13, 2011 at 10:07:44PM -0800, Chaim Rieger wrote: > What do you have for those that don't do the whole Jesus thing ? babalyonian fertility icons? (you -did- bring an evergreen tree into your home, yes?) /bill From streiner at cluebyfour.org Wed Dec 14 08:16:27 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 14 Dec 2011 09:16:27 -0500 (EST) Subject: Recognized Address Transfer Facilitators (was: Your Christmas Bonus Has Arrived) In-Reply-To: <8C3137B6-7690-4CF5-85B2-594E450CDB7B@ukbroadband.com> References: <4EE814F9.8000409@mt.au.com> <217E1C9B-EC83-4801-BBD8-60C7777A0814@ianai.net>, <131B2DA4-7C99-4DB8-924A-EBCB27EF9BF0@arin.net> <8C3137B6-7690-4CF5-85B2-594E450CDB7B@ukbroadband.com> Message-ID: On Wed, 14 Dec 2011, Leigh Porter wrote: > I love the anti v6 stuff on some of their sites! > > http://www.iptrading.com/news/news.htm Some of which seems to float between fear-mongering, possibly mis-appropriated quotes, half-truths and information that is flat-out wrong. I would not trust the judgment and opinions of someone who even admitted in one of their blog posts that they had "no hands-on Service Provider IPv6 experience." While I can understand why IPv4 address brokers would take a decidedly anti-IPv6 stance (deploying IPv6 cuts into their potential business), that doesn't make it any less underhanded. jms From mtinka at globaltransit.net Wed Dec 14 08:18:41 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Wed, 14 Dec 2011 22:18:41 +0800 Subject: Recognized Address Transfer Facilitators (was: Your Christmas Bonus Has Arrived) In-Reply-To: <8C3137B6-7690-4CF5-85B2-594E450CDB7B@ukbroadband.com> References: <131B2DA4-7C99-4DB8-924A-EBCB27EF9BF0@arin.net> <8C3137B6-7690-4CF5-85B2-594E450CDB7B@ukbroadband.com> Message-ID: <201112142218.42329.mtinka@globaltransit.net> On Wednesday, December 14, 2011 08:30:06 PM Leigh Porter wrote: > I love the anti v6 stuff on some of their sites! > > http://www.iptrading.com/news/news.htm I'd have been more impressed if they actually came up with the stories by themselves, as opposed to linking to existing stories that their link titles take out of context. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From dholmes at mwdh2o.com Wed Dec 14 13:07:04 2011 From: dholmes at mwdh2o.com (Holmes,David A) Date: Wed, 14 Dec 2011 11:07:04 -0800 Subject: Multiple ISP Load Balancing Message-ID: <922ACC42D498884AA02B3565688AF9953402D4EF13@USEXMBS01.mwd.h2o> >From time to time some have posted questions asking if BGP load balancers such as the old Routescience Pathcontrol device are still around, and if not what have others found to replace that function. I have used the Routescience device with much success 10 years ago when it first came on the market, but since then a full BGP feed has become much larger, Routescience has been bought by Avaya, then discontinued, and other competitors such as Sockeye, Netvmg have been acquired by other companies. Doing some research on how load balancing can be accomplished in 2011, I have come across Cisco's performance routing feature, and features from load balancing companies such as F5's Link Controller. I have always found BGP to be easy to work with, and an elegant, simple solution to load balancing using a route-reflector configuration in which one BGP client (Routescience Pathcontrol in my background) learns the best route to destination networks, and then announces that best route to BGP border routers using common and widely understood BGP concepts such as communities and local pref, and found this to lead to a deterministic Internet routing architecture. This required a knowledge only of IETF standards (common BGP concepts and configurations), required no specialized scripting, or any other knowledge lying outside IETF boundaries, and it seemed reasonable to expect that network engineers should eagerly and enthusiastically want to master this technology, just as any other technology must be mastered to run high availability networks. So I am wondering if anyone has experience with implementing load balancing across multiple ISP links in 2011, and if there have been any comparisons between IETF standards-based methods using BGP, and other proprietary methods which may use a particular vendor's approach to solving the same problem, but involves some complexity with more variables to be plugged in to the architecture. David ________________________________ This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system. From drew.weaver at thenap.com Wed Dec 14 13:28:34 2011 From: drew.weaver at thenap.com (Drew Weaver) Date: Wed, 14 Dec 2011 14:28:34 -0500 Subject: Multiple ISP Load Balancing In-Reply-To: <922ACC42D498884AA02B3565688AF9953402D4EF13@USEXMBS01.mwd.h2o> References: <922ACC42D498884AA02B3565688AF9953402D4EF13@USEXMBS01.mwd.h2o> Message-ID: I've asked several times about this in the past; although I learned quickly to stop asking. It seems that the consensus has generally been that the best way to handle traffic engineering in networks where you have multiple full-feed up-streams is to do it manually (i.e. set preference for your top N AS/prefix destinations) or don't do it at all (let BGP figure it out..?). Suggesting that a "route optimization system" has any value generally makes people cranky. Thanks, -Drew -----Original Message----- From: Holmes,David A [mailto:dholmes at mwdh2o.com] Sent: Wednesday, December 14, 2011 2:07 PM To: nanog at nanog.org Subject: Multiple ISP Load Balancing >From time to time some have posted questions asking if BGP load balancers such as the old Routescience Pathcontrol device are still around, and if not what have others found to replace that function. I have used the Routescience device with much success 10 years ago when it first came on the market, but since then a full BGP feed has become much larger, Routescience has been bought by Avaya, then discontinued, and other competitors such as Sockeye, Netvmg have been acquired by other companies. Doing some research on how load balancing can be accomplished in 2011, I have come across Cisco's performance routing feature, and features from load balancing companies such as F5's Link Controller. I have always found BGP to be easy to work with, and an elegant, simple solution to load balancing using a route-reflector configuration in which one BGP client (Routescience Pathcontrol in my background) learns the best route to destination networks, and then announces that best route to BGP border routers using common and widely understood BGP concepts such as communities and local pref, and found this to lead to a deterministic Internet routing architecture. This required a knowledge only of IETF standards (common BGP concepts and configurations), required no specialized scripting, or any other knowledge lying outside IETF boundaries, and it seemed reasonable to expect that network engineers should eagerly and enthusiastically want to master this technology, just as any other technology must be mastered to run high availability networks. So I am wondering if anyone has experience with implementing load balancing across multiple ISP links in 2011, and if there have been any comparisons between IETF standards-based methods using BGP, and other proprietary methods which may use a particular vendor's approach to solving the same problem, but involves some complexity with more variables to be plugged in to the architecture. David ________________________________ This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system. From morrowc.lists at gmail.com Wed Dec 14 13:34:46 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 14 Dec 2011 14:34:46 -0500 Subject: Multiple ISP Load Balancing In-Reply-To: References: <922ACC42D498884AA02B3565688AF9953402D4EF13@USEXMBS01.mwd.h2o> Message-ID: On Wed, Dec 14, 2011 at 2:28 PM, Drew Weaver wrote: > I've asked several times about this in the past; although I learned quickly to stop asking. > > It seems that the consensus has generally been that the best way to handle traffic engineering in networks where you have multiple full-feed up-streams is to do it manually (i.e. set preference for your top N AS/prefix destinations) or don't do it at all (let BGP figure it out..?). > seems the feeling is that if you have multiple full feeds and need to loadshare, you really don't want (in most cases) ispa=500mbps + ispb=500mbps. you really want destinationA to be reached across the 'best path' (best ... in some form, distance? packetdrop%? jitter? cost?) you'll most likely have to tweak things in order to achieve what you want since only distance is really used in the stock bgp calculation (distance by as-hops, presuming you don't listen to closely to med from your providers) > Suggesting that a "route optimization system" has any value generally makes people cranky. > ha! :) -chris > Thanks, > -Drew > > -----Original Message----- > From: Holmes,David A [mailto:dholmes at mwdh2o.com] > Sent: Wednesday, December 14, 2011 2:07 PM > To: nanog at nanog.org > Subject: Multiple ISP Load Balancing > > From time to time some have posted questions asking if BGP load balancers such as the old Routescience Pathcontrol device are still around, and if not what have others found to replace that function. I have used the Routescience device with much success 10 years ago when it first came on the market, but since then a full BGP feed has become much larger, Routescience has been bought by Avaya, then discontinued, and other competitors such as Sockeye, Netvmg have been acquired by other companies. > > Doing some research on how load balancing can be accomplished in 2011, I have come across Cisco's performance routing feature, and features from load balancing companies such as F5's Link Controller. I have always found BGP to be easy to work with, and an elegant, simple solution to load balancing using a route-reflector configuration in which one BGP client (Routescience Pathcontrol in my background) learns the best route to destination networks, and then announces that best route to BGP border routers using common and widely understood BGP concepts such as communities and local pref, and found this to lead to a deterministic Internet routing architecture. This required a knowledge only of IETF standards (common BGP concepts and configurations), required no specialized scripting, or any other knowledge lying outside IETF boundaries, and it seemed reasonable to expect that network engineers should eagerly and enthusiastically want to master this technology, just as any other technology must be mastered to run high availability networks. > > So I am wondering if anyone has experience with implementing load balancing across multiple ISP links in 2011, and if there have been any comparisons between IETF standards-based methods using BGP, and other proprietary methods which may use a particular vendor's approach to solving the same problem, but involves some complexity with more variables to be plugged in to the architecture. > > David > > > > ?________________________________ > This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system. > From orothschild at gmail.com Wed Dec 14 13:34:56 2011 From: orothschild at gmail.com (oliver rothschild) Date: Wed, 14 Dec 2011 14:34:56 -0500 Subject: NANOG Digest, Vol 47, Issue 56 In-Reply-To: References: Message-ID: This is my first e-mail to the list and I hope it is not entirely inappropriate. We are attempting to use Juniper single-mode SFPs (LX variety) across multi-mode fiber. Standard listed distance is always for SFPs using the appropriate type of fiber. Does anyone out there know how much distance we are likely to get? Thanks for your help in advance. On Wed, Dec 14, 2011 at 2:07 PM, wrote: > Send NANOG mailing list submissions to > ? ? ? ?nanog at nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > ? ? ? ?https://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > ? ? ? ?nanog-request at nanog.org > > You can reach the person managing the list at > ? ? ? ?nanog-owner at nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > ? 1. Re: EFF call for signatures from Internet engineers against > ? ? ?censorship (Suresh Ramasubramanian) > ? 2. RE: EFF call for signatures from Internet engineers against > ? ? ?censorship (O'Reirdan, Michael) > ? 3. Recognized Address Transfer Facilitators (was: Your Christmas > ? ? ?Bonus Has Arrived) (John Curran) > ? 4. Re: Recognized Address Transfer Facilitators (was: Your > ? ? ?Christmas Bonus Has Arrived) (Leigh Porter) > ? 5. Re: EFF call for signatures from Internet engineers against > ? ? ?censorship (Suresh Ramasubramanian) > ? 6. Re: Your Christmas Bonus Has Arrived > ? ? ?(bmanning at vacation.karoshi.com) > ? 7. Re: Recognized Address Transfer Facilitators (was: Your > ? ? ?Christmas Bonus Has Arrived) (Justin M. Streiner) > ? 8. Re: Recognized Address Transfer Facilitators (was: Your > ? ? ?Christmas Bonus Has Arrived) (Mark Tinka) > ? 9. Multiple ISP Load Balancing (Holmes,David A) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 14 Dec 2011 15:42:51 +0530 > From: Suresh Ramasubramanian > To: Hal Murray > Cc: nanog at nanog.org > Subject: Re: EFF call for signatures from Internet engineers against > ? ? ? ?censorship > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=UTF-8 > > I would strongly suggest that operators work with their legal > departments to endorse this paper by Crocker and others. > > If other ISP organizations (such as say MAAWG) come out with > something, other operators could sign on to that as well. > > The EFF petition has way too much propaganda and far less content than > would be entirely productive in a policy discussion. > > --srs > > > On Wed, Dec 14, 2011 at 12:51 PM, Hal Murray wrote: >> >> ?Security and Other Technical Concerns Raised by the >> ? ?DNS Filtering Requirements in the PROTECT IP Bill >> ?Authors: >> ? ?Steve Crocker, Shinkuro, Inc. >> ? ?David Dagon, Georgia Tech >> ? ?Dan Kaminsky, DKH >> ? ?Danny McPherson, Verisign, Inc. >> ? ?Paul Vixie, Internet Systems Consortium > > > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) > > > > ------------------------------ > > Message: 2 > Date: Wed, 14 Dec 2011 11:36:59 +0000 > From: "O'Reirdan, Michael" > To: Suresh Ramasubramanian , Hal Murray > ? ? ? ? > Cc: "nanog at nanog.org" > Subject: RE: EFF call for signatures from Internet engineers against > ? ? ? ?censorship > Message-ID: > ? ? ? ? > > Content-Type: text/plain; charset="us-ascii" > > MAAWG has written voicing its concerns on SOPA and PIPA. > > http://www.maawg.org/sites/maawg/files/news/MAAWG_US_Congress_S968-HR3261_Comments_2011-12.pdf > > Mike > ________________________________________ > From: Suresh Ramasubramanian [ops.lists at gmail.com] > Sent: 14 December 2011 05:12 > To: Hal Murray > Cc: nanog at nanog.org > Subject: Re: EFF call for signatures from Internet engineers against censorship > > I would strongly suggest that operators work with their legal > departments to endorse this paper by Crocker and others. > > If other ISP organizations (such as say MAAWG) come out with > something, other operators could sign on to that as well. > > The EFF petition has way too much propaganda and far less content than > would be entirely productive in a policy discussion. > > --srs > > > On Wed, Dec 14, 2011 at 12:51 PM, Hal Murray wrote: >> >> ?Security and Other Technical Concerns Raised by the >> ? ?DNS Filtering Requirements in the PROTECT IP Bill >> ?Authors: >> ? ?Steve Crocker, Shinkuro, Inc. >> ? ?David Dagon, Georgia Tech >> ? ?Dan Kaminsky, DKH >> ? ?Danny McPherson, Verisign, Inc. >> ? ?Paul Vixie, Internet Systems Consortium > > > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) > > > > > ------------------------------ > > Message: 3 > Date: Wed, 14 Dec 2011 12:18:56 +0000 > From: John Curran > To: "Patrick W. Gilmore" > Cc: NANOG list > Subject: Recognized Address Transfer Facilitators (was: Your Christmas > ? ? ? ?Bonus Has Arrived) > Message-ID: <131B2DA4-7C99-4DB8-924A-EBCB27EF9BF0 at arin.net> > Content-Type: text/plain; charset="us-ascii" > > On Dec 14, 2011, at 12:40 AM, Patrick W. Gilmore wrote: > >> I believe this company is the one that sold the MS & Borders blocks, so they may be "legit" (whatever that means in this context). > > I also do not know what "legit" means in this context, but will note > that we have added a public list of all recognized specified transfer > facilitators to the ARIN web site: > > > > Facilitators are aware of ARIN's address transfer policies and agree to > comply with same. ?Note that any qualifying parties may transfer space in > compliance with policy, but folks may find it easier to work with one of > these facilitators to find a matching party for transfer. ?Facilitators may > make use of information in the optional Specified Transfer Listing Service > (which lists those who have space available or prequalify as a recipient) > but not required to do so. ?Similarly, parties which may have space available > for transfer or wish to prequalify in advance to receive address space via > transfer may also register in the Specified Transfer Listing Service (STLS). > More information is available on the ARIN web site under > "IPv4 SPECIFIED TRANSFER OPTIONS" section. > > FYI (and Happy Holidays :-) > /John > > John Curran > President and CEO > ARIN > > > > > > ------------------------------ > > Message: 4 > Date: Wed, 14 Dec 2011 12:30:06 +0000 > From: Leigh Porter > To: John Curran > Cc: NANOG list > Subject: Re: Recognized Address Transfer Facilitators (was: Your > ? ? ? ?Christmas Bonus Has Arrived) > Message-ID: <8C3137B6-7690-4CF5-85B2-594E450CDB7B at ukbroadband.com> > Content-Type: text/plain; charset="us-ascii" > > I love the anti v6 stuff on some of their sites! > > http://www.iptrading.com/news/news.htm > > > -- > Leigh > > > On 14 Dec 2011, at 12:21, "John Curran" wrote: > >> On Dec 14, 2011, at 12:40 AM, Patrick W. Gilmore wrote: >> >>> I believe this company is the one that sold the MS & Borders blocks, so they may be "legit" (whatever that means in this context). >> >> I also do not know what "legit" means in this context, but will note >> that we have added a public list of all recognized specified transfer >> facilitators to the ARIN web site: >> >> >> >> Facilitators are aware of ARIN's address transfer policies and agree to >> comply with same. ?Note that any qualifying parties may transfer space in >> compliance with policy, but folks may find it easier to work with one of >> these facilitators to find a matching party for transfer. ?Facilitators may >> make use of information in the optional Specified Transfer Listing Service >> (which lists those who have space available or prequalify as a recipient) >> but not required to do so. ?Similarly, parties which may have space available >> for transfer or wish to prequalify in advance to receive address space via >> transfer may also register in the Specified Transfer Listing Service (STLS). >> More information is available on the ARIN web site under >> "IPv4 SPECIFIED TRANSFER OPTIONS" section. >> >> FYI (and Happy Holidays :-) >> /John >> >> John Curran >> President and CEO >> ARIN >> >> >> >> >> ______________________________________________________________________ >> This email has been scanned by the Symantec Email Security.cloud service. >> For more information please visit http://www.symanteccloud.com >> ______________________________________________________________________ > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ > > > > ------------------------------ > > Message: 5 > Date: Wed, 14 Dec 2011 18:01:06 +0530 > From: Suresh Ramasubramanian > To: "O'Reirdan, Michael" > Cc: "nanog at nanog.org" , Hal Murray > ? ? ? ? > Subject: Re: EFF call for signatures from Internet engineers against > ? ? ? ?censorship > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=UTF-8 > > Wonderful. ?I would urge SPs based stateside to strongly consider > endorsing the MAAWG comments. > > thanks > suresh > > On Wed, Dec 14, 2011 at 5:06 PM, O'Reirdan, Michael > wrote: >> MAAWG has written voicing its concerns on SOPA and PIPA. >> >> http://www.maawg.org/sites/maawg/files/news/MAAWG_US_Congress_S968-HR3261_Comments_2011-12.pdf >> >> Mike >> ________________________________________ >> From: Suresh Ramasubramanian [ops.lists at gmail.com] >> Sent: 14 December 2011 05:12 >> To: Hal Murray >> Cc: nanog at nanog.org >> Subject: Re: EFF call for signatures from Internet engineers against censorship >> >> I would strongly suggest that operators work with their legal >> departments to endorse this paper by Crocker and others. >> >> If other ISP organizations (such as say MAAWG) come out with >> something, other operators could sign on to that as well. >> >> The EFF petition has way too much propaganda and far less content than >> would be entirely productive in a policy discussion. >> >> --srs >> >> >> On Wed, Dec 14, 2011 at 12:51 PM, Hal Murray wrote: >>> >>> ?Security and Other Technical Concerns Raised by the >>> ? ?DNS Filtering Requirements in the PROTECT IP Bill >>> ?Authors: >>> ? ?Steve Crocker, Shinkuro, Inc. >>> ? ?David Dagon, Georgia Tech >>> ? ?Dan Kaminsky, DKH >>> ? ?Danny McPherson, Verisign, Inc. >>> ? ?Paul Vixie, Internet Systems Consortium >> >> >> >> -- >> Suresh Ramasubramanian (ops.lists at gmail.com) >> > > > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) > > > > ------------------------------ > > Message: 6 > Date: Wed, 14 Dec 2011 14:10:52 +0000 > From: bmanning at vacation.karoshi.com > To: Chaim Rieger > Cc: nanog at nanog.org > Subject: Re: Your Christmas Bonus Has Arrived > Message-ID: <20111214141052.GA7933 at vacation.karoshi.com.> > Content-Type: text/plain; charset=us-ascii > > On Tue, Dec 13, 2011 at 10:07:44PM -0800, Chaim Rieger wrote: >> What do you have for those that don't do the whole Jesus thing ? > > babalyonian fertility icons? ?(you -did- bring an evergreen tree into your > home, yes?) > > /bill > > > > ------------------------------ > > Message: 7 > Date: Wed, 14 Dec 2011 09:16:27 -0500 (EST) > From: "Justin M. Streiner" > To: NANOG list > Subject: Re: Recognized Address Transfer Facilitators (was: Your > ? ? ? ?Christmas Bonus Has Arrived) > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Wed, 14 Dec 2011, Leigh Porter wrote: > >> I love the anti v6 stuff on some of their sites! >> >> http://www.iptrading.com/news/news.htm > > Some of which seems to float between fear-mongering, possibly > mis-appropriated quotes, half-truths and information that is flat-out > wrong. ?I would not trust the judgment and opinions of someone who even > admitted in one of their blog posts that they had "no hands-on Service > Provider IPv6 experience." > > While I can understand why IPv4 address brokers would take a decidedly > anti-IPv6 stance (deploying IPv6 cuts into their potential business), that > doesn't make it any less underhanded. > > jms > > > > ------------------------------ > > Message: 8 > Date: Wed, 14 Dec 2011 22:18:41 +0800 > From: Mark Tinka > To: nanog at nanog.org > Cc: John Curran > Subject: Re: Recognized Address Transfer Facilitators (was: Your > ? ? ? ?Christmas Bonus Has Arrived) > Message-ID: <201112142218.42329.mtinka at globaltransit.net> > Content-Type: text/plain; charset="us-ascii" > > On Wednesday, December 14, 2011 08:30:06 PM Leigh Porter > wrote: > >> I love the anti v6 stuff on some of their sites! >> >> http://www.iptrading.com/news/news.htm > > I'd have been more impressed if they actually came up with > the stories by themselves, as opposed to linking to existing > stories that their link titles take out of context. > > Mark. > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 836 bytes > Desc: This is a digitally signed message part. > URL: > > ------------------------------ > > Message: 9 > Date: Wed, 14 Dec 2011 11:07:04 -0800 > From: "Holmes,David A" > To: "nanog at nanog.org" > Subject: Multiple ISP Load Balancing > Message-ID: > ? ? ? ?<922ACC42D498884AA02B3565688AF9953402D4EF13 at USEXMBS01.mwd.h2o> > Content-Type: text/plain; charset="us-ascii" > > >From time to time some have posted questions asking if BGP load balancers such as the old Routescience Pathcontrol device are still around, and if not what have others found to replace that function. I have used the Routescience device with much success 10 years ago when it first came on the market, but since then a full BGP feed has become much larger, Routescience has been bought by Avaya, then discontinued, and other competitors such as Sockeye, Netvmg have been acquired by other companies. > > Doing some research on how load balancing can be accomplished in 2011, I have come across Cisco's performance routing feature, and features from load balancing companies such as F5's Link Controller. I have always found BGP to be easy to work with, and an elegant, simple solution to load balancing using a route-reflector configuration in which one BGP client (Routescience Pathcontrol in my background) learns the best route to destination networks, and then announces that best route to BGP border routers using common and widely understood BGP concepts such as communities and local pref, and found this to lead to a deterministic Internet routing architecture. This required a knowledge only of IETF standards (common BGP concepts and configurations), required no specialized scripting, or any other knowledge lying outside IETF boundaries, and it seemed reasonable to expect that network engineers should eagerly and enthusiastically want to master this technology, just as any other technology must be mastered to run high availability networks. > > So I am wondering if anyone has experience with implementing load balancing across multiple ISP links in 2011, and if there have been any comparisons between IETF standards-based methods using BGP, and other proprietary methods which may use a particular vendor's approach to solving the same problem, but involves some complexity with more variables to be plugged in to the architecture. > > David > > > > ?________________________________ > This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system. > > > End of NANOG Digest, Vol 47, Issue 56 > ************************************* From jeff.tantsura at ericsson.com Wed Dec 14 13:38:10 2011 From: jeff.tantsura at ericsson.com (Jeff Tantsura) Date: Wed, 14 Dec 2011 14:38:10 -0500 Subject: Multiple ISP Load Balancing In-Reply-To: <922ACC42D498884AA02B3565688AF9953402D4EF13@USEXMBS01.mwd.h2o> References: <922ACC42D498884AA02B3565688AF9953402D4EF13@USEXMBS01.mwd.h2o> Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF6181C480943@EUSAACMS0701.eamcs.ericsson.se> Hi David, You might want to take a look at work happening in ALTO (http://tools.ietf.org/wg/alto/) Regards, Jeff -----Original Message----- From: Holmes,David A [mailto:dholmes at mwdh2o.com] Sent: Wednesday, December 14, 2011 11:07 AM To: nanog at nanog.org Subject: Multiple ISP Load Balancing >From time to time some have posted questions asking if BGP load balancers such as the old Routescience Pathcontrol device are still around, and if not what have others found to replace that function. I have used the Routescience device with much success 10 years ago when it first came on the market, but since then a full BGP feed has become much larger, Routescience has been bought by Avaya, then discontinued, and other competitors such as Sockeye, Netvmg have been acquired by other companies. Doing some research on how load balancing can be accomplished in 2011, I have come across Cisco's performance routing feature, and features from load balancing companies such as F5's Link Controller. I have always found BGP to be easy to work with, and an elegant, simple solution to load balancing using a route-reflector configuration in which one BGP client (Routescience Pathcontrol in my background) learns the best route to destination networks, and then announces that best route to BGP border routers using common and widely understood BGP concepts such as communities and local pref, and found this to lead to a deterministic Internet routing architecture. This required a knowledge only of IETF standards (common BGP concepts and configurations), required no specialized scripting, or any other knowledge lying outside IETF boundaries, and it seemed reasonable to expect that network engineers should eagerly and enthusiastically want to master this technology, just as any other technology must be mastered to run high availability networks. So I am wondering if anyone has experience with implementing load balancing across multiple ISP links in 2011, and if there have been any comparisons between IETF standards-based methods using BGP, and other proprietary methods which may use a particular vendor's approach to solving the same problem, but involves some complexity with more variables to be plugged in to the architecture. David ________________________________ This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system. From jof at thejof.com Wed Dec 14 13:38:35 2011 From: jof at thejof.com (Jonathan Lassoff) Date: Wed, 14 Dec 2011 11:38:35 -0800 Subject: Multiple ISP Load Balancing In-Reply-To: <922ACC42D498884AA02B3565688AF9953402D4EF13@USEXMBS01.mwd.h2o> References: <922ACC42D498884AA02B3565688AF9953402D4EF13@USEXMBS01.mwd.h2o> Message-ID: The best applications for analyzing paths, that I've seen, have been in-house development projects. So, admittedly, I don't have much experience with commercial products for route optimization. Projects I've seen that analyze "best" paths to Internet destinations via multiple ISPs add instrumentation to content-serving applications to log stream performance details to a database or log collection system along with a timestamp. Another database keeps a periodic log of RIB data that lists the specific next-hops out of the AS. Another log keeps a running log of UPDATEs. >From joining up all of this information, you can figure out the ISP you're taking to a destination (at a given time) and how the stream performed. Then, add some logic to inject routes to try out different next-hop ISPs for some destinations. Then, compare the newer ISP-path to the older one and see which performs "best". Where "best" means something specific to your application (optimizing for latency, cost, etc.) Cheers, jof From drew.weaver at thenap.com Wed Dec 14 13:44:27 2011 From: drew.weaver at thenap.com (Drew Weaver) Date: Wed, 14 Dec 2011 14:44:27 -0500 Subject: Multiple ISP Load Balancing In-Reply-To: References: <922ACC42D498884AA02B3565688AF9953402D4EF13@USEXMBS01.mwd.h2o> Message-ID: >seems the feeling is that if you have multiple full feeds and need to loadshare, you really don't want (in most cases) ispa=500mbps + ispb=500mbps. > > >you really want destinationA to be reached across the 'best path' >(best ... in some form, distance? packetdrop%? jitter? cost?) you'll most likely have to tweak things in order to achieve what you want since only distance is really used in the stock bgp calculation (distance by as-hops, presuming you don't listen to closely to med from your providers) Yes, but performance from your network to $destination_AS via $ISPx can be variable and how do you know when it changes before someone starts complaining? There are traditionally two pieces involved with optimization. 1) "Cost" (Commitment/oversubscribe management and monitoring) 2) "Performance" Usually "cost control" is #1 so systems like that are configured so that as long as the traffic isn't breaking your commits or filling your pipes they will then optimize X number of your top prefixes for performance (based on what the system can see). The performance aspect is generally just sending basic probes in all directions towards a destination host and seeing which ones reply the fastest. Although obviously this only impacts traffic outbound from your AS. -Drew From streiner at cluebyfour.org Wed Dec 14 14:10:10 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 14 Dec 2011 15:10:10 -0500 (EST) Subject: Multiple ISP Load Balancing In-Reply-To: <922ACC42D498884AA02B3565688AF9953402D4EF13@USEXMBS01.mwd.h2o> References: <922ACC42D498884AA02B3565688AF9953402D4EF13@USEXMBS01.mwd.h2o> Message-ID: On Wed, 14 Dec 2011, Holmes,David A wrote: > From time to time some have posted questions asking if BGP load > balancers such as the old Routescience Pathcontrol device are still > around, and if not what have others found to replace that function. I > have used the Routescience device with much success 10 years ago when it > first came on the market, but since then a full BGP feed has become much > larger, Routescience has been bought by Avaya, then discontinued, and > other competitors such as Sockeye, Netvmg have been acquired by other > companies. It's important to keep in mind what load-balancing is and isn't in this case. The terminology gap can be important because load-balancing (more accurately, load-sharing) in the context of internetwork traffic engineering is very different from load-balancing pools of servers in a data center. Some people can (and sometimes do) confuse the two, which can cause unrealistic expectations to be set :) Achieving a perfect split of network traffic across two or more upstream links rarely happens in the real world. General good practice is to put bandwidth where the network traffic wants to go, but that can be a moving target, and executives and accountants don't like those :) Traffic engineering still has a place on many networks, for a veriety of reasons (technical, financial, political, some combination of these), but as other posters have mentioned, it's often done manually, i.e. looking at Netflow reports, seeing where your traffic is going/coming from, adjusting BGP policies accordingly. Repeat as needed. Since traffic profiles can change over time, any policy tweaks that are put in place need to be reviewed periodically. Depending on how much prep work and planning you're willing to do, you can put a fairly rich set of internal BGP communities in place to control things like localpref, MEDs, selective prepends, and tagging outbound advertisements with provider-specific communities. With that kind of structure, you could control many aspects of your traffic engineering from a route server, rather than having to tinker with route policies on each outside-facing router. One caveat: If your route server crashes or has to be taken down for maintenance, the traffic patterns that were being tweaked by your policy framework could start to revert to the way the traffic would flow in its un-altered state, which could cause you some unintended headaches. jms From marshall.eubanks at gmail.com Wed Dec 14 14:15:53 2011 From: marshall.eubanks at gmail.com (Marshall Eubanks) Date: Wed, 14 Dec 2011 15:15:53 -0500 Subject: Range using single-mode SFPs across multi-mode fiber - was Re: NANOG Digest, Vol 47, Issue 56 Message-ID: On Wed, Dec 14, 2011 at 2:34 PM, oliver rothschild wrote: > This is my first e-mail to the list and I hope it is not entirely As a suggestion, could you please in the future not use a subject such as "Re: NANOG Digest, Vol 47, Issue 56" for posts. It is MUCH better to use a topical subject line (see my suggestion above); that helps people who filter their mail keep track of threads and topics. Regards Marshall > inappropriate. We are attempting to use Juniper single-mode SFPs (LX > variety) across multi-mode fiber. Standard listed distance is always > for SFPs using the appropriate type of fiber. Does anyone out there > know how much distance we are likely to get? Thanks for your help in > advance. > > On Wed, Dec 14, 2011 at 2:07 PM, ? wrote: >> Send NANOG mailing list submissions to >> ? ? ? ?nanog at nanog.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> ? ? ? ?https://mailman.nanog.org/mailman/listinfo/nanog >> or, via email, send a message with subject or body 'help' to >> ? ? ? ?nanog-request at nanog.org >> >> You can reach the person managing the list at >> ? ? ? ?nanog-owner at nanog.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of NANOG digest..." >> >> >> Today's Topics: >> >> ? 1. Re: EFF call for signatures from Internet engineers against >> ? ? ?censorship (Suresh Ramasubramanian) >> ? 2. RE: EFF call for signatures from Internet engineers against >> ? ? ?censorship (O'Reirdan, Michael) >> ? 3. Recognized Address Transfer Facilitators (was: Your Christmas >> ? ? ?Bonus Has Arrived) (John Curran) >> ? 4. Re: Recognized Address Transfer Facilitators (was: Your >> ? ? ?Christmas Bonus Has Arrived) (Leigh Porter) >> ? 5. Re: EFF call for signatures from Internet engineers against >> ? ? ?censorship (Suresh Ramasubramanian) >> ? 6. Re: Your Christmas Bonus Has Arrived >> ? ? ?(bmanning at vacation.karoshi.com) >> ? 7. Re: Recognized Address Transfer Facilitators (was: Your >> ? ? ?Christmas Bonus Has Arrived) (Justin M. Streiner) >> ? 8. Re: Recognized Address Transfer Facilitators (was: Your >> ? ? ?Christmas Bonus Has Arrived) (Mark Tinka) >> ? 9. Multiple ISP Load Balancing (Holmes,David A) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Wed, 14 Dec 2011 15:42:51 +0530 >> From: Suresh Ramasubramanian >> To: Hal Murray >> Cc: nanog at nanog.org >> Subject: Re: EFF call for signatures from Internet engineers against >> ? ? ? ?censorship >> Message-ID: >> ? ? ? ? >> Content-Type: text/plain; charset=UTF-8 >> >> I would strongly suggest that operators work with their legal >> departments to endorse this paper by Crocker and others. >> >> If other ISP organizations (such as say MAAWG) come out with >> something, other operators could sign on to that as well. >> >> The EFF petition has way too much propaganda and far less content than >> would be entirely productive in a policy discussion. >> >> --srs >> >> >> On Wed, Dec 14, 2011 at 12:51 PM, Hal Murray wrote: >>> >>> ?Security and Other Technical Concerns Raised by the >>> ? ?DNS Filtering Requirements in the PROTECT IP Bill >>> ?Authors: >>> ? ?Steve Crocker, Shinkuro, Inc. >>> ? ?David Dagon, Georgia Tech >>> ? ?Dan Kaminsky, DKH >>> ? ?Danny McPherson, Verisign, Inc. >>> ? ?Paul Vixie, Internet Systems Consortium >> >> >> >> -- >> Suresh Ramasubramanian (ops.lists at gmail.com) >> >> >> >> ------------------------------ >> >> Message: 2 >> Date: Wed, 14 Dec 2011 11:36:59 +0000 >> From: "O'Reirdan, Michael" >> To: Suresh Ramasubramanian , Hal Murray >> ? ? ? ? >> Cc: "nanog at nanog.org" >> Subject: RE: EFF call for signatures from Internet engineers against >> ? ? ? ?censorship >> Message-ID: >> ? ? ? ? >> >> Content-Type: text/plain; charset="us-ascii" >> >> MAAWG has written voicing its concerns on SOPA and PIPA. >> >> http://www.maawg.org/sites/maawg/files/news/MAAWG_US_Congress_S968-HR3261_Comments_2011-12.pdf >> >> Mike >> ________________________________________ >> From: Suresh Ramasubramanian [ops.lists at gmail.com] >> Sent: 14 December 2011 05:12 >> To: Hal Murray >> Cc: nanog at nanog.org >> Subject: Re: EFF call for signatures from Internet engineers against censorship >> >> I would strongly suggest that operators work with their legal >> departments to endorse this paper by Crocker and others. >> >> If other ISP organizations (such as say MAAWG) come out with >> something, other operators could sign on to that as well. >> >> The EFF petition has way too much propaganda and far less content than >> would be entirely productive in a policy discussion. >> >> --srs >> >> >> On Wed, Dec 14, 2011 at 12:51 PM, Hal Murray wrote: >>> >>> ?Security and Other Technical Concerns Raised by the >>> ? ?DNS Filtering Requirements in the PROTECT IP Bill >>> ?Authors: >>> ? ?Steve Crocker, Shinkuro, Inc. >>> ? ?David Dagon, Georgia Tech >>> ? ?Dan Kaminsky, DKH >>> ? ?Danny McPherson, Verisign, Inc. >>> ? ?Paul Vixie, Internet Systems Consortium >> >> >> >> -- >> Suresh Ramasubramanian (ops.lists at gmail.com) >> >> >> >> >> ------------------------------ >> >> Message: 3 >> Date: Wed, 14 Dec 2011 12:18:56 +0000 >> From: John Curran >> To: "Patrick W. Gilmore" >> Cc: NANOG list >> Subject: Recognized Address Transfer Facilitators (was: Your Christmas >> ? ? ? ?Bonus Has Arrived) >> Message-ID: <131B2DA4-7C99-4DB8-924A-EBCB27EF9BF0 at arin.net> >> Content-Type: text/plain; charset="us-ascii" >> >> On Dec 14, 2011, at 12:40 AM, Patrick W. Gilmore wrote: >> >>> I believe this company is the one that sold the MS & Borders blocks, so they may be "legit" (whatever that means in this context). >> >> I also do not know what "legit" means in this context, but will note >> that we have added a public list of all recognized specified transfer >> facilitators to the ARIN web site: >> >> >> >> Facilitators are aware of ARIN's address transfer policies and agree to >> comply with same. ?Note that any qualifying parties may transfer space in >> compliance with policy, but folks may find it easier to work with one of >> these facilitators to find a matching party for transfer. ?Facilitators may >> make use of information in the optional Specified Transfer Listing Service >> (which lists those who have space available or prequalify as a recipient) >> but not required to do so. ?Similarly, parties which may have space available >> for transfer or wish to prequalify in advance to receive address space via >> transfer may also register in the Specified Transfer Listing Service (STLS). >> More information is available on the ARIN web site under >> "IPv4 SPECIFIED TRANSFER OPTIONS" section. >> >> FYI (and Happy Holidays :-) >> /John >> >> John Curran >> President and CEO >> ARIN >> >> >> >> >> >> ------------------------------ >> >> Message: 4 >> Date: Wed, 14 Dec 2011 12:30:06 +0000 >> From: Leigh Porter >> To: John Curran >> Cc: NANOG list >> Subject: Re: Recognized Address Transfer Facilitators (was: Your >> ? ? ? ?Christmas Bonus Has Arrived) >> Message-ID: <8C3137B6-7690-4CF5-85B2-594E450CDB7B at ukbroadband.com> >> Content-Type: text/plain; charset="us-ascii" >> >> I love the anti v6 stuff on some of their sites! >> >> http://www.iptrading.com/news/news.htm >> >> >> -- >> Leigh >> >> >> On 14 Dec 2011, at 12:21, "John Curran" wrote: >> >>> On Dec 14, 2011, at 12:40 AM, Patrick W. Gilmore wrote: >>> >>>> I believe this company is the one that sold the MS & Borders blocks, so they may be "legit" (whatever that means in this context). >>> >>> I also do not know what "legit" means in this context, but will note >>> that we have added a public list of all recognized specified transfer >>> facilitators to the ARIN web site: >>> >>> >>> >>> Facilitators are aware of ARIN's address transfer policies and agree to >>> comply with same. ?Note that any qualifying parties may transfer space in >>> compliance with policy, but folks may find it easier to work with one of >>> these facilitators to find a matching party for transfer. ?Facilitators may >>> make use of information in the optional Specified Transfer Listing Service >>> (which lists those who have space available or prequalify as a recipient) >>> but not required to do so. ?Similarly, parties which may have space available >>> for transfer or wish to prequalify in advance to receive address space via >>> transfer may also register in the Specified Transfer Listing Service (STLS). >>> More information is available on the ARIN web site under >>> "IPv4 SPECIFIED TRANSFER OPTIONS" section. >>> >>> FYI (and Happy Holidays :-) >>> /John >>> >>> John Curran >>> President and CEO >>> ARIN >>> >>> >>> >>> >>> ______________________________________________________________________ >>> This email has been scanned by the Symantec Email Security.cloud service. >>> For more information please visit http://www.symanteccloud.com >>> ______________________________________________________________________ >> >> ______________________________________________________________________ >> This email has been scanned by the Symantec Email Security.cloud service. >> For more information please visit http://www.symanteccloud.com >> ______________________________________________________________________ >> >> >> >> ------------------------------ >> >> Message: 5 >> Date: Wed, 14 Dec 2011 18:01:06 +0530 >> From: Suresh Ramasubramanian >> To: "O'Reirdan, Michael" >> Cc: "nanog at nanog.org" , Hal Murray >> ? ? ? ? >> Subject: Re: EFF call for signatures from Internet engineers against >> ? ? ? ?censorship >> Message-ID: >> ? ? ? ? >> Content-Type: text/plain; charset=UTF-8 >> >> Wonderful. ?I would urge SPs based stateside to strongly consider >> endorsing the MAAWG comments. >> >> thanks >> suresh >> >> On Wed, Dec 14, 2011 at 5:06 PM, O'Reirdan, Michael >> wrote: >>> MAAWG has written voicing its concerns on SOPA and PIPA. >>> >>> http://www.maawg.org/sites/maawg/files/news/MAAWG_US_Congress_S968-HR3261_Comments_2011-12.pdf >>> >>> Mike >>> ________________________________________ >>> From: Suresh Ramasubramanian [ops.lists at gmail.com] >>> Sent: 14 December 2011 05:12 >>> To: Hal Murray >>> Cc: nanog at nanog.org >>> Subject: Re: EFF call for signatures from Internet engineers against censorship >>> >>> I would strongly suggest that operators work with their legal >>> departments to endorse this paper by Crocker and others. >>> >>> If other ISP organizations (such as say MAAWG) come out with >>> something, other operators could sign on to that as well. >>> >>> The EFF petition has way too much propaganda and far less content than >>> would be entirely productive in a policy discussion. >>> >>> --srs >>> >>> >>> On Wed, Dec 14, 2011 at 12:51 PM, Hal Murray wrote: >>>> >>>> ?Security and Other Technical Concerns Raised by the >>>> ? ?DNS Filtering Requirements in the PROTECT IP Bill >>>> ?Authors: >>>> ? ?Steve Crocker, Shinkuro, Inc. >>>> ? ?David Dagon, Georgia Tech >>>> ? ?Dan Kaminsky, DKH >>>> ? ?Danny McPherson, Verisign, Inc. >>>> ? ?Paul Vixie, Internet Systems Consortium >>> >>> >>> >>> -- >>> Suresh Ramasubramanian (ops.lists at gmail.com) >>> >> >> >> >> -- >> Suresh Ramasubramanian (ops.lists at gmail.com) >> >> >> >> ------------------------------ >> >> Message: 6 >> Date: Wed, 14 Dec 2011 14:10:52 +0000 >> From: bmanning at vacation.karoshi.com >> To: Chaim Rieger >> Cc: nanog at nanog.org >> Subject: Re: Your Christmas Bonus Has Arrived >> Message-ID: <20111214141052.GA7933 at vacation.karoshi.com.> >> Content-Type: text/plain; charset=us-ascii >> >> On Tue, Dec 13, 2011 at 10:07:44PM -0800, Chaim Rieger wrote: >>> What do you have for those that don't do the whole Jesus thing ? >> >> babalyonian fertility icons? ?(you -did- bring an evergreen tree into your >> home, yes?) >> >> /bill >> >> >> >> ------------------------------ >> >> Message: 7 >> Date: Wed, 14 Dec 2011 09:16:27 -0500 (EST) >> From: "Justin M. Streiner" >> To: NANOG list >> Subject: Re: Recognized Address Transfer Facilitators (was: Your >> ? ? ? ?Christmas Bonus Has Arrived) >> Message-ID: >> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> >> On Wed, 14 Dec 2011, Leigh Porter wrote: >> >>> I love the anti v6 stuff on some of their sites! >>> >>> http://www.iptrading.com/news/news.htm >> >> Some of which seems to float between fear-mongering, possibly >> mis-appropriated quotes, half-truths and information that is flat-out >> wrong. ?I would not trust the judgment and opinions of someone who even >> admitted in one of their blog posts that they had "no hands-on Service >> Provider IPv6 experience." >> >> While I can understand why IPv4 address brokers would take a decidedly >> anti-IPv6 stance (deploying IPv6 cuts into their potential business), that >> doesn't make it any less underhanded. >> >> jms >> >> >> >> ------------------------------ >> >> Message: 8 >> Date: Wed, 14 Dec 2011 22:18:41 +0800 >> From: Mark Tinka >> To: nanog at nanog.org >> Cc: John Curran >> Subject: Re: Recognized Address Transfer Facilitators (was: Your >> ? ? ? ?Christmas Bonus Has Arrived) >> Message-ID: <201112142218.42329.mtinka at globaltransit.net> >> Content-Type: text/plain; charset="us-ascii" >> >> On Wednesday, December 14, 2011 08:30:06 PM Leigh Porter >> wrote: >> >>> I love the anti v6 stuff on some of their sites! >>> >>> http://www.iptrading.com/news/news.htm >> >> I'd have been more impressed if they actually came up with >> the stories by themselves, as opposed to linking to existing >> stories that their link titles take out of context. >> >> Mark. >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: signature.asc >> Type: application/pgp-signature >> Size: 836 bytes >> Desc: This is a digitally signed message part. >> URL: >> >> ------------------------------ >> >> Message: 9 >> Date: Wed, 14 Dec 2011 11:07:04 -0800 >> From: "Holmes,David A" >> To: "nanog at nanog.org" >> Subject: Multiple ISP Load Balancing >> Message-ID: >> ? ? ? ?<922ACC42D498884AA02B3565688AF9953402D4EF13 at USEXMBS01.mwd.h2o> >> Content-Type: text/plain; charset="us-ascii" >> >> >From time to time some have posted questions asking if BGP load balancers such as the old Routescience Pathcontrol device are still around, and if not what have others found to replace that function. I have used the Routescience device with much success 10 years ago when it first came on the market, but since then a full BGP feed has become much larger, Routescience has been bought by Avaya, then discontinued, and other competitors such as Sockeye, Netvmg have been acquired by other companies. >> >> Doing some research on how load balancing can be accomplished in 2011, I have come across Cisco's performance routing feature, and features from load balancing companies such as F5's Link Controller. I have always found BGP to be easy to work with, and an elegant, simple solution to load balancing using a route-reflector configuration in which one BGP client (Routescience Pathcontrol in my background) learns the best route to destination networks, and then announces that best route to BGP border routers using common and widely understood BGP concepts such as communities and local pref, and found this to lead to a deterministic Internet routing architecture. This required a knowledge only of IETF standards (common BGP concepts and configurations), required no specialized scripting, or any other knowledge lying outside IETF boundaries, and it seemed reasonable to expect that network engineers should eagerly and enthusiastically want to master this technology, just as any other technology must be mastered to run high availability networks. >> >> So I am wondering if anyone has experience with implementing load balancing across multiple ISP links in 2011, and if there have been any comparisons between IETF standards-based methods using BGP, and other proprietary methods which may use a particular vendor's approach to solving the same problem, but involves some complexity with more variables to be plugged in to the architecture. >> >> David >> >> >> >> ?________________________________ >> This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system. >> >> >> End of NANOG Digest, Vol 47, Issue 56 >> ************************************* > From keegan.holley at sungard.com Wed Dec 14 14:37:07 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Wed, 14 Dec 2011 15:37:07 -0500 Subject: Range using single-mode SFPs across multi-mode fiber - was Re: NANOG Digest, Vol 47, Issue 56 In-Reply-To: References: Message-ID: > > inappropriate. We are attempting to use Juniper single-mode SFPs (LX > > variety) across multi-mode fiber. Standard listed distance is always > > for SFPs using the appropriate type of fiber. Does anyone out there > > know how much distance we are likely to get? Thanks for your help in > > advance. > Single mode just has a smaller core size for the smaller "beam" emitted by laser vs. LED. it works although I've never done it outside of a lab (MM is cheaper). As for the distance it theory that should come down to the optics and your transmit power. Hopefully this is just a cable connecting the router to a long line. I've never heard of a 10K MM fiber run since SX optics can't shoot that far. You should be able to get through the 500m or so that MM optics are rated for, but YMMV (errors, light levels, bounces, etc etc) From jim.rampley at chartercom.com Wed Dec 14 14:42:21 2011 From: jim.rampley at chartercom.com (Rampley Jr, Jim F) Date: Wed, 14 Dec 2011 14:42:21 -0600 Subject: Multiple ISP Load Balancing In-Reply-To: References: <922ACC42D498884AA02B3565688AF9953402D4EF13@USEXMBS01.mwd.h2o> Message-ID: <5D717D6976F4D8498089CBEE22C2EBCD12D78DA6@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM> We have specific situations where we have successfully used the Avaya CNA tool (old Route Science Patch Control). Not for load balancing, but for sub second failover from primary to a backup paths over MPLS VPN's. This is done on our internal network where we have MPLS VPN's sometimes over multiple carriers where normal convergence times are 30 seconds to 1 minute across an external provider. It's not easy to setup initially, but once you get it setup and the kinks worked out I've been impressed with its ability to test a path and move traffic at the first hint of trouble. Jim -----Original Message----- From: Justin M. Streiner [mailto:streiner at cluebyfour.org] Sent: Wednesday, December 14, 2011 2:10 PM To: nanog at nanog.org Subject: Re: Multiple ISP Load Balancing On Wed, 14 Dec 2011, Holmes,David A wrote: > From time to time some have posted questions asking if BGP load > balancers such as the old Routescience Pathcontrol device are still > around, and if not what have others found to replace that function. I > have used the Routescience device with much success 10 years ago when it > first came on the market, but since then a full BGP feed has become much > larger, Routescience has been bought by Avaya, then discontinued, and > other competitors such as Sockeye, Netvmg have been acquired by other > companies. It's important to keep in mind what load-balancing is and isn't in this case. The terminology gap can be important because load-balancing (more accurately, load-sharing) in the context of internetwork traffic engineering is very different from load-balancing pools of servers in a data center. Some people can (and sometimes do) confuse the two, which can cause unrealistic expectations to be set :) Achieving a perfect split of network traffic across two or more upstream links rarely happens in the real world. General good practice is to put bandwidth where the network traffic wants to go, but that can be a moving target, and executives and accountants don't like those :) Traffic engineering still has a place on many networks, for a veriety of reasons (technical, financial, political, some combination of these), but as other posters have mentioned, it's often done manually, i.e. looking at Netflow reports, seeing where your traffic is going/coming from, adjusting BGP policies accordingly. Repeat as needed. Since traffic profiles can change over time, any policy tweaks that are put in place need to be reviewed periodically. Depending on how much prep work and planning you're willing to do, you can put a fairly rich set of internal BGP communities in place to control things like localpref, MEDs, selective prepends, and tagging outbound advertisements with provider-specific communities. With that kind of structure, you could control many aspects of your traffic engineering from a route server, rather than having to tinker with route policies on each outside-facing router. One caveat: If your route server crashes or has to be taken down for maintenance, the traffic patterns that were being tweaked by your policy framework could start to revert to the way the traffic would flow in its un-altered state, which could cause you some unintended headaches. jms E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From mailing-lists at brianraaen.com Wed Dec 14 14:46:52 2011 From: mailing-lists at brianraaen.com (Brian Christopher Raaen) Date: Wed, 14 Dec 2011 15:46:52 -0500 Subject: Time Warner Routing Issue Message-ID: I have a Time Warner circuit that has been giving me issues and what their tech support has been telling me has not matched my previous experience with other backbones. I have been trying to move the backbone on one site from a tier-3 provider to Time Warner. Yesterday TW started advertising BGP for the ip blocks I have (68.68.176.0/22 in /24's) before they had the circuit completed, so I had to make an emergency mid-day switch to move to Time Warner. Then yesterday night they stopped announcing my blocks so my site went down again and would still be completely down if we had not added NAT to the /30 point-to-point link. They said the reason was they didn't have an LOA (which they had gotten back in October) and the ip blocks were not in the Level3 Radb list. I could still see announcement to some peers (Shaw Cable in Canada) in a few looking glasses and BGP routers. However my network blocks were not showing for the larger US carriers like Qwest and AT&T. One of their techs just called me back and said that Level3 should be advertising it, but I still do not see the routes on the AT&T route server. After noting that the tech said that it may take another day for BGP to "propagate" to other peers as they update their radb tables. In my experience I've never seen anything where I had to wait for a route to propagate other than standard routing table updates which usually take less then an hour, and I'd really not expect this many problems between Tier1 and Tier2 providers. I need to know if this matches other's experience and wanting to know what other people were seeing with traceroutes and "show ip bgp". The networks in question at the following 4 /24's 68.68.176.0/24 68.68.177.0/24 68.68.178.0/24 68.68.179.0/24 the serial ip address is 72.43.84.254 Thanks for your assistance. --- Brian Raaen Zcorum Network Architect From jeff-kell at utc.edu Wed Dec 14 14:50:47 2011 From: jeff-kell at utc.edu (Jeff Kell) Date: Wed, 14 Dec 2011 15:50:47 -0500 Subject: Range using single-mode SFPs across multi-mode fiber In-Reply-To: References: Message-ID: <4EE90C27.7030109@utc.edu> On 12/14/2011 3:37 PM, Keegan Holley wrote: > Single mode just has a smaller core size for the smaller "beam" emitted by > laser vs. LED. it works although I've never done it outside of a lab (MM > is cheaper). As for the distance it theory that should come down to the > optics and your transmit power. Hopefully this is just a cable connecting > the router to a long line. I've never heard of a 10K MM fiber run since SX > optics can't shoot that far. You should be able to get through the 500m or > so that MM optics are rated for, but YMMV (errors, light levels, bounces, > etc etc) Cisco gives specs for SFP LX over MM (they aren't that great at gig, and really suck at 10G; if you have 50u OM3/OM4 you can do much better at 10G). See SFP/fiber/distance table at http://www.cisco.com/en/US/prod/collateral/modules/ps5455/ps6577/product_data_sheet0900aecd8033f885.html We have run LX-over-MM (62.5) on short building runs as a band-aid until SM is available, and trying to do all new building MM with 50u OM3/OM4. We do have some dependence on 62.5u MM - used by our aging Simplex alarm system - which does point-to-point looped token ring <*cough*> on the alarm side. I'm trying to get them to confirm 50u will work point-to-point, but at some non-alarm-points there would be a necessary 50-to-62.5 exchange taking place and I'm not certain how to accomplish that (50->62.5 would likely have tolerable loss, but not 62.5->50). (I would suspect similar results cross-vendor but YMMV) Jeff From streiner at cluebyfour.org Wed Dec 14 14:54:47 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 14 Dec 2011 15:54:47 -0500 (EST) Subject: Range using single-mode SFPs across multi-mode fiber - was Re: NANOG Digest, Vol 47, Issue 56 In-Reply-To: References: Message-ID: On Wed, 14 Dec 2011, Keegan Holley wrote: >>> inappropriate. We are attempting to use Juniper single-mode SFPs (LX >>> variety) across multi-mode fiber. Standard listed distance is always >>> for SFPs using the appropriate type of fiber. Does anyone out there >>> know how much distance we are likely to get? Thanks for your help in >>> advance. > Single mode just has a smaller core size for the smaller "beam" emitted by > laser vs. LED. it works although I've never done it outside of a lab (MM > is cheaper). As for the distance it theory that should come down to the > optics and your transmit power. Hopefully this is just a cable connecting > the router to a long line. I've never heard of a 10K MM fiber run since SX > optics can't shoot that far. You should be able to get through the 500m or > so that MM optics are rated for, but YMMV (errors, light levels, bounces, > etc etc) In a nutshell, don't do it if at all possible. This issue gets significantly worse at 10G. If there's any way to get SMF in place for this link, do it. In practice, you will likely get something less than the rated distance, particularly if the MM fiber in question is an older type, such as OM1. If you're using OM1, mode-conditioning jumpers at both ends are pretty much a must. The problems with shooting an LX/LH beam over MMF are threefold: 1. Attenuation on some flavors of MMF can be significantly higher than an equivalent run of SMF. 2. Modal dispersion on MMF will scatter and distort the LX beam, likely resulting in link errors because the receiver can't recover the data correctly. 3. Shooting a 9 micron beam into a 50 (or worse, 62.5) micron core, and getting enough of the beam to reach the 9 micron target at the other end to result in a recoverable signal is problematic. jms From keegan.holley at sungard.com Wed Dec 14 15:04:51 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Wed, 14 Dec 2011 16:04:51 -0500 Subject: Range using single-mode SFPs across multi-mode fiber - was Re: NANOG Digest, Vol 47, Issue 56 In-Reply-To: References: Message-ID: 2011/12/14 Justin M. Streiner > On Wed, 14 Dec 2011, Keegan Holley wrote: > > inappropriate. We are attempting to use Juniper single-mode SFPs (LX >>>> variety) across multi-mode fiber. Standard listed distance is always >>>> for SFPs using the appropriate type of fiber. Does anyone out there >>>> know how much distance we are likely to get? Thanks for your help in >>>> advance. >>>> >>> Single mode just has a smaller core size for the smaller "beam" emitted >> by >> laser vs. LED. it works although I've never done it outside of a lab (MM >> is cheaper). As for the distance it theory that should come down to the >> optics and your transmit power. Hopefully this is just a cable connecting >> the router to a long line. I've never heard of a 10K MM fiber run since >> SX >> optics can't shoot that far. You should be able to get through the 500m >> or >> so that MM optics are rated for, but YMMV (errors, light levels, bounces, >> etc etc) >> > > In a nutshell, don't do it if at all possible. This issue gets > significantly > worse at 10G. If there's any way to get SMF in place for this link, do it. > > +1 probably should have added that. I guess I just assumed. > In practice, you will likely get something less than the rated distance, > particularly if the MM fiber in question is an older type, such as OM1. If > you're using OM1, mode-conditioning jumpers at both ends are pretty much a > must. > > The problems with shooting an LX/LH beam over MMF are threefold: > 1. Attenuation on some flavors of MMF can be significantly higher than an > equivalent run of SMF. > +1 Assumed again.. > 2. Modal dispersion on MMF will scatter and distort the LX beam, likely > resulting in link errors because the receiver can't recover the data > correctly. > Not that I'm advocating this, but it's fine over short distances. I did this for a few lab routers where I wasn't concerned with link quality, but I was able to fill a 10G pipe with no errors/retransmit over about 10M. > 3. Shooting a 9 micron beam into a 50 (or worse, 62.5) micron core, and > getting enough of the beam to reach the 9 micron target at the other end to > result in a recoverable signal is problematic. Again for short distances it's doable. I agree not to even try over 62.5 though. From blakjak at blakjak.net Wed Dec 14 15:06:06 2011 From: blakjak at blakjak.net (Mark Foster) Date: Thu, 15 Dec 2011 10:06:06 +1300 Subject: Range using single-mode SFPs across multi-mode fiber - was Re: NANOG Digest, Vol 47, Issue 56 In-Reply-To: References: Message-ID: <4EE90FBE.2040308@blakjak.net> On 15/12/11 09:54, Justin M. Streiner wrote: > On Wed, 14 Dec 2011, Keegan Holley wrote: > >>>> inappropriate. We are attempting to use Juniper single-mode SFPs (LX >>>> variety) across multi-mode fiber. Standard listed distance is always >>>> for SFPs using the appropriate type of fiber. Does anyone out there >>>> know how much distance we are likely to get? Thanks for your help in >>>> advance. >> Single mode just has a smaller core size for the smaller "beam" >> emitted by >> laser vs. LED. it works although I've never done it outside of a lab >> (MM >> is cheaper). As for the distance it theory that should come down to the >> optics and your transmit power. Hopefully this is just a cable >> connecting >> the router to a long line. I've never heard of a 10K MM fiber run >> since SX >> optics can't shoot that far. You should be able to get through the >> 500m or >> so that MM optics are rated for, but YMMV (errors, light levels, >> bounces, >> etc etc) > > In a nutshell, don't do it if at all possible. This issue gets > significantly > worse at 10G. If there's any way to get SMF in place for this link, > do it. > > In practice, you will likely get something less than the rated > distance, particularly if the MM fiber in question is an older type, > such as OM1. If you're using OM1, mode-conditioning jumpers at both > ends are pretty much a must. I sense confusion in the above. - LX drivers on MM fibre can work with Mode-Conditioning patch leads and can give you significant distance wins, particularly if you're using legacy OM1 Fibre. - SX drivers on SM fibre is not something i've ever seen done, I can't imagine why you'd do it - even if SX drivers are cheaper. > > The problems with shooting an LX/LH beam over MMF are threefold: > 1. Attenuation on some flavors of MMF can be significantly higher than > an equivalent run of SMF. > 2. Modal dispersion on MMF will scatter and distort the LX beam, > likely resulting in link errors because the receiver can't recover the > data correctly. > 3. Shooting a 9 micron beam into a 50 (or worse, 62.5) micron core, > and getting enough of the beam to reach the 9 micron target at the > other end to result in a recoverable signal is problematic. If you're not pushing your distance too far it'll probably be fine, to be honest. Back in the day when I was working on large legacy campus fibre runs, 220 metres was the max distance we considered OK for SX drivers and OM1 fibre (for gig ethernet). Mode conditioning leads would push this out to say, 900m trustworthy. If your distance is >900m I would suggest a fibre upgrade is on the cards. Again, the above all assumes mode-conditioning in use. If you're not mode-conditioning your effective range is going to be very short - to the point of unusability - and I'd be concerned about the affects of 'overdriving' fibre that is not set up for the use of low powered lasers and was instead optimised for LEDs, which obviously put out a lot less power. Mark. From keegan.holley at sungard.com Wed Dec 14 15:08:26 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Wed, 14 Dec 2011 16:08:26 -0500 Subject: Range using single-mode SFPs across multi-mode fiber In-Reply-To: <4EE90C27.7030109@utc.edu> References: <4EE90C27.7030109@utc.edu> Message-ID: 2011/12/14 Jeff Kell > On 12/14/2011 3:37 PM, Keegan Holley wrote: > > > Single mode just has a smaller core size for the smaller "beam" emitted > by > > laser vs. LED. it works although I've never done it outside of a lab (MM > > is cheaper). As for the distance it theory that should come down to the > > optics and your transmit power. Hopefully this is just a cable > connecting > > the router to a long line. I've never heard of a 10K MM fiber run since > SX > > optics can't shoot that far. You should be able to get through the 500m > or > > so that MM optics are rated for, but YMMV (errors, light levels, bounces, > > etc etc) > > Cisco gives specs for SFP LX over MM (they aren't that great at gig, and > really suck at > 10G; if you have 50u OM3/OM4 you can do much better at 10G). > > See SFP/fiber/distance table at > > http://www.cisco.com/en/US/prod/collateral/modules/ps5455/ps6577/product_data_sheet0900aecd8033f885.html > > They specify that line conditioning cables were used. I would say if you're going to bother purchasing why not purchase SM? > We have run LX-over-MM (62.5) on short building runs as a band-aid until > SM is > available, and trying to do all new building MM with 50u OM3/OM4. We do > have some > dependence on 62.5u MM - used by our aging Simplex alarm system - which > does > point-to-point looped token ring <*cough*> on the alarm side. What distances? > I'm trying to get them to confirm 50u will work point-to-point, but at > some non-alarm-points there would be a > necessary 50-to-62.5 exchange taking place and I'm not certain how to > accomplish that > (50->62.5 would likely have tolerable loss, but not 62.5->50). > > I don't think changing core sizes in the middle would work even with SM optics. From surfer at mauigateway.com Wed Dec 14 15:09:12 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 14 Dec 2011 13:09:12 -0800 Subject: Time Warner Routing Issue Message-ID: <20111214130912.2D89369@m0005296.ppops.net> : Yesterday TW started advertising BGP for the ip blocks I have : (68.68.176.0/22 in /24's) before they had the circuit completed How did they get the routes into their table if the ckt was not up and you were not advertising the routes to them? Did they also announce the covering prefix? scott --- mailing-lists at brianraaen.com wrote: From: Brian Christopher Raaen To: nanog at nanog.org Subject: Time Warner Routing Issue Date: Wed, 14 Dec 2011 15:46:52 -0500 I have a Time Warner circuit that has been giving me issues and what their tech support has been telling me has not matched my previous experience with other backbones. I have been trying to move the backbone on one site from a tier-3 provider to Time Warner. Yesterday TW started advertising BGP for the ip blocks I have (68.68.176.0/22 in /24's) before they had the circuit completed, so I had to make an emergency mid-day switch to move to Time Warner. Then yesterday night they stopped announcing my blocks so my site went down again and would still be completely down if we had not added NAT to the /30 point-to-point link. They said the reason was they didn't have an LOA (which they had gotten back in October) and the ip blocks were not in the Level3 Radb list. I could still see announcement to some peers (Shaw Cable in Canada) in a few looking glasses and BGP routers. However my network blocks were not showing for the larger US carriers like Qwest and AT&T. One of their techs just called me back and said that Level3 should be advertising it, but I still do not see the routes on the AT&T route server. After noting that the tech said that it may take another day for BGP to "propagate" to other peers as they update their radb tables. In my experience I've never seen anything where I had to wait for a route to propagate other than standard routing table updates which usually take less then an hour, and I'd really not expect this many problems between Tier1 and Tier2 providers. I need to know if this matches other's experience and wanting to know what other people were seeing with traceroutes and "show ip bgp". The networks in question at the following 4 /24's 68.68.176.0/24 68.68.177.0/24 68.68.178.0/24 68.68.179.0/24 the serial ip address is 72.43.84.254 Thanks for your assistance. --- Brian Raaen Zcorum Network Architect From cb.list6 at gmail.com Wed Dec 14 15:15:48 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Wed, 14 Dec 2011 13:15:48 -0800 Subject: De-bogon not possible via arin policy. Message-ID: Fyi, I just was rejected from arin for an ipv4 allocation. I demonstrated I own ~100k ipv4 addresses today. My customers use over 10 million bogon / squat space ip addresses today, and I have good attested data on that. But all I can qualify for is a /18, and then in 3 months maybe a /17. This is called slow start ? For an established business? Just fyi, de-bogoning , or private rfc 1918 is not really an option even with strong and consistent demonstrate load. Any suggestions on how to navigate this policy ? From rubensk at gmail.com Wed Dec 14 15:20:17 2011 From: rubensk at gmail.com (Rubens Kuhl) Date: Wed, 14 Dec 2011 19:20:17 -0200 Subject: De-bogon not possible via arin policy. In-Reply-To: References: Message-ID: > Fyi, I just was rejected from arin for an ipv4 allocation. I demonstrated I > own ~100k ipv4 addresses today.> > My customers use over 10 million bogon / squat space ip addresses today, > and I have good attested data on that. > But all I can qualify for is a /18, and then in 3 months maybe a /17. This > is called slow start ? For an established business? > Just fyi, de-bogoning , or private rfc 1918 is not really an option even > with strong and consistent demonstrate load. > > Any suggestions on how to navigate this policy ? You should easily qualify for a /32 or larger IPv6 block. And it's curious that errors that are likely to be there for decades are just now trying to be fixed as IPv4 pool is depleted, isn't it ? Rubens From axisml at gmail.com Wed Dec 14 15:23:53 2011 From: axisml at gmail.com (Chris Stone) Date: Wed, 14 Dec 2011 14:23:53 -0700 Subject: Time Warner Routing Issue In-Reply-To: <20111214130912.2D89369@m0005296.ppops.net> References: <20111214130912.2D89369@m0005296.ppops.net> Message-ID: Brian, > wanting to know what other people were seeing with traceroutes and "show ip > bgp". ?The networks in question at the following 4 /24's > > 68.68.176.0/24 > 68.68.177.0/24 > 68.68.178.0/24 > 68.68.179.0/24 Here's what I'm seeing on our L3 connection here in Denver, CO:: route1:~$ show ip bgp | egrep '68.68.17[6-9]' *> 68.68.176.0/24 4.79.81.221 0 0 3356 7843 11351 i *> 68.68.177.0/24 4.79.81.221 0 0 3356 7843 11351 i *> 68.68.178.0/24 4.79.81.221 0 0 3356 7843 11351 i *> 68.68.179.0/24 4.79.81.221 0 0 3356 7843 11351 i traceroute to 68.68.176.1 (68.68.176.1), 30 hops max, 60 byte packets 1 4.79.81.221 0.348 ms 0.343 ms 0.339 ms 2 4.69.147.94 0.310 ms 0.316 ms 0.337 ms 3 4.69.132.106 16.486 ms 21.091 ms 16.440 ms 4 4.69.151.165 14.695 ms 14.709 ms 4.69.151.129 22.556 ms 5 4.69.145.144 14.874 ms 14.890 ms 4.69.145.80 14.951 ms 6 4.28.152.110 14.697 ms 14.806 ms 4.59.32.18 16.736 ms 7 66.109.9.104 14.579 ms 66.109.6.208 14.686 ms 14.478 ms 8 66.109.9.40 30.662 ms 66.109.6.23 30.592 ms 30.638 ms 9 66.109.6.20 30.420 ms 30.595 ms 30.582 ms 10 66.109.6.73 44.523 ms 44.460 ms 44.498 ms 11 24.24.21.213 57.437 ms 57.642 ms 57.626 ms 12 74.76.241.191 57.340 ms 57.495 ms 57.388 ms 13 74.76.241.181 57.478 ms 57.450 ms 57.766 ms 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * traceroute to 68.68.179.1 (68.68.179.1), 30 hops max, 60 byte packets 1 4.79.81.221 0.421 ms 0.429 ms 0.430 ms 2 4.69.147.94 0.384 ms 0.402 ms 0.404 ms 3 4.69.132.106 14.763 ms 14.725 ms 14.750 ms 4 4.69.151.141 14.817 ms 14.787 ms 4.69.151.165 14.687 ms 5 4.69.145.80 62.893 ms 4.69.145.208 14.992 ms 4.69.145.144 14.975 ms 6 4.28.152.110 14.994 ms 14.808 ms 14.805 ms 7 66.109.6.208 14.659 ms 14.658 ms 14.589 ms 8 66.109.6.23 30.599 ms 30.774 ms 30.725 ms 9 66.109.6.20 30.509 ms 30.713 ms 30.718 ms 10 66.109.6.73 44.476 ms 107.14.19.29 44.468 ms * 11 24.24.21.213 57.657 ms 57.583 ms 57.567 ms 12 74.76.241.191 57.356 ms 57.227 ms 57.183 ms 13 74.76.241.181 58.266 ms 57.402 ms 57.452 ms 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * Chris From trelane at trelane.net Wed Dec 14 15:28:29 2011 From: trelane at trelane.net (Andrew D Kirch) Date: Wed, 14 Dec 2011 16:28:29 -0500 Subject: De-bogon not possible via arin policy. In-Reply-To: References: Message-ID: <4EE914FD.3020709@trelane.net> On 12/14/2011 4:20 PM, Rubens Kuhl wrote: > You should easily qualify for a /32 or larger IPv6 block. > And it's curious that errors that are likely to be there for decades > are just now trying to be fixed as IPv4 pool is depleted, isn't it ? > > His users can also switch to DECNET and reach about as many internet sites as they would with IPv6. Ooh well, internet's dieing, lets pack up our routers and go home. Randy Bush will turn out the lights for us. Andrew From rs at seastrom.com Wed Dec 14 15:29:17 2011 From: rs at seastrom.com (Robert E. Seastrom) Date: Wed, 14 Dec 2011 16:29:17 -0500 Subject: De-bogon not possible via arin policy. In-Reply-To: (Cameron Byrne's message of "Wed, 14 Dec 2011 13:15:48 -0800") References: Message-ID: <86ty524zbm.fsf@seastrom.com> What do you mean by "de-bogon"? Do you mean that your customers' addresses are listed in various RBLs for previous misbehavior? That they are using addresses that were never properly allocated to them? Something different? You don't "own" IPv4 addresses; they are assigned or allocated to you in response to demonstrated need. ARIN takes into account your history of needing IP address space when evaluating your request for more address space to be assigned or allocated to you. If you have not been back to ARIN for address space recently (or ever, if these are legacy addresses), you may find yourself subject to slow start just like a newly established entity. It does not sound as if ARIN rejected you for an IPv4 allocation. >From your statement below, it sounds as if ARIN approved you for a /18, which is reasonable and in accordance with current policies. If you walked in to ARIN and asked them for 10 million IPv4 addresses (which is on the order of 1/8 of the total that ARIN has on hand, for everyone), it is unsurprising that they declined. If you can clarify the problem, it's possible the community may be able to offer assistance. -r PS: I'm on the ARIN Advisory Council, which means that I help with policy creation. Neither I nor my 14 colleagues on the AC are employees; staff won't discuss particular cases, etc. So if you want us to know something, you'll have to state it here or in private email or something. Cameron Byrne writes: > Fyi, I just was rejected from arin for an ipv4 allocation. I demonstrated I > own ~100k ipv4 addresses today. > > My customers use over 10 million bogon / squat space ip addresses today, > and I have good attested data on that. > > But all I can qualify for is a /18, and then in 3 months maybe a /17. This > is called slow start ? For an established business? > > Just fyi, de-bogoning , or private rfc 1918 is not really an option even > with strong and consistent demonstrate load. > > Any suggestions on how to navigate this policy ? From shortdudey123 at gmail.com Wed Dec 14 15:35:37 2011 From: shortdudey123 at gmail.com (Grant Ridder) Date: Wed, 14 Dec 2011 15:35:37 -0600 Subject: Time Warner Routing Issue In-Reply-To: References: <20111214130912.2D89369@m0005296.ppops.net> Message-ID: Hi Brian, My school has 2x TW circuits. Tracing to 68.68.176.1 shows that it doesn't leave TW's network. In Chris's previous email, the origion is AS 11351 which is Road Runner (now owned by TW). It gets to Albany, NY then dies. C:\Users\ridderg>tracert 68.68.176.1 Tracing route to gw.princetowncable.com [68.68.176.1] over a maximum of 30 hops: 1 <1 ms 1 ms <1 ms 155.92.105.254 2 1 ms 1 ms 1 ms 155.92.10.17 3 2 ms 1 ms 1 ms 155.92.10.1 4 3 ms 1 ms 8 ms 155.92.10.130 5 2 ms 1 ms 2 ms 207-250-86-49.static.twtelecom.net[207.250.86.49] 6 4 ms 4 ms 4 ms chi2-pr1-xe-2-3-0-0.us.twtelecom.net[66.192.250.154] 7 49 ms 5 ms 4 ms ae-1-0.cr0.chi10.tbone.rr.com [66.109.6.152] 8 18 ms 19 ms 18 ms 66.109.6.73 9 32 ms 31 ms 31 ms ae1-0.glflnyaq-rtr000.nyroc.rr.com[24.24.21.213] 10 31 ms 31 ms 33 ms rdc-74-76-241-191.alb.northeast.rr.com[74.76.241.191] 11 * * * Request timed out. 12 * * * Request timed out. 13 * * * Request timed out. 14 * * * Request timed out. 15 * * * Request timed out. 16 * * * Request timed out. 17 * * * Request timed out. 18 * * * Request timed out. 19 * * * Request timed out. 20 * * * Request timed out. 21 * * * Request timed out. 22 * * * Request timed out. 23 * * * Request timed out. 24 * * * Request timed out. 25 * * * Request timed out. 26 * * * Request timed out. 27 * * * Request timed out. 28 * * * Request timed out. 29 * * * Request timed out. 30 * * * Request timed out. Trace complete. -Grant On Wed, Dec 14, 2011 at 3:23 PM, Chris Stone wrote: > Brian, > > > wanting to know what other people were seeing with traceroutes and "show > ip > > bgp". The networks in question at the following 4 /24's > > > > 68.68.176.0/24 > > 68.68.177.0/24 > > 68.68.178.0/24 > > 68.68.179.0/24 > > Here's what I'm seeing on our L3 connection here in Denver, CO:: > > route1:~$ show ip bgp | egrep '68.68.17[6-9]' > *> 68.68.176.0/24 4.79.81.221 0 0 3356 7843 > 11351 i > *> 68.68.177.0/24 4.79.81.221 0 0 3356 7843 > 11351 i > *> 68.68.178.0/24 4.79.81.221 0 0 3356 7843 > 11351 i > *> 68.68.179.0/24 4.79.81.221 0 0 3356 7843 > 11351 i > > traceroute to 68.68.176.1 (68.68.176.1), 30 hops max, 60 byte packets > 1 4.79.81.221 0.348 ms 0.343 ms 0.339 ms > 2 4.69.147.94 0.310 ms 0.316 ms 0.337 ms > 3 4.69.132.106 16.486 ms 21.091 ms 16.440 ms > 4 4.69.151.165 14.695 ms 14.709 ms 4.69.151.129 22.556 ms > 5 4.69.145.144 14.874 ms 14.890 ms 4.69.145.80 14.951 ms > 6 4.28.152.110 14.697 ms 14.806 ms 4.59.32.18 16.736 ms > 7 66.109.9.104 14.579 ms 66.109.6.208 14.686 ms 14.478 ms > 8 66.109.9.40 30.662 ms 66.109.6.23 30.592 ms 30.638 ms > 9 66.109.6.20 30.420 ms 30.595 ms 30.582 ms > 10 66.109.6.73 44.523 ms 44.460 ms 44.498 ms > 11 24.24.21.213 57.437 ms 57.642 ms 57.626 ms > 12 74.76.241.191 57.340 ms 57.495 ms 57.388 ms > 13 74.76.241.181 57.478 ms 57.450 ms 57.766 ms > 14 * * * > 15 * * * > 16 * * * > 17 * * * > 18 * * * > 19 * * * > 20 * * * > 21 * * * > 22 * * * > 23 * * * > 24 * * * > 25 * * * > 26 * * * > 27 * * * > 28 * * * > 29 * * * > 30 * * * > > traceroute to 68.68.179.1 (68.68.179.1), 30 hops max, 60 byte packets > 1 4.79.81.221 0.421 ms 0.429 ms 0.430 ms > 2 4.69.147.94 0.384 ms 0.402 ms 0.404 ms > 3 4.69.132.106 14.763 ms 14.725 ms 14.750 ms > 4 4.69.151.141 14.817 ms 14.787 ms 4.69.151.165 14.687 ms > 5 4.69.145.80 62.893 ms 4.69.145.208 14.992 ms 4.69.145.144 14.975 ms > 6 4.28.152.110 14.994 ms 14.808 ms 14.805 ms > 7 66.109.6.208 14.659 ms 14.658 ms 14.589 ms > 8 66.109.6.23 30.599 ms 30.774 ms 30.725 ms > 9 66.109.6.20 30.509 ms 30.713 ms 30.718 ms > 10 66.109.6.73 44.476 ms 107.14.19.29 44.468 ms * > 11 24.24.21.213 57.657 ms 57.583 ms 57.567 ms > 12 74.76.241.191 57.356 ms 57.227 ms 57.183 ms > 13 74.76.241.181 58.266 ms 57.402 ms 57.452 ms > 14 * * * > 15 * * * > 16 * * * > 17 * * * > 18 * * * > 19 * * * > 20 * * * > 21 * * * > 22 * * * > 23 * * * > 24 * * * > 25 * * * > 26 * * * > 27 * * * > 28 * * * > 29 * * * > 30 * * * > > > Chris > > From drc at virtualized.org Wed Dec 14 15:45:11 2011 From: drc at virtualized.org (David Conrad) Date: Wed, 14 Dec 2011 13:45:11 -0800 Subject: De-bogon not possible via arin policy. In-Reply-To: References: Message-ID: On Dec 14, 2011, at 1:15 PM, Cameron Byrne wrote: > Just fyi, de-bogoning , or private rfc 1918 is not really an option even > with strong and consistent demonstrate load. > > Any suggestions on how to navigate this policy ? Given unmet demand, I'd think the solution would be fairly obvious (albeit likely quite expensive with the going rate being around $12/address). I'd guess some of the folks who would be more than happy to help you (in exchange for a transaction fee of course) will contact you in the near future (if they haven't already). Regards, -drc From mailing-lists at brianraaen.com Wed Dec 14 15:54:13 2011 From: mailing-lists at brianraaen.com (Brian Christopher Raaen) Date: Wed, 14 Dec 2011 16:54:13 -0500 Subject: Time Warner Routing Issue In-Reply-To: References: Message-ID: Thank you everyone for your assistance. Either having a tech spot my post and make the change or me calling their bluff got them to fix it. Thanks --- Brian Raaen Zcorum Network Architect On Wed, Dec 14, 2011 at 3:46 PM, Brian Christopher Raaen wrote: > I have a Time Warner circuit that has been giving me issues and what their > tech support has been telling me has not matched my previous experience > with other backbones. ?I have been trying to move the backbone on one site > from a tier-3 provider to Time Warner. ?Yesterday TW started advertising > BGP for the ip blocks I have (68.68.176.0/22 in /24's) before they had the > circuit completed, so I had to make an emergency mid-day switch to move to > Time Warner. ?Then yesterday night they stopped announcing my blocks so my > site went down again and would still be completely down if we had not added > NAT to the /30 point-to-point link. ?They said the reason was they didn't > have an LOA (which they had gotten back in October) and the ip blocks were > not in the Level3 Radb list. ?I could still see announcement to some peers > (Shaw Cable in Canada) in a few looking glasses and BGP routers. ?However > my network blocks were not showing for the larger US carriers like Qwest > and AT&T. ?One of their techs just called me back and said that Level3 > should be advertising it, but I still do not see the routes on the AT&T > route server. ?After noting that the tech said that it may take another day > for BGP to "propagate" to other peers as they update their radb tables. ?In > my experience I've never seen anything where I had to wait for a route to > propagate other than standard routing table updates which usually take less > then an hour, and I'd really not expect this many problems between Tier1 > and Tier2 providers. ?I need to know if this matches other's experience and > wanting to know what other people were seeing with traceroutes and "show ip > bgp". ?The networks in question at the following 4 /24's > > 68.68.176.0/24 > 68.68.177.0/24 > 68.68.178.0/24 > 68.68.179.0/24 > > the serial ip address is 72.43.84.254 > > Thanks for your assistance. > > --- > Brian Raaen > Zcorum > Network Architect From courtneysmith at comcast.net Wed Dec 14 16:40:14 2011 From: courtneysmith at comcast.net (Courtney Smith) Date: Wed, 14 Dec 2011 17:40:14 -0500 Subject: Time Warner Routing Issue In-Reply-To: References: Message-ID: On Dec 14, 2011, at 4:09 PM, nanog-request at nanog.org wrote: > > Message: 3 > Date: Wed, 14 Dec 2011 15:46:52 -0500 > From: Brian Christopher Raaen > To: nanog at nanog.org > Subject: Time Warner Routing Issue > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > They said the reason was they didn't > have an LOA (which they had gotten back in October) and the ip blocks were > not in the Level3 Radb list. I could still see announcement to some peers > (Shaw Cable in Canada) in a few looking glasses and BGP routers. However > my network blocks were not showing for the larger US carriers like Qwest > and AT&T. One of their techs just called me back and said that Level3 > should be advertising it, but I still do not see the routes on the AT&T > route server. After noting that the tech said that it may take another day > for BGP to "propagate" to other peers as they update their radb tables. In > my experience I've never seen anything where I had to wait for a route to > propagate other than standard routing table updates which usually take less > then an hour, and I'd really not expect this many problems between Tier1 > and Tier2 providers. I need to know if this matches other's experience and > wanting to know what other people were seeing with traceroutes and "show ip > bgp". The networks in question at the following 4 /24's > > 68.68.176.0/24 > 68.68.177.0/24 > 68.68.178.0/24 > 68.68.179.0/24 > > the serial ip address is 72.43.84.254 > > Thanks for your assistance. > > --- > Brian Raaen > Zcorum > Network Architect > I believe the TWC tech is referring to prefix filter updates and not routing table updates. Some of TWC's peers most likely use IRR based filters on their BGP sessions. Most networks only check once a day for IRR changes and apply those changes to filters. It looks TWC put in proxy route objects today for your blocks so I am guessing someone at TWC forgot to make the updates in advance. Work around is for them to reach out to the peers with IRR based filters and request a manual update. Sounds like that is what they are doing. route: 68.68.176.0/24 descr: RR-RC-Princetown Cable Company, Inc.-Albany origin: AS11351 notify: ipaddreg at rr.com mnt-by: MAINT-RR changed: ipaddreg at rr.com 20111214 source: RADB route: 68.68.177.0/24 descr: RR-RC-Princetown Cable Company, Inc.-Albany origin: AS11351 notify: ipaddreg at rr.com mnt-by: MAINT-RR changed: ipaddreg at rr.com 20111214 source: RADB Run the below on 12/15 and it should return your blocks. $ whois -h filtergen.level3.net radb::as11351 | grep 68.6 $ Courtney Smith courtneysmith at comcast.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From jsw at inconcepts.biz Wed Dec 14 17:38:14 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Wed, 14 Dec 2011 18:38:14 -0500 Subject: De-bogon not possible via arin policy. In-Reply-To: References: Message-ID: On Wed, Dec 14, 2011 at 4:15 PM, Cameron Byrne wrote: > Fyi, I just was rejected from arin for an ipv4 allocation. I demonstrated I > own ~100k ipv4 addresses today. > > My customers use over 10 million bogon / squat space ip addresses today, > and I have good attested data on that. Cameron, I have a client who went through the same problem in early-2011. They had several thousand residential and small business end-users behind NAT and wished to provision public IP addresses for them. They assumed ARIN would be pleased to issue an appropriate block for their project. David Huberman rejected their request outright and told them to request provider space, renumber the customers to provider IPs, and then apply to ARIN again and renumber their network a second time. The client did not bother to involve me until after they had already been told to FOAD. This is clearly a counter-productive waste of time, but if the client had applied using the immediate need process, and provided the additional supporting documentation required by that, I think they would not have had this problem. The analyst you worked with should have suggested a different application procedure or otherwise worked with you to facilitate your request. Sometimes the ARIN staff are nice and helpful, sometimes they are not. It depends on who you get assigned to, price of tea in china, phase of the moon, etc. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From mysidia at gmail.com Wed Dec 14 20:46:08 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 14 Dec 2011 20:46:08 -0600 Subject: De-bogon not possible via arin policy. In-Reply-To: References: Message-ID: On Wed, Dec 14, 2011 at 3:15 PM, Cameron Byrne wrote: > Fyi, I just was rejected from arin for an ipv4 allocation. I demonstrated I > own ~100k ipv4 addresses today. > My customers use over 10 million bogon / squat space ip addresses today, > and I have good attested data on that. Wait... you had started using bogon addresses / "squatted" space not allocated and claimed the number of IP addresses your network is using that were not allocated by a RIR settles the need justification question? > Any suggestions on how to navigate this policy ? Work with ARIN to provide a satisfactory need justification for the entire allocation you are requesting. A mere count of the number of IP addresses you are currently using is not a need justification. There has to be a technical reason that each IP address is required. "I'm making IANA-unsanctioned use of 10^9 bogon IP addresses, please allocate me 10^9 proper IP addresses, so I can have matching allocated IP space with global recognition instead"; just doesn't cut it. You need to have all the documentation to show the actual justified technical need for the IPs you request, such as what each specific address is used for. Regards, -- -JH From orothschild at gmail.com Wed Dec 14 21:02:58 2011 From: orothschild at gmail.com (oliver rothschild) Date: Wed, 14 Dec 2011 22:02:58 -0500 Subject: Range using single-mode SFPs across multi-mode fiber Message-ID: Thanks to all who responded to my clumsy first question (both on matters of etiquette and technology). The group I work with (we are a small project acting as a last mile provider) was in the midst of deploying this solution when I posed the question. We put the single mode Juniper SFPs (LX) on to a run of approximately 1670 meters. We successfully established a 1G ethernet connection. Testing to date has been meager, but shows that the link is viable. Under significant load there is some minor packet loss. Since the link far exceeds the amount of data it required, we have decided to continue using it. Interestingly neither interface showed any physical errors. v/r, Oliver Rothschild Network Engineer III From cra at WPI.EDU Wed Dec 14 21:33:01 2011 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 14 Dec 2011 22:33:01 -0500 Subject: Range using single-mode SFPs across multi-mode fiber In-Reply-To: References: Message-ID: <20111215033301.GI21253@angus.ind.WPI.EDU> On Wed, Dec 14, 2011 at 10:02:58PM -0500, oliver rothschild wrote: > Thanks to all who responded to my clumsy first question (both on > matters of etiquette and technology). The group I work with (we are a > small project acting as a last mile provider) was in the midst of > deploying this solution when I posed the question. We put the single > mode Juniper SFPs (LX) on to a run of approximately 1670 meters. We > successfully established a 1G ethernet connection. Testing to date has > been meager, but shows that the link is viable. Under significant load > there is some minor packet loss. Since the link far exceeds the amount > of data it required, we have decided to continue using it. > Interestingly neither interface showed any physical errors. Technically you should be using offset-launch "mode conditioning" patch cords at each end when running LX over multimode fiber. I had been lucky with not using them for many years on 62.5/125 (OM1) multimode (and just started doing so again, albiet only for OOB/non-production traffic use). I believe my longest link was/is around 1 km. http://www.cisco.com/en/US/prod/collateral/modules/ps5455/white_paper_c11-463677.html From keegan.holley at sungard.com Wed Dec 14 21:38:47 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Wed, 14 Dec 2011 22:38:47 -0500 Subject: Range using single-mode SFPs across multi-mode fiber In-Reply-To: References: Message-ID: 2011/12/14 oliver rothschild > Thanks to all who responded to my clumsy first question (both on > matters of etiquette and technology). The group I work with (we are a > small project acting as a last mile provider) was in the midst of > deploying this solution when I posed the question. We put the single > mode Juniper SFPs (LX) on to a run of approximately 1670 meters. > How did you end up with a MM run this long? SX optics are only rated at 500 meters at best. Even with mode conditioning jumpers more the 1km is a risk. I'm glad it held up during testing though. Just out of curiosity did you purchase dark from a provider? Is it inside of a building? From blakjak at blakjak.net Wed Dec 14 21:46:13 2011 From: blakjak at blakjak.net (Mark Foster) Date: Thu, 15 Dec 2011 16:46:13 +1300 Subject: Range using single-mode SFPs across multi-mode fiber In-Reply-To: References: Message-ID: <4EE96D85.2020907@blakjak.net> On 15/12/11 16:38, Keegan Holley wrote: > 2011/12/14 oliver rothschild > >> Thanks to all who responded to my clumsy first question (both on >> matters of etiquette and technology). The group I work with (we are a >> small project acting as a last mile provider) was in the midst of >> deploying this solution when I posed the question. We put the single >> mode Juniper SFPs (LX) on to a run of approximately 1670 meters. >> > How did you end up with a MM run this long? SX optics are only rated at > 500 meters at best. Even with mode conditioning jumpers more the 1km is a > risk. I'm glad it held up during testing though. Just out of curiosity > did you purchase dark from a provider? Is it inside of a building? Um.. check that. https://en.wikipedia.org/wiki/Multi-mode_optical_fiber "Typical transmission speed and distance limits are 100 Mbit/s for distances up to 2 km (100BASE-FX ), 1 Gbit/s to 220--550 m (1000BASE-SX ), and 10 Gbit/s to 300 m (10GBASE-SR )." The old OM1 installations I used to work on started out as 10Mbit hubbed ethernet links and on the odd occasion would run out to close to 2km within a campus. They were progressively upgraded with the flow of: 10FX on 3Com Linkbuilder Kit 100FX on 3Com Corebuilder Kit and Allied Telesyn 100FX Media converters 1000SX on a variety of 3Com, Nortel and Cisco kit out to ~220m 1000LX via Mode-Conditioning out to ~900-1000m. The OM1 only got retired when the distance was >900m or there was budget to put new fibre on the run, in which case we ran SMF and rigged LX drivers. Mark. From cra at WPI.EDU Wed Dec 14 21:46:39 2011 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 14 Dec 2011 22:46:39 -0500 Subject: Range using single-mode SFPs across multi-mode fiber In-Reply-To: References: Message-ID: <20111215034639.GJ21253@angus.ind.WPI.EDU> On Wed, Dec 14, 2011 at 10:38:47PM -0500, Keegan Holley wrote: > 2011/12/14 oliver rothschild > > > Thanks to all who responded to my clumsy first question (both on > > matters of etiquette and technology). The group I work with (we are a > > small project acting as a last mile provider) was in the midst of > > deploying this solution when I posed the question. We put the single > > mode Juniper SFPs (LX) on to a run of approximately 1670 meters. > > > > How did you end up with a MM run this long? SX optics are only rated at > 500 meters at best. Even with mode conditioning jumpers more the 1km is a > risk. I'm glad it held up during testing though. Just out of curiosity > did you purchase dark from a provider? Is it inside of a building? In my case, it was installed for compatibility with FDDI, and used mostly for 10BASE-FL and 100BASE-FX, which work up to 1 or 2km, until we started using it for 1000BASE-LX. From keegan.holley at sungard.com Wed Dec 14 21:50:10 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Wed, 14 Dec 2011 22:50:10 -0500 Subject: Range using single-mode SFPs across multi-mode fiber In-Reply-To: <4EE96D85.2020907@blakjak.net> References: <4EE96D85.2020907@blakjak.net> Message-ID: I stand corrected, but I haven't dealt much with 100BASE-FX. I was just talking in terms of 1G/10G. 2011/12/14 Mark Foster > On 15/12/11 16:38, Keegan Holley wrote: > > 2011/12/14 oliver rothschild > > Thanks to all who responded to my clumsy first question (both on > matters of etiquette and technology). The group I work with (we are a > small project acting as a last mile provider) was in the midst of > deploying this solution when I posed the question. We put the single > mode Juniper SFPs (LX) on to a run of approximately 1670 meters. > > > How did you end up with a MM run this long? SX optics are only rated at > 500 meters at best. Even with mode conditioning jumpers more the 1km is a > risk. I'm glad it held up during testing though. Just out of curiosity > did you purchase dark from a provider? Is it inside of a building? > > > Um.. check that. > > https://en.wikipedia.org/wiki/Multi-mode_optical_fiber > > "Typical transmission speed and distance limits are 100 Mbit/s for > distances up to 2 km (100BASE-FX), > 1 Gbit/s to 220?550 m (1000BASE-SX), > and 10 Gbit/s to 300 m (10GBASE-SR > )." > > The old OM1 installations I used to work on started out as 10Mbit hubbed > ethernet links and on the odd occasion would run out to close to 2km within > a campus. They were progressively upgraded with the flow of: > > 10FX on 3Com Linkbuilder Kit > 100FX on 3Com Corebuilder Kit and Allied Telesyn 100FX Media converters > 1000SX on a variety of 3Com, Nortel and Cisco kit out to ~220m > 1000LX via Mode-Conditioning out to ~900-1000m. > > The OM1 only got retired when the distance was >900m or there was budget > to put new fibre on the run, in which case we ran SMF and rigged LX drivers. > > Mark. > > > > > From joelja at bogus.com Wed Dec 14 22:31:50 2011 From: joelja at bogus.com (Joel jaeggli) Date: Wed, 14 Dec 2011 20:31:50 -0800 Subject: De-bogon not possible via arin policy. In-Reply-To: References: Message-ID: <4EE97836.6000801@bogus.com> On 12/14/11 18:46 , Jimmy Hess wrote: > On Wed, Dec 14, 2011 at 3:15 PM, Cameron Byrne wrote: >> Fyi, I just was rejected from arin for an ipv4 allocation. I demonstrated I >> own ~100k ipv4 addresses today. >> My customers use over 10 million bogon / squat space ip addresses today, >> and I have good attested data on that. > > Wait... you had started using bogon addresses / "squatted" space not > allocated and claimed > the number of IP addresses your network is using that were not > allocated by a RIR > settles the need justification question? Anyone who has used their network in the last decade that actually bother to look at their assigned ip address knows this. >> Any suggestions on how to navigate this policy ? > > Work with ARIN to provide a satisfactory need justification for the > entire allocation you are requesting. > A mere count of the number of IP addresses you are currently using is > not a need justification. The wikipedia page shows something on the order of 34 million customers. I don't expect they all need an ip at the same time. > There has to be a technical reason that each IP address is required. > > "I'm making IANA-unsanctioned use of 10^9 bogon IP addresses, please > allocate me 10^9 proper IP addresses, so I can have matching > allocated IP space with global recognition instead"; just doesn't cut > it. > > You need to have all the documentation to show the actual justified > technical need for the IPs you request, such as what each specific > address is used for. > > > Regards, > -- > -JH > From drc at virtualized.org Wed Dec 14 22:47:36 2011 From: drc at virtualized.org (David Conrad) Date: Wed, 14 Dec 2011 20:47:36 -0800 Subject: De-bogon not possible via arin policy. In-Reply-To: References: Message-ID: <47067B6B-1026-42CF-A133-A18A70553731@virtualized.org> On Dec 14, 2011, at 6:46 PM, Jimmy Hess wrote > Wait... you had started using bogon addresses / "squatted" space not > allocated and claimed the number of IP addresses your network is using that were not > allocated by a RIR settles the need justification question? I'm confused. When justifying 'need' in an address allocation request, what difference does it make whether an address in use was allocated by an RIR or was squatted upon? Last I heard, renumbering out of (say) RFC 1918 space into public space was still a justification for address space. Has this changed? > You need to have all the documentation to show the actual justified > technical need for the IPs you request, such as what each specific > address is used for. Perhaps I'm naive, but I tend to give folks like Cameron the benefit of the doubt when it comes to dealing with IP address allocation requests and assume he provided a bit more information than what you're suggesting. I find the suggestions by other posters that he look at IPv6 particularly amusing. Unfortunately, regardless of the specifics of Cameron's case, the reality is that the traditional model of address allocation (i.e., "to each according to need" to quote a 19th century philosopher) is rapidly coming to a close. I expect there will be many more situations like Cameron's in the future. Regards, -drc From glen.kent at gmail.com Wed Dec 14 23:54:56 2011 From: glen.kent at gmail.com (Glen Kent) Date: Thu, 15 Dec 2011 11:24:56 +0530 Subject: /128 IPv6 prefixs in the wild? Message-ID: Hi, In the service provider networks, would we usually see a large number of /128 prefixs in the v6 FIB tables? In an IP/MPLS world, core routers in the service provider network learn the /32 loopback IPv4 addresses so that they can establish BGP/Targetted LDP sessions with those. They then establish LSPs and VPN tunnels. Since we dont have RSVP for IPv6 and LDP for IPv6 (not yet RFC) we cannot form MPLS tunnels in a pure IPv6 only network. GIven this, would v6 routers have large number of /128 prefixes? What are the scenarios when IPv6 routers would learn a large number of /128 prefixes? I would presume that most IPv6 prefixes that the routers have to install are less than /64, since the latter 64 is the host part. Is this correct? Glen From keegan.holley at sungard.com Thu Dec 15 00:07:58 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Thu, 15 Dec 2011 01:07:58 -0500 Subject: local_preference for transit traffic? Message-ID: Had in interesting conversation with a transit AS on behalf of a customer where I found out they are using communities to raise the local preference of routes that do not originate locally by default before sending to a other larger transit AS's. Obviously this isn't something that was asked of them and it took a few days to find since the customer is not a large company and neither them nor my company has a link or business relationship with the AS in question. This seemed strange to me for obvious reasons, but I was curious if anyone else was doing this and why. You obviously cannot use prepend to affect transit traffic again for obvious reasons. MED is a weak metric but it at least only affects traffic that was already going to transit your AS. The larger transit AS was favoring a lower bandwidth link for the customer and causing them to drop packets mysteriously. Just wondering if this practice seemed as strange to others as it does to me. From mtinka at globaltransit.net Thu Dec 15 00:30:08 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Thu, 15 Dec 2011 14:30:08 +0800 Subject: /128 IPv6 prefixs in the wild? In-Reply-To: References: Message-ID: <201112151430.12077.mtinka@globaltransit.net> On Thursday, December 15, 2011 01:54:56 PM Glen Kent wrote: > In an IP/MPLS world, core routers in the service provider > network learn the /32 loopback IPv4 addresses so that > they can establish BGP/Targetted LDP sessions with > those. That's right - not sure how things would have been if 'draft-swallow-mpls-aggregate-fec-01' had gained some traction. > They then establish LSPs and VPN tunnels. Indeed. > Since > we dont have RSVP for IPv6 and LDP for IPv6 (not yet > RFC) we cannot form MPLS tunnels in a pure IPv6 only > network. GIven this, would v6 routers have large number > of /128 prefixes? > > What are the scenarios when IPv6 routers would learn a > large number of /128 prefixes? I suspect ISP's that choose to assign broadband customers /128 addresses because "they only ever need one address" may be a situation where you see rise given to this. > I would presume that most IPv6 prefixes that the routers > have to install are less than /64, since the latter 64 > is the host part. Is this correct? This is certainly going to re-open some "wounds", but no, not all providers are assigning /64 to interfaces. Some (like us) are using longer prefix lengths such as /112 and /126. But as for /128 prefix lengths, aside from the fact that Loopbacks will be floating around the network, whether you're using them to signal MPLS LSP's or setup iBGP sessions, you will see them with ISP's that assign them to customers and choose not to aggregate them at specific edge routers. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From dholmes at mwdh2o.com Thu Dec 15 00:31:29 2011 From: dholmes at mwdh2o.com (Holmes,David A) Date: Wed, 14 Dec 2011 22:31:29 -0800 Subject: local_preference for transit traffic? In-Reply-To: References: Message-ID: <922ACC42D498884AA02B3565688AF9953402D4EF84@USEXMBS01.mwd.h2o> For this very reason I have advocated using longest prefix BGP routing for some years now, and checking periodically for the expected path, as it became obvious from investigating traceroutes that traffic was not being routed as intended using AS prepends. -----Original Message----- From: Keegan Holley [mailto:keegan.holley at sungard.com] Sent: Wednesday, December 14, 2011 10:08 PM To: NANOG Subject: local_preference for transit traffic? Had in interesting conversation with a transit AS on behalf of a customer where I found out they are using communities to raise the local preference of routes that do not originate locally by default before sending to a other larger transit AS's. Obviously this isn't something that was asked of them and it took a few days to find since the customer is not a large company and neither them nor my company has a link or business relationship with the AS in question. This seemed strange to me for obvious reasons, but I was curious if anyone else was doing this and why. You obviously cannot use prepend to affect transit traffic again for obvious reasons. MED is a weak metric but it at least only affects traffic that was already going to transit your AS. The larger transit AS was favoring a lower bandwidth link for the customer and causing them to drop packets mysteriously. Just wondering if this practice seemed as strange to others as it does to me. This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system. From keegan.holley at sungard.com Thu Dec 15 00:33:47 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Thu, 15 Dec 2011 01:33:47 -0500 Subject: local_preference for transit traffic? In-Reply-To: <922ACC42D498884AA02B3565688AF9953402D4EF84@USEXMBS01.mwd.h2o> References: <922ACC42D498884AA02B3565688AF9953402D4EF84@USEXMBS01.mwd.h2o> Message-ID: I suppose so because prepend is so easily defeated, but sometimes you don't own a prefix shorter than the one you need to advertise. Assuming I understand your suggestion correctly. 2011/12/15 Holmes,David A > For this very reason I have advocated using longest prefix BGP routing for > some years now, and checking periodically for the expected path, as it > became obvious from investigating traceroutes that traffic was not being > routed as intended using AS prepends. > > -----Original Message----- > From: Keegan Holley [mailto:keegan.holley at sungard.com] > Sent: Wednesday, December 14, 2011 10:08 PM > To: NANOG > Subject: local_preference for transit traffic? > > Had in interesting conversation with a transit AS on behalf of a customer > where I found out they are using communities to raise the local preference > of routes that do not originate locally by default before sending to a > other larger transit AS's. Obviously this isn't something that was asked > of them and it took a few days to find since the customer is not a large > company and neither them nor my company has a link or business relationship > with the AS in question. This seemed strange to me for obvious reasons, > but I was curious if anyone else was doing this and why. You obviously > cannot use prepend to affect transit traffic again for obvious reasons. > MED is a weak metric but it at least only affects traffic that was already > going to transit your AS. The larger transit AS was favoring a lower > bandwidth link for the customer and causing them to drop packets > mysteriously. Just wondering if this practice seemed as strange to others > as it does to me. > > This communication, together with any attachments or embedded links, is > for the sole use of the intended recipient(s) and may contain information > that is confidential or legally protected. If you are not the intended > recipient, you are hereby notified that any review, disclosure, copying, > dissemination, distribution or use of this communication is strictly > prohibited. If you have received this communication in error, please notify > the sender immediately by return e-mail message and delete the original and > all copies of the communication, along with any attachments or embedded > links, from your system. > > From jsw at inconcepts.biz Thu Dec 15 01:09:08 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Thu, 15 Dec 2011 02:09:08 -0500 Subject: local_preference for transit traffic? In-Reply-To: References: Message-ID: On Thu, Dec 15, 2011 at 1:07 AM, Keegan Holley wrote: > Had in interesting conversation with a transit AS on behalf of a customer > where I found out they are using communities to raise the local preference That sounds like a disreputable practice. While not quite as obvious, some large transit ASes, like Level3, reset the origin to I (best) sometime between when they learn it and when they announce it to their customers and peers. This similarly causes them to suck in a bit more traffic than they might otherwise. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From mysidia at gmail.com Thu Dec 15 01:14:15 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 15 Dec 2011 01:14:15 -0600 Subject: De-bogon not possible via arin policy. In-Reply-To: <47067B6B-1026-42CF-A133-A18A70553731@virtualized.org> References: <47067B6B-1026-42CF-A133-A18A70553731@virtualized.org> Message-ID: On Wed, Dec 14, 2011 at 10:47 PM, David Conrad wrote: [snip] > I'm confused. When justifying 'need' in an address allocation request, what difference does it make >whether an address in use was allocated by an RIR or was squatted upon? ?Last I heard, renumbering >out of (say) RFC 1918 space into public space was still a justification for address space. ?Has this >changed? It is a potential network change that could require additional address space, if an operator plans a complete and immediate renumbering, but the choice to renumber is not an automatic justification for the same number of non-RFC1918 IPs as the count of IPs available in their RFC1918 space networks. I'm sure the RIRs are not allowing that. A RFC1918 network is not a "normal" network; and this is not a renumbering in the same manner as a renumbering from public IP space to new public IP space. The operator might have to show why they shouldn't renumber their 1918 network partially, over time, in a manner compatible with the RIR policy for initial service provider allocations, instead of all at once. In other words: What is the technical justification that all those rfc1918 addressed hosts suddenly need to be moved immediately, and not over a normal allocation time frame for new public networks? When building the rfc1918 network originally, the architect did not need to follow RFC 2050, RFC3194, etc, so it is quite possible that the 1918 network does not efficiently utilize IP addresses. That means the RIR has to establish that the criterion is good enough. "I have a rfc1918 /16 that I use, so give me a public /16, please" is not good enough. That would essentially provide a backdoor around normal RIR justified need policy, if it were allowed...... -- -JH From keegan.holley at sungard.com Thu Dec 15 01:24:13 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Thu, 15 Dec 2011 02:24:13 -0500 Subject: local_preference for transit traffic? In-Reply-To: References: Message-ID: I always assumed that taking in more traffic was a bad thing. I've heard about one sided peering agreements where one side is sending more traffic than the other needs them to transport. Am I missing something? Would this cause a shift in their favor allowing them to offload more customer traffic to their peers without complaint? 2011/12/15 Jeff Wheeler > On Thu, Dec 15, 2011 at 1:07 AM, Keegan Holley > wrote: > > Had in interesting conversation with a transit AS on behalf of a customer > > where I found out they are using communities to raise the local > preference > > That sounds like a disreputable practice. > > While not quite as obvious, some large transit ASes, like Level3, > reset the origin to I (best) sometime between when they learn it and > when they announce it to their customers and peers. This similarly > causes them to suck in a bit more traffic than they might otherwise. > > -- > Jeff S Wheeler > Sr Network Operator / Innovative Network Concepts > > > From jared at puck.nether.net Thu Dec 15 01:31:57 2011 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 15 Dec 2011 08:31:57 +0100 Subject: De-bogon not possible via arin policy. In-Reply-To: References: <47067B6B-1026-42CF-A133-A18A70553731@virtualized.org> Message-ID: <67AF4904-9895-46AD-BEB1-54D7FB680FD4@puck.nether.net> I'm also aware of at least one network that has consumed all private address space, perhaps even including the testing /15 as well. If you are using a /8 /12 and /16 in total, ones future life could be very interesting. Almost makes the case for v6 easier at their site. I'm hoping we see 2012 as the date of broadband v6 becoming commonly available in the states at least. Jared Mauch On Dec 15, 2011, at 8:14, Jimmy Hess wrote: > > That would essentially provide a backdoor around normal RIR justified > need policy, if it were allowed...... From jsw at inconcepts.biz Thu Dec 15 01:35:55 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Thu, 15 Dec 2011 02:35:55 -0500 Subject: local_preference for transit traffic? In-Reply-To: References: Message-ID: On Thu, Dec 15, 2011 at 2:24 AM, Keegan Holley wrote: > I always assumed that taking in more traffic was a bad thing.? I've heard > about one sided peering agreements where one side is sending more traffic > than the other needs them to transport. Am I missing something?? Would this > cause a shift in their favor allowing them to offload more customer traffic > to their peers without complaint? Well, if Level3 wanted less ingress traffic, they would probably stop this practice. I would imagine they thought about it carefully. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From o.calvano at gmail.com Thu Dec 15 02:49:04 2011 From: o.calvano at gmail.com (Olivier CALVANO) Date: Thu, 15 Dec 2011 09:49:04 +0100 Subject: Coloc at Equinix Singapor Message-ID: Hi We search a colocation at Equinix Singapore: 1/4 Rack with in option 1/2 Rack. anyone know of a company that offers this service ? Cordialy Olivier From owen at delong.com Thu Dec 15 04:42:32 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 15 Dec 2011 02:42:32 -0800 Subject: /128 IPv6 prefixs in the wild? In-Reply-To: References: Message-ID: You'll still probably carry the /128 loopbacks in your IGP to deal with your iBGP mesh. Owen On Dec 14, 2011, at 9:54 PM, Glen Kent wrote: > Hi, > > In the service provider networks, would we usually see a large number > of /128 prefixs in the v6 FIB tables? > > In an IP/MPLS world, core routers in the service provider network > learn the /32 loopback IPv4 addresses so that they can establish > BGP/Targetted LDP sessions with those. They then establish LSPs and > VPN tunnels. Since we dont have RSVP for IPv6 and LDP for IPv6 (not > yet RFC) we cannot form MPLS tunnels in a pure IPv6 only network. > GIven this, would v6 routers have large number of /128 prefixes? > > What are the scenarios when IPv6 routers would learn a large number of > /128 prefixes? > > I would presume that most IPv6 prefixes that the routers have to > install are less than /64, since the latter 64 is the host part. Is > this correct? > > Glen From orothschild at gmail.com Thu Dec 15 06:43:44 2011 From: orothschild at gmail.com (Oliver Rothschild) Date: Thu, 15 Dec 2011 07:43:44 -0500 Subject: Range using single-mode SFPs across multi-mode fiber In-Reply-To: References: Message-ID: <157DE274-2C21-43FF-BA45-AFA6049E9A90@gmail.com> Some idiot jumpered runs that existed between 3 different buildings. That person did not know about the 550m limit that we also follow. Sent from my iPhone On Dec 14, 2011, at 22:38, Keegan Holley wrote: > > > > 2011/12/14 oliver rothschild > Thanks to all who responded to my clumsy first question (both on > matters of etiquette and technology). The group I work with (we are a > small project acting as a last mile provider) was in the midst of > deploying this solution when I posed the question. We put the single > mode Juniper SFPs (LX) on to a run of approximately 1670 meters. > > How did you end up with a MM run this long? SX optics are only rated at 500 meters at best. Even with mode conditioning jumpers more the 1km is a risk. I'm glad it held up during testing though. Just out of curiosity did you purchase dark from a provider? Is it inside of a building? From drew.weaver at thenap.com Thu Dec 15 07:04:17 2011 From: drew.weaver at thenap.com (Drew Weaver) Date: Thu, 15 Dec 2011 08:04:17 -0500 Subject: Multiple ISP Load Balancing In-Reply-To: <5D717D6976F4D8498089CBEE22C2EBCD12D78DA6@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM> References: <922ACC42D498884AA02B3565688AF9953402D4EF13@USEXMBS01.mwd.h2o> <5D717D6976F4D8498089CBEE22C2EBCD12D78DA6@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM> Message-ID: This is why I wish they would release it as open source or sell it to someone else, the product really did work well, the kernel in the underlying Linux is the biggest hurdle. Thanks, -Drew -----Original Message----- From: Rampley Jr, Jim F [mailto:jim.rampley at chartercom.com] Sent: Wednesday, December 14, 2011 3:42 PM To: Justin M. Streiner; nanog at nanog.org Subject: RE: Multiple ISP Load Balancing We have specific situations where we have successfully used the Avaya CNA tool (old Route Science Patch Control). Not for load balancing, but for sub second failover from primary to a backup paths over MPLS VPN's. This is done on our internal network where we have MPLS VPN's sometimes over multiple carriers where normal convergence times are 30 seconds to 1 minute across an external provider. It's not easy to setup initially, but once you get it setup and the kinks worked out I've been impressed with its ability to test a path and move traffic at the first hint of trouble. Jim -----Original Message----- From: Justin M. Streiner [mailto:streiner at cluebyfour.org] Sent: Wednesday, December 14, 2011 2:10 PM To: nanog at nanog.org Subject: Re: Multiple ISP Load Balancing On Wed, 14 Dec 2011, Holmes,David A wrote: > From time to time some have posted questions asking if BGP load > balancers such as the old Routescience Pathcontrol device are still > around, and if not what have others found to replace that function. I > have used the Routescience device with much success 10 years ago when > it first came on the market, but since then a full BGP feed has become > much larger, Routescience has been bought by Avaya, then discontinued, > and other competitors such as Sockeye, Netvmg have been acquired by > other companies. It's important to keep in mind what load-balancing is and isn't in this case. The terminology gap can be important because load-balancing (more accurately, load-sharing) in the context of internetwork traffic engineering is very different from load-balancing pools of servers in a data center. Some people can (and sometimes do) confuse the two, which can cause unrealistic expectations to be set :) Achieving a perfect split of network traffic across two or more upstream links rarely happens in the real world. General good practice is to put bandwidth where the network traffic wants to go, but that can be a moving target, and executives and accountants don't like those :) Traffic engineering still has a place on many networks, for a veriety of reasons (technical, financial, political, some combination of these), but as other posters have mentioned, it's often done manually, i.e. looking at Netflow reports, seeing where your traffic is going/coming from, adjusting BGP policies accordingly. Repeat as needed. Since traffic profiles can change over time, any policy tweaks that are put in place need to be reviewed periodically. Depending on how much prep work and planning you're willing to do, you can put a fairly rich set of internal BGP communities in place to control things like localpref, MEDs, selective prepends, and tagging outbound advertisements with provider-specific communities. With that kind of structure, you could control many aspects of your traffic engineering from a route server, rather than having to tinker with route policies on each outside-facing router. One caveat: If your route server crashes or has to be taken down for maintenance, the traffic patterns that were being tweaked by your policy framework could start to revert to the way the traffic would flow in its un-altered state, which could cause you some unintended headaches. jms E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From streiner at cluebyfour.org Thu Dec 15 07:53:18 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 15 Dec 2011 08:53:18 -0500 (EST) Subject: Range using single-mode SFPs across multi-mode fiber In-Reply-To: References: Message-ID: On Wed, 14 Dec 2011, Keegan Holley wrote: > 2011/12/14 oliver rothschild > How did you end up with a MM run this long? SX optics are only rated at > 500 meters at best. Even with mode conditioning jumpers more the 1km is a > risk. I'm glad it held up during testing though. Just out of curiosity > did you purchase dark from a provider? Is it inside of a building? Legacy 10baseFL/100baseFX/FDDI can run fairly long distances over OM1. In the past I've run 100baseFX over OM1 runs with multiple cross-connects, out to about 2 km. jms From bjohnson at drtel.com Thu Dec 15 07:56:04 2011 From: bjohnson at drtel.com (Brian Johnson) Date: Thu, 15 Dec 2011 13:56:04 +0000 Subject: /128 IPv6 prefixes in the wild? Message-ID: I think you will learn a lot of /128s from IGP, but not from eBGP. I consider the "wild" to be the DFZ or similar type of network and in that case, you should not see advertisements for anything longer than a /48. This is not hard and fast, but please correct me if I'm wrong. - Brian J. >-----Original Message----- >From: Mark Tinka [mailto:mtinka at globaltransit.net] >Sent: Thursday, December 15, 2011 12:30 AM >To: nanog at nanog.org >Subject: Re: /128 IPv6 prefixs in the wild? > >On Thursday, December 15, 2011 01:54:56 PM Glen Kent wrote: > >> In an IP/MPLS world, core routers in the service provider >> network learn the /32 loopback IPv4 addresses so that >> they can establish BGP/Targetted LDP sessions with >> those. > >That's right - not sure how things would have been if >'draft-swallow-mpls-aggregate-fec-01' had gained some >traction. > >> They then establish LSPs and VPN tunnels. > >Indeed. > >> Since >> we dont have RSVP for IPv6 and LDP for IPv6 (not yet >> RFC) we cannot form MPLS tunnels in a pure IPv6 only >> network. GIven this, would v6 routers have large number >> of /128 prefixes? >> >> What are the scenarios when IPv6 routers would learn a >> large number of /128 prefixes? > >I suspect ISP's that choose to assign broadband customers >/128 addresses because "they only ever need one address" may >be a situation where you see rise given to this. > >> I would presume that most IPv6 prefixes that the routers >> have to install are less than /64, since the latter 64 >> is the host part. Is this correct? > >This is certainly going to re-open some "wounds", but no, >not all providers are assigning /64 to interfaces. Some >(like us) are using longer prefix lengths such as /112 and >/126. > >But as for /128 prefix lengths, aside from the fact that >Loopbacks will be floating around the network, whether >you're using them to signal MPLS LSP's or setup iBGP >sessions, you will see them with ISP's that assign them to >customers and choose not to aggregate them at specific edge >routers. > >Cheers, > >Mark. From jloiacon at csc.com Thu Dec 15 08:06:35 2011 From: jloiacon at csc.com (Joe Loiacono) Date: Thu, 15 Dec 2011 09:06:35 -0500 Subject: Is AS information useful for security? Message-ID: Is a good knowledge of either origin-AS, or next-AS with respect to flows valuable in establishing, monitoring, or re-enforcing a security posture? In what ways? TIA, Joe From streiner at cluebyfour.org Thu Dec 15 08:07:50 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 15 Dec 2011 09:07:50 -0500 (EST) Subject: De-bogon not possible via arin policy. In-Reply-To: <47067B6B-1026-42CF-A133-A18A70553731@virtualized.org> References: <47067B6B-1026-42CF-A133-A18A70553731@virtualized.org> Message-ID: On Wed, 14 Dec 2011, David Conrad wrote: > I'm confused. When justifying 'need' in an address allocation request, > what difference does it make whether an address in use was allocated by > an RIR or was squatted upon? Last I heard, renumbering out of (say) RFC > 1918 space into public space was still a justification for address > space. Has this changed? I tend to think of squatting in the sense of using a resource (could be an IP address block, could be an empty house, could be just about anything) that the person who is using it does not have permission to do so. I would think that definition holds up even when taking into account that people do not own their IP address allocations. An RIR or ISP assigning address space to a particular entity would establish a legitimate (but not irrevocable) claim to use a block of address space. Squatting is maybe one notch above hijacking in this sense. jms From streiner at cluebyfour.org Thu Dec 15 08:15:36 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 15 Dec 2011 09:15:36 -0500 (EST) Subject: /128 IPv6 prefixs in the wild? In-Reply-To: References: Message-ID: On Thu, 15 Dec 2011, Glen Kent wrote: > In the service provider networks, would we usually see a large number > of /128 prefixs in the v6 FIB tables? If you have /128s on the loopbacks of your routers, your other routers could learn the /128s for the loopbacks of your other routers through your IGP. > What are the scenarios when IPv6 routers would learn a large number of > /128 prefixes? Two questions: 1. What is a 'large number' in this case? 2. Are the addresses from your v6 range(s), or something else that wouldn't be coming from the outside world (link-local, etc)? > I would presume that most IPv6 prefixes that the routers have to > install are less than /64, since the latter 64 is the host part. Is > this correct? Looking at the routing table on one of my lab routers, I only see the /64 for a remote network in its v6 routing table, along with the interface and link-local address of the router it wants to use to reach that destination. I do not see any separate entries for any smaller chunks of that /64. jms From bicknell at ufp.org Thu Dec 15 08:39:56 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 15 Dec 2011 06:39:56 -0800 Subject: /128 IPv6 prefixs in the wild? In-Reply-To: References: Message-ID: <20111215143956.GA73927@ussenterprise.ufp.org> In a message written on Thu, Dec 15, 2011 at 11:24:56AM +0530, Glen Kent wrote: > What are the scenarios when IPv6 routers would learn a large number of > /128 prefixes? In addition to the loopback interfaces already mentioned, you may also see "virtual addresses" of several kinds. For instance an anycasted recursive resolver service may come in as a /128. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From bicknell at ufp.org Thu Dec 15 08:42:37 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 15 Dec 2011 06:42:37 -0800 Subject: local_preference for transit traffic? In-Reply-To: References: Message-ID: <20111215144237.GB73927@ussenterprise.ufp.org> In a message written on Thu, Dec 15, 2011 at 02:24:13AM -0500, Keegan Holley wrote: > I always assumed that taking in more traffic was a bad thing. I've heard > about one sided peering agreements where one side is sending more traffic > than the other needs them to transport. Am I missing something? Would this > cause a shift in their favor allowing them to offload more customer traffic > to their peers without complaint? It's one of many techniques used by peers to "balance" the ratio. However, there may be a simpler explanation. If you bill by the bit as a transit provider it's in your best interest to make sure your customer gets as many bits through you as possible. Plus if you can fill their pipe, they need to buy an upgrade to you. -- 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 streiner at cluebyfour.org Thu Dec 15 08:44:39 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 15 Dec 2011 09:44:39 -0500 (EST) Subject: Is AS information useful for security? In-Reply-To: References: Message-ID: On Thu, 15 Dec 2011, Joe Loiacono wrote: > Is a good knowledge of either origin-AS, or next-AS with respect to flows > valuable in establishing, monitoring, or re-enforcing a security posture? > In what ways? If I'm understanding your question correctly, I think it can be helpful, to a degree. It's always good to 'know your neighbors', but for the most part I don't think an organization's security posture would change very much, based strictly on next-AS. In the case of next-AS, you already know your neighbors somewhat, because you have some sort of a business relationship with them (your transit providers, peers, downstream BGP-speaking customers, etc). origin-AS could be another story. If you know of an AS that is being used by the bad guys for bad purposes, you can write a routing policy to dump all traffic to/from that AS into the bit bucket or take some other action that could be dictated by your security policy. In that case, a routing policy could be considered an extension of a security policy. jms From Bryan at bryanfields.net Thu Dec 15 09:33:48 2011 From: Bryan at bryanfields.net (Bryan Fields) Date: Thu, 15 Dec 2011 10:33:48 -0500 Subject: De-bogon not possible via arin policy. In-Reply-To: References: <47067B6B-1026-42CF-A133-A18A70553731@virtualized.org> Message-ID: <4EEA135C.9080508@bryanfields.net> On 12/15/2011 09:07, Justin M. Streiner wrote: > I tend to think of squatting in the sense of using a resource (could be an > IP address block, could be an empty house, could be just about anything) > that the person who is using it does not have permission to do so. I > would think that definition holds up even when taking into account that > people do not own their IP address allocations. An RIR or ISP assigning > address space to a particular entity would establish a legitimate (but > not irrevocable) claim to use a block of address space. > > Squatting is maybe one notch above hijacking in this sense. Well here's the thing about allocations. All an IP allocation is, is a entry in a data base saying an ORG has a right (from an RIR perspective) to use use an address range. Now a AS can actually use any IP space it wants internally, and if it gets another AS to accept their routes for that IP space and that AS's peers agree to accept those routes, the first AS can actually use that IP space. The RIR or IANA has zero legal authority to stop this as it's just a bunch of private networks agreeing on some one using IP space. Now this gets a lot more fun as we get closer to true IPv4 exhaustion. If there is a business case between two or more providers to side step a RIR process and recognize IP allocations that the RIR does not, who really has the power to stop them? Think about this, if you're a service provider in the US, and the big US networks agree to route your IP space that is actually registered to some network in Kazakhstan according to the RIR's, what will happen? from the service providers perspective the average user will have access to 99% of the US networks (which is really all people want :) and most likely half way decent connectivity to other AS's. Sure, this sucks, but 99% of the people don't care, and still provides better connectivity to services people want than IPv6 does. So follow the money and see how IPv4 exhaustion plays out ;) -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From matthew at matthew.at Thu Dec 15 09:42:40 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 15 Dec 2011 07:42:40 -0800 Subject: De-bogon not possible via arin policy. In-Reply-To: References: <47067B6B-1026-42CF-A133-A18A70553731@virtualized.org> Message-ID: <4EEA1570.6080601@matthew.at> On 12/14/2011 11:14 PM, Jimmy Hess wrote: > On Wed, Dec 14, 2011 at 10:47 PM, David Conrad wrote: > [snip] >> I'm confused. When justifying 'need' in an address allocation request, what difference does it make>whether an address in use was allocated by an RIR or was squatted upon? Last I heard, renumbering>out of (say) RFC 1918 space into public space was still a justification for address space. Has this>changed? > It is a potential network change that could require additional address > space, if an operator plans a complete and immediate renumbering, but > the choice to renumber is not an automatic justification for the same > number of non-RFC1918 IPs as the count of IPs available in their > RFC1918 space networks. > I'm sure the RIRs are not allowing that. > > A RFC1918 network is not a "normal" network; and this is not a > renumbering in the same manner as a renumbering from public IP space > to new public IP space. > > > > > The operator might have to show why they shouldn't renumber their 1918 > network partially, over time, in a manner compatible with the RIR > policy for initial service provider allocations, instead of all at > once. > > In other words: What is the technical justification that all those > rfc1918 addressed hosts suddenly need to be moved immediately, and > not over a normal allocation time frame for new public networks? Here's a simple one involving "squat" space: You have a network that internally is using *all* of 10.0.0.0/8 *and* 5.0.0.0/8 (because you have enough customers to fill two /8s). Now that 5.0.0.0/8 is being allocated, you need to move out of it (so that your users can reach the real 5.0.0.0/8 sites). Why wouldn't this be sufficient justification for a new /8 from ARIN? Matthew Kaufman From Valdis.Kletnieks at vt.edu Thu Dec 15 10:05:27 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 15 Dec 2011 11:05:27 -0500 Subject: De-bogon not possible via arin policy. In-Reply-To: Your message of "Thu, 15 Dec 2011 07:42:40 PST." <4EEA1570.6080601@matthew.at> References: <47067B6B-1026-42CF-A133-A18A70553731@virtualized.org> <4EEA1570.6080601@matthew.at> Message-ID: <27530.1323965127@turing-police.cc.vt.edu> On Thu, 15 Dec 2011 07:42:40 PST, Matthew Kaufman said: > Here's a simple one involving "squat" space: You have a network that > internally is using *all* of 10.0.0.0/8 *and* 5.0.0.0/8 (because you > have enough customers to fill two /8s). > > Now that 5.0.0.0/8 is being allocated, you need to move out of it (so > that your users can reach the real 5.0.0.0/8 sites). > > Why wouldn't this be sufficient justification for a new /8 from ARIN? Because you can probably use the other two 10/8's you already have. And if thiose run out, a third 10/8 is cheap even on the secondary market. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From mtinka at globaltransit.net Thu Dec 15 10:13:17 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Fri, 16 Dec 2011 00:13:17 +0800 Subject: /128 IPv6 prefixes in the wild? In-Reply-To: References: Message-ID: <201112160013.18318.mtinka@globaltransit.net> On Thursday, December 15, 2011 09:56:04 PM Brian Johnson wrote: > I think you will learn a lot of /128s from IGP, but not > from eBGP. I consider the "wild" to be the DFZ or > similar type of network and in that case, you should not > see advertisements for anything longer than a /48. This > is not hard and fast, but please correct me if I'm > wrong. Ideally, yes. Good filtering (against your peers, customers and upstreams) will ensure you keep anything longer than a /48 out of your AS. However, do note that if you provide customer-induced automated blackhole routing (where customers attach an "evil" community to an "evil" host route and send that to you in an eBGP update because you expect it), that's one other way to see /128's (or more appropriately, something longer than a /48) across eBGP sessions with customers. Also, if customers multi-home to you and they want to be able to load share traffic across the various links between their network and yours, you may be inclined to allow them to send longer subnets that have a NO_EXPORT community attached to them so that load sharing occurs within your network for their inbound traffic, but de-aggregated routes do not flood the rest of the Internet. This is another way you could get "longer" routes into your network, with the benefit of not polluting the global Internet. Among other scenarios... :-). Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mtinka at globaltransit.net Thu Dec 15 10:15:50 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Fri, 16 Dec 2011 00:15:50 +0800 Subject: local_preference for transit traffic? In-Reply-To: <20111215144237.GB73927@ussenterprise.ufp.org> References: <20111215144237.GB73927@ussenterprise.ufp.org> Message-ID: <201112160015.50466.mtinka@globaltransit.net> On Thursday, December 15, 2011 10:42:37 PM Leo Bicknell wrote: > However, there may be a simpler explanation. If you bill > by the bit as a transit provider it's in your best > interest to make sure your customer gets as many bits > through you as possible. Plus if you can fill their > pipe, they need to buy an upgrade to you. Indeed. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From drc at virtualized.org Thu Dec 15 10:16:12 2011 From: drc at virtualized.org (David Conrad) Date: Thu, 15 Dec 2011 08:16:12 -0800 Subject: De-bogon not possible via arin policy. In-Reply-To: References: <47067B6B-1026-42CF-A133-A18A70553731@virtualized.org> Message-ID: Jimmy, On Dec 14, 2011, at 11:14 PM, Jimmy Hess wrote: > A RFC1918 network is not a "normal" network; and this is not a > renumbering in the same manner as a renumbering from public IP space > to new public IP space. I'll admit I haven't been following ARIN policy making for some time. Can you point to the ARIN policy that makes this distinction? > In other words: What is the technical justification that all those > rfc1918 addressed hosts suddenly need to be moved immediately, and > not over a normal allocation time frame for new public networks? I used RFC 1918 space as an example. A more likely scenario is needing to renumber out of recently allocated squat space (particularly in situations where RFC 1918 is not an alternative). > That means the RIR has to establish that the criterion is good enough. > "I have a rfc1918 /16 that I use, so give me a public /16, please" > is not good enough. > > That would essentially provide a backdoor around normal RIR justified > need policy, if it were allowed...... Hmm. If one makes the assumption that the (1918/squat) address space is being used in an efficient manner and there is a business/technical requirement to renumber that space into public space, I would have thought the acceptance of justification would depend more on the business/technical requirement, not the fact that 1918/squat space is being used. Regards, -drc From drc at virtualized.org Thu Dec 15 10:24:10 2011 From: drc at virtualized.org (David Conrad) Date: Thu, 15 Dec 2011 08:24:10 -0800 Subject: De-bogon not possible via arin policy. In-Reply-To: References: <47067B6B-1026-42CF-A133-A18A70553731@virtualized.org> Message-ID: On Dec 15, 2011, at 6:07 AM, Justin M. Streiner wrote: > On Wed, 14 Dec 2011, David Conrad wrote: >> I'm confused. When justifying 'need' in an address allocation request, what difference does it make whether an address in use was allocated by an RIR or was squatted upon? Last I heard, renumbering out of (say) RFC 1918 space into public space was still a justification for address space. Has this changed? > > I tend to think of squatting in the sense of using a resource (could be an IP address block, could be an empty house, could be just about anything) that the person who is using it does not have permission to do so. Right, but how does that impact whether or not non-squat space is justified? From my perspective, the actual bit patterns associated with an address in use shouldn't have any impact on the whether or not it is deemed by our ARIN overlords to be needed to be in use. Regards, -drc From keegan.holley at sungard.com Thu Dec 15 10:27:48 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Thu, 15 Dec 2011 11:27:48 -0500 Subject: local_preference for transit traffic? In-Reply-To: <201112160015.50466.mtinka@globaltransit.net> References: <20111215144237.GB73927@ussenterprise.ufp.org> <201112160015.50466.mtinka@globaltransit.net> Message-ID: 2011/12/15 Mark Tinka > On Thursday, December 15, 2011 10:42:37 PM Leo Bicknell > wrote: > > > However, there may be a simpler explanation. If you bill > > by the bit as a transit provider it's in your best > > interest to make sure your customer gets as many bits > > through you as possible. Plus if you can fill their > > pipe, they need to buy an upgrade to you. > > Indeed. > > Forgive my ignorance, but are connections between ISP's normally billed by the bit? I'm a transit AS but not an ISP in the traditional sense, so I just have the normal monthly billing. From drew.weaver at thenap.com Thu Dec 15 10:28:48 2011 From: drew.weaver at thenap.com (Drew Weaver) Date: Thu, 15 Dec 2011 11:28:48 -0500 Subject: Is AS information useful for security? In-Reply-To: References: Message-ID: -----Original Message----- From: Justin M. Streiner [mailto:streiner at cluebyfour.org] Sent: Thursday, December 15, 2011 9:45 AM To: nanog at nanog.org Subject: Re: Is AS information useful for security? >origin-AS could be another story. If you know of an AS that is being used by the bad guys for bad purposes, you can write a routing policy to dump all traffic to/from that AS into the bit bucket or take some other action that could be dictated by your security policy. In that case, a routing policy could be >considered an extension of a security policy. I could be wrong here but I believe origin-AS uses a lookup from the routing table to figure out what the originAS for the source IP should be (and not what it explicitly IS) which means the information is unreliable. For example if someone is sending spoofed packets towards you the origin AS will always show up as the originator of the real route instead of the origin AS of the actual traffic. This is why it would be useful to have the originAS (from the actual origin) in the packet header. Thanks, -Drew From mtinka at globaltransit.net Thu Dec 15 10:42:48 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Fri, 16 Dec 2011 00:42:48 +0800 Subject: local_preference for transit traffic? In-Reply-To: References: <201112160015.50466.mtinka@globaltransit.net> Message-ID: <201112160042.51389.mtinka@globaltransit.net> On Friday, December 16, 2011 12:27:48 AM Keegan Holley wrote: > Forgive my ignorance, but are connections between ISP's > normally billed by the bit? I'm a transit AS but not an > ISP in the traditional sense, so I just have the normal > monthly billing. Per-bit billing, for us, is not a pre-requisite for us to encourage traffic toward our customers to use the transit link they purchase from us. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From bicknell at ufp.org Thu Dec 15 10:48:25 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 15 Dec 2011 08:48:25 -0800 Subject: De-bogon not possible via arin policy. In-Reply-To: References: Message-ID: <20111215164825.GA79952@ussenterprise.ufp.org> In a message written on Wed, Dec 14, 2011 at 01:15:48PM -0800, Cameron Byrne wrote: > But all I can qualify for is a /18, and then in 3 months maybe a /17. This > is called slow start ? For an established business? https://www.arin.net/policy/nrpm.html#four216 You should be able to get a /16 under the "immediate need" policy if you can prove to ARIN you need it and can use it in 30 days or less. Otherwise, yes, the slow-start policies apply. -- 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 matthew at matthew.at Thu Dec 15 10:53:04 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 15 Dec 2011 08:53:04 -0800 Subject: De-bogon not possible via arin policy. In-Reply-To: <27530.1323965127@turing-police.cc.vt.edu> References: <47067B6B-1026-42CF-A133-A18A70553731@virtualized.org> <4EEA1570.6080601@matthew.at> <27530.1323965127@turing-police.cc.vt.edu> Message-ID: <4EEA25F0.3040300@matthew.at> On 12/15/2011 8:05 AM, Valdis.Kletnieks at vt.edu wrote: > On Thu, 15 Dec 2011 07:42:40 PST, Matthew Kaufman said: > >> Here's a simple one involving "squat" space: You have a network that >> internally is using *all* of 10.0.0.0/8 *and* 5.0.0.0/8 (because you >> have enough customers to fill two /8s). >> >> Now that 5.0.0.0/8 is being allocated, you need to move out of it (so >> that your users can reach the real 5.0.0.0/8 sites). >> >> Why wouldn't this be sufficient justification for a new /8 from ARIN? > Because you can probably use the other two 10/8's you already have. > And if thiose run out, a third 10/8 is cheap even on the secondary market. > You're assuming a network architecture which is not required by policy. Matthew Kaufman From network.ipdog at gmail.com Thu Dec 15 11:26:19 2011 From: network.ipdog at gmail.com (Network IP Dog) Date: Thu, 15 Dec 2011 09:26:19 -0800 Subject: FREE!!!111 Net Master Message-ID: <4eea2dc6.d339e70a.57ad.ffff9016@mx.google.com> Hey fellow WWW Zombies, Net Master appears to be Free for a limited? time. http://itunes.apple.com/app/net-master/id470646694?mt=8&affToken=55503 Quite a good tool to have on your if you don't already. Wish there was a Android version... ;^( - Network IPdog E = 4:32 & Cheers!!! From pl+list at pmacct.net Thu Dec 15 11:35:44 2011 From: pl+list at pmacct.net (Paolo Lucente) Date: Thu, 15 Dec 2011 17:35:44 +0000 Subject: Is AS information useful for security? In-Reply-To: References: Message-ID: <20111215173544.GA29641@moussaka.pmacct.net> On Thu, Dec 15, 2011 at 11:28:48AM -0500, Drew Weaver wrote: > I could be wrong here but I believe origin-AS uses a lookup from the routing table to figure out what the originAS for the source IP should be (and not what it explicitly IS) which means the information is unreliable. Using a bit of Cisco jargon, i believe we speak of source peer-AS and asymmetric routing. True what you say but a more accurate information can be achieved by correlation, ie. against the input interface. This leaves open the case of input traffic from a shared medium ie. an IXP. If using sFlow, MAC layer information would be pretty much available for the job; if using NetFlow instead, NetFlow v9 (and IPFIX .. brrr) could come to the rescue .. if was not for lack of implementation of the MAC layer primitives for routed traffic (ie. not switched) by the vendors on the bigger pieces of iron (ie. no ASR1K, software routers, etc.). Cheers, Paolo From surfer at mauigateway.com Thu Dec 15 11:57:31 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 15 Dec 2011 09:57:31 -0800 Subject: De-bogon not possible via arin policy. Message-ID: <20111215095731.2D898B0@m0005312.ppops.net> --- Bryan at bryanfields.net wrote: From: Bryan Fields Now this gets a lot more fun as we get closer to true IPv4 exhaustion. If there is a business case between two or more providers to side step a RIR process and recognize IP allocations that the RIR does not, who really has the power to stop them? -------------------------------------------------- The networking community in general. The usefulness of the space would be very limited. scott From dholmes at mwdh2o.com Thu Dec 15 12:46:53 2011 From: dholmes at mwdh2o.com (Holmes,David A) Date: Thu, 15 Dec 2011 10:46:53 -0800 Subject: Range using single-mode SFPs across multi-mode fiber In-Reply-To: References: Message-ID: <922ACC42D498884AA02B3565688AF9953402D4EFEE@USEXMBS01.mwd.h2o> The max limit for 100 base FX (100 Mbps Ethernet) is around 6600 feet. Many campus ductbank systems built in the 1990s when 10 and 100 Mbps Ethernet were the commodity speeds (before GiGE) used 62.5/125 MM fiber to connect buildings. It is not unusual to see long MM runs on campus facilities where 100 Mbps backbones once were the fastest speeds available. In those days, apart from longhaul telco use, singlemode fiber was usually only run for closed circuit TV (CCTV) use in the campus environment, and in places where 1990s SM was run for CCTV it can still be used for longhaul laser sfps, which to me shows that SM is future proof. SM even makes sense in short runs as attenuators can be placed on the send/receive strands to reduce the dB so the optical receiver is not saturated. -----Original Message----- From: Justin M. Streiner [mailto:streiner at cluebyfour.org] Sent: Thursday, December 15, 2011 5:53 AM To: Keegan Holley Cc: nanog at nanog.org; oliver rothschild Subject: Re: Range using single-mode SFPs across multi-mode fiber On Wed, 14 Dec 2011, Keegan Holley wrote: > 2011/12/14 oliver rothschild > How did you end up with a MM run this long? SX optics are only rated at > 500 meters at best. Even with mode conditioning jumpers more the 1km is a > risk. I'm glad it held up during testing though. Just out of curiosity > did you purchase dark from a provider? Is it inside of a building? Legacy 10baseFL/100baseFX/FDDI can run fairly long distances over OM1. In the past I've run 100baseFX over OM1 runs with multiple cross-connects, out to about 2 km. jms This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system. From mysidia at gmail.com Thu Dec 15 13:12:30 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 15 Dec 2011 13:12:30 -0600 Subject: De-bogon not possible via arin policy. In-Reply-To: <4EEA25F0.3040300@matthew.at> References: <47067B6B-1026-42CF-A133-A18A70553731@virtualized.org> <4EEA1570.6080601@matthew.at> <27530.1323965127@turing-police.cc.vt.edu> <4EEA25F0.3040300@matthew.at> Message-ID: On Thu, Dec 15, 2011 at 10:53 AM, Matthew Kaufman wrote: > On 12/15/2011 8:05 AM, Valdis.Kletnieks at vt.edu wrote: >> On Thu, 15 Dec 2011 07:42:40 PST, Matthew Kaufman said: >>> Here's a simple one involving "squat" space: You have a network that >>> internally is using *all* of 10.0.0.0/8 *and* 5.0.0.0/8 (because you >>> have enough customers to fill two /8s). >>> Now that 5.0.0.0/8 is being allocated, you need to move out of it (so >>> that your users can reach the real 5.0.0.0/8 sites). >>> Why wouldn't this be sufficient justification for a new /8 from ARIN? It is valid justification you may have available to obtain some additional address space from ARIN. Probably not a /8, however. With such a large request, you can be sure the RIR will want to vet it in great detail, and make sure everything is fully justified technically, to the letter and spirit of the policy. If it is, then you get a /8, providing it is available, and the policy is still justified need. If you don't immediately require an entire /8 equivalent, you can expect to get a smaller amount immediately. You are only allowed a 3 months supply, anyways, and you may not get to have the /8 as a single aggregate. The limitation is that "Efficiently utilizing 10.0.0.0/8" or "Efficiently utilizing 5.0.0.0/8" Cannot be used to obtain a /7 or another /8, because 10.0.0.0/8 and 5.0.0.0/8 are not your allocation. If the allocation is not yours, then you cannot apply the policy that says "Efficient utilization of previous blocks assigned and requirement for more addresses" as the justification for more IPs, because 10/8 wasn't assigned to you anyways. You are left having to justify based on number of simultaneous HOSTS on your network, not number of customers. The RIRs do not currently require you to utilize NAT or RFC1918 addresses for hosts on your network, so if you met the requirements, you can justify the allocations required to renumber your entire 10/8 and your entire 5/8 into public IP space, at the rate you intend to renumber them. You however don't get to say "I have 10 million DSL customers", therefore, I get 10 million IPs, right now. >> Because you can probably use the other two 10/8's you already have. >> And if thiose run out, a third 10/8 is cheap even on the secondary market. > You're assuming a network architecture which is not required by policy. > Matthew Kaufman The RIRs do not require you to utilize NAT in the first place. It follows that they also don't require you to segment your network and re-use the same NAT ranges. But in utilizing NAT, you might be utilizing your address space inefficiently, because the pressure to utilize addresses efficiently is reduced by the large size of 1918 space. An example would be having 10 million dialup customers, with hosts that are only transiently connected to a network, and never 10 million simultaneously, each you addressed with a permanent IP. The problem with that, is you only get to assign addresses to addressable objects. When a device is not connected to your network, it is not an addressable object. In obtaining an allocation from an RIR, you can expect to be required to utilize your address space efficiently, which means that devices not connected to your network at any point in time are not hosts, and therefore do not have IP addresses assigned from you. And the number of IP addresses you can justify is related to the number of simultaneous connected devices. -- -JH From jfbeam at gmail.com Thu Dec 15 14:41:21 2011 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 15 Dec 2011 15:41:21 -0500 Subject: De-bogon not possible via arin policy. In-Reply-To: <4EEA1570.6080601@matthew.at> References: <47067B6B-1026-42CF-A133-A18A70553731@virtualized.org> <4EEA1570.6080601@matthew.at> Message-ID: On Thu, 15 Dec 2011 10:42:40 -0500, Matthew Kaufman wrote: > Now that 5.0.0.0/8 is being allocated, you need to move out of it (so > that your users can reach the real 5.0.0.0/8 sites). > > Why wouldn't this be sufficient justification for a new /8 from ARIN? Because it's not ARIN's job to clean up someone else's stupid. You chose to use address space that would eventually be allocated, thus creating a (future) mess for yourself; now you're left to live with it. (For the record, there's no easy way out of that mess now.) From jmalcolm at uraeus.com Thu Dec 15 15:02:33 2011 From: jmalcolm at uraeus.com (Joe Malcolm) Date: Thu, 15 Dec 2011 21:02:33 +0000 Subject: local_preference for transit traffic? In-Reply-To: References: Message-ID: <20202.24681.755161.614903@shoggoth.uraeus.com> Jeff Wheeler writes: >On Thu, Dec 15, 2011 at 1:07 AM, Keegan Holley > wrote: >> Had in interesting conversation with a transit AS on behalf of a customer >> where I found out they are using communities to raise the local preference > >That sounds like a disreputable practice. > >While not quite as obvious, some large transit ASes, like Level3, >reset the origin to I (best) sometime between when they learn it and >when they announce it to their customers and peers. This similarly >causes them to suck in a bit more traffic than they might otherwise. Once upon a time, UUNET did the opposite by setting origin to unknown for peer routes, in an attempt to prefer customer routes over peer routes. We moved to local preference shortly thereafter as it became clear this was "changing" the routes in some meaningful way; if a customer was multihomed to us and another provider, this might affect path selection. (The original thought was that local pref might be too heavyweight, but of course later it became the standard.) Joe From drc at virtualized.org Thu Dec 15 15:36:32 2011 From: drc at virtualized.org (David Conrad) Date: Thu, 15 Dec 2011 13:36:32 -0800 Subject: De-bogon not possible via arin policy. In-Reply-To: References: <47067B6B-1026-42CF-A133-A18A70553731@virtualized.org> <4EEA1570.6080601@matthew.at> Message-ID: On Dec 15, 2011, at 12:41 PM, Ricky Beam wrote: > Because it's not ARIN's job to clean up someone else's stupid. ARIN's job (well, beyond the world travel, publishing comic books, handing out raffle prizes, etc.) is to allocate and register addresses according to community-defined documented policies. I had thought new allocations are based on demonstrated need. The fact that addresses are in use would seem to suggest they're needed. As I've said, I haven't been following ARIN's policy discussions -- can you point me to the policy that says allocations can be denied because you happened to have (demonstrably ill-advisedly) used the wrong bit patterns in setting up your network? Thanks, -drc From bicknell at ufp.org Thu Dec 15 15:43:53 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 15 Dec 2011 13:43:53 -0800 Subject: De-bogon not possible via arin policy. In-Reply-To: References: <47067B6B-1026-42CF-A133-A18A70553731@virtualized.org> <4EEA1570.6080601@matthew.at> Message-ID: <20111215214353.GA91453@ussenterprise.ufp.org> In a message written on Thu, Dec 15, 2011 at 01:36:32PM -0800, David Conrad wrote: > ARIN's job (well, beyond the world travel, publishing comic books, handing out raffle prizes, etc.) is to allocate and register addresses according to community-defined documented policies. I had thought new allocations are based on demonstrated need. The fact that addresses are in use would seem to suggest they're needed. As I've said, I haven't been following ARIN's policy discussions -- can you point me to the policy that says allocations can be denied because you happened to have (demonstrably ill-advisedly) used the wrong bit patterns in setting up your network? The problem is that "in use" means different things to differnet folks. ifconfig em0 inet 10.0.0.1 255.0.0.0 I'm now using 16 million IP addresses at home. ARIN policy does not allow me to get 16 million public IP addresses as a result, based on the 1 machine I have configured at the moment. In the case at hand we don't know if the original poster configured up /16's on p2p links for two hosts each, or if they have an actual host up and pingable at every single IP address. ARIN has a duty to the community to ask these questions, because otherwise anyone could fabricate a "need" for as many addresses as they want. It would seem the original poster and ARIN have a disagrement in this case as to how many IP addresses are required to support their needs. Perhaps incomplete information was provided, perhaps ARIN staff got it wrong. No one on NANOG has enough information to know either way. -- 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 joelja at bogus.com Thu Dec 15 15:54:28 2011 From: joelja at bogus.com (Joel jaeggli) Date: Thu, 15 Dec 2011 13:54:28 -0800 Subject: De-bogon not possible via arin policy. In-Reply-To: <20111215214353.GA91453@ussenterprise.ufp.org> References: <47067B6B-1026-42CF-A133-A18A70553731@virtualized.org> <4EEA1570.6080601@matthew.at> <20111215214353.GA91453@ussenterprise.ufp.org> Message-ID: <4EEA6C94.9020402@bogus.com> On 12/15/11 13:43 , Leo Bicknell wrote: > In a message written on Thu, Dec 15, 2011 at 01:36:32PM -0800, David Conrad wrote: >> ARIN's job (well, beyond the world travel, publishing comic books, handing out raffle prizes, etc.) is to allocate and register addresses according to community-defined documented policies. I had thought new allocations are based on demonstrated need. The fact that addresses are in use would seem to suggest they're needed. As I've said, I haven't been following ARIN's policy discussions -- can you point me to the policy that says allocations can be denied because you happened to have (demonstrably ill-advisedly) used the wrong bit patterns in setting up your network? > > The problem is that "in use" means different things to differnet > folks. > > ifconfig em0 inet 10.0.0.1 255.0.0.0 > > I'm now using 16 million IP addresses at home. ARIN policy does > not allow me to get 16 million public IP addresses as a result, > based on the 1 machine I have configured at the moment. > > In the case at hand we don't know if the original poster configured > up /16's on p2p links for two hosts each, or if they have an actual > host up and pingable at every single IP address. ARIN has a duty to the We know rather alot about the original posters' business, it has ~34 million wireless subscribers in north america. I think it's safe to assume that adequate docuementation could be provided. > community to ask these questions, because otherwise anyone could > fabricate a "need" for as many addresses as they want. > > It would seem the original poster and ARIN have a disagrement in this > case as to how many IP addresses are required to support their needs. > Perhaps incomplete information was provided, perhaps ARIN staff got it > wrong. No one on NANOG has enough information to know either way. > From jsw at inconcepts.biz Thu Dec 15 16:12:23 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Thu, 15 Dec 2011 17:12:23 -0500 Subject: De-bogon not possible via arin policy. In-Reply-To: <4EEA6C94.9020402@bogus.com> References: <47067B6B-1026-42CF-A133-A18A70553731@virtualized.org> <4EEA1570.6080601@matthew.at> <20111215214353.GA91453@ussenterprise.ufp.org> <4EEA6C94.9020402@bogus.com> Message-ID: On Thu, Dec 15, 2011 at 4:54 PM, Joel jaeggli wrote: > We know rather alot about the original posters' business, it has ~34 > million wireless subscribers in north america. I think it's safe to > assume that adequate docuementation could be provided. I missed the post where he supplied this information. I guess his company should have cheated the system, with full complicity of ARIN, like Verizon Wireless did a few years ago. http://marc.info/?l=nanog&m=123406577704970&w=4 -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From stephen at sprunk.org Thu Dec 15 16:24:52 2011 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 15 Dec 2011 16:24:52 -0600 Subject: De-bogon not possible via arin policy. In-Reply-To: <4EEA6C94.9020402@bogus.com> References: <47067B6B-1026-42CF-A133-A18A70553731@virtualized.org> <4EEA1570.6080601@matthew.at> <20111215214353.GA91453@ussenterprise.ufp.org> <4EEA6C94.9020402@bogus.com> Message-ID: <4EEA73B4.5070209@sprunk.org> On 15-Dec-11 15:54, Joel jaeggli wrote: > On 12/15/11 13:43 , Leo Bicknell wrote: >> In a message written on Thu, Dec 15, 2011 at 01:36:32PM -0800, David Conrad wrote: >>> ARIN's job (well, beyond the world travel, publishing comic books, handing out raffle prizes, etc.) is to allocate and register addresses according to community-defined documented policies. I had thought new allocations are based on demonstrated need. The fact that addresses are in use would seem to suggest they're needed. >> The problem is that "in use" means different things to differnet folks. >> >> ifconfig em0 inet 10.0.0.1 255.0.0.0 >> >> I'm now using 16 million IP addresses at home. ARIN policy does not allow me to get 16 million public IP addresses as a result, based on the 1 machine I have configured at the moment. > We know rather alot about the original posters' business, it has ~34 > million wireless subscribers in north america. For those that haven't bothered to look it up, folks appear to be referring to T-Mobile--a Cameron Byrne works there, and they fit the profile given. > I think it's safe to assume that adequate docuementation could be provided. One might assume it /could/ be provided, but so far we have no evidence that it /has/ been provided or, if so, on what grounds ARIN rejected it as being adequate. Heck, so far we have no evidence that any request has even been filed or that the OP is who we think he is. All we have so far is the word of one person, using a Gmail address and the name of a T-Mobile employee, that such addresses were applied for and that ARIN denied the request. I'll also point out that, even if some of the above claims turn out to be true, T-Mobile almost certainly would have required ARIN to sign an NDA (as is customary for any almost any business dealings these days), so ARIN cannot defend itself against the ones that are not, leaving us only with the OP's obviously biased version of events and the ensuing speculation--and the OP probably knew that when he/she posted. Furthermore, it is a fact that not all of T-Mobile's ~34M customers are using IPv4-addressable devices, and they're certainly not all online at the same time, so a simple customer count does /not/ qualify as justification for getting that many addresses. 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 jfbeam at gmail.com Thu Dec 15 16:31:19 2011 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 15 Dec 2011 17:31:19 -0500 Subject: De-bogon not possible via arin policy. In-Reply-To: References: <47067B6B-1026-42CF-A133-A18A70553731@virtualized.org> <4EEA1570.6080601@matthew.at> Message-ID: On Thu, 15 Dec 2011 16:36:32 -0500, David Conrad wrote: > ... I had thought new allocations are based on demonstrated need. The > fact that addresses are in use would seem to suggest they're needed. That depends on how you see their "demontrated need." The way I look at it, if you build your network squatting on someone elses addresses, that's a problem of your own making and does not equate to any "immediate need" on my (channeling ARIN) part. This is a mess they created for themselves and should have known was going to bite them in the ass sooner than later. Translation: they should have started working to resolve this a long time ago. (or never done it in the first place.) And if I may say, they've demonstrated no need at all for public address space. They simply need to stop using 5/8 as if it were 10/8 -- i.e. they need more private address space. They don't need *public* IPv4 space for that. They will need to re-engineer their network to handle the addressing overlaps (ala NAT444.) From bicknell at ufp.org Thu Dec 15 16:32:17 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 15 Dec 2011 14:32:17 -0800 Subject: De-bogon not possible via arin policy. In-Reply-To: <4EEA6C94.9020402@bogus.com> References: <47067B6B-1026-42CF-A133-A18A70553731@virtualized.org> <4EEA1570.6080601@matthew.at> <20111215214353.GA91453@ussenterprise.ufp.org> <4EEA6C94.9020402@bogus.com> Message-ID: <20111215223217.GA92929@ussenterprise.ufp.org> In a message written on Thu, Dec 15, 2011 at 01:54:28PM -0800, Joel jaeggli wrote: > We know rather alot about the original posters' business, it has ~34 > million wireless subscribers in north america. I think it's safe to > assume that adequate docuementation could be provided. As I suspect there are a few confused people here, the OP did not post that information. Google shows Cameron Byrne works at T-Moble USA, per his LinkedIn, and I believe Joel is citing that T-Moble has ~34 Million subscribers, which seems to match some recent info. It appears to me folks are _assuming_ his request to ARIN was for T-Moble, and covered all 34 Million users. Of course that still doesn't mean 34 million IP addresses are required. T-Moble sells phones today that can't do anything IP related (http://www.t-mobile.com/shop/Phones/cell-phone-detail.aspx?cell-phone=Samsung-t139, as an example), and even for the phones that can do IP not all of them are connected at once. I will repeat myself though, we don't know what was submitted to ARIN, or why they responded the way they did. Having the OP come whine to NANOG without us having that information is useless. ARIN's PPML list might be more helpful, or some AC members. Heck, even picking up the phone and talking to ARIN might work better. To bring this back on topic for NANOG though, they need to get it sorted quickly. ARIN shows an equivilent of 5.63 /8's in inventory right now. If 34 million addresses are needed, and can be used to 80% effiency that would require ~2.5 /8's worth of space. It would only take a couple of these sorts of requests and the free pool is gone. -- 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 matthew at matthew.at Thu Dec 15 16:35:33 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 15 Dec 2011 14:35:33 -0800 Subject: De-bogon not possible via arin policy. In-Reply-To: <20111215223217.GA92929@ussenterprise.ufp.org> References: <47067B6B-1026-42CF-A133-A18A70553731@virtualized.org> <4EEA1570.6080601@matthew.at> <20111215214353.GA91453@ussenterprise.ufp.org> <4EEA6C94.9020402@bogus.com> <20111215223217.GA92929@ussenterprise.ufp.org> Message-ID: <4EEA7635.8010109@matthew.at> On 12/15/2011 2:32 PM, Leo Bicknell wrote: > It would only take a couple of these sorts of requests and the free > pool is gone. Personally, I can't wait. Matthew Kaufman From Valdis.Kletnieks at vt.edu Thu Dec 15 16:40:10 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 15 Dec 2011 17:40:10 -0500 Subject: De-bogon not possible via arin policy. In-Reply-To: Your message of "Thu, 15 Dec 2011 14:32:17 PST." <20111215223217.GA92929@ussenterprise.ufp.org> References: <47067B6B-1026-42CF-A133-A18A70553731@virtualized.org> <4EEA1570.6080601@matthew.at> <20111215214353.GA91453@ussenterprise.ufp.org> <4EEA6C94.9020402@bogus.com> <20111215223217.GA92929@ussenterprise.ufp.org> Message-ID: <16204.1323988810@turing-police.cc.vt.edu> On Thu, 15 Dec 2011 14:32:17 PST, Leo Bicknell said: > 80% effiency that would require ~2.5 /8's worth of space. It would only > take a couple of these sorts of requests and the free pool is gone. /me makes some popcorn. This could be fun. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From joelja at bogus.com Thu Dec 15 17:26:20 2011 From: joelja at bogus.com (Joel jaeggli) Date: Thu, 15 Dec 2011 15:26:20 -0800 Subject: De-bogon not possible via arin policy. In-Reply-To: References: <47067B6B-1026-42CF-A133-A18A70553731@virtualized.org> <4EEA1570.6080601@matthew.at> <20111215214353.GA91453@ussenterprise.ufp.org> <4EEA6C94.9020402@bogus.com> Message-ID: <4EEA821C.5010401@bogus.com> On 12/15/11 14:12 , Jeff Wheeler wrote: > On Thu, Dec 15, 2011 at 4:54 PM, Joel jaeggli wrote: >> We know rather alot about the original posters' business, it has ~34 >> million wireless subscribers in north america. I think it's safe to >> assume that adequate docuementation could be provided. > > I missed the post where he supplied this information. I imagine the NANOG community to be small enough that the regular participants should be known to each other. Possibly naive, I know. > I guess his > company should have cheated the system, with full complicity of ARIN, > like Verizon Wireless did a few years ago. > http://marc.info/?l=nanog&m=123406577704970&w=4 I figured the discussion was for illustrative purposes more than anything. From stephen at sprunk.org Thu Dec 15 17:43:05 2011 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 15 Dec 2011 17:43:05 -0600 Subject: De-bogon not possible via arin policy. In-Reply-To: References: <47067B6B-1026-42CF-A133-A18A70553731@virtualized.org> <4EEA1570.6080601@matthew.at> Message-ID: <4EEA8609.5020508@sprunk.org> On 15-Dec-11 16:31, Ricky Beam wrote: > On Thu, 15 Dec 2011 16:36:32 -0500, David Conrad > wrote: >> ... I had thought new allocations are based on demonstrated need. The >> fact that addresses are in use would seem to suggest they're needed. > > That depends on how you see their "demontrated need." The way I look > at it, if you build your network squatting on someone elses addresses, > that's a problem of your own making and does not equate to any > "immediate need" on my (channeling ARIN) part. However, if they actually have the number of hosts claimed, that justifies the space they're asking for. What addresses they're using today is irrelevant. ARIN policy only /suggests/ that they use RFC 1918 space; they are allowed to get public space if they want it. > This is a mess they created for themselves and should have known was > going to bite them in the ass sooner than later. Translation: they > should have started working to resolve this a long time ago. (or never > done it in the first place.) Agreed, but what's done is done. What /should/ have been done is now irrelevant. > And if I may say, they've demonstrated no need at all for public > address space. They simply need to stop using 5/8 as if it were 10/8 > -- i.e. they need more private address space. They don't need > *public* IPv4 space for that. They will need to re-engineer their > network to handle the addressing overlaps (ala NAT444.) Presumably, they "need" to renumber out of 5/8 so that their customers can reach sites legitimately assigned addresses in 5/8. However, those customers seem to have gotten along okay for years without public addresses, so why not renumber them into a second instance of 10/8? When I was in the consulting world, I had one customer with eight instances of 10/8, so I know it's doable. If they want to give every customer a public address, IPv6 provides more than they could ever possibly use--and ~34M new IPv6 eyeballs would give the content industry a nice kick in the pants... 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 cb.list6 at gmail.com Thu Dec 15 18:59:15 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Thu, 15 Dec 2011 16:59:15 -0800 Subject: De-bogon not possible via arin policy. In-Reply-To: <4EEA8609.5020508@sprunk.org> References: <47067B6B-1026-42CF-A133-A18A70553731@virtualized.org> <4EEA1570.6080601@matthew.at> <4EEA8609.5020508@sprunk.org> Message-ID: On Dec 15, 2011 6:43 PM, "Stephen Sprunk" wrote: > > On 15-Dec-11 16:31, Ricky Beam wrote: > > On Thu, 15 Dec 2011 16:36:32 -0500, David Conrad > > wrote: > >> ... I had thought new allocations are based on demonstrated need. The > >> fact that addresses are in use would seem to suggest they're needed. > > > > That depends on how you see their "demontrated need." The way I look > > at it, if you build your network squatting on someone elses addresses, > > that's a problem of your own making and does not equate to any > > "immediate need" on my (channeling ARIN) part. > > However, if they actually have the number of hosts claimed, that > justifies the space they're asking for. What addresses they're using > today is irrelevant. ARIN policy only /suggests/ that they use RFC 1918 > space; they are allowed to get public space if they want it. > Right. But actually getting the space seems to be the issue since the only way space comes out is slow start /18 or immediate need /16? Is that right ? > > This is a mess they created for themselves and should have known was > > going to bite them in the ass sooner than later. Translation: they > > should have started working to resolve this a long time ago. (or never > > done it in the first place.) > > Agreed, but what's done is done. What /should/ have been done is now > irrelevant. > Yes. Hind sight is 20/20... From bag phones to the iPhone, the evolution in cellular data has not been predictable. > > And if I may say, they've demonstrated no need at all for public > > address space. They simply need to stop using 5/8 as if it were 10/8 > > -- i.e. they need more private address space. They don't need > > *public* IPv4 space for that. They will need to re-engineer their > > network to handle the addressing overlaps (ala NAT444.) > > Presumably, they "need" to renumber out of 5/8 so that their customers > can reach sites legitimately assigned addresses in 5/8. > > However, those customers seem to have gotten along okay for years > without public addresses, so why not renumber them into a second > instance of 10/8? When I was in the consulting world, I had one > customer with eight instances of 10/8, so I know it's doable. > Not always. Sometimes backend systems require customers use unique space, and that is really only the tip of that iceberg.... IMS does not work well with duplicate space. > If they want to give every customer a public address, IPv6 provides more > than they could ever possibly use--and ~34M new IPv6 eyeballs would give > the content industry a nice kick in the pants... > Yep. Sometimes I feel I personally preach and promote my ipv6 sermon too the point of being bothersome to the list. Apparently, my good word has not yet reached some. So, for all those that have considered ipv6 as the answer, I suggest you take the bold move of being part of the solution by ensuring your (and however you influence) phone does ipv6 on the cellular network. It is always good to lead by doing. On the T-Mobile USA network, the process is here https://sites.google.com/site/tmoipv6/lg-mytouch While I have not verified it myself, I hear the NEW gsm/umts galaxy nexus does ipv6 on 3g very well. http://www.newegg.com/Product/Product.aspx?Item=N82E16875176322 In all fairness, Verizon LTE has ipv6 as well. Regarding this thread in general, I asked a question about slow start and got a good answer about immediate need. Thanks ! Cb > 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 > From bicknell at ufp.org Thu Dec 15 19:53:46 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 15 Dec 2011 17:53:46 -0800 Subject: De-bogon not possible via arin policy. In-Reply-To: References: <47067B6B-1026-42CF-A133-A18A70553731@virtualized.org> <4EEA1570.6080601@matthew.at> <4EEA8609.5020508@sprunk.org> Message-ID: <20111216015346.GA99339@ussenterprise.ufp.org> In a message written on Thu, Dec 15, 2011 at 04:59:15PM -0800, Cameron Byrne wrote: > Regarding this thread in general, I asked a question about slow start and > got a good answer about immediate need. Thanks ! Note that the "slow-start" is not based on size (as far as I can remember) but on timeframe. That is, if you have a bunch of ARIN blocks you can request a "12 month supply" based on past usage and best predictions. However, if your company has NO IPv4 space and you make your first request you get limited to 3 months worth of address space, 2nd request you get 6 months, and then 12 months with your 3rd and more requests. That's the slow-start. The feeling is that with no track record your predictions are, on average, less likely to be accurate. It's also my understanding that if you use all of the space you can immediately ask for more. Hypothetically, let's say ARIN gives a company with 34M subscribers a /18. Let's say said company can drop it in a DHCP server, and have 100% utilization in oh, a week. At the end of that week the company could submit documentation of 100% utilization to ARIN and get a second block, lather, since, repeat. It's part of the general "chinese buffet" model of ARIN, "Take all you want, but eat all you take." They want to see the eating part. So no, they won't hand you a /8 up front as a new entrant, but if you really can deploy (and document it) that fast you could get a /8's worth of space in a couple of months time. -- 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 eric at roxanne.org Thu Dec 15 20:05:35 2011 From: eric at roxanne.org (Eric) Date: Thu, 15 Dec 2011 21:05:35 -0500 Subject: Is AS information useful for security? In-Reply-To: References: Message-ID: <69E3D76A-8CDF-41E1-9CD8-117CBFD77732@roxanne.org> It's useful in terms of remediation as it can help identify through which "door" packets entered your network. Though, as others will undoubtedly point out, it's trustworthiness will depend upon how you derive the AS mapping and upon other security features (e.g. uRPF) -- Eric :) > On Thu, 15 Dec 2011, Joe Loiacono wrote: > >> Is a good knowledge of either origin-AS, or next-AS with respect to flows >> valuable in establishing, monitoring, or re-enforcing a security posture? >> In what way? From jfbeam at gmail.com Thu Dec 15 21:21:19 2011 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 15 Dec 2011 22:21:19 -0500 Subject: De-bogon not possible via arin policy. In-Reply-To: <4EEA8609.5020508@sprunk.org> References: <47067B6B-1026-42CF-A133-A18A70553731@virtualized.org> <4EEA1570.6080601@matthew.at> <4EEA8609.5020508@sprunk.org> Message-ID: On Thu, 15 Dec 2011 18:43:05 -0500, Stephen Sprunk wrote: > However, if they actually have the number of hosts claimed, that > justifies the space they're asking for. What addresses they're using > today is irrelevant. ARIN policy only /suggests/ that they use RFC 1918 > space; they are allowed to get public space if they want it. Except they've tipped their hand already. If they've been NAT'ing 5/8 for who knows how long, it's clear they don't need public IPv4 space for their network. However, getting public space is easier than building multiple 10/8 private islands. (or so they thought :-)) > However, those customers seem to have gotten along okay for years > without public addresses, so why not renumber them into a second > instance of 10/8? When I was in the consulting world, I had one > customer with eight instances of 10/8, so I know it's doable. And that's my entire point. Thus how they've failed to demonstrate a legitimate need for what little IPv4 space is still available. Maybe they (tmo) should get their european arm to ask RIPE for the entire 5/8 :-) (well, the 3/4th they haven't allocated yet.) --Ricky From bruns at 2mbit.com Thu Dec 15 21:35:34 2011 From: bruns at 2mbit.com (Brielle Bruns) Date: Thu, 15 Dec 2011 20:35:34 -0700 Subject: De-bogon not possible via arin policy. In-Reply-To: References: <47067B6B-1026-42CF-A133-A18A70553731@virtualized.org> <4EEA1570.6080601@matthew.at> Message-ID: <4EEABC86.40800@2mbit.com> On 12/15/11 3:31 PM, Ricky Beam wrote: > On Thu, 15 Dec 2011 16:36:32 -0500, David Conrad > wrote: >> ... I had thought new allocations are based on demonstrated need. The >> fact that addresses are in use would seem to suggest they're needed. > > That depends on how you see their "demontrated need." The way I look at > it, if you build your network squatting on someone elses addresses, > that's a problem of your own making and does not equate to any > "immediate need" on my (channeling ARIN) part. This is a mess they > created for themselves and should have known was going to bite them in > the ass sooner than later. Translation: they should have started working > to resolve this a long time ago. (or never done it in the first place.) > > And if I may say, they've demonstrated no need at all for public address > space. They simply need to stop using 5/8 as if it were 10/8 -- i.e. > they need more private address space. They don't need *public* IPv4 > space for that. They will need to re-engineer their network to handle > the addressing overlaps (ala NAT444.) > Heh, if this is about TMO, then they're squatting on alot more then just 5/8... My phone has an IP address in 22/8, and I've seen it get IPs in 25/8, 26/8 as well. I've always wondered what the deal was with the obviously squatted addresses that my device gets. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From browe at rti.org Thu Dec 15 21:49:19 2011 From: browe at rti.org (Rowe, Brent) Date: Thu, 15 Dec 2011 22:49:19 -0500 Subject: Cybersecurity Investments Survey - request for participation Message-ID: <57BB782DA0EE7D4E9DA4C42A2C3FEFC41326F978@RTPWEXC17.RCC_NT.RTI.ORG> All - See below a solicitation for a NIST-sponsored survey to help identify investments in cyber security that would have the greatest economic impact. All individuals with knowledge of cyber security gaps from an industry perspective are welcome to participate. As an additional incentive, participants will be entered into a raffle for 1 of 10 iPad 2's. Thanks to anyone willing to participate. Feel free to email me with any questions. Brent Rowe, Study Director ------------------------------------------------------------------------ ----------------- ECONOMIC ANALYSIS OF THE U.S. TECHNOLOGY-BASED CYBER SECURITY GAPS - SURVEY INVITATION U.S. industries spend billions of dollars each year securing their information technology (IT) assets. Yet, these businesses still suffer significant economic losses from cyber attacks. Many organizations may not have the technical ability or capacity to identify or address attacks, while other organizations with very complex communications infrastructures may make investments only in response to attacks or breaches. The National Institute of Standards and Technology (NIST) and RTI International are asking IT security managers around the world to participate in a 15-minute survey. Respondents taking the survey will help both the public and private sectors identify inadequacies in the technology-based cybersecurity infrastructure and quantify the economic benefits of these improvements in these areas. Your participation will help ensure that new investments by public agencies and private sector organizations in the cybersecurity infrastructure will be targeted at achieving the greatest economic benefit to organizations such as yours. Go now to https://cybersurvey.rti.org/. To thank you for your participation, you can enter a raffle to win 1 of 10 iPad 2s! We will notify winners by email and telephone in January 2012. For questions or comments about this survey, please contact Igor Pokryshevskiy at (415) 848-1378 (Pacific Time) or igor at rti.org. Brent R. Rowe Senior Economist Technology Economics & Policy RTI International 114 Sansome St., Suite 500 San Francisco, CA 94104 (415) 848-1317 (415) 848-1330 fax -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 64566 bytes Desc: image001.jpg URL: From network.ipdog at gmail.com Fri Dec 16 01:28:55 2011 From: network.ipdog at gmail.com (Network IP Dog) Date: Thu, 15 Dec 2011 23:28:55 -0800 Subject: [sort of off topic] An Open Letter From Internet Engineers to the U.S. Congress Message-ID: <4eeaf344.a24de70a.4da6.ffff9ab0@mx.google.com> I wonder how this will go in the USA and what trickle effect it might have on us if Senator Conroy gets wind of it. An Open Letter From Internet Engineers to the U.S. Congress. https://www.eff.org/deeplinks/2011/12/internet-inventors-warn-against-sopa-a nd-pipa Ephesians 4:32 & Cheers!!! Andy From cb.list6 at gmail.com Fri Dec 16 05:38:28 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Fri, 16 Dec 2011 03:38:28 -0800 Subject: De-bogon not possible via arin policy. In-Reply-To: <4EEABC86.40800@2mbit.com> References: <47067B6B-1026-42CF-A133-A18A70553731@virtualized.org> <4EEA1570.6080601@matthew.at> <4EEABC86.40800@2mbit.com> Message-ID: On Dec 15, 2011 10:35 PM, "Brielle Bruns" wrote: > > On 12/15/11 3:31 PM, Ricky Beam wrote: >> >> On Thu, 15 Dec 2011 16:36:32 -0500, David Conrad >> wrote: >>> >>> ... I had thought new allocations are based on demonstrated need. The >>> fact that addresses are in use would seem to suggest they're needed. >> >> >> That depends on how you see their "demontrated need." The way I look at >> it, if you build your network squatting on someone elses addresses, >> that's a problem of your own making and does not equate to any >> "immediate need" on my (channeling ARIN) part. This is a mess they >> created for themselves and should have known was going to bite them in >> the ass sooner than later. Translation: they should have started working >> to resolve this a long time ago. (or never done it in the first place.) >> >> And if I may say, they've demonstrated no need at all for public address >> space. They simply need to stop using 5/8 as if it were 10/8 -- i.e. >> they need more private address space. They don't need *public* IPv4 >> space for that. They will need to re-engineer their network to handle >> the addressing overlaps (ala NAT444.) >> > > > Heh, if this is about TMO, then they're squatting on alot more then just 5/8... My phone has an IP address in 22/8, and I've seen it get IPs in 25/8, 26/8 as well. > > I've always wondered what the deal was with the obviously squatted addresses that my device gets. > > 5/8 is not used for squat space in this case, somebody along this thread mentioned 5/8 as an example, not a data point. There's an effort to avoid squat space that appears in the dfz. Yes, that is a moving target. Cb > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > From colin.alston at gmail.com Fri Dec 16 07:20:08 2011 From: colin.alston at gmail.com (Colin Alston) Date: Fri, 16 Dec 2011 15:20:08 +0200 Subject: BGP and Firewalls... In-Reply-To: <1F4D60B00DE5FB42AD4BB2BC06DC3092207090B9@mail.shoremortgage.com> References: <1F4D60B00DE5FB42AD4BB2BC06DC3092207090B9@mail.shoremortgage.com> Message-ID: On Wed, Dec 7, 2011 at 7:31 PM, Gregory Croft wrote: > Does anyone have any experience with using firewalls as edge devices > when BGP is concerned? Doing so very successfully with Fortigate devices. From blake at ispn.net Fri Dec 16 08:10:46 2011 From: blake at ispn.net (Blake Hudson) Date: Fri, 16 Dec 2011 08:10:46 -0600 Subject: Overall Netflix bandwidth usage numbers on a network? In-Reply-To: <4EE54B01.6000305@temk.in> References: <20111203004732.GH13315@hijacked.us> <20111203005847.GI13315@hijacked.us> <4EDF9AE9.9040700@ispn.net> <4EE54B01.6000305@temk.in> Message-ID: <4EEB5166.2070702@ispn.net> Requests to this address appear to go unanswered? Dave Temkin wrote the following on 12/11/2011 6:29 PM: > Feel free to contact peering at netflixcom - we're happy to provide > you with delivery statistics for traffic terminating on your network. > > Regards, > -Dave Temkin > Netflix > > On 12/7/11 8:57 AM, Blake Hudson wrote: >> Yeah, that's an interesting one. We currently utilize netflow for >> this, but you also need to consider that netflix streaming is just >> port 80 www traffic. Because netflix uses CDNs, its difficult to pin >> down the traffic to specific hosts in the CDN and say that this >> traffic was netflix, while this traffic was the latest windows update >> (remember this is often a shared hosting platform). We've done our >> own testing and have come to a good solution which uses a combination >> of nbar, packet marking, and netflow to come to a conclusion. On a >> ~160Mbps link, netflix peaks out between 30-50Mbps around 8-10PM each >> evening. The rest of the traffic is predominantly other forms of HTTP >> traffic (including other video streaming services). >> >> >> Martin Hepworth wrote the following on 12/3/2011 2:36 AM: >>> Also checkout Adrian Cockcroft presentations on their architecture >>> which >>> describes how they use aws and CDns etc >>> >>> Martin >>> >>> >> > From dmburgess at linktechs.net Fri Dec 16 08:16:54 2011 From: dmburgess at linktechs.net (Dennis Burgess) Date: Fri, 16 Dec 2011 08:16:54 -0600 Subject: Overall Netflix bandwidth usage numbers on a network? References: <20111203004732.GH13315@hijacked.us> <20111203005847.GI13315@hijacked.us> <4EDF9AE9.9040700@ispn.net> <4EE54B01.6000305@temk.in> <4EEB5166.2070702@ispn.net> Message-ID: <13175F96BDC3B34AB1425BAE905B3CE50D4D8C87@ltiserver.lti.local> Same here. ----------------------------------------------------------- Dennis Burgess, Mikrotik Certified Trainer Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training - Author of "Learn RouterOS" > -----Original Message----- > From: Blake Hudson [mailto:blake at ispn.net] > Sent: Friday, December 16, 2011 8:11 AM > To: Dave Temkin > Cc: nanog at nanog.org > Subject: Re: Overall Netflix bandwidth usage numbers on a network? > > Requests to this address appear to go unanswered? > > Dave Temkin wrote the following on 12/11/2011 6:29 PM: > > Feel free to contact peering at netflixcom - we're happy to provide > > you with delivery statistics for traffic terminating on your network. > > > > Regards, > > -Dave Temkin > > Netflix > > > > On 12/7/11 8:57 AM, Blake Hudson wrote: > >> Yeah, that's an interesting one. We currently utilize netflow for > >> this, but you also need to consider that netflix streaming is just > >> port 80 www traffic. Because netflix uses CDNs, its difficult to pin > >> down the traffic to specific hosts in the CDN and say that this > >> traffic was netflix, while this traffic was the latest windows update > >> (remember this is often a shared hosting platform). We've done our > >> own testing and have come to a good solution which uses a combination > >> of nbar, packet marking, and netflow to come to a conclusion. On a > >> ~160Mbps link, netflix peaks out between 30-50Mbps around 8-10PM > each > >> evening. The rest of the traffic is predominantly other forms of HTTP > >> traffic (including other video streaming services). > >> > >> > >> Martin Hepworth wrote the following on 12/3/2011 2:36 AM: > >>> Also checkout Adrian Cockcroft presentations on their architecture > >>> which describes how they use aws and CDns etc > >>> > >>> Martin > >>> > >>> > >> > > From patrick.sumby at sohonet.co.uk Fri Dec 16 08:16:22 2011 From: patrick.sumby at sohonet.co.uk (Patrick Sumby) Date: Fri, 16 Dec 2011 14:16:22 +0000 Subject: BGP and Firewalls... In-Reply-To: <1F4D60B00DE5FB42AD4BB2BC06DC3092207090B9@mail.shoremortgage.com> References: <1F4D60B00DE5FB42AD4BB2BC06DC3092207090B9@mail.shoremortgage.com> Message-ID: <4EEB52B6.2090604@sohonet.co.uk> We run redundant solutions for a number of our customers and have always decoupled the routing and firewalling. I can think of one situation where the customer manages the BGP and firewall failover on their firewalls, it doesn't work too well. The issue as I see it is that in the event of a device failure if you only have firewalls you need to keep the firewall session states when failing over to the second device, the BGP sessions will not if in an active passive HA setup whereas user traffic states will. If you run in an active active setup, BGP states will remain up however user traffic states will not always be transferred. If you're only using one firewall then this is not going to be an issue but it depends if the solution you're deploying has only redundant connectivity or redundant equipment as well. My experience is mainly using Juniper routers and firewalls so not able to comment on the Palo Alto platform. Decoupling the two functions gives a much better model from an NSP sales perspective as it means you're able to sell failover with no managed equipment / just managed routers / full solution with routers and firewalls. -- --- Patrick Sumby Network Architect Sohonet On 07/12/2011 17:31, Gregory Croft wrote: > Hi All, > > > > Does anyone have any experience with using firewalls as edge devices > when BGP is concerned? > > Specifically the Palo Alto series of devices. > > > > If so please contact me off list. > > > > Thank you. > > > > > > Thank you, > > Gregory S. Croft > > > > > From paul at paulstewart.org Fri Dec 16 08:55:35 2011 From: paul at paulstewart.org (Paul Stewart) Date: Fri, 16 Dec 2011 09:55:35 -0500 Subject: Overall Netflix bandwidth usage numbers on a network? In-Reply-To: <13175F96BDC3B34AB1425BAE905B3CE50D4D8C87@ltiserver.lti.local> References: <20111203004732.GH13315@hijacked.us> <20111203005847.GI13315@hijacked.us> <4EDF9AE9.9040700@ispn.net> <4EE54B01.6000305@temk.in> <4EEB5166.2070702@ispn.net> <13175F96BDC3B34AB1425BAE905B3CE50D4D8C87@ltiserver.lti.local> Message-ID: <3D55217B-C11D-45F9-98EC-FE5D685D55E3@paulstewart.org> I'll take a guess they are back logged - they have been working on our traffic stats since a week before that posting made it to nanog list --- Sent via IPhone On 2011-12-16, at 9:16 AM, "Dennis Burgess" wrote: > Same here. > > ----------------------------------------------------------- > Dennis Burgess, Mikrotik Certified Trainer > Link Technologies, Inc -- Mikrotik & WISP Support Services > Office: 314-735-0270 Website: http://www.linktechs.net > LIVE On-Line Mikrotik Training - Author of "Learn RouterOS" > > >> -----Original Message----- >> From: Blake Hudson [mailto:blake at ispn.net] >> Sent: Friday, December 16, 2011 8:11 AM >> To: Dave Temkin >> Cc: nanog at nanog.org >> Subject: Re: Overall Netflix bandwidth usage numbers on a network? >> >> Requests to this address appear to go unanswered? >> >> Dave Temkin wrote the following on 12/11/2011 6:29 PM: >>> Feel free to contact peering at netflixcom - we're happy to provide >>> you with delivery statistics for traffic terminating on your network. >>> >>> Regards, >>> -Dave Temkin >>> Netflix >>> >>> On 12/7/11 8:57 AM, Blake Hudson wrote: >>>> Yeah, that's an interesting one. We currently utilize netflow for >>>> this, but you also need to consider that netflix streaming is just >>>> port 80 www traffic. Because netflix uses CDNs, its difficult to pin >>>> down the traffic to specific hosts in the CDN and say that this >>>> traffic was netflix, while this traffic was the latest windows update >>>> (remember this is often a shared hosting platform). We've done our >>>> own testing and have come to a good solution which uses a combination >>>> of nbar, packet marking, and netflow to come to a conclusion. On a >>>> ~160Mbps link, netflix peaks out between 30-50Mbps around 8-10PM >> each >>>> evening. The rest of the traffic is predominantly other forms of HTTP >>>> traffic (including other video streaming services). >>>> >>>> >>>> Martin Hepworth wrote the following on 12/3/2011 2:36 AM: >>>>> Also checkout Adrian Cockcroft presentations on their architecture >>>>> which describes how they use aws and CDns etc >>>>> >>>>> Martin >>>>> >>>>> >>>> >>> > From don at sandvine.com Fri Dec 16 09:59:13 2011 From: don at sandvine.com (Don Bowman) Date: Fri, 16 Dec 2011 15:59:13 +0000 Subject: Overall Netflix bandwidth usage numbers on a network? In-Reply-To: <4EDF9AE9.9040700@ispn.net> References: <20111203004732.GH13315@hijacked.us> <20111203005847.GI13315@hijacked.us> <4EDF9AE9.9040700@ispn.net> Message-ID: From: Blake Hudson [mailto:blake at ispn.net] > > Yeah, that's an interesting one. We currently utilize netflow for this, > but you also need to consider that netflix streaming is just port 80 > www traffic. Because netflix uses CDNs, its difficult to pin down the > traffic to specific hosts in the CDN and say that this traffic was > netflix, while this traffic was the latest windows update (remember > this is often a shared hosting platform). We've done our own testing > and have come to a good solution which uses a combination of nbar, > packet marking, and netflow to come to a conclusion. On a ~160Mbps > link, netflix peaks out between 30-50Mbps around 8-10PM each evening. > The rest of the traffic is predominantly other forms of HTTP traffic > (including other video streaming services). We (Sandvine) also have a product that does this measurement in the IP network, per CDN, per device type (e.g. how much Netflix on xbox is on Akamai vs Limelight). In addition it measures the delivered quality per CDN. Anyone can feel free to contact me off list for more information. [cid:image001.jpg at 01CCBBE1.BCF573A0] -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 38015 bytes Desc: image001.jpg URL: From sh.vahabzadeh at gmail.com Fri Dec 16 10:03:41 2011 From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh) Date: Fri, 16 Dec 2011 19:33:41 +0330 Subject: IP Management Software Message-ID: Hi everybody, Can anybody share his/her experience with IP Management software's? Which I can use it managing near 100K IP Address? IPPlan is not good enough, I think its covering all my need and not fully flexible. If you have discuss this before here please share me the link. Thanks -- Regards, Shahab Vahabzadeh, IP Engineer, *nix Admin and Geek From regnauld at nsrc.org Fri Dec 16 10:14:34 2011 From: regnauld at nsrc.org (Phil Regnauld) Date: Fri, 16 Dec 2011 17:14:34 +0100 Subject: IP Management Software In-Reply-To: References: Message-ID: <20111216161434.GT42500@macbook.bluepipe.net> Shahab Vahabzadeh (sh.vahabzadeh) writes: > Hi everybody, > Can anybody share his/her experience with IP Management software's? Which I > can use it managing near 100K IP Address? > IPPlan is not good enough, I think its covering all my need and not fully > flexible. > If you have discuss this before here please share me the link. Hi Shahab, Look at the archives for NANOG - there are plenty of solutions. You might want to look at: - Netdot: https://osl.uoregon.edu/redmine/projects/netdot - TIPP: http://tipp.tobez.org/ Cheers, Phil From me at payam124.com Fri Dec 16 10:16:52 2011 From: me at payam124.com (Payam Poursaied) Date: Fri, 16 Dec 2011 19:46:52 +0330 Subject: IP Management Software In-Reply-To: References: Message-ID: Try noc project On Friday, December 16, 2011, Shahab Vahabzadeh wrote: > Hi everybody, > Can anybody share his/her experience with IP Management software's? Which I > can use it managing near 100K IP Address? > IPPlan is not good enough, I think its > From alter3d at alter3d.ca Fri Dec 16 10:33:50 2011 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Fri, 16 Dec 2011 11:33:50 -0500 Subject: Comcast Mail Admin Message-ID: <4EEB72EE.9010502@alter3d.ca> Apologies to the list for the noise, but if there's a clueful Comcast mail admin on list, can you please get in touch with me off list? My employer's network is having problems sending mail to your domain, and several attempts to clear it up using the "Blocked Provider Request Form" have failed (it looks like the comments I provided on the form aren't being read, as the link I provided to some of our log snippets showing the problem hasn't been hit). Thanks! - Peter Kristolaitis From patrick.sumby at sohonet.co.uk Fri Dec 16 11:40:32 2011 From: patrick.sumby at sohonet.co.uk (Patrick Sumby) Date: Fri, 16 Dec 2011 17:40:32 +0000 Subject: Is AS information useful for security? In-Reply-To: References: Message-ID: <4EEB8290.30501@sohonet.co.uk> On 15/12/2011 16:28, Drew Weaver wrote: > > > -----Original Message----- > From: Justin M. Streiner [mailto:streiner at cluebyfour.org] > Sent: Thursday, December 15, 2011 9:45 AM > To: nanog at nanog.org > Subject: Re: Is AS information useful for security? > >> origin-AS could be another story. If you know of an AS that is being used by the bad guys for bad purposes, you can write a routing policy to dump all traffic to/from that AS into the bit bucket or take some other action that could be dictated by your security policy. In that case, a routing policy could be>considered an extension of a security policy. > > I could be wrong here but I believe origin-AS uses a lookup from the routing table to figure out what the originAS for the source IP should be (and not what it explicitly IS) which means the information is unreliable. > > For example if someone is sending spoofed packets towards you the origin AS will always show up as the originator of the real route instead of the origin AS of the actual traffic. > > This is why it would be useful to have the originAS (from the actual origin) in the packet header. > How would you determine and enforce this? Ok so a packet leaves my network that I know originated from my network based on some factor (IGP route existing or matched prefix list) and the origin AS is put into a new field in the packet header... Whats to stop the spoofer putting that origin AS into their spoofed packet headers? This means that another level of checking then needs to be put into inter AS BGP sessions to make sure that all traffic passing across the link would need to be checked to make sure origin ASs are matched. Couldn't most of the same protection be solved by more people running BCP38 and RPKI? > Thanks, > -Drew > > From packetjockey at gmail.com Fri Dec 16 11:54:40 2011 From: packetjockey at gmail.com (Rafael Rodriguez) Date: Fri, 16 Dec 2011 12:54:40 -0500 Subject: IP Management Software In-Reply-To: References: Message-ID: <0B6EA49C-8F01-4A76-8BAE-C851FAFB1570@gmail.com> Check out 6connect. Sent from my iPhone On Dec 16, 2011, at 11:03, Shahab Vahabzadeh wrote: > Hi everybody, > Can anybody share his/her experience with IP Management software's? Which I > can use it managing near 100K IP Address? > IPPlan is not good enough, I think its covering all my need and not fully > flexible. > If you have discuss this before here please share me the link. > Thanks > > -- > Regards, > Shahab Vahabzadeh, IP Engineer, *nix Admin and Geek From darren at bolding.org Fri Dec 16 12:24:24 2011 From: darren at bolding.org (Darren Bolding) Date: Fri, 16 Dec 2011 10:24:24 -0800 Subject: Wireless/Free Space Enterprise ISP in Palo Alto Message-ID: Apologies if this is not the most appropriate forum for this, but I am not aware of a better list to use. I recently took over responsibility for the network connectivity at an office in downtown Palo Alto (University and Emerson). Unfortunately, and perhaps ironically, the connectivity options here are not as great as I would like- currently they are using DSL, there is no cable service, and lead times for T1's and above are higher than I would like. I have already started the process of getting fiber from the city of Palo Alto between the office and Equinix/S&D/PAIX/529 Bryant, which will resolve the problem. However, the city's time estimate is longer than we need, and experience implies there may be delays. So- I am investigating wireless/free space ISP's in downtown Palo Alto, and also possible options for doing a point-to-point wireless connection between our office and 529 Bryant (I am reaching out to Equinix on this). Any pointers to known good providers, or other suggestions would be very welcome- off list is fine. I am already reaching out to a telecom broker, but wanted to reach out for suggestions. To clarify- I am trying to get either a) rapidly turned up IP transit or b) rapidly turned up point-to-point (presumably wireless) between 529 Bryant/PAIX and the office (University and Emerson). Thanks very much! --D -- -- Darren Bolding -- -- darren at bolding.org -- From jared at puck.nether.net Fri Dec 16 12:33:06 2011 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 16 Dec 2011 13:33:06 -0500 Subject: Wireless/Free Space Enterprise ISP in Palo Alto In-Reply-To: References: Message-ID: <96D69A1C-B933-46E5-B76D-D954EAFAADDB@puck.nether.net> I can't help with most, but for wireless gear check out the ubiquity nanobridge stuff. Cheap fast and good. I've seen these work at 5km range with high speeds (eg: 30-60mbps) when using 40mhz channels. Works well to bridge the last mile in cases where you have access to mount hardware. A pair costs around $180 or so. Jared Mauch On Dec 16, 2011, at 1:24 PM, Darren Bolding wrote: > Apologies if this is not the most appropriate forum for this, but I am not > aware of a better list to use. > > I recently took over responsibility for the network connectivity at an > office in downtown Palo Alto (University and Emerson). Unfortunately, and > perhaps ironically, the connectivity options here are not as great as I > would like- currently they are using DSL, there is no cable service, and > lead times for T1's and above are higher than I would like. > > I have already started the process of getting fiber from the city of Palo > Alto between the office and Equinix/S&D/PAIX/529 Bryant, which will resolve > the problem. However, the city's time estimate is longer than we need, and > experience implies there may be delays. > > So- I am investigating wireless/free space ISP's in downtown Palo Alto, and > also possible options for doing a point-to-point wireless connection > between our office and 529 Bryant (I am reaching out to Equinix on this). > > Any pointers to known good providers, or other suggestions would be very > welcome- off list is fine. I am already reaching out to a telecom broker, > but wanted to reach out for suggestions. > > To clarify- I am trying to get either a) rapidly turned up IP transit or b) > rapidly turned up point-to-point (presumably wireless) between 529 > Bryant/PAIX and the office (University and Emerson). > > Thanks very much! > > --D > > -- > -- Darren Bolding -- > -- darren at bolding.org -- From cscora at apnic.net Fri Dec 16 13:28:34 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 17 Dec 2011 05:28:34 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201112161928.pBGJSY03022610@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 17 Dec, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 387142 Prefixes after maximum aggregation: 167902 Deaggregation factor: 2.31 Unique aggregates announced to Internet: 189021 Total ASes present in the Internet Routing Table: 39612 Prefixes per ASN: 9.77 Origin-only ASes present in the Internet Routing Table: 32512 Origin ASes announcing only one prefix: 15502 Transit ASes present in the Internet Routing Table: 5342 Transit-only ASes present in the Internet Routing Table: 145 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 33 Max AS path prepend of ASN (48687) 24 Prefixes from unregistered ASNs in the Routing Table: 1923 Unregistered ASNs in the Routing Table: 999 Number of 32-bit ASNs allocated by the RIRs: 2095 Number of 32-bit ASNs visible in the Routing Table: 1758 Prefixes from 32-bit ASNs in the Routing Table: 4191 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 90 Number of addresses announced to Internet: 2502485008 Equivalent to 149 /8s, 40 /16s and 228 /24s Percentage of available address space announced: 67.5 Percentage of allocated address space announced: 67.5 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 91.7 Total number of prefixes smaller than registry allocations: 163725 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 95726 Total APNIC prefixes after maximum aggregation: 31275 APNIC Deaggregation factor: 3.06 Prefixes being announced from the APNIC address blocks: 92115 Unique aggregates announced from the APNIC address blocks: 38521 APNIC Region origin ASes present in the Internet Routing Table: 4609 APNIC Prefixes per ASN: 19.99 APNIC Region origin ASes announcing only one prefix: 1248 APNIC Region transit ASes present in the Internet Routing Table: 726 Average APNIC Region AS path length visible: 4.3 Max APNIC Region AS path length visible: 18 Number of APNIC region 32-bit ASNs visible in the Routing Table: 123 Number of APNIC addresses announced to Internet: 631919968 Equivalent to 37 /8s, 170 /16s and 85 /24s Percentage of available APNIC address space announced: 80.1 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-132095, 132096-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, 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: 146548 Total ARIN prefixes after maximum aggregation: 74859 ARIN Deaggregation factor: 1.96 Prefixes being announced from the ARIN address blocks: 118628 Unique aggregates announced from the ARIN address blocks: 48721 ARIN Region origin ASes present in the Internet Routing Table: 14807 ARIN Prefixes per ASN: 8.01 ARIN Region origin ASes announcing only one prefix: 5665 ARIN Region transit ASes present in the Internet Routing Table: 1571 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 25 Number of ARIN region 32-bit ASNs visible in the Routing Table: 14 Number of ARIN addresses announced to Internet: 804460224 Equivalent to 47 /8s, 243 /16s and 22 /24s Percentage of available ARIN address space announced: 63.9 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 95151 Total RIPE prefixes after maximum aggregation: 51645 RIPE Deaggregation factor: 1.84 Prefixes being announced from the RIPE address blocks: 87257 Unique aggregates announced from the RIPE address blocks: 55070 RIPE Region origin ASes present in the Internet Routing Table: 16196 RIPE Prefixes per ASN: 5.39 RIPE Region origin ASes announcing only one prefix: 7990 RIPE Region transit ASes present in the Internet Routing Table: 2575 Average RIPE Region AS path length visible: 4.7 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1222 Number of RIPE addresses announced to Internet: 494441160 Equivalent to 29 /8s, 120 /16s and 146 /24s Percentage of available RIPE address space announced: 79.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 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 36850 Total LACNIC prefixes after maximum aggregation: 7994 LACNIC Deaggregation factor: 4.61 Prefixes being announced from the LACNIC address blocks: 36349 Unique aggregates announced from the LACNIC address blocks: 18889 LACNIC Region origin ASes present in the Internet Routing Table: 1557 LACNIC Prefixes per ASN: 23.35 LACNIC Region origin ASes announcing only one prefix: 443 LACNIC Region transit ASes present in the Internet Routing Table: 284 Average LACNIC Region AS path length visible: 4.5 Max LACNIC Region AS path length visible: 19 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 395 Number of LACNIC addresses announced to Internet: 94826888 Equivalent to 5 /8s, 166 /16s and 241 /24s Percentage of available LACNIC address space announced: 62.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, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 8509 Total AfriNIC prefixes after maximum aggregation: 2057 AfriNIC Deaggregation factor: 4.14 Prefixes being announced from the AfriNIC address blocks: 6551 Unique aggregates announced from the AfriNIC address blocks: 2061 AfriNIC Region origin ASes present in the Internet Routing Table: 498 AfriNIC Prefixes per ASN: 13.15 AfriNIC Region origin ASes announcing only one prefix: 156 AfriNIC Region transit ASes present in the Internet Routing Table: 108 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 4 Number of AfriNIC addresses announced to Internet: 30843648 Equivalent to 1 /8s, 214 /16s and 163 /24s Percentage of available AfriNIC address space announced: 46.0 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2513 11104 971 Korea Telecom (KIX) 17974 1716 503 38 PT TELEKOMUNIKASI INDONESIA 7545 1632 303 86 TPG Internet Pty Ltd 4755 1517 385 158 TATA Communications formerly 7552 1491 1064 7 Vietel Corporation 9829 1170 989 28 BSNL National Internet Backbo 9583 1101 81 494 Sify Limited 4808 1077 2034 304 CNCGROUP IP network: China169 24560 996 385 167 Bharti Airtel Ltd., Telemedia 18101 964 122 157 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 3479 3814 220 bellsouth.net, inc. 7029 2918 1017 200 Windstream Communications Inc 18566 2093 383 177 Covad Communications 1785 1855 680 121 PaeTec Communications, Inc. 4323 1620 1073 386 Time Warner Telecom 20115 1604 1549 626 Charter Communications 22773 1513 2909 105 Cox Communications, Inc. 30036 1460 261 677 Mediacom Communications Corp 19262 1388 4683 401 Verizon Global Networks 7018 1301 7013 852 AT&T WorldNet Services 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 1592 480 15 Corbina telecom 2118 1097 99 14 EUnet/RELCOM Autonomous Syste 15557 1035 2161 64 LDCOM NETWORKS 6830 647 1928 413 UPC Distribution Services 34984 625 132 195 BILISIM TELEKOM 20940 549 177 438 Akamai Technologies European 12479 539 630 48 Uni2 Autonomous System 3320 532 8162 398 Deutsche Telekom AG 3292 480 2106 407 TDC Tele Danmark 8866 462 134 27 Bulgarian Telecommunication C 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 1717 318 155 TVCABLE BOGOTA 28573 1577 1064 75 NET Servicos de Comunicao S.A 8151 1458 2989 347 UniNet S.A. de C.V. 7303 1248 752 176 Telecom Argentina Stet-France 27947 631 73 93 Telconet S.A 22047 582 322 17 VTR PUNTO NET S.A. 6503 555 434 68 AVANTEL, S.A. 7738 551 1050 31 Telecomunicacoes da Bahia S.A 3816 546 237 89 Empresa Nacional de Telecomun 11172 529 102 96 Servicios Alestra S.A de C.V Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1035 958 13 TEDATA 24863 790 146 36 LINKdotNET AS number 3741 281 939 230 The Internet Solution 6713 243 647 17 Itissalat Al-MAGHRIB 15706 242 32 6 Sudatel Internet Exchange Aut 33776 240 13 8 Starcomms Nigeria Limited 29571 217 17 13 Ci Telecom Autonomous system 12258 195 28 60 Vodacom Internet Company 24835 188 80 8 RAYA Telecom - Egypt 16637 160 664 82 MTN Network Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3479 3814 220 bellsouth.net, inc. 7029 2918 1017 200 Windstream Communications Inc 4766 2513 11104 971 Korea Telecom (KIX) 18566 2093 383 177 Covad Communications 1785 1855 680 121 PaeTec Communications, Inc. 10620 1717 318 155 TVCABLE BOGOTA 17974 1716 503 38 PT TELEKOMUNIKASI INDONESIA 7545 1632 303 86 TPG Internet Pty Ltd 4323 1620 1073 386 Time Warner Telecom 20115 1604 1549 626 Charter Communications 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 2918 2718 Windstream Communications Inc 18566 2093 1916 Covad Communications 1785 1855 1734 PaeTec Communications, Inc. 17974 1716 1678 PT TELEKOMUNIKASI INDONESIA 8402 1592 1577 Corbina telecom 10620 1717 1562 TVCABLE BOGOTA 7545 1632 1546 TPG Internet Pty Ltd 4766 2513 1542 Korea Telecom (KIX) 28573 1577 1502 NET Servicos de Comunicao S.A 7552 1491 1484 Vietel Corporation Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 32873 UNALLOCATED 12.46.100.0/23 10912 InterNAP Network Ser 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.0.0/21 12654 RIPE NCC RIS Project 128.0.24.0/24 12654 RIPE NCC RIS Project Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 37.9.192.0/21 25424 INTERNEXT 2000 S.R.O. 37.10.0.0/17 23456 32-bit ASN transition 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.92.0/22 36936 >>UNKNOWN<< 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.21.192.0/20 11610 Internet Nebraska Corporation 64.21.212.0/22 11610 Internet Nebraska Corporation 64.21.216.0/21 11610 Internet Nebraska Corporation 66.129.0.0/19 3901 Higher Technology Services, I Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:12 /10:27 /11:81 /12:237 /13:465 /14:814 /15:1445 /16:12061 /17:6115 /18:10180 /19:20115 /20:27947 /21:28173 /22:38333 /23:35855 /24:201635 /25:1180 /26:1407 /27:784 /28:169 /29:56 /30:14 /31:0 /32:18 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 2546 2918 Windstream Communications Inc 6389 2124 3479 bellsouth.net, inc. 18566 2042 2093 Covad Communications 10620 1612 1717 TVCABLE BOGOTA 8402 1569 1592 Corbina telecom 30036 1420 1460 Mediacom Communications Corp 11492 1105 1142 Cable One 1785 1059 1855 PaeTec Communications, Inc. 7011 1051 1168 Citizens Utilities 15557 991 1035 LDCOM NETWORKS Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:451 2:415 4:15 5:1 6:3 8:360 12:1944 13:1 14:562 15:11 16:3 17:7 20:9 23:74 24:1695 27:1122 31:734 32:67 33:2 34:2 36:4 38:776 39:1 40:114 41:2992 42:78 43:1 44:3 46:1136 47:3 49:278 50:464 52:13 55:5 56:2 57:44 58:958 59:485 60:342 61:1185 62:932 63:1964 64:4112 65:2302 66:4371 67:2005 68:1183 69:3135 70:919 71:378 72:1776 74:2637 75:432 76:319 77:933 78:856 79:442 80:1171 81:848 82:528 83:530 84:570 85:1163 86:733 87:899 88:342 89:1578 90:247 91:4368 92:540 93:1505 94:1321 95:1047 96:397 97:286 98:766 99:38 100:1 101:130 103:561 106:11 107:113 108:99 109:1403 110:672 111:825 112:379 113:490 114:601 115:708 116:887 117:716 118:894 119:1244 120:343 121:674 122:1559 123:1028 124:1379 125:1340 128:556 129:189 130:182 131:584 132:162 133:21 134:225 135:54 136:213 137:151 138:286 139:124 140:493 141:255 142:382 143:388 144:490 145:67 146:477 147:222 148:634 149:273 150:164 151:192 152:445 153:172 154:7 155:382 156:210 157:366 158:155 159:499 160:341 161:221 162:362 163:187 164:521 165:387 166:541 167:459 168:816 169:146 170:829 171:93 172:4 173:1793 174:596 175:416 176:325 177:436 178:1143 180:1204 181:39 182:670 183:251 184:403 185:1 186:1426 187:783 188:954 189:1178 190:5290 192:5981 193:5191 194:4280 195:3364 196:1283 197:173 198:3629 199:4232 200:5512 201:1714 202:8480 203:8509 204:4345 205:2406 206:2668 207:2835 208:4024 209:3560 210:2750 211:1475 212:1972 213:1802 214:800 215:93 216:4927 217:1499 218:584 219:351 220:1250 221:529 222:326 223:264 End of report From bmanning at vacation.karoshi.com Fri Dec 16 13:38:20 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 16 Dec 2011 19:38:20 +0000 Subject: playing NICE Message-ID: <20111216193820.GA1022@vacation.karoshi.com.> http://csrc.nist.gov/nice/framework/ its only a tad over 100 pages. :) the comment period has been extended to january 2012. something to read by the fire over the holiday. /bill From tcannon at c2company.com Fri Dec 16 14:35:11 2011 From: tcannon at c2company.com (Thomas Cannon) Date: Fri, 16 Dec 2011 20:35:11 +0000 Subject: I'm looking for routing/switching guys near the SF Bay Area Message-ID: <18966110-3DEE-4219-9A2A-1851AB850CB0@c2company.com> Preferably with consulting experience. If that's you, please contact me directly. Thanks. Thomas Cannon CCDP, CCNP, BCNE, CISSP tcannon at c2company.com From chip.gwyn at gmail.com Fri Dec 16 15:29:54 2011 From: chip.gwyn at gmail.com (chip) Date: Fri, 16 Dec 2011 16:29:54 -0500 Subject: IP Management Software In-Reply-To: <0B6EA49C-8F01-4A76-8BAE-C851FAFB1570@gmail.com> References: <0B6EA49C-8F01-4A76-8BAE-C851FAFB1570@gmail.com> Message-ID: http://getipv6.info/index.php/IPv6_Management_Tools A good list of stuffs On Fri, Dec 16, 2011 at 12:54 PM, Rafael Rodriguez wrote: > Check out 6connect. > > Sent from my iPhone > > On Dec 16, 2011, at 11:03, Shahab Vahabzadeh wrote: > >> Hi everybody, >> Can anybody share his/her experience with IP Management software's? Which I >> can use it managing near 100K IP Address? >> IPPlan is not good enough, I think its covering all my need and not fully >> flexible. >> If you have discuss this before here please share me the link. >> Thanks >> >> -- >> Regards, >> Shahab Vahabzadeh, IP Engineer, *nix Admin and Geek > -- Just my $.02, your mileage may vary,? batteries not included, etc.... From mwalter at 3z.net Fri Dec 16 15:42:10 2011 From: mwalter at 3z.net (Mike Walter) Date: Fri, 16 Dec 2011 21:42:10 +0000 Subject: IP Management Software In-Reply-To: <0B6EA49C-8F01-4A76-8BAE-C851FAFB1570@gmail.com> References: <0B6EA49C-8F01-4A76-8BAE-C851FAFB1570@gmail.com> Message-ID: +1, agree on 6connect.net. -----Original Message----- From: Rafael Rodriguez [mailto:packetjockey at gmail.com] Sent: Friday, December 16, 2011 12:55 PM To: Shahab Vahabzadeh Cc: nanog at nanog.org Subject: Re: IP Management Software Check out 6connect. Sent from my iPhone On Dec 16, 2011, at 11:03, Shahab Vahabzadeh wrote: > Hi everybody, > Can anybody share his/her experience with IP Management software's? Which I > can use it managing near 100K IP Address? > IPPlan is not good enough, I think its covering all my need and not fully > flexible. > If you have discuss this before here please share me the link. > Thanks > > -- > Regards, > Shahab Vahabzadeh, IP Engineer, *nix Admin and Geek From deleskie at gmail.com Fri Dec 16 15:46:57 2011 From: deleskie at gmail.com (deleskie at gmail.com) Date: Fri, 16 Dec 2011 21:46:57 +0000 Subject: IP Management Software Message-ID: <1699353981-1324072019-cardhu_decombobulator_blackberry.rim.net-244183982-@b3.c17.bise6.blackberry> Not to be a bandwagon jumper but +1 for 6connect as well. ------Original Message------ From: Mike Walter To: nanog at nanog.org Subject: RE: IP Management Software Sent: Dec 16, 2011 4:42 PM +1, agree on 6connect.net. -----Original Message----- From: Rafael Rodriguez [mailto:packetjockey at gmail.com] Sent: Friday, December 16, 2011 12:55 PM To: Shahab Vahabzadeh Cc: nanog at nanog.org Subject: Re: IP Management Software Check out 6connect. Sent from my iPhone On Dec 16, 2011, at 11:03, Shahab Vahabzadeh wrote: > Hi everybody, > Can anybody share his/her experience with IP Management software's? Which I > can use it managing near 100K IP Address? > IPPlan is not good enough, I think its covering all my need and not fully > flexible. > If you have discuss this before here please share me the link. > Thanks > > -- > Regards, > Shahab Vahabzadeh, IP Engineer, *nix Admin and Geek Sent from my BlackBerry device on the Rogers Wireless Network From cidr-report at potaroo.net Fri Dec 16 16:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 16 Dec 2011 22:00:00 GMT Subject: BGP Update Report Message-ID: <201112162200.pBGM00AZ084757@wattle.apnic.net> BGP Update Report Interval: 08-Dec-11 -to- 15-Dec-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS42116 163949 8.9% 3345.9 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 2 - AS8402 44512 2.4% 24.5 -- CORBINA-AS OJSC "Vimpelcom" 3 - AS9829 30388 1.6% 39.4 -- BSNL-NIB National Internet Backbone 4 - AS27738 28941 1.6% 85.1 -- Ecuadortelecom S.A. 5 - AS44568 25931 1.4% 1525.4 -- OPSOURCE-UK OpSource, Inc 6 - AS8163 25030 1.4% 80.7 -- METROTEL REDES S.A. 7 - AS7552 24318 1.3% 16.0 -- VIETEL-AS-AP Vietel Corporation 8 - AS32528 24316 1.3% 4863.2 -- ABBOTT Abbot Labs 9 - AS20632 19939 1.1% 586.4 -- PETERSTAR-AS PeterStar 10 - AS55515 18990 1.0% 791.2 -- ONE-NET-HK INTERNET-SOLUTION -HK 11 - AS24560 14095 0.8% 14.2 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 12 - AS19223 13134 0.7% 13134.0 -- NTEGRATED-SOLUTIONS - Ntegrated Solutions 13 - AS5800 12855 0.7% 46.9 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 14 - AS7465 12846 0.7% 988.2 -- PROCERGS - Cia. de Processamento de Dados do RGS 15 - AS17974 12603 0.7% 8.4 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 16 - AS6072 12586 0.7% 899.0 -- UNISYS-6072 For routing issues, email hostmaster at unisys.com 17 - AS12479 12581 0.7% 63.2 -- UNI2-AS France Telecom Espana SA 18 - AS5400 12104 0.7% 117.5 -- BT BT European Backbone 19 - AS39353 11082 0.6% 3694.0 -- PRINCAST-AS Gobierno del Principado de Asturias 20 - AS17488 10341 0.6% 14.9 -- HATHWAY-NET-AP Hathway IP Over Cable Internet TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS19223 13134 0.7% 13134.0 -- NTEGRATED-SOLUTIONS - Ntegrated Solutions 2 - AS10209 5013 0.3% 5013.0 -- SYNOPSYS-AS-JP-AP Japan HUB and Data Center 3 - AS32528 24316 1.3% 4863.2 -- ABBOTT Abbot Labs 4 - AS37378 4777 0.3% 4777.0 -- NIGERIA-AIRFORCE 5 - AS39353 11082 0.6% 3694.0 -- PRINCAST-AS Gobierno del Principado de Asturias 6 - AS42116 163949 8.9% 3345.9 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 7 - AS44568 25931 1.4% 1525.4 -- OPSOURCE-UK OpSource, Inc 8 - AS7465 12846 0.7% 988.2 -- PROCERGS - Cia. de Processamento de Dados do RGS 9 - AS6072 12586 0.7% 899.0 -- UNISYS-6072 For routing issues, email hostmaster at unisys.com 10 - AS53362 857 0.1% 857.0 -- MIXIT-AS - Mixit, Inc. 11 - AS55515 18990 1.0% 791.2 -- ONE-NET-HK INTERNET-SOLUTION -HK 12 - AS38528 783 0.0% 783.0 -- LANIC-AS-AP Lao National Internet Committee 13 - AS31598 776 0.0% 776.0 -- TELECOMAX-AS TELECOMAX 14 - AS3 3621 0.2% 237.0 -- BORYSZEW BORYSZEW SPOLKA AKCYJNA 15 - AS6066 1368 0.1% 684.0 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc. 16 - AS20632 19939 1.1% 586.4 -- PETERSTAR-AS PeterStar 17 - AS19674 1646 0.1% 548.7 -- NAVPOINT - Navpoint Internet 18 - AS24562 1611 0.1% 537.0 -- UNESCAP-AS-AP The United Nations Economic and Social Commission for Asia and the Pacific (ESCAP) 19 - AS21863 532 0.0% 532.0 -- DMVNOC - Internet Connection 20 - AS25910 526 0.0% 526.0 -- TELTRAX-ARIN - TELTRAX CORP. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 84.204.132.0/24 19840 1.0% AS20632 -- PETERSTAR-AS PeterStar 2 - 67.97.156.0/24 13134 0.7% AS19223 -- NTEGRATED-SOLUTIONS - Ntegrated Solutions 3 - 130.36.34.0/24 12152 0.6% AS32528 -- ABBOTT Abbot Labs 4 - 130.36.35.0/24 12152 0.6% AS32528 -- ABBOTT Abbot Labs 5 - 88.151.16.0/22 11080 0.6% AS39353 -- PRINCAST-AS Gobierno del Principado de Asturias 6 - 46.147.72.0/22 7023 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 7 - 46.147.80.0/22 7022 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 8 - 95.78.20.0/22 7021 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 9 - 95.78.4.0/22 7019 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 10 - 95.78.16.0/22 7017 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 11 - 46.147.76.0/22 7016 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 12 - 95.78.12.0/22 7013 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 13 - 46.147.84.0/22 7010 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 14 - 46.147.92.0/22 6989 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 15 - 46.147.120.0/22 6984 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 16 - 95.78.80.0/22 6973 0.3% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 17 - 95.78.116.0/22 6962 0.3% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 18 - 176.213.100.0/22 6960 0.3% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 19 - 95.78.108.0/22 6955 0.3% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 20 - 95.78.88.0/22 6924 0.3% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 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 cidr-report at potaroo.net Fri Dec 16 16:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 16 Dec 2011 22:00:00 GMT Subject: The Cidr Report Message-ID: <201112162200.pBGM00vU084749@wattle.apnic.net> This report has been generated at Fri Dec 16 21:12:27 2011 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 09-12-11 386491 227371 10-12-11 386600 227223 11-12-11 386365 227383 12-12-11 386687 227266 13-12-11 386830 226854 14-12-11 387006 227323 15-12-11 388632 223854 16-12-11 385889 227871 AS Summary 39706 Number of ASes in routing system 16714 Number of ASes announcing only one prefix 3479 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 109169664 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'). --- 16Dec11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 389158 227932 161226 41.4% All ASes AS6389 3479 223 3256 93.6% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS18566 2093 412 1681 80.3% COVAD - Covad Communications Co. AS4766 2517 994 1523 60.5% KIXS-AS-KR Korea Telecom AS7029 2958 1525 1433 48.4% WINDSTREAM - Windstream Communications Inc AS22773 1513 114 1399 92.5% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1515 213 1302 85.9% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS4323 1622 389 1233 76.0% TWTC - tw telecom holdings, inc. AS28573 1577 399 1178 74.7% NET Servicos de Comunicao S.A. AS1785 1858 785 1073 57.8% AS-PAETEC-NET - PaeTec Communications, Inc. AS7552 1491 438 1053 70.6% VIETEL-AS-AP Vietel Corporation AS19262 1388 402 986 71.0% VZGNI-TRANSIT - Verizon Online LLC AS10620 1717 751 966 56.3% Telmex Colombia S.A. AS2118 1097 144 953 86.9% RELCOM-AS OOO "NPO Relcom" AS7303 1247 362 885 71.0% Telecom Argentina S.A. AS18101 965 158 807 83.6% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS8151 1460 656 804 55.1% Uninet S.A. de C.V. AS30036 1460 685 775 53.1% MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp AS4808 1077 335 742 68.9% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS15557 1035 310 725 70.0% LDCOMNET Societe Francaise du Radiotelephone S.A AS24560 996 279 717 72.0% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7545 1632 947 685 42.0% TPG-INTERNET-AP TPG Internet Pty Ltd AS3356 1105 457 648 58.6% LEVEL3 Level 3 Communications AS17974 1716 1104 612 35.7% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS17676 675 74 601 89.0% GIGAINFRA Softbank BB Corp. AS8402 1446 873 573 39.6% CORBINA-AS OJSC "Vimpelcom" AS4804 663 95 568 85.7% MPX-AS Microplex PTY LTD AS20115 1604 1048 556 34.7% CHARTER-NET-HKY-NC - Charter Communications AS22561 929 378 551 59.3% DIGITAL-TELEPORT - Digital Teleport Inc. AS22047 582 33 549 94.3% VTR BANDA ANCHA S.A. AS9498 854 306 548 64.2% BBIL-AP BHARTI Airtel Ltd. Total 44271 14889 29382 66.4% 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- 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 66.129.0.0/19 AS3901 ARRAKIS - Higher Technology Services 66.175.222.0/23 AS30058 FDCSERVERS - FDCservers.net 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 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 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 80.88.10.0/24 AS33774 DJAWEB 98.159.96.0/20 AS46975 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 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 Inc. 172.45.1.0/24 AS29571 CITelecom-AS 172.45.2.0/24 AS29571 CITelecom-AS 172.45.3.0/24 AS29571 CITelecom-AS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 190.104.32.0/21 AS27882 Telef?nica Celular de Bolivia S.A. 200.6.93.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.94.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.95.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.23.84.0/24 AS8151 Uninet S.A. de C.V. 200.24.73.0/24 AS26061 Equant Colombia 200.33.40.0/24 AS11172 Alestra, S. de R.L. de C.V. 200.34.0.0/20 AS6342 Instituto Tecnol?gico y de Estudios Superiores de Monterrey 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 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.9.55.0/24 AS2764 AAPT AAPT Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 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.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.160.152.0/22 AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 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.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 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - KNOLOGY, Inc. 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.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.91.56.0/21 AS22241 IC2NET - IC2NET 208.91.56.0/24 AS22241 IC2NET - IC2NET 208.91.57.0/24 AS22241 IC2NET - IC2NET 208.91.58.0/24 AS22241 IC2NET - IC2NET 208.91.59.0/24 AS22241 IC2NET - IC2NET 208.91.60.0/24 AS22241 IC2NET - IC2NET 208.91.61.0/24 AS22241 IC2NET - IC2NET 208.91.62.0/24 AS22241 IC2NET - IC2NET 208.91.63.0/24 AS22241 IC2NET - IC2NET 209.133.224.0/19 AS4323 TWTC - tw telecom holdings, inc. 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 209.222.240.0/22 AS19747 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From eric at roxanne.org Fri Dec 16 19:57:56 2011 From: eric at roxanne.org (Eric) Date: Fri, 16 Dec 2011 20:57:56 -0500 Subject: IP Management Software In-Reply-To: <1699353981-1324072019-cardhu_decombobulator_blackberry.rim.net-244183982-@b3.c17.bise6.blackberry> References: <1699353981-1324072019-cardhu_decombobulator_blackberry.rim.net-244183982-@b3.c17.bise6.blackberry> Message-ID: <8F6C6944-0D7B-4371-AAB5-483C46280DDD@roxanne.org> you didn't specify "open source"' so I'll throw out IPControl by BT/INS. I used it at my last place to manage about 100k+ DNS entries (3x /16s, misc blocks, RFC1918) and our DNS/DHCP servers. Worked great but not cheap :) -- Eric :) On Dec 16, 2011, at 4:46 PM, deleskie at gmail.com wrote: > Not to be a bandwagon jumper but +1 for 6connect as well. > ------Original Message------ > From: Mike Walter > To: nanog at nanog.org > Subject: RE: IP Management Software > Sent: Dec 16, 2011 4:42 PM > > +1, agree on 6connect.net. > > -----Original Message----- > From: Rafael Rodriguez [mailto:packetjockey at gmail.com] > Sent: Friday, December 16, 2011 12:55 PM > To: Shahab Vahabzadeh > Cc: nanog at nanog.org > Subject: Re: IP Management Software > > Check out 6connect. > > Sent from my iPhone > > On Dec 16, 2011, at 11:03, Shahab Vahabzadeh wrote: > >> Hi everybody, >> Can anybody share his/her experience with IP Management software's? Which I >> can use it managing near 100K IP Address? >> IPPlan is not good enough, I think its covering all my need and not fully >> flexible. >> If you have discuss this before here please share me the link. >> Thanks >> >> -- >> Regards, >> Shahab Vahabzadeh, IP Engineer, *nix Admin and Geek > > > > > Sent from my BlackBerry device on the Rogers Wireless Network From ravi at cow.org Fri Dec 16 20:13:42 2011 From: ravi at cow.org (Ravi Pina) Date: Fri, 16 Dec 2011 21:13:42 -0500 Subject: IP Management Software In-Reply-To: <0B6EA49C-8F01-4A76-8BAE-C851FAFB1570@gmail.com> References: <0B6EA49C-8F01-4A76-8BAE-C851FAFB1570@gmail.com> Message-ID: <20111217021342.GF50370@neu.cow.org> ++ For many reasons not the least of which is they listen to what their customers need. They run on top of OSS which is great and have the service provider work flow in mind. The only negative is they (at the time of eval) were lacking for enterprise customers, but as I said they listen and are inclined to make improvement to the product. -r On Fri, Dec 16, 2011 at 12:54:40PM -0500, Rafael Rodriguez wrote: > Check out 6connect. > > Sent from my iPhone > > On Dec 16, 2011, at 11:03, Shahab Vahabzadeh wrote: > > > Hi everybody, > > Can anybody share his/her experience with IP Management software's? Which I > > can use it managing near 100K IP Address? > > IPPlan is not good enough, I think its covering all my need and not fully > > flexible. > > If you have discuss this before here please share me the link. > > Thanks > > > > -- > > Regards, > > Shahab Vahabzadeh, IP Engineer, *nix Admin and Geek From mansaxel at besserwisser.org Fri Dec 16 22:35:39 2011 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Sat, 17 Dec 2011 05:35:39 +0100 Subject: IP Management Software In-Reply-To: References: Message-ID: <20111217043539.GH20780@besserwisser.org> Subject: IP Management Software Date: Fri, Dec 16, 2011 at 07:33:41PM +0330 Quoting Shahab Vahabzadeh (sh.vahabzadeh at gmail.com): > Hi everybody, > Can anybody share his/her experience with IP Management software's? Which I > can use it managing near 100K IP Address? > IPPlan is not good enough, I think its covering all my need and not fully > flexible. > If you have discuss this before here please share me the link. I've been impressed by InfoBlox. Main factor behind that is the good integration between DHCP, IP address management and DNS. If you only need IP address management, there probably are other solutions. Also, I've seen no integration with RIR registries. Pricey, as well. We moved from IPPlan, and are a lot happier. In spite of above. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I was born in a Hostess Cupcake factory before the sexual revolution! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From jmamodio at gmail.com Sat Dec 17 00:39:23 2011 From: jmamodio at gmail.com (Jorge Amodio) Date: Sat, 17 Dec 2011 00:39:23 -0600 Subject: playing NICE In-Reply-To: <4eeb9e3f.108b650a.614e.2690SMTPIN_ADDED@mx.google.com> References: <4eeb9e3f.108b650a.614e.2690SMTPIN_ADDED@mx.google.com> Message-ID: With SOPA/PIPA and so much fuss about IP (not the protocol) protection, CBS should sue the government for using an image that looks like a Borg cube from Startrek. -J On Fri, Dec 16, 2011 at 1:38 PM, wrote: > > http://csrc.nist.gov/nice/framework/ > > its only a tad over 100 pages. :) ?the comment period has been extended to january 2012. > > something to read by the fire over the holiday. > > /bill > From mtinka at globaltransit.net Sat Dec 17 02:14:59 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Sat, 17 Dec 2011 16:14:59 +0800 Subject: local_preference for transit traffic? In-Reply-To: <20202.24681.755161.614903@shoggoth.uraeus.com> References: <20202.24681.755161.614903@shoggoth.uraeus.com> Message-ID: <201112171615.02551.mtinka@globaltransit.net> On Friday, December 16, 2011 05:02:33 AM Joe Malcolm wrote: > Once upon a time, UUNET did the opposite by setting > origin to unknown for peer routes, in an attempt to > prefer customer routes over peer routes. We moved to > local preference shortly thereafter as it became clear > this was "changing" the routes in some meaningful way; > if a customer was multihomed to us and another provider, > this might affect path selection. This raises an interesting question we've dealt with many a time in our network - outside of situations mandated by governments or some such, are ISP's happy to peer with their customers (where "peer" = settlement-free exchanging of routes/traffic across public interconnects while "customers" = servicing a commercial IP Transit contract)? Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mpetach at netflight.com Sat Dec 17 10:32:03 2011 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 17 Dec 2011 08:32:03 -0800 Subject: local_preference for transit traffic? In-Reply-To: <201112171615.02551.mtinka@globaltransit.net> References: <20202.24681.755161.614903@shoggoth.uraeus.com> <201112171615.02551.mtinka@globaltransit.net> Message-ID: On Sat, Dec 17, 2011 at 12:14 AM, Mark Tinka wrote: > On Friday, December 16, 2011 05:02:33 AM Joe Malcolm wrote: > >> Once upon a time, UUNET did the opposite by setting >> origin to unknown for peer routes, in an attempt to >> prefer customer routes over peer routes. We moved to >> local preference shortly thereafter as it became clear >> this was "changing" the routes in some meaningful way; >> if a customer was multihomed to us and another provider, >> this might affect path selection. > > This raises an interesting question we've dealt with many a > time in our network - outside of situations mandated by > governments or some such, are ISP's happy to peer with their > customers (where "peer" = settlement-free exchanging of > routes/traffic across public interconnects while "customers" > = servicing a commercial IP Transit contract)? > > Mark. I've been able to negotiate peering+transit relationships with providers, but only by threat of total revenue loss; ie "we currently pay you $x million/year; we want your on-net routes as settlement-free routes, and will continue to pay for off-net transit traffic. Otherwise, we will be transferring all that revenue to your competitor, X" This tends to be effective only for content providers, though, where the outbound traffic dominates, and you don't care if the inbound bits are coming over the "pay for" pipe vs the "settlement free" pipe. If you're an inbound-heavy shop, though, this won't really buy you much benefit. (And, if the revenue point isn't in the $x millions/year for the transit provider, they're more likely to just shrug and say "too much hassle...please, go be a headache for our competitor" rather than configuring a dual relationship like that--so it really only works for higher-volume relationships.) Matt From joelja at bogus.com Sat Dec 17 12:35:37 2011 From: joelja at bogus.com (Joel jaeggli) Date: Sat, 17 Dec 2011 10:35:37 -0800 Subject: local_preference for transit traffic? In-Reply-To: <201112171615.02551.mtinka@globaltransit.net> References: <20202.24681.755161.614903@shoggoth.uraeus.com> <201112171615.02551.mtinka@globaltransit.net> Message-ID: <4EECE0F9.8070606@bogus.com> On 12/17/11 00:14 , Mark Tinka wrote: > On Friday, December 16, 2011 05:02:33 AM Joe Malcolm wrote: > >> Once upon a time, UUNET did the opposite by setting >> origin to unknown for peer routes, in an attempt to >> prefer customer routes over peer routes. We moved to >> local preference shortly thereafter as it became clear >> this was "changing" the routes in some meaningful way; >> if a customer was multihomed to us and another provider, >> this might affect path selection. > > This raises an interesting question we've dealt with many a > time in our network - outside of situations mandated by > governments or some such, are ISP's happy to peer with their > customers (where "peer" = settlement-free exchanging of > routes/traffic across public interconnects while "customers" > = servicing a commercial IP Transit contract)? In the circumstances where I've seen this are rare... We have had transit providers that we used who also peered with us on exchange fabrics for v6 that's about it. > Mark. From joelja at bogus.com Sat Dec 17 12:45:27 2011 From: joelja at bogus.com (Joel jaeggli) Date: Sat, 17 Dec 2011 10:45:27 -0800 Subject: Wireless/Free Space Enterprise ISP in Palo Alto In-Reply-To: References: Message-ID: <4EECE347.5020508@bogus.com> I haven't done wireless in downtown palo alto, only metro-e however. Given your proximity to 345 hamilton (under 1000 feet most likely) I would think at&t would be in a position to offer fairly high-rate dsl, On 12/16/11 10:24 , Darren Bolding wrote: > Apologies if this is not the most appropriate forum for this, but I am not > aware of a better list to use. > > I recently took over responsibility for the network connectivity at an > office in downtown Palo Alto (University and Emerson). Unfortunately, and > perhaps ironically, the connectivity options here are not as great as I > would like- currently they are using DSL, there is no cable service, and > lead times for T1's and above are higher than I would like. > > I have already started the process of getting fiber from the city of Palo > Alto between the office and Equinix/S&D/PAIX/529 Bryant, which will resolve > the problem. However, the city's time estimate is longer than we need, and > experience implies there may be delays. > > So- I am investigating wireless/free space ISP's in downtown Palo Alto, and > also possible options for doing a point-to-point wireless connection > between our office and 529 Bryant (I am reaching out to Equinix on this). > > Any pointers to known good providers, or other suggestions would be very > welcome- off list is fine. I am already reaching out to a telecom broker, > but wanted to reach out for suggestions. > > To clarify- I am trying to get either a) rapidly turned up IP transit or b) > rapidly turned up point-to-point (presumably wireless) between 529 > Bryant/PAIX and the office (University and Emerson). > > Thanks very much! > > --D > From asr at latency.net Sat Dec 17 14:49:46 2011 From: asr at latency.net (Adam Rothschild) Date: Sat, 17 Dec 2011 15:49:46 -0500 Subject: local_preference for transit traffic? In-Reply-To: References: <20202.24681.755161.614903@shoggoth.uraeus.com> <201112171615.02551.mtinka@globaltransit.net> Message-ID: I've had similar experiences to Mr. Petach. Depending on order of operations, you can look at this from a different prospective as well -- why go with a soulless entity for your transit (or transport, collocation, ...) requirements, when you can "keep it in the family" and engage a peer who already understands your service model and is committed to maintaining mutual benefit? Indeed, the old adage of "once a customer, never a peer" could never be wronger. -a From lists at internetpolicyagency.com Sat Dec 17 15:27:03 2011 From: lists at internetpolicyagency.com (Roland Perry) Date: Sat, 17 Dec 2011 21:27:03 +0000 Subject: Sad IPv4 story? In-Reply-To: <4EE6E7D2.8060306@bogus.com> References: <20196.3069.632519.601259@world.std.com> <15282.1323576426@turing-police.cc.vt.edu> <3ADD5AAC-C95A-48CD-8880-F44E799C8A25@eparsonage.com> <4EE6E7D2.8060306@bogus.com> Message-ID: In article <4EE6E7D2.8060306 at bogus.com>, Joel jaeggli writes >> So now we will reap the consequences and it will be at the cost of >> new market entrants (which I am sure will please some people) and >> perhaps cold hard cash for those who cannot expand their business or >> have to 'buy' address space. > >New market entrants are the customers of existing operators, so their >plight and the feasibility of being a new market entrant impacts our >bottom lines. On the three occasions where I've been involved in running a new market entrant they were not previously a customer of an existing operator (other than the founders having an earlier personal online account with someone or other). So it's not always a case of an entrant getting started using someone else's IP transit (and IP addressing), then bringing that in-house. -- Roland Perry From mtinka at globaltransit.net Sun Dec 18 09:55:36 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Sun, 18 Dec 2011 23:55:36 +0800 Subject: local_preference for transit traffic? In-Reply-To: References: <201112171615.02551.mtinka@globaltransit.net> Message-ID: <201112182355.40854.mtinka@globaltransit.net> On Sunday, December 18, 2011 12:32:03 AM Matthew Petach wrote: > I've been able to negotiate peering+transit relationships > with providers, but only by threat of total revenue loss; > ie "we currently pay you $x million/year; we want your > on-net routes as settlement-free routes, and will > continue to pay for off-net transit traffic. Otherwise, > we will be transferring all that revenue to your > competitor, X" If the customer is taking these on-net routes via an exchange point or private peering arrangement, this should be fairly easy to do. If they choose to take it over the same link as their off- net service, not only does the provider need to support a visible way in which these services can be separated over the same wire, but it may also not make much sense for the customer as there is potential for on-net traffic to hog the link, making the case to upgrade the link for traffic that may not necessarily incentivise them to do so. But it's hard to judge this one, especially if the ISP is large with tons of other on-net customers "talking" to the customer negotiating such an arrangement. I can see ISP's accepting to do this if the ratio of on- net:off-net traffic is disproportionate, in favor of more off-net traffic. > This tends to be effective only for > content providers, though, where the outbound traffic > dominates, > and you don't care if the inbound bits are coming > over the "pay for" pipe vs the "settlement free" pipe. It's also mostly useful where the ISP is sufficiently large in a meaningful way for their on-net routes to make any sense to the downstream customer negotiating such an agreement. > If you're an inbound-heavy shop, though, this won't > really buy you much benefit. (And, if the revenue > point isn't in the $x millions/year for the transit > provider, they're more likely to just shrug and say > "too much hassle...please, go be a headache > for our competitor" rather than configuring a > dual relationship like that--so it really only works > for higher-volume relationships.) Maybe what you meant to say is "if the revenue point isn't high enough" :-). Relatively, different ISP's may be kings in their part of town, but still be small enough to accept fewer dollars for such a deal. On the whole, I can envisage cases where trying to fix this "peering with customers" issue can end up causing inadvertent competition with exchange points. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mtinka at globaltransit.net Sun Dec 18 09:56:54 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Sun, 18 Dec 2011 23:56:54 +0800 Subject: local_preference for transit traffic? In-Reply-To: <4EECE0F9.8070606@bogus.com> References: <201112171615.02551.mtinka@globaltransit.net> <4EECE0F9.8070606@bogus.com> Message-ID: <201112182356.55060.mtinka@globaltransit.net> On Sunday, December 18, 2011 02:35:37 AM Joel jaeggli wrote: > In the circumstances where I've seen this are rare... We > have had transit providers that we used who also peered > with us on exchange fabrics for v6 that's about it. Funny, we have something similar :-). But yes, we've seen this in situations where public exchange points are supported by governments, and license holders are "urged" to peer with all members. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mtinka at globaltransit.net Sun Dec 18 10:02:13 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Mon, 19 Dec 2011 00:02:13 +0800 Subject: local_preference for transit traffic? In-Reply-To: References: Message-ID: <201112190002.13951.mtinka@globaltransit.net> On Sunday, December 18, 2011 04:49:46 AM Adam Rothschild wrote: > Indeed, the old adage of "once a customer, never a peer" > could never be wronger. Socially, "once a customer, then a peer, then a customer again" is even more interesting yet. The second instance of "customer" could rise during M&A situations, where an ISP Z peers with ISP A, but buys transit from ISP B. Then ISP A and ISP B decide to merge. But I suppose this is certainly going way off-topic now :-). Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From keegan.holley at sungard.com Sun Dec 18 14:26:57 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Sun, 18 Dec 2011 15:26:57 -0500 Subject: Savvis Route Server/Looking Glass Message-ID: Does anyone know of a working Savvis route server or looking glass. The http://as3561lg.savvis.net/lg.html site doesn't seem to be able to query BGP routes. For example it says they don't have a route to 12.0/9 which seems to be a pretty common aggregate. The traceroute tool works normally though. From jeroen at mompl.net Mon Dec 19 14:23:52 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Mon, 19 Dec 2011 12:23:52 -0800 Subject: Steve Jobs has died In-Reply-To: <201110111717.07171.lowen@pari.edu> References: <2D0AF14BA6FB334988BC1F5D4FC38CB808D13DEF62@EXCHMBX.hq.nac.net> <201110111717.07171.lowen@pari.edu> Message-ID: <4EEF9D58.5060909@mompl.net> Lamar Owen wrote: > On Tuesday, October 11, 2011 04:00:44 PM Douglas Otis wrote: >> products are able to provide good returns. In this view, the analogy >> holds when price alone is not considered. > And, like Edison, Mr. Jobs fiercely championed his own technologies over all others; just one example is in the field of electricity where Edison's DC lost the war to Tesla's AC. Time has yet to tell how well Mr. Jobs' walled garden devices and OS's do, finally. A bit late, but I found this quote in relation to the topic quite interesting and perhaps fitting a not all too uncommon sentiment: http://www.stallman.org/archives/2011-sep-dec.html#27_October_2011_%28Steve_Jobs%29 "Mayor Washington's words (..): When he says that he would hope that I would have all the good qualities of past mayors, there are no good qualities of past mayors to be had. None. None. None. None. I did not mourn at the bier of the late mayor. I regret anyone dying. I have no regrets about him leaving." -- Earthquake Magnitude: 3.4 Date: Monday, December 19, 2011 17:48:20 UTC Location: Southern Alaska Latitude: 61.2449; Longitude: -151.3567 Depth: 94.00 km From rlaager at wiktel.com Mon Dec 19 20:10:23 2011 From: rlaager at wiktel.com (Richard Laager) Date: Mon, 19 Dec 2011 20:10:23 -0600 Subject: Microsoft JMRP (Mail) Admin Needed Message-ID: <1324347023.29883.25.camel@watermelon.coderich.net> I'm trying to sign up for Microsoft's Junk Mail Reporting Program. Multiple representatives keep sending me more-or-less form responses saying they can't add my dynamic customer IP ranges because they're "included in...[a] third party block list". The list in question is the SpamHaus PBL. They clearly don't understand that the SpamHaus PBL (unlike other SpamHaus lists) is not a list of IPs that have sent spam. I'm looking for someone with a clue that can help me. Thanks, Richard Laager Wikstrom Telephone Company P.S. Even ignoring the PBL, this policy of not enrolling IP ranges that are listed on DNSBLs doesn't make a lot of sense to me. Even if the IPs had been sending spam, wouldn't Microsoft want the ISP's help in stopping that? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From sethm at rollernet.us Mon Dec 19 20:13:19 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 19 Dec 2011 18:13:19 -0800 Subject: Microsoft JMRP (Mail) Admin Needed In-Reply-To: <1324347023.29883.25.camel@watermelon.coderich.net> References: <1324347023.29883.25.camel@watermelon.coderich.net> Message-ID: <4EEFEF3F.7050705@rollernet.us> On 12/19/11 6:10 PM, Richard Laager wrote: > I'm trying to sign up for Microsoft's Junk Mail Reporting Program. > Multiple representatives keep sending me more-or-less form > responses saying they can't add my dynamic customer IP ranges > because they're "included in...[a] third party block list". The > list in question is the SpamHaus PBL. > > They clearly don't understand that the SpamHaus PBL (unlike other > SpamHaus lists) is not a list of IPs that have sent spam. I'm > looking for someone with a clue that can help me. > > Thanks, Richard Laager Wikstrom Telephone Company > > P.S. Even ignoring the PBL, this policy of not enrolling IP ranges > that are listed on DNSBLs doesn't make a lot of sense to me. Even > if the IPs had been sending spam, wouldn't Microsoft want the ISP's > help in stopping that? Have you tried removing the addresses in question from the PBL first? ~Seth From mjwise at kapu.net Mon Dec 19 22:41:20 2011 From: mjwise at kapu.net (Michael J Wise) Date: Mon, 19 Dec 2011 20:41:20 -0800 Subject: Microsoft JMRP (Mail) Admin Needed In-Reply-To: <1324347023.29883.25.camel@watermelon.coderich.net> References: <1324347023.29883.25.camel@watermelon.coderich.net> Message-ID: On Dec 19, 2011, at 6:10 PM, Richard Laager wrote: > I'm trying to sign up for Microsoft's Junk Mail Reporting Program. > Multiple representatives keep sending me more-or-less form responses > saying they can't add my dynamic ? Stop right there. Are the IP addresses you are sending mail from Dynamic? Do you *own* those addresses? Why are they, "Dynamic"? Mail should never be coming from Dynamic IP addresses. > ? customer IP ranges because they're > "included in...[a] third party block list". The list in question is the > SpamHaus PBL. > > They clearly don't understand ? They clearly *DO* understand. They know exactly what the PBL is. > that the SpamHaus PBL (unlike other > SpamHaus lists) is not a list of IPs that have sent spam. I'm looking > for someone with a clue that can help me. You need to understand why they are not interested in your traffic as you currently describe your ability to send it. > P.S. Even ignoring the PBL, this policy of not enrolling IP ranges that > are listed on DNSBLs doesn't make a lot of sense to me. Even if the IPs > had been sending spam, wouldn't Microsoft want the ISP's help in > stopping that? They *HAVE* stopped it. :) Already. Aloha, Michael. -- "Please have your Internet License and Usenet Registration handy..." From raviduggal2906 at gmail.com Tue Dec 20 00:27:49 2011 From: raviduggal2906 at gmail.com (Ravi Duggal) Date: Tue, 20 Dec 2011 11:57:49 +0530 Subject: IPv6 RA vs DHCPv6 - The chosen one? Message-ID: Hi, IPv6 devices (routers and hosts) can obtain configuration information about default routers, on-link prefixes and addresses from Router Advertisements as defined in Neighbor Discovery. I have been told that in some deployments, there is a strong desire not to use Router Advertisements at all and to perform all configuration via DHCPv6. There are thus similar IETF standards to get everything that you can get from RAs, by using DHCPv6 instead. As a result of this we see new proposals in IETF that try to do similar things by either extending RA mechanisms or by introducing new options in DHCPv6. We thus have draft-droms-dhc-dhcpv6-default-router-00 that extends DHCPv6 to do what RA does. And now, we have draft-bcd-6man-ntp-server-ra-opt-00.txt that extends RA to advertise the NTP information that is currently done via DHCPv6. My question is, that which then is the more preferred option for the operators? Do they prefer extending RA so that the new information loaded on top of the RA messages gets known in the single shot when routers do neighbor discovery. Or do they prefer all the extra information to be learnt via DHCPv6? What are the pros and cons in each approach and when would people favor one over the other? I can see some advantages with the loading information to RA since then one is not dependent on the DHCPv6 server. However, the latter provides its own benefits. Regards, Ravi D. From rlaager at wiktel.com Tue Dec 20 00:53:35 2011 From: rlaager at wiktel.com (Richard Laager) Date: Tue, 20 Dec 2011 00:53:35 -0600 Subject: Microsoft JMRP (Mail) Admin Needed In-Reply-To: References: <1324347023.29883.25.camel@watermelon.coderich.net> Message-ID: <1324364015.11137.15.camel@watermelon.coderich.net> On Mon, 2011-12-19 at 20:41 -0800, Michael J Wise wrote: > On Dec 19, 2011, at 6:10 PM, Richard Laager wrote: > > > I'm trying to sign up for Microsoft's Junk Mail Reporting Program. > > Multiple representatives keep sending me more-or-less form responses > > saying they can't add my dynamic ? > > Stop right there. > Are the IP addresses you are sending mail from Dynamic? > Do you *own* those addresses? We're an ISP. Let me use an example (with private IPs): We have 10.0.0.0/20 from ARIN. Of that, 10.0.0.0/24 is for our servers, and the rest is used for dynamic pools for residential customers. So we've listed the following ranges in the PBL: 10.0.1.0/24 10.0.2.0/23 10.0.4.0/22 10.0.8.0/21 I want to enroll 10.0.0.0/20 in Microsoft's JMRP. They give me a canned answer about 10.0.1.0-10.0.15.255 being "on a spam list". > Mail should never be coming from Dynamic IP addresses. That's why I've listed my dynamic ranges in the PBL! So yes, nobody *should* be sending mail from these ranges. But if a customer sends spam from one of those ranges anyway, I still want to know about it, so I can notify them to cleanup their infected computer (and disconnect them if necessary). Also, there are a handful of individual IP exceptions to the PBL listings for specific customers with static addresses who are running their own mail servers. Because of that, and the fact that subnets get reassigned from time to time, it'd be best if Microsoft would accept the supernet listing from me, as it'd be one less thing to have to worry about updating every time we make an IP assignment change. I'm not sure why it's necessary to have all these individual "feedback loop" processes anyway. Why can't everyone just send spam reports to the Abuse handles on the relevant WHOIS record? Richard From eyeronic.design at gmail.com Tue Dec 20 00:58:58 2011 From: eyeronic.design at gmail.com (Mike Hale) Date: Mon, 19 Dec 2011 22:58:58 -0800 Subject: Microsoft JMRP (Mail) Admin Needed In-Reply-To: <1324364015.11137.15.camel@watermelon.coderich.net> References: <1324347023.29883.25.camel@watermelon.coderich.net> <1324364015.11137.15.camel@watermelon.coderich.net> Message-ID: "I'm not sure why it's necessary to have all these individual "feedback loop" processes anyway. Why can't everyone just send spam reports to the Abuse handles on the relevant WHOIS record?" Because that only works for organizations who actually do the right thing when they get complaints. That's a poor way to fight spam. On Mon, Dec 19, 2011 at 10:53 PM, Richard Laager wrote: > On Mon, 2011-12-19 at 20:41 -0800, Michael J Wise wrote: > > On Dec 19, 2011, at 6:10 PM, Richard Laager wrote: > > > > > I'm trying to sign up for Microsoft's Junk Mail Reporting Program. > > > Multiple representatives keep sending me more-or-less form responses > > > saying they can't add my dynamic ? > > > > Stop right there. > > Are the IP addresses you are sending mail from Dynamic? > > Do you *own* those addresses? > > We're an ISP. Let me use an example (with private IPs): > > We have 10.0.0.0/20 from ARIN. Of that, 10.0.0.0/24 is for our servers, > and the rest is used for dynamic pools for residential customers. So > we've listed the following ranges in the PBL: > 10.0.1.0/24 > 10.0.2.0/23 > 10.0.4.0/22 > 10.0.8.0/21 > > I want to enroll 10.0.0.0/20 in Microsoft's JMRP. They give me a canned > answer about 10.0.1.0-10.0.15.255 being "on a spam list". > > > Mail should never be coming from Dynamic IP addresses. > > That's why I've listed my dynamic ranges in the PBL! > > So yes, nobody *should* be sending mail from these ranges. But if a > customer sends spam from one of those ranges anyway, I still want to > know about it, so I can notify them to cleanup their infected computer > (and disconnect them if necessary). > > Also, there are a handful of individual IP exceptions to the PBL > listings for specific customers with static addresses who are running > their own mail servers. Because of that, and the fact that subnets get > reassigned from time to time, it'd be best if Microsoft would accept the > supernet listing from me, as it'd be one less thing to have to worry > about updating every time we make an IP assignment change. > > I'm not sure why it's necessary to have all these individual > "feedback loop" processes anyway. Why can't everyone just send spam > reports to the Abuse handles on the relevant WHOIS record? > > Richard > > > -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From ops.lists at gmail.com Tue Dec 20 01:09:29 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 20 Dec 2011 12:39:29 +0530 Subject: Microsoft JMRP (Mail) Admin Needed In-Reply-To: <1324364015.11137.15.camel@watermelon.coderich.net> References: <1324347023.29883.25.camel@watermelon.coderich.net> <1324364015.11137.15.camel@watermelon.coderich.net> Message-ID: On Tue, Dec 20, 2011 at 12:23 PM, Richard Laager wrote: > I'm not sure why it's necessary to have all these individual > "feedback loop" processes anyway. Why can't everyone just send spam > reports to the Abuse handles on the relevant WHOIS record? Feedback loops are sent in machine parseable formats like ARF (RFC 5965) to separate, dedicated mailboxes that are read by scripts which then process the reports to automate whatever action needs to be taken for AUP enforcement, filtering etc. Every single report spam click by a user on hotmail, yahoo etc is fed through their feedback loops (like JMRPP for hotmail) abuse mailboxes are read by ISP support staff and complaints are manually handled. -- Suresh Ramasubramanian (ops.lists at gmail.com) From rlaager at wiktel.com Tue Dec 20 01:12:06 2011 From: rlaager at wiktel.com (Richard Laager) Date: Tue, 20 Dec 2011 01:12:06 -0600 Subject: Microsoft JMRP (Mail) Admin Needed In-Reply-To: References: <1324347023.29883.25.camel@watermelon.coderich.net> <1324364015.11137.15.camel@watermelon.coderich.net> Message-ID: <1324365126.11137.25.camel@watermelon.coderich.net> On Mon, 2011-12-19 at 22:58 -0800, Mike Hale wrote: > "I'm not sure why it's necessary to have all these individual > "feedback loop" processes anyway. Why can't everyone just send spam > reports to the Abuse handles on the relevant WHOIS record?" > Because that only works for organizations who actually do the right > thing when they get complaints. That's a poor way to fight spam. All* the feedback loop concept does is waste a lot of administrative time on both sides to avoid sending spam reports to organizations which have setup abuse handles but not signed up for that particular feedback loop. Given that sending complaint emails to the abuse handle is virtually cost free, I don't see what's gained by not sending them. What the organization does with those complaints when they receive them is unaffected by the mechanism that routes the complaints to them. Richard * I suspect that someone's lawyers would say that feedback loop processes allow organizations to require agreement to some set of terms (confidentiality, etc.) before receiving the reports and that this is a useful benefit. I disagree, given that you're sending the report to someone who almost certainly could've captured the original email as it transited their network. From rlaager at wiktel.com Tue Dec 20 01:19:39 2011 From: rlaager at wiktel.com (Richard Laager) Date: Tue, 20 Dec 2011 01:19:39 -0600 Subject: Microsoft JMRP (Mail) Admin Needed In-Reply-To: References: <1324347023.29883.25.camel@watermelon.coderich.net> <1324364015.11137.15.camel@watermelon.coderich.net> Message-ID: <1324365579.11137.30.camel@watermelon.coderich.net> On Tue, 2011-12-20 at 12:39 +0530, Suresh Ramasubramanian wrote: > On Tue, Dec 20, 2011 at 12:23 PM, Richard Laager wrote: > > I'm not sure why it's necessary to have all these individual > > "feedback loop" processes anyway. Why can't everyone just send spam > > reports to the Abuse handles on the relevant WHOIS record? > > Feedback loops are sent in machine parseable formats ... > abuse mailboxes are read by ISP support staff and complaints are > manually handled. If the feedback loop complaints are machine parseable, then by definition a machine can parse the abuse mail stream and separate out the feedback loop complaints for automated handling before sending the rest to the human team. > Every single report spam click by > a user on hotmail, yahoo etc is fed through their feedback loops (like > JMRPP for hotmail) I think the implied point here is that this can be a LOT of mail and that obtaining the recipient's consent is desirable before sending them this volume of mail? If so, I think that's a fair point. On the other hand, the complaints are in response to messages their network sent in the first place. Richard -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From owen at delong.com Tue Dec 20 01:31:15 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 19 Dec 2011 23:31:15 -0800 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: Message-ID: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> Different operators will have different preferences in different environments. Ideally, the IETF should provide complete solutions based on DHCPv6 and on RA and let the operators decide what they want to use in their environments. Owen On Dec 19, 2011, at 10:27 PM, Ravi Duggal wrote: > Hi, > > IPv6 devices (routers and hosts) can obtain configuration information > about default routers, on-link prefixes and addresses from Router > Advertisements as defined in Neighbor Discovery. I have been told > that in some deployments, there is a strong desire not to use Router > Advertisements at all and to perform all configuration via DHCPv6. > There are thus similar IETF standards to get everything that you can > get from RAs, by using DHCPv6 instead. > > As a result of this we see new proposals in IETF that try to do > similar things by either extending RA mechanisms or by introducing new > options in DHCPv6. > > We thus have draft-droms-dhc-dhcpv6-default-router-00 that extends > DHCPv6 to do what RA does. And now, we have > draft-bcd-6man-ntp-server-ra-opt-00.txt that extends RA to advertise > the NTP information that is currently done via DHCPv6. > > My question is, that which then is the more preferred option for the > operators? Do they prefer extending RA so that the new information > loaded on top of the RA messages gets known in the single shot when > routers do neighbor discovery. Or do they prefer all the extra > information to be learnt via DHCPv6? What are the pros and cons in > each approach and when would people favor one over the other? > > I can see some advantages with the loading information to RA since > then one is not dependent on the DHCPv6 server. However, the latter > provides its own benefits. > > Regards, > Ravi D. From ops.lists at gmail.com Tue Dec 20 01:37:57 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 20 Dec 2011 13:07:57 +0530 Subject: Microsoft JMRP (Mail) Admin Needed In-Reply-To: <1324365579.11137.30.camel@watermelon.coderich.net> References: <1324347023.29883.25.camel@watermelon.coderich.net> <1324364015.11137.15.camel@watermelon.coderich.net> <1324365579.11137.30.camel@watermelon.coderich.net> Message-ID: Sure. But it is common courtesy to ask an abuse desk first, rather than, say, flood their ticketing system with automated alerts. On Tue, Dec 20, 2011 at 12:49 PM, Richard Laager wrote: > > I think the implied point here is that this can be a LOT of mail and > that obtaining the recipient's consent is desirable before sending them > this volume of mail? If so, I think that's a fair point. On the other > hand, the complaints are in response to messages their network sent in > the first place. -- Suresh Ramasubramanian (ops.lists at gmail.com) From mohacsi at niif.hu Tue Dec 20 02:08:07 2011 From: mohacsi at niif.hu (Mohacsi Janos) Date: Tue, 20 Dec 2011 09:08:07 +0100 (CET) Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> Message-ID: On Mon, 19 Dec 2011, Owen DeLong wrote: > Different operators will have different preferences in different environments. > > Ideally, the IETF should provide complete solutions based on DHCPv6 and > on RA and let the operators decide what they want to use in their environments. Agree. Selection also influenced by the availability of the particular feature on a particular environments and habits of the operators. Best Regards, Janos Mohacsi > > Owen > > On Dec 19, 2011, at 10:27 PM, Ravi Duggal wrote: > >> Hi, >> >> IPv6 devices (routers and hosts) can obtain configuration information >> about default routers, on-link prefixes and addresses from Router >> Advertisements as defined in Neighbor Discovery. I have been told >> that in some deployments, there is a strong desire not to use Router >> Advertisements at all and to perform all configuration via DHCPv6. >> There are thus similar IETF standards to get everything that you can >> get from RAs, by using DHCPv6 instead. >> >> As a result of this we see new proposals in IETF that try to do >> similar things by either extending RA mechanisms or by introducing new >> options in DHCPv6. >> >> We thus have draft-droms-dhc-dhcpv6-default-router-00 that extends >> DHCPv6 to do what RA does. And now, we have >> draft-bcd-6man-ntp-server-ra-opt-00.txt that extends RA to advertise >> the NTP information that is currently done via DHCPv6. >> >> My question is, that which then is the more preferred option for the >> operators? Do they prefer extending RA so that the new information >> loaded on top of the RA messages gets known in the single shot when >> routers do neighbor discovery. Or do they prefer all the extra >> information to be learnt via DHCPv6? What are the pros and cons in >> each approach and when would people favor one over the other? >> >> I can see some advantages with the loading information to RA since >> then one is not dependent on the DHCPv6 server. However, the latter >> provides its own benefits. >> >> Regards, >> Ravi D. > > > From glen.kent at gmail.com Tue Dec 20 03:58:24 2011 From: glen.kent at gmail.com (Glen Kent) Date: Tue, 20 Dec 2011 15:28:24 +0530 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: Message-ID: When a router needs to learn information from another router it will *usually* use the RA messages and not DHCPv6, as the latter is *usually* meant for Router - Host communication. However, it is NOT uncommon to see hosts also learning the information using RA messages. Router's afaik dont usually act as DHCP clients and thus information that can only be passed in DHCPv6 may not be available to the routers, and you may need an alternate mechanism. Glen On Tue, Dec 20, 2011 at 11:57 AM, Ravi Duggal wrote: > Hi, > > IPv6 devices (routers and hosts) can obtain configuration information > about default routers, on-link prefixes and addresses from Router > Advertisements as defined in ? Neighbor Discovery. ?I have been told > that in some deployments, there is a strong desire not to use Router > Advertisements at all and to perform all configuration via DHCPv6. > There are thus similar IETF standards to get everything that you can > get from RAs, by using DHCPv6 instead. > > As a result of this we see new proposals in IETF that try to do > similar things by either extending RA mechanisms or by introducing new > options in DHCPv6. > > We thus have draft-droms-dhc-dhcpv6-default-router-00 that extends > DHCPv6 to do what RA does. And now, we have > draft-bcd-6man-ntp-server-ra-opt-00.txt that extends RA to advertise > the NTP information that is currently done via DHCPv6. > > My question is, that which then is the more preferred option for the > operators? Do they prefer extending RA so that the new information > loaded on top of the RA messages gets known in the single shot when > routers do neighbor discovery. Or do they prefer all the extra > information to be learnt via DHCPv6? What are the pros and cons in > each approach and when would people favor one over the other? > > I can see some advantages with the loading information to RA since > then one is not dependent on the DHCPv6 server. However, the latter > provides its own benefits. > > Regards, > Ravi D. > From frnkblk at iname.com Tue Dec 20 04:56:38 2011 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 20 Dec 2011 04:56:38 -0600 Subject: ipv6.level3.com responding with a "500 Internal Server Error" for 3+ days Message-ID: <001601ccbf06$0c31a1b0$2494e510$@iname.com> ipv6.level3.com has been responding with a "500 Internal Server Error" since Saturday morning. I reached out twice to the NOC email address I have on file, but no response. Perhaps someone can reach out to the right person. Frank P.S.: ipv6.cnn.com has not been responding properly for about two-thirds of this month, starting December 7, early a.m. I've reached out to my Turner contact at least twice, but not luck there, either. From stephen.strowes at gmail.com Tue Dec 20 06:02:17 2011 From: stephen.strowes at gmail.com (Stephen Strowes) Date: Tue, 20 Dec 2011 12:02:17 +0000 Subject: routeviews.org domain registration Message-ID: routeviews.org domain registration has lapsed? I pinged John Kemp at uoregon.edu, but unsure if he is the correct contact for this. Domain ID:D48496876-LROR Domain Name:ROUTEVIEWS.ORG Created On:14-Dec-2000 23:05:47 UTC Last Updated On:20-Dec-2011 08:53:07 UTC Expiration Date:14-Dec-2012 23:05:47 UTC Sponsoring Registrar:Network Solutions LLC (R63-LROR) Status:CLIENT TRANSFER PROHIBITED Status:AUTORENEWPERIOD Registrant ID:DOMAIN-RESALE Registrant Name:Pending Renewal or Deletion Registrant Street1:P.O. Box 430 Registrant Street2: Registrant Street3: Registrant City:Herndon Registrant State/Province:VA Registrant Postal Code:20172 Registrant Country:US Registrant Phone:+1.5707088786 Registrant Phone Ext.: Registrant FAX: Registrant FAX Ext.: Registrant Email:pendingrenewalordeletion at networksolutions.com From andy at nosignal.org Tue Dec 20 06:09:05 2011 From: andy at nosignal.org (Andy Davidson) Date: Tue, 20 Dec 2011 12:09:05 +0000 Subject: routeviews.org domain registration In-Reply-To: References: Message-ID: On 20 Dec 2011, at 12:02, Stephen Strowes wrote: > I pinged John Kemp at uoregon.edu, but unsure if he is the correct contact for this. I beeped Dave Meyer, who acknowledged, so I think someone is on it. Andy From bhmccie at gmail.com Tue Dec 20 07:55:13 2011 From: bhmccie at gmail.com (-Hammer-) Date: Tue, 20 Dec 2011 07:55:13 -0600 Subject: Nexus emulation? Anyone? Message-ID: <4EF093C1.1040806@gmail.com> I know we can't throw NX code on Dynamips but I figured I would ask the group anyway. We are starting to discuss Nexus platform options and I can only get so much from demo depot before our AM gets whiny. Is anyone currently emulating Nexus on anything that is open to the public? Not I.O.U. but Dynamips or something similar? If the software is out there I have the hardware to support it. Based on some cheap googling I'm thinking the answer will be no. Although I did find Greg Ferros public outcry for network emulators from last year.... -- -Hammer- "I was a normal American nerd" -Jack Herer From sclark at netwolves.com Tue Dec 20 08:17:44 2011 From: sclark at netwolves.com (Steve Clark) Date: Tue, 20 Dec 2011 09:17:44 -0500 Subject: IPV6 issue Message-ID: <4EF09908.3050701@netwolves.com> Hello, I have a SIXXS ipv6 tunnel that terminates in Ashburn, Va. I have two HE ipv6 tunnels, one terminates in Dallas the other terminate in Ashburn. I can ping each endpoint of the tunnels that terminate in Ashburn, but I can't ping between the SIXXS and HE with the HE termination in Dallas. Using Looking Glass at HE I can traceroute to my SIXXS tunnel from Chicago but not from Dallas. Any ideas on how to get this fixed. This problem only started occurring within the last week or so. Thanks for your indulgence, -- Stephen Clark *NetWolves* Sr. Software Engineer III Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark at netwolves.com http://www.netwolves.com From greg at bestnet.kharkov.ua Tue Dec 20 08:21:50 2011 From: greg at bestnet.kharkov.ua (Gregory Edigarov) Date: Tue, 20 Dec 2011 16:21:50 +0200 Subject: software wanted Message-ID: <20111220162150.08ee33b7@greg.bestnet.kharkov.ua> Hi everybody, can anybody recomend a piece of software, that could "graph" a live network scanning it via snmp. requirements are: 1. must produce a text output suitable for postproduction. graphviz is an ideal, xml - acceptable. 2. must use no external database i.e. have text config file. clean text console, suitable to run as a cronjob. 3. must be able to work in heterogenous environment. thanks a lot in advance -- With best regards, Gregory Edigarov From morrowc.lists at gmail.com Tue Dec 20 08:26:44 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 20 Dec 2011 09:26:44 -0500 Subject: software wanted In-Reply-To: <20111220162150.08ee33b7@greg.bestnet.kharkov.ua> References: <20111220162150.08ee33b7@greg.bestnet.kharkov.ua> Message-ID: mrtg? www.mrtg.org On Tue, Dec 20, 2011 at 9:21 AM, Gregory Edigarov wrote: > Hi everybody, > > can anybody recomend a piece of software, that could "graph" a live > network scanning it via snmp. > requirements are: > 1. must produce a text output suitable for postproduction. graphviz is > an ideal, xml - acceptable. > 2. must use no external database i.e. have text config file. clean text > console, suitable to run as a cronjob. > 3. must be able to work in heterogenous environment. > > thanks a lot in advance > > -- > With best regards, > ? ? ? ?Gregory Edigarov > From Jeremy.M.Bowen at windstream.com Tue Dec 20 08:26:52 2011 From: Jeremy.M.Bowen at windstream.com (Bowen, Jeremy M) Date: Tue, 20 Dec 2011 08:26:52 -0600 Subject: software wanted In-Reply-To: <20111220162150.08ee33b7@greg.bestnet.kharkov.ua> References: <20111220162150.08ee33b7@greg.bestnet.kharkov.ua> Message-ID: <51F530F6D5D78F44B347894FFAE52DDA8E51B853@CWWAPP230.windstream.com> Cacti is a very useful graphing tool We have used it to graph anything we can grab via snmp. Hope that helps. Jeremy Bowen >Hi everybody, >can anybody recomend a piece of software, that could "graph" a live network scanning it via snmp. >requirements are: >1. must produce a text output suitable for postproduction. graphviz is an ideal, xml - acceptable. >2. must use no external database i.e. have text config file. clean text console, suitable to run as a cronjob. >3. must be able to work in heterogenous environment. >thanks a lot in advance >- >With best regards, Gregory Edigarov ---------------------------------------------------------------------- The information contained in this message, including attachments, may contain privileged or confidential information that is intended to be delivered only to the person identified above. If you are not the intended recipient, or the person responsible for delivering this message to the intended recipient, Windstream requests that you immediately notify the sender and asks that you do not read the message or its attachments, and that you delete them without copying or sending them to anyone else. From jeroen at unfix.org Tue Dec 20 08:33:21 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 20 Dec 2011 15:33:21 +0100 Subject: IPV6 issue In-Reply-To: <4EF09908.3050701@netwolves.com> References: <4EF09908.3050701@netwolves.com> Message-ID: <4EF09CB1.1030501@unfix.org> On 2011-12-20 15:17 , Steve Clark wrote: > Hello, > > I have a SIXXS ipv6 tunnel that terminates in Ashburn, Va. > I have two HE ipv6 tunnels, one terminates in Dallas the other > terminate in Ashburn. I can ping each endpoint of the tunnels that > terminate > in Ashburn, but I can't ping between the SIXXS and HE with the HE > termination in Dallas. > > Using Looking Glass at HE I can traceroute to my SIXXS tunnel from > Chicago but > not from Dallas. > > Any ideas on how to get this fixed. Contact the providers involved directly? Sending a mail to ipv6 at he.net + info at sixxs.net should get you what you need, given that you actually provide IP addresses and other such useful diagnostics like interface configuration, routing tables etc etc etc. The above mail is far from useful and nobody would be able to help you in anyway except to state the above. Greets, Jeroen From eric-list at truenet.com Tue Dec 20 08:36:17 2011 From: eric-list at truenet.com (Eric Tykwinski) Date: Tue, 20 Dec 2011 09:36:17 -0500 Subject: software wanted In-Reply-To: <51F530F6D5D78F44B347894FFAE52DDA8E51B853@CWWAPP230.windstream.com> References: <20111220162150.08ee33b7@greg.bestnet.kharkov.ua> <51F530F6D5D78F44B347894FFAE52DDA8E51B853@CWWAPP230.windstream.com> Message-ID: <00b401ccbf24$bbede640$33c9b2c0$@truenet.com> Cacti uses MySQL, but I'm not sure if plain rrdtool does. There is support for custom programming, so might be worth checking out. http://oss.oetiker.ch/rrdtool/ Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 F: 610-429-3222 -----Original Message----- From: Bowen, Jeremy M [mailto:Jeremy.M.Bowen at windstream.com] Sent: Tuesday, December 20, 2011 9:27 AM To: 'Gregory Edigarov'; nanog at nanog.org Subject: RE: software wanted Cacti is a very useful graphing tool We have used it to graph anything we can grab via snmp. Hope that helps. Jeremy Bowen >Hi everybody, >can anybody recomend a piece of software, that could "graph" a live network scanning it via snmp. >requirements are: >1. must produce a text output suitable for postproduction. graphviz is an ideal, xml - acceptable. >2. must use no external database i.e. have text config file. clean text console, suitable to run as a cronjob. >3. must be able to work in heterogenous environment. >thanks a lot in advance >- >With best regards, Gregory Edigarov ---------------------------------------------------------------------- The information contained in this message, including attachments, may contain privileged or confidential information that is intended to be delivered only to the person identified above. If you are not the intended recipient, or the person responsible for delivering this message to the intended recipient, Windstream requests that you immediately notify the sender and asks that you do not read the message or its attachments, and that you delete them without copying or sending them to anyone else. From greg at bestnet.kharkov.ua Tue Dec 20 08:37:35 2011 From: greg at bestnet.kharkov.ua (Gregory Edigarov) Date: Tue, 20 Dec 2011 16:37:35 +0200 Subject: software wanted In-Reply-To: <20111220162150.08ee33b7@greg.bestnet.kharkov.ua> References: <20111220162150.08ee33b7@greg.bestnet.kharkov.ua> Message-ID: <20111220163735.3d7a11c1@greg.bestnet.kharkov.ua> On Tue, 20 Dec 2011 16:21:50 +0200 Gregory Edigarov wrote: > Hi everybody, > > can anybody recomend a piece of software, that could "graph" a live > network scanning it via snmp. > requirements are: > 1. must produce a text output suitable for postproduction. graphviz is > an ideal, xml - acceptable. > 2. must use no external database i.e. have text config file. clean > text console, suitable to run as a cronjob. > 3. must be able to work in heterogenous environment. > > thanks a lot in advance > and, the question is about producing network schematic, not about graphs like mrtg, cacti etc, etc.... -- With best regards, Gregory Edigarov From mark at AMPLEX.NET Tue Dec 20 08:48:30 2011 From: mark at AMPLEX.NET (Mark Radabaugh) Date: Tue, 20 Dec 2011 09:48:30 -0500 Subject: software wanted In-Reply-To: <20111220162150.08ee33b7@greg.bestnet.kharkov.ua> References: <20111220162150.08ee33b7@greg.bestnet.kharkov.ua> Message-ID: <4EF0A03E.3080204@amplex.net> On 12/20/11 9:21 AM, Gregory Edigarov wrote: > Hi everybody, > > can anybody recomend a piece of software, that could "graph" a live > network scanning it via snmp. > requirements are: > 1. must produce a text output suitable for postproduction. graphviz is > an ideal, xml - acceptable. > 2. must use no external database i.e. have text config file. clean text > console, suitable to run as a cronjob. > 3. must be able to work in heterogenous environment. > > thanks a lot in advance > This *might* do what you want. It will create the graph for you, what happens after that I don't know. http://www.mikrotik.com/thedude.php I played with it briefly but it didn't really serve a purpose for us since we derive our network layout from the OSS database. -- Mark Radabaugh Amplex mark at amplex.net 419.837.5015 From bhmccie at gmail.com Tue Dec 20 08:47:08 2011 From: bhmccie at gmail.com (-Hammer-) Date: Tue, 20 Dec 2011 08:47:08 -0600 Subject: software wanted In-Reply-To: <20111220163735.3d7a11c1@greg.bestnet.kharkov.ua> References: <20111220162150.08ee33b7@greg.bestnet.kharkov.ua> <20111220163735.3d7a11c1@greg.bestnet.kharkov.ua> Message-ID: <4EF09FEC.7010702@gmail.com> So you want a dynamic real time network discovery / topology mapping? I think Whatsup gold tried this years ago and it could even export to Visio. But not sure lately. -Hammer- "I was a normal American nerd" -Jack Herer On 12/20/2011 08:37 AM, Gregory Edigarov wrote: > On Tue, 20 Dec 2011 16:21:50 +0200 > Gregory Edigarov wrote: > > >> Hi everybody, >> >> can anybody recomend a piece of software, that could "graph" a live >> network scanning it via snmp. >> requirements are: >> 1. must produce a text output suitable for postproduction. graphviz is >> an ideal, xml - acceptable. >> 2. must use no external database i.e. have text config file. clean >> text console, suitable to run as a cronjob. >> 3. must be able to work in heterogenous environment. >> >> thanks a lot in advance >> >> > and, the question is about producing network schematic, not about > graphs like mrtg, cacti etc, etc.... > > > From ray at oneunified.net Tue Dec 20 08:58:25 2011 From: ray at oneunified.net (Raymond Burkholder) Date: Tue, 20 Dec 2011 10:58:25 -0400 Subject: software wanted In-Reply-To: <20111220162150.08ee33b7@greg.bestnet.kharkov.ua> References: <20111220162150.08ee33b7@greg.bestnet.kharkov.ua> Message-ID: <0b3a01ccbf27$d3dede50$7b9c9af0$@oneunified.net> > can anybody recommend a piece of software, that could "graph" a live > network scanning it via snmp. > requirements are: > 1. must produce a text output suitable for postproduction. graphviz is > an ideal, xml - acceptable. > 2. must use no external database i.e. have text config file. clean text > console, suitable to run as a cronjob. > 3. must be able to work in heterogenous environment. Except for requirement #2, NetDisco would fulfill your requirements. On the otherhand, NetDisco uses a database for topology management. For the graph side, it creates a text file useable by graphviz. Raymond. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owen at delong.com Tue Dec 20 08:58:24 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 20 Dec 2011 06:58:24 -0800 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: Message-ID: <263F5718-46C7-4B21-82A5-083D42EB4B05@delong.com> I had some trouble parsing what Glen was saying, so, I'll provide some clarification of how things actually work today and what I think would be desirable in future development: 1. In IPv6, it is not uncommon for certain types of routers to be DHCP clients. DHCPv6-PD is relatively useless except when talking to a router. 2. Routers rarely listen to RAs and mostly generate them. There's no reason for router A to listen to RAs from router B on the same link. Router A doesn't care that Router B can be a default gateway. If Router A needs a default gateway, router A shouldn't be advertising himself with RAs and should know about Router B from a static route or some routing protocol. RAs are only useful (as far as routing is concerned) for routers to announce themselves as default gateways. They do not provide any mechanism for advertising more specific routes. 3. As it currently stands, RAs can provide the following information: + Default Router (anything sending an RA should be a valid default router). + Router Priority (High/Medium/Low) + Prefixes (must be /64) for SLAAC * Desired Lifetime * Valid Lifetime + DHCP Server Address + DNS Resolver Address[1] + M-Bit (Network is managed, host should ask DHCP server for some configuration information) + A-Bit (DHCP server is authoritative for addressing, do not use SLAAC to generate unicast addresses from prefixes) [1] Requires recent extensions to SLAAC and RA. Not available in all implementations. 4. As it currently stands, a DHCPv6 server can provide most of the things you're used to a DHCP server providing. It cannot provide any information about routing whatsoever. There is currently no mechanism for a host to ask a DHCPv6 server for configuration information unless and until it receives an RA with at least the M-Bit set. (You currently can't use DHCP without RA). Currently, many clients support only SLAAC and Static for configuring IPv6 information. If you have such clients in your environment, setting the A-bit is generally self-destructive. Short of some form of NAC[2], there is currently no mechanism for preventing a host which uses SLAAC in spite of the A-bit being present (nefariously or erroneously) from making use of the network with that address. (i.e. you can't force a host to use DHCPv6 if it is not well behaved). [2] Network Admission Control -- A process which does not place clients into functional VLANs on the switch until certain policy defined criteria have been met. 5. What I'd like to see: 1. A mechanism for DHCP to be used without requiring RA at all. 2. A mechanism for DHCP to provide zero or more copies of an optional attribute called "Routing Information". Said attribute's value would be a structure containing: Prefix (128 bits) Masklen (8 bits) Next-Hop (128 bits) Metric (16 bits) A default router would be specified as: Prefix 0::0/128 Masklen 0 Next-Hop pfx::gateway A static routing table with specific routes could be built as: Prefix 2001:0db8:0:32:: Masklen 64 Next-Hop 2001:0db8:0:7::1 Prefix 2001:0db8:0:64: Masklen 60 Next-Hop 2001:0db8:0:7::5 Prefix :: Masklen 0 Next-Hop 2001:0db8:0:7:feed:beef:cafe:babe 3. Extensions to SLAAC to provide for NTP, "next-server", "boot-file", and certain other key elements available from DHCP, but, not possible in the current specification for SLAAC. Yes, this will annoy those purists who believe there should be one true way to do each thing. That's OK, they're entitled to their opinion, but, this is mine. DIfferent operators have different preferences and different environments sometimes work better or adapt better to different solutions. Currently, most significant environments have to cobble together a complete solution from remnants of SLAAC and DHCP. This is far from ideal. Far better for organizations to look at 2 complete solutions and pick the solution that works best for them in their environment. Owen On Dec 20, 2011, at 1:58 AM, Glen Kent wrote: > When a router needs to learn information from another router it will > *usually* use the RA messages and not DHCPv6, as the latter is > *usually* meant for Router - Host communication. However, it is NOT > uncommon to see hosts also learning the information using RA messages. > Router's afaik dont usually act as DHCP clients and thus information > that can only be passed in DHCPv6 may not be available to the routers, > and you may need an alternate mechanism. > > Glen > > On Tue, Dec 20, 2011 at 11:57 AM, Ravi Duggal wrote: >> Hi, >> >> IPv6 devices (routers and hosts) can obtain configuration information >> about default routers, on-link prefixes and addresses from Router >> Advertisements as defined in Neighbor Discovery. I have been told >> that in some deployments, there is a strong desire not to use Router >> Advertisements at all and to perform all configuration via DHCPv6. >> There are thus similar IETF standards to get everything that you can >> get from RAs, by using DHCPv6 instead. >> >> As a result of this we see new proposals in IETF that try to do >> similar things by either extending RA mechanisms or by introducing new >> options in DHCPv6. >> >> We thus have draft-droms-dhc-dhcpv6-default-router-00 that extends >> DHCPv6 to do what RA does. And now, we have >> draft-bcd-6man-ntp-server-ra-opt-00.txt that extends RA to advertise >> the NTP information that is currently done via DHCPv6. >> >> My question is, that which then is the more preferred option for the >> operators? Do they prefer extending RA so that the new information >> loaded on top of the RA messages gets known in the single shot when >> routers do neighbor discovery. Or do they prefer all the extra >> information to be learnt via DHCPv6? What are the pros and cons in >> each approach and when would people favor one over the other? >> >> I can see some advantages with the loading information to RA since >> then one is not dependent on the DHCPv6 server. However, the latter >> provides its own benefits. >> >> Regards, >> Ravi D. >> From tore.anderson at redpill-linpro.com Tue Dec 20 09:09:37 2011 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 20 Dec 2011 16:09:37 +0100 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <263F5718-46C7-4B21-82A5-083D42EB4B05@delong.com> References: <263F5718-46C7-4B21-82A5-083D42EB4B05@delong.com> Message-ID: <4EF0A531.1040900@redpill-linpro.com> * Owen DeLong > RAs are only useful (as far as routing is concerned) for routers to > announce themselves as default gateways. They do not provide > any mechanism for advertising more specific routes. They do, actually. See RFC 4191. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From jra at baylink.com Tue Dec 20 09:10:08 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 20 Dec 2011 10:10:08 -0500 (EST) Subject: DNS zone response speed test tool? Message-ID: <27365203.1273.1324393807954.JavaMail.root@benjamin.baylink.com> I've put monitoring onto my public website, and by far the largest component of the response time it gives me is the DNS lookup -- 4-500ms, which seems entirely unreasonable. Is there a tool that anyone knows about that will measure the response time of my zone servers, somewhere on the web? Is the sum of the times in a dig +trace the proper metric to look at 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 http://photo.imageinc.us +1 727 647 1274 From dave at temk.in Tue Dec 20 09:14:27 2011 From: dave at temk.in (David Temkin) Date: Tue, 20 Dec 2011 10:14:27 -0500 Subject: Overall Netflix bandwidth usage numbers on a network? In-Reply-To: <3D55217B-C11D-45F9-98EC-FE5D685D55E3@paulstewart.org> References: <20111203004732.GH13315@hijacked.us> <20111203005847.GI13315@hijacked.us> <4EDF9AE9.9040700@ispn.net> <4EE54B01.6000305@temk.in> <4EEB5166.2070702@ispn.net> <13175F96BDC3B34AB1425BAE905B3CE50D4D8C87@ltiserver.lti.local> <3D55217B-C11D-45F9-98EC-FE5D685D55E3@paulstewart.org> Message-ID: <4EF0A653.9040403@temk.in> Yes, sorry. We will respond to all takers shortly; there was a flaw in our logic used to generate these numbers and wanted to ensure that we were painting an accurate picture. We will have statistics out within a week, hopefully. Thanks, -Dave On 12/16/11 9:55 AM, Paul Stewart wrote: > I'll take a guess they are back logged - they have been working on our traffic stats since a week before that posting made it to nanog list > > --- Sent via IPhone > > On 2011-12-16, at 9:16 AM, "Dennis Burgess" wrote: > >> Same here. >> >> ----------------------------------------------------------- >> Dennis Burgess, Mikrotik Certified Trainer >> Link Technologies, Inc -- Mikrotik& WISP Support Services >> Office: 314-735-0270 Website: http://www.linktechs.net >> LIVE On-Line Mikrotik Training - Author of "Learn RouterOS" >> >> >>> -----Original Message----- >>> From: Blake Hudson [mailto:blake at ispn.net] >>> Sent: Friday, December 16, 2011 8:11 AM >>> To: Dave Temkin >>> Cc: nanog at nanog.org >>> Subject: Re: Overall Netflix bandwidth usage numbers on a network? >>> >>> Requests to this address appear to go unanswered? >>> >>> Dave Temkin wrote the following on 12/11/2011 6:29 PM: >>>> Feel free to contact peering at netflixcom - we're happy to provide >>>> you with delivery statistics for traffic terminating on your network. >>>> >>>> Regards, >>>> -Dave Temkin >>>> Netflix >>>> >>>> On 12/7/11 8:57 AM, Blake Hudson wrote: >>>>> Yeah, that's an interesting one. We currently utilize netflow for >>>>> this, but you also need to consider that netflix streaming is just >>>>> port 80 www traffic. Because netflix uses CDNs, its difficult to pin >>>>> down the traffic to specific hosts in the CDN and say that this >>>>> traffic was netflix, while this traffic was the latest windows update >>>>> (remember this is often a shared hosting platform). We've done our >>>>> own testing and have come to a good solution which uses a combination >>>>> of nbar, packet marking, and netflow to come to a conclusion. On a >>>>> ~160Mbps link, netflix peaks out between 30-50Mbps around 8-10PM >>> each >>>>> evening. The rest of the traffic is predominantly other forms of HTTP >>>>> traffic (including other video streaming services). >>>>> >>>>> >>>>> Martin Hepworth wrote the following on 12/3/2011 2:36 AM: >>>>>> Also checkout Adrian Cockcroft presentations on their architecture >>>>>> which describes how they use aws and CDns etc >>>>>> >>>>>> Martin >>>>>> >>>>>> From bortzmeyer at nic.fr Tue Dec 20 09:16:41 2011 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 20 Dec 2011 16:16:41 +0100 Subject: DNS zone response speed test tool? In-Reply-To: <27365203.1273.1324393807954.JavaMail.root@benjamin.baylink.com> References: <27365203.1273.1324393807954.JavaMail.root@benjamin.baylink.com> Message-ID: <20111220151641.GA22263@nic.fr> On Tue, Dec 20, 2011 at 10:10:08AM -0500, Jay Ashworth wrote a message of 16 lines which said: > Is there a tool that anyone knows about that will measure the > response time of my zone servers, somewhere on the web? Yes, it is called Nanog. For baylink.com ? Only one real name server and quite slow. % qtest -n 10 "SOA baylink.com" $(dig +short NS baylink.com.) 148 ns5.baylink.com./69.12.222.27 149 ns6.baylink.com./69.12.222.27 -------------- next part -------------- #!/bin/sh # # qtest: queries a set of DNS name servers and report the fastest ones # # Usage: qtest query server... # Example: qtest -n 3 "SOA fr" $(dig +short NS fr.) # # From: Joe Abley # Modified-by: Stephane Bortzmeyer # Settings max=1 verbose=0 # Some Unices like NetBSD are crazy enough to ship a dinosaurian # version of getopt, which cannot handle arguments with spaces! So, we # have a lot of work to work around this pre-babylonian limit. test_getopt() { getopt=$1 if [ ! -x $getopt ] && ! which $getopt > /dev/null 2>&1; then return 1 fi if [ "$($getopt -o '' -- 'a b')" = " -- 'a b'" ]; then return 0 else return 1 fi } if test_getopt getopt; then GETOPT=getopt else if test_getopt ggetopt; then GETOPT=ggetopt else if test_getopt /usr/pkg/bin/getopt; then # Last resort for NetBSD GETOPT=/usr/pkg/bin/getopt else echo "Cannot find a working getopt on this machine" > /dev/stderr exit 1 fi fi fi TEMP=$($GETOPT -o "n:v" -- "$@") if [ $? != 0 ]; then echo "Usage: $0 [-n MAX] [-v] query server..." > /dev/stderr exit 1 fi eval set -- "$TEMP" while true ; do case "$1" in -n) max=$2; shift 2;; -v) verbose=1; shift;; --) shift ; break ;; *) echo "Internal error!" > /dev/stderr ; exit 1 ;; esac done query=$1 shift servers="" for server in $*; do addresses=$(dig +short A $server ; dig +short AAAA $server) if [ -z "$addresses" ]; then # Let's hope it was an IP address addresses=$server fi for address in $addresses; do servers="$servers $server/$address" done done for i in 0 1 2; do for server in $servers; do address=$(echo $server | cut -d/ -f 2) # TODO: if the box has no IPv6 connectivity, or if it is an # old dig without IPv6, we get something like "dig: couldn't # get address for '2001:4f8:0:2::8': address family not # supported". Should we do something? echo "TEST: $server" dig @${address} ${query} done done | \ awk '/^TEST: / { server = $2; } \ /^;; Query time:/ { query_time = $4; } \ /^;; SERVER: / { sum[server] += query_time; num[server]++; } \ END { for (ns in sum) { print int(sum[ns]/num[ns]), ns; } }' | \ sort -n | head -${max} From chip.gwyn at gmail.com Tue Dec 20 10:00:09 2011 From: chip.gwyn at gmail.com (chip) Date: Tue, 20 Dec 2011 11:00:09 -0500 Subject: DNS zone response speed test tool? In-Reply-To: <27365203.1273.1324393807954.JavaMail.root@benjamin.baylink.com> References: <27365203.1273.1324393807954.JavaMail.root@benjamin.baylink.com> Message-ID: http://code.google.com/p/namebench/ Seems like it may be fun to play with On Tue, Dec 20, 2011 at 10:10 AM, Jay Ashworth wrote: > I've put monitoring onto my public website, and by far the largest component > of the response time it gives me is the DNS lookup -- 4-500ms, which seems > entirely unreasonable. > > Is there a tool that anyone knows about that will measure the response time > of my zone servers, somewhere on the web? > > Is the sum of the times in a dig +trace the proper metric to look at 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 ? ? ?http://photo.imageinc.us ? ? ? ? ? ? +1 727 647 1274 > -- Just my $.02, your mileage may vary,? batteries not included, etc.... From netsaint at gmail.com Tue Dec 20 10:01:52 2011 From: netsaint at gmail.com (Net Saint) Date: Tue, 20 Dec 2011 10:01:52 -0600 Subject: OT: Nortel/Ciena Cooling Tray for OME 6500 - NTK607AAE5 Message-ID: For a project that needs to be completed like yesterday in Houston, TX, I need to find cooling trays for Ciena/Nortel OME 6500's .Please contact me off-list if you have any inventory of NTK607AAE5 for sale. Only contact if you have them available, not if you know a guy who knows a guy :) +1-832-615-7743. Thanks and sorry for the OT. From tlyons at ivenue.com Tue Dec 20 10:25:16 2011 From: tlyons at ivenue.com (Todd Lyons) Date: Tue, 20 Dec 2011 08:25:16 -0800 Subject: DNS zone response speed test tool? In-Reply-To: References: <27365203.1273.1324393807954.JavaMail.root@benjamin.baylink.com> Message-ID: Doesn't do much for long term graphing and monitoring, but for quickie issue detection or verification, http://www.grc.com/dns/benchmark.htm ...Todd On Tue, Dec 20, 2011 at 8:00 AM, chip wrote: > http://code.google.com/p/namebench/ > ?Seems like it may be fun to play with > > > > > > On Tue, Dec 20, 2011 at 10:10 AM, Jay Ashworth wrote: >> I've put monitoring onto my public website, and by far the largest component >> of the response time it gives me is the DNS lookup -- 4-500ms, which seems >> entirely unreasonable. >> >> Is there a tool that anyone knows about that will measure the response time >> of my zone servers, somewhere on the web? >> >> Is the sum of the times in a dig +trace the proper metric to look at 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 ? ? ?http://photo.imageinc.us ? ? ? ? ? ? +1 727 647 1274 >> > > > > -- > Just my $.02, your mileage may vary,? batteries not included, etc.... > -- If Americans could eliminate sugary beverages, potatoes, white bread, pasta, white rice and sugary snacks, we would wipe out almost all the problems we have with weight and diabetes and other metabolic diseases. -- Dr. Walter Willett, Harvard School of Public Health From esuarez at fcaglp.fcaglp.unlp.edu.ar Tue Dec 20 10:37:23 2011 From: esuarez at fcaglp.fcaglp.unlp.edu.ar (Eduardo A. =?iso-8859-1?b?U3XhcmV6?=) Date: Tue, 20 Dec 2011 13:37:23 -0300 Subject: what if...? Message-ID: <20111220133723.cfjv8g999ssoc8gg@fcaglp.fcaglp.unlp.edu.ar> Hi, what if evil guys hack my mom ISP DNS servers and use RPZ to redirect traffic from mom_bank.com to evil.com? How can she detect this? Eduardo.- -- Eduardo A. Suarez Facultad de Ciencias Astron?micas y Geof?sicas - UNLP FCAG: (0221)-4236593 int. 172/Cel: (0221)-15-4557542/Casa: (0221)-4526589 ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From MatlockK at exempla.org Tue Dec 20 10:41:56 2011 From: MatlockK at exempla.org (Matlock, Kenneth L) Date: Tue, 20 Dec 2011 09:41:56 -0700 Subject: what if...? In-Reply-To: <20111220133723.cfjv8g999ssoc8gg@fcaglp.fcaglp.unlp.edu.ar> References: <20111220133723.cfjv8g999ssoc8gg@fcaglp.fcaglp.unlp.edu.ar> Message-ID: <4288131ED5E3024C9CD4782CECCAD2C710B04935@LMC-MAIL2.exempla.org> You mean besides SSL? :) Ken Matlock Network Analyst Systems and Technology Service Center Sisters of Charity of Leavenworth Health System 12600 W. Colfax, Suite A-500 Lakewood, CO 80215 303-467-4671 matlockk at exempla.org -----Original Message----- From: Eduardo A. Su?rez [mailto:esuarez at fcaglp.fcaglp.unlp.edu.ar] Sent: Tuesday, December 20, 2011 9:37 AM To: nanog at nanog.org Subject: what if...? Hi, what if evil guys hack my mom ISP DNS servers and use RPZ to redirect traffic from mom_bank.com to evil.com? How can she detect this? Eduardo.- -- Eduardo A. Suarez Facultad de Ciencias Astron?micas y Geof?sicas - UNLP FCAG: (0221)-4236593 int. 172/Cel: (0221)-15-4557542/Casa: (0221)-4526589 ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. *** Exempla Confidentiality Notice *** The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any other dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately by replying to the message and deleting it from your computer. Thank you. *** Exempla Confidentiality Notice *** From Valdis.Kletnieks at vt.edu Tue Dec 20 10:53:12 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 20 Dec 2011 11:53:12 -0500 Subject: what if...? In-Reply-To: Your message of "Tue, 20 Dec 2011 13:37:23 -0300." <20111220133723.cfjv8g999ssoc8gg@fcaglp.fcaglp.unlp.edu.ar> References: <20111220133723.cfjv8g999ssoc8gg@fcaglp.fcaglp.unlp.edu.ar> Message-ID: <4930.1324399992@turing-police.cc.vt.edu> On Tue, 20 Dec 2011 13:37:23 -0300, "Eduardo A. =?iso-8859-1?b?U3XhcmV6?=" said: > what if evil guys hack my mom ISP DNS servers and use RPZ to redirect > traffic from mom_bank.com to evil.com? > > How can she detect this? The snarky answer is "If your mom has to ask how she can detect this, she's probably going to be unable to do so". The more technically correct answer is that you can check the IP and TTL as returned by your local caching nameserver, and compare them to the values reported from the authoritative NS for the zone. Of course, this means you have to hit the authoritative server, which sort of defeats the purpose of DNS caching. Or you can deploy DNSSEC. Or you can deploy SSL (not perfect, but it raises the bar considerably). Or you can google for "DNS RPZ" and start reading - the top hit seems to be Paul Vixie's announcement: https://www.isc.org/community/blog/201007/taking-back-dns-0 and start reading - as about the 4th or 5th commenter points out, the threat model is *no* different than a DNS server that forces in its own zones. The commenter is talking in the context of a provider replacing a zone, but it's the same issue if a black hat hacks in a zone. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jared at puck.nether.net Tue Dec 20 11:00:28 2011 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 20 Dec 2011 12:00:28 -0500 Subject: what if...? In-Reply-To: <20111220133723.cfjv8g999ssoc8gg@fcaglp.fcaglp.unlp.edu.ar> References: <20111220133723.cfjv8g999ssoc8gg@fcaglp.fcaglp.unlp.edu.ar> Message-ID: <84355935-D650-40EB-AEE1-14755D6AB2DA@puck.nether.net> On Dec 20, 2011, at 11:37 AM, Eduardo A. Su?rez wrote: > Hi, > > what if evil guys hack my mom ISP DNS servers and use RPZ to redirect traffic from mom_bank.com to evil.com? > > How can she detect this? Thankfully mom_bank.com is not valid, as underscores aren't valid in dns names :) Additionally, SSL certificates combined with DNSSEC/DANE can provide some protection. Some of this technology may not be available today, but is worth tracking if you are interested in this topic. - Jared From nick at foobar.org Tue Dec 20 11:02:46 2011 From: nick at foobar.org (Nick Hilliard) Date: Tue, 20 Dec 2011 17:02:46 +0000 Subject: Nexus emulation? Anyone? In-Reply-To: <4EF093C1.1040806@gmail.com> References: <4EF093C1.1040806@gmail.com> Message-ID: <4EF0BFB6.1060605@foobar.org> On 20/12/2011 13:55, -Hammer- wrote: > I know we can't throw NX code on Dynamips but I figured I would ask the > group anyway. We are starting to discuss Nexus platform options and I can > only get so much from demo depot before our AM gets whiny. Is anyone > currently emulating Nexus on anything that is open to the public? nexus1k? Nick From bhmccie at gmail.com Tue Dec 20 11:08:12 2011 From: bhmccie at gmail.com (-Hammer-) Date: Tue, 20 Dec 2011 11:08:12 -0600 Subject: Nexus emulation? Anyone? In-Reply-To: <4EF0BFB6.1060605@foobar.org> References: <4EF093C1.1040806@gmail.com> <4EF0BFB6.1060605@foobar.org> Message-ID: <4EF0C0FC.2020905@gmail.com> Bah. Look like I need more of an education on Nexus in general. Thanks for the easy pointer. -Hammer- "I was a normal American nerd" -Jack Herer On 12/20/2011 11:02 AM, Nick Hilliard wrote: > On 20/12/2011 13:55, -Hammer- wrote: > >> I know we can't throw NX code on Dynamips but I figured I would ask the >> group anyway. We are starting to discuss Nexus platform options and I can >> only get so much from demo depot before our AM gets whiny. Is anyone >> currently emulating Nexus on anything that is open to the public? >> > nexus1k? > > Nick > > > > > From michael at rancid.berkeley.edu Tue Dec 20 11:12:33 2011 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Tue, 20 Dec 2011 09:12:33 -0800 Subject: IPV6 issue (occaid.net) In-Reply-To: <4EF09CB1.1030501@unfix.org> References: <4EF09908.3050701@netwolves.com> <4EF09CB1.1030501@unfix.org> Message-ID: <4EF0C201.1090503@rancid.berkeley.edu> On 12/20/11 06:33, Jeroen Massar wrote: > On 2011-12-20 15:17 , Steve Clark wrote: >> Hello, >> >> I have a SIXXS ipv6 tunnel that terminates in Ashburn, Va. >> I have two HE ipv6 tunnels, one terminates in Dallas the other >> terminate in Ashburn. I can ping each endpoint of the tunnels that >> terminate >> in Ashburn, but I can't ping between the SIXXS and HE with the HE >> termination in Dallas. >> >> Using Looking Glass at HE I can traceroute to my SIXXS tunnel from >> Chicago but >> not from Dallas. >> >> Any ideas on how to get this fixed. > > Contact the providers involved directly? > > Sending a mail to ipv6 at he.net + info at sixxs.net should get you what you > need, given that you actually provide IP addresses and other such useful > diagnostics like interface configuration, routing tables etc etc etc. > The above mail is far from useful and nobody would be able to help you > in anyway except to state the above. Actually, I was about to send a message about this. I believe the problem is in occaid.net, particularly their router in Atlanta. SIXXS uses a variety of providers at various PoPs to provide their tunnel connectivity and occaid.net is the provider at Ashburn (I have a SIXXS tunnel there as well). Tracerouting from the West Coast or Texas goes through occaid.net's router in Atlanta and dies there with 'network unreachable': traceroute6 to burnttofu.net (2001:4830:1600:3bf::2) from 2001:470:1f05:17a6:219:d1ff:fe26:5246, 64 hops max, 12 byte packets 1 2001:470:1f05:17a6::1 0.316 ms 0.321 ms 0.321 ms 2 100000-1.tunnel.tserv3.fmt2.ipv6.he.net 28.000 ms 22.402 ms 26.169 ms 3 gige-g5-19.core1.fmt2.he.net 16.697 ms 18.046 ms 15.891 ms 4 10gigabitethernet6-4.core1.lax1.he.net 23.735 ms 25.327 ms 25.711 ms 5 10gigabitethernet1-3.core1.lax2.he.net 25.708 ms 24.923 ms 25.793 ms 6 2001:504:13::8 25.713 ms 23.731 ms 25.705 ms 7 bbr01-v441.atln01.occaid.net 80.617 ms !N 88.252 ms !N 79.369 ms !N Tracerouting from the East Coast is fine: traceroute6 to burnttofu.net (2001:4830:1600:3bf::2) from 2001:470:30:80:e076:63ff:fe88:2d62, 64 hops max, 12 byte packets 1 2001:470:30:80::2 21.739 ms 1.938 ms 2.474 ms 2 gige-g3-3.core1.nyc4.he.net 8.678 ms 2.710 ms 2.596 ms 3 10gigabitethernet2-3.core1.ash1.he.net 7.488 ms 7.168 ms 8.449 ms 4 ibr01-ve96.asbn01.occaid.net 7.211 ms 7.272 ms 7.177 ms 5 equi6ix.dc.hotnic.net 9.789 ms 8.597 ms 8.610 ms 6 sixxs-asbnva-gw.customer.occaid.net 8.782 ms 8.100 ms 9.522 ms 7 cl-960.qas-01.us.sixxs.net 22.621 ms 20.880 ms 21.072 ms Attempts to get a response from noc at occaid.net regarding this issue over the past 36 hours have failed. If there is anyone here from occaid.net or knows a clueful person there, can you please point them to this thread. I still think it's a good idea to contact info at sixxs.net, so they know what's going on, but I don't think it's actually their problem. michael From cdel at firsthand.net Tue Dec 20 11:14:53 2011 From: cdel at firsthand.net (Christian de Larrinaga) Date: Tue, 20 Dec 2011 17:14:53 +0000 Subject: what if...? In-Reply-To: <84355935-D650-40EB-AEE1-14755D6AB2DA@puck.nether.net> References: <20111220133723.cfjv8g999ssoc8gg@fcaglp.fcaglp.unlp.edu.ar> <84355935-D650-40EB-AEE1-14755D6AB2DA@puck.nether.net> Message-ID: <5891AEFD-B1A0-44B6-BDD0-B818335060F3@firsthand.net> You tell that to http://www.charset.org/punycode.php?encoded=xn--m_omaaamk.com&decode=Punycode+to+normal+text Normal text FMQQSQQT.com to Punycode xn--m_omaaamk.com ? On 20 Dec 2011, at 17:00, Jared Mauch wrote: > > On Dec 20, 2011, at 11:37 AM, Eduardo A. Su?rez wrote: > >> Hi, >> >> what if evil guys hack my mom ISP DNS servers and use RPZ to redirect traffic from mom_bank.com to evil.com? >> >> How can she detect this? > > Thankfully mom_bank.com is not valid, as underscores aren't valid in dns names :) > > Additionally, SSL certificates combined with DNSSEC/DANE can provide some protection. Some of this technology may not be available today, but is worth tracking if you are interested in this topic. > > - Jared From sethm at rollernet.us Tue Dec 20 11:16:45 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 20 Dec 2011 09:16:45 -0800 Subject: what if...? In-Reply-To: <5891AEFD-B1A0-44B6-BDD0-B818335060F3@firsthand.net> References: <20111220133723.cfjv8g999ssoc8gg@fcaglp.fcaglp.unlp.edu.ar> <84355935-D650-40EB-AEE1-14755D6AB2DA@puck.nether.net> <5891AEFD-B1A0-44B6-BDD0-B818335060F3@firsthand.net> Message-ID: <4EF0C2FD.4050705@rollernet.us> On 12/20/11 9:14 AM, Christian de Larrinaga wrote: > You tell that to http://www.charset.org/punycode.php?encoded=xn--m_omaaamk.com&decode=Punycode+to+normal+text > > > Normal text > FMQQSQQT.com > > to Punycode > xn--m_omaaamk.com > > ? > Dash - is a different character than underscore _ ~Seth From bmanning at vacation.karoshi.com Tue Dec 20 11:16:06 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 20 Dec 2011 17:16:06 +0000 Subject: what if...? In-Reply-To: <4930.1324399992@turing-police.cc.vt.edu> References: <20111220133723.cfjv8g999ssoc8gg@fcaglp.fcaglp.unlp.edu.ar> <4930.1324399992@turing-police.cc.vt.edu> Message-ID: <20111220171606.GA22143@vacation.karoshi.com.> On Tue, Dec 20, 2011 at 11:53:12AM -0500, Valdis.Kletnieks at vt.edu wrote: > On Tue, 20 Dec 2011 13:37:23 -0300, "Eduardo A. =?iso-8859-1?b?U3XhcmV6?=" said: > > what if evil guys hack my mom ISP DNS servers and use RPZ to redirect > > traffic from mom_bank.com to evil.com? > > > > How can she detect this? > > The snarky answer is "If your mom has to ask how she can detect this, she's > probably going to be unable to do so". > > The more technically correct answer is that you can check the IP and TTL as > returned by your local caching nameserver, and compare them to the values > reported from the authoritative NS for the zone. Of course, this means you > have to hit the authoritative server, which sort of defeats the purpose of DNS > caching. > > Or you can deploy DNSSEC. > > Or you can deploy SSL (not perfect, but it raises the bar considerably). > > Or you can google for "DNS RPZ" and start reading - the top hit seems to be > Paul Vixie's announcement: https://www.isc.org/community/blog/201007/taking-back-dns-0 > and start reading - as about the 4th or 5th commenter points out, the threat > model is *no* different than a DNS server that forces in its own zones. The > commenter is talking in the context of a provider replacing a zone, but it's the > same issue if a black hat hacks in a zone. > the one difference is that ISC will be shipping RPZ enabled code v. the blackhat having to hack the machine and modify the configuration. in the new BIND w/ RPZ, it will be much harder to determine when RPZ has been tweeked... Lowers the bar considerably. RPZ sucks /bill From marshall.eubanks at gmail.com Tue Dec 20 11:22:55 2011 From: marshall.eubanks at gmail.com (Marshall Eubanks) Date: Tue, 20 Dec 2011 12:22:55 -0500 Subject: what if...? In-Reply-To: <20111220133723.cfjv8g999ssoc8gg@fcaglp.fcaglp.unlp.edu.ar> References: <20111220133723.cfjv8g999ssoc8gg@fcaglp.fcaglp.unlp.edu.ar> Message-ID: On Tue, Dec 20, 2011 at 11:37 AM, Eduardo A. Su?rez wrote: > Hi, > > what if evil guys hack my mom ISP DNS servers and use RPZ to redirect > traffic from mom_bank.com to evil.com? > > How can she detect this? Does your Mom call you up every time she gets a dialog box complaining about an invalid certificate ? If she has been conditioned just to click "OK" when that happens, then she probably can't. Regards Marshall > > Eduardo.- > > -- > Eduardo A. Suarez > Facultad de Ciencias Astron?micas y Geof?sicas - UNLP > FCAG: (0221)-4236593 int. 172/Cel: (0221)-15-4557542/Casa: (0221)-4526589 > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > From sethm at rollernet.us Tue Dec 20 11:24:39 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 20 Dec 2011 09:24:39 -0800 Subject: what if...? In-Reply-To: References: <20111220133723.cfjv8g999ssoc8gg@fcaglp.fcaglp.unlp.edu.ar> <84355935-D650-40EB-AEE1-14755D6AB2DA@puck.nether.net> <5891AEFD-B1A0-44B6-BDD0-B818335060F3@firsthand.net> <4EF0C2FD.4050705@rollernet.us> Message-ID: <4EF0C4D7.5000505@rollernet.us> On 12/20/11 9:23 AM, Christian de Larrinaga wrote: > indeed.. now have your Mom read this again > C Uh, what? ~Seth From Valdis.Kletnieks at vt.edu Tue Dec 20 11:31:02 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 20 Dec 2011 17:31:02 +0000 Subject: what if...? In-Reply-To: Your message of "Tue, 20 Dec 2011 17:16:06 GMT." <20111220171606.GA22143@vacation.karoshi.com> References: <20111220133723.cfjv8g999ssoc8gg@fcaglp.fcaglp.unlp.edu.ar> <4930.1324399992@turing-police.cc.vt.edu> <20111220171606.GA22143@vacation.karoshi.com> Message-ID: <27876.1324402262@turing-police.cc.vt.edu> On Tue, 20 Dec 2011 17:16:06 GMT, bmanning at vacation.karoshi.com said: > the one difference is that ISC will be shipping RPZ enabled code v. > the blackhat having to hack the machine and modify the configuration. EIther way, the blackhat still has to hack the machine and modify the config. The only difference is what config change they make. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From luan at netcraftsmen.net Tue Dec 20 11:34:42 2011 From: luan at netcraftsmen.net (Luan Nguyen) Date: Tue, 20 Dec 2011 12:34:42 -0500 Subject: Nexus emulation? Anyone? In-Reply-To: <4EF0C0FC.2020905@gmail.com> References: <4EF093C1.1040806@gmail.com> <4EF0BFB6.1060605@foobar.org> <4EF0C0FC.2020905@gmail.com> Message-ID: You can't use the software switch Nexus 1000V to judge/discuss the Nexus family products N7K, N5K...etc as a whole? Check out this discussion https://supportforums.cisco.com/thread/2054884 Titanium as they call the NX-OS simulator is not available to the public though... -Luan On Tue, Dec 20, 2011 at 12:08 PM, -Hammer- wrote: > Bah. Look like I need more of an education on Nexus in general. Thanks for > the easy pointer. > > > -Hammer- > > "I was a normal American nerd" > -Jack Herer > > > > On 12/20/2011 11:02 AM, Nick Hilliard wrote: > >> On 20/12/2011 13:55, -Hammer- wrote: >> >> >>> I know we can't throw NX code on Dynamips but I figured I would ask the >>> group anyway. We are starting to discuss Nexus platform options and I can >>> only get so much from demo depot before our AM gets whiny. Is anyone >>> currently emulating Nexus on anything that is open to the public? >>> >>> >> nexus1k? >> >> Nick >> >> >> >> >> >> > From ken.gilmour at gmail.com Tue Dec 20 11:37:19 2011 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Tue, 20 Dec 2011 18:37:19 +0100 Subject: what if...? In-Reply-To: <20111220133723.cfjv8g999ssoc8gg@fcaglp.fcaglp.unlp.edu.ar> References: <20111220133723.cfjv8g999ssoc8gg@fcaglp.fcaglp.unlp.edu.ar> Message-ID: You probably want to google for the dnschanger virus -- Sent from my smart phone. Please excuse my brevity On Dec 20, 2011 4:38 p.m., "Eduardo A. Su?rez" < esuarez at fcaglp.fcaglp.unlp.edu.ar> wrote: > Hi, > > what if evil guys hack my mom ISP DNS servers and use RPZ to redirect > traffic from mom_bank.com to evil.com? > > How can she detect this? > > Eduardo.- > > -- > Eduardo A. Suarez > Facultad de Ciencias Astron?micas y Geof?sicas - UNLP > FCAG: (0221)-4236593 int. 172/Cel: (0221)-15-4557542/Casa: (0221)-4526589 > > > ------------------------------**------------------------------**---- > This message was sent using IMP, the Internet Messaging Program. > > > From sclark at netwolves.com Tue Dec 20 11:41:03 2011 From: sclark at netwolves.com (Steve Clark) Date: Tue, 20 Dec 2011 12:41:03 -0500 Subject: IPV6 issue (occaid.net) In-Reply-To: <4EF0C201.1090503@rancid.berkeley.edu> References: <4EF09908.3050701@netwolves.com> <4EF09CB1.1030501@unfix.org> <4EF0C201.1090503@rancid.berkeley.edu> Message-ID: <4EF0C8AF.2080402@netwolves.com> On 12/20/2011 12:12 PM, Michael Sinatra wrote: > On 12/20/11 06:33, Jeroen Massar wrote: >> On 2011-12-20 15:17 , Steve Clark wrote: >>> Hello, >>> >>> I have a SIXXS ipv6 tunnel that terminates in Ashburn, Va. >>> I have two HE ipv6 tunnels, one terminates in Dallas the other >>> terminate in Ashburn. I can ping each endpoint of the tunnels that >>> terminate >>> in Ashburn, but I can't ping between the SIXXS and HE with the HE >>> termination in Dallas. >>> >>> Using Looking Glass at HE I can traceroute to my SIXXS tunnel from >>> Chicago but >>> not from Dallas. >>> >>> Any ideas on how to get this fixed. >> Contact the providers involved directly? >> >> Sending a mail to ipv6 at he.net + info at sixxs.net should get you what you >> need, given that you actually provide IP addresses and other such useful >> diagnostics like interface configuration, routing tables etc etc etc. >> The above mail is far from useful and nobody would be able to help you >> in anyway except to state the above. > Actually, I was about to send a message about this. I believe the > problem is in occaid.net, particularly their router in Atlanta. > > SIXXS uses a variety of providers at various PoPs to provide their > tunnel connectivity and occaid.net is the provider at Ashburn (I have a > SIXXS tunnel there as well). Tracerouting from the West Coast or Texas > goes through occaid.net's router in Atlanta and dies there with 'network > unreachable': > > traceroute6 to burnttofu.net (2001:4830:1600:3bf::2) from > 2001:470:1f05:17a6:219:d1ff:fe26:5246, 64 hops max, 12 byte packets > 1 2001:470:1f05:17a6::1 0.316 ms 0.321 ms 0.321 ms > 2 100000-1.tunnel.tserv3.fmt2.ipv6.he.net 28.000 ms 22.402 ms > 26.169 ms > 3 gige-g5-19.core1.fmt2.he.net 16.697 ms 18.046 ms 15.891 ms > 4 10gigabitethernet6-4.core1.lax1.he.net 23.735 ms 25.327 ms 25.711 ms > 5 10gigabitethernet1-3.core1.lax2.he.net 25.708 ms 24.923 ms 25.793 ms > 6 2001:504:13::8 25.713 ms 23.731 ms 25.705 ms > 7 bbr01-v441.atln01.occaid.net 80.617 ms !N 88.252 ms !N 79.369 ms !N > > Tracerouting from the East Coast is fine: > traceroute6 to burnttofu.net (2001:4830:1600:3bf::2) from > 2001:470:30:80:e076:63ff:fe88:2d62, 64 hops max, 12 byte packets > 1 2001:470:30:80::2 21.739 ms 1.938 ms 2.474 ms > 2 gige-g3-3.core1.nyc4.he.net 8.678 ms 2.710 ms 2.596 ms > 3 10gigabitethernet2-3.core1.ash1.he.net 7.488 ms 7.168 ms 8.449 ms > 4 ibr01-ve96.asbn01.occaid.net 7.211 ms 7.272 ms 7.177 ms > 5 equi6ix.dc.hotnic.net 9.789 ms 8.597 ms 8.610 ms > 6 sixxs-asbnva-gw.customer.occaid.net 8.782 ms 8.100 ms 9.522 ms > 7 cl-960.qas-01.us.sixxs.net 22.621 ms 20.880 ms 21.072 ms > > Attempts to get a response from noc at occaid.net regarding this issue over > the past 36 hours have failed. If there is anyone here from occaid.net > or knows a clueful person there, can you please point them to this thread. > > I still think it's a good idea to contact info at sixxs.net, so they know > what's going on, but I don't think it's actually their problem. > > michael > I did and now it appears to be resolved. Thanks HE and SixXS. -- Stephen Clark *NetWolves* Sr. Software Engineer III Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark at netwolves.com http://www.netwolves.com From michael at rancid.berkeley.edu Tue Dec 20 11:46:11 2011 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Tue, 20 Dec 2011 09:46:11 -0800 Subject: what if...? In-Reply-To: <27876.1324402262@turing-police.cc.vt.edu> References: <20111220133723.cfjv8g999ssoc8gg@fcaglp.fcaglp.unlp.edu.ar> <4930.1324399992@turing-police.cc.vt.edu> <20111220171606.GA22143@vacation.karoshi.com> <27876.1324402262@turing-police.cc.vt.edu> Message-ID: <4EF0C9E3.2030803@rancid.berkeley.edu> On 12/20/11 09:31, Valdis.Kletnieks at vt.edu wrote: > On Tue, 20 Dec 2011 17:16:06 GMT, bmanning at vacation.karoshi.com said: > >> the one difference is that ISC will be shipping RPZ enabled code v. >> the blackhat having to hack the machine and modify the configuration. > > EIther way, the blackhat still has to hack the machine and modify the config. > The only difference is what config change they make. Yes and... If you have a really insecure DDNS update mechanism on your master RPZ zone, then I can see how RPZ might lower the bar *a little*, but I have to stretch my imagination quite a bit for that to happen. If your ISP doesn't use RPZ (regardless of whether the code is present in BIND), then the bad guy has to hack the box, set up an RPZ configuration, and then pollute it with bad data. Much easier to just install a bunch of fake zones. RPZ is a red herring here. michael From nanog-post at rsuc.gweep.net Tue Dec 20 11:55:58 2011 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Tue, 20 Dec 2011 12:55:58 -0500 Subject: software wanted In-Reply-To: <20111220163735.3d7a11c1@greg.bestnet.kharkov.ua> References: <20111220162150.08ee33b7@greg.bestnet.kharkov.ua> <20111220163735.3d7a11c1@greg.bestnet.kharkov.ua> Message-ID: <20111220175558.GA76916@gweep.net> On Tue, Dec 20, 2011 at 04:37:35PM +0200, Gregory Edigarov wrote: [snip] > > can anybody recomend a piece of software, that could "graph" a live > > network scanning it via snmp. > > requirements are: > > 1. must produce a text output suitable for postproduction. graphviz is > > an ideal, xml - acceptable. > > 2. must use no external database i.e. have text config file. clean > > text console, suitable to run as a cronjob. > > 3. must be able to work in heterogenous environment. > > > and, the question is about producing network schematic, not about > graphs like mrtg, cacti etc, etc.... Rather than SNMP probing, for larger layer3 networks try setting up a proper config archive (rancid), then build on mktop and top2dot: http://www.nanog.org/meetings/nanog26/presentations/stephen.pdf If you want to use SNMP and have good detail for layer2 networks and edge stations, take a look at http://www.netdisco.org/ Good old intermapper has been commercial for a while, does probing using several methods and makes pretty maps http://www.intermapper.com/ -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG From tstevens at cisco.com Tue Dec 20 12:03:09 2011 From: tstevens at cisco.com (Tim Stevenson) Date: Tue, 20 Dec 2011 10:03:09 -0800 Subject: Nexus emulation? Anyone? In-Reply-To: References: <4EF093C1.1040806@gmail.com> <4EF0BFB6.1060605@foobar.org> <4EF0C0FC.2020905@gmail.com> Message-ID: <201112201803.pBKI3abp032117@mtv-core-3.cisco.com> You couldn't use Titanium to judge/discuss the nexus family as a whole either. Aside from 1KV, all the nexus products use ASIC hardware specific to that platform/linecard and no NXOS software emulator exists that mimics those behaviors. 2 cents, Tim At 09:34 AM 12/20/2011, Luan Nguyen gushed: >You can't use the software switch Nexus 1000V to judge/discuss the Nexus >family products N7K, N5K...etc as a whole? > >Check out this discussion >https://supportforums.cisco.com/thread/2054884 > >Titanium as they call the NX-OS simulator is not available to the public >though... > >-Luan > >On Tue, Dec 20, 2011 at 12:08 PM, -Hammer- wrote: > > > Bah. Look like I need more of an education on Nexus in general. Thanks for > > the easy pointer. > > > > > > -Hammer- > > > > "I was a normal American nerd" > > -Jack Herer > > > > > > > > On 12/20/2011 11:02 AM, Nick Hilliard wrote: > > > >> On 20/12/2011 13:55, -Hammer- wrote: > >> > >> > >>> I know we can't throw NX code on Dynamips but I figured I would ask the > >>> group anyway. We are starting to discuss Nexus platform options and I can > >>> only get so much from demo depot before our AM gets whiny. Is anyone > >>> currently emulating Nexus on anything that is open to the public? > >>> > >>> > >> nexus1k? > >> > >> Nick > >> > >> > >> > >> > >> > >> > > Tim Stevenson, tstevens at cisco.com Routing & Switching CCIE #5561 Distinguished Technical Marketing Engineer, Cisco Nexus 7000 Cisco - http://www.cisco.com IP Phone: 408-526-6759 ******************************************************** The contents of this message may be *Cisco Confidential* and are intended for the specified recipients only. From bhmccie at gmail.com Tue Dec 20 12:15:19 2011 From: bhmccie at gmail.com (-Hammer-) Date: Tue, 20 Dec 2011 12:15:19 -0600 Subject: Nexus emulation? Anyone? In-Reply-To: <201112201803.pBKI3abp032117@mtv-core-3.cisco.com> References: <4EF093C1.1040806@gmail.com> <4EF0BFB6.1060605@foobar.org> <4EF0C0FC.2020905@gmail.com> <201112201803.pBKI3abp032117@mtv-core-3.cisco.com> Message-ID: <4EF0D0B7.4040202@gmail.com> I am understanding that more as I am researching. I didn't realize there was a separation between 1000v and [5,7]K. I thought Nexus was Nexus. I should have known not to simplify it to that level. :) So I'm understanding more the differences as well as why I won't be expecting to find a good way to emulate the [5,7]K anytime soon. Thank you all for your comments. -Hammer- "I was a normal American nerd" -Jack Herer On 12/20/2011 12:03 PM, Tim Stevenson wrote: > You couldn't use Titanium to judge/discuss the nexus family as a whole > either. Aside from 1KV, all the nexus products use ASIC hardware > specific to that platform/linecard and no NXOS software emulator > exists that mimics those behaviors. > > 2 cents, > Tim > > At 09:34 AM 12/20/2011, Luan Nguyen gushed: > >> You can't use the software switch Nexus 1000V to judge/discuss the Nexus >> family products N7K, N5K...etc as a whole? >> >> Check out this discussion >> https://supportforums.cisco.com/thread/2054884 >> >> >> Titanium as they call the NX-OS simulator is not available to the public >> though... >> >> -Luan >> >> On Tue, Dec 20, 2011 at 12:08 PM, -Hammer- wrote: >> >> > Bah. Look like I need more of an education on Nexus in general. >> Thanks for >> > the easy pointer. >> > >> > >> > -Hammer- >> > >> > "I was a normal American nerd" >> > -Jack Herer >> > >> > >> > >> > On 12/20/2011 11:02 AM, Nick Hilliard wrote: >> > >> >> On 20/12/2011 13:55, -Hammer- wrote: >> >> >> >> >> >>> I know we can't throw NX code on Dynamips but I figured I would >> ask the >> >>> group anyway. We are starting to discuss Nexus platform options >> and I can >> >>> only get so much from demo depot before our AM gets whiny. Is anyone >> >>> currently emulating Nexus on anything that is open to the public? >> >>> >> >>> >> >> nexus1k? >> >> >> >> Nick >> >> >> >> >> >> >> >> >> >> >> >> >> > > > > > > Tim Stevenson, tstevens at cisco.com > Routing & Switching CCIE #5561 > Distinguished Technical Marketing Engineer, Cisco Nexus 7000 > Cisco - http://www.cisco.com > IP Phone: 408-526-6759 > ******************************************************** > The contents of this message may be *Cisco Confidential* > and are intended for the specified recipients only. > > > From dsinn at dsinn.com Tue Dec 20 12:19:02 2011 From: dsinn at dsinn.com (David Sinn) Date: Tue, 20 Dec 2011 10:19:02 -0800 Subject: Nexus emulation? Anyone? In-Reply-To: <201112201803.pBKI3abp032117@mtv-core-3.cisco.com> References: <4EF093C1.1040806@gmail.com> <4EF0BFB6.1060605@foobar.org> <4EF0C0FC.2020905@gmail.com> <201112201803.pBKI3abp032117@mtv-core-3.cisco.com> Message-ID: <81162EB3-8A8F-40E1-9631-13ED0E6580CB@dsinn.com> I don't think anyone is asking for a full simulation of the platform in software, that is how the actual ASIC's operate. That is probably best for an entirely different conversation. But there is huge need to simulate the control-plane functionally with a basic forwarding ability (not performant, but pass packets correctly such that you can verify the topology). This is something Dyanmips does great in emulating a cluster of 7200's and allows operators to validate topologies and planned changes in mainstream IOS platforms. Having that for NX-OS would increase the adoption and confidence in the platform. VM's on multiple boxes make simulating a whole network of a given platform simple and easy. From the outside Cisco continues to miss the need for this. At least some of the other vendors are picking up how helpful this and are reacting positively to it. David On Dec 20, 2011, at 10:03 AM, Tim Stevenson wrote: > You couldn't use Titanium to judge/discuss the nexus family as a whole either. Aside from 1KV, all the nexus products use ASIC hardware specific to that platform/linecard and no NXOS software emulator exists that mimics those behaviors. > > 2 cents, > Tim > > At 09:34 AM 12/20/2011, Luan Nguyen gushed: > >> You can't use the software switch Nexus 1000V to judge/discuss the Nexus >> family products N7K, N5K...etc as a whole? >> >> Check out this discussion >> https://supportforums.cisco.com/thread/2054884 >> >> Titanium as they call the NX-OS simulator is not available to the public >> though... >> >> -Luan >> >> On Tue, Dec 20, 2011 at 12:08 PM, -Hammer- wrote: >> >> > Bah. Look like I need more of an education on Nexus in general. Thanks for >> > the easy pointer. >> > >> > >> > -Hammer- >> > >> > "I was a normal American nerd" >> > -Jack Herer >> > >> > >> > >> > On 12/20/2011 11:02 AM, Nick Hilliard wrote: >> > >> >> On 20/12/2011 13:55, -Hammer- wrote: >> >> >> >> >> >>> I know we can't throw NX code on Dynamips but I figured I would ask the >> >>> group anyway. We are starting to discuss Nexus platform options and I can >> >>> only get so much from demo depot before our AM gets whiny. Is anyone >> >>> currently emulating Nexus on anything that is open to the public? >> >>> >> >>> >> >> nexus1k? >> >> >> >> Nick >> >> >> >> >> >> >> >> >> >> >> >> >> > > > > > > Tim Stevenson, tstevens at cisco.com > Routing & Switching CCIE #5561 > Distinguished Technical Marketing Engineer, Cisco Nexus 7000 > Cisco - http://www.cisco.com > IP Phone: 408-526-6759 > ******************************************************** > The contents of this message may be *Cisco Confidential* > and are intended for the specified recipients only. > > From bhmccie at gmail.com Tue Dec 20 12:18:47 2011 From: bhmccie at gmail.com (-Hammer-) Date: Tue, 20 Dec 2011 12:18:47 -0600 Subject: Nexus emulation? Anyone? In-Reply-To: <81162EB3-8A8F-40E1-9631-13ED0E6580CB@dsinn.com> References: <4EF093C1.1040806@gmail.com> <4EF0BFB6.1060605@foobar.org> <4EF0C0FC.2020905@gmail.com> <201112201803.pBKI3abp032117@mtv-core-3.cisco.com> <81162EB3-8A8F-40E1-9631-13ED0E6580CB@dsinn.com> Message-ID: <4EF0D187.1000807@gmail.com> Doesn't "Titanium" achieve this for you? I know. It's Internal. But it simulates the 7k. Or am I getting it backwards? My point is that if Cisco already simulates it Internally it's only a matter of time before someone ports something.... -Hammer- "I was a normal American nerd" -Jack Herer On 12/20/2011 12:19 PM, David Sinn wrote: > I don't think anyone is asking for a full simulation of the platform in software, that is how the actual ASIC's operate. That is probably best for an entirely different conversation. > > But there is huge need to simulate the control-plane functionally with a basic forwarding ability (not performant, but pass packets correctly such that you can verify the topology). This is something Dyanmips does great in emulating a cluster of 7200's and allows operators to validate topologies and planned changes in mainstream IOS platforms. Having that for NX-OS would increase the adoption and confidence in the platform. VM's on multiple boxes make simulating a whole network of a given platform simple and easy. > > From the outside Cisco continues to miss the need for this. At least some of the other vendors are picking up how helpful this and are reacting positively to it. > > David > > > > On Dec 20, 2011, at 10:03 AM, Tim Stevenson wrote: > > >> You couldn't use Titanium to judge/discuss the nexus family as a whole either. Aside from 1KV, all the nexus products use ASIC hardware specific to that platform/linecard and no NXOS software emulator exists that mimics those behaviors. >> >> 2 cents, >> Tim >> >> At 09:34 AM 12/20/2011, Luan Nguyen gushed: >> >> >>> You can't use the software switch Nexus 1000V to judge/discuss the Nexus >>> family products N7K, N5K...etc as a whole? >>> >>> Check out this discussion >>> https://supportforums.cisco.com/thread/2054884 >>> >>> Titanium as they call the NX-OS simulator is not available to the public >>> though... >>> >>> -Luan >>> >>> On Tue, Dec 20, 2011 at 12:08 PM, -Hammer- wrote: >>> >>> >>>> Bah. Look like I need more of an education on Nexus in general. Thanks for >>>> the easy pointer. >>>> >>>> >>>> -Hammer- >>>> >>>> "I was a normal American nerd" >>>> -Jack Herer >>>> >>>> >>>> >>>> On 12/20/2011 11:02 AM, Nick Hilliard wrote: >>>> >>>> >>>>> On 20/12/2011 13:55, -Hammer- wrote: >>>>> >>>>> >>>>> >>>>>> I know we can't throw NX code on Dynamips but I figured I would ask the >>>>>> group anyway. We are starting to discuss Nexus platform options and I can >>>>>> only get so much from demo depot before our AM gets whiny. Is anyone >>>>>> currently emulating Nexus on anything that is open to the public? >>>>>> >>>>>> >>>>>> >>>>> nexus1k? >>>>> >>>>> Nick >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >> >> >> >> Tim Stevenson, tstevens at cisco.com >> Routing& Switching CCIE #5561 >> Distinguished Technical Marketing Engineer, Cisco Nexus 7000 >> Cisco - http://www.cisco.com >> IP Phone: 408-526-6759 >> ******************************************************** >> The contents of this message may be *Cisco Confidential* >> and are intended for the specified recipients only. >> >> >> > > From tstevens at cisco.com Tue Dec 20 12:31:30 2011 From: tstevens at cisco.com (Tim Stevenson) Date: Tue, 20 Dec 2011 10:31:30 -0800 Subject: Nexus emulation? Anyone? In-Reply-To: <4EF0D187.1000807@gmail.com> References: <4EF093C1.1040806@gmail.com> <4EF0BFB6.1060605@foobar.org> <4EF0C0FC.2020905@gmail.com> <201112201803.pBKI3abp032117@mtv-core-3.cisco.com> <81162EB3-8A8F-40E1-9631-13ED0E6580CB@dsinn.com> <4EF0D187.1000807@gmail.com> Message-ID: <201112201831.pBKIVZE1019138@mtv-core-2.cisco.com> At 10:18 AM 12/20/2011, -Hammer- gushed: >Doesn't "Titanium" achieve this for you? I know. It's Internal. But it >simulates the 7k. Or am I getting it backwards? Titanium is basically the NXOS control plane, sans data plane. It's the "platform independent" part of the OS. >My point is that if Cisco already simulates it Internally it's only a >matter of time before someone ports something.... Not saying whether it's right or wrong, but maintaining, releasing, & supporting it would require resources, which as you can imagine get prioritized onto other things. Tim >-Hammer- > >"I was a normal American nerd" >-Jack Herer > > > >On 12/20/2011 12:19 PM, David Sinn wrote: > > I don't think anyone is asking for a full simulation of the > platform in software, that is how the actual ASIC's operate. That > is probably best for an entirely different conversation. > > > > But there is huge need to simulate the control-plane functionally > with a basic forwarding ability (not performant, but pass packets > correctly such that you can verify the topology). This is > something Dyanmips does great in emulating a cluster of 7200's and > allows operators to validate topologies and planned changes in > mainstream IOS platforms. Having that for NX-OS would increase the > adoption and confidence in the platform. VM's on multiple boxes > make simulating a whole network of a given platform simple and easy. > > > > From the outside Cisco continues to miss the need for this. At > least some of the other vendors are picking up how helpful this and > are reacting positively to it. > > > > David > > > > management for a while now, so sorry if this is a duplicate you've > already seen.> > > > > On Dec 20, 2011, at 10:03 AM, Tim Stevenson wrote: > > > > > >> You couldn't use Titanium to judge/discuss the nexus family as a > whole either. Aside from 1KV, all the nexus products use ASIC > hardware specific to that platform/linecard and no NXOS software > emulator exists that mimics those behaviors. > >> > >> 2 cents, > >> Tim > >> > >> At 09:34 AM 12/20/2011, Luan Nguyen gushed: > >> > >> > >>> You can't use the software switch Nexus 1000V to judge/discuss the Nexus > >>> family products N7K, N5K...etc as a whole? > >>> > >>> Check out this discussion > >>> > <https://supportforums.cisco.com/thread/2054884>https://supportforums.cisco.com/thread/2054884 > >>> > >>> Titanium as they call the NX-OS simulator is not available to the public > >>> though... > >>> > >>> -Luan > >>> > >>> On Tue, Dec 20, 2011 at 12:08 PM, -Hammer- wrote: > >>> > >>> > >>>> Bah. Look like I need more of an education on Nexus in > general. Thanks for > >>>> the easy pointer. > >>>> > >>>> > >>>> -Hammer- > >>>> > >>>> "I was a normal American nerd" > >>>> -Jack Herer > >>>> > >>>> > >>>> > >>>> On 12/20/2011 11:02 AM, Nick Hilliard wrote: > >>>> > >>>> > >>>>> On 20/12/2011 13:55, -Hammer- wrote: > >>>>> > >>>>> > >>>>> > >>>>>> I know we can't throw NX code on Dynamips but I figured I > would ask the > >>>>>> group anyway. We are starting to discuss Nexus platform > options and I can > >>>>>> only get so much from demo depot before our AM gets whiny. Is anyone > >>>>>> currently emulating Nexus on anything that is open to the public? > >>>>>> > >>>>>> > >>>>>> > >>>>> nexus1k? > >>>>> > >>>>> Nick > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >> > >> > >> > >> Tim Stevenson, tstevens at cisco.com > >> Routing& Switching CCIE #5561 > >> Distinguished Technical Marketing Engineer, Cisco Nexus 7000 > >> Cisco - http://www.cisco.com > >> IP Phone: 408-526-6759 > >> ******************************************************** > >> The contents of this message may be *Cisco Confidential* > >> and are intended for the specified recipients only. > >> > >> > >> > > > > Tim Stevenson, tstevens at cisco.com Routing & Switching CCIE #5561 Distinguished Technical Marketing Engineer, Cisco Nexus 7000 Cisco - http://www.cisco.com IP Phone: 408-526-6759 ******************************************************** The contents of this message may be *Cisco Confidential* and are intended for the specified recipients only. From bhmccie at gmail.com Tue Dec 20 12:40:20 2011 From: bhmccie at gmail.com (-Hammer-) Date: Tue, 20 Dec 2011 12:40:20 -0600 Subject: Nexus emulation? Anyone? In-Reply-To: <201112201831.pBKIVZE1019138@mtv-core-2.cisco.com> References: <4EF093C1.1040806@gmail.com> <4EF0BFB6.1060605@foobar.org> <4EF0C0FC.2020905@gmail.com> <201112201803.pBKI3abp032117@mtv-core-3.cisco.com> <81162EB3-8A8F-40E1-9631-13ED0E6580CB@dsinn.com> <4EF0D187.1000807@gmail.com> <201112201831.pBKIVZE1019138@mtv-core-2.cisco.com> Message-ID: <4EF0D694.9090004@gmail.com> OK. Thanks for the clarification. I understand that resources would be required to support such an effort. I was more or less implying that if it's done Internally it probably won't be long before someone comes up with a way to do it (Dynamips part deux) for the public. Not supported by Cisco. I don't see how it can hurt Cisco to have people wanting to run their stuff for learning/training/validation purposes in a virtual environment. But that is a whole different thread. -Hammer- "I was a normal American nerd" -Jack Herer On 12/20/2011 12:31 PM, Tim Stevenson wrote: > At 10:18 AM 12/20/2011, -Hammer- gushed: > >> Doesn't "Titanium" achieve this for you? I know. It's Internal. But it >> simulates the 7k. Or am I getting it backwards? > > Titanium is basically the NXOS control plane, sans data plane. It's > the "platform independent" part of the OS. > > >> My point is that if Cisco already simulates it Internally it's only a >> matter of time before someone ports something.... > > Not saying whether it's right or wrong, but maintaining, releasing, & > supporting it would require resources, which as you can imagine get > prioritized onto other things. > > Tim > > >> -Hammer- >> >> "I was a normal American nerd" >> -Jack Herer >> >> >> >> On 12/20/2011 12:19 PM, David Sinn wrote: >> > I don't think anyone is asking for a full simulation of the >> platform in software, that is how the actual ASIC's operate. That is >> probably best for an entirely different conversation. >> > >> > But there is huge need to simulate the control-plane functionally >> with a basic forwarding ability (not performant, but pass packets >> correctly such that you can verify the topology). This is something >> Dyanmips does great in emulating a cluster of 7200's and allows >> operators to validate topologies and planned changes in mainstream >> IOS platforms. Having that for NX-OS would increase the adoption and >> confidence in the platform. VM's on multiple boxes make simulating a >> whole network of a given platform simple and easy. >> > >> > From the outside Cisco continues to miss the need for this. At >> least some of the other vendors are picking up how helpful this and >> are reacting positively to it. >> > >> > David >> > >> > > management for a while now, so sorry if this is a duplicate you've >> already seen.> >> > >> > On Dec 20, 2011, at 10:03 AM, Tim Stevenson wrote: >> > >> > >> >> You couldn't use Titanium to judge/discuss the nexus family as a >> whole either. Aside from 1KV, all the nexus products use ASIC >> hardware specific to that platform/linecard and no NXOS software >> emulator exists that mimics those behaviors. >> >> >> >> 2 cents, >> >> Tim >> >> >> >> At 09:34 AM 12/20/2011, Luan Nguyen gushed: >> >> >> >> >> >>> You can't use the software switch Nexus 1000V to judge/discuss >> the Nexus >> >>> family products N7K, N5K...etc as a whole? >> >>> >> >>> Check out this discussion >> >>> >> <https://supportforums.cisco.com/thread/2054884>https://supportforums.cisco.com/thread/2054884 >> >> >>> >> >>> Titanium as they call the NX-OS simulator is not available to the >> public >> >>> though... >> >>> >> >>> -Luan >> >>> >> >>> On Tue, Dec 20, 2011 at 12:08 PM, -Hammer- >> wrote: >> >>> >> >>> >> >>>> Bah. Look like I need more of an education on Nexus in general. >> Thanks for >> >>>> the easy pointer. >> >>>> >> >>>> >> >>>> -Hammer- >> >>>> >> >>>> "I was a normal American nerd" >> >>>> -Jack Herer >> >>>> >> >>>> >> >>>> >> >>>> On 12/20/2011 11:02 AM, Nick Hilliard wrote: >> >>>> >> >>>> >> >>>>> On 20/12/2011 13:55, -Hammer- wrote: >> >>>>> >> >>>>> >> >>>>> >> >>>>>> I know we can't throw NX code on Dynamips but I figured I >> would ask the >> >>>>>> group anyway. We are starting to discuss Nexus platform >> options and I can >> >>>>>> only get so much from demo depot before our AM gets whiny. Is >> anyone >> >>>>>> currently emulating Nexus on anything that is open to the public? >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>> nexus1k? >> >>>>> >> >>>>> Nick >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>> >> >> >> >> >> >> >> >> Tim Stevenson, tstevens at cisco.com >> >> Routing& Switching CCIE #5561 >> >> Distinguished Technical Marketing Engineer, Cisco Nexus 7000 >> >> Cisco - http://www.cisco.com >> >> IP Phone: 408-526-6759 >> >> ******************************************************** >> >> The contents of this message may be *Cisco Confidential* >> >> and are intended for the specified recipients only. >> >> >> >> >> >> >> > >> > > > > > > Tim Stevenson, tstevens at cisco.com > Routing & Switching CCIE #5561 > Distinguished Technical Marketing Engineer, Cisco Nexus 7000 > Cisco - http://www.cisco.com > IP Phone: 408-526-6759 > ******************************************************** > The contents of this message may be *Cisco Confidential* > and are intended for the specified recipients only. > > From dsinn at dsinn.com Tue Dec 20 12:51:25 2011 From: dsinn at dsinn.com (David Sinn) Date: Tue, 20 Dec 2011 10:51:25 -0800 Subject: Nexus emulation? Anyone? In-Reply-To: <4EF0D187.1000807@gmail.com> References: <4EF093C1.1040806@gmail.com> <4EF0BFB6.1060605@foobar.org> <4EF0C0FC.2020905@gmail.com> <201112201803.pBKI3abp032117@mtv-core-3.cisco.com> <81162EB3-8A8F-40E1-9631-13ED0E6580CB@dsinn.com> <4EF0D187.1000807@gmail.com> Message-ID: Titanium is a release vehicle for LISP (http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/release/LISP/50_lisp_nx-os_release_note.html), so it is public knowledge of it's existence. Given that Titanium is just a PC with a few NIC's there shouldn't be much effort to get it to run under QEMU/KVM/[VM of your choice]. It would probably take someone some time to try and hack it together or quicker if Cisco was willing to publish some "use at your own risk" pointers. It is, as Tim points out, a support question. Hopefully the pressure of their large customers will get them to see that the support is worth it for the continued adoption of the platform. As I said, other vendors have clued in to this and thus their friction to adoption is reduced as a result. David On Dec 20, 2011, at 10:18 AM, -Hammer- wrote: > Doesn't "Titanium" achieve this for you? I know. It's Internal. But it simulates the 7k. Or am I getting it backwards? > > My point is that if Cisco already simulates it Internally it's only a matter of time before someone ports something.... > > -Hammer- > > "I was a normal American nerd" > -Jack Herer > > > > On 12/20/2011 12:19 PM, David Sinn wrote: >> I don't think anyone is asking for a full simulation of the platform in software, that is how the actual ASIC's operate. That is probably best for an entirely different conversation. >> >> But there is huge need to simulate the control-plane functionally with a basic forwarding ability (not performant, but pass packets correctly such that you can verify the topology). This is something Dyanmips does great in emulating a cluster of 7200's and allows operators to validate topologies and planned changes in mainstream IOS platforms. Having that for NX-OS would increase the adoption and confidence in the platform. VM's on multiple boxes make simulating a whole network of a given platform simple and easy. >> >> From the outside Cisco continues to miss the need for this. At least some of the other vendors are picking up how helpful this and are reacting positively to it. >> >> David >> >> >> >> On Dec 20, 2011, at 10:03 AM, Tim Stevenson wrote: >> >> >>> You couldn't use Titanium to judge/discuss the nexus family as a whole either. Aside from 1KV, all the nexus products use ASIC hardware specific to that platform/linecard and no NXOS software emulator exists that mimics those behaviors. >>> >>> 2 cents, >>> Tim >>> >>> At 09:34 AM 12/20/2011, Luan Nguyen gushed: >>> >>> >>>> You can't use the software switch Nexus 1000V to judge/discuss the Nexus >>>> family products N7K, N5K...etc as a whole? >>>> >>>> Check out this discussion >>>> https://supportforums.cisco.com/thread/2054884 >>>> >>>> Titanium as they call the NX-OS simulator is not available to the public >>>> though... >>>> >>>> -Luan >>>> >>>> On Tue, Dec 20, 2011 at 12:08 PM, -Hammer- wrote: >>>> >>>> >>>>> Bah. Look like I need more of an education on Nexus in general. Thanks for >>>>> the easy pointer. >>>>> >>>>> >>>>> -Hammer- >>>>> >>>>> "I was a normal American nerd" >>>>> -Jack Herer >>>>> >>>>> >>>>> >>>>> On 12/20/2011 11:02 AM, Nick Hilliard wrote: >>>>> >>>>> >>>>>> On 20/12/2011 13:55, -Hammer- wrote: >>>>>> >>>>>> >>>>>> >>>>>>> I know we can't throw NX code on Dynamips but I figured I would ask the >>>>>>> group anyway. We are starting to discuss Nexus platform options and I can >>>>>>> only get so much from demo depot before our AM gets whiny. Is anyone >>>>>>> currently emulating Nexus on anything that is open to the public? >>>>>>> >>>>>>> >>>>>>> >>>>>> nexus1k? >>>>>> >>>>>> Nick >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>> >>> >>> >>> Tim Stevenson, tstevens at cisco.com >>> Routing& Switching CCIE #5561 >>> Distinguished Technical Marketing Engineer, Cisco Nexus 7000 >>> Cisco - http://www.cisco.com >>> IP Phone: 408-526-6759 >>> ******************************************************** >>> The contents of this message may be *Cisco Confidential* >>> and are intended for the specified recipients only. >>> >>> >>> >> >> From dave.nanog at alfordmedia.com Tue Dec 20 12:52:58 2011 From: dave.nanog at alfordmedia.com (Dave Pooser) Date: Tue, 20 Dec 2011 13:52:58 -0500 Subject: BGP noob needs monitoring advice Message-ID: Earlier this year I got a /24 of PA space, set up our shiny new router, got BGP working with both my upstreams, and heaved a sigh of relief: "I'll never have to think about THAT again!" (Okay, quit laughing; I SAID I was a noob!) Now, I discover that one of my upstreams quit announcing our route in November (fortunately the provider who assigned us the /24, so we're still covered in their /18) and the other upstream apparently started filtering our announcements last week. I'm working with both of them to get that fixed, but it's made it clear to me that I need to be monitoring this. My question for the group is, how? I can and do monitor my own router, and I can see that I'm receiving full routes from both ISPs. I am capable of manually accessing route servers and looking glass servers to check if they're receiving routes to me, but I'd like something more automated. Free is nice, $$ is not a problem, $$$$ might become a problem. Thanks in advance for any suggestions. -- Dave Pooser Manager of Information Services Alford Media http://www.alfordmedia.com From mksmith at adhost.com Tue Dec 20 12:57:28 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Tue, 20 Dec 2011 18:57:28 +0000 Subject: BGP noob needs monitoring advice In-Reply-To: References: Message-ID: Hey: Manually speaking, you can always telnet to route-views.routeviews.org which is a restricted Cisco interface. Log in with username "rviews" and don't enable. From the prompt you can do all the "show ip bgp" commands you need to see whether or not your /24 is being announced via your upstream providers. As an example 'sho ip bgp x.x.x.x' where x.x.x.x is your /24. You should see the announcement originating from your AS over multiple providers that includes both of yours. If not, you know you have a problem. Mike -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) > -----Original Message----- > From: Dave Pooser [mailto:dave.nanog at alfordmedia.com] > Sent: Tuesday, December 20, 2011 10:53 AM > To: nanog at nanog.org > Subject: BGP noob needs monitoring advice > > Earlier this year I got a /24 of PA space, set up our shiny new router, > got BGP working with both my upstreams, and heaved a sigh of relief: "I'll > never have to think about THAT again!" (Okay, quit laughing; I SAID I was > a noob!) > > Now, I discover that one of my upstreams quit announcing our route in > November (fortunately the provider who assigned us the /24, so we're still > covered in their /18) and the other upstream apparently started filtering > our announcements last week. I'm working with both of them to get that > fixed, but it's made it clear to me that I need to be monitoring this. > > My question for the group is, how? I can and do monitor my own router, and > I can see that I'm receiving full routes from both ISPs. I am capable of > manually accessing route servers and looking glass servers to check if > they're receiving routes to me, but I'd like something more automated. > Free is nice, $$ is not a problem, $$$$ might become a problem. > > Thanks in advance for any suggestions. > -- > Dave Pooser > Manager of Information Services > Alford Media http://www.alfordmedia.com > > From hank at efes.iucc.ac.il Tue Dec 20 13:03:14 2011 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 20 Dec 2011 21:03:14 +0200 Subject: BGP noob needs monitoring advice In-Reply-To: Message-ID: <5.1.0.14.2.20111220210142.00c459c0@efes.iucc.ac.il> At 13:52 20/12/2011 -0500, Dave Pooser wrote: Use one of the following services: http://cyclops.cs.ucla.edu/ http://bgpmon.net/ You'll get an email whenever a routing change takes place in regards to the prefix you are monitoring. -Hank >Earlier this year I got a /24 of PA space, set up our shiny new router, >got BGP working with both my upstreams, and heaved a sigh of relief: "I'll >never have to think about THAT again!" (Okay, quit laughing; I SAID I was >a noob!) > >Now, I discover that one of my upstreams quit announcing our route in >November (fortunately the provider who assigned us the /24, so we're still >covered in their /18) and the other upstream apparently started filtering >our announcements last week. I'm working with both of them to get that >fixed, but it's made it clear to me that I need to be monitoring this. > >My question for the group is, how? I can and do monitor my own router, and >I can see that I'm receiving full routes from both ISPs. I am capable of >manually accessing route servers and looking glass servers to check if >they're receiving routes to me, but I'd like something more automated. >Free is nice, $$ is not a problem, $$$$ might become a problem. > >Thanks in advance for any suggestions. >-- >Dave Pooser >Manager of Information Services >Alford Media http://www.alfordmedia.com From bclark at spectraaccess.com Tue Dec 20 13:16:20 2011 From: bclark at spectraaccess.com (Bret Clark) Date: Tue, 20 Dec 2011 14:16:20 -0500 Subject: BGP noob needs monitoring advice In-Reply-To: <5.1.0.14.2.20111220210142.00c459c0@efes.iucc.ac.il> References: <5.1.0.14.2.20111220210142.00c459c0@efes.iucc.ac.il> Message-ID: <4EF0DF04.50908@spectraaccess.com> Is http://cyclops.cs.ucla.edu/ still working? I don't seem to received emails from them anymore when we stop announcing to one of our upstream providers. On the other hand http://bgpmon.net/ does send me emails when an announcement disappears from an upstream, although it's usually a day later. On 12/20/2011 02:03 PM, Hank Nussbacher wrote: > At 13:52 20/12/2011 -0500, Dave Pooser wrote: > > Use one of the following services: > http://cyclops.cs.ucla.edu/ > http://bgpmon.net/ > You'll get an email whenever a routing change takes place in regards to the > prefix you are monitoring. > > -Hank > >> Earlier this year I got a /24 of PA space, set up our shiny new router, >> got BGP working with both my upstreams, and heaved a sigh of relief: "I'll >> never have to think about THAT again!" (Okay, quit laughing; I SAID I was >> a noob!) >> >> Now, I discover that one of my upstreams quit announcing our route in >> November (fortunately the provider who assigned us the /24, so we're still >> covered in their /18) and the other upstream apparently started filtering >> our announcements last week. I'm working with both of them to get that >> fixed, but it's made it clear to me that I need to be monitoring this. >> >> My question for the group is, how? I can and do monitor my own router, and >> I can see that I'm receiving full routes from both ISPs. I am capable of >> manually accessing route servers and looking glass servers to check if >> they're receiving routes to me, but I'd like something more automated. >> Free is nice, $$ is not a problem, $$$$ might become a problem. >> >> Thanks in advance for any suggestions. >> -- >> Dave Pooser >> Manager of Information Services >> Alford Media http://www.alfordmedia.com > From paul4004 at gmail.com Tue Dec 20 13:17:06 2011 From: paul4004 at gmail.com (PC) Date: Tue, 20 Dec 2011 13:17:06 -0600 Subject: BGP noob needs monitoring advice In-Reply-To: <5.1.0.14.2.20111220210142.00c459c0@efes.iucc.ac.il> References: <5.1.0.14.2.20111220210142.00c459c0@efes.iucc.ac.il> Message-ID: Depending on the nature of your redundant connections, your traffic engineering/bgp settings, and the visibility of the routing through the lost provider to the internet route servers mentioned, you may/may not be able to easily monitor this. Some failures are harder to find than others. Suggestions: 1) On the provider that stopped accepting your prefix, your inbound traffic would have dropped to 0. Monitor for this if this isn't by design already. 2) Use the bgpmon suggested by Dave below to see events which are visible to the route server they use. On Tue, Dec 20, 2011 at 1:03 PM, Hank Nussbacher wrote: > At 13:52 20/12/2011 -0500, Dave Pooser wrote: > > Use one of the following services: > http://cyclops.cs.ucla.edu/ > http://bgpmon.net/ > You'll get an email whenever a routing change takes place in regards to > the prefix you are monitoring. > > -Hank > > > Earlier this year I got a /24 of PA space, set up our shiny new router, >> got BGP working with both my upstreams, and heaved a sigh of relief: "I'll >> never have to think about THAT again!" (Okay, quit laughing; I SAID I was >> a noob!) >> >> Now, I discover that one of my upstreams quit announcing our route in >> November (fortunately the provider who assigned us the /24, so we're still >> covered in their /18) and the other upstream apparently started filtering >> our announcements last week. I'm working with both of them to get that >> fixed, but it's made it clear to me that I need to be monitoring this. >> >> My question for the group is, how? I can and do monitor my own router, and >> I can see that I'm receiving full routes from both ISPs. I am capable of >> manually accessing route servers and looking glass servers to check if >> they're receiving routes to me, but I'd like something more automated. >> Free is nice, $$ is not a problem, $$$$ might become a problem. >> >> Thanks in advance for any suggestions. >> -- >> Dave Pooser >> Manager of Information Services >> Alford Media http://www.alfordmedia.com >> > > > From rlaager at wiktel.com Tue Dec 20 13:19:31 2011 From: rlaager at wiktel.com (Richard Laager) Date: Tue, 20 Dec 2011 13:19:31 -0600 Subject: BGP noob needs monitoring advice In-Reply-To: References: Message-ID: <1324408771.8484.52.camel@watermelon.coderich.net> Try this: http://bgpmon.net/ Richard From andree+nanog at toonk.nl Tue Dec 20 13:43:45 2011 From: andree+nanog at toonk.nl (Andree Toonk) Date: Tue, 20 Dec 2011 11:43:45 -0800 Subject: BGP noob needs monitoring advice In-Reply-To: <4EF0DF04.50908@spectraaccess.com> References: <5.1.0.14.2.20111220210142.00c459c0@efes.iucc.ac.il> <4EF0DF04.50908@spectraaccess.com> Message-ID: <4EF0E571.20305@toonk.nl> Hi, .-- My secret spy satellite informs me that at 11-12-20 11:16 AM Bret Clark wrote: > Is http://cyclops.cs.ucla.edu/ still working? I don't seem to received > emails from them anymore when we stop announcing to one of our upstream > providers. On the other hand http://bgpmon.net/ does send me emails when > an announcement disappears from an upstream, although it's usually a day > later. Just to clarify this: For all alert types below BGPmon.net sends out an alert within minutes: 1) prefix withdrawal (prefix disappeared) 2) new upstream 3) new prefix 4) origin AS changes 5) ASpath regex failure 6) policy violation 7) RPKI validation failure There's one other feature, the routing-report feature, that runs only once a day. It's similar as the cidr report, but specific to your AS. I like to refer to it as a rancid for your BGP announcements. It's basically a diff between how your routes were visible today and yesterday. This specific feature will also notify the user if you lost / gained one or more upstreams per prefix. Also see http://bgpmon.net/blog/?p=257 for more information about that specific feature. Cheers, Andree From marka at isc.org Tue Dec 20 14:22:47 2011 From: marka at isc.org (Mark Andrews) Date: Wed, 21 Dec 2011 07:22:47 +1100 Subject: IPV6 issue In-Reply-To: Your message of "Tue, 20 Dec 2011 09:17:44 CDT." <4EF09908.3050701@netwolves.com> References: <4EF09908.3050701@netwolves.com> Message-ID: <20111220202247.2F80E1A5E341@drugs.dv.isc.org> In message <4EF09908.3050701 at netwolves.com>, Steve Clark writes: > Hello, > > I have a SIXXS ipv6 tunnel that terminates in Ashburn, Va. > I have two HE ipv6 tunnels, one terminates in Dallas the other > terminate in Ashburn. I can ping each endpoint of the tunnels that terminate > in Ashburn, but I can't ping between the SIXXS and HE with the HE termination > in Dallas. > > Using Looking Glass at HE I can traceroute to my SIXXS tunnel from Chicago bu > t > not from Dallas. > > Any ideas on how to get this fixed. > > This problem only started occurring within the last week or so. > > Thanks for your indulgence, > -- > Stephen Clark > *NetWolves* > Sr. Software Engineer III > Phone: 813-579-3200 > Fax: 813-882-0209 > Email: steve.clark at netwolves.com > http://www.netwolves.com noc at he.net have always been good when I've had strange issues. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From michael at rancid.berkeley.edu Tue Dec 20 14:35:09 2011 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Tue, 20 Dec 2011 12:35:09 -0800 Subject: IPV6 issue In-Reply-To: <20111220202247.2F80E1A5E341@drugs.dv.isc.org> References: <4EF09908.3050701@netwolves.com> <20111220202247.2F80E1A5E341@drugs.dv.isc.org> Message-ID: <4EF0F17D.7090901@rancid.berkeley.edu> On 12/20/11 12:22, Mark Andrews wrote: > In message<4EF09908.3050701 at netwolves.com>, Steve Clark writes: >> Hello, >> >> I have a SIXXS ipv6 tunnel that terminates in Ashburn, Va. >> I have two HE ipv6 tunnels, one terminates in Dallas the other >> terminate in Ashburn. I can ping each endpoint of the tunnels that terminate >> in Ashburn, but I can't ping between the SIXXS and HE with the HE termination >> in Dallas. >> >> Using Looking Glass at HE I can traceroute to my SIXXS tunnel from Chicago bu >> t >> not from Dallas. >> >> Any ideas on how to get this fixed. >> >> This problem only started occurring within the last week or so. >> >> Thanks for your indulgence, >> -- >> Stephen Clark >> *NetWolves* >> Sr. Software Engineer III >> Phone: 813-579-3200 >> Fax: 813-882-0209 >> Email: steve.clark at netwolves.com >> http://www.netwolves.com > > noc at he.net have always been good when I've had strange issues. It wasn't strictly an HE problem, since I could reproduce it from Level3's looking glass. In both cases, the occaid.net router in Atlanta appeared to be the Point of Breakage. It looks like the problem has been resolved. michael From marka at isc.org Tue Dec 20 16:06:05 2011 From: marka at isc.org (Mark Andrews) Date: Wed, 21 Dec 2011 09:06:05 +1100 Subject: what if...? In-Reply-To: Your message of "Tue, 20 Dec 2011 13:37:23 -0300." <20111220133723.cfjv8g999ssoc8gg@fcaglp.fcaglp.unlp.edu.ar> References: <20111220133723.cfjv8g999ssoc8gg@fcaglp.fcaglp.unlp.edu.ar> Message-ID: <20111220220606.140721A5FC63@drugs.dv.isc.org> In message <20111220133723.cfjv8g999ssoc8gg at fcaglp.fcaglp.unlp.edu.ar>, "Eduard o A. =?iso-8859-1?b?U3XhcmV6?=" writes: > Hi, > > what if evil guys hack my mom ISP DNS servers and use RPZ to redirect =20 > traffic from mom_bank.com to evil.com? > > How can she detect this? The bank signs their zone and mum's machine validates the answers it gets from the ISP. This is not rocket science. This is not beyond the capabilities of even the smallest client that mom would use to talk to the bank. This is how DNSSEC was designed to be used. Validating in the resolver protects the resolver itself and the cache from pollution. It also protects non DNSSEC aware clients from upstream of the resolver threats. It was always expected that clients would validate answers themselves. Mark > Eduardo.- > > --=20 > Eduardo A. Suarez > Facultad de Ciencias Astron=F3micas y Geof=EDsicas - UNLP > FCAG: (0221)-4236593 int. 172/Cel: (0221)-15-4557542/Casa: (0221)-4526589 > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jra at baylink.com Tue Dec 20 16:21:42 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 20 Dec 2011 17:21:42 -0500 (EST) Subject: DNS zone response speed test tool? In-Reply-To: Message-ID: <17999945.1328.1324419702702.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Todd Lyons" > Doesn't do much for long term graphing and monitoring, but for quickie > issue detection or verification, http://www.grc.com/dns/benchmark.htm Am I mistaken in thinking that's a tool for measuring the efficiency and accessibility of *customer resolver* servers, not zone servers? 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 http://photo.imageinc.us +1 727 647 1274 From jra at baylink.com Tue Dec 20 18:34:28 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 20 Dec 2011 19:34:28 -0500 (EST) Subject: RIP DMR - a postscript Message-ID: <12754189.1374.1324427668383.JavaMail.root@benjamin.baylink.com> In case it hadn't occurred to anyone to look back: http://cm.bell-labs.com/who/dmr/ 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 http://photo.imageinc.us +1 727 647 1274 From tlyons at ivenue.com Tue Dec 20 18:57:26 2011 From: tlyons at ivenue.com (Todd Lyons) Date: Tue, 20 Dec 2011 16:57:26 -0800 Subject: DNS zone response speed test tool? In-Reply-To: <17999945.1328.1324419702702.JavaMail.root@benjamin.baylink.com> References: <17999945.1328.1324419702702.JavaMail.root@benjamin.baylink.com> Message-ID: On Tue, Dec 20, 2011 at 2:21 PM, Jay Ashworth wrote: > >> Doesn't do much for long term graphing and monitoring, but for quickie >> issue detection or verification, http://www.grc.com/dns/benchmark.htm > Am I mistaken in thinking that's a tool for measuring the efficiency and > accessibility of *customer resolver* servers, not zone servers? Oops, yeah, I was thinking it would do timing of zone servers, but it's aimed at resolvers. Sorry for the misdirection. ...Todd -- If Americans could eliminate sugary beverages, potatoes, white bread, pasta, white rice and sugary snacks, we would wipe out almost all the problems we have with weight and diabetes and other metabolic diseases. -- Dr. Walter Willett, Harvard School of Public Health From mike.lyon at gmail.com Tue Dec 20 19:00:39 2011 From: mike.lyon at gmail.com (Mike Lyon) Date: Tue, 20 Dec 2011 17:00:39 -0800 Subject: Any clueful Megapath/Covad peeps on the list? Message-ID: If so, can you ping me off-list? Having issues finding clue through your phone tree. Thank You, Mike From don at bowenvale.co.nz Tue Dec 20 20:44:36 2011 From: don at bowenvale.co.nz (Don Gould) Date: Wed, 21 Dec 2011 15:44:36 +1300 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> Message-ID: <4EF14814.2080709@bowenvale.co.nz> On 20/12/2011 8:31 p.m., Owen DeLong wrote: > Ideally, the IETF should provide complete solutions based on DHCPv6 and > on RA and let the operators decide what they want to use in their environments. +1 I would like to see a simple presentation of the different ways of setting up a small network at the edge with the features, benefits and issues, of each method. My interest is in networks with 2 to 20 devices in them. ie, small business and home. I would also like to see a survey of how people are setting up their small networks. While some are interested in the purest way of setting them up, I'm not. I'm interested in how people are setting them up. When setting up networks for customers, I'm interested in doing it in the most common way. What I don't want is to end up with a bad name because I set up stuff 'the right way' but in such a way that the next tech the customer calls gets annoyed that what I've done is so complex that it will cost the customer $$$$$ to fix a fault. I'm sure these comments have been made by others in the past, I'm just adding a voice. D -- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699 From daniel.unam.ipv6 at gmail.com Tue Dec 20 21:04:05 2011 From: daniel.unam.ipv6 at gmail.com (Daniel Espejel) Date: Tue, 20 Dec 2011 21:04:05 -0600 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: Message-ID: <4EF14CA5.8010905@gmail.com> IPv6-RA autoconfiguration method allows to autoconfigure ipv6-capable network interfaces by sending IPv6 prefixes throughout a link, so every node that understands its message format can derive its own IPv6 address based on internal algorithms. By using RA, you can configure almost any node to serve as a router (i.e. running RADVD). As a matter of fact, there are some flags in the RAs to set the DHCP as the "complement device" to get full information about the network. In cases when the only thing you need to know its a basic network configuration (routes), or if devices don't need to use another external services such as DNS, RA should me enough. On the other hand, DHCPv6 works in a way very similar like DHCPv4, and you can spread information like the DNS-servers for a given link or network. More advanced auto-configuration schemas may be reached if using RA+DHCPv6. Think on scenarios like mobile networks, multihommed hosts and low-power consuption ip based network-based networks. BR. -- Daniel Espejel P?rez From andrew.wallace at rocketmail.com Tue Dec 20 21:08:10 2011 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Tue, 20 Dec 2011 19:08:10 -0800 (PST) Subject: Happy xmas folks Message-ID: <1324436890.96419.YahooMailNeo@web162104.mail.bf1.yahoo.com> I just want to say happy xmas to everyone at NANOG. I'm about to sign off for the holidays. Andrew From trelane at trelane.net Tue Dec 20 21:44:30 2011 From: trelane at trelane.net (Andrew D Kirch) Date: Tue, 20 Dec 2011 22:44:30 -0500 Subject: Happy xmas folks In-Reply-To: <1324436890.96419.YahooMailNeo@web162104.mail.bf1.yahoo.com> References: <1324436890.96419.YahooMailNeo@web162104.mail.bf1.yahoo.com> Message-ID: <4EF1561E.5000009@trelane.net> On 12/20/2011 10:08 PM, andrew.wallace wrote: > I just want to say happy xmas to everyone at NANOG. > > I'm about to sign off for the holidays. > > > Andrew enjoy your chistmas, and you don't have to come back after the holidays, we'll be fine without you. Andrew From andrew.wallace at rocketmail.com Tue Dec 20 21:49:03 2011 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Tue, 20 Dec 2011 19:49:03 -0800 (PST) Subject: Happy xmas folks In-Reply-To: <1324436890.96419.YahooMailNeo@web162104.mail.bf1.yahoo.com> References: <1324436890.96419.YahooMailNeo@web162104.mail.bf1.yahoo.com> Message-ID: <1324439343.26724.YahooMailNeo@web162102.mail.bf1.yahoo.com> On Wed, Dec 21, 2011 at 3:44 AM, Andrew D Kirch wrote: > On 12/20/2011 10:08 PM, andrew.wallace wrote: >> >> I just want to say happy xmas to everyone at NANOG. >> >> I'm about to sign off for the holidays. >> >> >> Andrew > > enjoy your chistmas, and you don't have to come back after the holidays, > we'll be fine without you. > > Andrew Thats fine. Andrew https://plus.google.com/115085501867247270932/about From nanog-02 at jeremykister.com Wed Dec 21 00:57:50 2011 From: nanog-02 at jeremykister.com (Jeremy Kister) Date: Wed, 21 Dec 2011 01:57:50 -0500 Subject: BGP noob needs monitoring advice In-Reply-To: References: Message-ID: <4EF1836E.9090004@jeremykister.com> On 12/20/2011 1:52 PM, Dave Pooser wrote: > My question for the group is, how? I can and do monitor my own router, and > I can see that I'm receiving full routes from both ISPs. I am capable of you might want to start with a good monitoring software like Argus - http://argus.tcp4me.com/ Group "Upstream Connections" { Group "T3 to whomever" { Service Ping { hostname: far-side.example.net } Service UDP/SNMP { eqvalue: 6 label: BGP uname: BGP oid: .1.3.6.1.2.1.15.3.1.2.x.x.x.x hostname: your-router.example.net } } Group "T3 to whomever2" { Service Ping { hostname: far-other-side.example.net } Service UDP/SNMP { eqvalue: 6 label: BGP uname: BGP oid: .1.3.6.1.2.1.15.3.1.2.x.x.x.x hostname: your-router.example.net } } } something like that will alert you when BGP is anything other than happy. your oid may vary. use snmpwalk to help. then you could also add: Service Prog { frequency: 1800 command: chkbgp.pl -a -n -r nexepect: evil } *http://jeremy.kister.net/code/perl/chkbgp.pl -- Jeremy Kister http://jeremy.kister.net./ From oscar.vives at gmail.com Wed Dec 21 06:27:18 2011 From: oscar.vives at gmail.com (Tei) Date: Wed, 21 Dec 2011 13:27:18 +0100 Subject: Happy xmas folks In-Reply-To: <1324439343.26724.YahooMailNeo@web162102.mail.bf1.yahoo.com> References: <1324436890.96419.YahooMailNeo@web162104.mail.bf1.yahoo.com> <1324439343.26724.YahooMailNeo@web162102.mail.bf1.yahoo.com> Message-ID: >> On 12/20/2011 10:08 PM, andrew.wallace wrote: >>> >>> I just want to say happy xmas to everyone at NANOG. >>> >>> I'm about to sign off for the holidays. >>> >>> >>> Andrew >> >> enjoy your chistmas, and you don't have to come back after the holidays, >> we'll be fine without you. >> > Has a gamer, I hope ipv6 come sooon. Singleplayer videogames are a historic weird thing. Since the begin of humanity most games has ben cooperative or competitive. But tryiing to host a videogame (serving the game) from behind a crappy router, using NAT, is not fun. It is even more crappy because hardware manufactures produce these horrible interfaces in these routers ( my favorte pet-peeve is limit to forward 6 ports). I suppose nobody in this mail list will have any problem in configuring one of these things. But for 99.999% of the gamers, even the concepts are unknowm. Now that gaming is mainstream, and more than 500 millions persons play games daily, more and more people his exposed to the crappyness of crappy NAT configure dialogs on crappy routers. Please made the pain stop. I am looking forward for a day where you would be able to avoid NAT, and share your ip with your teammates, to have a pain-free experience. So gamers don't have to study sites like this one: http://portforward.com/ -- -- ?in del ?ensaje. From vinny at abellohome.net Wed Dec 21 07:17:36 2011 From: vinny at abellohome.net (Vinny Abello) Date: Wed, 21 Dec 2011 08:17:36 -0500 Subject: BGP noob needs monitoring advice In-Reply-To: <4EF0E571.20305@toonk.nl> References: <5.1.0.14.2.20111220210142.00c459c0@efes.iucc.ac.il> <4EF0DF04.50908@spectraaccess.com> <4EF0E571.20305@toonk.nl> Message-ID: <4EF1DC70.9030803@abellohome.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/20/2011 2:43 PM, Andree Toonk wrote: > Hi, > > .-- My secret spy satellite informs me that at 11-12-20 11:16 AM Bret Clark wrote: >> Is http://cyclops.cs.ucla.edu/ still working? I don't seem to received >> emails from them anymore when we stop announcing to one of our upstream >> providers. On the other hand http://bgpmon.net/ does send me emails when >> an announcement disappears from an upstream, although it's usually a day >> later. > > Just to clarify this: > For all alert types below BGPmon.net sends out an alert within minutes: > 1) prefix withdrawal (prefix disappeared) > 2) new upstream > 3) new prefix > 4) origin AS changes > 5) ASpath regex failure > 6) policy violation > 7) RPKI validation failure > > There's one other feature, the routing-report feature, that runs only once a day. It's similar as the cidr report, but specific to your AS. I like to refer to it as a rancid for your BGP announcements. > > It's basically a diff between how your routes were visible today and yesterday. This specific feature will also notify the user if you lost / gained one or more upstreams per prefix. > Also see http://bgpmon.net/blog/?p=257 for more information about that specific feature. Unless I'm misunderstanding something, I'm concerned regarding the IPv4 bogon list on http://bgpmon.net/showbogons.php?inet=4 . It clearly includes several /8's that should not be there. The data seems to be stale as if some job is no longer pulling the updated data. It states it's being pulled from http://www.cymru.com/Documents/bogon-bn-nonagg.txt , but that clearly does not contain 100/8, 5/8, 181/8, 49/8 and a few others... and hasn't for quite some time. - -Vinny -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) iEYEARECAAYFAk7x3G8ACgkQUyX7ywEAl3rMjACg87ma/guBPU8mmhy/jfxz6Dzx s6wAnRGXMTU2P1tRE+Azm+eSMKW1YENL =RyFn -----END PGP SIGNATURE----- From ge at linuxbox.org Wed Dec 21 09:01:52 2011 From: ge at linuxbox.org (Gadi Evron) Date: Wed, 21 Dec 2011 17:01:52 +0200 Subject: Google's Schmidt on Iran supposedly hijacking GOOG'd .dk traffic Message-ID: <4EF1F4E0.3010703@linuxbox.org> Video at: http://edition.cnn.com/video/#/video/bestoftv/2011/12/13/erin-schmidt-on-iran.cnn Gadi. -- Gadi Evron, ge at linuxbox.org. Blog: http://gevron.livejournal.com/ From nanog2 at adns.net Wed Dec 21 09:36:08 2011 From: nanog2 at adns.net (John Palmer (NANOG Acct)) Date: Wed, 21 Dec 2011 09:36:08 -0600 Subject: Well Lookie Here, Barracuda Networks tries to get me to fall into their trap again... Message-ID: Well look what was in my in-box this morning! Looks like Barracuda Networks is sending out spam again. Maybe word is getting around about their less that value-full renewal policy. Could it be that people are starting to resent being taken advantage of?? See my response below their message. Seems like they don't remember that I was a fish they already hooked and fleeced. --- SPAM from Barracuda ---- Howdy, Just following up with you about a project you were working on with Barracuda Networks. Checking in to see how things are going for you. Have you had network changes recently or a issue pop up that we can help solve? Let me know if you would like a solution guide for reference. Happy December, --- Message sent in response to the sales droid message from Barracuda --- Hi Jaz, No, things are about the same. I see by your website that you haven't changed a bit and continue to think that it is an honest business practice to charge people for a service and then not to deliver it. When I renew my Barracuda Engergize subscription, THE RENEWAL SHOULD BE FROM THE DATE THAT I RENEW, NOT THE ANNIVERSARY DATE! Many small businesses have cash flow challenges and cannot renew their subscription right at the expirartion date. Where does that leave them? If they have to delay their renewal by three or four months, they then get greeted by your company charging them for an entire year of service when they only actually get 8 or 9 months, since the renewal goes from the anniversary date instead of the anniversary date being reset to the actual date of renewal. As it stands right now, If we were to renew our Energize subscription, We'd have to pay for FIVE YEARS of service but would only get THREE years. If that isn't a rip-off, I don't know what is. I think this is dishonest business practice. I will no longer give money to what I view as a crooked company such as yours. I have posted about this corrupt practice on my blog (http://www.john-palmer.net/wordpress/?p=46) and on facebook. Think I'll "bump" each of those postings to refresh them in the search engines so that people continue to be informed of this practice so that they won't fall into the trap of doing business with your company as we did. Perhaps for your collective New Year's resolution at Barracuda Networks, you can all resolve to operate your business in an honest fashion and provide FAIR value with FAIR business practices in 2012, both of which, in my opinion, you are severly lacking. Maybe then, PERHAPS, we may look at doing further business with you. From john-nanog at johnpeach.com Wed Dec 21 09:41:48 2011 From: john-nanog at johnpeach.com (John Peach) Date: Wed, 21 Dec 2011 10:41:48 -0500 Subject: Well Lookie Here, Barracuda Networks tries to get me to fall into their trap again... In-Reply-To: References: Message-ID: <20111221104148.4565907e@jpeach-desktop.anbg.mssm.edu> On Wed, 21 Dec 2011 09:36:08 -0600 "John Palmer \(NANOG Acct\)" wrote: > Well look what was in my in-box this morning! Looks like Barracuda > Networks is sending out spam again. Maybe word is getting around > about their less that value-full renewal policy. Could it be that > people are starting to resent being taken advantage of?? > > See my response below their message. Seems like they don't remember > that I was a fish they already hooked and fleeced. > [rest of rant snipped] This has nothing to do with NANOG and is standard practice in the software industry anyway. From rps at maine.edu Wed Dec 21 10:25:53 2011 From: rps at maine.edu (Ray Soucy) Date: Wed, 21 Dec 2011 11:25:53 -0500 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: Message-ID: Agree that in the long term support for more flexibility is good. Acknowledge that change is slow, and we're just at a point now where popular host systems even include mature DHCPv6 (but without route options). Both of the features discussed would be useful in specific applications, but more often than not what get's used is what most host implementations support, so the horse may have already left the barn on that one, at least for the next 5 years or so. RA + SLAAC is great for residential environments and automatic discovery. For a more controlled environment, RA + DHCPv6 is increasingly attractive, especially in a dual-stack environment where having a similar operational model for both protocols can simplify operations and support, and allow for a phased deployment. Remember, an RFC is just an idea on how things should work; it's not a standard until most people choose to implement it. "The nice thing about standards is that you have so many to choose from." On Tue, Dec 20, 2011 at 1:27 AM, Ravi Duggal wrote: > Hi, > > IPv6 devices (routers and hosts) can obtain configuration information > about default routers, on-link prefixes and addresses from Router > Advertisements as defined in ? Neighbor Discovery. ?I have been told > that in some deployments, there is a strong desire not to use Router > Advertisements at all and to perform all configuration via DHCPv6. > There are thus similar IETF standards to get everything that you can > get from RAs, by using DHCPv6 instead. > > As a result of this we see new proposals in IETF that try to do > similar things by either extending RA mechanisms or by introducing new > options in DHCPv6. > > We thus have draft-droms-dhc-dhcpv6-default-router-00 that extends > DHCPv6 to do what RA does. And now, we have > draft-bcd-6man-ntp-server-ra-opt-00.txt that extends RA to advertise > the NTP information that is currently done via DHCPv6. > > My question is, that which then is the more preferred option for the > operators? Do they prefer extending RA so that the new information > loaded on top of the RA messages gets known in the single shot when > routers do neighbor discovery. Or do they prefer all the extra > information to be learnt via DHCPv6? What are the pros and cons in > each approach and when would people favor one over the other? > > I can see some advantages with the loading information to RA since > then one is not dependent on the DHCPv6 server. However, the latter > provides its own benefits. > > Regards, > Ravi D. > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From cjp at 0x1.net Wed Dec 21 11:06:14 2011 From: cjp at 0x1.net (Christopher J. Pilkington) Date: Wed, 21 Dec 2011 12:06:14 -0500 Subject: BGPmon regex Message-ID: I'm trying to edit my prefixes' AS path regex in BGPmon, and when I add a '\s' in the Regular expression field, upon save, the '\' is stripped. Is this expected behavior? The workaround is to insert a '\\s' instead, but one needs to remember to do this on every edit, and I tend to forget which results in panicking the others on our team with false positives. -cjp From andree+nanog at toonk.nl Wed Dec 21 11:31:58 2011 From: andree+nanog at toonk.nl (Andree Toonk) Date: Wed, 21 Dec 2011 09:31:58 -0800 Subject: BGP noob needs monitoring advice In-Reply-To: <4EF1DC70.9030803@abellohome.net> References: <5.1.0.14.2.20111220210142.00c459c0@efes.iucc.ac.il> <4EF0DF04.50908@spectraaccess.com> <4EF0E571.20305@toonk.nl> <4EF1DC70.9030803@abellohome.net> Message-ID: <4EF2180E.4010103@toonk.nl> Hi Vinny, .-- My secret spy satellite informs me that at 11-12-21 5:17 AM Vinny Abello wrote: > Unless I'm misunderstanding something, I'm concerned regarding the IPv4 bogon list on http://bgpmon.net/showbogons.php?inet=4 . It clearly includes several /8's that should not be there. The data seems to be stale as if some job is no longer pulling the updated data. It states it's being pulled from http://www.cymru.com/Documents/bogon-bn-nonagg.txt , but that clearly does not contain 100/8, 5/8, 181/8, 49/8 and a few others... and hasn't for quite some time. The http://bgpmon.net/showbogons.php?inet=4 page show a list of bogons that were announced at a certain point in time, so the page show historical announcements as well (check the date). For example the last 100/8 bogons were detected on 2010-10-29, at that time it was still considered a bogon. The list is not stale, there's just very few IPv4 bogons left :) We do still see RFC1918 announcements: http://www.bgpmon.net/showbogons.php?inet=4&global=yes&private=yes And of course IPv6 bogons, Last month for example: 18c::/16 http://www.bgpmon.net/showbogons.php?global=yes&private=yes&inet=6 Cheers, Andree From brandon.kim at brandontek.com Wed Dec 21 11:43:15 2011 From: brandon.kim at brandontek.com (Brandon Kim) Date: Wed, 21 Dec 2011 12:43:15 -0500 Subject: BGPmon regex In-Reply-To: References: Message-ID: I'm not familiar with BGPmon but your symptoms sounds like typical programming issue. The '\' is stripped probably due to a "Stripslashes" function in the code. So by doing double '\\' you kinda trick the code into only doing the first one. I don't really know of any way around this. > Date: Wed, 21 Dec 2011 12:06:14 -0500 > Subject: BGPmon regex > From: cjp at 0x1.net > To: nanog at nanog.org > > I'm trying to edit my prefixes' AS path regex in BGPmon, and when I add a > '\s' in the Regular expression field, upon save, the '\' is stripped. > > Is this expected behavior? > > The workaround is to insert a '\\s' instead, but one needs to remember to > do this on every edit, and I tend to forget which results in panicking the > others on our team with false positives. > > -cjp From kemp at network-services.uoregon.edu Wed Dec 21 11:48:03 2011 From: kemp at network-services.uoregon.edu (John Kemp) Date: Wed, 21 Dec 2011 09:48:03 -0800 Subject: routeviews.org domain registration In-Reply-To: References: Message-ID: <4EF21BD3.7040205@network-services.uoregon.edu> On 12/20/11 4:09 AM, Andy Davidson wrote: > On 20 Dec 2011, at 12:02, Stephen Strowes wrote: > >> I pinged John Kemp at uoregon.edu, but unsure if he is the correct contact for this. > I beeped Dave Meyer, who acknowledged, so I think someone is on it. > > Andy Dave jumped on it and got it taken care of. Thanks to all the kind folks who notified us of the issue. -- John Kemp (kemp at network-services.uoregon.edu) RouteViews Engineer From jra at baylink.com Wed Dec 21 11:54:35 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 21 Dec 2011 12:54:35 -0500 (EST) Subject: Well Lookie Here, Barracuda Networks tries to get me to fall into their trap again... In-Reply-To: <20111221104148.4565907e@jpeach-desktop.anbg.mssm.edu> Message-ID: <1449422.1440.1324490075558.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "John Peach" > On Wed, 21 Dec 2011 09:36:08 -0600 > "John Palmer \(NANOG Acct\)" wrote: > > > Well look what was in my in-box this morning! Looks like Barracuda > > Networks is sending out spam again. Maybe word is getting around > > about their less that value-full renewal policy. Could it be that > > people are starting to resent being taken advantage of?? > > > > See my response below their message. Seems like they don't remember > > that I was a fish they already hooked and fleeced. > > > [rest of rant snipped] > > This has nothing to do with NANOG and is standard practice in the > software industry anyway. In fact, it's not. If you miss your renewal payment for, frex, Safari books, they actually slip your cycle date to when you renew -- since you don't *get* the service between the expire date and the renew date, I concur with his appraisal that you shouldn't be paying for it, either. If in fact, the service *kept working* for a short time when an overlooked payment was missed, it would be a different story. But, effectively, he's a new client, and should probably be treated that way. Assuming the paid service is actually *the update service*. I also disagree with your proposition that this is off-topic for NANOG, really. 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 http://photo.imageinc.us +1 727 647 1274 From andree+nanog at toonk.nl Wed Dec 21 12:03:03 2011 From: andree+nanog at toonk.nl (Andree Toonk) Date: Wed, 21 Dec 2011 10:03:03 -0800 Subject: BGPmon regex In-Reply-To: References: Message-ID: <4EF21F57.7080209@toonk.nl> Hi Christopher, .-- My secret spy satellite informs me that at 11-12-21 9:06 AM Christopher J. Pilkington wrote: > I'm trying to edit my prefixes' AS path regex in BGPmon, and when I add a > '\s' in the Regular expression field, upon save, the '\' is stripped. > > Is this expected behavior? > > The workaround is to insert a '\\s' instead, but one needs to remember to > do this on every edit, and I tend to forget which results in panicking the > others on our team with false positives. I believe this should be fixed now, please try again. Contact me directly (andree at bgpmon.net) if the problem persists or if you have any other bgpmon.net questions. Alternatively, as a replacement for \s you can also just use a white space for example: (6327|13768|852) 271$ Cheers, Andree From deric.kwok2000 at gmail.com Wed Dec 21 12:41:10 2011 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Wed, 21 Dec 2011 13:41:10 -0500 Subject: Any tools to help network security Message-ID: Hi We discover there are so many (source) ip not belonging to our network to go to outside. We can block it but don't know how to locate the source. Any tools can be easily found out. Thank you From nathan at atlasnetworks.us Wed Dec 21 12:46:50 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Wed, 21 Dec 2011 18:46:50 +0000 Subject: Well Lookie Here, Barracuda Networks tries to get me to fall into their trap again... In-Reply-To: <1449422.1440.1324490075558.JavaMail.root@benjamin.baylink.com> References: <20111221104148.4565907e@jpeach-desktop.anbg.mssm.edu> <1449422.1440.1324490075558.JavaMail.root@benjamin.baylink.com> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B6354A8@ex-mb-1.corp.atlasnetworks.us> > In fact, it's not. If you miss your renewal payment for, frex, Safari > books, > they actually slip your cycle date to when you renew -- since you don't > *get* > the service between the expire date and the renew date, I concur with > his > appraisal that you shouldn't be paying for it, either. > > If in fact, the service *kept working* for a short time when an > overlooked payment was missed, it would be a different story. > > But, effectively, he's a new client, and should probably be treated > that way. > Assuming the paid service is actually *the update service*. > > I also disagree with your proposition that this is off-topic for NANOG, > really. I've always strongly felt that this was a rather foul business practice, wherever I've seen it. The justification for it is the utterly misguided belief that, if allowed to, customers will pay for a month then cancel their subscription and 'coast' on the 'current' version of the signature for a year. This approach suffers from (at least) two fundamental flaws: 1) The entire customer base are treated as hostile. It is no surprise that they resent this. (Assumption: having resentful customers is bad) 2) Spam is, perhaps moreso than ever, a rapidly evolving threat. The effectiveness of signatures declines dramatically with time, which means that August's signatures have little value by December. [By the way, it seems to me that if they're willing to charge for valueless signatures, that represents either A) doubt as to the value of the current signatures, or B) disbelief in the decreasing value of out of date signatures.] While I realize that car insurance might not be the best analogy subject, imagine if you put your car on blocks, went off to college and allowed the insurance to lapse whilst you were there. When you return, the insurance company wants you to pay the last three years of insurance in order to reactivate your policy. That companies customers would react in the same way: they would find a new provider to do business with, rather than pay out for a valueless bit of smoke and mirrors. Nathan Eisenberg From jeremyparr at gmail.com Wed Dec 21 13:00:42 2011 From: jeremyparr at gmail.com (Jeremy Parr) Date: Wed, 21 Dec 2011 14:00:42 -0500 Subject: Well Lookie Here, Barracuda Networks tries to get me to fall into their trap again... In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B6354A8@ex-mb-1.corp.atlasnetworks.us> References: <20111221104148.4565907e@jpeach-desktop.anbg.mssm.edu> <1449422.1440.1324490075558.JavaMail.root@benjamin.baylink.com> <8C26A4FDAE599041A13EB499117D3C286B6354A8@ex-mb-1.corp.atlasnetworks.us> Message-ID: On 21 December 2011 13:46, Nathan Eisenberg wrote: > I've always strongly felt that this was a rather foul business practice, > wherever I've seen it. The justification for it is the utterly misguided > belief that, if allowed to, customers will pay for a month then cancel > their subscription and 'coast' on the 'current' version of the signature > for a year. This approach suffers from (at least) two fundamental flaws: > > 1) The entire customer base are treated as hostile. It is no surprise > that they resent this. (Assumption: having resentful customers is bad) > 2) Spam is, perhaps moreso than ever, a rapidly evolving threat. The > effectiveness of signatures declines dramatically with time, which means > that August's signatures have little value by December. [By the way, it > seems to me that if they're willing to charge for valueless signatures, > that represents either A) doubt as to the value of the current signatures, > or B) disbelief in the decreasing value of out of date signatures.] > > While I realize that car insurance might not be the best analogy subject, > imagine if you put your car on blocks, went off to college and allowed the > insurance to lapse whilst you were there. When you return, the insurance > company wants you to pay the last three years of insurance in order to > reactivate your policy. That companies customers would react in the same > way: they would find a new provider to do business with, rather than pay > out for a valueless bit of smoke and mirrors. > > Nathan Eisenberg > Exactly. And when you consider the fact that most anyone can roll their own solution with Postfix, Postgrey, a few RBLs, and Spamassassin that works just as well - if not better than a Barracuda, trying to justify back charging is even more unbelievable. From sthaug at nethelp.no Wed Dec 21 13:03:16 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 21 Dec 2011 20:03:16 +0100 (CET) Subject: Any tools to help network security In-Reply-To: References: Message-ID: <20111221.200316.41697039.sthaug@nethelp.no> > We discover there are so many (source) ip not belonging to our network > to go to outside. > > We can block it but don't know how to locate the source. > > Any tools can be easily found out. http://lmgtfy.com/?q=unicast+rpf Steinar Haug, Nethelp consulting, sthaug at nethelp.no From edward.dore at freethought-internet.co.uk Wed Dec 21 13:09:15 2011 From: edward.dore at freethought-internet.co.uk (Edward Dore) Date: Wed, 21 Dec 2011 19:09:15 +0000 Subject: Well Lookie Here, Barracuda Networks tries to get me to fall into their trap again... In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B6354A8@ex-mb-1.corp.atlasnetworks.us> References: <20111221104148.4565907e@jpeach-desktop.anbg.mssm.edu> <1449422.1440.1324490075558.JavaMail.root@benjamin.baylink.com> <8C26A4FDAE599041A13EB499117D3C286B6354A8@ex-mb-1.corp.atlasnetworks.us> Message-ID: <2F1D4FA4-107A-49C4-B5E5-CD40B282B9B2@freethought-internet.co.uk> On 21 Dec 2011, at 18:46, Nathan Eisenberg wrote: >> In fact, it's not. If you miss your renewal payment for, frex, Safari >> books, >> they actually slip your cycle date to when you renew -- since you don't >> *get* >> the service between the expire date and the renew date, I concur with >> his >> appraisal that you shouldn't be paying for it, either. >> >> If in fact, the service *kept working* for a short time when an >> overlooked payment was missed, it would be a different story. >> >> But, effectively, he's a new client, and should probably be treated >> that way. >> Assuming the paid service is actually *the update service*. >> >> I also disagree with your proposition that this is off-topic for NANOG, >> really. > > I've always strongly felt that this was a rather foul business practice, wherever I've seen it. The justification for it is the utterly misguided belief that, if allowed to, customers will pay for a month then cancel their subscription and 'coast' on the 'current' version of the signature for a year. This approach suffers from (at least) two fundamental flaws: > > 1) The entire customer base are treated as hostile. It is no surprise that they resent this. (Assumption: having resentful customers is bad) > 2) Spam is, perhaps moreso than ever, a rapidly evolving threat. The effectiveness of signatures declines dramatically with time, which means that August's signatures have little value by December. [By the way, it seems to me that if they're willing to charge for valueless signatures, that represents either A) doubt as to the value of the current signatures, or B) disbelief in the decreasing value of out of date signatures.] > > While I realize that car insurance might not be the best analogy subject, imagine if you put your car on blocks, went off to college and allowed the insurance to lapse whilst you were there. When you return, the insurance company wants you to pay the last three years of insurance in order to reactivate your policy. That companies customers would react in the same way: they would find a new provider to do business with, rather than pay out for a valueless bit of smoke and mirrors. > > Nathan Eisenberg Are you turning your anti-spam appliance off whilst choosing not to pay for the maintenance? If not, then I'd argue that a better analogy would be that you don't pay for your car insurance but continue to drive your car around until you have an accident, at which point you try to take out a new policy so that you are covered. Whilst I can see the argument for the likes of signature updates, where you aren't receiving the service in the period that you haven't paid for (unless the signature update system is seriously broken), these kind of maintenance renewals for appliances normally also include software support and hardware repair/replacement. If the companies don't backdate the maintenance renewal, then you would end up with lots of companies only purchasing the maintenance on an ad-hoc basis and that will just make the renewals more expensive for those of us that actually pay attention to when our subscriptions to due to expire and how much they will cost to renew in order accurately predict cash flow. Edward Dore Freethought Internet From dmiller at tiggee.com Wed Dec 21 13:12:12 2011 From: dmiller at tiggee.com (David Miller) Date: Wed, 21 Dec 2011 14:12:12 -0500 Subject: Any tools to help network security In-Reply-To: <20111221.200316.41697039.sthaug@nethelp.no> References: <20111221.200316.41697039.sthaug@nethelp.no> Message-ID: <4EF22F8C.8090008@tiggee.com> On 12/21/2011 2:03 PM, sthaug at nethelp.no wrote: >> We discover there are so many (source) ip not belonging to our network >> to go to outside. >> >> We can block it but don't know how to locate the source. >> >> Any tools can be easily found out. > http://lmgtfy.com/?q=unicast+rpf > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no > Also - http://lmgtfy.com/?q=tracing+spoofed+source+on+network Which get you to some strategies for finding the source(s) on your network (which I believe was the OP's question). Including: http://www.csm.ornl.gov/~dunigan/oci/bktrk.html http://www.cymru.com/Documents/tracking-spoofed.html -DMM From tpoder at cis.vutbr.cz Wed Dec 21 13:16:34 2011 From: tpoder at cis.vutbr.cz (Tomas Podermanski) Date: Wed, 21 Dec 2011 20:16:34 +0100 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> Message-ID: <4EF23092.9090103@cis.vutbr.cz> Hi, from my perspective the short answer for this never-ending story is: - SLAAC/RA is totally useless, does not bring any benefit at all and should be removed from IPv6 specs - DHCPv6 should be extended by route options as proposed in http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-03 - DHCPv6 should be extended by layer 2 address to identify client's L2 address (something that we can see in RFC 6221) - DHCPv6 should be the common way to autoconfigure an address in a IPv6 environment The long answer is: I completely disagree with opinion that both DHCPv6 and RA (SLAAC) should be supported. It is easy to say that both have place but it has some consequences. I and my colleagues have been working on deploying IPv6 for a few years and from the operation perspective we conclude into a quite clear opinion in that area. Both SLAAC and DHCPv6 uses a opposite principles although the goal is just one. DHCPv6 is based on a central DHCPv6 server that assigns addresses. SLAAC does opposite - leaves the decision about the address on a client side. However we have to run both of them in a network to provide all necessary pieces of information to the clients (default route and DNS). This brings many implementation and operational complications. - Clients have to support both SLAAC and DHCPv6 to be able to work in both environments - There must be solved a situation what to do when SLAAC and DHCPv6 provides some conflict information (quite long thread with various opinions can be found at http://www.ietf.org/mail-archive/web/ipv6/current/msg14949.html) - The first hop security have to be solved twice - for SLAAC and for DHCPv6. Both of then uses a differed communication way. SLAAC is part of ICMPv6, but DHCPv6 uses "own" UDP communication what does not make things easier. - SLAAC is usually processed in a kernel, DHCPv6 is usually run as a process in the user space. Diagnostic and troubleshooting is more complicated. - DHCPv6 is currently tied with SLAAC (M,O flags), what means that a DHCPv6 client have to wait until some RA message arrives to start DHCPv6 discovery. That unnecessary prolongs whole autoconfiguration process. Some other issues are also described in [1]. I personally prefer to bury SLAAC once forever for several reasons: - In fact SLAAC does nothing more what DHCPv6 can do. - SLAAC is quite difficult to secure. One (really only ONE) RA packet can destroy the IPv6 connection for all clients in a local network just in a few milliseconds. It also happens accidentally by "connection sharing" in Vista, Win7 (https://openwiki.uninett.no//_media/geantcampus:2011-gn3na3t4-ipv6-gregr.pdf) - The full protection against that behavior it's impossible today. RA-Guard or PACL can be bypassed using extension headers or fragmentation (http://www.mh-sec.de/downloads/mh-ipv6_vulnerabilities.pdf) - With SLAAC is difficult to implement security features like ARP/ND protection/inspection, IP source guard/Dynamic lock down, because all this techniques are based on a MAC-IP database created during a communication with a DHCP server. There are some attempts (ND protection, SAVI) but it does not provide the same level of security. - Just the same technique was introduced in IPv4 as Router Discovery (RFC 1256). Nobody uses it today. Do we really need go through same death way again? (Oh right, we are already going :-( ) Comparing to SLAAC, DHCPv6 have several advantages: - DHCPv6 is very similar to DHCP(v4) and many people are used to using it. - DHCPv6 can potentially do much more - for example handle an information for PXE, options for IP phones, prefix delegation. - DHCPv6 allows handle an information only for some hosts or group of hosts (differed lease time, search list, DNS atc.). With SLAAC it is impossible and all host on a subnet have to share the same set of the configuration information. - Frankly said, I have not found any significant benefit that SLAAC brings. Unfortunately there is another issue with DUIDs in DHCPv6. But it is a little bit differed tale. At the beginning the autoconfiguration was meant as easy to use and easy to configure but the result turned out into kind of nightmare. For those who do not know what I am talking about I prepared two images. The first one shows necessary communication before first regular packet can be send over IPv4 (http://hawk.cis.vutbr.cz/~tpoder/tmp/autoconf/IPv4.png) and just the same thing in IPv6 (http://hawk.cis.vutbr.cz/~tpoder/tmp/autoconf/IPv4.png). In IPv4 we have very simple answer if somebody asks for autoconfiguration = use DHCP. In IPv6 the description how things work have to be written into more than 10 pages [1]. I believe that is not what we really wanted. For those who are interested in that area there are several articles/presentations where we mentioned that topic. [1] IPv6 Autoconfiguration - Best Practice Document http://www.terena.org/activities/campus-bp/pdf/gn3-na3-t4-cbpd117.pdf [2] IPv6 - security threads http://www.fit.vutbr.cz/research/view_pub.php?id=9835 [3] Deploying IPv6 in University Campus Network - Practical Problems http://www.fit.vutbr.cz/research/view_pub.php?id=9836 Regards, Tomas Podermanski On 12/20/11 8:31 AM, Owen DeLong wrote: > Different operators will have different preferences in different environments. > > Ideally, the IETF should provide complete solutions based on DHCPv6 and > on RA and let the operators decide what they want to use in their environments. > > Owen > > On Dec 19, 2011, at 10:27 PM, Ravi Duggal wrote: > >> Hi, >> >> IPv6 devices (routers and hosts) can obtain configuration information >> about default routers, on-link prefixes and addresses from Router >> Advertisements as defined in Neighbor Discovery. I have been told >> that in some deployments, there is a strong desire not to use Router >> Advertisements at all and to perform all configuration via DHCPv6. >> There are thus similar IETF standards to get everything that you can >> get from RAs, by using DHCPv6 instead. >> >> As a result of this we see new proposals in IETF that try to do >> similar things by either extending RA mechanisms or by introducing new >> options in DHCPv6. >> >> We thus have draft-droms-dhc-dhcpv6-default-router-00 that extends >> DHCPv6 to do what RA does. And now, we have >> draft-bcd-6man-ntp-server-ra-opt-00.txt that extends RA to advertise >> the NTP information that is currently done via DHCPv6. >> >> My question is, that which then is the more preferred option for the >> operators? Do they prefer extending RA so that the new information >> loaded on top of the RA messages gets known in the single shot when >> routers do neighbor discovery. Or do they prefer all the extra >> information to be learnt via DHCPv6? What are the pros and cons in >> each approach and when would people favor one over the other? >> >> I can see some advantages with the loading information to RA since >> then one is not dependent on the DHCPv6 server. However, the latter >> provides its own benefits. >> >> Regards, >> Ravi D. > From dseagrav at humancapitaldev.com Wed Dec 21 13:52:58 2011 From: dseagrav at humancapitaldev.com (Daniel Seagraves) Date: Wed, 21 Dec 2011 13:52:58 -0600 Subject: Well Lookie Here, Barracuda Networks tries to get me to fall into their trap again... In-Reply-To: <2F1D4FA4-107A-49C4-B5E5-CD40B282B9B2@freethought-internet.co.uk> References: <20111221104148.4565907e@jpeach-desktop.anbg.mssm.edu> <1449422.1440.1324490075558.JavaMail.root@benjamin.baylink.com> <8C26A4FDAE599041A13EB499117D3C286B6354A8@ex-mb-1.corp.atlasnetworks.us> <2F1D4FA4-107A-49C4-B5E5-CD40B282B9B2@freethought-internet.co.uk> Message-ID: On Dec 21, 2011, at 1:09 PM, Edward Dore wrote: > On 21 Dec 2011, at 18:46, Nathan Eisenberg wrote: > >>> In fact, it's not. If you miss your renewal payment for, frex, Safari >>> books, >>> they actually slip your cycle date to when you renew -- since you don't >>> *get* >>> the service between the expire date and the renew date, I concur with >>> his >>> appraisal that you shouldn't be paying for it, either. >>> >>> If in fact, the service *kept working* for a short time when an >>> overlooked payment was missed, it would be a different story. >>> >>> But, effectively, he's a new client, and should probably be treated >>> that way. >>> Assuming the paid service is actually *the update service*. >>> >>> I also disagree with your proposition that this is off-topic for NANOG, >>> really. >> >> I've always strongly felt that this was a rather foul business practice, wherever I've seen it. The justification for it is the utterly misguided belief that, if allowed to, customers will pay for a month then cancel their subscription and 'coast' on the 'current' version of the signature for a year. This approach suffers from (at least) two fundamental flaws: >> >> 1) The entire customer base are treated as hostile. It is no surprise that they resent this. (Assumption: having resentful customers is bad) >> 2) Spam is, perhaps moreso than ever, a rapidly evolving threat. The effectiveness of signatures declines dramatically with time, which means that August's signatures have little value by December. [By the way, it seems to me that if they're willing to charge for valueless signatures, that represents either A) doubt as to the value of the current signatures, or B) disbelief in the decreasing value of out of date signatures.] >> >> While I realize that car insurance might not be the best analogy subject, imagine if you put your car on blocks, went off to college and allowed the insurance to lapse whilst you were there. When you return, the insurance company wants you to pay the last three years of insurance in order to reactivate your policy. That companies customers would react in the same way: they would find a new provider to do business with, rather than pay out for a valueless bit of smoke and mirrors. >> >> Nathan Eisenberg > > Are you turning your anti-spam appliance off whilst choosing not to pay for the maintenance? If not, then I'd argue that a better analogy would be that you don't pay for your car insurance but continue to drive your car around until you have an accident, at which point you try to take out a new policy so that you are covered. > > Whilst I can see the argument for the likes of signature updates, where you aren't receiving the service in the period that you haven't paid for (unless the signature update system is seriously broken), these kind of maintenance renewals for appliances normally also include software support and hardware repair/replacement. > > If the companies don't backdate the maintenance renewal, then you would end up with lots of companies only purchasing the maintenance on an ad-hoc basis and that will just make the renewals more expensive for those of us that actually pay attention to when our subscriptions to due to expire and how much they will cost to renew in order accurately predict cash flow. Besides, treating your customers like thieves and/or forcing disagreeable conditions on them is all the rage now! Everyone knows they can screw customers as hard as they like because everyone else is going to screw them just as hard, and if you aren't screwing them hard enough, well that's just wasted potential right there! Don't worry about them leaving for another provider - They all do it! I mean, look at the airlines: Company profits in the toilet, customer satisfaction so low they're trying to get Congress involved, crew pay at the lowest on record, and the salaries of the upper management is the highest in the history of the industry! Just think, if you screw your customers hard enough, YOU could be NEXT sitting on that huge pile of cash in the top of your ivory tower pissing down on the public! For example, I have a large pile of content that I have paid for but cannot access anymore because their various copy protection schemes are no longer supported or no longer run on modern machines. Next to that I have a smaller but increasingly growing stack of content I paid for but REFUSE to access due to provisions hidden in the EULA requiring me to display advertisements and/or install spyware on my computer. You can't read the EULA before purchase and you can't return the purchase for a refund if you refuse the EULA. (That's right, you can sell AD-SUPPORTED software that customers pay FULL RETAIL PRICE for! They whine and complain on the internet, but believe you me, when the next iteration comes out, they'll line up to buy it!) I could resort to illegal hacks that disable the DRM or remove the ads, but that is a federal offense and a security risk, and I don't feel like wasting my computer or career over a few hundred dollars. So they join the pile. The companies who do this actually consider this situation desirable - They got my money, and I'm not going to be downloading patches or using up server time or anything. Pure profit! It's win-win! Executive Summary: It doesn't matter what your customers want anymore. You just give them what you want to give them, and if they don't take it, you punish them until they give up and go away (and don't worry about that, they'll be back!) or accept your conditions. Thar's gold in them thar hills, you just gotta go beat it out of em! From david at davidswafford.com Wed Dec 21 14:22:55 2011 From: david at davidswafford.com (David Swafford) Date: Wed, 21 Dec 2011 15:22:55 -0500 Subject: Well Lookie Here, Barracuda Networks tries to get me to fall into their trap again... In-Reply-To: References: <20111221104148.4565907e@jpeach-desktop.anbg.mssm.edu> <1449422.1440.1324490075558.JavaMail.root@benjamin.baylink.com> <8C26A4FDAE599041A13EB499117D3C286B6354A8@ex-mb-1.corp.atlasnetworks.us> <2F1D4FA4-107A-49C4-B5E5-CD40B282B9B2@freethought-internet.co.uk> Message-ID: In my position within the enterprise vertical, backdating to the expiration (not the payment date) seems to be the norm. Cisco does this on SmartNet, as does SolarWinds and a number of other vendors I've worked with. We don't typically slip on the dates intentionally, but our procurement and legal groups have a habit of fighting over wording on the contracts. David. On Wed, Dec 21, 2011 at 2:52 PM, Daniel Seagraves wrote: > > On Dec 21, 2011, at 1:09 PM, Edward Dore wrote: > >> On 21 Dec 2011, at 18:46, Nathan Eisenberg wrote: >> >>>> In fact, it's not. ?If you miss your renewal payment for, frex, Safari >>>> books, >>>> they actually slip your cycle date to when you renew -- since you don't >>>> *get* >>>> the service between the expire date and the renew date, I concur with >>>> his >>>> appraisal that you shouldn't be paying for it, either. >>>> >>>> If in fact, the service *kept working* for a short time when an >>>> overlooked payment was missed, it would be a different story. >>>> >>>> But, effectively, he's a new client, and should probably be treated >>>> that way. >>>> Assuming the paid service is actually *the update service*. >>>> >>>> I also disagree with your proposition that this is off-topic for NANOG, >>>> really. >>> >>> I've always strongly felt that this was a rather foul business practice, wherever I've seen it. ?The justification for it is the utterly misguided belief that, if allowed to, customers will pay for a month then cancel their subscription and 'coast' on the 'current' version of the signature for a year. ?This approach suffers from (at least) two fundamental flaws: >>> >>> 1) The entire customer base are treated as hostile. ?It is no surprise that they resent this. ?(Assumption: having resentful customers is bad) >>> 2) Spam is, perhaps moreso than ever, a rapidly evolving threat. ?The effectiveness of signatures declines dramatically with time, which means that August's signatures have little value by December. ?[By the way, it seems to me that if they're willing to charge for valueless signatures, that represents either A) doubt as to the value of the current signatures, or B) disbelief in the decreasing value of out of date signatures.] >>> >>> While I realize that car insurance might not be the best analogy subject, imagine if you put your car on blocks, went off to college and allowed the insurance to lapse whilst you were there. ?When you return, the insurance company wants you to pay the last three years of insurance in order to reactivate your policy. ?That companies customers would react in the same way: they would find a new provider to do business with, rather than pay out for a valueless bit of smoke and mirrors. >>> >>> Nathan Eisenberg >> >> Are you turning your anti-spam appliance off whilst choosing not to pay for the maintenance? If not, then I'd argue that a better analogy would be that you don't pay for your car insurance but continue to drive your car around until you have an accident, at which point you try to take out a new policy so that you are covered. >> >> Whilst I can see the argument for the likes of signature updates, where you aren't receiving the service in the period that you haven't paid for (unless the signature update system is seriously broken), these kind of maintenance renewals for appliances normally also include software support and hardware repair/replacement. >> >> If the companies don't backdate the maintenance renewal, then you would end up with lots of companies only purchasing the maintenance on an ad-hoc basis and that will just make the renewals more expensive for those of us that actually pay attention to when our subscriptions to due to expire and how much they will cost to renew in order accurately predict cash flow. > > > > Besides, treating your customers like thieves and/or forcing disagreeable conditions on them is all the rage now! Everyone knows they can screw customers as hard as they like because everyone else is going to screw them just as hard, and if you aren't screwing them hard enough, well that's just wasted potential right there! Don't worry about them leaving for another provider - They all do it! I mean, look at the airlines: Company profits in the toilet, customer satisfaction so low they're trying to get Congress involved, crew pay at the lowest on record, and the salaries of the upper management is the highest in the history of the industry! Just think, if you screw your customers hard enough, YOU could be NEXT sitting on that huge pile of cash in the top of your ivory tower pissing down on the public! > > For example, I have a large pile of content that I have paid for but cannot access anymore because their various copy protection schemes are no longer supported or no longer run on modern machines. Next to that I have a smaller but increasingly growing stack of content I paid for but REFUSE to access due to provisions hidden in the EULA requiring me to display advertisements and/or install spyware on my computer. You can't read the EULA before purchase and you can't return the purchase for a refund if you refuse the EULA. (That's right, you can sell AD-SUPPORTED software that customers pay FULL RETAIL PRICE for! They whine and complain on the internet, but believe you me, when the next iteration comes out, they'll line up to buy it!) I could resort to illegal hacks that disable the DRM or remove the ads, but that is a federal offense and a security risk, and I don't feel like wasting my computer or career over a few hundred dollars. So they join the pile. The companies who do this actually consider this situation desirable - They got my money, and I'm not going to be downloading patches or using up server time or anything. Pure profit! It's win-win! > > Executive Summary: It doesn't matter what your customers want anymore. You just give them what you want to give them, and if they don't take it, you punish them until they give up and go away (and don't worry about that, they'll be back!) or accept your conditions. Thar's gold in them thar hills, you just gotta go beat it out of em! > > > From rps at maine.edu Wed Dec 21 14:40:19 2011 From: rps at maine.edu (Ray Soucy) Date: Wed, 21 Dec 2011 15:40:19 -0500 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EF23092.9090103@cis.vutbr.cz> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> Message-ID: I'm afraid you're about 10 years too late for this opinion to make much difference. ;-) We have been running IPv6 in production for several years (2008) as well (answering this email over IPv6 now, actually) yet I have completely different conclusions about the role of RA and DHCPv6. Weird. On Wed, Dec 21, 2011 at 2:16 PM, Tomas Podermanski wrote: > Hi, > > from my perspective the short answer for this never-ending story is: > > - SLAAC/RA is totally useless, does not bring any benefit at all > ?and should be removed from IPv6 specs > - DHCPv6 should be extended by route options as proposed in > ?http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-03 > - DHCPv6 should be extended by layer 2 address to identify > ?client's L2 address (something that we can see in RFC 6221) > - DHCPv6 should be the common way to autoconfigure an address > ?in a IPv6 environment > > The long answer is: > > I completely disagree with opinion that both DHCPv6 and RA (SLAAC) > should be supported. It is easy to say that both have place but it has > some consequences. I and my colleagues have been working on deploying > IPv6 for a few years and from the operation perspective we conclude into > a quite clear opinion in that area. Both SLAAC and DHCPv6 uses a > opposite principles although the goal is just one. DHCPv6 is based on a > central DHCPv6 server that assigns addresses. SLAAC does opposite - > leaves the decision about the address on a client side. However we have > to run both of them in a network to provide all necessary pieces of > information to the clients (default route and DNS). This brings many > implementation and operational complications. > > - Clients have to support both SLAAC and DHCPv6 to be able to work in > ?both environments > - There must be solved a situation what to do when SLAAC and DHCPv6 > ?provides some conflict information (quite long thread with various > opinions > ?can be found at > http://www.ietf.org/mail-archive/web/ipv6/current/msg14949.html) > - The first hop security have to be solved twice - for SLAAC and for > DHCPv6. Both > ?of then uses a differed communication way. SLAAC is part of ICMPv6, > but DHCPv6 > ?uses "own" UDP communication what does not make things easier. > - SLAAC is usually processed in a kernel, DHCPv6 is usually run as a > ?process in the user space. Diagnostic and troubleshooting is more > complicated. > - DHCPv6 is currently tied with SLAAC (M,O flags), what means that > ?a DHCPv6 client have to wait until some RA message arrives to start DHCPv6 > ?discovery. That unnecessary prolongs whole autoconfiguration process. > > Some other issues are also described in [1]. > > I personally prefer to bury SLAAC once forever for several reasons: > - In fact SLAAC does nothing more what DHCPv6 can do. > - SLAAC is quite difficult to secure. One (really only ONE) ?RA packet > can destroy > ?the IPv6 connection for all clients in a local network just in a few > milliseconds. > ?It also happens accidentally by "connection sharing" in Vista, Win7 > > (https://openwiki.uninett.no//_media/geantcampus:2011-gn3na3t4-ipv6-gregr.pdf) > - The full protection against that behavior it's impossible today. > RA-Guard or > ?PACL can be bypassed using extension headers or fragmentation > ?(http://www.mh-sec.de/downloads/mh-ipv6_vulnerabilities.pdf) > - With SLAAC is difficult to implement security features like ARP/ND > ?protection/inspection, IP source guard/Dynamic lock down, because > ?all this techniques are based on a MAC-IP database created during > ?a communication with a DHCP server. There are some attempts (ND > protection, SAVI) > ?but it does not provide the same level of security. > - Just the same technique was introduced in IPv4 as Router Discovery > (RFC 1256). > ?Nobody uses it today. Do we really need go through same death way again? > ?(Oh right, we are already going :-( ) > > Comparing to SLAAC, DHCPv6 have several advantages: > - DHCPv6 is very similar to DHCP(v4) and many people are used to using it. > - DHCPv6 can potentially do much more - for example handle an information > ?for PXE, options for IP phones, prefix delegation. > - DHCPv6 allows handle an information only for some hosts or group of > ?hosts (differed lease time, search list, DNS atc.). With SLAAC it is > ?impossible and all host on a subnet have to share the same set of > ?the configuration information. > - Frankly said, I have not found any significant benefit that SLAAC brings. > > Unfortunately there is another issue with DUIDs in DHCPv6. But it is a > little bit differed tale. > > At the beginning the autoconfiguration was meant as easy to use and easy > to configure but the result turned out into kind of nightmare. For those > who do not know what I am talking about I prepared two images. The first > one shows necessary communication before first regular packet can be > send over IPv4 (http://hawk.cis.vutbr.cz/~tpoder/tmp/autoconf/IPv4.png) > and just the same thing in IPv6 > (http://hawk.cis.vutbr.cz/~tpoder/tmp/autoconf/IPv4.png). In IPv4 we > have very simple answer if somebody asks for autoconfiguration ?= use > DHCP. In IPv6 the description how things work have to be written into > more than 10 pages [1]. I believe that is not what we really wanted. > > For those who are interested in that area there are several > articles/presentations where we mentioned that topic. > > [1] IPv6 Autoconfiguration - Best Practice Document > http://www.terena.org/activities/campus-bp/pdf/gn3-na3-t4-cbpd117.pdf > > [2] IPv6 - security threads > http://www.fit.vutbr.cz/research/view_pub.php?id=9835 > > [3] Deploying IPv6 in University Campus Network - Practical Problems > http://www.fit.vutbr.cz/research/view_pub.php?id=9836 > > > Regards, > ? ?Tomas Podermanski > > > > On 12/20/11 8:31 AM, Owen DeLong wrote: >> Different operators will have different preferences in different environments. >> >> Ideally, the IETF should provide complete solutions based on DHCPv6 and >> on RA and let the operators decide what they want to use in their environments. >> >> Owen >> >> On Dec 19, 2011, at 10:27 PM, Ravi Duggal wrote: >> >>> Hi, >>> >>> IPv6 devices (routers and hosts) can obtain configuration information >>> about default routers, on-link prefixes and addresses from Router >>> Advertisements as defined in ? Neighbor Discovery. ?I have been told >>> that in some deployments, there is a strong desire not to use Router >>> Advertisements at all and to perform all configuration via DHCPv6. >>> There are thus similar IETF standards to get everything that you can >>> get from RAs, by using DHCPv6 instead. >>> >>> As a result of this we see new proposals in IETF that try to do >>> similar things by either extending RA mechanisms or by introducing new >>> options in DHCPv6. >>> >>> We thus have draft-droms-dhc-dhcpv6-default-router-00 that extends >>> DHCPv6 to do what RA does. And now, we have >>> draft-bcd-6man-ntp-server-ra-opt-00.txt that extends RA to advertise >>> the NTP information that is currently done via DHCPv6. >>> >>> My question is, that which then is the more preferred option for the >>> operators? Do they prefer extending RA so that the new information >>> loaded on top of the RA messages gets known in the single shot when >>> routers do neighbor discovery. Or do they prefer all the extra >>> information to be learnt via DHCPv6? What are the pros and cons in >>> each approach and when would people favor one over the other? >>> >>> I can see some advantages with the loading information to RA since >>> then one is not dependent on the DHCPv6 server. However, the latter >>> provides its own benefits. >>> >>> Regards, >>> Ravi D. >> > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From morrowc.lists at gmail.com Wed Dec 21 15:15:34 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 21 Dec 2011 16:15:34 -0500 Subject: Any tools to help network security In-Reply-To: <4EF22F8C.8090008@tiggee.com> References: <20111221.200316.41697039.sthaug@nethelp.no> <4EF22F8C.8090008@tiggee.com> Message-ID: On Wed, Dec 21, 2011 at 2:12 PM, David Miller wrote: > On 12/21/2011 2:03 PM, sthaug at nethelp.no wrote: >>> >>> We discover there are so many (source) ip not belonging to our network >>> to go to outside. >>> >>> We can block it but don't know how to locate the source. >>> >>> Any tools can be easily found out. >> >> http://lmgtfy.com/?q=unicast+rpf >> >> Steinar Haug, Nethelp consulting, sthaug at nethelp.no >> > > Also - http://lmgtfy.com/?q=tracing+spoofed+source+on+network > > Which get you to some strategies for finding the source(s) on your network > (which I believe was the OP's question). ?Including: > ?http://www.csm.ornl.gov/~dunigan/oci/bktrk.html > ?http://www.cymru.com/Documents/tracking-spoofed.html also, of course netflow... which I think Deric has asked about in the past? From seth.mos at dds.nl Wed Dec 21 15:31:35 2011 From: seth.mos at dds.nl (Seth Mos) Date: Wed, 21 Dec 2011 22:31:35 +0100 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EF23092.9090103@cis.vutbr.cz> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> Message-ID: Hi, Op 21 dec 2011, om 20:16 heeft Tomas Podermanski het volgende geschreven: > Hi, > > from my perspective the short answer for this never-ending story is: To be fair, SLAAC was designed as a light weight method to configure addressing on the hosts. Hosts. We don't have hosts on the internet anymore, we stopped using dialup ages ago (or so it seems). We now address routers, and those have very different requirements, like needing routing and firewalling and some way to get subnets routed to them, that is where dhcp6 prefix delegation comes in. SLAAC serves no purpose for routers bar making the configure process awkward and error prone. That wasn't what we needed. I recently had a conversation with a promoter of the SLAAC method. "A 64KB ram device can configure a address and work as a autonomous sensor". I raised the concern that the device might need to connect to a host, since you couldn't find it in a /64 of address space. He honestly suggested that you could just configure to have it connect to a static address. Really, and nobody renumbers networks, at all? That's false. And that is still a host, not a router. And since then we've come a lot farther then 64KB sensor devices. Considering we can buy (wireless) routers at the local mall that have more ram and processing power then we used to have in a computer in the 90s now in a tablet, phone or other embedded device. Having built DHCP6 support in a open source firewall I agree that the (+IPv6) configuration of routers has become overly complicated and error prone, even more so due to possible renumbering. RA will have one thought, and the DHCP6 client another, not even going into multiple (possible differing) feeds of both IPv4 and IPv6 DNS servers. It was intended for hosts, not really minding that, but please, can we stop using it for routers? Regards, Seth From bill at herrin.us Wed Dec 21 15:37:58 2011 From: bill at herrin.us (William Herrin) Date: Wed, 21 Dec 2011 11:37:58 -1000 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> Message-ID: On Wed, Dec 21, 2011 at 10:40 AM, Ray Soucy wrote: > On Wed, Dec 21, 2011 at 2:16 PM, Tomas Podermanski wrote: >> from my perspective the short answer for this never-ending story is: >> >> - SLAAC/RA is totally useless, does not bring any benefit at all >> and should be removed from IPv6 specs > I'm afraid you're about 10 years too late for this opinion to make > much difference. ;-) I won't go so far as to say SLAAC should be removed from the IPv6 spec but it's never too late to deprecate a protocol that doesn't pan out. I'm with Owen: On Tue, Dec 20, 2011 at 4:58 AM, Owen DeLong wrote: > Currently, most significant environments have to cobble together a complete > solution from remnants of SLAAC and DHCP. This is far from ideal. > Far better for organizations to look at 2 complete solutions and pick the > solution that works best for them in their environment. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From rosmith325 at gmail.com Wed Dec 21 16:21:27 2011 From: rosmith325 at gmail.com (Rob Smith) Date: Wed, 21 Dec 2011 17:21:27 -0500 Subject: Level3 AWS network issues? Message-ID: Is anyone else seeing issues connecting to the different Amazon AWS products from the east coast via Level3? I'm very high latency once I hit Amazon's network on Level3 for the last day and a half: me at computer:~/$ tracepath s3.amazonaws.com 1: computer.local 0.136ms pmtu 1500 1: XXXXXXXX 6.495ms 1: XXXXXXXX 2.091ms 2: 10.68.96.1 8.933ms 3: gig-2-18-nycmnyr-rtr02.nyc.rr.com 12.440ms 4: tenge-0-4-0-6-nyquny91-rtr001.nyc.rr.com 12.296ms 5: bun6-nyquny91-rtr002.nyc.rr.com 13.894ms 6: ae-3-0.cr0.nyc20.tbone.rr.com 16.869ms 7: 107.14.17.169 10.200ms 8: xe-9-3-0.edge2.Newark1.Level3.net 12.215ms 9: ae-32-52.ebr2.Newark1.Level3.net 12.380ms 10: ae-4-4.ebr2.Washington1.Level3.net 20.277ms 11: ae-92-92.csw4.Washington1.Level3.net 15.482ms 12: ae-2-70.edge3.Washington1.Level3.net 15.972ms asymm 13 *13: AMAZON.COM.edge3.Washington1.Level3.net 277.609ms asymm 16 * *14: 72.21.220.129 311.718ms asymm 17 * *15: 72.21.222.139 325.718ms * *16: 72.21.218.201 279.354ms asymm 17 * *17: 72.21.218.207 276.793ms asymm 15 * I've heard from a few other folks that they're experiencing this as well, but only if they're traversing the Level3 network. I've tried contacting Amazon and tried going through my own provider but haven't been able to get anywhere. Can anyone forward this to the appropriate Amazon/Level3 contacts or provide contact information for someone that I can relay this information to? From vinny at abellohome.net Wed Dec 21 16:21:38 2011 From: vinny at abellohome.net (Vinny Abello) Date: Wed, 21 Dec 2011 17:21:38 -0500 Subject: BGP noob needs monitoring advice In-Reply-To: <4EF2180E.4010103@toonk.nl> References: <5.1.0.14.2.20111220210142.00c459c0@efes.iucc.ac.il> <4EF0DF04.50908@spectraaccess.com> <4EF0E571.20305@toonk.nl> <4EF1DC70.9030803@abellohome.net> <4EF2180E.4010103@toonk.nl> Message-ID: <4EF25BF2.9040607@abellohome.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/21/2011 12:31 PM, Andree Toonk wrote: > Hi Vinny, > > .-- My secret spy satellite informs me that at 11-12-21 5:17 AM Vinny Abello wrote: > >> Unless I'm misunderstanding something, I'm concerned regarding the IPv4 bogon list on http://bgpmon.net/showbogons.php?inet=4 . It clearly includes several /8's that should not be there. The data seems to be stale as if some job is no longer pulling the updated data. It states it's being pulled from http://www.cymru.com/Documents/bogon-bn-nonagg.txt , but that clearly does not contain 100/8, 5/8, 181/8, 49/8 and a few others... and hasn't for quite some time. > > The http://bgpmon.net/showbogons.php?inet=4 page show a list of bogons that were announced at a certain point in time, so the page show historical announcements as well (check the date). > > For example the last 100/8 bogons were detected on 2010-10-29, at that time it was still considered a bogon. > > The list is not stale, there's just very few IPv4 bogons left :) > We do still see RFC1918 announcements: > http://www.bgpmon.net/showbogons.php?inet=4&global=yes&private=yes > > And of course IPv6 bogons, Last month for example: 18c::/16 > http://www.bgpmon.net/showbogons.php?global=yes&private=yes&inet=6 Ahh, that would be the part where I'm misunderstanding something, the date! LOL... Makes sense now. I thought this was a recent snapshot all from 2011. I see of course that I was wrong. Thanks for clearing that up for me. My excuse is lack of coffee when I wrote that. ;) - -Vinny -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) iEYEARECAAYFAk7yW/EACgkQUyX7ywEAl3opowCgsFRAy3osAmML5T6LncNLNzWh UBsAniwvOTKrOT7uwIYWBDie29MDq47r =H3PD -----END PGP SIGNATURE----- From michael at rancid.berkeley.edu Wed Dec 21 17:04:58 2011 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Wed, 21 Dec 2011 15:04:58 -0800 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> Message-ID: <4EF2661A.4050408@rancid.berkeley.edu> On 12/21/11 12:40, Ray Soucy wrote: > I'm afraid you're about 10 years too late for this opinion to make > much difference. ;-) > > We have been running IPv6 in production for several years (2008) as > well (answering this email over IPv6 now, actually) yet I have > completely different conclusions about the role of RA and DHCPv6. > Weird. And that's a very good reason not to deprecate SLAAC. Tomas may prefer DHCPv6, and he may provide reasons others may prefer DHCPv6. But he hasn't provided justification for deprecating SLAAC. Many of us have been working with IPv6 for years and have found SLAAC to be quite useful. The biggest benefit it provides, which Tomas did not acknowledge, is the ability to autoconfigure hosts without running a central server. That said, I have also found DHCPv6 to be quite useful. I also agree with Owen: Provide two complete solutions, and let operators choose based on their needs. That implies fixing DHCPv6 so I don't have to go in and disable the autonomous flag on my routers and run RAs just to get a default route. But it also implies not deprecating either SLAAC or DHCPv6. michael From owen at delong.com Wed Dec 21 17:18:05 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 21 Dec 2011 15:18:05 -0800 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EF23092.9090103@cis.vutbr.cz> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> Message-ID: <9B747991-09CC-47E2-A245-846C3ABD9005@delong.com> On Dec 21, 2011, at 11:16 AM, Tomas Podermanski wrote: > Hi, > > from my perspective the short answer for this never-ending story is: > > - SLAAC/RA is totally useless, does not bring any benefit at all > and should be removed from IPv6 specs Except that there are many environments where that's not true. > - DHCPv6 should be extended by route options as proposed in > http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-03 I haven't read the particular draft, but, I do think dhcpv6 route options should be added. > - DHCPv6 should be extended by layer 2 address to identify > client's L2 address (something that we can see in RFC 6221) I'm neutral on this one. Once you get used to dealing with it, using DUIDs isn't so bad. It does (at least potentially) allow you to identify the same client across a NIC replacement, which can be useful in some environments. > - DHCPv6 should be the common way to autoconfigure an address > in a IPv6 environment DHCPv6 should be a common option for operators that want to use it, but there is no reason to take SLAAC away from operators that are happy with it. > > The long answer is: > > I completely disagree with opinion that both DHCPv6 and RA (SLAAC) > should be supported. It is easy to say that both have place but it has > some consequences. I and my colleagues have been working on deploying > IPv6 for a few years and from the operation perspective we conclude into > a quite clear opinion in that area. Both SLAAC and DHCPv6 uses a > opposite principles although the goal is just one. DHCPv6 is based on a > central DHCPv6 server that assigns addresses. SLAAC does opposite - > leaves the decision about the address on a client side. However we have > to run both of them in a network to provide all necessary pieces of > information to the clients (default route and DNS). This brings many > implementation and operational complications. > I agree that the requirement to run both is broken. I don't agree that this means we should remove the option of using SLAAC in environments where it makes sense. > - Clients have to support both SLAAC and DHCPv6 to be able to work in > both environments So? > - There must be solved a situation what to do when SLAAC and DHCPv6 > provides some conflict information (quite long thread with various > opinions > can be found at > http://www.ietf.org/mail-archive/web/ipv6/current/msg14949.html) SLAAC and DHCPv6 can't really provide conflicting information unless the router is misconfigured. Even if a host gets different answers for the same prefixes from SLAAC and DHCP, it should be able to use both host addresses. There's the question of source address selection, but, the answer to that question at the IETF level should only be a matter of what the default answer is. There are configuration options for setting host source address selection priorities. > - The first hop security have to be solved twice - for SLAAC and for > DHCPv6. Both > of then uses a differed communication way. SLAAC is part of ICMPv6, > but DHCPv6 > uses "own" UDP communication what does not make things easier. Solved for SLAAC -- SEND. Allegedly, there is Secure DHCPv6 for DHCP, but, I haven't seen any actual implementations yet. > - SLAAC is usually processed in a kernel, DHCPv6 is usually run as a > process in the user space. Diagnostic and troubleshooting is more > complicated. That seems like an argument for SLAAC, if anything. > - DHCPv6 is currently tied with SLAAC (M,O flags), what means that > a DHCPv6 client have to wait until some RA message arrives to start DHCPv6 > discovery. That unnecessary prolongs whole autoconfiguration process. While I agree with you that the standard is broken in this regard, there is at least one OS vendor that already violates that rule anyway. > > Some other issues are also described in [1]. > > I personally prefer to bury SLAAC once forever for several reasons: > - In fact SLAAC does nothing more what DHCPv6 can do. Yes, but, it does it in a much simpler way with a lot less overhead which can be a benefit in some environments. > - SLAAC is quite difficult to secure. One (really only ONE) RA packet > can destroy > the IPv6 connection for all clients in a local network just in a few > milliseconds. This is what RA-Guard is for and it's quite simple to deploy. SEND makes it even better, but is a bit more complicated. > It also happens accidentally by "connection sharing" in Vista, Win7 > This is an argument for burying Windows, not an argument for burying SLAAC. It's not like ICS in IPv4 didn't create rogue DHCP servers. If you were to bury SLAAC, Micr0$0ft would simply switch to breaking DHCPv6 instead of breaking SLAAC. > (https://openwiki.uninett.no//_media/geantcampus:2011-gn3na3t4-ipv6-gregr.pdf) > - The full protection against that behavior it's impossible today. > RA-Guard or > PACL can be bypassed using extension headers or fragmentation > (http://www.mh-sec.de/downloads/mh-ipv6_vulnerabilities.pdf) Yes and no. RA Guard implementations are getting better at addressing those issues. > - With SLAAC is difficult to implement security features like ARP/ND > protection/inspection, IP source guard/Dynamic lock down, because > all this techniques are based on a MAC-IP database created during > a communication with a DHCP server. There are some attempts (ND > protection, SAVI) > but it does not provide the same level of security. Most sites don't need that level of security. I agree there should be a way to disable SLAAC reliably at a site as a policy matter, but, frankly the techniques you're talking about come in one of two flavors: 1. They dynamically enable the switch to accept packets from a client, in which case, SLAAC based clients would be blocked until they registered with DHCP anyway. or 2. They don't effectively block an attacker who cobbles his own address even without SLAAC. In the former case, you get the security you want and force DHCP anyway, so I don't see a problem. In the latter case, you only had the illusion of security to begin with, so, SLAAC just makes it easy to disillusion you. > - Just the same technique was introduced in IPv4 as Router Discovery > (RFC 1256). > Nobody uses it today. Do we really need go through same death way again? > (Oh right, we are already going :-( ) Not a fair comparison. There were a number of additional issues with 1256 that prevented it from gaining acceptance in IPv4. > > Comparing to SLAAC, DHCPv6 have several advantages: > - DHCPv6 is very similar to DHCP(v4) and many people are used to using it. That just makes it familiar, not necessarily better for all environments. > - DHCPv6 can potentially do much more - for example handle an information > for PXE, options for IP phones, prefix delegation. True, but, that comes at a cost of complexity and overhead which may not be desirable in all environments. > - DHCPv6 allows handle an information only for some hosts or group of > hosts (differed lease time, search list, DNS atc.). With SLAAC it is > impossible and all host on a subnet have to share the same set of > the configuration information. Which is not an issue in 99+% of environments. > - Frankly said, I have not found any significant benefit that SLAAC brings. Perhaps you have not, but, others have. I have seen environments where SLAAC is much more useful than DHCPv6. I've seen environments where DHCPv6 is needed. > > Unfortunately there is another issue with DUIDs in DHCPv6. But it is a > little bit differed tale. > > At the beginning the autoconfiguration was meant as easy to use and easy > to configure but the result turned out into kind of nightmare. For those > who do not know what I am talking about I prepared two images. The first > one shows necessary communication before first regular packet can be > send over IPv4 (http://hawk.cis.vutbr.cz/~tpoder/tmp/autoconf/IPv4.png) > and just the same thing in IPv6 > (http://hawk.cis.vutbr.cz/~tpoder/tmp/autoconf/IPv4.png). In IPv4 we > have very simple answer if somebody asks for autoconfiguration = use > DHCP. In IPv6 the description how things work have to be written into > more than 10 pages [1]. I believe that is not what we really wanted. > That's no really a fair characterization. Yes, DHCPv6 is more complex than DHCPv4, but, not significantly so. In reality it can be summed up relatively quickly: 1. Choose link local address (fe80::EUI64) 2. Send RS packet to all-routers multicast address 3. Receive one or more RA packets. a. if Packet contains prefix information: i. Set timers, apply addresses to interfaces (first regular packet can be sent at this point) b. If packet has O bit set: i. Send DHCPv6 request to DHCP server ii. Get response iii. Configure accordingly. (If a was false (a and b are not mutually exclusive), then you can now send your first regular packet). Yes, there are a few corner cases not completely addressed above, but, unless you're building the software to implement the standards, they are mostly irrelevant. Even if you add them in (interactions between the M, A, and O bits), you can still describe it in about a page, not ten. Owen From kloch at kl.net Wed Dec 21 19:38:08 2011 From: kloch at kl.net (Kevin Loch) Date: Wed, 21 Dec 2011 20:38:08 -0500 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: Message-ID: <4EF28A00.2080904@kl.net> Ravi Duggal wrote: > We thus have draft-droms-dhc-dhcpv6-default-router-00 that extends > DHCPv6 to do what RA does. And now, we have > draft-bcd-6man-ntp-server-ra-opt-00.txt that extends RA to advertise > the NTP information that is currently done via DHCPv6. > > My question is, that which then is the more preferred option for the > operators? In many environments RA is a catastrophic disaster. Some operators need to be able to do everything with RA turned off on routers, disabled on hosts and filtered on switches. - Kevin From Valdis.Kletnieks at vt.edu Wed Dec 21 19:48:00 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 21 Dec 2011 20:48:00 -0500 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: Your message of "Wed, 21 Dec 2011 15:18:05 PST." <9B747991-09CC-47E2-A245-846C3ABD9005@delong.com> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <9B747991-09CC-47E2-A245-846C3ABD9005@delong.com> Message-ID: <135180.1324518480@turing-police.cc.vt.edu> On Wed, 21 Dec 2011 15:18:05 PST, Owen DeLong said: > Perhaps you have not, but, others have. I have seen environments where > SLAAC is much more useful than DHCPv6. I've seen environments where > DHCPv6 is needed. OK, I'll name names. If you have end users still running WinXP, getting them at least somewhat working under SLAAC/DHCPv4 is a lot less headache than trying to DHCPv6 them. Anybody managed to stamp out WinXP in their end user population yet? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bill at herrin.us Wed Dec 21 22:28:21 2011 From: bill at herrin.us (William Herrin) Date: Wed, 21 Dec 2011 23:28:21 -0500 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: Message-ID: On Tue, Dec 20, 2011 at 1:27 AM, Ravi Duggal wrote: > We thus have draft-droms-dhc-dhcpv6-default-router-00 that extends > DHCPv6 to do what RA does. And now, we have > draft-bcd-6man-ntp-server-ra-opt-00.txt that extends RA to advertise > the NTP information that is currently done via DHCPv6. > > My question is, that which then is the more preferred option for the > operators? "Yes." We want both. We'll try both. And in a couple years when the percentage Internet use of IPv6 is out of the single digits, we'll let you know what worked in which situations. We probably don't need one configuration protocol to rule them all. IPv4 has PAP/CHAP over PPP and DHCP over Ethernet plus a number of more minor ones like bootp (DHCP's semi-compatible predecessor) and rarp. We really don't suffer for the choice. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From rps at maine.edu Wed Dec 21 23:01:37 2011 From: rps at maine.edu (Ray Soucy) Date: Thu, 22 Dec 2011 00:01:37 -0500 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <9B747991-09CC-47E2-A245-846C3ABD9005@delong.com> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <9B747991-09CC-47E2-A245-846C3ABD9005@delong.com> Message-ID: Look at that, for once I agree with Owen on all points made. ;-) On Wed, Dec 21, 2011 at 6:18 PM, Owen DeLong wrote: > > On Dec 21, 2011, at 11:16 AM, Tomas Podermanski wrote: > >> Hi, >> >> from my perspective the short answer for this never-ending story is: >> >> - SLAAC/RA is totally useless, does not bring any benefit at all >> ?and should be removed from IPv6 specs > > Except that there are many environments where that's not true. > >> - DHCPv6 should be extended by route options as proposed in >> ?http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-03 > > I haven't read the particular draft, but, I do think dhcpv6 route options > should be added. > >> - DHCPv6 should be extended by layer 2 address to identify >> ?client's L2 address (something that we can see in RFC 6221) > > I'm neutral on this one. Once you get used to dealing with it, using DUIDs > isn't so bad. It does (at least potentially) allow you to identify the same client > across a NIC replacement, which can be useful in some environments. > >> - DHCPv6 should be the common way to autoconfigure an address >> ?in a IPv6 environment > > DHCPv6 should be a common option for operators that want to use it, but > there is no reason to take SLAAC away from operators that are happy with > it. > >> >> The long answer is: >> >> I completely disagree with opinion that both DHCPv6 and RA (SLAAC) >> should be supported. It is easy to say that both have place but it has >> some consequences. I and my colleagues have been working on deploying >> IPv6 for a few years and from the operation perspective we conclude into >> a quite clear opinion in that area. Both SLAAC and DHCPv6 uses a >> opposite principles although the goal is just one. DHCPv6 is based on a >> central DHCPv6 server that assigns addresses. SLAAC does opposite - >> leaves the decision about the address on a client side. However we have >> to run both of them in a network to provide all necessary pieces of >> information to the clients (default route and DNS). This brings many >> implementation and operational complications. >> > > I agree that the requirement to run both is broken. I don't agree that this > means we should remove the option of using SLAAC in environments > where it makes sense. > >> - Clients have to support both SLAAC and DHCPv6 to be able to work in >> ?both environments > > So? > >> - There must be solved a situation what to do when SLAAC and DHCPv6 >> ?provides some conflict information (quite long thread with various >> opinions >> ?can be found at >> http://www.ietf.org/mail-archive/web/ipv6/current/msg14949.html) > > SLAAC and DHCPv6 can't really provide conflicting information unless > the router is misconfigured. Even if a host gets different answers for the > same prefixes from SLAAC and DHCP, it should be able to use both > host addresses. There's the question of source address selection, but, > the answer to that question at the IETF level should only be a matter > of what the default answer is. There are configuration options for setting > host source address selection priorities. > >> - The first hop security have to be solved twice - for SLAAC and for >> DHCPv6. Both >> ?of then uses a differed communication way. SLAAC is part of ICMPv6, >> but DHCPv6 >> ?uses "own" UDP communication what does not make things easier. > > Solved for SLAAC -- SEND. > Allegedly, there is Secure DHCPv6 for DHCP, but, I haven't seen any > actual implementations yet. > >> - SLAAC is usually processed in a kernel, DHCPv6 is usually run as a >> ?process in the user space. Diagnostic and troubleshooting is more >> complicated. > > That seems like an argument for SLAAC, if anything. > >> - DHCPv6 is currently tied with SLAAC (M,O flags), what means that >> ?a DHCPv6 client have to wait until some RA message arrives to start DHCPv6 >> ?discovery. That unnecessary prolongs whole autoconfiguration process. > > While I agree with you that the standard is broken in this regard, there is at > least one OS vendor that already violates that rule anyway. >> >> Some other issues are also described in [1]. >> >> I personally prefer to bury SLAAC once forever for several reasons: >> - In fact SLAAC does nothing more what DHCPv6 can do. > > Yes, but, it does it in a much simpler way with a lot less overhead which > can be a benefit in some environments. > >> - SLAAC is quite difficult to secure. One (really only ONE) ?RA packet >> can destroy >> ?the IPv6 connection for all clients in a local network just in a few >> milliseconds. > > This is what RA-Guard is for and it's quite simple to deploy. SEND makes > it even better, but is a bit more complicated. > >> ?It also happens accidentally by "connection sharing" in Vista, Win7 >> > > This is an argument for burying Windows, not an argument for burying > SLAAC. It's not like ICS in IPv4 didn't create rogue DHCP servers. If you > were to bury SLAAC, Micr0$0ft would simply switch to breaking DHCPv6 > instead of breaking SLAAC. > >> (https://openwiki.uninett.no//_media/geantcampus:2011-gn3na3t4-ipv6-gregr.pdf) >> - The full protection against that behavior it's impossible today. >> RA-Guard or >> ?PACL can be bypassed using extension headers or fragmentation >> ?(http://www.mh-sec.de/downloads/mh-ipv6_vulnerabilities.pdf) > > Yes and no. RA Guard implementations are getting better at addressing > those issues. > >> - With SLAAC is difficult to implement security features like ARP/ND >> ?protection/inspection, IP source guard/Dynamic lock down, because >> ?all this techniques are based on a MAC-IP database created during >> ?a communication with a DHCP server. There are some attempts (ND >> protection, SAVI) >> ?but it does not provide the same level of security. > > Most sites don't need that level of security. I agree there should be a > way to disable SLAAC reliably at a site as a policy matter, but, frankly > the techniques you're talking about come in one of two flavors: > > ? ? ? ?1. ? ? ?They dynamically enable the switch to accept packets from > ? ? ? ? ? ? ? ?a client, in which case, SLAAC based clients would be blocked > ? ? ? ? ? ? ? ?until they registered with DHCP anyway. > or > ? ? ? ?2. ? ? ?They don't effectively block an attacker who cobbles his own > ? ? ? ? ? ? ? ?address even without SLAAC. > > In the former case, you get the security you want and force DHCP anyway, > so I don't see a problem. In the latter case, you only had the illusion of > security to begin with, so, SLAAC just makes it easy to disillusion you. > >> - Just the same technique was introduced in IPv4 as Router Discovery >> (RFC 1256). >> ?Nobody uses it today. Do we really need go through same death way again? >> ?(Oh right, we are already going :-( ) > > Not a fair comparison. There were a number of additional issues with 1256 that > prevented it from gaining acceptance in IPv4. > >> >> Comparing to SLAAC, DHCPv6 have several advantages: >> - DHCPv6 is very similar to DHCP(v4) and many people are used to using it. > > That just makes it familiar, not necessarily better for all environments. > >> - DHCPv6 can potentially do much more - for example handle an information >> ?for PXE, options for IP phones, prefix delegation. > > True, but, that comes at a cost of complexity and overhead which may not be > desirable in all environments. > >> - DHCPv6 allows handle an information only for some hosts or group of >> ?hosts (differed lease time, search list, DNS atc.). With SLAAC it is >> ?impossible and all host on a subnet have to share the same set of >> ?the configuration information. > > Which is not an issue in 99+% of environments. > >> - Frankly said, I have not found any significant benefit that SLAAC brings. > > Perhaps you have not, but, others have. I have seen environments where > SLAAC is much more useful than DHCPv6. I've seen environments where > DHCPv6 is needed. > >> >> Unfortunately there is another issue with DUIDs in DHCPv6. But it is a >> little bit differed tale. >> >> At the beginning the autoconfiguration was meant as easy to use and easy >> to configure but the result turned out into kind of nightmare. For those >> who do not know what I am talking about I prepared two images. The first >> one shows necessary communication before first regular packet can be >> send over IPv4 (http://hawk.cis.vutbr.cz/~tpoder/tmp/autoconf/IPv4.png) >> and just the same thing in IPv6 >> (http://hawk.cis.vutbr.cz/~tpoder/tmp/autoconf/IPv4.png). In IPv4 we >> have very simple answer if somebody asks for autoconfiguration ?= use >> DHCP. In IPv6 the description how things work have to be written into >> more than 10 pages [1]. I believe that is not what we really wanted. >> > > That's no really a fair characterization. Yes, DHCPv6 is more complex > than DHCPv4, but, not significantly so. > > In reality it can be summed up relatively quickly: > > 1. ? ? ?Choose link local address (fe80::EUI64) > 2. ? ? ?Send RS packet to all-routers multicast address > 3. ? ? ?Receive one or more RA packets. > ? ? ? ?a. if Packet contains prefix information: > ? ? ? ? ? ? ? ?i. ? ? ?Set timers, apply addresses to interfaces > ? ? ? ? ? ? ? ? ? ? ? ?(first regular packet can be sent at this point) > ? ? ? ?b. If packet has O bit set: > ? ? ? ? ? ? ? ?i. ? ? ?Send DHCPv6 request to DHCP server > ? ? ? ? ? ? ? ?ii. ? ? Get response > ? ? ? ? ? ? ? ?iii. ? ?Configure accordingly. > ? ? ? ? ? ? ? ? ? ? ? ?(If a was false (a and b are not mutually exclusive), then > ? ? ? ? ? ? ? ? ? ? ? ?you can now send your first regular packet). > > Yes, there are a few corner cases not completely addressed above, > but, unless you're building the software to implement the standards, > they are mostly irrelevant. Even if you add them in (interactions between > the M, A, and O bits), you can still describe it in about a page, not > ten. > > Owen > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From bonomi at mail.r-bonomi.com Thu Dec 22 01:51:52 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Thu, 22 Dec 2011 01:51:52 -0600 (CST) Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <135180.1324518480@turing-police.cc.vt.edu> Message-ID: <201112220751.pBM7pqrU091109@mail.r-bonomi.com> Valdis.Kletnieks at vt.edu wrote: > > OK, I'll name names. If you have end users still running WinXP, getting > them at least somewhat working under SLAAC/DHCPv4 is a lot less headache > than trying to DHCPv6 them. > > Anybody managed to stamp out WinXP in their end user population yet? > Heh. I haven't manage to stamp out WinXP in _my_ usage. Microsoft's "Services for Unix" doesn't run on on anything but the obsecenely high-priced top-end versions of their newer releases. In addition to the significantly increased hardware requirements to get the same "user app" performance, this makes upgrading a 'show stopper'. From glen.kent at gmail.com Thu Dec 22 06:48:06 2011 From: glen.kent at gmail.com (Glen Kent) Date: Thu, 22 Dec 2011 18:18:06 +0530 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EF28A00.2080904@kl.net> References: <4EF28A00.2080904@kl.net> Message-ID: > In many environments RA is a catastrophic disaster. Some operators need > to be able to do everything with RA turned off on routers, disabled on > hosts and filtered on switches. While in some environments, typically with small number of devices, its indispensable. Small businesses may not want the complexity of setting up a central server (for DHCP) - SLAAC works very well in such environments. Today, we can get NTP server information only with DHCP (DNS info is supported by both DHCP and RAs). DHCP only works after RAs have been processed. In some environments (mobile IPv6) delays in acquiring NTP and other servers information is critical and waiting for DHCP to come up may not be acceptable. Glen From olivier.benghozi at wifirst.fr Thu Dec 22 07:20:21 2011 From: olivier.benghozi at wifirst.fr (Olivier Benghozi) Date: Thu, 22 Dec 2011 14:20:21 +0100 Subject: bgp update destroying transit on redback routers ? In-Reply-To: <0ED867EB33AB2B45AAB470D5A64CDBF6181C2EDEB6@EUSAACMS0701.eamcs.ericsson.se> References: <0ED867EB33AB2B45AAB470D5A64CDBF6181C25624E@EUSAACMS0701.eamcs.ericsson.se> <20111202143554.GA66539@snar.spb.ru> <0ED867EB33AB2B45AAB470D5A64CDBF6181C2EDEB6@EUSAACMS0701.eamcs.ericsson.se> Message-ID: <87CD9A36-6A74-465C-8154-7C9F58640773@wifirst.fr> Aha, it looks that our Quebecer friends from Hostlogistic (AS46609) have again been advertising their now famous funny aggregate with their mad Brocade router, since yesterday 10pm UTC (that is 5pm in Quebec)... Same route to 206.125.164.0/22, same AGGREGATOR attribute full of 0. At least I can say that the patched Ericsson's bgpd stopped reseting the sessions. regards, Olivier Le 2 d?c. 2011 ? 23:14, Jeff Tantsura a ?crit : > Hi Alexandre, > > You are right, the behavior is exactly as per RFC4271 section 6: > "When any of the conditions described here are detected, a > NOTIFICATION message, with the indicated Error Code, Error Subcode, and Data fields, is sent, and the BGP connection is closed. > So because ASN 0 in AGGREGATOR is seen as a malformed UPDATE we send 3/9 and close the connection. > > Ideally it should be treated as "treat-as-withdraw" as per draft-chen-ebgp-error-handling, however please note - this is still a draft, > not a normative document and with all my support it takes time to implement. > > Once again, we understand the implications for our customers and hence going to disable ASN 0 check. > > P.S. We have strong evidence that the update in question was caused by a bug on a freshly updated router (I'm not going to disclose the vendor) > > Regards, > Jeff > > > -----Original Message----- > From: Alexandre Snarskii [mailto:snar at snar.spb.ru] > Sent: Friday, December 02, 2011 6:36 AM > To: Jeff Tantsura > Cc: nanog at nanog.org > Subject: Re: bgp update destroying transit on redback routers ? > > On Thu, Dec 01, 2011 at 04:56:43PM -0500, Jeff Tantsura wrote: >> Hi, >> >> Let me take it over from now on, I'm the IP Routing/MPLS Product >> Manager at Ericsson responsible for all routing protocols. >> There's nothing wrong in checking ASN in AGGREGATOR, we don't really >> want see ASN 0 anywhere, that's how draft-wkumari-idr-as0 >> (draft-ietf-idr-as0-00) came into the worlds. > > This draft says that > > If a BGP speaker receives a route which has an AS number of zero in the AS_PATH (or AS4_PATH) attribute, it SHOULD be logged and treated as a WITHDRAW. This same behavior applies to routes containing zero as the Aggregator or AS4 Aggregator. > > but observed behaviour was more like following: > > If a BGP speaker receives [bad route] it MUST close session immediately with NOTIFICATION Error Code 'Update Message Error' and subcode 'Error with optional attribute'. From djw at bbn.com Thu Dec 22 08:57:30 2011 From: djw at bbn.com (David Waitzman) Date: Thu, 22 Dec 2011 09:57:30 -0500 Subject: Help with quagga BGP config for ipv6 route-server Message-ID: <2D1257E5-A7CA-47A0-B08B-9B515D6E7017@bbn.com> I am trying to set up BGP peering with a route-server, concurrently dual-stack. BGP 4 over an IPv4 connection works fine. A separate BGP 6 over IPv6 fails: with an "[Error] No common capability". I am using quagga 0.99.20 on ubuntu 10.04.03. I don't know what the route-server is. I have tried to tell both quagga to not be strict about capabilities or not negotiate them at all. My quagga config includes: router bgp XX no bgp enforce-first-as no bgp default ipv4-unicast !! tried with and without this bgp router-id XX network XY/24 route-map SetAttr neighbor XX4 remote-as XX neighbor XX4 activate neighbor XX4 next-hop-self neighbor XX4 send-community address-family ipv6 network XY6/48 route-map SetAttr neighbor XX6 remote-as XX neighbor XX6 activate neighbor XX6 next-hop-self neighbor XX6 send-community neighbor XX6 soft-reconfiguration inbound The code, I think, that's triggering the error is: /* Check there is no common capability send Unsupported Capability error. */ if (*capability && ! CHECK_FLAG (peer->flags, PEER_FLAG_OVERRIDE_CAPABILITY)) { if (! peer->afc_nego[AFI_IP][SAFI_UNICAST] && ! peer->afc_nego[AFI_IP][SAFI_MULTICAST] && ! peer->afc_nego[AFI_IP][SAFI_MPLS_VPN] && ! peer->afc_nego[AFI_IP6][SAFI_UNICAST] && ! peer->afc_nego[AFI_IP6][SAFI_MULTICAST]) From tcpdump, my side's open message includes: Open Message (1), length: 57 Version 4, my AS XX, Holdtime 180s, ID XX4 !! XX4 is my V4 address Optional parameters, length: 28 Option Capabilities Advertisement (2), length: 6 Multiprotocol Extensions (1), length: 4 AFI IPv4 (1), SAFI Unicast (1) 0x0000: 0001 0001 Option Capabilities Advertisement (2), length: 2 Route Refresh (Cisco) (128), length: 0 Option Capabilities Advertisement (2), length: 2 Route Refresh (2), length: 0 Option Capabilities Advertisement (2), length: 6 32-Bit AS Number (65), length: 4 no decoder for Capability 65 0x0000: 0000 e0c5 Option Capabilities Advertisement (2), length: 2 Unknown (66), length: 0 no decoder for Capability 66 The route-server's response is: Open Message (1), length: 45 Version 4, my AS XX, Holdtime 240s, ID XY4 !! XY4 is his V4 address Optional parameters, length: 16 Option Capabilities Advertisement (2), length: 14 Multiprotocol Extensions (1), length: 4 AFI IPv6 (2), SAFI Unicast (1) 0x0000: 0002 0001 To which I respond: Notification Message (3), length: 27, OPEN Message Error (2), subcode Capability Message Error (7) When I add "dont-capability-negotiate" to the config, I send: Open Message (1), length: 29 Version 4, my AS 57541, Holdtime 180s, ID XX4 Optional parameters, length: 0 I get back: Open Message (1), length: 45 Version 4, my AS XX, Holdtime 240s, ID XY4 Optional parameters, length: 16 Option Capabilities Advertisement (2), length: 14 Multiprotocol Extensions (1), length: 4 AFI IPv6 (2), SAFI Unicast (1) 0x0000: 0002 0001 I respond: Notification Message (3), length: 27, OPEN Message Error (2), subcode Capability Message Error (7) I'm a developer and former rfc writer, not a network operator. thanks nanog, -- David Waitzman BBN Technologies From jmkeller at houseofzen.org Thu Dec 22 10:55:04 2011 From: jmkeller at houseofzen.org (James M Keller) Date: Thu, 22 Dec 2011 11:55:04 -0500 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: Message-ID: <4EF360E8.6000108@houseofzen.org> On 12/21/2011 11:28 PM, William Herrin wrote: > On Tue, Dec 20, 2011 at 1:27 AM, Ravi Duggal wrote: >> We thus have draft-droms-dhc-dhcpv6-default-router-00 that extends >> DHCPv6 to do what RA does. And now, we have >> draft-bcd-6man-ntp-server-ra-opt-00.txt that extends RA to advertise >> the NTP information that is currently done via DHCPv6. >> >> My question is, that which then is the more preferred option for the >> operators? > "Yes." > > We want both. We'll try both. And in a couple years when the > percentage Internet use of IPv6 is out of the single digits, we'll let > you know what worked in which situations. > > We probably don't need one configuration protocol to rule them all. > IPv4 has PAP/CHAP over PPP and DHCP over Ethernet plus a number of > more minor ones like bootp (DHCP's semi-compatible predecessor) and > rarp. We really don't suffer for the choice. > > Regards, > Bill Herrin > > > Yes +1 I would consider RA+SLAAC for residential/hotel/company guest, etc. Any place you don't care about host configuration tracking, authentication, accounting, etc. DHCPv6 for fully managed environments with NAC / Auditing requirements. DHCPv6 would let you control per host/host class which router(s) on the network to use explicitly, vs RA with just preferences for each router. Both should be able to provide the same type of information, and let the administrators choose which deployment method meets the requirements for their environment. -- --- James M Keller From jmkeller at houseofzen.org Thu Dec 22 11:04:28 2011 From: jmkeller at houseofzen.org (James M Keller) Date: Thu, 22 Dec 2011 12:04:28 -0500 Subject: Well Lookie Here, Barracuda Networks tries to get me to fall into their trap again... In-Reply-To: References: <20111221104148.4565907e@jpeach-desktop.anbg.mssm.edu> <1449422.1440.1324490075558.JavaMail.root@benjamin.baylink.com> <8C26A4FDAE599041A13EB499117D3C286B6354A8@ex-mb-1.corp.atlasnetworks.us> <2F1D4FA4-107A-49C4-B5E5-CD40B282B9B2@freethought-internet.co.uk> Message-ID: <4EF3631C.8030600@houseofzen.org> On 12/21/2011 3:22 PM, David Swafford wrote: > In my position within the enterprise vertical, backdating to the > expiration (not the payment date) seems to be the norm. Cisco does > this on SmartNet, as does SolarWinds and a number of other vendors > I've worked with. We don't typically slip on the dates intentionally, > but our procurement and legal groups have a habit of fighting over > wording on the contracts. > > David. > > Having worked in the past at a shop that sold managed support agreements for software we sold - the overhead for staffing and code and blacklisting type data sets are spread out in the yearly support agreement. A lapsed customer has not funded the delta changes in code and data set from lapsed data to renewal date, but will get to take advantage of the work. While a new customer also will not fund these on a new starting contract, that is normally considered some cost of acquiring new business. Now in some cases on the other end of the transaction I've found it cheaper to buy 'new' then it was to 'true up' the support. I haven't found a vendor that wouldn't go that route, even if it involved getting some escalation on the sales side first. At that point it's the cost of customer retention vs new business that the vendor needs to worry about. However if you are happy with the product, and the renewal isn't more then 'new' purchases - we all shouldn't be baulking having to 'true up' contracts. -- --- James M Keller From paul4004 at gmail.com Thu Dec 22 12:26:56 2011 From: paul4004 at gmail.com (PC) Date: Thu, 22 Dec 2011 12:26:56 -0600 Subject: Well Lookie Here, Barracuda Networks tries to get me to fall into their trap again... In-Reply-To: <4EF3631C.8030600@houseofzen.org> References: <20111221104148.4565907e@jpeach-desktop.anbg.mssm.edu> <1449422.1440.1324490075558.JavaMail.root@benjamin.baylink.com> <8C26A4FDAE599041A13EB499117D3C286B6354A8@ex-mb-1.corp.atlasnetworks.us> <2F1D4FA4-107A-49C4-B5E5-CD40B282B9B2@freethought-internet.co.uk> <4EF3631C.8030600@houseofzen.org> Message-ID: This particular product is often used by the SMB types. This changes things a bit. While I disagree with paying for signature updates you didn't use (It's a service, and I don't care about their fixed costs, I went into it knowing I'd have a license for the signatures as they were expired), I do understand where they are coming from for software/firmware development. Unfortunately, they don't decouple the two. However, this particular vendor is bad in a market where gear often passes hands or goes lapsed for years. After a certain point (IE: 1 yr), you shouldn't have to true-up. This particular company makes your 3-year lapsed appliance pay for 3 years of missed updates, at which point you might as well just throw it in the garbage. Same thing with my license plates -- if they go for 11 months or less, I have to "true up". If I put a car in storage for over a year, I can purchase a new registration. On Thu, Dec 22, 2011 at 11:04 AM, James M Keller wrote: > On 12/21/2011 3:22 PM, David Swafford wrote: > > In my position within the enterprise vertical, backdating to the > > expiration (not the payment date) seems to be the norm. Cisco does > > this on SmartNet, as does SolarWinds and a number of other vendors > > I've worked with. We don't typically slip on the dates intentionally, > > but our procurement and legal groups have a habit of fighting over > > wording on the contracts. > > > > David. > > > > > > Having worked in the past at a shop that sold managed support agreements > for software we sold - the overhead for staffing and code and > blacklisting type data sets are spread out in the yearly support > agreement. A lapsed customer has not funded the delta changes in code > and data set from lapsed data to renewal date, but will get to take > advantage of the work. > While a new customer also will not fund these on a new starting > contract, that is normally considered some cost of acquiring new > business. > > Now in some cases on the other end of the transaction I've found it > cheaper to buy 'new' then it was to 'true up' the support. I haven't > found a vendor that wouldn't go that route, even if it involved getting > some escalation on the sales side first. At that point it's the cost > of customer retention vs new business that the vendor needs to worry > about. However if you are happy with the product, and the renewal > isn't more then 'new' purchases - we all shouldn't be baulking having to > 'true up' contracts. > > -- > --- > James M Keller > > > From jeff.tantsura at ericsson.com Thu Dec 22 12:42:15 2011 From: jeff.tantsura at ericsson.com (Jeff Tantsura) Date: Thu, 22 Dec 2011 13:42:15 -0500 Subject: bgp update destroying transit on redback routers ? In-Reply-To: <87CD9A36-6A74-465C-8154-7C9F58640773@wifirst.fr> References: <0ED867EB33AB2B45AAB470D5A64CDBF6181C25624E@EUSAACMS0701.eamcs.ericsson.se> <20111202143554.GA66539@snar.spb.ru> <0ED867EB33AB2B45AAB470D5A64CDBF6181C2EDEB6@EUSAACMS0701.eamcs.ericsson.se> <87CD9A36-6A74-465C-8154-7C9F58640773@wifirst.fr> Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF6181C5C68CF@EUSAACMS0701.eamcs.ericsson.se> Olivier, Thanks! We've done our best to provide the fix ASAP. Regards, Jeff -----Original Message----- From: Olivier Benghozi [mailto:olivier.benghozi at wifirst.fr] Sent: Thursday, December 22, 2011 5:20 AM To: nanog at nanog.org Cc: Alexandre Snarskii; Jeff Tantsura Subject: Re: bgp update destroying transit on redback routers ? Aha, it looks that our Quebecer friends from Hostlogistic (AS46609) have again been advertising their now famous funny aggregate with their mad Brocade router, since yesterday 10pm UTC (that is 5pm in Quebec)... Same route to 206.125.164.0/22, same AGGREGATOR attribute full of 0. At least I can say that the patched Ericsson's bgpd stopped reseting the sessions. regards, Olivier Le 2 d?c. 2011 ? 23:14, Jeff Tantsura a ?crit : > Hi Alexandre, > > You are right, the behavior is exactly as per RFC4271 section 6: > "When any of the conditions described here are detected, a > NOTIFICATION message, with the indicated Error Code, Error Subcode, and Data fields, is sent, and the BGP connection is closed. > So because ASN 0 in AGGREGATOR is seen as a malformed UPDATE we send 3/9 and close the connection. > > Ideally it should be treated as "treat-as-withdraw" as per > draft-chen-ebgp-error-handling, however please note - this is still a draft, not a normative document and with all my support it takes time to implement. > > Once again, we understand the implications for our customers and hence going to disable ASN 0 check. > > P.S. We have strong evidence that the update in question was caused by > a bug on a freshly updated router (I'm not going to disclose the > vendor) > > Regards, > Jeff > > > -----Original Message----- > From: Alexandre Snarskii [mailto:snar at snar.spb.ru] > Sent: Friday, December 02, 2011 6:36 AM > To: Jeff Tantsura > Cc: nanog at nanog.org > Subject: Re: bgp update destroying transit on redback routers ? > > On Thu, Dec 01, 2011 at 04:56:43PM -0500, Jeff Tantsura wrote: >> Hi, >> >> Let me take it over from now on, I'm the IP Routing/MPLS Product >> Manager at Ericsson responsible for all routing protocols. >> There's nothing wrong in checking ASN in AGGREGATOR, we don't really >> want see ASN 0 anywhere, that's how draft-wkumari-idr-as0 >> (draft-ietf-idr-as0-00) came into the worlds. > > This draft says that > > If a BGP speaker receives a route which has an AS number of zero in the AS_PATH (or AS4_PATH) attribute, it SHOULD be logged and treated as a WITHDRAW. This same behavior applies to routes containing zero as the Aggregator or AS4 Aggregator. > > but observed behaviour was more like following: > > If a BGP speaker receives [bad route] it MUST close session immediately with NOTIFICATION Error Code 'Update Message Error' and subcode 'Error with optional attribute'. From bicknell at ufp.org Thu Dec 22 12:47:45 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 22 Dec 2011 10:47:45 -0800 Subject: Well Lookie Here, Barracuda Networks tries to get me to fall into their trap again... In-Reply-To: References: <20111221104148.4565907e@jpeach-desktop.anbg.mssm.edu> <1449422.1440.1324490075558.JavaMail.root@benjamin.baylink.com> <8C26A4FDAE599041A13EB499117D3C286B6354A8@ex-mb-1.corp.atlasnetworks.us> <2F1D4FA4-107A-49C4-B5E5-CD40B282B9B2@freethought-internet.co.uk> <4EF3631C.8030600@houseofzen.org> Message-ID: <20111222184745.GA69040@ussenterprise.ufp.org> In a message written on Thu, Dec 22, 2011 at 12:26:56PM -0600, PC wrote: > This particular product is often used by the SMB types. This changes > things a bit. While I disagree with paying for signature updates you > didn't use (It's a service, and I don't care about their fixed costs, I > went into it knowing I'd have a license for the signatures as they were > expired), I do understand where they are coming from for software/firmware > development. Unfortunately, they don't decouple the two. Maybe I'm just a grinch, but I think they could fix this problem. If they set the software in the box so that on the day your subscription expires it no longer processes the subscription data there would be a lot less issue. The problem here is they let the system use the old signature data, and that data is useful for a while. The day after a contract expires, you're still getting 99.9% of th benefit, a week later 95%, and so on. They've essentially been too nice in letting the software be leniant with the signature data, and they they pay for it in terms of customer relations when they try to do renew. Do they let customers renew every 13 months, effectively getting one month free each year while they run on old subscription data, or do they play hardball and make them "true up" with a backdated contract. It's really a no-win choice for them. I suspect if someone came in here saying "my Baracuda stopped filtering out spam the day my contract expired" there would be no love for that person, they would be told "yeah, so renew your contract if you want the service to work". While making it stop working may seem less customer friendly, I think it actually ends up more. Everyone knows where they stand, and the poor engineer trying to get his management to renew it now has a nice club to use internally rather than the current "nothing happens if we ignore it, at least in the short term." -- 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 mike at mtcc.com Thu Dec 22 12:54:55 2011 From: mike at mtcc.com (Michael Thomas) Date: Thu, 22 Dec 2011 10:54:55 -0800 Subject: Well Lookie Here, Barracuda Networks tries to get me to fall into their trap again... In-Reply-To: <20111222184745.GA69040@ussenterprise.ufp.org> References: <20111221104148.4565907e@jpeach-desktop.anbg.mssm.edu> <1449422.1440.1324490075558.JavaMail.root@benjamin.baylink.com> <8C26A4FDAE599041A13EB499117D3C286B6354A8@ex-mb-1.corp.atlasnetworks.us> <2F1D4FA4-107A-49C4-B5E5-CD40B282B9B2@freethought-internet.co.uk> <4EF3631C.8030600@houseofzen.org> <20111222184745.GA69040@ussenterprise.ufp.org> Message-ID: <4EF37CFF.3020109@mtcc.com> On 12/22/2011 10:47 AM, Leo Bicknell wrote: > In a message written on Thu, Dec 22, 2011 at 12:26:56PM -0600, PC wrote: >> This particular product is often used by the SMB types. This changes >> things a bit. While I disagree with paying for signature updates you >> didn't use (It's a service, and I don't care about their fixed costs, I >> went into it knowing I'd have a license for the signatures as they were >> expired), I do understand where they are coming from for software/firmware >> development. Unfortunately, they don't decouple the two. > Maybe I'm just a grinch, but I think they could fix this problem. > If they set the software in the box so that on the day your > subscription expires it no longer processes the subscription data > there would be a lot less issue. At that point why should they sell iron at all? Seems like you get all of the downside of owning the iron, and all of the downside of paying for a cloud based service. Either you own what you own, or you pay for service that somebody else provides. This "you bought useless hardware unless you pay up" is really what's infuriating. Mike From bicknell at ufp.org Thu Dec 22 13:02:40 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 22 Dec 2011 11:02:40 -0800 Subject: Well Lookie Here, Barracuda Networks tries to get me to fall into their trap again... In-Reply-To: <4EF37CFF.3020109@mtcc.com> References: <20111221104148.4565907e@jpeach-desktop.anbg.mssm.edu> <1449422.1440.1324490075558.JavaMail.root@benjamin.baylink.com> <8C26A4FDAE599041A13EB499117D3C286B6354A8@ex-mb-1.corp.atlasnetworks.us> <2F1D4FA4-107A-49C4-B5E5-CD40B282B9B2@freethought-internet.co.uk> <4EF3631C.8030600@houseofzen.org> <20111222184745.GA69040@ussenterprise.ufp.org> <4EF37CFF.3020109@mtcc.com> Message-ID: <20111222190240.GA69876@ussenterprise.ufp.org> In a message written on Thu, Dec 22, 2011 at 10:54:55AM -0800, Michael Thomas wrote: > At that point why should they sell iron at all? Seems like you get > all of the downside of owning the iron, and all of the downside of > paying for a cloud based service. Either you own what you own, > or you pay for service that somebody else provides. This "you > bought useless hardware unless you pay up" is really what's > infuriating. I didn't say the box should stop working, but that it should stop processing the subscription data. For instance Barracuda boxes do local bayesian filtering, which does not require a subscription, and should continue to work. But I'm also not sure why this is any more or less infuriating than other things in the real world. When my home was built I had to buy an electric meter, at my cost, so I could get electric _service_. If I don't pay the bill they turn me off, that hardware is now useless and I don't get to recoup that cost. Barracuda has bundled a hardware product with a service. Some people want it priced like a hardware product, some people want it priced like a service. That is fundamentally why they are in a no-win position from a customer relations perspective. -- 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 jlewis at lewis.org Thu Dec 22 13:07:31 2011 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 22 Dec 2011 14:07:31 -0500 (EST) Subject: Well Lookie Here, Barracuda Networks tries to get me to fall into their trap again... In-Reply-To: <4EF37CFF.3020109@mtcc.com> References: <20111221104148.4565907e@jpeach-desktop.anbg.mssm.edu> <1449422.1440.1324490075558.JavaMail.root@benjamin.baylink.com> <8C26A4FDAE599041A13EB499117D3C286B6354A8@ex-mb-1.corp.atlasnetworks.us> <2F1D4FA4-107A-49C4-B5E5-CD40B282B9B2@freethought-internet.co.uk> <4EF3631C.8030600@houseofzen.org> <20111222184745.GA69040@ussenterprise.ufp.org> <4EF37CFF.3020109@mtcc.com> Message-ID: On Thu, 22 Dec 2011, Michael Thomas wrote: > At that point why should they sell iron at all? Seems like you get > all of the downside of owning the iron, and all of the downside of > paying for a cloud based service. Either you own what you own, > or you pay for service that somebody else provides. This "you > bought useless hardware unless you pay up" is really what's > infuriating. Presumably, Barracuda's hardware is i386/i686 compatible commodity parts. It's probably not at all "useless". Just attach a USB DVD drive or USB flash drive, wipe the disk(s) and install your favorite Linux distro. It may take some doing to get all/most of the features Barracuda provides setup on your own...but if you don't have the time/expertise to do it, that's why companies like Barracuda exist. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From mike at mtcc.com Thu Dec 22 13:22:00 2011 From: mike at mtcc.com (Michael Thomas) Date: Thu, 22 Dec 2011 11:22:00 -0800 Subject: Well Lookie Here, Barracuda Networks tries to get me to fall into their trap again... In-Reply-To: References: <20111221104148.4565907e@jpeach-desktop.anbg.mssm.edu> <1449422.1440.1324490075558.JavaMail.root@benjamin.baylink.com> <8C26A4FDAE599041A13EB499117D3C286B6354A8@ex-mb-1.corp.atlasnetworks.us> <2F1D4FA4-107A-49C4-B5E5-CD40B282B9B2@freethought-internet.co.uk> <4EF3631C.8030600@houseofzen.org> <20111222184745.GA69040@ussenterprise.ufp.org> <4EF37CFF.3020109@mtcc.com> Message-ID: <4EF38358.40705@mtcc.com> On 12/22/2011 11:07 AM, Jon Lewis wrote: > On Thu, 22 Dec 2011, Michael Thomas wrote: > >> At that point why should they sell iron at all? Seems like you get >> all of the downside of owning the iron, and all of the downside of >> paying for a cloud based service. Either you own what you own, >> or you pay for service that somebody else provides. This "you >> bought useless hardware unless you pay up" is really what's >> infuriating. > > Presumably, Barracuda's hardware is i386/i686 compatible commodity parts. It's probably not at all "useless". Just attach a USB DVD drive or USB flash drive, wipe the disk(s) and install your favorite Linux distro. > It may take some doing to get all/most of the features Barracuda provides setup on your own...but if you don't have the time/expertise to do it, that's why companies like Barracuda exist. If the spam filter stop working, it's presumably a pretty useless thing as a... spam filtering device which is presumably why most people are buying barracuda boxen. I suppose my larger point is that this is why companies like postini exist. At least there you know that if you don't pay the bill, mail stops flowing altogether much like any other service. It's this "I paid for the hardware, but I don't really own what I paid for" state that seems to stick in people's craw. Or maybe if they just leased the box it would be more clear what their business model was. Mike From zeusdadog at gmail.com Thu Dec 22 13:28:10 2011 From: zeusdadog at gmail.com (Jay Nakamura) Date: Thu, 22 Dec 2011 14:28:10 -0500 Subject: Windows UDP packet generator software? Message-ID: The goal of what I am doing is to test some network convergence impact in a lab with two PCs with windows (Can't run Linux, it would be easier if I could) and switches and/or routers in between. So, I thought there must be some simple utility out there that can just start spewing out UDP packets to the other side at a certain time interval and I can look at packet loss via what arrives on the other side with wireshark on the PC. I found hping but it seems to be outdated and I can't get it to work on my windows boxes. Anyone have any suggestions? From hvgeekwtrvl at gmail.com Thu Dec 22 13:34:45 2011 From: hvgeekwtrvl at gmail.com (james machado) Date: Thu, 22 Dec 2011 11:34:45 -0800 Subject: Windows UDP packet generator software? In-Reply-To: References: Message-ID: d-itg works very well. http://www.grid.unina.it/software/ITG/index.php you can create reports of loss/jitter etc. windows and qos don't work so don't try setting qos values as they will just be reset to 0 by the windows tcp/ip stack. james From drohan at gmail.com Thu Dec 22 13:35:22 2011 From: drohan at gmail.com (Daniel Rohan) Date: Thu, 22 Dec 2011 22:35:22 +0300 Subject: Windows UDP packet generator software? In-Reply-To: References: Message-ID: On Thu, Dec 22, 2011 at 10:28 PM, Jay Nakamura wrote: > The goal of what I am doing is to test some network convergence impact > in a lab with two PCs with windows (Can't run Linux, it would be > easier if I could) and switches and/or routers in between. > > So, I thought there must be some simple utility out there that can > just start spewing out UDP packets to the other side at a certain time > interval and I can look at packet loss via what arrives on the other > side with wireshark on the PC. > > I found hping but it seems to be outdated and I can't get it to work > on my windows boxes. > > Anyone have any suggestions? > > Two suggestions: 1) http://robert.rsa3.com/traffic.html (I haven't actually run this myself, but it's description seems to fit the bill) 2) http://sourceforge.net/projects/iperf/ (iPerf in client mode can spew UDP packets in configurable bursts) From sean at seanharlow.info Thu Dec 22 13:36:30 2011 From: sean at seanharlow.info (Sean Harlow) Date: Thu, 22 Dec 2011 14:36:30 -0500 Subject: Windows UDP packet generator software? In-Reply-To: References: Message-ID: <0B377425-F833-4914-BFCC-C2364A4F07BF@seanharlow.info> iperf might be able to do what you need and there are Windows builds available, but I'm not sure if it has a mode where it's not flooding the network trying to test maximum speed. Is there a reason that standard ICMP pings aren't appropriate if you just want packet loss info? Obviously every platform worth using has ping built in. ---------- Sean Harlow sean at seanharlow.info On Dec 22, 2011, at 2:28 PM, Jay Nakamura wrote: > The goal of what I am doing is to test some network convergence impact > in a lab with two PCs with windows (Can't run Linux, it would be > easier if I could) and switches and/or routers in between. > > So, I thought there must be some simple utility out there that can > just start spewing out UDP packets to the other side at a certain time > interval and I can look at packet loss via what arrives on the other > side with wireshark on the PC. > > I found hping but it seems to be outdated and I can't get it to work > on my windows boxes. > > Anyone have any suggestions? > From tpoder at cis.vutbr.cz Thu Dec 22 14:04:42 2011 From: tpoder at cis.vutbr.cz (Tomas Podermanski) Date: Thu, 22 Dec 2011 21:04:42 +0100 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> Message-ID: <4EF38D5A.4070003@cis.vutbr.cz> Hi, On 12/21/11 9:40 PM, Ray Soucy wrote: > I'm afraid you're about 10 years too late for this opinion to make > much difference. ;-) My opinion is that there is never too late to make thinks easier to implement and operate, specially in situation when things are unnecessary complicated. I do not hide that my opinion about SLAAC might look extreme but I have wrote my reasons for that. I do not expect that anything will be changed but the fact that I can see discussion about that topic approximately 2 or 3 times per month (v6ops, dhcwg, ipv6, ...) and that shows that this problem is pain for many people/ISP. Have you ever seen similar discussion related to DHCP(v4). I have not, because there nothing to discuss about. It just works. It works in simple and logical way. > > We have been running IPv6 in production for several years (2008) as > well (answering this email over IPv6 now, actually) yet I have > completely different conclusions about the role of RA and DHCPv6. > Weird. Well, then how many devices do you have in the network that uses IPv6? Do you have implemented first hop security? What will you do when some user runs RA flood attack (http://samsclass.info/ipv6/proj/flood-router6a.htm). What will you do when some user runs NDP Table Exhaustion Attack (http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf) ? It is quite easy to bring IPv6 into a server subnet or a small office network. Providing stable and secure connectivity into the network with thousands of access port for the paying customers/users is really a serious issue today. I am very interested how the sites with similar number of access ports (users/customers) solve that problems. I can see that many ISPs prefer to solve that by blocking whole IPv6 traffic instead. But it does not look as a good strategy for deploying IPv6 :-(. Tomas > > On Wed, Dec 21, 2011 at 2:16 PM, Tomas Podermanski wrote: >> Hi, >> >> from my perspective the short answer for this never-ending story is: >> >> - SLAAC/RA is totally useless, does not bring any benefit at all >> and should be removed from IPv6 specs >> - DHCPv6 should be extended by route options as proposed in >> http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-03 >> - DHCPv6 should be extended by layer 2 address to identify >> client's L2 address (something that we can see in RFC 6221) >> - DHCPv6 should be the common way to autoconfigure an address >> in a IPv6 environment >> >> The long answer is: >> >> I completely disagree with opinion that both DHCPv6 and RA (SLAAC) >> should be supported. It is easy to say that both have place but it has >> some consequences. I and my colleagues have been working on deploying >> IPv6 for a few years and from the operation perspective we conclude into >> a quite clear opinion in that area. Both SLAAC and DHCPv6 uses a >> opposite principles although the goal is just one. DHCPv6 is based on a >> central DHCPv6 server that assigns addresses. SLAAC does opposite - >> leaves the decision about the address on a client side. However we have >> to run both of them in a network to provide all necessary pieces of >> information to the clients (default route and DNS). This brings many >> implementation and operational complications. >> >> - Clients have to support both SLAAC and DHCPv6 to be able to work in >> both environments >> - There must be solved a situation what to do when SLAAC and DHCPv6 >> provides some conflict information (quite long thread with various >> opinions >> can be found at >> http://www.ietf.org/mail-archive/web/ipv6/current/msg14949.html) >> - The first hop security have to be solved twice - for SLAAC and for >> DHCPv6. Both >> of then uses a differed communication way. SLAAC is part of ICMPv6, >> but DHCPv6 >> uses "own" UDP communication what does not make things easier. >> - SLAAC is usually processed in a kernel, DHCPv6 is usually run as a >> process in the user space. Diagnostic and troubleshooting is more >> complicated. >> - DHCPv6 is currently tied with SLAAC (M,O flags), what means that >> a DHCPv6 client have to wait until some RA message arrives to start DHCPv6 >> discovery. That unnecessary prolongs whole autoconfiguration process. >> >> Some other issues are also described in [1]. >> >> I personally prefer to bury SLAAC once forever for several reasons: >> - In fact SLAAC does nothing more what DHCPv6 can do. >> - SLAAC is quite difficult to secure. One (really only ONE) RA packet >> can destroy >> the IPv6 connection for all clients in a local network just in a few >> milliseconds. >> It also happens accidentally by "connection sharing" in Vista, Win7 >> >> (https://openwiki.uninett.no//_media/geantcampus:2011-gn3na3t4-ipv6-gregr.pdf) >> - The full protection against that behavior it's impossible today. >> RA-Guard or >> PACL can be bypassed using extension headers or fragmentation >> (http://www.mh-sec.de/downloads/mh-ipv6_vulnerabilities.pdf) >> - With SLAAC is difficult to implement security features like ARP/ND >> protection/inspection, IP source guard/Dynamic lock down, because >> all this techniques are based on a MAC-IP database created during >> a communication with a DHCP server. There are some attempts (ND >> protection, SAVI) >> but it does not provide the same level of security. >> - Just the same technique was introduced in IPv4 as Router Discovery >> (RFC 1256). >> Nobody uses it today. Do we really need go through same death way again? >> (Oh right, we are already going :-( ) >> >> Comparing to SLAAC, DHCPv6 have several advantages: >> - DHCPv6 is very similar to DHCP(v4) and many people are used to using it. >> - DHCPv6 can potentially do much more - for example handle an information >> for PXE, options for IP phones, prefix delegation. >> - DHCPv6 allows handle an information only for some hosts or group of >> hosts (differed lease time, search list, DNS atc.). With SLAAC it is >> impossible and all host on a subnet have to share the same set of >> the configuration information. >> - Frankly said, I have not found any significant benefit that SLAAC brings. >> >> Unfortunately there is another issue with DUIDs in DHCPv6. But it is a >> little bit differed tale. >> >> At the beginning the autoconfiguration was meant as easy to use and easy >> to configure but the result turned out into kind of nightmare. For those >> who do not know what I am talking about I prepared two images. The first >> one shows necessary communication before first regular packet can be >> send over IPv4 (http://hawk.cis.vutbr.cz/~tpoder/tmp/autoconf/IPv4.png) >> and just the same thing in IPv6 >> (http://hawk.cis.vutbr.cz/~tpoder/tmp/autoconf/IPv4.png). In IPv4 we >> have very simple answer if somebody asks for autoconfiguration = use >> DHCP. In IPv6 the description how things work have to be written into >> more than 10 pages [1]. I believe that is not what we really wanted. >> >> For those who are interested in that area there are several >> articles/presentations where we mentioned that topic. >> >> [1] IPv6 Autoconfiguration - Best Practice Document >> http://www.terena.org/activities/campus-bp/pdf/gn3-na3-t4-cbpd117.pdf >> >> [2] IPv6 - security threads >> http://www.fit.vutbr.cz/research/view_pub.php?id=9835 >> >> [3] Deploying IPv6 in University Campus Network - Practical Problems >> http://www.fit.vutbr.cz/research/view_pub.php?id=9836 >> >> >> Regards, >> Tomas Podermanski >> >> >> >> On 12/20/11 8:31 AM, Owen DeLong wrote: >>> Different operators will have different preferences in different environments. >>> >>> Ideally, the IETF should provide complete solutions based on DHCPv6 and >>> on RA and let the operators decide what they want to use in their environments. >>> >>> Owen >>> >>> On Dec 19, 2011, at 10:27 PM, Ravi Duggal wrote: >>> >>>> Hi, >>>> >>>> IPv6 devices (routers and hosts) can obtain configuration information >>>> about default routers, on-link prefixes and addresses from Router >>>> Advertisements as defined in Neighbor Discovery. I have been told >>>> that in some deployments, there is a strong desire not to use Router >>>> Advertisements at all and to perform all configuration via DHCPv6. >>>> There are thus similar IETF standards to get everything that you can >>>> get from RAs, by using DHCPv6 instead. >>>> >>>> As a result of this we see new proposals in IETF that try to do >>>> similar things by either extending RA mechanisms or by introducing new >>>> options in DHCPv6. >>>> >>>> We thus have draft-droms-dhc-dhcpv6-default-router-00 that extends >>>> DHCPv6 to do what RA does. And now, we have >>>> draft-bcd-6man-ntp-server-ra-opt-00.txt that extends RA to advertise >>>> the NTP information that is currently done via DHCPv6. >>>> >>>> My question is, that which then is the more preferred option for the >>>> operators? Do they prefer extending RA so that the new information >>>> loaded on top of the RA messages gets known in the single shot when >>>> routers do neighbor discovery. Or do they prefer all the extra >>>> information to be learnt via DHCPv6? What are the pros and cons in >>>> each approach and when would people favor one over the other? >>>> >>>> I can see some advantages with the loading information to RA since >>>> then one is not dependent on the DHCPv6 server. However, the latter >>>> provides its own benefits. >>>> >>>> Regards, >>>> Ravi D. >> > > From tpoder at cis.vutbr.cz Thu Dec 22 14:09:28 2011 From: tpoder at cis.vutbr.cz (Tomas Podermanski) Date: Thu, 22 Dec 2011 21:09:28 +0100 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EF2661A.4050408@rancid.berkeley.edu> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF2661A.4050408@rancid.berkeley.edu> Message-ID: <4EF38E78.7050504@cis.vutbr.cz> Hi, On 12/22/11 12:04 AM, Michael Sinatra wrote: > On 12/21/11 12:40, Ray Soucy wrote: >> I'm afraid you're about 10 years too late for this opinion to make >> much difference. ;-) >> >> We have been running IPv6 in production for several years (2008) as >> well (answering this email over IPv6 now, actually) yet I have >> completely different conclusions about the role of RA and DHCPv6. >> Weird. > > And that's a very good reason not to deprecate SLAAC. Tomas may > prefer DHCPv6, and he may provide reasons others may prefer DHCPv6. > But he hasn't provided justification for deprecating SLAAC. I am not against SLAAC. I am against the way how DHCPv6 & SLAAC works today. Today, SLAAC can not live without DHCPv6 and DHCPv6 can not live without SLAAC (RA). Second reason is that we have two protocols/techniques to do just the same thing. I prefer to have just ONE common autoconfiguration method as we have it in IPv4. Because DHCPv6 is more complex and SLAAC can provide only subset of DHCP functionality I personaly prefer DHCPv6. > > Many of us have been working with IPv6 for years and have found SLAAC > to be quite useful. The biggest benefit it provides, which Tomas did > not acknowledge, is the ability to autoconfigure hosts without running > a central server. That said, I have also found DHCPv6 to be quite > useful. We have to use SLAAC as well because we do not have other choice. Not all operating systems supports DHCPv6 today. But we are not happy about it (problems with privacy extensions, security as I mentioned before). DHCPv6 do not have to be run on a central server. DHCPv6 can be implemented as a part of a router as well. It is common for DHCP(v4) an implementations for DHCPv6 are available today (eg. cisco http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-dhcp.html). > > I also agree with Owen: Provide two complete solutions, and let > operators choose based on their needs. That implies fixing DHCPv6 so > I don't have to go in and disable the autonomous flag on my routers > and run RAs just to get a default route. But it also implies not > deprecating either SLAAC or DHCPv6. Although we have differed opinion whether we need one or two autoconfiguration protocols, I totally agree that "fixing" DHCPv6 is a really necessary step and It should have been done many years ago. Btw. not all people agree that DHCPv6 should be fixed in that way. There was a discussion in 2009 in dhcwg (thread available on: http://www.ietf.org/mail-archive/web/dhcwg/current/msg09715.html). The current draft (draft-ietf-mif-dhcpv6-route-option-03) is the 3rd attempt to do it. In past, there were another two drafts trying to introduce route information into DHCPv6: draft-droms-dhc-dhcpv6-default-router-00, expired September 2009 draft-dec-dhcpv6-route-option-05, expired April 2011 So I hope that this time we will have more luck :-) Tomas From djw at bbn.com Thu Dec 22 14:13:41 2011 From: djw at bbn.com (David Waitzman) Date: Thu, 22 Dec 2011 15:13:41 -0500 Subject: Help with quagga BGP config for ipv6 route-server In-Reply-To: <2D1257E5-A7CA-47A0-B08B-9B515D6E7017@bbn.com> References: <2D1257E5-A7CA-47A0-B08B-9B515D6E7017@bbn.com> Message-ID: <1B38068D-CF6A-47AA-9A7C-7665F4C8EC42@bbn.com> My IPv4 and IPv6 BGP connections now get prefixes. My thanks to those who answered on and off the list. My revised config is like: ----------------------- router bgp MYAS no bgp enforce-first-as no bgp default ipv4-unicast network MYIPv4NET route-map SetAttr neighbor PEERIPv6 remote-as RSAS neighbor PEERIPv4 remote-as RSAS neighbor PEERIPv4 activate neighbor PEERIPv4 next-hop-self neighbor PEERIPv4 send-community !neighbor PEERIPv4 soft-reconfiguration inbound address-family ipv6 network MYIPv6NET route-map SetAttr neighbor PEERIPv6 activate neighbor PEERIPv6 send-community neighbor PEERIPv6 soft-reconfiguration inbound exit-address-family route-map SetAttr permit 10 set community RSAS:RSAS end ------------------------- I had to move the V6 remote-as line up before the address-family ipv6 block. I appear to have needed the "exit-address-family". Having "bgp router-id MYIP4INTERFACE" causes problems. I am not sure yet if not having it is going to cause other problems. -- David Waitzman From blakjak at blakjak.net Thu Dec 22 14:16:28 2011 From: blakjak at blakjak.net (Mark Foster) Date: Fri, 23 Dec 2011 09:16:28 +1300 Subject: Windows UDP packet generator software? In-Reply-To: <0B377425-F833-4914-BFCC-C2364A4F07BF@seanharlow.info> References: <0B377425-F833-4914-BFCC-C2364A4F07BF@seanharlow.info> Message-ID: <4EF3901C.60106@blakjak.net> I can imagine plenty of circumstances where someone might want by-protocol indications of service, rather than the relatively basic link-test that ICMP provides. Another vote for iperf.... Mark. On 23/12/11 08:36, Sean Harlow wrote: > iperf might be able to do what you need and there are Windows builds available, but I'm not sure if it has a mode where it's not flooding the network trying to test maximum speed. Is there a reason that standard ICMP pings aren't appropriate if you just want packet loss info? Obviously every platform worth using has ping built in. > ---------- > Sean Harlow > sean at seanharlow.info > > On Dec 22, 2011, at 2:28 PM, Jay Nakamura wrote: > >> The goal of what I am doing is to test some network convergence impact >> in a lab with two PCs with windows (Can't run Linux, it would be >> easier if I could) and switches and/or routers in between. >> >> So, I thought there must be some simple utility out there that can >> just start spewing out UDP packets to the other side at a certain time >> interval and I can look at packet loss via what arrives on the other >> side with wireshark on the PC. >> >> I found hping but it seems to be outdated and I can't get it to work >> on my windows boxes. >> >> Anyone have any suggestions? >> > From ljb at merit.edu Thu Dec 22 14:20:56 2011 From: ljb at merit.edu (Larry Blunk) Date: Thu, 22 Dec 2011 15:20:56 -0500 Subject: Windows UDP packet generator software? In-Reply-To: <0B377425-F833-4914-BFCC-C2364A4F07BF@seanharlow.info> References: <0B377425-F833-4914-BFCC-C2364A4F07BF@seanharlow.info> Message-ID: <4EF39128.7010109@merit.edu> On 12/22/2011 02:36 PM, Sean Harlow wrote: > iperf might be able to do what you need and there are Windows builds available, but I'm not sure if it has a mode where it's not flooding the network trying to test maximum speed. Is there a reason that standard ICMP pings aren't appropriate if you just want packet loss info? Obviously every platform worth using has ping built in. > ---------- > Sean Harlow > sean at seanharlow.info In UDP mode, iperf sends at 1 Mbps by default. You change the rate with the -b flag. There's an iperf-2.0.5-cygwin build floating around for Windows. From Valdis.Kletnieks at vt.edu Thu Dec 22 14:38:59 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 22 Dec 2011 15:38:59 -0500 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: Your message of "Thu, 22 Dec 2011 21:04:42 +0100." <4EF38D5A.4070003@cis.vutbr.cz> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF38D5A.4070003@cis.vutbr.cz> Message-ID: <9810.1324586339@turing-police.cc.vt.edu> On Thu, 22 Dec 2011 21:04:42 +0100, Tomas Podermanski said: > Well, then how many devices do you have in the network that uses IPv6? 1,300+ wireless access points, 1,100+ switches, 30k+ users, around 55% doing at least some IPv6 traffic (mostly when they hit Google). > Do you have implemented first hop security? What will you do when some > user runs RA flood attack > (http://samsclass.info/ipv6/proj/flood-router6a.htm). "First actual case of a bug being found" -- Lt Cmdr Grace Hopper I've asked around, and although everybody understands it's an issue, the number of people actually *seeing* one of these attacks is... Bueller? Bueller? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From tpoder at cis.vutbr.cz Thu Dec 22 14:46:17 2011 From: tpoder at cis.vutbr.cz (Tomas Podermanski) Date: Thu, 22 Dec 2011 21:46:17 +0100 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <9B747991-09CC-47E2-A245-846C3ABD9005@delong.com> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <9B747991-09CC-47E2-A245-846C3ABD9005@delong.com> Message-ID: <4EF39719.5010802@cis.vutbr.cz> Hi, On 12/22/11 12:18 AM, Owen DeLong wrote: >> The long answer is: >> >> I completely disagree with opinion that both DHCPv6 and RA (SLAAC) >> should be supported. It is easy to say that both have place but it has >> some consequences. I and my colleagues have been working on deploying >> IPv6 for a few years and from the operation perspective we conclude into >> a quite clear opinion in that area. Both SLAAC and DHCPv6 uses a >> opposite principles although the goal is just one. DHCPv6 is based on a >> central DHCPv6 server that assigns addresses. SLAAC does opposite - >> leaves the decision about the address on a client side. However we have >> to run both of them in a network to provide all necessary pieces of >> information to the clients (default route and DNS). This brings many >> implementation and operational complications. >> > I agree that the requirement to run both is broken. I don't agree that this > means we should remove the option of using SLAAC in environments > where it makes sense. > >> - Clients have to support both SLAAC and DHCPv6 to be able to work in >> both environments > So? It makes the client side more difficult to implement (=more expensive). What worse SLAAC and DHCPv6 are differed protocols, so there is bigger probability for attacks (overflow, flood etc.). For example in UNIX-like systems autoconfiguration have to be solved by 3 parts of the system: 1. some SLAAC options are usually processed by a kernel (address selection, MTU) and behavior of that process can be changed via sysctl 2. some SLAAC options are processed by rdnssd daemon (processing DNS options) 3. DHCPv6 options are processed byt dhcpv6-client All those parts have to cooperate together. At the first sight it is obvious that there is pretty good probability that something can go wrong. Troubleshooting then is really piece of cake. For example in IPv4 environment we have following scenario: 1. DHCP options are processed by dhcp-client > >> - There must be solved a situation what to do when SLAAC and DHCPv6 >> provides some conflict information (quite long thread with various >> opinions >> can be found at >> http://www.ietf.org/mail-archive/web/ipv6/current/msg14949.html) > SLAAC and DHCPv6 can't really provide conflicting information unless > the router is misconfigured. Even if a host gets different answers for the > same prefixes from SLAAC and DHCP, it should be able to use both > host addresses. There's the question of source address selection, but, > the answer to that question at the IETF level should only be a matter > of what the default answer is. There are configuration options for setting > host source address selection priorities. I am not thinking about address. It is the easier part - we can use all provided. There are other options like DNS servers, search list, NTP servers, ... > >> - The first hop security have to be solved twice - for SLAAC and for >> DHCPv6. Both >> of then uses a differed communication way. SLAAC is part of ICMPv6, >> but DHCPv6 >> uses "own" UDP communication what does not make things easier. > Solved for SLAAC -- SEND. > Allegedly, there is Secure DHCPv6 for DHCP, but, I haven't seen any > actual implementations yet. Right, very easy to write but pretty difficult (impossible) to use today. None of operating systems supports SEND and some will probably never be: as we can find http://technet.microsoft.com/en-us/library/bb726956.aspx However, Microsoft does not support SEND in any version of Windows. I have found only one implementation for Linux (http://amnesiak.org/NDprotector/) that is not ready for production. So we can not think seriously about SEND today. SEND also brings another set of problems like certificate management, etc., but is a little differed story. > >> - SLAAC is usually processed in a kernel, DHCPv6 is usually run as a >> process in the user space. Diagnostic and troubleshooting is more >> complicated. > That seems like an argument for SLAAC, if anything. > >> - DHCPv6 is currently tied with SLAAC (M,O flags), what means that >> a DHCPv6 client have to wait until some RA message arrives to start DHCPv6 >> discovery. That unnecessary prolongs whole autoconfiguration process. > While I agree with you that the standard is broken in this regard, there is at > least one OS vendor that already violates that rule anyway. >> Some other issues are also described in [1]. >> >> I personally prefer to bury SLAAC once forever for several reasons: >> - In fact SLAAC does nothing more what DHCPv6 can do. > Yes, but, it does it in a much simpler way with a lot less overhead which > can be a benefit in some environments. I have to admit that less overhead is one of benefit of SLAAC. But having experience with DHCP(v4) all devices that we have today (phones, cameras, etc.) do not have a problem to process DHCPv4 packets, so there is no reason why same devices could not do it for DHCPv6. The sensor networks mentioned in one mail before is a very special case of use. I believe SLAAC might be useful there but is not typical case. > >> - SLAAC is quite difficult to secure. One (really only ONE) RA packet >> can destroy >> the IPv6 connection for all clients in a local network just in a few >> milliseconds. > This is what RA-Guard is for and it's quite simple to deploy. SEND makes > it even better, but is a bit more complicated. I can not agree. Access switches usually do not support RA-Guard or IPv6-ACLs. For example looking at Cisco portfolio only 4900, 4500, 6500, 3750 series supports RA-Guard. In HP 54xx, 82xx, 66xx, 35xx series (all with K software). All this series are not suitable (means too expensive) in a role of access switches. What worse RA-Guard can be easily bypassed (http://www.insinuator.net/2011/05/yet-another-update-on-ipv6-security-some-notes-from-the-ipv6-kongress-in-frankfurt/). So even if you buy 3 times more expensive switches it does not help you :-(. As I wrote before - SEND is not an option today. > >> It also happens accidentally by "connection sharing" in Vista, Win7 >> > This is an argument for burying Windows, not an argument for burying > SLAAC. It's not like ICS in IPv4 didn't create rogue DHCP servers. If you > were to bury SLAAC, Micr0$0ft would simply switch to breaking DHCPv6 > instead of breaking SLAAC. > >> (https://openwiki.uninett.no//_media/geantcampus:2011-gn3na3t4-ipv6-gregr.pdf) >> - The full protection against that behavior it's impossible today. >> RA-Guard or >> PACL can be bypassed using extension headers or fragmentation >> (http://www.mh-sec.de/downloads/mh-ipv6_vulnerabilities.pdf) > Yes and no. RA Guard implementations are getting better at addressing > those issues. How that is getting better. Can you provide an example. > >> - With SLAAC is difficult to implement security features like ARP/ND >> protection/inspection, IP source guard/Dynamic lock down, because >> all this techniques are based on a MAC-IP database created during >> a communication with a DHCP server. There are some attempts (ND >> protection, SAVI) >> but it does not provide the same level of security. > Most sites don't need that level of security. I agree there should be a > way to disable SLAAC reliably at a site as a policy matter, but, frankly > the techniques you're talking about come in one of two flavors: > > 1. They dynamically enable the switch to accept packets from > a client, in which case, SLAAC based clients would be blocked > until they registered with DHCP anyway. > or > 2. They don't effectively block an attacker who cobbles his own > address even without SLAAC. > > In the former case, you get the security you want and force DHCP anyway, > so I don't see a problem. In the latter case, you only had the illusion of > security to begin with, so, SLAAC just makes it easy to disillusion you. Agree. The firs option is the answer but you have to have DHCPv6 only environment. > >> - Just the same technique was introduced in IPv4 as Router Discovery >> (RFC 1256). >> Nobody uses it today. Do we really need go through same death way again? >> (Oh right, we are already going :-( ) > Not a fair comparison. There were a number of additional issues with 1256 that > prevented it from gaining acceptance in IPv4. > >> Comparing to SLAAC, DHCPv6 have several advantages: >> - DHCPv6 is very similar to DHCP(v4) and many people are used to using it. > That just makes it familiar, not necessarily better for all environments. > >> - DHCPv6 can potentially do much more - for example handle an information >> for PXE, options for IP phones, prefix delegation. > True, but, that comes at a cost of complexity and overhead which may not be > desirable in all environments. As I wrote before. I do not think that overhead is an issue today. > >> - DHCPv6 allows handle an information only for some hosts or group of >> hosts (differed lease time, search list, DNS atc.). With SLAAC it is >> impossible and all host on a subnet have to share the same set of >> the configuration information. > Which is not an issue in 99+% of environments. > >> - Frankly said, I have not found any significant benefit that SLAAC brings. > Perhaps you have not, but, others have. I have seen environments where > SLAAC is much more useful than DHCPv6. I've seen environments where > DHCPv6 is needed. It is true today, because not all operating systems supports DHCPv6. In many cases DHCPv6 is not an option. > >> Unfortunately there is another issue with DUIDs in DHCPv6. But it is a >> little bit differed tale. >> >> At the beginning the autoconfiguration was meant as easy to use and easy >> to configure but the result turned out into kind of nightmare. For those >> who do not know what I am talking about I prepared two images. The first >> one shows necessary communication before first regular packet can be >> send over IPv4 (http://hawk.cis.vutbr.cz/~tpoder/tmp/autoconf/IPv4.png) >> and just the same thing in IPv6 >> (http://hawk.cis.vutbr.cz/~tpoder/tmp/autoconf/IPv4.png). In IPv4 we >> have very simple answer if somebody asks for autoconfiguration = use >> DHCP. In IPv6 the description how things work have to be written into >> more than 10 pages [1]. I believe that is not what we really wanted. >> > That's no really a fair characterization. Yes, DHCPv6 is more complex > than DHCPv4, but, not significantly so. > > In reality it can be summed up relatively quickly: > > 1. Choose link local address (fe80::EUI64) > 2. Send RS packet to all-routers multicast address > 3. Receive one or more RA packets. > a. if Packet contains prefix information: > i. Set timers, apply addresses to interfaces > (first regular packet can be sent at this point) > b. If packet has O bit set: > i. Send DHCPv6 request to DHCP server > ii. Get response > iii. Configure accordingly. > (If a was false (a and b are not mutually exclusive), then > you can now send your first regular packet). > > Yes, there are a few corner cases not completely addressed above, > but, unless you're building the software to implement the standards, > they are mostly irrelevant. Even if you add them in (interactions between > the M, A, and O bits), you can still describe it in about a page, not > ten. And when we compare it with IPv4 - send DHCP request to DHCP server - get response - configure accordingly No waiting for RA packets, no additional "IFs", no additional conditions and all corner cases are solved. Why it can not work similar in IPv6? I know, there maybe is many reasons :-). Tomas From dougb at dougbarton.us Thu Dec 22 15:33:10 2011 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 22 Dec 2011 13:33:10 -0800 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: <4EF28A00.2080904@kl.net> Message-ID: <4EF3A216.7040006@dougbarton.us> On 12/22/2011 04:48, Glen Kent wrote: >> In many environments RA is a catastrophic disaster. Some operators need >> to be able to do everything with RA turned off on routers, disabled on >> hosts and filtered on switches. > > While in some environments, typically with small number of devices, > its indispensable. Small businesses may not want the complexity of > setting up a central server (for DHCP) - SLAAC works very well in such > environments. Please show me the small businesses that don't already have a DHCP server. Or (equally unlikely) show me the small business whose DHCP server isn't baked into their SOHO router/toaster and works with nearly zero human intervention. > Today, we can get NTP server information only with DHCP (DNS info is > supported by both DHCP and RAs). DHCP only works after RAs have been > processed. In some environments (mobile IPv6) delays in acquiring NTP > and other servers information is critical and waiting for DHCP to come > up may not be acceptable. So clearly the right answer is to make DHCPv6 a superset of RA functionality so that the people who need more than what RA provides only have to run DHCP. Over strenuous objection DNS resolver data was added to RA and the folks over in MIF are just now getting around to sorting out the damage caused by having the same category of information arrive over 2 different configuration protocols with subtly different data. (A 100% foreseen problem that was part of the core of the previously mentioned strenuous objections.) RA was an interesting idea that came to light in an era when DHCP was new, clunky, unreliable, and not widely deployed. None of those things are true anymore, so it would be very helpful if IPv6 deployment planning moved into the 21st Century. Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From jeremyparr at gmail.com Thu Dec 22 15:54:13 2011 From: jeremyparr at gmail.com (Jeremy Parr) Date: Thu, 22 Dec 2011 16:54:13 -0500 Subject: Well Lookie Here, Barracuda Networks tries to get me to fall into their trap again... In-Reply-To: References: <20111221104148.4565907e@jpeach-desktop.anbg.mssm.edu> <1449422.1440.1324490075558.JavaMail.root@benjamin.baylink.com> <8C26A4FDAE599041A13EB499117D3C286B6354A8@ex-mb-1.corp.atlasnetworks.us> <2F1D4FA4-107A-49C4-B5E5-CD40B282B9B2@freethought-internet.co.uk> <4EF3631C.8030600@houseofzen.org> <20111222184745.GA69040@ussenterprise.ufp.org> <4EF37CFF.3020109@mtcc.com> Message-ID: On 22 December 2011 14:07, Jon Lewis wrote: > Presumably, Barracuda's hardware is i386/i686 compatible commodity parts. > It's probably not at all "useless". Just attach a USB DVD drive or USB > flash drive, wipe the disk(s) and install your favorite Linux distro. > It may take some doing to get all/most of the features Barracuda provides > setup on your own...but if you don't have the time/expertise to do it, > that's why companies like Barracuda exist. > The hardware Barracuda charges you a very pretty penny for is very low end. $3000 or so that they charge for a mid-level spam filters gets you a single power supply, single hard disk, and a low end processor. According to their site it does appear they offer the product as VM image. This would eliminate the stupid hardware markup and their attempt at backdating updates. From eesslinger at fpu-tn.com Thu Dec 22 16:49:02 2011 From: eesslinger at fpu-tn.com (Eric J Esslinger) Date: Thu, 22 Dec 2011 16:49:02 -0600 Subject: Well Lookie Here, Barracuda Networks tries to get me to fall into their trap again... In-Reply-To: Message-ID: The vmware image is more expensive than the midrange hardware. (and you pay for how many processors it will use, ram, features like multi domain support, etc...) __________________________ Eric Esslinger Information Services Manager - Fayetteville Public Utilities http://www.fpu-tn.com/ (931)433-1522 ext 165 > -----Original Message----- > From: Jeremy Parr [mailto:jeremyparr at gmail.com] > Sent: Thursday, December 22, 2011 3:54 PM > To: Jon Lewis; nanog at nanog.org > Subject: Re: Well Lookie Here, Barracuda Networks tries to > get me to fall into their trap again... > > > On 22 December 2011 14:07, Jon Lewis wrote: > > > Presumably, Barracuda's hardware is i386/i686 compatible commodity > > parts. It's probably not at all "useless". Just attach a USB DVD > > drive or USB flash drive, wipe the disk(s) and install your > favorite > > Linux distro. It may take some doing to get all/most of the > features > > Barracuda provides setup on your own...but if you don't have the > > time/expertise to do it, that's why companies like Barracuda exist. > > > The hardware Barracuda charges you a very pretty penny for is > very low end. $3000 or so that they charge for a mid-level > spam filters gets you a single power supply, single hard > disk, and a low end processor. > > According to their site it does appear they offer the product > as VM image. This would eliminate the stupid hardware markup > and their attempt at backdating updates. > This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. -------------- next part -------------- A non-text attachment was scrubbed... Name: Eric J Esslinger.vcf Type: text/x-vcard Size: 498 bytes Desc: Eric J Esslinger.vcf URL: From paradox at nac.net Thu Dec 22 17:24:19 2011 From: paradox at nac.net (Ryan Pavely) Date: Thu, 22 Dec 2011 18:24:19 -0500 Subject: Windows UDP packet generator software? In-Reply-To: <4EF39128.7010109@merit.edu> References: <0B377425-F833-4914-BFCC-C2364A4F07BF@seanharlow.info> <4EF39128.7010109@merit.edu> Message-ID: <4EF3BC23.9040603@nac.net> If anyone needs a per-compiled iPerf.exe, no need for cygwin libraries, lemme know. It's a great tool! Ryan Pavely Director Research And Development Net Access Corporation http://www.nac.net/ On 12/22/2011 3:20 PM, Larry Blunk wrote: > On 12/22/2011 02:36 PM, Sean Harlow wrote: >> iperf might be able to do what you need and there are Windows builds >> available, but I'm not sure if it has a mode where it's not flooding >> the network trying to test maximum speed. Is there a reason that >> standard ICMP pings aren't appropriate if you just want packet loss >> info? Obviously every platform worth using has ping built in. >> ---------- >> Sean Harlow >> sean at seanharlow.info > > > In UDP mode, iperf sends at 1 Mbps by default. You change > the rate with the -b flag. There's an iperf-2.0.5-cygwin > build floating around for Windows. From jeroen at mompl.net Thu Dec 22 18:04:12 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Thu, 22 Dec 2011 16:04:12 -0800 Subject: what if...? In-Reply-To: References: <20111220133723.cfjv8g999ssoc8gg@fcaglp.fcaglp.unlp.edu.ar> Message-ID: <4EF3C57C.1010108@mompl.net> Marshall Eubanks wrote: > Does your Mom call you up every time she gets a dialog box complaining > about an invalid certificate ? > > If she has been conditioned just to click "OK" when that happens, then > she probably can't. Everyone I have observed clicks "ok" or "confirm exception" (if I remember the phrase correctly) as soon as possible. Sadly I think only a few security conscious (IT) people will actually think twice and reject it if they don't trust it. That to me proves this aspect ssl is somewhat flawed in that regard. But then I am preaching to the choir. :-) Regards, Jeroen -- Earthquake Magnitude: 4.9 Date: Thursday, December 22, 2011 16:41:15 UTC Location: Tarapaca, Chile Latitude: -19.5358; Longitude: -69.1219 Depth: 95.20 km From mohta at necom830.hpcl.titech.ac.jp Thu Dec 22 18:16:36 2011 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 23 Dec 2011 09:16:36 +0900 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: <4EF28A00.2080904@kl.net> Message-ID: <4EF3C864.60807@necom830.hpcl.titech.ac.jp> Glen Kent wrote: > While in some environments, typically with small number of devices, > its indispensable. Small businesses may not want the complexity of > setting up a central server (for DHCP) - SLAAC works very well in such > environments. IPv6 routers are the central servers for SLAAC with the complexity of setting up. Moreover, SLAAC is stateful in the worst way, because states of address assignments are held unnecessarily distributed way, which is why time and power consuming DAD is considered to be necessary. Just as most, if not all, NAT boxes have preconfigured DHCPv4 service to offer part of preconfigured private address space, home IPv6 routers may have preconfigured DHCPv6 service to offer part of configured public address space. Masataka Ohta From smb at cs.columbia.edu Thu Dec 22 21:13:40 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Thu, 22 Dec 2011 22:13:40 -0500 Subject: what if...? In-Reply-To: <4EF3C57C.1010108@mompl.net> References: <20111220133723.cfjv8g999ssoc8gg@fcaglp.fcaglp.unlp.edu.ar> <4EF3C57C.1010108@mompl.net> Message-ID: <5EFF95C7-AEE6-411C-A06E-FDDC6F5D7D91@cs.columbia.edu> On Dec 22, 2011, at 7:04 PM, Jeroen van Aart wrote: > Marshall Eubanks wrote: >> Does your Mom call you up every time she gets a dialog box complaining >> about an invalid certificate ? >> If she has been conditioned just to click "OK" when that happens, then >> she probably can't. > > Everyone I have observed clicks "ok" or "confirm exception" (if I remember the phrase correctly) as soon as possible. Sadly I think only a few security conscious (IT) people will actually think twice and reject it if they don't trust it. > > That to me proves this aspect ssl is somewhat flawed in that regard. But then I am preaching to the choir. :-) See the definition of "dialog box" at http://www.w3.org/2006/WSC/wiki/Glossary --Steve Bellovin, https://www.cs.columbia.edu/~smb From owen at delong.com Thu Dec 22 21:33:37 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 23 Dec 2011 10:33:37 +0700 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EF39719.5010802@cis.vutbr.cz> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <9B747991-09CC-47E2-A245-846C3ABD9005@delong.com> <4EF39719.5010802@cis.vutbr.cz> Message-ID: Sent from my iPad On Dec 23, 2011, at 3:46 AM, Tomas Podermanski wrote: > Hi, > > On 12/22/11 12:18 AM, Owen DeLong wrote: >>> The long answer is: >>> >>> I completely disagree with opinion that both DHCPv6 and RA (SLAAC) >>> should be supported. It is easy to say that both have place but it has >>> some consequences. I and my colleagues have been working on deploying >>> IPv6 for a few years and from the operation perspective we conclude into >>> a quite clear opinion in that area. Both SLAAC and DHCPv6 uses a >>> opposite principles although the goal is just one. DHCPv6 is based on a >>> central DHCPv6 server that assigns addresses. SLAAC does opposite - >>> leaves the decision about the address on a client side. However we have >>> to run both of them in a network to provide all necessary pieces of >>> information to the clients (default route and DNS). This brings many >>> implementation and operational complications. >>> >> I agree that the requirement to run both is broken. I don't agree that this >> means we should remove the option of using SLAAC in environments >> where it makes sense. >> >>> - Clients have to support both SLAAC and DHCPv6 to be able to work in >>> both environments >> So? > > It makes the client side more difficult to implement (=more expensive). > What worse SLAAC and DHCPv6 are differed protocols, so there is bigger > probability for attacks (overflow, flood etc.). For example in UNIX-like > systems autoconfiguration have to be solved by 3 parts of the system: > > 1. some SLAAC options are usually processed by a kernel (address > selection, MTU) and behavior of that process can be changed via sysctl > 2. some SLAAC options are processed by rdnssd daemon (processing DNS > options) > 3. DHCPv6 options are processed byt dhcpv6-client > > All those parts have to cooperate together. At the first sight it is > obvious that there is pretty good probability that something can go > wrong. Troubleshooting then is really piece of cake. For example in IPv4 > environment we have following scenario: > > 1. DHCP options are processed by dhcp-client Except when they are processed by BIOS, Kernel, or something else. Yeah, the situation there in terms of the number of moving pieces is actually about the same. Even when DHCP options are parsed by dhcp-client, it has to use them to modify the kernel data structures and affect the behavior of other parts of the system, so, there's roughly similar amount of interaction either way. > >> >>> - There must be solved a situation what to do when SLAAC and DHCPv6 >>> provides some conflict information (quite long thread with various >>> opinions >>> can be found at >>> http://www.ietf.org/mail-archive/web/ipv6/current/msg14949.html) >> SLAAC and DHCPv6 can't really provide conflicting information unless >> the router is misconfigured. Even if a host gets different answers for the >> same prefixes from SLAAC and DHCP, it should be able to use both >> host addresses. There's the question of source address selection, but, >> the answer to that question at the IETF level should only be a matter >> of what the default answer is. There are configuration options for setting >> host source address selection priorities. > > I am not thinking about address. It is the easier part - we can use all > provided. There are other options like DNS servers, search list, NTP > servers, ... > If you get DNS servers from RA and from DHCP, throw them all in the candidate DNS server list. Unless something is broken, any one of them should work and provide the same answers as the others. You can't get NTP from SLAAC/RA, so, no conflict there. If the router and dhcp server administrators can't agree on the DNS search list, then, you're going to have some problems no matter what protocol you use, so, I really think this is a tempest in a teacup. >> >>> - The first hop security have to be solved twice - for SLAAC and for >>> DHCPv6. Both >>> of then uses a differed communication way. SLAAC is part of ICMPv6, >>> but DHCPv6 >>> uses "own" UDP communication what does not make things easier. >> Solved for SLAAC -- SEND. >> Allegedly, there is Secure DHCPv6 for DHCP, but, I haven't seen any >> actual implementations yet. > > Right, very easy to write but pretty difficult (impossible) to use > today. None of operating systems supports SEND and some will probably > never be: If there is actual real world demand for it, it will get implemented. Reality is that today, DHCPv4 has been running just as insecure for many years and nobody cares. I don't know why the bar for IPv6 should be so much higher than IPv4. > > as we can find http://technet.microsoft.com/en-us/library/bb726956.aspx > However, Microsoft does not support SEND in any version of Windows. > > I have found only one implementation for Linux > (http://amnesiak.org/NDprotector/) that is not ready for production. So > we can not think seriously about SEND today. SEND also brings another > set of problems like certificate management, etc., but is a little > differed story. > Right. Actual security is hard. No surprise there. Moreover, administrators are lazy. Also no surprise. Limited threat, lazy administrators, hard security, no action. This is the same in IPv4, IPv6, and doesn't really change whether you use SLAAC or DHCP or even static addresses. >> >>> - SLAAC is usually processed in a kernel, DHCPv6 is usually run as a >>> process in the user space. Diagnostic and troubleshooting is more >>> complicated. >> That seems like an argument for SLAAC, if anything. >> >>> - DHCPv6 is currently tied with SLAAC (M,O flags), what means that >>> a DHCPv6 client have to wait until some RA message arrives to start DHCPv6 >>> discovery. That unnecessary prolongs whole autoconfiguration process. >> While I agree with you that the standard is broken in this regard, there is at >> least one OS vendor that already violates that rule anyway. >>> Some other issues are also described in [1]. >>> >>> I personally prefer to bury SLAAC once forever for several reasons: >>> - In fact SLAAC does nothing more what DHCPv6 can do. >> Yes, but, it does it in a much simpler way with a lot less overhead which >> can be a benefit in some environments. > > I have to admit that less overhead is one of benefit of SLAAC. But > having experience with DHCP(v4) all devices that we have today (phones, > cameras, etc.) do not have a problem to process DHCPv4 packets, so there > is no reason why same devices could not do it for DHCPv6. The sensor > networks mentioned in one mail before is a very special case of use. I > believe SLAAC might be useful there but is not typical case. How many RFID sensors do you see managed on an IPv4 network? Thought so. The reality is that IPv6 has to support a much much wider range of hardware and applications than were ever considered for IPv4. Just because these may not apply to your environment does not mean that they are not important to other parts of the world. > >> >>> - SLAAC is quite difficult to secure. One (really only ONE) RA packet >>> can destroy >>> the IPv6 connection for all clients in a local network just in a few >>> milliseconds. >> This is what RA-Guard is for and it's quite simple to deploy. SEND makes >> it even better, but is a bit more complicated. > > I can not agree. Access switches usually do not support RA-Guard or > IPv6-ACLs. For example looking at Cisco portfolio only 4900, 4500, > 6500, 3750 series supports RA-Guard. In HP 54xx, 82xx, 66xx, 35xx series > (all with K software). All this series are not suitable (means too > expensive) in a role of access switches. What worse RA-Guard can be > easily bypassed > (http://www.insinuator.net/2011/05/yet-another-update-on-ipv6-security-some-notes-from-the-ipv6-kongress-in-frankfurt/). > So even if you buy 3 times more expensive switches it does not help you > :-(. As I wrote before - SEND is not an option today. > RA-Guard is in most Juniper switches today. Yes, there are improvements needed. However, it's not like DHCP is immune to spoofing attacks, so, I'm not sure why you think this is so much worse than the current state of IPv4 and/or IPv6 if we went with DHCP only. >> >>> It also happens accidentally by "connection sharing" in Vista, Win7 >>> >> This is an argument for burying Windows, not an argument for burying >> SLAAC. It's not like ICS in IPv4 didn't create rogue DHCP servers. If you >> were to bury SLAAC, Micr0$0ft would simply switch to breaking DHCPv6 >> instead of breaking SLAAC. >> >>> (https://openwiki.uninett.no//_media/geantcampus:2011-gn3na3t4-ipv6-gregr.pdf) >>> - The full protection against that behavior it's impossible today. >>> RA-Guard or >>> PACL can be bypassed using extension headers or fragmentation >>> (http://www.mh-sec.de/downloads/mh-ipv6_vulnerabilities.pdf) >> Yes and no. RA Guard implementations are getting better at addressing >> those issues. > > How that is getting better. Can you provide an example. > No, because some of what I know is currently NDA. However, it's not like vendors aren't hearing about these concerns and it's not like they aren't working to address them. >> >>> - With SLAAC is difficult to implement security features like ARP/ND >>> protection/inspection, IP source guard/Dynamic lock down, because >>> all this techniques are based on a MAC-IP database created during >>> a communication with a DHCP server. There are some attempts (ND >>> protection, SAVI) >>> but it does not provide the same level of security. >> Most sites don't need that level of security. I agree there should be a >> way to disable SLAAC reliably at a site as a policy matter, but, frankly >> the techniques you're talking about come in one of two flavors: >> >> 1. They dynamically enable the switch to accept packets from >> a client, in which case, SLAAC based clients would be blocked >> until they registered with DHCP anyway. >> or >> 2. They don't effectively block an attacker who cobbles his own >> address even without SLAAC. >> >> In the former case, you get the security you want and force DHCP anyway, >> so I don't see a problem. In the latter case, you only had the illusion of >> security to begin with, so, SLAAC just makes it easy to disillusion you. > > Agree. The firs option is the answer but you have to have DHCPv6 only > environment. > But you don't need to eliminate SLAAC from everyone else's network to make that work. There's no need to deprecate SLAAC/RA from places where it works just fine to achieve what you want. That's my point. >> >>> - Just the same technique was introduced in IPv4 as Router Discovery >>> (RFC 1256). >>> Nobody uses it today. Do we really need go through same death way again? >>> (Oh right, we are already going :-( ) >> Not a fair comparison. There were a number of additional issues with 1256 that >> prevented it from gaining acceptance in IPv4. >> >>> Comparing to SLAAC, DHCPv6 have several advantages: >>> - DHCPv6 is very similar to DHCP(v4) and many people are used to using it. >> That just makes it familiar, not necessarily better for all environments. >> >>> - DHCPv6 can potentially do much more - for example handle an information >>> for PXE, options for IP phones, prefix delegation. >> True, but, that comes at a cost of complexity and overhead which may not be >> desirable in all environments. > > As I wrote before. I do not think that overhead is an issue today. > And as I wrote before, I think that comes from a narrow view of the implementation spectrum. >> >>> - DHCPv6 allows handle an information only for some hosts or group of >>> hosts (differed lease time, search list, DNS atc.). With SLAAC it is >>> impossible and all host on a subnet have to share the same set of >>> the configuration information. >> Which is not an issue in 99+% of environments. >> >>> - Frankly said, I have not found any significant benefit that SLAAC brings. >> Perhaps you have not, but, others have. I have seen environments where >> SLAAC is much more useful than DHCPv6. I've seen environments where >> DHCPv6 is needed. > > It is true today, because not all operating systems supports DHCPv6. In > many cases DHCPv6 is not an option. > I have seen environments where even if everything supported DHCPv6, SLAAC would still be a better solution for that environment. That's my point. Administrators should be able to choose the solution that best fits their environment. I'm all for the ability to create a DHCP-only environment, but, I don't want to see SLAAC/RA eliminated from environments where it provides benefit. >> >>> Unfortunately there is another issue with DUIDs in DHCPv6. But it is a >>> little bit differed tale. >>> >>> At the beginning the autoconfiguration was meant as easy to use and easy >>> to configure but the result turned out into kind of nightmare. For those >>> who do not know what I am talking about I prepared two images. The first >>> one shows necessary communication before first regular packet can be >>> send over IPv4 (http://hawk.cis.vutbr.cz/~tpoder/tmp/autoconf/IPv4.png) >>> and just the same thing in IPv6 >>> (http://hawk.cis.vutbr.cz/~tpoder/tmp/autoconf/IPv4.png). In IPv4 we >>> have very simple answer if somebody asks for autoconfiguration = use >>> DHCP. In IPv6 the description how things work have to be written into >>> more than 10 pages [1]. I believe that is not what we really wanted. >>> >> That's no really a fair characterization. Yes, DHCPv6 is more complex >> than DHCPv4, but, not significantly so. >> >> In reality it can be summed up relatively quickly: >> >> 1. Choose link local address (fe80::EUI64) >> 2. Send RS packet to all-routers multicast address >> 3. Receive one or more RA packets. >> a. if Packet contains prefix information: >> i. Set timers, apply addresses to interfaces >> (first regular packet can be sent at this point) >> b. If packet has O bit set: >> i. Send DHCPv6 request to DHCP server >> ii. Get response >> iii. Configure accordingly. >> (If a was false (a and b are not mutually exclusive), then >> you can now send your first regular packet). >> >> Yes, there are a few corner cases not completely addressed above, >> but, unless you're building the software to implement the standards, >> they are mostly irrelevant. Even if you add them in (interactions between >> the M, A, and O bits), you can still describe it in about a page, not >> ten. > > And when we compare it with IPv4 > > - send DHCP request to DHCP server Uh, no. DHCP request is never sent by client to DHCP server. Request is sent to broadcast. Then some magic happens (helper address) in most cases to forward it to the DHCP server, then some more magic happens to get the response back to the original client. > - get response > - configure accordingly > Assuming that the client understands all the correct options, that all the options fit in a single packet, etc., etc., etc. > > No waiting for RA packets, no additional "IFs", no additional conditions > and all corner cases are solved. Why it can not work similar in IPv6? I > know, there maybe is many reasons :-). > Uh, no, there are many corner cases I have encountered where DHCPv4 is a non-option and administrators have had no other choice in IPv4 but to use static addressing. Some of them would actually work just fine with SLAAC. Owen From mohacsi at niif.hu Thu Dec 22 23:56:24 2011 From: mohacsi at niif.hu (Mohacsi Janos) Date: Fri, 23 Dec 2011 06:56:24 +0100 (CET) Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EF23092.9090103@cis.vutbr.cz> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> Message-ID: On Wed, 21 Dec 2011, Tomas Podermanski wrote: > Hi, > > from my perspective the short answer for this never-ending story is: > > - SLAAC/RA is totally useless, does not bring any benefit at all > and should be removed from IPv6 specs > - DHCPv6 should be extended by route options as proposed in > http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-03 > - DHCPv6 should be extended by layer 2 address to identify > client's L2 address (something that we can see in RFC 6221) > - DHCPv6 should be the common way to autoconfigure an address > in a IPv6 environment Your opinion is very extreme. Another extremity would be to add some extension into SLAAC/RA and remove DHCPv6 completely. BUT both mechanisms have their merits. They have to interporate! Every environment should develop their policy according to their needs! > > The long answer is: > > I completely disagree with opinion that both DHCPv6 and RA (SLAAC) > should be supported. It is easy to say that both have place but it has > some consequences. I and my colleagues have been working on deploying > IPv6 for a few years and from the operation perspective we conclude into > a quite clear opinion in that area. Both SLAAC and DHCPv6 uses a > opposite principles although the goal is just one. DHCPv6 is based on a > central DHCPv6 server that assigns addresses. SLAAC does opposite - > leaves the decision about the address on a client side. However we have > to run both of them in a network to provide all necessary pieces of > information to the clients (default route and DNS). This brings many > implementation and operational complications. > > - Clients have to support both SLAAC and DHCPv6 to be able to work in > both environments They already do. If not they have to be fixed. > - There must be solved a situation what to do when SLAAC and DHCPv6 > provides some conflict information (quite long thread with various > opinions > can be found at > http://www.ietf.org/mail-archive/web/ipv6/current/msg14949.html) Administrators are deliberately providing conflicting information? > - The first hop security have to be solved twice - for SLAAC and for > DHCPv6. Both > of then uses a differed communication way. SLAAC is part of ICMPv6, > but DHCPv6 > uses "own" UDP communication what does not make things easier. This can be an argument for remove DHCPv6 completely.... > - SLAAC is usually processed in a kernel, DHCPv6 is usually run as a > process in the user space. Diagnostic and troubleshooting is more > complicated. Some operating system do the SLAAC processing in user space. What is the problem. > - DHCPv6 is currently tied with SLAAC (M,O flags), what means that > a DHCPv6 client have to wait until some RA message arrives to start DHCPv6 > discovery. That unnecessary prolongs whole autoconfiguration process. I think it is matter of implementation. > > Some other issues are also described in [1]. > > I personally prefer to bury SLAAC once forever for several reasons: > - In fact SLAAC does nothing more what DHCPv6 can do. But suitable in certain environments. > - SLAAC is quite difficult to secure. One (really only ONE) RA packet > can destroy > the IPv6 connection for all clients in a local network just in a few > milliseconds. > It also happens accidentally by "connection sharing" in Vista, Win7 > > (https://openwiki.uninett.no//_media/geantcampus:2011-gn3na3t4-ipv6-gregr.pdf) Their is an RAguard RFC to prevent this. > - The full protection against that behavior it's impossible today. > RA-Guard or > PACL can be bypassed using extension headers or fragmentation > (http://www.mh-sec.de/downloads/mh-ipv6_vulnerabilities.pdf) For solution See propoosal of Fernando Gont about atomic ICMPv6 messages. > - With SLAAC is difficult to implement security features like ARP/ND > protection/inspection, IP source guard/Dynamic lock down, because > all this techniques are based on a MAC-IP database created during > a communication with a DHCP server. There are some attempts (ND > protection, SAVI) > but it does not provide the same level of security. What is missing? > - Just the same technique was introduced in IPv4 as Router Discovery > (RFC 1256). > Nobody uses it today. Do we really need go through same death way again? > (Oh right, we are already going :-( ) > Nobody? Every modern Windows OS. > Comparing to SLAAC, DHCPv6 have several advantages: > - DHCPv6 is very similar to DHCP(v4) and many people are used to using it. > - DHCPv6 can potentially do much more - for example handle an information > for PXE, options for IP phones, prefix delegation. > - DHCPv6 allows handle an information only for some hosts or group of > hosts (differed lease time, search list, DNS atc.). With SLAAC it is > impossible and all host on a subnet have to share the same set of > the configuration information. RA is just matter of swtiching on first hop router. You don't have to configure anything. > - Frankly said, I have not found any significant benefit that SLAAC brings. Configuration of thousands of device without much overhead on server side? > > Unfortunately there is another issue with DUIDs in DHCPv6. But it is a > little bit differed tale. It is a big issue. > > At the beginning the autoconfiguration was meant as easy to use and easy > to configure but the result turned out into kind of nightmare. For those > who do not know what I am talking about I prepared two images. The first > one shows necessary communication before first regular packet can be > send over IPv4 (http://hawk.cis.vutbr.cz/~tpoder/tmp/autoconf/IPv4.png) > and just the same thing in IPv6 > (http://hawk.cis.vutbr.cz/~tpoder/tmp/autoconf/IPv4.png). In IPv4 we > have very simple answer if somebody asks for autoconfiguration = use > DHCP. In IPv6 the description how things work have to be written into > more than 10 pages [1]. I believe that is not what we really wanted. > > For those who are interested in that area there are several > articles/presentations where we mentioned that topic. > > [1] IPv6 Autoconfiguration - Best Practice Document > http://www.terena.org/activities/campus-bp/pdf/gn3-na3-t4-cbpd117.pdf > It is written very badly! It has to be completed by results from: http://openwiki.uninett.no/_media/geantcampus:2011-gn3na3t4-ipv6-mohacsi.pdf > [2] IPv6 - security threads > http://www.fit.vutbr.cz/research/view_pub.php?id=9835 > > [3] Deploying IPv6 in University Campus Network - Practical Problems > http://www.fit.vutbr.cz/research/view_pub.php?id=9836 > Best Regards, Janos Mohacsi > > Regards, > Tomas Podermanski > > > > On 12/20/11 8:31 AM, Owen DeLong wrote: >> Different operators will have different preferences in different environments. >> >> Ideally, the IETF should provide complete solutions based on DHCPv6 and >> on RA and let the operators decide what they want to use in their environments. >> >> Owen >> >> On Dec 19, 2011, at 10:27 PM, Ravi Duggal wrote: >> >>> Hi, >>> >>> IPv6 devices (routers and hosts) can obtain configuration information >>> about default routers, on-link prefixes and addresses from Router >>> Advertisements as defined in Neighbor Discovery. I have been told >>> that in some deployments, there is a strong desire not to use Router >>> Advertisements at all and to perform all configuration via DHCPv6. >>> There are thus similar IETF standards to get everything that you can >>> get from RAs, by using DHCPv6 instead. >>> >>> As a result of this we see new proposals in IETF that try to do >>> similar things by either extending RA mechanisms or by introducing new >>> options in DHCPv6. >>> >>> We thus have draft-droms-dhc-dhcpv6-default-router-00 that extends >>> DHCPv6 to do what RA does. And now, we have >>> draft-bcd-6man-ntp-server-ra-opt-00.txt that extends RA to advertise >>> the NTP information that is currently done via DHCPv6. >>> >>> My question is, that which then is the more preferred option for the >>> operators? Do they prefer extending RA so that the new information >>> loaded on top of the RA messages gets known in the single shot when >>> routers do neighbor discovery. Or do they prefer all the extra >>> information to be learnt via DHCPv6? What are the pros and cons in >>> each approach and when would people favor one over the other? >>> >>> I can see some advantages with the loading information to RA since >>> then one is not dependent on the DHCPv6 server. However, the latter >>> provides its own benefits. >>> >>> Regards, >>> Ravi D. >> > > > From mohacsi at niif.hu Fri Dec 23 00:03:34 2011 From: mohacsi at niif.hu (Mohacsi Janos) Date: Fri, 23 Dec 2011 07:03:34 +0100 (CET) Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EF38E78.7050504@cis.vutbr.cz> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF2661A.4050408@rancid.berkeley.edu> <4EF38E78.7050504@cis.vutbr.cz> Message-ID: On Thu, 22 Dec 2011, Tomas Podermanski wrote: > Hi, > > On 12/22/11 12:04 AM, Michael Sinatra wrote: >> On 12/21/11 12:40, Ray Soucy wrote: >>> I'm afraid you're about 10 years too late for this opinion to make >>> much difference. ;-) >>> >>> We have been running IPv6 in production for several years (2008) as >>> well (answering this email over IPv6 now, actually) yet I have >>> completely different conclusions about the role of RA and DHCPv6. >>> Weird. >> >> And that's a very good reason not to deprecate SLAAC. Tomas may >> prefer DHCPv6, and he may provide reasons others may prefer DHCPv6. >> But he hasn't provided justification for deprecating SLAAC. > I am not against SLAAC. I am against the way how DHCPv6 & SLAAC works > today. Today, SLAAC can not live without DHCPv6 and DHCPv6 can not live > without SLAAC (RA). Second reason is that we have two > protocols/techniques to do just the same thing. I prefer to have just > ONE common autoconfiguration method as we have it in IPv4. Because > DHCPv6 is more complex and SLAAC can provide only subset of DHCP > functionality I personaly prefer DHCPv6. This is your personal preference. Some has other personal preference. > >> >> Many of us have been working with IPv6 for years and have found SLAAC >> to be quite useful. The biggest benefit it provides, which Tomas did >> not acknowledge, is the ability to autoconfigure hosts without running >> a central server. That said, I have also found DHCPv6 to be quite >> useful. > > We have to use SLAAC as well because we do not have other choice. Not > all operating systems supports DHCPv6 today. But we are not happy about > it (problems with privacy extensions, security as I mentioned before). > > DHCPv6 do not have to be run on a central server. DHCPv6 can be > implemented as a part of a router as well. It is common for DHCP(v4) an > implementations for DHCPv6 are available today (eg. cisco > http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-dhcp.html). Similar configuration o routers: - enabling ipv6 relay agent -> DHCPv6 configuration - enabling router advertisment on interace -> SLAAC (some routers has to oppposite) > >> >> I also agree with Owen: Provide two complete solutions, and let >> operators choose based on their needs. That implies fixing DHCPv6 so >> I don't have to go in and disable the autonomous flag on my routers >> and run RAs just to get a default route. But it also implies not >> deprecating either SLAAC or DHCPv6. > > Although we have differed opinion whether we need one or two > autoconfiguration protocols, I totally agree that "fixing" DHCPv6 is a > really necessary step and It should have been done many years ago. > > Btw. not all people agree that DHCPv6 should be fixed in that way. There > was a discussion in 2009 in dhcwg (thread available on: > http://www.ietf.org/mail-archive/web/dhcwg/current/msg09715.html). The > current draft (draft-ietf-mif-dhcpv6-route-option-03) is the 3rd > attempt to do it. In past, there were another two drafts trying to > introduce route information into DHCPv6: > > draft-droms-dhc-dhcpv6-default-router-00, expired September 2009 > draft-dec-dhcpv6-route-option-05, expired April 2011 > > So I hope that this time we will have more luck :-) I am also supporting this.... > > > Tomas > > > From mohacsi at niif.hu Fri Dec 23 00:07:29 2011 From: mohacsi at niif.hu (Mohacsi Janos) Date: Fri, 23 Dec 2011 07:07:29 +0100 (CET) Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EF38D5A.4070003@cis.vutbr.cz> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF38D5A.4070003@cis.vutbr.cz> Message-ID: On Thu, 22 Dec 2011, Tomas Podermanski wrote: > Hi, > > On 12/21/11 9:40 PM, Ray Soucy wrote: >> I'm afraid you're about 10 years too late for this opinion to make >> much difference. ;-) > > My opinion is that there is never too late to make thinks easier to > implement and operate, specially in situation when things are > unnecessary complicated. I do not hide that my opinion about SLAAC might > look extreme but I have wrote my reasons for that. I do not expect that > anything will be changed but the fact that I can see discussion about > that topic approximately 2 or 3 times per month (v6ops, dhcwg, ipv6, > ...) and that shows that this problem is pain for many people/ISP. Have > you ever seen similar discussion related to DHCP(v4). I have not, > because there nothing to discuss about. It just works. It works in > simple and logical way. > >> >> We have been running IPv6 in production for several years (2008) as >> well (answering this email over IPv6 now, actually) yet I have >> completely different conclusions about the role of RA and DHCPv6. >> Weird. > > Well, then how many devices do you have in the network that uses IPv6? > Do you have implemented first hop security? What will you do when some > user runs RA flood attack > (http://samsclass.info/ipv6/proj/flood-router6a.htm). What will you do > when some user runs NDP Table Exhaustion Attack > (http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf) ? It is quite easy > to bring IPv6 into a server subnet or a small office network. Providing > stable and secure connectivity into the network with thousands of access > port for the paying customers/users is really a serious issue today. This is implementation issue. Has to be fixed. Or your have to think about port-security.... > > I am very interested how the sites with similar number of access ports > (users/customers) solve that problems. If users are not seperated by interfaces you can see similar issues in IPv4 (spoofing attacks).... > I can see that many ISPs prefer > to solve that by blocking whole IPv6 traffic instead. But it does not > look as a good strategy for deploying IPv6 :-(. > > Tomas > >> >> On Wed, Dec 21, 2011 at 2:16 PM, Tomas Podermanski wrote: >>> Hi, >>> >>> from my perspective the short answer for this never-ending story is: >>> >>> - SLAAC/RA is totally useless, does not bring any benefit at all >>> and should be removed from IPv6 specs >>> - DHCPv6 should be extended by route options as proposed in >>> http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-03 >>> - DHCPv6 should be extended by layer 2 address to identify >>> client's L2 address (something that we can see in RFC 6221) >>> - DHCPv6 should be the common way to autoconfigure an address >>> in a IPv6 environment >>> >>> The long answer is: >>> >>> I completely disagree with opinion that both DHCPv6 and RA (SLAAC) >>> should be supported. It is easy to say that both have place but it has >>> some consequences. I and my colleagues have been working on deploying >>> IPv6 for a few years and from the operation perspective we conclude into >>> a quite clear opinion in that area. Both SLAAC and DHCPv6 uses a >>> opposite principles although the goal is just one. DHCPv6 is based on a >>> central DHCPv6 server that assigns addresses. SLAAC does opposite - >>> leaves the decision about the address on a client side. However we have >>> to run both of them in a network to provide all necessary pieces of >>> information to the clients (default route and DNS). This brings many >>> implementation and operational complications. >>> >>> - Clients have to support both SLAAC and DHCPv6 to be able to work in >>> both environments >>> - There must be solved a situation what to do when SLAAC and DHCPv6 >>> provides some conflict information (quite long thread with various >>> opinions >>> can be found at >>> http://www.ietf.org/mail-archive/web/ipv6/current/msg14949.html) >>> - The first hop security have to be solved twice - for SLAAC and for >>> DHCPv6. Both >>> of then uses a differed communication way. SLAAC is part of ICMPv6, >>> but DHCPv6 >>> uses "own" UDP communication what does not make things easier. >>> - SLAAC is usually processed in a kernel, DHCPv6 is usually run as a >>> process in the user space. Diagnostic and troubleshooting is more >>> complicated. >>> - DHCPv6 is currently tied with SLAAC (M,O flags), what means that >>> a DHCPv6 client have to wait until some RA message arrives to start DHCPv6 >>> discovery. That unnecessary prolongs whole autoconfiguration process. >>> >>> Some other issues are also described in [1]. >>> >>> I personally prefer to bury SLAAC once forever for several reasons: >>> - In fact SLAAC does nothing more what DHCPv6 can do. >>> - SLAAC is quite difficult to secure. One (really only ONE) RA packet >>> can destroy >>> the IPv6 connection for all clients in a local network just in a few >>> milliseconds. >>> It also happens accidentally by "connection sharing" in Vista, Win7 >>> >>> (https://openwiki.uninett.no//_media/geantcampus:2011-gn3na3t4-ipv6-gregr.pdf) >>> - The full protection against that behavior it's impossible today. >>> RA-Guard or >>> PACL can be bypassed using extension headers or fragmentation >>> (http://www.mh-sec.de/downloads/mh-ipv6_vulnerabilities.pdf) >>> - With SLAAC is difficult to implement security features like ARP/ND >>> protection/inspection, IP source guard/Dynamic lock down, because >>> all this techniques are based on a MAC-IP database created during >>> a communication with a DHCP server. There are some attempts (ND >>> protection, SAVI) >>> but it does not provide the same level of security. >>> - Just the same technique was introduced in IPv4 as Router Discovery >>> (RFC 1256). >>> Nobody uses it today. Do we really need go through same death way again? >>> (Oh right, we are already going :-( ) >>> >>> Comparing to SLAAC, DHCPv6 have several advantages: >>> - DHCPv6 is very similar to DHCP(v4) and many people are used to using it. >>> - DHCPv6 can potentially do much more - for example handle an information >>> for PXE, options for IP phones, prefix delegation. >>> - DHCPv6 allows handle an information only for some hosts or group of >>> hosts (differed lease time, search list, DNS atc.). With SLAAC it is >>> impossible and all host on a subnet have to share the same set of >>> the configuration information. >>> - Frankly said, I have not found any significant benefit that SLAAC brings. >>> >>> Unfortunately there is another issue with DUIDs in DHCPv6. But it is a >>> little bit differed tale. >>> >>> At the beginning the autoconfiguration was meant as easy to use and easy >>> to configure but the result turned out into kind of nightmare. For those >>> who do not know what I am talking about I prepared two images. The first >>> one shows necessary communication before first regular packet can be >>> send over IPv4 (http://hawk.cis.vutbr.cz/~tpoder/tmp/autoconf/IPv4.png) >>> and just the same thing in IPv6 >>> (http://hawk.cis.vutbr.cz/~tpoder/tmp/autoconf/IPv4.png). In IPv4 we >>> have very simple answer if somebody asks for autoconfiguration = use >>> DHCP. In IPv6 the description how things work have to be written into >>> more than 10 pages [1]. I believe that is not what we really wanted. >>> >>> For those who are interested in that area there are several >>> articles/presentations where we mentioned that topic. >>> >>> [1] IPv6 Autoconfiguration - Best Practice Document >>> http://www.terena.org/activities/campus-bp/pdf/gn3-na3-t4-cbpd117.pdf >>> >>> [2] IPv6 - security threads >>> http://www.fit.vutbr.cz/research/view_pub.php?id=9835 >>> >>> [3] Deploying IPv6 in University Campus Network - Practical Problems >>> http://www.fit.vutbr.cz/research/view_pub.php?id=9836 >>> >>> >>> Regards, >>> Tomas Podermanski >>> >>> >>> >>> On 12/20/11 8:31 AM, Owen DeLong wrote: >>>> Different operators will have different preferences in different environments. >>>> >>>> Ideally, the IETF should provide complete solutions based on DHCPv6 and >>>> on RA and let the operators decide what they want to use in their environments. >>>> >>>> Owen >>>> >>>> On Dec 19, 2011, at 10:27 PM, Ravi Duggal wrote: >>>> >>>>> Hi, >>>>> >>>>> IPv6 devices (routers and hosts) can obtain configuration information >>>>> about default routers, on-link prefixes and addresses from Router >>>>> Advertisements as defined in Neighbor Discovery. I have been told >>>>> that in some deployments, there is a strong desire not to use Router >>>>> Advertisements at all and to perform all configuration via DHCPv6. >>>>> There are thus similar IETF standards to get everything that you can >>>>> get from RAs, by using DHCPv6 instead. >>>>> >>>>> As a result of this we see new proposals in IETF that try to do >>>>> similar things by either extending RA mechanisms or by introducing new >>>>> options in DHCPv6. >>>>> >>>>> We thus have draft-droms-dhc-dhcpv6-default-router-00 that extends >>>>> DHCPv6 to do what RA does. And now, we have >>>>> draft-bcd-6man-ntp-server-ra-opt-00.txt that extends RA to advertise >>>>> the NTP information that is currently done via DHCPv6. >>>>> >>>>> My question is, that which then is the more preferred option for the >>>>> operators? Do they prefer extending RA so that the new information >>>>> loaded on top of the RA messages gets known in the single shot when >>>>> routers do neighbor discovery. Or do they prefer all the extra >>>>> information to be learnt via DHCPv6? What are the pros and cons in >>>>> each approach and when would people favor one over the other? >>>>> >>>>> I can see some advantages with the loading information to RA since >>>>> then one is not dependent on the DHCPv6 server. However, the latter >>>>> provides its own benefits. >>>>> >>>>> Regards, >>>>> Ravi D. >>> >> >> > > > From mysidia at gmail.com Fri Dec 23 00:11:38 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 23 Dec 2011 00:11:38 -0600 Subject: Well Lookie Here, Barracuda Networks tries to get me to fall into their trap again... In-Reply-To: <1449422.1440.1324490075558.JavaMail.root@benjamin.baylink.com> References: <20111221104148.4565907e@jpeach-desktop.anbg.mssm.edu> <1449422.1440.1324490075558.JavaMail.root@benjamin.baylink.com> Message-ID: On Wed, Dec 21, 2011 at 11:54 AM, Jay Ashworth wrote: Leveraging a superior bargaining position to achieve more revenue from a kind of high-risk customer doesn't sound "dishonest".... it sounds rational. Why would an agreement be denominated as "1 year maintenance" if it could simply be reinstated at will? What is meant by high-risk, is a customer inclined to renew maintenance, only at the moment that a lot of services are to be required all at once -- for example, just before a major software upgrade, likely followed by a slew of support incidents, possibly at a cost to the software vendor above the fee. I guess the networking equivalent is --- you stop paying for your OC3 with $BIG_TELCO for a few months, and you get it turned off, but for some reason the physical cabling isn't physically removed. A few months later, you decide you need an OC3 again and exclaim the unfairness of $BIG_TELCO informing you that a fee is required to re-install the OC3 they haven't removed yet. How unfair right... many thousands of $$ just to flip a switch? One chose to go without service for a few months, therefore should get a lower total cost, based on the new renewal date, right? In fact, it's not. If you miss your renewal payment for, frex, Safari > books, > they actually slip your cycle date to when you renew -- since you don't > *get* > It's a standard practice for _Software_ _Maintenance_ agreements; where a product is purchased, with an annual charge for updates, support, sometimes warranty, and other services for that product. If you let the agreement lapse, usually no warranty. Most extended warranties can't be renewed 6 months after they lapsed, because you found the product just broke and you would like to renew a warranty, so you can RMA it for a repair/replacement. Safari books is not a software maintenance agreement; it's a subscription service, and they allow members of the public to start a subscription any time, the cost to renew's basically equivalent to the cost to sign up; it's not as if there is a higher price for new subs. But, effectively, he's a new client, and should probably be treated that > way. > Yes. Software maintenance / subscription update services are not usually sold to just anyone on the street; they are normally sold with software. If you allowed your maintenance agreement to lapse, then You may now be in a position to negotiate a new agreement, but this most likely consists of asking what costs/terms are available for re-upping the maintenance, and having to accept in order to re-up. This likely means one of these scenarios... 1 o One time upgrade fee 2 o Pay delinquent maintenance bills, and then renew from anniversary date. 3 o Have to re-purchase product at brand new product cost, no 'upgrade' discount, since maintenance lapsed. (1) and (2) are most popular ways vendors offer to redeem expired maintenance. (3) Is not dishonest. It is the simplest thing to do, and justifiable if the product's price is low. One-time upgrade fee is very common with consumer software. When you buy "Windows 95" retail, you don't even pay an annual maintenance for free lifetime upgrades. Chances are you buy each upgrade, or get forced into (3), since Windows' cost is basically built into each new computer nowadays. But imagine if no computers came with windows.. and Microsoft offered you $25 a year for annual maintenance, for your Windows '95, and issued a new release every 2 years. If you allowed your maintenance to lapse in 1995, and then decided to renew in 2011... do you really think a reasonable software vendor would give you the 1 year windows '95 maintenance re-activation for $25 and the free upgrade to Windows 7? Nope... chances are you'd to pay $150+ before the vendor would consider re-upping that. -- -JH From rps at maine.edu Fri Dec 23 00:48:37 2011 From: rps at maine.edu (Ray Soucy) Date: Fri, 23 Dec 2011 01:48:37 -0500 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EF38D5A.4070003@cis.vutbr.cz> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF38D5A.4070003@cis.vutbr.cz> Message-ID: On Thu, Dec 22, 2011 at 3:04 PM, Tomas Podermanski wrote: > Well, then how many devices do you have in the network that uses IPv6? Good question, and I applaud you for wanting to verify that people talking about IPv6 have legitimate experience deploying it. I dug into the database I log all IPv6 traffic into. We have 8,509 active hosts using IPv6, that's in comparison to 35,229 on the IPv4 side, so about 24% (mind you, this is only the LAN networks we manage, we provide IPv6 transit to other entities as the regional R&E network). At this point over 95% of IPv4 LAN networks have IPv6 available, wireless is still a challenge (which is a big part of the difference between the host numbers you see above). We participate in Google's trusted IPv6 program, so Google announces AAAA's to us for nearly all their services, so a significant amount of bandwidth is actually over IPv6. I would say that Google does make up the majority of IPv6 traffic though; there isn't much else out there announcing AAAA's yet. We have always taken the approach that IPv6 isn't ready to be deployed if you can't do so while maintaining the same standards you have for IPv4 in the areas of manageability, security, availability, and stability. And we literally spent a few years modifying internal systems (and implementing new ones) to support IPv6 before we started making it available. See http://reports.informationweek.com/abstract/19/2233/Network-Infrastructure/strategy-session-ipv6.html for the case I've been making the last few years, or listen to me (and others) talking a little about it on Cisco's Higher Education webcast series http://www.cisco.com/web/strategy/education/us_education/webcasts.html > Do you have implemented first hop ?security? What will you do when some > user runs RA flood attack You can hear me talk a little about that in the Cisco webcast. Right now we maintain a PACL on our switches that filter RA or DHCPv6 server traffic originating from access ports. As you mentioned it doesn't protect against malicious attempts to disrupt services on the network (fragmented packets) but it does add a reasonable level of stability (e.g. prevent Windows ICS) to levels that are similar to IPv4. In addition, we have a process that monitors our routers for new RAs on the network, and alerts us to that (which would let us respond to a malicious RA that got past the PACL). For neighbor table exhaustion, I've written a set of scripts that I can use in a lab environment to perform the attacks against the platforms we use, and test how they fair. There is a pretty wide range of results. Most of the larger platforms that are the ones we would be concerned about actually hit CPU limitations before neighbor table exhaustion is accomplished, mainly because the neighbor discovery process doesn't appear to be implemented in hardware. It doesn't take much to pull off the attack either; a handful of residential connections would do the trick. This isn't an IPv6 problem so much as a vendor implementation problem, though. Like most DoS and DDoS attack vectors, vendors will need to take extra steps to harden equipment against these attack vectors as they become aware of them. Until vendors catch up (and that includes us having the funds to upgrade to new platforms that do a better job with it), we have opt'd to make use of longer prefixes than 64-bit (in fact we mirror the capacity of the IPv4 prefix; so a /24 in IPv4 would be a /120 in IPv6). A good description of this is available in some slides by Jeff Wheeler at http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf While your mileage may vary with longer prefixes, with the same attacks we saw the impact on CPU usage to be less than half when longer prefixes were used, and that's pretty good. You can also keep external attacks from reaching internal routers if you don't do route summarization internally, which sees considerable gains, as more of that logic appears to be in hardware. On the deployment side, we make use of DHCPv6 and RA with M and O set, and A unset. Our DHCPv6 servers only hand out IPv6 addresses to registered systems that are in the database and have been flagged as OK for IPv6. This has allowed us to roll out IPv6 on a host-by-host basis, rather than a network-wide basis (as you would need to do with SLAAC). This does have the consequence of excluding hosts from IPv6, piticurally Windows XP systems, and pre-Lion OS X systems. But since IPv6 isn't "required" yet (there is really no IPv6-only content yet), we take the position that we only provide IPv6 to systems that support DHCPv6 and have an adequate IPv6 host-level firewall as part of their IPv6 implementation. This makes it easy to exclude hosts that might be problematic to deliver IPv6 to, due to lack of security, or even bugs (RHEL 3 can kernel panic when connected to over IPv6, for example). It also keeps the pressure on to upgrade legacy systems. Wireless is an area we would really like to move forward with IPv6, but we still have concerns that need to be addressed before that can happen. In a Cisco environment, like ours, for example. IPv6 requires Ethernet Mode Multicast to be enabled on the WLAN. Unfortunately it doesn't provide tools to filter which multicast traffic is permitted, and at the scale we deploy wireless it just isn't practical. We might be able to re-architect wireless to better handle this, but that's a future project. I think the big picture here is that IPv6 isn't as "easy" as it should be for large deployments just yet, but that's the case with any new technology. The more people who begin to work through it, the more we will identify problems, and work to resolve them. The almost religious debate of RA vs DHCPv6 gets a lot of attention, but there are much more important issues in my view; like making sure our routers and switches provide the functionality we want them to, and this is an argument that takes away from that. Over 10 years of implementation for IPv6, both RA and DHCPv6 work nicely, well enough that they are reasonably functional and flexible. We can look to enhance them, but that will take another 10 years to wait for implementations to be updated (and then users to upgrade). I would much rather focus the energy of this list to things like neighbor table exhaustion, RA guard, etc. and getting vendors to understand the importance of addressing these concerns. It's a lot easier to upgrade one router than a thousand hosts. Furthermore, DHCPv6 "Other Only" implementations are trivial if you want to use SLAAC for DNS, and most routers already support it. DHCPv6 may not be the only option for DNS in a few years. Things from the ZEROCONF WG like multicast DNS for example (or even an anycast DNS standard) will more than likely come into play, allowing SLAAC without DNS information or DHCPv6 to function just fine on its own. IPv6 is also designed to last quite a while. We might not always be using DNS, something better might come a long, and keeping that out of RA would be my personal preference. But options are always good, and I have no problem adding DNS to RA and route information to DHCPv6; just understand that even if we do get these implemented, you won't be able to use them as a standard for another 5 years at minimum; it would be nice to see IPv6 adoption not be held up over re-designing something that already gets the job done. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From mmzinyi at yahoo.com Fri Dec 23 03:18:40 2011 From: mmzinyi at yahoo.com (jacob miller) Date: Fri, 23 Dec 2011 01:18:40 -0800 (PST) Subject: Speed Test Results Message-ID: <1324631920.7845.YahooMailNeo@web39508.mail.mud.yahoo.com> Hi, Am having a debate on the results of speed tests sites. Am interested in knowing the thoughts of different individuals in regards to this. Regards, Jacob From leigh.porter at ukbroadband.com Fri Dec 23 03:23:26 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Fri, 23 Dec 2011 09:23:26 +0000 Subject: Speed Test Results In-Reply-To: <1324631920.7845.YahooMailNeo@web39508.mail.mud.yahoo.com> References: <1324631920.7845.YahooMailNeo@web39508.mail.mud.yahoo.com> Message-ID: <725D3716-AAF5-4A4D-A4E5-C67E0811C850@ukbroadband.com> They are completely unreliable and not to be trusted except for an occasional general indication of speed. -- Leigh Porter On 23 Dec 2011, at 09:20, "jacob miller" wrote: > Hi, > > Am having a debate on the results of speed tests sites. > > Am interested in knowing the thoughts of different individuals in regards to this. > > Regards, > Jacob > > > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From glen.kent at gmail.com Fri Dec 23 03:24:46 2011 From: glen.kent at gmail.com (Glen Kent) Date: Fri, 23 Dec 2011 14:54:46 +0530 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <9B747991-09CC-47E2-A245-846C3ABD9005@delong.com> <4EF39719.5010802@cis.vutbr.cz> Message-ID: >> > > If you get DNS servers from RA and from DHCP, throw them all in the candidate DNS server list. Unless something is broken, any one of them should work and provide the same answers as the others. > > You can't get NTP from SLAAC/RA, so, no conflict there. If the router and dhcp server administrators can't agree on the DNS search list, then, you're going to have some problems no matter what protocol you use, so, I really think this is a tempest in a teacup. You can get NTP from RA http://tools.ietf.org/html/draft-bcd-6man-ntp-server-ra-opt-00 From rtrim at gmx.com Fri Dec 23 06:04:49 2011 From: rtrim at gmx.com (Ruben Tripiana Martin) Date: Fri, 23 Dec 2011 13:04:49 +0100 Subject: =?utf-8?Q?MPLS_IPVPN_=E2=80=9Cpipe_mode=E2=80=9D_tunneling?= Message-ID: <20111223120449.55960@gmx.com> Hi all First of all I'm new to this list, so although I've checked the Mailing list FAQs, I apologize if my post is not appropriate. I decided to post these questions here as I think is one of the biggest networks engineering communities, and therefore with the biggest gained experience... and the questions are basically about that... experience. To get to the point, my questions are: Does anyone have any input regarding if a majority of global carriers offers ?pipe mode? tunneling as regular feature in their MPLS IP-VPN services? According to your experience do you feel is fairly common? Thanks a lot in advance Ruben Tripiana From bclark at spectraaccess.com Fri Dec 23 06:31:34 2011 From: bclark at spectraaccess.com (Bret Clark) Date: Fri, 23 Dec 2011 07:31:34 -0500 Subject: Speed Test Results In-Reply-To: <725D3716-AAF5-4A4D-A4E5-C67E0811C850@ukbroadband.com> References: <1324631920.7845.YahooMailNeo@web39508.mail.mud.yahoo.com> <725D3716-AAF5-4A4D-A4E5-C67E0811C850@ukbroadband.com> Message-ID: <4EF474A6.8050005@spectraaccess.com> Couldn't agree more, it's unfortunate that so many users take them as gospel! On 12/23/2011 04:23 AM, Leigh Porter wrote: > They are completely unreliable and not to be trusted except for an occasional general indication of speed. > > From jmaimon at ttec.com Fri Dec 23 06:45:39 2011 From: jmaimon at ttec.com (Joe Maimon) Date: Fri, 23 Dec 2011 07:45:39 -0500 Subject: Speed Test Results In-Reply-To: <725D3716-AAF5-4A4D-A4E5-C67E0811C850@ukbroadband.com> References: <1324631920.7845.YahooMailNeo@web39508.mail.mud.yahoo.com> <725D3716-AAF5-4A4D-A4E5-C67E0811C850@ukbroadband.com> Message-ID: <4EF477F3.9050708@ttec.com> They are very useful for like-for-like comparison, for an indication of where your minimum performance levels are probably at, for a quick check that things are working properly and as expected. To determine the exact max effective speed? To test qos policies? To determine whether you are meeting SLA's? Not so much. Joe Leigh Porter wrote: > > They are completely unreliable and not to be trusted except for an occasional general indication of speed. > > From paul at paulstewart.org Fri Dec 23 07:07:58 2011 From: paul at paulstewart.org (Paul Stewart) Date: Fri, 23 Dec 2011 08:07:58 -0500 Subject: Speed Test Results In-Reply-To: <1324631920.7845.YahooMailNeo@web39508.mail.mud.yahoo.com> References: <1324631920.7845.YahooMailNeo@web39508.mail.mud.yahoo.com> Message-ID: <005301ccc173$e6e6ffc0$b4b4ff40$@paulstewart.org> In my opinion they are only "somewhat reliable" if they are on your network or very close to your network -we operate one of the speedtest.net sites and for our own eyeball traffic find it to be a "reasonable indicator" of what kind of speeds the customer is getting. To put it a different way, if a customer is getting 20X1 Internet service and the speedtest shows 17 X 0.8 then case closed - if they are getting a speedtest result of 5 X 0.5 then our helpdesk will take a further look - this is really in rough terms... Paul -----Original Message----- From: jacob miller [mailto:mmzinyi at yahoo.com] Sent: Friday, December 23, 2011 4:19 AM To: nanog at nanog.org Subject: Speed Test Results Hi, Am having a debate on the results of speed tests sites. Am interested in knowing the thoughts of different individuals in regards to this. Regards, Jacob From tate at baumrucker.org Fri Dec 23 07:41:59 2011 From: tate at baumrucker.org (C Tate Baumrucker) Date: Fri, 23 Dec 2011 08:41:59 -0500 Subject: Speed Test Results In-Reply-To: <1324631920.7845.YahooMailNeo@web39508.mail.mud.yahoo.com> References: <1324631920.7845.YahooMailNeo@web39508.mail.mud.yahoo.com> Message-ID: <4EF48527.6080203@baumrucker.org> Rolling your own with NDT (web100 tools), placing it on a common transit point within your network, and providing access to your customers will provide decent, consistent and pretty detailed results regarding TCP attributes. There are facilities within the software to perform packet captures for each test too. Works for our help desk to understand relative performance and respond accordingly. Trust nothing off your managed net. Tate On 12/23/2011 4:18 AM, jacob miller wrote: > Hi, > > Am having a debate on the results of speed tests sites. > > Am interested in knowing the thoughts of different individuals in regards to this. > > Regards, > Jacob > > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From jra at baylink.com Fri Dec 23 07:59:47 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 23 Dec 2011 08:59:47 -0500 (EST) Subject: Well Lookie Here, Barracuda Networks tries to get me to fall into their trap again... In-Reply-To: Message-ID: <27438489.1776.1324648787143.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jimmy Hess" > I guess the networking equivalent is --- you stop paying for your OC3 > with $BIG_TELCO for a few months, and you get it turned off, but for > some reason the physical cabling isn't physically removed. A few months > later, you decide you need an OC3 again and exclaim the unfairness of > $BIG_TELCO informing you that a fee is required to re-install the OC3 > they haven't removed yet. > How unfair right... many thousands of $$ just to flip a switch? One > chose to go without service for a few months, therefore should get a > lower total cost, based on the new renewal date, right? Well, I strongly suspect that's a bad analogy: the thing they'd be collecting for would be *the three months of unpaid bills on the circuit*. Possibly plus a deposit to make sure you don't screw them again. But they might well not charge you a new installation charge; I don't know that there's an industry standard practice there, nor that we'd know about if it there was (people who do that aren't much talking about it). And, finally, I suspect that on a circuit the size of an OC-3, you'd be lucky to get to be 30 days late on the payment; "a few" is generally between 3 and 5. But in fact, while you'd be on the hook for the "few months" they let it run while you weren't paying, you would almost certainly *not* owe them for the "few months" after they shut it off, since they weren't providing you the service 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 http://photo.imageinc.us +1 727 647 1274 From james.cutler at consultant.com Fri Dec 23 08:02:01 2011 From: james.cutler at consultant.com (Cutler James R) Date: Fri, 23 Dec 2011 09:02:01 -0500 Subject: Speed Test Results In-Reply-To: <005301ccc173$e6e6ffc0$b4b4ff40$@paulstewart.org> References: <1324631920.7845.YahooMailNeo@web39508.mail.mud.yahoo.com> <005301ccc173$e6e6ffc0$b4b4ff40$@paulstewart.org> Message-ID: <2E6C90F0-61A6-42EB-86EE-40C65123C033@consultant.com> On Dec 23, 2011, at 8:07 AM, Paul Stewart wrote: > In my opinion they are only "somewhat reliable" if they are on your network > or very close to your network -we operate one of the speedtest.net sites and > for our own eyeball traffic find it to be a "reasonable indicator" of what > kind of speeds the customer is getting. > > To put it a different way, if a customer is getting 20X1 Internet service > and the speedtest shows 17 X 0.8 then case closed - if they are getting a > speedtest result of 5 X 0.5 then our helpdesk will take a further look - > this is really in rough terms... > > Paul From the consumer viewpoint: No single data point should be extrapolated to infinity, but comparing problematic behavior with "normal" behavior is a standard process across all fields. Speed tests from several locations done regularly give a baseline for performance. Major departure from expected numbers from a set of speed test sites can be regarded as an indicator of local loop problems. Did you know that local loops suffer from backhoe fade? And, DSLAMS fail. In my home office, speed tests are just another useful diagnostic helping to locate problem areas - just like in Paul's example. DSLReports line monitoring service is a similarly useful tool. James R. Cutler james.cutler at consultant.com From brandon.kim at brandontek.com Fri Dec 23 08:46:59 2011 From: brandon.kim at brandontek.com (Brandon Kim) Date: Fri, 23 Dec 2011 09:46:59 -0500 Subject: Speed Test Results In-Reply-To: <2E6C90F0-61A6-42EB-86EE-40C65123C033@consultant.com> References: <1324631920.7845.YahooMailNeo@web39508.mail.mud.yahoo.com>, <005301ccc173$e6e6ffc0$b4b4ff40$@paulstewart.org>, <2E6C90F0-61A6-42EB-86EE-40C65123C033@consultant.com> Message-ID: I love using speedtest. My FIOS at home is 25/25. And speedtest consistently hits that mark so I know FIOS is giving me what I paid for. When Verizon was having internet issues last week my numbers were bad. Like someone else said, I would not use it much more for quick gauge. To get more granular info you should be using other tools.... > Subject: Re: Speed Test Results > From: james.cutler at consultant.com > Date: Fri, 23 Dec 2011 09:02:01 -0500 > To: nanog at nanog.org > > > On Dec 23, 2011, at 8:07 AM, Paul Stewart wrote: > > > In my opinion they are only "somewhat reliable" if they are on your network > > or very close to your network -we operate one of the speedtest.net sites and > > for our own eyeball traffic find it to be a "reasonable indicator" of what > > kind of speeds the customer is getting. > > > > To put it a different way, if a customer is getting 20X1 Internet service > > and the speedtest shows 17 X 0.8 then case closed - if they are getting a > > speedtest result of 5 X 0.5 then our helpdesk will take a further look - > > this is really in rough terms... > > > > Paul > > From the consumer viewpoint: > > No single data point should be extrapolated to infinity, but comparing problematic behavior with "normal" behavior is a standard process across all fields. > > Speed tests from several locations done regularly give a baseline for performance. Major departure from expected numbers from a set of speed test sites can be regarded as an indicator of local loop problems. Did you know that local loops suffer from backhoe fade? And, DSLAMS fail. > > In my home office, speed tests are just another useful diagnostic helping to locate problem areas - just like in Paul's example. DSLReports line monitoring service is a similarly useful tool. > > James R. Cutler > james.cutler at consultant.com > > > > > From frank at fttx.org Fri Dec 23 09:59:03 2011 From: frank at fttx.org (Frank A. Coluccio) Date: Fri, 23 Dec 2011 07:59:03 -0800 Subject: Speed Test Results Message-ID: <20111223075903.452C2B96@resin13.mta.everyone.net> From alvarezp at alvarezp.ods.org Fri Dec 23 10:19:31 2011 From: alvarezp at alvarezp.ods.org (Octavio Alvarez) Date: Fri, 23 Dec 2011 08:19:31 -0800 Subject: Speed Test Results In-Reply-To: <1324631920.7845.YahooMailNeo@web39508.mail.mud.yahoo.com> References: <1324631920.7845.YahooMailNeo@web39508.mail.mud.yahoo.com> Message-ID: On Fri, 23 Dec 2011 01:18:40 -0800, jacob miller wrote: > Am having a debate on the results of speed tests sites. > > Am interested in knowing the thoughts of different individuals in > regards to this. They are just a measurement, which need to be correctly used and interpreted (that's the difficult part). Reading bad numbers is not necessarily an indication of a link problem. Reading "good enough" numbers is only meaningful for the duration of the test. To me, the big problem is that they don't state all the details of the tests (for example, how exactly to they do the transfer). Geographical location is good, but sometimes not enough. Do they use http, https, ftp or their own JS implementation of whatever weird protocol they though of? How do I know if I'm hitting my firewall, web cache or ALG? I only use them to get a generic overview of the link. -- Octavio. Twitter: @alvarezp2000 -- Identi.ca: @alvarezp From askoorb+nanog at gmail.com Fri Dec 23 10:31:42 2011 From: askoorb+nanog at gmail.com (Alex Brooks) Date: Fri, 23 Dec 2011 16:31:42 +0000 Subject: Speed Test Results In-Reply-To: References: <1324631920.7845.YahooMailNeo@web39508.mail.mud.yahoo.com> Message-ID: Hello, On Fri, Dec 23, 2011 at 4:19 PM, Octavio Alvarez wrote: > > On Fri, 23 Dec 2011 01:18:40 -0800, jacob miller wrote: > >> Am having a debate on the results of speed tests sites. >> >> Am interested in knowing the thoughts of different individuals in regards to this. > > > They are just a measurement, which need to be correctly used and > interpreted (that's the difficult part). > > Reading bad numbers is not necessarily an indication of a link problem. > > Reading "good enough" numbers is only meaningful for the duration of the > test. > > To me, the big problem is that they don't state all the details of the > tests (for example, how exactly to they do the transfer). Geographical > location is good, but sometimes not enough. Do they use http, https, ftp > or their own JS implementation of whatever weird protocol they though of? > How do I know if I'm hitting my firewall, web cache or ALG? > I agree. But one that is fairly clear in what (and how) it tests (but to be fair isn't really a 'speed test') that I've come across is ICSI Netalyzr. It's pretty useful to give a first impression to a tech of what's going on with a link. Take a look at an example report (from a dodgy connection) I dug up: http://netalyzr.icsi.berkeley.edu/restore/id=43ca208a-28820-e88f1efc-a129-4c92-8968 More info and examples are at http://netalyzr.icsi.berkeley.edu/ I also think that sometimes having a 'speed test' or similar hosted on a network you are trying to connect to can be useful to find out if a link is congested, or other problems getting from you to that network. An example of this is The BBC's iPlayer diagnostic at http://www.bbc.co.uk/iplayer/diagnostics (think Hulu, but in the UK). It tests to all their CDNs (Akami, Limelight etc) using different streaming methods and gives the results. Only useful as an overview, but a decent first guide nevertheless . > > I only use them to get a generic overview of the link. > Heck yes! Alex From Jason_Livingood at cable.comcast.com Fri Dec 23 11:13:48 2011 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Fri, 23 Dec 2011 17:13:48 +0000 Subject: Speed Test Results In-Reply-To: <1324631920.7845.YahooMailNeo@web39508.mail.mud.yahoo.com> Message-ID: If you want to understand the issue in detail, check out the report from MIT this year, written by Steve Bauer and available at http://mitas.csail.mit.edu/papers/Bauer_Clark_Lehr_Broadband_Speed_Measurem ents.pdf. - Jason On 12/23/11 4:18 AM, "jacob miller" wrote: >Hi, > >Am having a debate on the results of speed tests sites. > >Am interested in knowing the thoughts of different individuals in regards >to this. > >Regards, >Jacob > > From michael at rancid.berkeley.edu Fri Dec 23 12:48:00 2011 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Fri, 23 Dec 2011 10:48:00 -0800 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EF3C864.60807@necom830.hpcl.titech.ac.jp> References: <4EF28A00.2080904@kl.net> <4EF3C864.60807@necom830.hpcl.titech.ac.jp> Message-ID: <4EF4CCE0.5060304@rancid.berkeley.edu> On 12/22/11 16:16, Masataka Ohta wrote: > Glen Kent wrote: > >> While in some environments, typically with small number of devices, >> its indispensable. Small businesses may not want the complexity of >> setting up a central server (for DHCP) - SLAAC works very well in such >> environments. > > IPv6 routers are the central servers for SLAAC with the > complexity of setting up. I have never found an IPv6 router--with SLAAC enabled--any harder or more complex to configure than an IPv4 router. You need to route IPv6 anyway. The only time you need to perform extra steps is when you want to run DHCPv6. You need to enable the M and/or O flags and turn off the 'autonomous' flag (if you don't want a host to get both SLAAC addresses and DHCPv6 addresses. Then you need to turn on relaying unless you are putting the DHCPv6 server on the same wire. We need to make it easier to run DHCPv6, not harder to run SLAAC. michael From michael at rancid.berkeley.edu Fri Dec 23 13:11:00 2011 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Fri, 23 Dec 2011 11:11:00 -0800 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EF38E78.7050504@cis.vutbr.cz> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF2661A.4050408@rancid.berkeley.edu> <4EF38E78.7050504@cis.vutbr.cz> Message-ID: <4EF4D244.1020900@rancid.berkeley.edu> On 12/22/11 12:09, Tomas Podermanski wrote: > We have to use SLAAC as well because we do not have other choice. Not > all operating systems supports DHCPv6 today. But we are not happy about > it (problems with privacy extensions, security as I mentioned before). > > DHCPv6 do not have to be run on a central server. DHCPv6 can be > implemented as a part of a router as well. It is common for DHCP(v4) an > implementations for DHCPv6 are available today (eg. cisco > http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-dhcp.html). But one of the advantages you cite for DHCPv6 was the ability for the central DHCPv6 service to make decisions about how to configure clients. Most US EDUs that I am familiar with do not wish to go out and touch every router when they want to make site-wide configuration changes. Even if you run DHCP[v6] on a router (and yes, I have done it), you're still running a separate service beyond routing and it still increases the complexity of your configuration. I agree with Bill: We're not hurting for choices in IPv4. What we don't need to do is reduce choice in IPv6 by deprecating SLAAC--a move which would also reduce the credibility of IPv6 itself. There was at least some criticism of the community for deprecating NAT-PT. By pushing SLAAC for many years, then deprecating it (as opposed to simply adding alternatives), we will be telling would be adopters "we really can't make up our minds as to how you're supposed to use this stuff." That would only stall IPv6 adoption, even if the ultimate result of keeping both protocols will be that a vast majority of folks use DHCPv6. michael From jmaslak at antelope.net Fri Dec 23 13:16:38 2011 From: jmaslak at antelope.net (Joel Maslak) Date: Fri, 23 Dec 2011 12:16:38 -0700 Subject: Speed Test Results In-Reply-To: <1324631920.7845.YahooMailNeo@web39508.mail.mud.yahoo.com> References: <1324631920.7845.YahooMailNeo@web39508.mail.mud.yahoo.com> Message-ID: On Fri, Dec 23, 2011 at 2:18 AM, jacob miller wrote: > Am having a debate on the results of speed tests sites. > > Am interested in knowing the thoughts of different individuals in regards to this. It's one data point of many. Depending on the speed test site, the protocols it uses, where the test is located, any local networking gear (I've seen transparent proxies get great speedtest ratings!), etc, they can be useful, particularly in verifying that a provider's off-net interconnects and partners are doing well. However, they are susceptible to things like wireless network issues, TCP limitations (one stream vs. many streams), and misconfiguration of devices at the customer location. And the speed test box isn't necessarily configured/speced correctly either. I second the thoughts on NDT and I like the ICSI Netalyzer. But I wouldn't necessarily put either tool in most end users' hands (I think they are too complex for most end users to interpret the results properly). From cscora at apnic.net Fri Dec 23 13:23:39 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 24 Dec 2011 05:23:39 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201112231923.pBNJNdtZ003208@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 24 Dec, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 387081 Prefixes after maximum aggregation: 168128 Deaggregation factor: 2.30 Unique aggregates announced to Internet: 189666 Total ASes present in the Internet Routing Table: 39672 Prefixes per ASN: 9.76 Origin-only ASes present in the Internet Routing Table: 32553 Origin ASes announcing only one prefix: 15517 Transit ASes present in the Internet Routing Table: 5339 Transit-only ASes present in the Internet Routing Table: 141 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 33 Max AS path prepend of ASN (48687) 24 Prefixes from unregistered ASNs in the Routing Table: 1962 Unregistered ASNs in the Routing Table: 1019 Number of 32-bit ASNs allocated by the RIRs: 2123 Number of 32-bit ASNs visible in the Routing Table: 1780 Prefixes from 32-bit ASNs in the Routing Table: 4232 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 127 Number of addresses announced to Internet: 2503477552 Equivalent to 149 /8s, 56 /16s and 9 /24s Percentage of available address space announced: 67.5 Percentage of allocated address space announced: 67.5 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 91.8 Total number of prefixes smaller than registry allocations: 163949 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 95769 Total APNIC prefixes after maximum aggregation: 31336 APNIC Deaggregation factor: 3.06 Prefixes being announced from the APNIC address blocks: 92133 Unique aggregates announced from the APNIC address blocks: 38669 APNIC Region origin ASes present in the Internet Routing Table: 4619 APNIC Prefixes per ASN: 19.95 APNIC Region origin ASes announcing only one prefix: 1249 APNIC Region transit ASes present in the Internet Routing Table: 729 Average APNIC Region AS path length visible: 4.3 Max APNIC Region AS path length visible: 18 Number of APNIC region 32-bit ASNs visible in the Routing Table: 125 Number of APNIC addresses announced to Internet: 632233600 Equivalent to 37 /8s, 175 /16s and 30 /24s Percentage of available APNIC address space announced: 80.2 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-132095, 132096-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, 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: 146693 Total ARIN prefixes after maximum aggregation: 74924 ARIN Deaggregation factor: 1.96 Prefixes being announced from the ARIN address blocks: 118806 Unique aggregates announced from the ARIN address blocks: 48828 ARIN Region origin ASes present in the Internet Routing Table: 14819 ARIN Prefixes per ASN: 8.02 ARIN Region origin ASes announcing only one prefix: 5672 ARIN Region transit ASes present in the Internet Routing Table: 1566 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 25 Number of ARIN region 32-bit ASNs visible in the Routing Table: 14 Number of ARIN addresses announced to Internet: 804598720 Equivalent to 47 /8s, 245 /16s and 51 /24s Percentage of available ARIN address space announced: 63.9 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 94898 Total RIPE prefixes after maximum aggregation: 51720 RIPE Deaggregation factor: 1.83 Prefixes being announced from the RIPE address blocks: 86897 Unique aggregates announced from the RIPE address blocks: 55306 RIPE Region origin ASes present in the Internet Routing Table: 16209 RIPE Prefixes per ASN: 5.36 RIPE Region origin ASes announcing only one prefix: 7986 RIPE Region transit ASes present in the Internet Routing Table: 2575 Average RIPE Region AS path length visible: 4.7 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1239 Number of RIPE addresses announced to Internet: 494850504 Equivalent to 29 /8s, 126 /16s and 209 /24s Percentage of available RIPE address space announced: 79.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 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 36823 Total LACNIC prefixes after maximum aggregation: 8014 LACNIC Deaggregation factor: 4.59 Prefixes being announced from the LACNIC address blocks: 36312 Unique aggregates announced from the LACNIC address blocks: 18904 LACNIC Region origin ASes present in the Internet Routing Table: 1559 LACNIC Prefixes per ASN: 23.29 LACNIC Region origin ASes announcing only one prefix: 451 LACNIC Region transit ASes present in the Internet Routing Table: 287 Average LACNIC Region AS path length visible: 4.5 Max LACNIC Region AS path length visible: 27 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 398 Number of LACNIC addresses announced to Internet: 94882952 Equivalent to 5 /8s, 167 /16s and 204 /24s Percentage of available LACNIC address space announced: 62.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, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 8506 Total AfriNIC prefixes after maximum aggregation: 2063 AfriNIC Deaggregation factor: 4.12 Prefixes being announced from the AfriNIC address blocks: 6551 Unique aggregates announced from the AfriNIC address blocks: 2036 AfriNIC Region origin ASes present in the Internet Routing Table: 503 AfriNIC Prefixes per ASN: 13.02 AfriNIC Region origin ASes announcing only one prefix: 159 AfriNIC Region transit ASes present in the Internet Routing Table: 111 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 4 Number of AfriNIC addresses announced to Internet: 30835968 Equivalent to 1 /8s, 214 /16s and 133 /24s Percentage of available AfriNIC address space announced: 45.9 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2488 11102 967 Korea Telecom (KIX) 17974 1716 503 38 PT TELEKOMUNIKASI INDONESIA 7545 1629 303 86 TPG Internet Pty Ltd 4755 1515 385 157 TATA Communications formerly 7552 1420 1064 7 Vietel Corporation 9829 1168 989 28 BSNL National Internet Backbo 9583 1101 81 494 Sify Limited 4808 1076 2036 307 CNCGROUP IP network: China169 24560 1012 385 167 Bharti Airtel Ltd., Telemedia 18101 974 131 157 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 3473 3814 219 bellsouth.net, inc. 7029 2910 1017 200 Windstream Communications Inc 18566 2093 383 177 Covad Communications 1785 1860 680 122 PaeTec Communications, Inc. 4323 1621 1065 385 Time Warner Telecom 20115 1612 1549 622 Charter Communications 22773 1515 2909 107 Cox Communications, Inc. 30036 1466 260 686 Mediacom Communications Corp 19262 1389 4683 401 Verizon Global Networks 7018 1302 7012 854 AT&T WorldNet Services 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 1617 480 15 Corbina telecom 15557 1092 2161 64 LDCOM NETWORKS 2118 672 99 14 EUnet/RELCOM Autonomous Syste 6830 648 1928 413 UPC Distribution Services 34984 628 132 197 BILISIM TELEKOM 20940 555 179 441 Akamai Technologies European 12479 551 636 53 Uni2 Autonomous System 3320 532 8162 398 Deutsche Telekom AG 3292 480 2106 407 TDC Tele Danmark 8866 464 134 27 Bulgarian Telecommunication C 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 1719 318 157 TVCABLE BOGOTA 28573 1574 1064 75 NET Servicos de Comunicao S.A 8151 1452 2960 356 UniNet S.A. de C.V. 7303 1249 752 174 Telecom Argentina Stet-France 27947 631 73 94 Telconet S.A 22047 582 322 17 VTR PUNTO NET S.A. 7738 551 1050 31 Telecomunicacoes da Bahia S.A 3816 547 237 90 Empresa Nacional de Telecomun 6503 539 434 67 AVANTEL, S.A. 11172 530 102 97 Servicios Alestra S.A de C.V Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1036 958 13 TEDATA 24863 790 146 36 LINKdotNET AS number 3741 280 939 229 The Internet Solution 6713 243 647 17 Itissalat Al-MAGHRIB 15706 242 32 6 Sudatel Internet Exchange Aut 33776 240 13 8 Starcomms Nigeria Limited 29571 217 17 13 Ci Telecom Autonomous system 12258 195 28 60 Vodacom Internet Company 24835 188 80 8 RAYA Telecom - Egypt 16637 160 664 82 MTN Network Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3473 3814 219 bellsouth.net, inc. 7029 2910 1017 200 Windstream Communications Inc 4766 2488 11102 967 Korea Telecom (KIX) 18566 2093 383 177 Covad Communications 1785 1860 680 122 PaeTec Communications, Inc. 10620 1719 318 157 TVCABLE BOGOTA 17974 1716 503 38 PT TELEKOMUNIKASI INDONESIA 7545 1629 303 86 TPG Internet Pty Ltd 4323 1621 1065 385 Time Warner Telecom 8402 1617 480 15 Corbina telecom 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 2910 2710 Windstream Communications Inc 18566 2093 1916 Covad Communications 1785 1860 1738 PaeTec Communications, Inc. 17974 1716 1678 PT TELEKOMUNIKASI INDONESIA 8402 1617 1602 Corbina telecom 10620 1719 1562 TVCABLE BOGOTA 7545 1629 1543 TPG Internet Pty Ltd 4766 2488 1521 Korea Telecom (KIX) 28573 1574 1499 NET Servicos de Comunicao S.A 7552 1420 1413 Vietel Corporation Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 32873 UNALLOCATED 12.46.100.0/23 10912 InterNAP Network Ser 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.0.0/21 12654 RIPE NCC RIS Project 128.0.24.0/24 12654 RIPE NCC RIS Project 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 37.19.72.0/21 42322 Zhanr Ltd. 37.25.64.0/21 33828 iptoX GmbH Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:12 /10:27 /11:81 /12:237 /13:465 /14:814 /15:1448 /16:12072 /17:6121 /18:10183 /19:20111 /20:27962 /21:28218 /22:38383 /23:35824 /24:201495 /25:1182 /26:1403 /27:771 /28:166 /29:55 /30:14 /31:0 /32:18 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 2538 2910 Windstream Communications Inc 6389 2118 3473 bellsouth.net, inc. 18566 2042 2093 Covad Communications 10620 1614 1719 TVCABLE BOGOTA 8402 1596 1617 Corbina telecom 30036 1426 1466 Mediacom Communications Corp 11492 1115 1152 Cable One 1785 1063 1860 PaeTec Communications, Inc. 7011 1051 1168 Citizens Utilities 15557 1042 1092 LDCOM NETWORKS Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:470 2:427 4:15 5:1 6:3 8:366 12:1946 13:1 14:576 15:11 16:3 17:7 20:9 23:79 24:1716 27:1129 31:734 32:67 33:2 34:2 36:4 37:6 38:774 40:115 41:2978 42:78 43:1 44:3 46:1142 47:3 49:280 50:471 52:13 55:6 56:2 57:42 58:924 59:488 60:342 61:1172 62:937 63:1963 64:4137 65:2303 66:4372 67:1989 68:1167 69:3134 70:924 71:410 72:1787 74:2640 75:431 76:320 77:941 78:871 79:469 80:1167 81:839 82:524 83:529 84:577 85:1162 86:743 87:905 88:353 89:1585 90:249 91:4375 92:533 93:1525 94:1333 95:1051 96:398 97:286 98:785 99:38 100:2 101:130 103:582 106:11 107:118 108:100 109:1404 110:675 111:827 112:432 113:494 114:591 115:707 116:873 117:713 118:891 119:1272 120:359 121:671 122:1600 123:1029 124:1329 125:1347 128:554 129:189 130:185 131:586 132:163 133:21 134:226 135:54 136:213 137:151 138:285 139:126 140:492 141:256 142:382 143:389 144:501 145:67 146:475 147:222 148:634 149:269 150:165 151:191 152:445 153:170 154:7 155:383 156:210 157:365 158:154 159:504 160:358 161:221 162:333 163:186 164:522 165:389 166:544 167:455 168:816 169:146 170:830 171:95 172:4 173:1803 174:602 175:400 176:323 177:425 178:1148 180:1207 181:39 182:674 183:265 184:408 185:1 186:1398 187:780 188:1003 189:1174 190:5316 192:5979 193:5439 194:3781 195:3182 196:1291 197:170 198:3615 199:4233 200:5523 201:1681 202:8489 203:8524 204:4344 205:2419 206:2681 207:2819 208:4010 209:3563 210:2746 211:1476 212:1956 213:1800 214:796 215:93 216:4919 217:1473 218:569 219:336 220:1255 221:529 222:323 223:265 End of report From michael.holstein at csuohio.edu Fri Dec 23 13:26:30 2011 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Fri, 23 Dec 2011 14:26:30 -0500 Subject: Speed Test Results In-Reply-To: <1324631920.7845.YahooMailNeo@web39508.mail.mud.yahoo.com> References: <1324631920.7845.YahooMailNeo@web39508.mail.mud.yahoo.com> Message-ID: <4EF4D5E6.50705@csuohio.edu> > Am having a debate on the results of speed tests sites. > > Am interested in knowing the thoughts of different individuals in regards to this. > > They are excellent tools for generating user complaints. (just like the "do traceroute and count the hops" advice from gamer mags of old). (my $0.02) Michael Holstein Cleveland State University From Valdis.Kletnieks at vt.edu Fri Dec 23 13:33:08 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 23 Dec 2011 14:33:08 -0500 Subject: Speed Test Results In-Reply-To: Your message of "Fri, 23 Dec 2011 12:16:38 MST." References: <1324631920.7845.YahooMailNeo@web39508.mail.mud.yahoo.com> Message-ID: <107251.1324668788@turing-police.cc.vt.edu> On Fri, 23 Dec 2011 12:16:38 MST, Joel Maslak said: > However, they are susceptible to things like wireless network issues, > TCP limitations (one stream vs. many streams), and misconfiguration of > devices at the customer location. And the speed test box isn't > necessarily configured/speced correctly either. I have seen some surreal results reported by some of the speed test sites if you have a sufficiently fat pipe. Near as I could tell, every single hop was gigE or better all the way, the speedtest site then tried to apply a correction for the bottleneck it knew about on its local gigE nterface, and basically decided that the *rest* of the path must be near-infinite speed. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From tpoder at cis.vutbr.cz Fri Dec 23 13:51:58 2011 From: tpoder at cis.vutbr.cz (Tomas Podermanski) Date: Fri, 23 Dec 2011 20:51:58 +0100 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF38D5A.4070003@cis.vutbr.cz> Message-ID: <4EF4DBDE.7050706@cis.vutbr.cz> Hi, On 12/23/11 7:07 AM, Mohacsi Janos wrote: > > On Thu, 22 Dec 2011, Tomas Podermanski wrote: > >> Hi, >> >> On 12/21/11 9:40 PM, Ray Soucy wrote: >>> I'm afraid you're about 10 years too late for this opinion to make >>> much difference. ;-) >> >> My opinion is that there is never too late to make thinks easier to >> implement and operate, specially in situation when things are >> unnecessary complicated. I do not hide that my opinion about SLAAC might >> look extreme but I have wrote my reasons for that. I do not expect that >> anything will be changed but the fact that I can see discussion about >> that topic approximately 2 or 3 times per month (v6ops, dhcwg, ipv6, >> ...) and that shows that this problem is pain for many people/ISP. Have >> you ever seen similar discussion related to DHCP(v4). I have not, >> because there nothing to discuss about. It just works. It works in >> simple and logical way. >> >>> >>> We have been running IPv6 in production for several years (2008) as >>> well (answering this email over IPv6 now, actually) yet I have >>> completely different conclusions about the role of RA and DHCPv6. >>> Weird. >> >> Well, then how many devices do you have in the network that uses IPv6? >> Do you have implemented first hop security? What will you do when some >> user runs RA flood attack >> (http://samsclass.info/ipv6/proj/flood-router6a.htm). What will you do >> when some user runs NDP Table Exhaustion Attack >> (http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf) ? It is quite easy >> to bring IPv6 into a server subnet or a small office network. Providing >> stable and secure connectivity into the network with thousands of access >> port for the paying customers/users is really a serious issue today. > > > This is implementation issue. Has to be fixed. Or your have to think > about port-security.... Port security does not help in that case (same as 802.1x). Port security is a layer 2 feature so all layer 3 attacks can be still performed. That prevents only against source MAC address spoofing. All other attacks like DAD DOS, NDP Exhaustion, RA flooding etc. can be performed even though the port security is implemented. > >> >> I am very interested how the sites with similar number of access ports >> (users/customers) solve that problems. > > If users are not seperated by interfaces you can see similar issues in > IPv4 (spoofing attacks).... That is true, but we know solution for IPv4 (DHCP snooping, ARP protection, source address validation) and there are access switches on the market having that security features. Switches supporting such features for IPv6 are usually much more expensive. And there is another problem. Although you have money for that hardware it does not protect you against malicious attacks. Tomas > > >> I can see that many ISPs prefer >> to solve that by blocking whole IPv6 traffic instead. But it does not >> look as a good strategy for deploying IPv6 :-(. >> >> Tomas >> >>> >>> On Wed, Dec 21, 2011 at 2:16 PM, Tomas Podermanski >>> wrote: >>>> Hi, >>>> >>>> from my perspective the short answer for this never-ending story is: >>>> >>>> - SLAAC/RA is totally useless, does not bring any benefit at all >>>> and should be removed from IPv6 specs >>>> - DHCPv6 should be extended by route options as proposed in >>>> http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-03 >>>> - DHCPv6 should be extended by layer 2 address to identify >>>> client's L2 address (something that we can see in RFC 6221) >>>> - DHCPv6 should be the common way to autoconfigure an address >>>> in a IPv6 environment >>>> >>>> The long answer is: >>>> >>>> I completely disagree with opinion that both DHCPv6 and RA (SLAAC) >>>> should be supported. It is easy to say that both have place but it has >>>> some consequences. I and my colleagues have been working on deploying >>>> IPv6 for a few years and from the operation perspective we conclude >>>> into >>>> a quite clear opinion in that area. Both SLAAC and DHCPv6 uses a >>>> opposite principles although the goal is just one. DHCPv6 is based >>>> on a >>>> central DHCPv6 server that assigns addresses. SLAAC does opposite - >>>> leaves the decision about the address on a client side. However we >>>> have >>>> to run both of them in a network to provide all necessary pieces of >>>> information to the clients (default route and DNS). This brings many >>>> implementation and operational complications. >>>> >>>> - Clients have to support both SLAAC and DHCPv6 to be able to work in >>>> both environments >>>> - There must be solved a situation what to do when SLAAC and DHCPv6 >>>> provides some conflict information (quite long thread with various >>>> opinions >>>> can be found at >>>> http://www.ietf.org/mail-archive/web/ipv6/current/msg14949.html) >>>> - The first hop security have to be solved twice - for SLAAC and for >>>> DHCPv6. Both >>>> of then uses a differed communication way. SLAAC is part of ICMPv6, >>>> but DHCPv6 >>>> uses "own" UDP communication what does not make things easier. >>>> - SLAAC is usually processed in a kernel, DHCPv6 is usually run as a >>>> process in the user space. Diagnostic and troubleshooting is more >>>> complicated. >>>> - DHCPv6 is currently tied with SLAAC (M,O flags), what means that >>>> a DHCPv6 client have to wait until some RA message arrives to >>>> start DHCPv6 >>>> discovery. That unnecessary prolongs whole autoconfiguration process. >>>> >>>> Some other issues are also described in [1]. >>>> >>>> I personally prefer to bury SLAAC once forever for several reasons: >>>> - In fact SLAAC does nothing more what DHCPv6 can do. >>>> - SLAAC is quite difficult to secure. One (really only ONE) RA packet >>>> can destroy >>>> the IPv6 connection for all clients in a local network just in a few >>>> milliseconds. >>>> It also happens accidentally by "connection sharing" in Vista, Win7 >>>> >>>> (https://openwiki.uninett.no//_media/geantcampus:2011-gn3na3t4-ipv6-gregr.pdf) >>>> >>>> - The full protection against that behavior it's impossible today. >>>> RA-Guard or >>>> PACL can be bypassed using extension headers or fragmentation >>>> (http://www.mh-sec.de/downloads/mh-ipv6_vulnerabilities.pdf) >>>> - With SLAAC is difficult to implement security features like ARP/ND >>>> protection/inspection, IP source guard/Dynamic lock down, because >>>> all this techniques are based on a MAC-IP database created during >>>> a communication with a DHCP server. There are some attempts (ND >>>> protection, SAVI) >>>> but it does not provide the same level of security. >>>> - Just the same technique was introduced in IPv4 as Router Discovery >>>> (RFC 1256). >>>> Nobody uses it today. Do we really need go through same death way >>>> again? >>>> (Oh right, we are already going :-( ) >>>> >>>> Comparing to SLAAC, DHCPv6 have several advantages: >>>> - DHCPv6 is very similar to DHCP(v4) and many people are used to >>>> using it. >>>> - DHCPv6 can potentially do much more - for example handle an >>>> information >>>> for PXE, options for IP phones, prefix delegation. >>>> - DHCPv6 allows handle an information only for some hosts or group of >>>> hosts (differed lease time, search list, DNS atc.). With SLAAC it is >>>> impossible and all host on a subnet have to share the same set of >>>> the configuration information. >>>> - Frankly said, I have not found any significant benefit that SLAAC >>>> brings. >>>> >>>> Unfortunately there is another issue with DUIDs in DHCPv6. But it is a >>>> little bit differed tale. >>>> >>>> At the beginning the autoconfiguration was meant as easy to use and >>>> easy >>>> to configure but the result turned out into kind of nightmare. For >>>> those >>>> who do not know what I am talking about I prepared two images. The >>>> first >>>> one shows necessary communication before first regular packet can be >>>> send over IPv4 >>>> (http://hawk.cis.vutbr.cz/~tpoder/tmp/autoconf/IPv4.png) >>>> and just the same thing in IPv6 >>>> (http://hawk.cis.vutbr.cz/~tpoder/tmp/autoconf/IPv4.png). In IPv4 we >>>> have very simple answer if somebody asks for autoconfiguration = use >>>> DHCP. In IPv6 the description how things work have to be written into >>>> more than 10 pages [1]. I believe that is not what we really wanted. >>>> >>>> For those who are interested in that area there are several >>>> articles/presentations where we mentioned that topic. >>>> >>>> [1] IPv6 Autoconfiguration - Best Practice Document >>>> http://www.terena.org/activities/campus-bp/pdf/gn3-na3-t4-cbpd117.pdf >>>> >>>> [2] IPv6 - security threads >>>> http://www.fit.vutbr.cz/research/view_pub.php?id=9835 >>>> >>>> [3] Deploying IPv6 in University Campus Network - Practical Problems >>>> http://www.fit.vutbr.cz/research/view_pub.php?id=9836 >>>> >>>> >>>> Regards, >>>> Tomas Podermanski >>>> >>>> >>>> >>>> On 12/20/11 8:31 AM, Owen DeLong wrote: >>>>> Different operators will have different preferences in different >>>>> environments. >>>>> >>>>> Ideally, the IETF should provide complete solutions based on >>>>> DHCPv6 and >>>>> on RA and let the operators decide what they want to use in their >>>>> environments. >>>>> >>>>> Owen >>>>> >>>>> On Dec 19, 2011, at 10:27 PM, Ravi Duggal wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> IPv6 devices (routers and hosts) can obtain configuration >>>>>> information >>>>>> about default routers, on-link prefixes and addresses from Router >>>>>> Advertisements as defined in Neighbor Discovery. I have been told >>>>>> that in some deployments, there is a strong desire not to use Router >>>>>> Advertisements at all and to perform all configuration via DHCPv6. >>>>>> There are thus similar IETF standards to get everything that you can >>>>>> get from RAs, by using DHCPv6 instead. >>>>>> >>>>>> As a result of this we see new proposals in IETF that try to do >>>>>> similar things by either extending RA mechanisms or by >>>>>> introducing new >>>>>> options in DHCPv6. >>>>>> >>>>>> We thus have draft-droms-dhc-dhcpv6-default-router-00 that extends >>>>>> DHCPv6 to do what RA does. And now, we have >>>>>> draft-bcd-6man-ntp-server-ra-opt-00.txt that extends RA to advertise >>>>>> the NTP information that is currently done via DHCPv6. >>>>>> >>>>>> My question is, that which then is the more preferred option for the >>>>>> operators? Do they prefer extending RA so that the new information >>>>>> loaded on top of the RA messages gets known in the single shot when >>>>>> routers do neighbor discovery. Or do they prefer all the extra >>>>>> information to be learnt via DHCPv6? What are the pros and cons in >>>>>> each approach and when would people favor one over the other? >>>>>> >>>>>> I can see some advantages with the loading information to RA since >>>>>> then one is not dependent on the DHCPv6 server. However, the latter >>>>>> provides its own benefits. >>>>>> >>>>>> Regards, >>>>>> Ravi D. >>>> >>> >>> >> >> >> From tpoder at cis.vutbr.cz Fri Dec 23 14:06:26 2011 From: tpoder at cis.vutbr.cz (Tomas Podermanski) Date: Fri, 23 Dec 2011 21:06:26 +0100 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <9B747991-09CC-47E2-A245-846C3ABD9005@delong.com> <4EF39719.5010802@cis.vutbr.cz> Message-ID: <4EF4DF42.2030709@cis.vutbr.cz> Hi, On 12/23/11 4:33 AM, Owen DeLong wrote: > > Sent from my iPad > > On Dec 23, 2011, at 3:46 AM, Tomas Podermanski wrote: > >> Hi, >> >> On 12/22/11 12:18 AM, Owen DeLong wrote: >>>> The long answer is: >>>> >>>> I completely disagree with opinion that both DHCPv6 and RA (SLAAC) >>>> should be supported. It is easy to say that both have place but it has >>>> some consequences. I and my colleagues have been working on deploying >>>> IPv6 for a few years and from the operation perspective we conclude into >>>> a quite clear opinion in that area. Both SLAAC and DHCPv6 uses a >>>> opposite principles although the goal is just one. DHCPv6 is based on a >>>> central DHCPv6 server that assigns addresses. SLAAC does opposite - >>>> leaves the decision about the address on a client side. However we have >>>> to run both of them in a network to provide all necessary pieces of >>>> information to the clients (default route and DNS). This brings many >>>> implementation and operational complications. >>>> >>> I agree that the requirement to run both is broken. I don't agree that this >>> means we should remove the option of using SLAAC in environments >>> where it makes sense. >>> >>>> - Clients have to support both SLAAC and DHCPv6 to be able to work in >>>> both environments >>> So? >> It makes the client side more difficult to implement (=more expensive). >> What worse SLAAC and DHCPv6 are differed protocols, so there is bigger >> probability for attacks (overflow, flood etc.). For example in UNIX-like >> systems autoconfiguration have to be solved by 3 parts of the system: >> >> 1. some SLAAC options are usually processed by a kernel (address >> selection, MTU) and behavior of that process can be changed via sysctl >> 2. some SLAAC options are processed by rdnssd daemon (processing DNS >> options) >> 3. DHCPv6 options are processed byt dhcpv6-client >> >> All those parts have to cooperate together. At the first sight it is >> obvious that there is pretty good probability that something can go >> wrong. Troubleshooting then is really piece of cake. For example in IPv4 >> environment we have following scenario: >> >> 1. DHCP options are processed by dhcp-client > Except when they are processed by BIOS, Kernel, or something else. Sure, in all this parts (you probably meant PXE, network booting) we will have more difficult code. If developers are ok with that and I will have all that code in PXE, grub and a kerel code... > > Yeah, the situation there in terms of the number of moving pieces is actually about the same. Even when DHCP options are parsed by dhcp-client, it has to use them to modify the kernel data structures and affect the behavior of other parts of the system, so, there's roughly similar amount of interaction either way. > > >>>> - There must be solved a situation what to do when SLAAC and DHCPv6 >>>> provides some conflict information (quite long thread with various >>>> opinions >>>> can be found at >>>> http://www.ietf.org/mail-archive/web/ipv6/current/msg14949.html) >>> SLAAC and DHCPv6 can't really provide conflicting information unless >>> the router is misconfigured. Even if a host gets different answers for the >>> same prefixes from SLAAC and DHCP, it should be able to use both >>> host addresses. There's the question of source address selection, but, >>> the answer to that question at the IETF level should only be a matter >>> of what the default answer is. There are configuration options for setting >>> host source address selection priorities. >> I am not thinking about address. It is the easier part - we can use all >> provided. There are other options like DNS servers, search list, NTP >> servers, ... >> > If you get DNS servers from RA and from DHCP, throw them all in the candidate DNS server list. Unless something is broken, any one of them should work and provide the same answers as the others. > > You can't get NTP from SLAAC/RA, so, no conflict there. If the router and dhcp server administrators can't agree on the DNS search list, then, you're going to have some problems no matter what protocol you use, so, I really think this is a tempest in a teacup. > >>>> - The first hop security have to be solved twice - for SLAAC and for >>>> DHCPv6. Both >>>> of then uses a differed communication way. SLAAC is part of ICMPv6, >>>> but DHCPv6 >>>> uses "own" UDP communication what does not make things easier. >>> Solved for SLAAC -- SEND. >>> Allegedly, there is Secure DHCPv6 for DHCP, but, I haven't seen any >>> actual implementations yet. >> Right, very easy to write but pretty difficult (impossible) to use >> today. None of operating systems supports SEND and some will probably >> never be: > If there is actual real world demand for it, it will get implemented. Reality is that today, DHCPv4 has been running just as insecure for many years and nobody cares. I don't know why the bar for IPv6 should be so much higher than IPv4. I can not agree with that. Many operators having customers into a shared segment and uses security features I mentioned before ( again DHCP snooping, ARP protection, source address validation). In IPv6 is quite difficult to implement it even thou an ISP have a lot of money for new equipment. That is a reason why some operators prefer to block all protocols except IP(v4) and ARP instead of deploying IPv6. So we can not be surprised then that only less than 0.5% users have native IPv6 connectivity. I do not claim that is the only reason but one small piece of a bigger problem. > >> as we can find http://technet.microsoft.com/en-us/library/bb726956.aspx >> However, Microsoft does not support SEND in any version of Windows. >> >> I have found only one implementation for Linux >> (http://amnesiak.org/NDprotector/) that is not ready for production. So >> we can not think seriously about SEND today. SEND also brings another >> set of problems like certificate management, etc., but is a little >> differed story. >> > Right. Actual security is hard. No surprise there. Moreover, administrators are lazy. Also no surprise. Limited threat, lazy administrators, hard security, no action. This is the same in IPv4, IPv6, and doesn't really change whether you use SLAAC or DHCP or even static addresses. It is also question of money. For implementing more difficult environment the more experienced staff and more money is needed. > >>>> - SLAAC is usually processed in a kernel, DHCPv6 is usually run as a >>>> process in the user space. Diagnostic and troubleshooting is more >>>> complicated. >>> That seems like an argument for SLAAC, if anything. >>> >>>> - DHCPv6 is currently tied with SLAAC (M,O flags), what means that >>>> a DHCPv6 client have to wait until some RA message arrives to start DHCPv6 >>>> discovery. That unnecessary prolongs whole autoconfiguration process. >>> While I agree with you that the standard is broken in this regard, there is at >>> least one OS vendor that already violates that rule anyway. >>>> Some other issues are also described in [1]. >>>> >>>> I personally prefer to bury SLAAC once forever for several reasons: >>>> - In fact SLAAC does nothing more what DHCPv6 can do. >>> Yes, but, it does it in a much simpler way with a lot less overhead which >>> can be a benefit in some environments. >> I have to admit that less overhead is one of benefit of SLAAC. But >> having experience with DHCP(v4) all devices that we have today (phones, >> cameras, etc.) do not have a problem to process DHCPv4 packets, so there >> is no reason why same devices could not do it for DHCPv6. The sensor >> networks mentioned in one mail before is a very special case of use. I >> believe SLAAC might be useful there but is not typical case. > How many RFID sensors do you see managed on an IPv4 network? Thought so. > The reality is that IPv6 has to support a much much wider range of hardware and applications than were ever considered for IPv4. Just because these may not apply to your environment does not mean that they are not important to other parts of the world. I do not think that there is problem with that. SLAAC can be still an option. Today SLAAC is mandatory and DHCPv6 is an option. > >>>> - SLAAC is quite difficult to secure. One (really only ONE) RA packet >>>> can destroy >>>> the IPv6 connection for all clients in a local network just in a few >>>> milliseconds. >>> This is what RA-Guard is for and it's quite simple to deploy. SEND makes >>> it even better, but is a bit more complicated. >> I can not agree. Access switches usually do not support RA-Guard or >> IPv6-ACLs. For example looking at Cisco portfolio only 4900, 4500, >> 6500, 3750 series supports RA-Guard. In HP 54xx, 82xx, 66xx, 35xx series >> (all with K software). All this series are not suitable (means too >> expensive) in a role of access switches. What worse RA-Guard can be >> easily bypassed >> (http://www.insinuator.net/2011/05/yet-another-update-on-ipv6-security-some-notes-from-the-ipv6-kongress-in-frankfurt/). >> So even if you buy 3 times more expensive switches it does not help you >> :-(. As I wrote before - SEND is not an option today. >> > RA-Guard is in most Juniper switches today. Yes, there are improvements needed. However, it's not like DHCP is immune to spoofing attacks, so, I'm not sure why you think this is so much worse than the current state of IPv4 and/or IPv6 if we went with DHCP only. > >>>> It also happens accidentally by "connection sharing" in Vista, Win7 >>>> >>> This is an argument for burying Windows, not an argument for burying >>> SLAAC. It's not like ICS in IPv4 didn't create rogue DHCP servers. If you >>> were to bury SLAAC, Micr0$0ft would simply switch to breaking DHCPv6 >>> instead of breaking SLAAC. >>> >>>> (https://openwiki.uninett.no//_media/geantcampus:2011-gn3na3t4-ipv6-gregr.pdf) >>>> - The full protection against that behavior it's impossible today. >>>> RA-Guard or >>>> PACL can be bypassed using extension headers or fragmentation >>>> (http://www.mh-sec.de/downloads/mh-ipv6_vulnerabilities.pdf) >>> Yes and no. RA Guard implementations are getting better at addressing >>> those issues. >> How that is getting better. Can you provide an example. >> > No, because some of what I know is currently NDA. However, it's not like vendors aren't hearing about these concerns and it's not like they aren't working to address them. > >>>> - With SLAAC is difficult to implement security features like ARP/ND >>>> protection/inspection, IP source guard/Dynamic lock down, because >>>> all this techniques are based on a MAC-IP database created during >>>> a communication with a DHCP server. There are some attempts (ND >>>> protection, SAVI) >>>> but it does not provide the same level of security. >>> Most sites don't need that level of security. I agree there should be a >>> way to disable SLAAC reliably at a site as a policy matter, but, frankly >>> the techniques you're talking about come in one of two flavors: >>> >>> 1. They dynamically enable the switch to accept packets from >>> a client, in which case, SLAAC based clients would be blocked >>> until they registered with DHCP anyway. >>> or >>> 2. They don't effectively block an attacker who cobbles his own >>> address even without SLAAC. >>> >>> In the former case, you get the security you want and force DHCP anyway, >>> so I don't see a problem. In the latter case, you only had the illusion of >>> security to begin with, so, SLAAC just makes it easy to disillusion you. >> Agree. The firs option is the answer but you have to have DHCPv6 only >> environment. >> > But you don't need to eliminate SLAAC from everyone else's network to make that work. There's no need to deprecate SLAAC/RA from places where it works just fine to achieve what you want. That's my point. > >>>> - Just the same technique was introduced in IPv4 as Router Discovery >>>> (RFC 1256). >>>> Nobody uses it today. Do we really need go through same death way again? >>>> (Oh right, we are already going :-( ) >>> Not a fair comparison. There were a number of additional issues with 1256 that >>> prevented it from gaining acceptance in IPv4. >>> >>>> Comparing to SLAAC, DHCPv6 have several advantages: >>>> - DHCPv6 is very similar to DHCP(v4) and many people are used to using it. >>> That just makes it familiar, not necessarily better for all environments. >>> >>>> - DHCPv6 can potentially do much more - for example handle an information >>>> for PXE, options for IP phones, prefix delegation. >>> True, but, that comes at a cost of complexity and overhead which may not be >>> desirable in all environments. >> As I wrote before. I do not think that overhead is an issue today. >> > And as I wrote before, I think that comes from a narrow view of the implementation spectrum. > >>>> - DHCPv6 allows handle an information only for some hosts or group of >>>> hosts (differed lease time, search list, DNS atc.). With SLAAC it is >>>> impossible and all host on a subnet have to share the same set of >>>> the configuration information. >>> Which is not an issue in 99+% of environments. >>> >>>> - Frankly said, I have not found any significant benefit that SLAAC brings. >>> Perhaps you have not, but, others have. I have seen environments where >>> SLAAC is much more useful than DHCPv6. I've seen environments where >>> DHCPv6 is needed. >> It is true today, because not all operating systems supports DHCPv6. In >> many cases DHCPv6 is not an option. >> > I have seen environments where even if everything supported DHCPv6, SLAAC would still be a better solution for that environment. That's my point. Administrators should be able to choose the solution that best fits their environment. I'm all for the ability to create a DHCP-only environment, but, I don't want to see SLAAC/RA eliminated from environments where it provides benefit. > >>>> Unfortunately there is another issue with DUIDs in DHCPv6. But it is a >>>> little bit differed tale. >>>> >>>> At the beginning the autoconfiguration was meant as easy to use and easy >>>> to configure but the result turned out into kind of nightmare. For those >>>> who do not know what I am talking about I prepared two images. The first >>>> one shows necessary communication before first regular packet can be >>>> send over IPv4 (http://hawk.cis.vutbr.cz/~tpoder/tmp/autoconf/IPv4.png) >>>> and just the same thing in IPv6 >>>> (http://hawk.cis.vutbr.cz/~tpoder/tmp/autoconf/IPv4.png). In IPv4 we >>>> have very simple answer if somebody asks for autoconfiguration = use >>>> DHCP. In IPv6 the description how things work have to be written into >>>> more than 10 pages [1]. I believe that is not what we really wanted. >>>> >>> That's no really a fair characterization. Yes, DHCPv6 is more complex >>> than DHCPv4, but, not significantly so. >>> >>> In reality it can be summed up relatively quickly: >>> >>> 1. Choose link local address (fe80::EUI64) >>> 2. Send RS packet to all-routers multicast address >>> 3. Receive one or more RA packets. >>> a. if Packet contains prefix information: >>> i. Set timers, apply addresses to interfaces >>> (first regular packet can be sent at this point) >>> b. If packet has O bit set: >>> i. Send DHCPv6 request to DHCP server >>> ii. Get response >>> iii. Configure accordingly. >>> (If a was false (a and b are not mutually exclusive), then >>> you can now send your first regular packet). >>> >>> Yes, there are a few corner cases not completely addressed above, >>> but, unless you're building the software to implement the standards, >>> they are mostly irrelevant. Even if you add them in (interactions between >>> the M, A, and O bits), you can still describe it in about a page, not >>> ten. >> And when we compare it with IPv4 >> >> - send DHCP request to DHCP server > Uh, no. DHCP request is never sent by client to DHCP server. Request is sent to broadcast. Then some magic happens (helper address) in most cases to forward it to the DHCP server, then some more magic happens to get the response back to the original client. I deliberately used just the same description of obtaining information from a DHCP server. You have twisted it and trying to show DHCP(v4) in worse light. Just same (as you said) magic happen in DHCPv6. The only difference is that multicast address is used instead. And there is another difference. DHCP(v4) client renews an address (and options) directly from the server where the client get it from. DHCPv6 uses multicast for whole communication. > >> - get response >> - configure accordingly >> > Assuming that the client understands all the correct options, that all the options fit in a single packet, etc., etc., etc. > >> No waiting for RA packets, no additional "IFs", no additional conditions >> and all corner cases are solved. Why it can not work similar in IPv6? I >> know, there maybe is many reasons :-). >> > Uh, no, there are many corner cases I have encountered where DHCPv4 is a non-option and administrators have had no other choice in IPv4 but to use static addressing. Some of them would actually work just fine with SLAAC. Can you be more specific? I can not imagine situation where SLAAC could solves a problem that DHCP would not. So I will be happy to hear that case/cases. Tomas From rps at maine.edu Fri Dec 23 14:09:02 2011 From: rps at maine.edu (Ray Soucy) Date: Fri, 23 Dec 2011 15:09:02 -0500 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EF4DBDE.7050706@cis.vutbr.cz> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF38D5A.4070003@cis.vutbr.cz> <4EF4DBDE.7050706@cis.vutbr.cz> Message-ID: On Fri, Dec 23, 2011 at 2:51 PM, Tomas Podermanski wrote: > That is true, but we know solution for IPv4 (DHCP snooping, ARP > protection, source address validation) and there are access switches on > the market having that security features. Switches supporting such > features for IPv6 are usually much more expensive. And there is another > problem. Although you have money for that hardware it does not protect > you against malicious attacks. Yes, and over time similar Layer-2 security features will become available for IPv6 by default. The more people who work to deploy IPv6 and express these concerns to vendors, the more likely vendors are to give them priority. RA Guard is one such example where vendors have responded to community concerns and have begun to implement the functionality. All these problems exist for IPv4, and I would go as far as to say that the vast majority of networks don't even implement things like ARP inpsection, DHCP snooping, IP source verification, UUFB, etc. They're things that dramatically increase network stability, and things that are used by those of us who run larger networks, but they are certainly not typical by any measure. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From tpoder at cis.vutbr.cz Fri Dec 23 14:19:25 2011 From: tpoder at cis.vutbr.cz (Tomas Podermanski) Date: Fri, 23 Dec 2011 21:19:25 +0100 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> Message-ID: <4EF4E24D.4020107@cis.vutbr.cz> On 12/23/11 6:56 AM, Mohacsi Janos wrote: > > > > On Wed, 21 Dec 2011, Tomas Podermanski wrote: > >> Hi, >> >> from my perspective the short answer for this never-ending story is: >> >> - SLAAC/RA is totally useless, does not bring any benefit at all >> and should be removed from IPv6 specs >> - DHCPv6 should be extended by route options as proposed in >> http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-03 >> - DHCPv6 should be extended by layer 2 address to identify >> client's L2 address (something that we can see in RFC 6221) >> - DHCPv6 should be the common way to autoconfigure an address >> in a IPv6 environment > > Your opinion is very extreme. Another extremity would be to add some > extension into SLAAC/RA and remove DHCPv6 completely. BUT both > mechanisms have their merits. They have to interporate! Every > environment should develop their policy according to their needs! > >> >> The long answer is: >> >> I completely disagree with opinion that both DHCPv6 and RA (SLAAC) >> should be supported. It is easy to say that both have place but it has >> some consequences. I and my colleagues have been working on deploying >> IPv6 for a few years and from the operation perspective we conclude into >> a quite clear opinion in that area. Both SLAAC and DHCPv6 uses a >> opposite principles although the goal is just one. DHCPv6 is based on a >> central DHCPv6 server that assigns addresses. SLAAC does opposite - >> leaves the decision about the address on a client side. However we have >> to run both of them in a network to provide all necessary pieces of >> information to the clients (default route and DNS). This brings many >> implementation and operational complications. >> >> - Clients have to support both SLAAC and DHCPv6 to be able to work in >> both environments > > They already do. If not they have to be fixed. It sounds good, but according to RFC 6434 ( IPv6 Node Requirements) SLAAC is required, but DHCPv6 is only optional. So any manufacturer of operating systems or devices do not have to support DHCPv6. > >> - There must be solved a situation what to do when SLAAC and DHCPv6 >> provides some conflict information (quite long thread with various >> opinions >> can be found at >> http://www.ietf.org/mail-archive/web/ipv6/current/msg14949.html) > > Administrators are deliberately providing conflicting information? Not administrators, but attackers then could have more ways for harmful activity. > >> - The first hop security have to be solved twice - for SLAAC and for >> DHCPv6. Both >> of then uses a differed communication way. SLAAC is part of ICMPv6, >> but DHCPv6 >> uses "own" UDP communication what does not make things easier. > > This can be an argument for remove DHCPv6 completely.... Why not :-), but SLAAC can provide only a subset functionality comparing to DHCPv6. It is actually the reason why DHCPv6 was added into IPv6. Sothe world without DHCPv6 had already been there. > >> - SLAAC is usually processed in a kernel, DHCPv6 is usually run as a >> process in the user space. Diagnostic and troubleshooting is more >> complicated. > > Some operating system do the SLAAC processing in user space. What is > the problem. As I wrote. Troubleshooting is more difficult. > >> - DHCPv6 is currently tied with SLAAC (M,O flags), what means that >> a DHCPv6 client have to wait until some RA message arrives to start >> DHCPv6 >> discovery. That unnecessary prolongs whole autoconfiguration process. > > I think it is matter of implementation. Because DHCPv6 is depended on a information provided by SLAAC (RA messages) and DHCPv6 client have to wait. I hope that this dependency will disappear when the route option is added into DHCPv6. Nice thread on this topic is on http://www.ietf.org/mail-archive/web/dhcwg/current/msg12183.html. > >> >> Some other issues are also described in [1]. >> >> I personally prefer to bury SLAAC once forever for several reasons: >> - In fact SLAAC does nothing more what DHCPv6 can do. > > > But suitable in certain environments. > >> - SLAAC is quite difficult to secure. One (really only ONE) RA packet >> can destroy >> the IPv6 connection for all clients in a local network just in a few >> milliseconds. >> It also happens accidentally by "connection sharing" in Vista, Win7 >> >> (https://openwiki.uninett.no//_media/geantcampus:2011-gn3na3t4-ipv6-gregr.pdf) >> > > Their is an RAguard RFC to prevent this. > >> - The full protection against that behavior it's impossible today. >> RA-Guard or >> PACL can be bypassed using extension headers or fragmentation >> (http://www.mh-sec.de/downloads/mh-ipv6_vulnerabilities.pdf) > > For solution See propoosal of Fernando Gont about atomic ICMPv6 messages. > >> - With SLAAC is difficult to implement security features like ARP/ND >> protection/inspection, IP source guard/Dynamic lock down, because >> all this techniques are based on a MAC-IP database created during >> a communication with a DHCP server. There are some attempts (ND >> protection, SAVI) >> but it does not provide the same level of security. > > > What is missing? It works quite well in DHCPv6 only environments (with M and A flag set). But not all devices supports DHCPv6, because DHCPv6 (as I said) is optional. So it is kind of catch XXII. It was specially problem when apple did not support DHCPv6. So XP and older apple devices can not have IPv6 connectivity in that environment. Fortunately things are going better. Another problem is with support in devices - I discussed it in one of the previous mail. > >> - Just the same technique was introduced in IPv4 as Router Discovery >> (RFC 1256). >> Nobody uses it today. Do we really need go through same death way >> again? >> (Oh right, we are already going :-( ) >> > > Nobody? Every modern Windows OS. I do not know whether Win 7 supports that option (in win 2000, XP there was an option to enable it), but I have never seen any network that uses it to handle router information. If there is any network that uses it I am eager to hear about it. > >> Comparing to SLAAC, DHCPv6 have several advantages: >> - DHCPv6 is very similar to DHCP(v4) and many people are used to >> using it. >> - DHCPv6 can potentially do much more - for example handle an >> information >> for PXE, options for IP phones, prefix delegation. >> - DHCPv6 allows handle an information only for some hosts or group of >> hosts (differed lease time, search list, DNS atc.). With SLAAC it is >> impossible and all host on a subnet have to share the same set of >> the configuration information. > > RA is just matter of swtiching on first hop router. You don't have to > configure anything. > >> - Frankly said, I have not found any significant benefit that SLAAC >> brings. > > Configuration of thousands of device without much overhead on server > side? Agree, can be another advantage. But in fact it seems that networks with thousand devices will rather prefer dhcpv6 instead. > >> >> Unfortunately there is another issue with DUIDs in DHCPv6. But it is a >> little bit differed tale. > > It is a big issue. Agree. > >> >> At the beginning the autoconfiguration was meant as easy to use and easy >> to configure but the result turned out into kind of nightmare. For those >> who do not know what I am talking about I prepared two images. The first >> one shows necessary communication before first regular packet can be >> send over IPv4 (http://hawk.cis.vutbr.cz/~tpoder/tmp/autoconf/IPv4.png) >> and just the same thing in IPv6 >> (http://hawk.cis.vutbr.cz/~tpoder/tmp/autoconf/IPv4.png). In IPv4 we >> have very simple answer if somebody asks for autoconfiguration = use >> DHCP. In IPv6 the description how things work have to be written into >> more than 10 pages [1]. I believe that is not what we really wanted. >> >> For those who are interested in that area there are several >> articles/presentations where we mentioned that topic. >> >> [1] IPv6 Autoconfiguration - Best Practice Document >> http://www.terena.org/activities/campus-bp/pdf/gn3-na3-t4-cbpd117.pdf >> > > It is written very badly! It has to be completed by results from: > http://openwiki.uninett.no/_media/geantcampus:2011-gn3na3t4-ipv6-mohacsi.pdf > It is always matter of a personal opinion. There is always chance to comment, extend, discuss or write the new one document with own point of view. Tomas > > >> [2] IPv6 - security threads >> http://www.fit.vutbr.cz/research/view_pub.php?id=9835 >> >> [3] Deploying IPv6 in University Campus Network - Practical Problems >> http://www.fit.vutbr.cz/research/view_pub.php?id=9836 >> > > Best Regards, > Janos Mohacsi > > >> >> Regards, >> Tomas Podermanski >> >> >> >> On 12/20/11 8:31 AM, Owen DeLong wrote: >>> Different operators will have different preferences in different >>> environments. >>> >>> Ideally, the IETF should provide complete solutions based on DHCPv6 and >>> on RA and let the operators decide what they want to use in their >>> environments. >>> >>> Owen >>> >>> On Dec 19, 2011, at 10:27 PM, Ravi Duggal wrote: >>> >>>> Hi, >>>> >>>> IPv6 devices (routers and hosts) can obtain configuration information >>>> about default routers, on-link prefixes and addresses from Router >>>> Advertisements as defined in Neighbor Discovery. I have been told >>>> that in some deployments, there is a strong desire not to use Router >>>> Advertisements at all and to perform all configuration via DHCPv6. >>>> There are thus similar IETF standards to get everything that you can >>>> get from RAs, by using DHCPv6 instead. >>>> >>>> As a result of this we see new proposals in IETF that try to do >>>> similar things by either extending RA mechanisms or by introducing new >>>> options in DHCPv6. >>>> >>>> We thus have draft-droms-dhc-dhcpv6-default-router-00 that extends >>>> DHCPv6 to do what RA does. And now, we have >>>> draft-bcd-6man-ntp-server-ra-opt-00.txt that extends RA to advertise >>>> the NTP information that is currently done via DHCPv6. >>>> >>>> My question is, that which then is the more preferred option for the >>>> operators? Do they prefer extending RA so that the new information >>>> loaded on top of the RA messages gets known in the single shot when >>>> routers do neighbor discovery. Or do they prefer all the extra >>>> information to be learnt via DHCPv6? What are the pros and cons in >>>> each approach and when would people favor one over the other? >>>> >>>> I can see some advantages with the loading information to RA since >>>> then one is not dependent on the DHCPv6 server. However, the latter >>>> provides its own benefits. >>>> >>>> Regards, >>>> Ravi D. >>> >> >> >> From rps at maine.edu Fri Dec 23 14:33:13 2011 From: rps at maine.edu (Ray Soucy) Date: Fri, 23 Dec 2011 15:33:13 -0500 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EF4DF42.2030709@cis.vutbr.cz> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <9B747991-09CC-47E2-A245-846C3ABD9005@delong.com> <4EF39719.5010802@cis.vutbr.cz> <4EF4DF42.2030709@cis.vutbr.cz> Message-ID: On Fri, Dec 23, 2011 at 3:06 PM, Tomas Podermanski wrote: > Can you be more specific? I can not imagine situation where SLAAC could > solves a problem that DHCP would not. SLAAC is the magic that makes the link-local scope work. I think having a link-local scope is a good thing, so I think I'll keep SLAAC. Now that I'm keeping SLAAC, I think I might as well make it an option for global unicast addressing. DHCPv6, especially on a large scale, does have a cost. A small network doesn't need much of a server, but for a large network the amount of requests can be high. DHCP is also something that isn't trivial to distribute across systems to avoid a single point of failure, there is an entire discussion on the design issues of making a salable DHCP solution, especially if you want more than a generic open pool. I'd say being able to use SLAAC and avoid that complexity is something worth while. RA is much more responsive than DHCP was. When an IPv6 router goes away, hosts can release global addresses for that prefix and fail over gracefully, rather than depending on stale configuration data and blindly sending packets. In the future, we'll likely see RA leveraged to provide better availability than we've seen with IPv4. Then there is the entire issue of someone misconfiguring a DHCP server and having to run around rebooting systems to get them to drop the bogus information (or wait for leases to expire, typically several hours). At least with RA + DHCPv6 you can recover from this in a reasonable amount of time. There are other special case considerations; extensions like privacy addressing kind of become not so private if everything is being logged by a DHCPv6 server. It's legitimate that you might want a network where the anonymity of users is provided. Especially as we continue to see increased requirements for log retention by governments. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From Valdis.Kletnieks at vt.edu Fri Dec 23 14:36:46 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 23 Dec 2011 15:36:46 -0500 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: Your message of "Fri, 23 Dec 2011 21:19:25 +0100." <4EF4E24D.4020107@cis.vutbr.cz> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF4E24D.4020107@cis.vutbr.cz> Message-ID: <108984.1324672606@turing-police.cc.vt.edu> On Fri, 23 Dec 2011 21:19:25 +0100, Tomas Podermanski said: > It sounds good, but according to RFC 6434 ( IPv6 Node Requirements) > SLAAC is required, but DHCPv6 is only optional. So any manufacturer of > operating systems or devices do not have to support DHCPv6. Strictly speaking, they don't *have* to support IPv6 at all. And until very recently, there was very little market incentive for them to do so. You want DHCPv6 support? It happens in one of two ways: 1) Deploy it yourself using open-source pieces. 2) You tell the vendor "You ship DHCPv6 or we'll find another solution that has it". It's been that way since the big players were Bay and Proteon, not Cisco and Juniper. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Fri Dec 23 14:44:30 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 23 Dec 2011 15:44:30 -0500 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: Your message of "Fri, 23 Dec 2011 21:06:26 +0100." <4EF4DF42.2030709@cis.vutbr.cz> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <9B747991-09CC-47E2-A245-846C3ABD9005@delong.com> <4EF39719.5010802@cis.vutbr.cz> <4EF4DF42.2030709@cis.vutbr.cz> Message-ID: <109176.1324673070@turing-police.cc.vt.edu> On Fri, 23 Dec 2011 21:06:26 +0100, Tomas Podermanski said: > On 12/23/11 4:33 AM, Owen DeLong wrote: > > If there is actual real world demand for it, it will get implemented. > > Reality is that today, DHCPv4 has been running just as insecure for many years > > and nobody cares. I don't know why the bar for IPv6 should be so much higher > > than IPv4. > I can not agree with that. Many operators having customers into a shared > segment and uses security features I mentioned before ( again DHCP > snooping, ARP protection, source address validation). Hate to inject some reality here - but Owen is totally correct here. That's all stuff you do *because DHCPv4 is an insecure protocol*. And a *lot* of places don't do all that added security on the IPv4 side because it's not part of their threat model, and probably don't want it on the IPv6 side for the same exact reasons. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From tpoder at cis.vutbr.cz Fri Dec 23 14:50:12 2011 From: tpoder at cis.vutbr.cz (Tomas Podermanski) Date: Fri, 23 Dec 2011 21:50:12 +0100 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF38D5A.4070003@cis.vutbr.cz> <4EF4DBDE.7050706@cis.vutbr.cz> Message-ID: <4EF4E984.1050102@cis.vutbr.cz> Hi, On 12/23/11 9:09 PM, Ray Soucy wrote: > On Fri, Dec 23, 2011 at 2:51 PM, Tomas Podermanski wrote: > >> That is true, but we know solution for IPv4 (DHCP snooping, ARP >> protection, source address validation) and there are access switches on >> the market having that security features. Switches supporting such >> features for IPv6 are usually much more expensive. And there is another >> problem. Although you have money for that hardware it does not protect >> you against malicious attacks. > Yes, and over time similar Layer-2 security features will become > available for IPv6 by default. The more people who work to deploy > IPv6 and express these concerns to vendors, the more likely vendors > are to give them priority. > > RA Guard is one such example where vendors have responded to community > concerns and have begun to implement the functionality. > > All these problems exist for IPv4, and I would go as far as to say > that the vast majority of networks don't even implement things like > ARP inpsection, DHCP snooping, IP source verification, UUFB, etc. > They're things that dramatically increase network stability, and > things that are used by those of us who run larger networks, but they > are certainly not typical by any measure. I agree with you, that is not typical for many networks. For example in our network we have enabled some of that features (not all) only in some subnets. Unfortunately those subnets connects over 70% of our users (6500). Is also great that many produces are going to take that issues seriously. Actually we have quite big concerns with decision if: 1. to buy cheaper access switches (like HP 42xx) that have security features for IPv4 but will never have support for IPv6. The hardware does not support IPv6 at all. In that case we will be able to replace access switches in quite short time - one year. And in next five years we will be buy a brand new generation of switches that will have all those problems solved (I hope). or 2. to buy much more expensive switches (like HP 54xx) that supports some basic security features for IPv6 and there is some a probability that other features will be implemented. So we will be able to use ra-guard and ACLs immediately. In that case there is still a chance that some features will not be implemented due to hardware limits. So we will have to buy new generation of switches again in five years. Tomas From mohta at necom830.hpcl.titech.ac.jp Fri Dec 23 14:52:47 2011 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 24 Dec 2011 05:52:47 +0900 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EF4CCE0.5060304@rancid.berkeley.edu> References: <4EF28A00.2080904@kl.net> <4EF3C864.60807@necom830.hpcl.titech.ac.jp> <4EF4CCE0.5060304@rancid.berkeley.edu> Message-ID: <4EF4EA1F.3060900@necom830.hpcl.titech.ac.jp> Michael Sinatra wrote: > The only time you need to perform extra steps is when you want to run > DHCPv6. You need to enable the M and/or O flags and turn off the > 'autonomous' flag (if you don't want a host to get both SLAAC addresses > and DHCPv6 addresses. That's a configuration of RA, not DHCPv6. > Then you need to turn on relaying unless you are > putting the DHCPv6 server on the same wire. As I wrote: > Just as most, if not all, NAT boxes have preconfigured DHCPv4 > service to offer part of preconfigured private address > space, home IPv6 routers may have preconfigured DHCPv6 > service to offer part of configured public address space. local DHCPv6 server should be running locally by default. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Fri Dec 23 15:00:16 2011 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 24 Dec 2011 06:00:16 +0900 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EF4E24D.4020107@cis.vutbr.cz> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF4E24D.4020107@cis.vutbr.cz> Message-ID: <4EF4EBE0.4050609@necom830.hpcl.titech.ac.jp> Tomas Podermanski wrote: > It sounds good, but according to RFC 6434 ( IPv6 Node Requirements) > SLAAC is required, Not at all. SLAAC is required only if ND is supported, which is optional. Note that ND works poorly over link layers such as 802.11 where multicast is unreliable. > but DHCPv6 is only optional. DHCPv6 works over link layers with unreliable multicast better than ND. Masataka Ohta So any manufacturer of > operating systems or devices do not have to support DHCPv6. > >> >>> - There must be solved a situation what to do when SLAAC and DHCPv6 >>> provides some conflict information (quite long thread with various >>> opinions >>> can be found at >>> http://www.ietf.org/mail-archive/web/ipv6/current/msg14949.html) >> >> Administrators are deliberately providing conflicting information? > > Not administrators, but attackers then could have more ways for harmful > activity. > >> >>> - The first hop security have to be solved twice - for SLAAC and for >>> DHCPv6. Both >>> of then uses a differed communication way. SLAAC is part of ICMPv6, >>> but DHCPv6 >>> uses "own" UDP communication what does not make things easier. >> >> This can be an argument for remove DHCPv6 completely.... > > Why not :-), but SLAAC can provide only a subset functionality comparing > to DHCPv6. It is actually the reason why DHCPv6 was added into IPv6. > Sothe world without DHCPv6 had already been there. > >> >>> - SLAAC is usually processed in a kernel, DHCPv6 is usually run as a >>> process in the user space. Diagnostic and troubleshooting is more >>> complicated. >> >> Some operating system do the SLAAC processing in user space. What is >> the problem. > > As I wrote. Troubleshooting is more difficult. > >> >>> - DHCPv6 is currently tied with SLAAC (M,O flags), what means that >>> a DHCPv6 client have to wait until some RA message arrives to start >>> DHCPv6 >>> discovery. That unnecessary prolongs whole autoconfiguration process. >> >> I think it is matter of implementation. > > Because DHCPv6 is depended on a information provided by SLAAC (RA > messages) and DHCPv6 client have to wait. I hope that this dependency > will disappear when the route option is added into DHCPv6. Nice thread > on this topic is on > http://www.ietf.org/mail-archive/web/dhcwg/current/msg12183.html. > >> >>> >>> Some other issues are also described in [1]. >>> >>> I personally prefer to bury SLAAC once forever for several reasons: >>> - In fact SLAAC does nothing more what DHCPv6 can do. >> >> >> But suitable in certain environments. >> >>> - SLAAC is quite difficult to secure. One (really only ONE) RA packet >>> can destroy >>> the IPv6 connection for all clients in a local network just in a few >>> milliseconds. >>> It also happens accidentally by "connection sharing" in Vista, Win7 >>> >>> (https://openwiki.uninett.no//_media/geantcampus:2011-gn3na3t4-ipv6-gregr.pdf) >>> >> >> Their is an RAguard RFC to prevent this. >> >>> - The full protection against that behavior it's impossible today. >>> RA-Guard or >>> PACL can be bypassed using extension headers or fragmentation >>> (http://www.mh-sec.de/downloads/mh-ipv6_vulnerabilities.pdf) >> >> For solution See propoosal of Fernando Gont about atomic ICMPv6 messages. >> >>> - With SLAAC is difficult to implement security features like ARP/ND >>> protection/inspection, IP source guard/Dynamic lock down, because >>> all this techniques are based on a MAC-IP database created during >>> a communication with a DHCP server. There are some attempts (ND >>> protection, SAVI) >>> but it does not provide the same level of security. >> >> >> What is missing? > > It works quite well in DHCPv6 only environments (with M and A flag set). > But not all devices supports DHCPv6, because DHCPv6 (as I said) is > optional. So it is kind of catch XXII. It was specially problem when > apple did not support DHCPv6. So XP and older apple devices can not have > IPv6 connectivity in that environment. Fortunately things are going > better. Another problem is with support in devices - I discussed it in > one of the previous mail. > >> >>> - Just the same technique was introduced in IPv4 as Router Discovery >>> (RFC 1256). >>> Nobody uses it today. Do we really need go through same death way >>> again? >>> (Oh right, we are already going :-( ) >>> >> >> Nobody? Every modern Windows OS. > > I do not know whether Win 7 supports that option (in win 2000, XP there > was an option to enable it), but I have never seen any network that uses > it to handle router information. If there is any network that uses it I > am eager to hear about it. > >> >>> Comparing to SLAAC, DHCPv6 have several advantages: >>> - DHCPv6 is very similar to DHCP(v4) and many people are used to >>> using it. >>> - DHCPv6 can potentially do much more - for example handle an >>> information >>> for PXE, options for IP phones, prefix delegation. >>> - DHCPv6 allows handle an information only for some hosts or group of >>> hosts (differed lease time, search list, DNS atc.). With SLAAC it is >>> impossible and all host on a subnet have to share the same set of >>> the configuration information. >> >> RA is just matter of swtiching on first hop router. You don't have to >> configure anything. >> >>> - Frankly said, I have not found any significant benefit that SLAAC >>> brings. >> >> Configuration of thousands of device without much overhead on server >> side? > > Agree, can be another advantage. But in fact it seems that networks with > thousand devices will rather prefer dhcpv6 instead. > > >> >>> >>> Unfortunately there is another issue with DUIDs in DHCPv6. But it is a >>> little bit differed tale. >> >> It is a big issue. > > Agree. > >> >>> >>> At the beginning the autoconfiguration was meant as easy to use and easy >>> to configure but the result turned out into kind of nightmare. For those >>> who do not know what I am talking about I prepared two images. The first >>> one shows necessary communication before first regular packet can be >>> send over IPv4 (http://hawk.cis.vutbr.cz/~tpoder/tmp/autoconf/IPv4.png) >>> and just the same thing in IPv6 >>> (http://hawk.cis.vutbr.cz/~tpoder/tmp/autoconf/IPv4.png). In IPv4 we >>> have very simple answer if somebody asks for autoconfiguration = use >>> DHCP. In IPv6 the description how things work have to be written into >>> more than 10 pages [1]. I believe that is not what we really wanted. >>> >>> For those who are interested in that area there are several >>> articles/presentations where we mentioned that topic. >>> >>> [1] IPv6 Autoconfiguration - Best Practice Document >>> http://www.terena.org/activities/campus-bp/pdf/gn3-na3-t4-cbpd117.pdf >>> >> >> It is written very badly! It has to be completed by results from: >> http://openwiki.uninett.no/_media/geantcampus:2011-gn3na3t4-ipv6-mohacsi.pdf >> > > It is always matter of a personal opinion. There is always chance to > comment, extend, discuss or write the new one document with own point of > view. > > > Tomas > >> >> >>> [2] IPv6 - security threads >>> http://www.fit.vutbr.cz/research/view_pub.php?id=9835 >>> >>> [3] Deploying IPv6 in University Campus Network - Practical Problems >>> http://www.fit.vutbr.cz/research/view_pub.php?id=9836 >>> >> >> Best Regards, >> Janos Mohacsi >> >> >>> >>> Regards, >>> Tomas Podermanski >>> >>> >>> >>> On 12/20/11 8:31 AM, Owen DeLong wrote: >>>> Different operators will have different preferences in different >>>> environments. >>>> >>>> Ideally, the IETF should provide complete solutions based on DHCPv6 and >>>> on RA and let the operators decide what they want to use in their >>>> environments. >>>> >>>> Owen >>>> >>>> On Dec 19, 2011, at 10:27 PM, Ravi Duggal wrote: >>>> >>>>> Hi, >>>>> >>>>> IPv6 devices (routers and hosts) can obtain configuration information >>>>> about default routers, on-link prefixes and addresses from Router >>>>> Advertisements as defined in Neighbor Discovery. I have been told >>>>> that in some deployments, there is a strong desire not to use Router >>>>> Advertisements at all and to perform all configuration via DHCPv6. >>>>> There are thus similar IETF standards to get everything that you can >>>>> get from RAs, by using DHCPv6 instead. >>>>> >>>>> As a result of this we see new proposals in IETF that try to do >>>>> similar things by either extending RA mechanisms or by introducing new >>>>> options in DHCPv6. >>>>> >>>>> We thus have draft-droms-dhc-dhcpv6-default-router-00 that extends >>>>> DHCPv6 to do what RA does. And now, we have >>>>> draft-bcd-6man-ntp-server-ra-opt-00.txt that extends RA to advertise >>>>> the NTP information that is currently done via DHCPv6. >>>>> >>>>> My question is, that which then is the more preferred option for the >>>>> operators? Do they prefer extending RA so that the new information >>>>> loaded on top of the RA messages gets known in the single shot when >>>>> routers do neighbor discovery. Or do they prefer all the extra >>>>> information to be learnt via DHCPv6? What are the pros and cons in >>>>> each approach and when would people favor one over the other? >>>>> >>>>> I can see some advantages with the loading information to RA since >>>>> then one is not dependent on the DHCPv6 server. However, the latter >>>>> provides its own benefits. >>>>> >>>>> Regards, >>>>> Ravi D. >>>> >>> >>> >>> > > > From mohacsi at niif.hu Fri Dec 23 15:13:54 2011 From: mohacsi at niif.hu (Mohacsi Janos) Date: Fri, 23 Dec 2011 22:13:54 +0100 (CET) Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EF4DBDE.7050706@cis.vutbr.cz> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF38D5A.4070003@cis.vutbr.cz> <4EF4DBDE.7050706@cis.vutbr.cz> Message-ID: On Fri, 23 Dec 2011, Tomas Podermanski wrote: > > Port security does not help in that case (same as 802.1x). Port security > is a layer 2 feature so all layer 3 attacks can be still performed. That > prevents only against source MAC address spoofing. All other attacks > like DAD DOS, NDP Exhaustion, RA flooding etc. can be performed even > though the port security is implemented. If you can limit number of ARP/NDP entries per interfaces and you complement RAGuard and DHCPv4 snooping your are done. With "extended port security" such a features are comming... Best Regards, Janos Mohacsi From mohacsi at niif.hu Fri Dec 23 15:22:09 2011 From: mohacsi at niif.hu (Mohacsi Janos) Date: Fri, 23 Dec 2011 22:22:09 +0100 (CET) Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EF4E24D.4020107@cis.vutbr.cz> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF4E24D.4020107@cis.vutbr.cz> Message-ID: On Fri, 23 Dec 2011, Tomas Podermanski wrote: > > > It sounds good, but according to? RFC 6434 ( IPv6 Node Requirements) SLAAC is required, but DHCPv6 is only optional. So any > manufacturer of operating systems or devices do not have to support DHCPv6. You might propose updating RFC 6434 > > Administrators are deliberately providing conflicting information? > > > Not administrators, but attackers then could have more ways for harmful activity. That is why you are administrator - closely monitor your network. > > Some operating system do the SLAAC processing in user space. What is the problem. > > > As I wrote. Troubleshooting is more difficult. Both can difficult to troubleshhoot > > > - DHCPv6 is currently tied with SLAAC (M,O flags), what means that > ?a DHCPv6 client have to wait until some RA message arrives to start DHCPv6 > ?discovery. That unnecessary prolongs whole autoconfiguration process. > > > I think it is matter of implementation. > > > Because DHCPv6 is depended on a information provided by SLAAC (RA messages) and DHCPv6 client have to wait. I hope that this dependency > will disappear when the route option is added into DHCPv6. Nice thread on this topic is on > http://www.ietf.org/mail-archive/web/dhcwg/current/msg12183.html. In my opinion client can ask address via DHPv6 without paying attention to RA messages. > > > Agree, can be another advantage. But in fact it seems that networks with thousand devices will rather prefer dhcpv6 instead. As other already mentioned: SLAAC for less controlled, more resource concerned environment. DHCPv6 for more tightly controlled ones. Best Regards, Janos Mohacsi From jsw at inconcepts.biz Fri Dec 23 15:23:31 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Fri, 23 Dec 2011 16:23:31 -0500 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF38D5A.4070003@cis.vutbr.cz> <4EF4DBDE.7050706@cis.vutbr.cz> Message-ID: On Fri, Dec 23, 2011 at 4:13 PM, Mohacsi Janos wrote: > If you can limit number of ARP/NDP entries per interfaces and you complement > RAGuard and DHCPv4 snooping your are done. That depends on how ARP/ND gleaning works on the box. In short, Cisco already has a knob to limit the number of ND entries per interface on some of their kit, and it is not a solution, only a damage mitigation measure. http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From mohacsi at niif.hu Fri Dec 23 15:36:44 2011 From: mohacsi at niif.hu (Mohacsi Janos) Date: Fri, 23 Dec 2011 22:36:44 +0100 (CET) Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF38D5A.4070003@cis.vutbr.cz> <4EF4DBDE.7050706@cis.vutbr.cz> Message-ID: On Fri, 23 Dec 2011, Jeff Wheeler wrote: > On Fri, Dec 23, 2011 at 4:13 PM, Mohacsi Janos wrote: >> If you can limit number of ARP/NDP entries per interfaces and you complement >> RAGuard and DHCPv4 snooping your are done. > > That depends on how ARP/ND gleaning works on the box. In short, Cisco > already has a knob to limit the number of ND entries per interface on > some of their kit, and it is not a solution, only a damage mitigation > measure. http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf The solution is that you monitor your device: if limits reached then you get notified and you can resolve the problem. Best Regards, Janos Mohacsi > > -- > Jeff S Wheeler > Sr Network Operator? /? Innovative Network Concepts > > From cidr-report at potaroo.net Fri Dec 23 16:00:01 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 23 Dec 2011 22:00:01 GMT Subject: BGP Update Report Message-ID: <201112232200.pBNM01l6026863@wattle.apnic.net> BGP Update Report Interval: 15-Dec-11 -to- 22-Dec-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS42116 153691 8.4% 3073.8 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 2 - AS9829 47003 2.6% 72.3 -- BSNL-NIB National Internet Backbone 3 - AS8402 46674 2.5% 28.3 -- CORBINA-AS OJSC "Vimpelcom" 4 - AS5800 31418 1.7% 111.4 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 5 - AS32528 24957 1.4% 4991.4 -- ABBOTT Abbot Labs 6 - AS12479 24864 1.4% 350.2 -- UNI2-AS France Telecom Espana SA 7 - AS7552 21848 1.2% 14.7 -- VIETEL-AS-AP Vietel Corporation 8 - AS20632 19971 1.1% 512.1 -- PETERSTAR-AS PeterStar 9 - AS43348 16000 0.9% 125.0 -- TATARINOVA-AS PE Tatarinova Alla Ivanovna 10 - AS55515 15659 0.8% 652.5 -- ONE-NET-HK INTERNET-SOLUTION -HK 11 - AS19223 12913 0.7% 4304.3 -- NTEGRATED-SOLUTIONS - Ntegrated Solutions 12 - AS24560 12838 0.7% 18.5 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 13 - AS17974 12219 0.7% 9.4 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 14 - AS1273 11958 0.7% 161.6 -- CW Cable and Wireless Worldwide plc 15 - AS27738 11913 0.7% 34.9 -- Ecuadortelecom S.A. 16 - AS14420 11441 0.6% 23.4 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 17 - AS39353 11338 0.6% 3779.3 -- PRINCAST-AS Gobierno del Principado de Asturias 18 - AS6072 10584 0.6% 756.0 -- UNISYS-6072 For routing issues, email hostmaster at unisys.com 19 - AS9498 10158 0.6% 15.4 -- BBIL-AP BHARTI Airtel Ltd. 20 - AS17639 9931 0.5% 121.1 -- COMCLARK-AS ComClark Network & Technology Corp. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS32528 24957 1.4% 4991.4 -- ABBOTT Abbot Labs 2 - AS10209 4887 0.3% 4887.0 -- SYNOPSYS-AS-JP-AP Japan HUB and Data Center 3 - AS19223 12913 0.7% 4304.3 -- NTEGRATED-SOLUTIONS - Ntegrated Solutions 4 - AS39353 11338 0.6% 3779.3 -- PRINCAST-AS Gobierno del Principado de Asturias 5 - AS42116 153691 8.4% 3073.8 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 6 - AS37378 2347 0.1% 2347.0 -- NIGERIA-AIRFORCE 7 - AS9254 1271 0.1% 1271.0 -- DELMONTE-AS-PH-AP Del Monte Philippines, Inc. 8 - AS46023 1048 0.1% 1048.0 -- QUANTUMNET-AS-ID PT Quantum Tera Network 9 - AS53362 972 0.1% 972.0 -- MIXIT-AS - Mixit, Inc. 10 - AS31598 856 0.1% 856.0 -- TELECOMAX-AS TELECOMAX 11 - AS3 842 0.1% 241.0 -- SISLAB-AS SIS Laboratory, LLC 12 - AS8163 801 0.0% 801.0 -- METROTEL REDES S.A. 13 - AS6072 10584 0.6% 756.0 -- UNISYS-6072 For routing issues, email hostmaster at unisys.com 14 - AS26004 664 0.0% 664.0 -- AUTOWEB-AS01 - Trubiquity Inc 15 - AS48068 661 0.0% 661.0 -- VISONIC Visonic Ltd 16 - AS45723 658 0.0% 658.0 -- OMADATA-AS-ID Omadata Indonesia, PT 17 - AS55515 15659 0.8% 652.5 -- ONE-NET-HK INTERNET-SOLUTION -HK 18 - AS50091 644 0.0% 644.0 -- NEGENET Negenet, N.T.P.SH 19 - AS24562 1677 0.1% 559.0 -- UNESCAP-AS-AP The United Nations Economic and Social Commission for Asia and the Pacific (ESCAP) 20 - AS21863 532 0.0% 532.0 -- DMVNOC - Internet Connection TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 84.204.132.0/24 19777 1.0% AS20632 -- PETERSTAR-AS PeterStar 2 - 67.97.156.0/24 12909 0.7% AS19223 -- NTEGRATED-SOLUTIONS - Ntegrated Solutions 3 - 130.36.35.0/24 12472 0.6% AS32528 -- ABBOTT Abbot Labs 4 - 130.36.34.0/24 12470 0.6% AS32528 -- ABBOTT Abbot Labs 5 - 88.151.16.0/22 11334 0.6% AS39353 -- PRINCAST-AS Gobierno del Principado de Asturias 6 - 62.36.252.0/22 7678 0.4% AS12479 -- UNI2-AS France Telecom Espana SA 7 - 95.78.108.0/22 6498 0.3% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 8 - 95.78.88.0/22 6496 0.3% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 9 - 95.78.116.0/22 6492 0.3% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 10 - 95.78.100.0/22 6485 0.3% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 11 - 176.213.100.0/22 6484 0.3% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 12 - 95.78.84.0/22 6480 0.3% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 13 - 46.147.120.0/22 6474 0.3% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 14 - 95.78.0.0/22 6463 0.3% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 15 - 46.147.68.0/22 6453 0.3% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 16 - 95.78.4.0/22 6453 0.3% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 17 - 46.147.72.0/22 6446 0.3% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 18 - 95.78.20.0/22 6443 0.3% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 19 - 46.147.76.0/22 6436 0.3% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 20 - 95.78.16.0/22 6435 0.3% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 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 cidr-report at potaroo.net Fri Dec 23 16:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 23 Dec 2011 22:00:00 GMT Subject: The Cidr Report Message-ID: <201112232200.pBNM00sC026852@wattle.apnic.net> This report has been generated at Fri Dec 23 21:12:13 2011 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 16-12-11 385889 227873 17-12-11 389196 227642 18-12-11 389128 227738 19-12-11 389199 226868 20-12-11 388637 226734 21-12-11 388688 227520 22-12-11 388706 227460 23-12-11 388955 227357 AS Summary 39773 Number of ASes in routing system 16736 Number of ASes announcing only one prefix 3470 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 109243392 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'). --- 23Dec11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 389359 227438 161921 41.6% All ASes AS6389 3470 222 3248 93.6% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS18566 2093 412 1681 80.3% COVAD - Covad Communications Co. AS4766 2492 990 1502 60.3% KIXS-AS-KR Korea Telecom AS7029 2958 1525 1433 48.4% WINDSTREAM - Windstream Communications Inc AS22773 1515 116 1399 92.3% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1512 201 1311 86.7% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS4323 1622 387 1235 76.1% TWTC - tw telecom holdings, inc. AS28573 1574 365 1209 76.8% NET Servicos de Comunicao S.A. AS10620 1720 642 1078 62.7% Telmex Colombia S.A. AS1785 1863 787 1076 57.8% AS-PAETEC-NET - PaeTec Communications, Inc. AS7552 1420 402 1018 71.7% VIETEL-AS-AP Vietel Corporation AS19262 1389 402 987 71.1% VZGNI-TRANSIT - Verizon Online LLC AS7303 1249 364 885 70.9% Telecom Argentina S.A. AS18101 975 158 817 83.8% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS8151 1457 659 798 54.8% Uninet S.A. de C.V. AS8402 1553 762 791 50.9% CORBINA-AS OJSC "Vimpelcom" AS30036 1466 694 772 52.7% MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp AS4808 1076 338 738 68.6% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS15557 1092 365 727 66.6% LDCOMNET Societe Francaise du Radiotelephone S.A AS24560 1012 287 725 71.6% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7545 1628 946 682 41.9% TPG-INTERNET-AP TPG Internet Pty Ltd AS3356 1105 459 646 58.5% LEVEL3 Level 3 Communications AS2118 672 61 611 90.9% RELCOM-AS OOO "NPO Relcom" AS17974 1716 1110 606 35.3% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS17676 676 74 602 89.1% GIGAINFRA Softbank BB Corp. AS4804 663 95 568 85.7% MPX-AS Microplex PTY LTD AS20115 1612 1060 552 34.2% CHARTER-NET-HKY-NC - Charter Communications AS3549 971 420 551 56.7% GBLX Global Crossing Ltd. AS9498 857 308 549 64.1% BBIL-AP BHARTI Airtel Ltd. AS22047 582 33 549 94.3% VTR BANDA ANCHA S.A. Total 43990 14644 29346 66.7% 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- 37.25.64.0/21 AS33828 IPTOX-AS iptoX GmbH 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 66.129.0.0/19 AS3901 ARRAKIS - Higher Technology Services 66.175.222.0/23 AS30058 FDCSERVERS - FDCservers.net 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 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 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 80.88.10.0/24 AS33774 DJAWEB 91.234.44.0/23 AS57015 SENSITIVE-TELECOM Sensitive Line SRL 91.234.46.0/24 AS57015 SENSITIVE-TELECOM Sensitive Line SRL 98.159.96.0/20 AS46975 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 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 Inc. 172.45.1.0/24 AS29571 CITelecom-AS 172.45.2.0/24 AS29571 CITelecom-AS 172.45.3.0/24 AS29571 CITelecom-AS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 190.104.32.0/21 AS27882 Telef?nica Celular de Bolivia S.A. 193.0.22.0/23 AS3333 RIPE-NCC-AS RIPE Network Coordination Centre 200.6.93.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.94.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.95.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.23.84.0/24 AS8151 Uninet S.A. de C.V. 200.24.73.0/24 AS26061 Equant Colombia 200.33.40.0/24 AS11172 Alestra, S. de R.L. de C.V. 200.34.0.0/20 AS6342 Instituto Tecnol?gico y de Estudios Superiores de Monterrey 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 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.9.55.0/24 AS2764 AAPT AAPT Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 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.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.160.152.0/22 AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 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.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 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - KNOLOGY, Inc. 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.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.91.56.0/21 AS22241 IC2NET - IC2NET 208.91.56.0/24 AS22241 IC2NET - IC2NET 208.91.57.0/24 AS22241 IC2NET - IC2NET 208.91.58.0/24 AS22241 IC2NET - IC2NET 208.91.59.0/24 AS22241 IC2NET - IC2NET 208.91.60.0/24 AS22241 IC2NET - IC2NET 208.91.61.0/24 AS22241 IC2NET - IC2NET 208.91.62.0/24 AS22241 IC2NET - IC2NET 208.91.63.0/24 AS22241 IC2NET - IC2NET 209.133.224.0/19 AS4323 TWTC - tw telecom holdings, inc. 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 209.222.240.0/22 AS19747 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.97.0/24 AS13333 CCI-PA-AS-1 - Consolidated Communications, Inc. 216.170.98.0/24 AS13333 CCI-PA-AS-1 - Consolidated Communications, Inc. 216.170.99.0/24 AS13333 CCI-PA-AS-1 - Consolidated Communications, Inc. 216.170.100.0/24 AS13333 CCI-PA-AS-1 - Consolidated Communications, Inc. 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.102.0/24 AS13333 CCI-PA-AS-1 - Consolidated Communications, Inc. 216.170.103.0/24 AS13333 CCI-PA-AS-1 - Consolidated Communications, Inc. 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.106.0/24 AS13333 CCI-PA-AS-1 - Consolidated Communications, Inc. 216.170.107.0/24 AS13333 CCI-PA-AS-1 - Consolidated Communications, Inc. 216.170.108.0/24 AS13333 CCI-PA-AS-1 - Consolidated Communications, Inc. 216.170.109.0/24 AS13333 CCI-PA-AS-1 - Consolidated Communications, Inc. 216.170.110.0/24 AS13333 CCI-PA-AS-1 - Consolidated Communications, Inc. 216.170.111.0/24 AS13333 CCI-PA-AS-1 - Consolidated Communications, Inc. 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From nanog2 at adns.net Fri Dec 23 16:57:02 2011 From: nanog2 at adns.net (John Palmer (NANOG Acct)) Date: Fri, 23 Dec 2011 16:57:02 -0600 Subject: Well Lookie Here, Barracuda Networks tries to get me to fall into their trap again... References: <20111221104148.4565907e@jpeach-desktop.anbg.mssm.edu> <1449422.1440.1324490075558.JavaMail.root@benjamin.baylink.com> <8C26A4FDAE599041A13EB499117D3C286B6354A8@ex-mb-1.corp.atlasnetworks.us> <2F1D4FA4-107A-49C4-B5E5-CD40B282B9B2@freethought-internet.co.uk> <4EF3631C.8030600@houseofzen.org> <20111222184745.GA69040@ussenterprise.ufp.org> <4EF37CFF.3020109@mtcc.com> <4EF38358.40705@mtcc.com> Message-ID: Actually, the unit still works as an e-mail filter. You can still access the Barracuda "reputation" list with it and it does SPF and Baysian filtering still. It also lets you configure black lists and other RBLs as well, so it still has utility. The thing that you don't get is updated SPAM and virus defs as well as updated software for the machine. Someone mentioned the fact that if the hardware is still working, then the renewal policy is reasonable since the machine still works. May I remind that person that Barracuda charges you for the hardware AND also the subscriptions to the spam and virus defs. If they provided the hardware for free, then I would agree with him about the renewal policy, but its NOT free. ----- Original Message ----- From: "Michael Thomas" To: "Jon Lewis" Cc: Sent: Thursday, December 22, 2011 1:22 PM Subject: Re: Well Lookie Here, Barracuda Networks tries to get me to fall into their trap again... > On 12/22/2011 11:07 AM, Jon Lewis wrote: >> On Thu, 22 Dec 2011, Michael Thomas wrote: >> >>> At that point why should they sell iron at all? Seems like you get >>> all of the downside of owning the iron, and all of the downside of >>> paying for a cloud based service. Either you own what you own, >>> or you pay for service that somebody else provides. This "you >>> bought useless hardware unless you pay up" is really what's >>> infuriating. >> >> Presumably, Barracuda's hardware is i386/i686 compatible commodity parts. It's probably not at all "useless". Just attach a USB >> DVD drive or USB flash drive, wipe the disk(s) and install your favorite Linux distro. >> It may take some doing to get all/most of the features Barracuda provides setup on your own...but if you don't have the >> time/expertise to do it, that's why companies like Barracuda exist. > > If the spam filter stop working, it's presumably a pretty useless thing > as a... spam filtering device which is presumably why most people are > buying barracuda boxen. I suppose my larger point is that this is why > companies like postini exist. At least there you know that if you don't > pay the bill, mail stops flowing altogether much like any other service. > It's this "I paid for the hardware, but I don't really own what I paid for" > state that seems to stick in people's craw. Or maybe if they just leased > the box it would be more clear what their business model was. > > Mike > > From joelja at bogus.com Fri Dec 23 17:08:43 2011 From: joelja at bogus.com (Joel jaeggli) Date: Fri, 23 Dec 2011 15:08:43 -0800 Subject: Speed Test Results In-Reply-To: References: <1324631920.7845.YahooMailNeo@web39508.mail.mud.yahoo.com> Message-ID: <4EF509FB.9000201@bogus.com> On 12/23/11 11:16 , Joel Maslak wrote: > On Fri, Dec 23, 2011 at 2:18 AM, jacob miller wrote: > >> Am having a debate on the results of speed tests sites. >> >> Am interested in knowing the thoughts of different individuals in regards to this. > > It's one data point of many. > > Depending on the speed test site, the protocols it uses, where the > test is located, any local networking gear (I've seen transparent > proxies get great speedtest ratings!), etc, they can be useful, > particularly in verifying that a provider's off-net interconnects and > partners are doing well. > > However, they are susceptible to things like wireless network issues, > TCP limitations (one stream vs. many streams), and misconfiguration of > devices at the customer location. And the speed test box isn't > necessarily configured/speced correctly either. I don't imagine it accounts for l3 emcp either... To be clear, what one is I assume generally looking for from a speed test is usable throughput from the vantage point of the end-user running it. > I second the thoughts on NDT and I like the ICSI Netalyzer. But I > wouldn't necessarily put either tool in most end users' hands (I think > they are too complex for most end users to interpret the results > properly). > From lstewart at superb.net Fri Dec 23 17:50:35 2011 From: lstewart at superb.net (Landon Stewart) Date: Fri, 23 Dec 2011 15:50:35 -0800 Subject: Speed Test Results In-Reply-To: <1324631920.7845.YahooMailNeo@web39508.mail.mud.yahoo.com> References: <1324631920.7845.YahooMailNeo@web39508.mail.mud.yahoo.com> Message-ID: Just a note on this subject although not directly related to the original question - There some interesting tests available here: http://www.measurementlab.net/ -- Landon Stewart Manager of Systems and Engineering Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead of the Rest": http://www.superbhosting.net From bill at herrin.us Fri Dec 23 20:17:45 2011 From: bill at herrin.us (William Herrin) Date: Fri, 23 Dec 2011 21:17:45 -0500 Subject: Well Lookie Here, Barracuda Networks tries to get me to fall into their trap again... In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B6354A8@ex-mb-1.corp.atlasnetworks.us> References: <20111221104148.4565907e@jpeach-desktop.anbg.mssm.edu> <1449422.1440.1324490075558.JavaMail.root@benjamin.baylink.com> <8C26A4FDAE599041A13EB499117D3C286B6354A8@ex-mb-1.corp.atlasnetworks.us> Message-ID: On Wed, Dec 21, 2011 at 8:46 AM, Nathan Eisenberg wrote: >> In fact, it's not. ?If you miss your renewal payment for, frex, Safari >> books, they actually slip your cycle date to when you renew -- since you don't >> [...] >> But, effectively, he's a new client, and should probably be treated >> that way. >> Assuming the paid service is actually *the update service*. > > I've always strongly felt that this was a rather foul business practice, > wherever I've seen it. ?The justification for it is the utterly misguided > belief that, if allowed to, customers will pay for a month then Spin it the other direction. The company will sell you the current version of their system for $X. For a period of Y years they will at any time sell you the then-current version of the system at the discount rate (%{Y} since last payment)*$X. Y years after your last payment, they will sell you the then-current version of their system at any time for $X. Where's the ethical problem here? The same company offers you a subscription so that you're considered paid up on the cost of the then-current system at all times during the duration of the subscription. Did this raise a new ethical problem? On Fri, Dec 23, 2011 at 1:11 AM, Jimmy Hess wrote: > If you let the agreement lapse, usually no warranty. Most extended > warranties can't be renewed 6 months after they lapsed, because you found > the product just broke and you would like to renew a warranty, so you can > RMA it for a repair/replacement. My out-of-warranty refrigerator from Sears broke a couple years ago. When I called to schedule a repair, the nice lady on the phone pitched me on buying a 1 year extended warranty. Easy sale. The repairman came out, fixed the fridge, and billed the warranty company for about 1.5 times the cost of the warranty I bought. Every so often I receive a mailer from Sears offering to sell me another 1 year extended warranty at a fixed price. 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 Fri Dec 23 20:19:40 2011 From: bill at herrin.us (William Herrin) Date: Fri, 23 Dec 2011 21:19:40 -0500 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EF4E24D.4020107@cis.vutbr.cz> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF4E24D.4020107@cis.vutbr.cz> Message-ID: On Fri, Dec 23, 2011 at 10:19 AM, Tomas Podermanski wrote: > On 12/23/11 6:56 AM, Mohacsi Janos wrote: >> On Wed, 21 Dec 2011, Tomas Podermanski wrote: >>> - There must be solved a situation what to do when SLAAC and DHCPv6 >>> ?provides some conflict information (quite long thread with various >>> opinions >>> ?can be found at >>> http://www.ietf.org/mail-archive/web/ipv6/current/msg14949.html) >> >> Administrators are deliberately providing conflicting information? > > Not administrators, but attackers then could have more ways for harmful > activity. Administrators too. Data normalization is about enforcing consistency at a technical level. Because in practice, enforcing consistency at a human level is damn hard. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From glen.kent at gmail.com Fri Dec 23 23:32:35 2011 From: glen.kent at gmail.com (Glen Kent) Date: Sat, 24 Dec 2011 11:02:35 +0530 Subject: subnet prefix length > 64 breaks IPv6? Message-ID: Hi, I am trying to understand why standards say that "using a subnet prefix length other than a /64 will break many features of IPv6, including Neighbor Discovery (ND), Secure Neighbor Discovery (SEND) [RFC3971], .. " [reference RFC 5375] Or "A number of other features currently in development, or being proposed, also rely on /64 subnet prefixes." Is it because the 128 bits are divided into two 64 bit halves, where the latter identifies an Interface ID which is uniquely derived from the 48bit MAC address. I am not sure if this is the reason as this only applies to the link local IP address. One could still assign a global IPv6 address. So, why does basic IPv6 (ND process, etc) break if i use a netmask of say /120? I know that several operators use /120 as a /64 can be quite risky in terms of ND attacks. So, how does that work? I tried googling but couldnt find any references that explain how IPv6 breaks with using a netmask other than 64. Glen From graham at apolix.co.za Fri Dec 23 23:35:39 2011 From: graham at apolix.co.za (Graham Beneke) Date: Sat, 24 Dec 2011 07:35:39 +0200 Subject: Speed Test Results In-Reply-To: <4EF4D5E6.50705@csuohio.edu> References: <1324631920.7845.YahooMailNeo@web39508.mail.mud.yahoo.com> <4EF4D5E6.50705@csuohio.edu> Message-ID: <4EF564AB.3000008@apolix.co.za> On 23/12/2011 21:26, Michael Holstein wrote: > They are excellent tools for generating user complaints. I find that they are useful for filtering out some of the completely bogus complaints. We encourage customers to include some test results when they contact our NOC to avoid being ignored when they send an "its slow" complaint. That said - people get fixated on the numbers. 80% of the purchased speed on non-CIR services is cause for a complaint. Our biggest issue is people doing tests to destinations 300+ ms away that only last for a few seconds and then complaining about poor performance. As soon as you mention things like bandwidth delay product the eyes glaze over. Heavy use of lossy WISP access network providers doesn't help. -- Graham Beneke From joe at nethead.com Fri Dec 23 23:58:54 2011 From: joe at nethead.com (Joe Hamelin) Date: Fri, 23 Dec 2011 21:58:54 -0800 Subject: Speed Test Results In-Reply-To: <4EF564AB.3000008@apolix.co.za> References: <1324631920.7845.YahooMailNeo@web39508.mail.mud.yahoo.com> <4EF4D5E6.50705@csuohio.edu> <4EF564AB.3000008@apolix.co.za> Message-ID: On Fri, Dec 23, 2011 at 9:35 PM, Graham Beneke wrote: > That said - people get fixated on the numbers. 80% of the purchased speed > on non-CIR services is cause for a complaint. > > Our biggest issue is people doing tests to destinations 300+ ms away that > only last for a few seconds and then complaining about poor performance. As > soon as you mention things like bandwidth delay product the eyes glaze > over. Heavy use of lossy WISP access network providers doesn't help. Or that most ADSL lines have about 20% ATM cell "tax" on them. I did get caught up on a speed test today. I was turning up a GBLX 100Mb circuit. I got the /30 and all the pings were good to the router. I then pinged some known hosts in the Westin (about a block away where GBLX's router was) and saw some not so nice ping times. I then ran a speedtest and only got about 2Mb/s. Come to find out that this was going to be an MPLS path to the company's California office. Since it hadn't been setup fully the router had found some path through it's management network to ping the world through the tester's DSL line on the other side. So, know the path you are testing. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From sthaug at nethelp.no Sat Dec 24 01:08:22 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sat, 24 Dec 2011 08:08:22 +0100 (CET) Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: References: Message-ID: <20111224.080822.74721455.sthaug@nethelp.no> > I am not sure if this is the reason as this only applies to the link > local IP address. One could still assign a global IPv6 address. So, > why does basic IPv6 (ND process, etc) break if i use a netmask of say > /120? As long as you assign addresses statically, IPv6 works just fine with a netmask > 64. We've been using this for several years now. No problem. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From michael at rancid.berkeley.edu Sat Dec 24 02:07:25 2011 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Sat, 24 Dec 2011 00:07:25 -0800 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EF4EA1F.3060900@necom830.hpcl.titech.ac.jp> References: <4EF28A00.2080904@kl.net> <4EF3C864.60807@necom830.hpcl.titech.ac.jp> <4EF4CCE0.5060304@rancid.berkeley.edu> <4EF4EA1F.3060900@necom830.hpcl.titech.ac.jp> Message-ID: <4EF5883D.8060807@rancid.berkeley.edu> On 12/23/11 12:52, Masataka Ohta wrote: > Michael Sinatra wrote: > >> The only time you need to perform extra steps is when you want to run >> DHCPv6. You need to enable the M and/or O flags and turn off the >> 'autonomous' flag (if you don't want a host to get both SLAAC addresses >> and DHCPv6 addresses. > > That's a configuration of RA, not DHCPv6. So? If DHCPv6 had default route capability you wouldn't need RA at all. The point is, you have to do more work to run DHCPv6 than SLAAC. >> Then you need to turn on relaying unless you are >> putting the DHCPv6 server on the same wire. > > As I wrote: > >> Just as most, if not all, NAT boxes have preconfigured DHCPv4 >> service to offer part of preconfigured private address >> space, home IPv6 routers may have preconfigured DHCPv6 >> service to offer part of configured public address space. > > local DHCPv6 server should be running locally by default. If you're talking about a little CPE router, maybe. If you're talking about an enterprise core router, then no. Ideally, nothing should be on by default, and services you wish to run should be configured explicitly. (Currently not the case with SLAAC, which is on by default when you configure IPv6 on some routers.) From michael at rancid.berkeley.edu Sat Dec 24 02:20:04 2011 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Sat, 24 Dec 2011 00:20:04 -0800 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EF4EBE0.4050609@necom830.hpcl.titech.ac.jp> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF4E24D.4020107@cis.vutbr.cz> <4EF4EBE0.4050609@necom830.hpcl.titech.ac.jp> Message-ID: <4EF58B34.6000904@rancid.berkeley.edu> On 12/23/11 13:00, Masataka Ohta wrote: > Tomas Podermanski wrote: > >> It sounds good, but according to RFC 6434 ( IPv6 Node Requirements) >> SLAAC is required, > > Not at all. SLAAC is required only if ND is supported, which > is optional. > > Note that ND works poorly over link layers such as 802.11 > where multicast is unreliable. > >> but DHCPv6 is only optional. > > DHCPv6 works over link layers with unreliable multicast > better than ND. You still need ND to provide the link-layer address resolution (i.e. the IPv6 equivalent of ARP), even with DHCPv6. Moreover, how do you come to the conclusion that DHCPv6, which uses multicast for the solicitation, is more reliable over links where multicast is unreliable? FYI, I have been using SLAAC over 802.11 for many years, and have supported large 802.11 installations with SLAAC and have never had a problem related to "unreliable multicast" on that medium. Other problems, yes. But not that one. michael From mohta at necom830.hpcl.titech.ac.jp Sat Dec 24 02:52:10 2011 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 24 Dec 2011 17:52:10 +0900 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EF5883D.8060807@rancid.berkeley.edu> References: <4EF28A00.2080904@kl.net> <4EF3C864.60807@necom830.hpcl.titech.ac.jp> <4EF4CCE0.5060304@rancid.berkeley.edu> <4EF4EA1F.3060900@necom830.hpcl.titech.ac.jp> <4EF5883D.8060807@rancid.berkeley.edu> Message-ID: <4EF592BA.2030204@necom830.hpcl.titech.ac.jp> Michael Sinatra wrote: >> That's a configuration of RA, not DHCPv6. > > So? If DHCPv6 had default route capability you wouldn't need RA at all. According to the end to end principle that hosts do everything, default router is a bad idea and you should better snoop IGP, which is the only solution for multihomed cases. >> local DHCPv6 server should be running locally by default. > > If you're talking about a little CPE router, maybe. If you're talking > about an enterprise core router, then no. The context of the thread is: > Glen Kent wrote: >> While in some environments, typically with small number of devices, >> its indispensable. Small businesses may not want the complexity of >> setting up a central server (for DHCP) - SLAAC works very well in such >> environments. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Sat Dec 24 02:58:32 2011 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 24 Dec 2011 17:58:32 +0900 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EF58B34.6000904@rancid.berkeley.edu> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF4E24D.4020107@cis.vutbr.cz> <4EF4EBE0.4050609@necom830.hpcl.titech.ac.jp> <4EF58B34.6000904@rancid.berkeley.edu> Message-ID: <4EF59438.8040505@necom830.hpcl.titech.ac.jp> Michael Sinatra wrote: >> DHCPv6 works over link layers with unreliable multicast >> better than ND. > > You still need ND to provide the link-layer address resolution (i.e. the > IPv6 equivalent of ARP), even with DHCPv6. Not necessarily. You can use ARP and DHCPv6 and you don't have to waste time and power for DAD. > Moreover, how do you come to > the conclusion that DHCPv6, which uses multicast for the solicitation, > is more reliable over links where multicast is unreliable? DHCPv6 (and ARP) uses a lot less multicast/broadcast than ND. > FYI, I have been using SLAAC over 802.11 for many years, and have > supported large 802.11 installations with SLAAC and have never had a > problem related to "unreliable multicast" on that medium. Other > problems, yes. But not that one. That's because your 802.11 is not congested. Masataka Ohta From glen.kent at gmail.com Sat Dec 24 04:07:02 2011 From: glen.kent at gmail.com (Glen Kent) Date: Sat, 24 Dec 2011 15:37:02 +0530 Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: <20111224.080822.74721455.sthaug@nethelp.no> References: <20111224.080822.74721455.sthaug@nethelp.no> Message-ID: Ok. So does SLAAC break with masks > 64? Glen On Sat, Dec 24, 2011 at 12:38 PM, wrote: >> I am not sure if this is the reason as this only applies to the link >> local IP address. One could still assign a global IPv6 address. So, >> why does basic IPv6 (ND process, etc) break if i use a netmask of say >> /120? > > As long as you assign addresses statically, IPv6 works just fine with a > netmask > 64. We've been using this for several years now. No problem. > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no From kauer at biplane.com.au Sat Dec 24 04:58:51 2011 From: kauer at biplane.com.au (Karl Auer) Date: Sat, 24 Dec 2011 21:58:51 +1100 Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: References: <20111224.080822.74721455.sthaug@nethelp.no> Message-ID: <1324724331.2763.20.camel@karl> On Sat, 2011-12-24 at 15:37 +0530, Glen Kent wrote: > Ok. So does SLAAC break with masks > 64? "Break" is not the right word. SLAAC only works with /64, But that is by design. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: This is a digitally signed message part URL: From kauer at biplane.com.au Sat Dec 24 05:05:31 2011 From: kauer at biplane.com.au (Karl Auer) Date: Sat, 24 Dec 2011 22:05:31 +1100 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EF59438.8040505@necom830.hpcl.titech.ac.jp> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF4E24D.4020107@cis.vutbr.cz> <4EF4EBE0.4050609@necom830.hpcl.titech.ac.jp> <4EF58B34.6000904@rancid.berkeley.edu> <4EF59438.8040505@necom830.hpcl.titech.ac.jp> Message-ID: <1324724731.2763.26.camel@karl> On Sat, 2011-12-24 at 17:58 +0900, Masataka Ohta wrote: > Not necessarily. You can use ARP and DHCPv6 and you don't have > to waste time and power for DAD. IPv6 does not do ARP, it does ND. Even if you use DHCv6, you still need ND. DAD is still performed on addresses assigned via DHCPv6. > DHCPv6 (and ARP) uses a lot less multicast/broadcast than ND. ARP uses no multicast at all. However, ARP is an IPv4 protocol, not an IPv6 protocol. DHCPv6 uses multicast a lot - *every* client message is multicast. Relay messages to servers are multicast by default (though it seems most actual deployments configure the relays to use unicast). Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: This is a digitally signed message part URL: From alexandru.petrescu at gmail.com Sat Dec 24 05:16:07 2011 From: alexandru.petrescu at gmail.com (Alexandru Petrescu) Date: Sat, 24 Dec 2011 12:16:07 +0100 Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: <1324724331.2763.20.camel@karl> References: <20111224.080822.74721455.sthaug@nethelp.no> <1324724331.2763.20.camel@karl> Message-ID: <4EF5B477.7040703@gmail.com> Le 24/12/2011 11:58, Karl Auer a ?crit : > On Sat, 2011-12-24 at 15:37 +0530, Glen Kent wrote: >> Ok. So does SLAAC break with masks> 64? > > "Break" is not the right word. SLAAC only works with /64, But that is > by design. SLAAC only works with /64 - yes - but only if it runs on Ethernet-like Interface ID's of 64bit length (RFC2464). SLAAC could work ok with /65 on non-Ethernet media, like a point-to-point link whose Interface ID's length be negotiated during the setup phase. Other non-64 Interface IDs could be constructed for 802.15.4 links, for example a 16bit MAC address could be converted into a 32bit Interface ID. SLAAC would thus use a /96 prefix in the RA and a 32bit IID. IP-over-USB misses an Interface ID altogether, so one is free to define its length. Alex > > Regards, K. > From glen.kent at gmail.com Sat Dec 24 08:48:40 2011 From: glen.kent at gmail.com (Glen Kent) Date: Sat, 24 Dec 2011 20:18:40 +0530 Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: <4EF5B477.7040703@gmail.com> References: <20111224.080822.74721455.sthaug@nethelp.no> <1324724331.2763.20.camel@karl> <4EF5B477.7040703@gmail.com> Message-ID: > > SLAAC only works with /64 - yes - but only if it runs on Ethernet-like > Interface ID's of 64bit length (RFC2464). Ok, the last 64 bits of the 128 bit address identifies an Interface ID which is uniquely derived from the 48bit MAC address (which exists only in ethernet). > SLAAC could work ok with /65 on non-Ethernet media, like a > point-to-point link whose Interface ID's length be negotiated during the > setup phase. If we can do this for a p2p link, then why cant the same be done for an ethernet link? Glen > > Other non-64 Interface IDs could be constructed for 802.15.4 links, for > example a 16bit MAC address could be converted into a 32bit Interface > ID. ?SLAAC would thus use a /96 prefix in the RA and a 32bit IID. > > IP-over-USB misses an Interface ID altogether, so one is free to define > its length. > > Alex > >> >> Regards, K. >> > > From sven at cb3rob.net Sat Dec 24 09:30:10 2011 From: sven at cb3rob.net (Sven Olaf Kamphuis) Date: Sat, 24 Dec 2011 15:30:10 +0000 (UTC) Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: References: Message-ID: it only breaks the auto configure crap which you don't want to use anyway. (unless you want to have any computer on your network be able to tell any other computer "oh hai i'm a router, please route all your packets through me so i can intercept them" and/or flood its route table ;) we use all kinds of things from /126'es to /112 (but hardly any /64 crap) works perfectly fine. as long as its nibble aligned (for other reasons ;) -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. & Co. KG ========================================================================= Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration: HRA 42834 B BERLIN Phone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE: CBSK1-RIPE e-Mail: sven at cb3rob.net ========================================================================= C3P0, der elektrische Westerwelle http://www.facebook.com/cb3rob ========================================================================= Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Sat, 24 Dec 2011, Glen Kent wrote: > Hi, > > I am trying to understand why standards say that "using a subnet > prefix length other than a /64 will break many features of IPv6, > including Neighbor Discovery (ND), Secure Neighbor Discovery (SEND) > [RFC3971], .. " [reference RFC 5375] > > Or "A number of other features currently in development, or being > proposed, also rely on /64 subnet prefixes." > > Is it because the 128 bits are divided into two 64 bit halves, where > the latter identifies an Interface ID which is uniquely derived from > the 48bit MAC address. > > I am not sure if this is the reason as this only applies to the link > local IP address. One could still assign a global IPv6 address. So, > why does basic IPv6 (ND process, etc) break if i use a netmask of say > /120? > > I know that several operators use /120 as a /64 can be quite risky in > terms of ND attacks. So, how does that work? I tried googling but > couldnt find any references that explain how IPv6 breaks with using a > netmask other than 64. > > Glen > From jof at thejof.com Sat Dec 24 09:39:32 2011 From: jof at thejof.com (Jonathan Lassoff) Date: Sat, 24 Dec 2011 15:39:32 +0000 Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: References: <20111224.080822.74721455.sthaug@nethelp.no> <1324724331.2763.20.camel@karl> <4EF5B477.7040703@gmail.com> Message-ID: On Sat, Dec 24, 2011 at 6:48 AM, Glen Kent wrote: > > > > SLAAC only works with /64 - yes - but only if it runs on Ethernet-like > > Interface ID's of 64bit length (RFC2464). > > Ok, the last 64 bits of the 128 bit address identifies an Interface ID > which is uniquely derived from the 48bit MAC address (which exists > only in ethernet). > > > SLAAC could work ok with /65 on non-Ethernet media, like a > > point-to-point link whose Interface ID's length be negotiated during the > > setup phase. > > If we can do this for a p2p link, then why cant the same be done for > an ethernet link? > I think by "point-to-point", Alexandru was referring to PPP-signalled links. In the case of Ethernet and SLAAC, the standards define a way to turn a globally unique 48-bit 802.3 MAC-48 address into an EUI-64 identifier by flipping and adding some bits. This uniquely maps conventional MAC-48 addresses into EUI-64 addresses. I imagine this was chosen because the IEEE is encouraging new standards and numbering schemes to use the 64-bit schemes over the older 48-bit ones. Presumably to avoid exhaustion in the future (like we're seeing with IPv4). The result of which is that with the standards we've got today, we can easily map a piece of hardware's globally unique MAC address into a globally unique 64-bit identifier -- which happens to cleanly fit into the second half of the v6 address space. I suppose one could make an argument to use /80 networks and just use the MAC-48 identifier for the address portion, but given the vastness of v6 space I don't think it's really worth the extra savings of bit space. So, to address your original question, in v6 networks with netmask lengths greater than 64 bits nothing "breaks" per se, but some of the conventional standards and ideas about what a "network" is in that context are broken. While it's not possible to have hosts uniquely pick addresses for themselves, one can use other addressing mechanisms like DHCPv6 or static addresses. --j From sven at cb3rob.net Sat Dec 24 09:44:41 2011 From: sven at cb3rob.net (Sven Olaf Kamphuis) Date: Sat, 24 Dec 2011 15:44:41 +0000 (UTC) Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: References: Message-ID: things that -do- break on ipv6 a lot (not nessesarily related to the /64 thing) are premature protocols like ospf6 and ripng that for some magic reason refuse to work on point-to-point (as opposed to putting the interface in broadcast mode, like ethernet) interfaces without (additional) link-local addresses, despite the option to clearly specify the interface and/or address of the peer and/or address ranges they should work on (these do not nessesarily have to be /64, but they do need to be scope link local and start with a multicast prefix). also various bgp implementations will send the autoconfigure crap ip as the next-hop instead of the session ip, resulting in all kinds of crap in your route table (if not fixed with nasty hacks on your end ;) which doesn't exactly make it easy to figure out which one belongs to which peer all the more reason not to use that autoconfigure crap ;) on the whole, ipv6 simply still needs a -lot- of work. for those that do want autoconfigure (workstations?) , a proper dhcp implementation would be preferred over keeping that RA stuff around in future implementations of the v6 stack, as far as we're concerned, it can go the way of the dinosaur (already ;) On Sat, 24 Dec 2011, Sven Olaf Kamphuis wrote: > it only breaks the auto configure crap which you don't want to use anyway. > > (unless you want to have any computer on your network be able to tell any > other computer "oh hai i'm a router, please route all your packets through me > so i can intercept them" and/or flood its route table ;) > > we use all kinds of things from /126'es to /112 (but hardly any /64 crap) > > works perfectly fine. > > as long as its nibble aligned (for other reasons ;) > > -- > Greetings, > > Sven Olaf Kamphuis, > CB3ROB Ltd. & Co. KG > ========================================================================= > Address: Koloniestrasse 34 VAT Tax ID: DE267268209 > D-13359 Registration: HRA 42834 B > BERLIN Phone: +31/(0)87-8747479 > Germany GSM: +49/(0)152-26410799 > RIPE: CBSK1-RIPE e-Mail: sven at cb3rob.net > ========================================================================= > C3P0, der elektrische Westerwelle > http://www.facebook.com/cb3rob > ========================================================================= > > Confidential: Please be advised that the information contained in this > email message, including all attached documents or files, is privileged > and confidential and is intended only for the use of the individual or > individuals addressed. Any other use, dissemination, distribution or > copying of this communication is strictly prohibited. > > > On Sat, 24 Dec 2011, Glen Kent wrote: > >> Hi, >> >> I am trying to understand why standards say that "using a subnet >> prefix length other than a /64 will break many features of IPv6, >> including Neighbor Discovery (ND), Secure Neighbor Discovery (SEND) >> [RFC3971], .. " [reference RFC 5375] >> >> Or "A number of other features currently in development, or being >> proposed, also rely on /64 subnet prefixes." >> >> Is it because the 128 bits are divided into two 64 bit halves, where >> the latter identifies an Interface ID which is uniquely derived from >> the 48bit MAC address. >> >> I am not sure if this is the reason as this only applies to the link >> local IP address. One could still assign a global IPv6 address. So, >> why does basic IPv6 (ND process, etc) break if i use a netmask of say >> /120? >> >> I know that several operators use /120 as a /64 can be quite risky in >> terms of ND attacks. So, how does that work? I tried googling but >> couldnt find any references that explain how IPv6 breaks with using a >> netmask other than 64. >> >> Glen >> > From rps at maine.edu Sat Dec 24 11:10:32 2011 From: rps at maine.edu (Ray Soucy) Date: Sat, 24 Dec 2011 12:10:32 -0500 Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: References: Message-ID: Your understanding of IPv6 is poor if you think by not using a 64-bit prefix you will be protected against rogue RA. The prefix length you define on your router will have no impact on a rogue RA sent out. IPv6 hosts can have addresses from multiple prefixes on the same link. Choosing to make use of a 120-bit prefix (for example) will do nothing to protect against a rogue RA announcing its own 64-bit prefix with the A flag set. You can use a 64-bit prefix and not use SLAAC as well. SLAAC is used only when the A flag is set. It just so happens that the majority of router implementations have it set by default. You still need to filter RA from unauthorized hosts. Currently, many switches can accomplish this using a PACL on access ports. In the near future, we will begin to see the RA Guard feature become standard on enterprise switches. Mind you, you should be filtering out rogue RA regardless if whether or not you have deployed IPv6. Windows ICS sending RA is a widespread problem (honestly wish Microsoft would remove ICS from the default install). There are some things that will break by not using a 64-bit prefix. SLAAC can't function without it. Privacy Extensions for SLAAC can't either (obviously). If you make use of a longer prefix, then you need to use either manual configuration or DHCPv6 for address assignment. All standards-compliant implementations of IPv6 will work with prefixes longer than 64-bit. In production, we make use of 126-bit prefixes for link networks, and common use of 120 (and similar) prefixes for host networks and they work perfectly. That said, the only reason we don't make use of 64-bit prefixes for host networks is in an effort (which may be futile) to mitigate neighbor table exhaustion attacks. We still reserve a full 64-bit prefix, allowing us to expand the prefix in the future without disrupting service. The long term plan is to migrate to 64-bit prefixes when routing equipment is better able to handle neighbor table exhaustion attacks. As for the comments on the use of multicast; multicast is a good thing. On most devices is is no different than broadcast, but it adds the information needed for more advanced hardware (e.g. managed switches with MLD snooping) to only replicate the traffic to interested parties. The elimination of broadcast traffic in IPv6 is a good thing, and doesn't introduce any problem. The (related) other comment made was using ARP with IPv6 instead of ND. This also shows a poor understanding of how IPv6 works. ARP is for IPv4, ND is for IPv6. There is no ARP for IPv6. ND has the advantage that it actually happens over IPv6, rather than a lower level or parallel protocol. This makes filtering such traffic and designing hardware that is aware of it significantly easier. It will be nice to reach a point where non-IPv6 traffic can be filtered and dropped completely. Other than making use of the link-local scope and using a multicast group instead of broadcast, ND is pretty much the same thing as ARP. On Sat, Dec 24, 2011 at 10:30 AM, Sven Olaf Kamphuis wrote: > it only breaks the auto configure crap which you don't want to use anyway. > > (unless you want to have any computer on your network be able to tell any > other computer "oh hai i'm a router, please route all your packets through > me so i can intercept them" and/or flood its route table ;) > > we use all kinds of things from /126'es to /112 (but hardly any /64 crap) > > works perfectly fine. > > as long as its nibble aligned (for other reasons ;) > > -- > Greetings, > > Sven Olaf Kamphuis, > CB3ROB Ltd. & Co. KG > ========================================================================= > Address: Koloniestrasse 34 ? ? ? ? VAT Tax ID: ? ? ?DE267268209 > ? ? ? ? D-13359 ? ? ? ? ? ? ? ? ? Registration: ? ?HRA 42834 B > ? ? ? ? BERLIN ? ? ? ? ? ? ? ? ? ?Phone: ? ? ? ? ? +31/(0)87-8747479 > ? ? ? ? Germany ? ? ? ? ? ? ? ? ? GSM: ? ? ? ? ? ? +49/(0)152-26410799 > RIPE: ? ?CBSK1-RIPE ? ? ? ? ? ? ? ?e-Mail: ? ? ? ? ?sven at cb3rob.net > ========================================================================= > C3P0, der elektrische Westerwelle > http://www.facebook.com/cb3rob > ========================================================================= > > Confidential: Please be advised that the information contained in this > email message, including all attached documents or files, is privileged > and confidential and is intended only for the use of the individual or > individuals addressed. Any other use, dissemination, distribution or > copying of this communication is strictly prohibited. > > > > On Sat, 24 Dec 2011, Glen Kent wrote: > >> Hi, >> >> I am trying to understand why standards say that "using a subnet >> prefix length other than a /64 will break many features of IPv6, >> including Neighbor Discovery (ND), Secure Neighbor Discovery (SEND) >> [RFC3971], .. " [reference RFC 5375] >> >> Or "A number of other features currently in development, or being >> proposed, also rely on /64 subnet prefixes." >> >> Is it because the 128 bits are divided into two 64 bit halves, where >> the latter identifies an Interface ID which is uniquely derived from >> the 48bit MAC address. >> >> I am not sure if this is the reason as this only applies to the link >> local IP address. One could still assign a global IPv6 address. So, >> why does basic IPv6 (ND process, etc) break if i use a netmask of say >> /120? >> >> I know that several operators use /120 as a /64 can be quite risky in >> terms of ND attacks. So, how does that work? I tried googling but >> couldnt find any references that explain how IPv6 breaks with using a >> netmask other than 64. >> >> Glen >> > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From jcdill.lists at gmail.com Sat Dec 24 13:24:53 2011 From: jcdill.lists at gmail.com (JC Dill) Date: Sat, 24 Dec 2011 11:24:53 -0800 Subject: Merry Chrismafestihanukwanzstice Message-ID: <4EF62705.2040907@gmail.com> Merry Chrismafestihanukwanzstice to everyone reading NANOG on this holiday weekend. And now, for some On Topic technical content, I bring you RFC 1882 (it's an RFC, by definition it must have some relevant content for network operators :-): http://www.ietf.org/rfc/rfc1882.txt Network Working Group B. Hancock Request for Comments: 1882 Network-1 Software and Technology, Inc. Category: Informational December 1995 The 12-Days of Technology Before Christmas Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Discussion On the first day of Christmas, technology gave to me: A database with a broken b-tree (what the hell is a b-tree anyway?) On the second day of Christmas, technology gave to me: Two transceiver failures (CRC errors? Collisions? What is going on?) And a database with a broken b-tree (Rebuild WHAT? It's a 10GB database!) On the third day of Christmas, technology gave to me: Three French users (who, of course, think they know everything) Two transceiver failures (which are now spewing packets all over the net) And a database with a broken b-tree (Backup? What backup?) On the fourth day of Christmas, technology gave to me: Four calls for support (playing the same Christmas song over and over) Three French users (Why do they like to argue so much over trivial things?) Two transceiver failures (How the hell do I know which ones they are?) And a database with a broken b-tree (Pointer error? What's a pointer error?) Hancock Informational [Page 1] RFC 1882 12-Days of Technology Before Christmas December 1995 On the fifth day of Christmas, technology gave to me: Five golden SCSI contacts (Of course they're better than silver!) Four support calls (Ever notice how time stands still when on hold? Three French users (No, we don't have footpedals on PC's. Why do you ask?) Two transceiver failures (If I knew which ones were bad, I would know which ones to fix!) And a database with a broken b-tree (Not till next week? Are you nuts?!?!) On the sixth day of Christmas, technology gave to me: Six games a-playing (On the production network, of course!) Five golden SCSI contacts (What do you mean "not terminated!") Four support calls (No, don't transfer me again - do you HEAR? Damn!) Three French users (No, you cannot scan in by putting the page to the screen...) Two transceiver failures (I can't look at the LEDs - they're in the ceiling!) And a database with a broken b-tree (Norway? That's where this was written?) On the seventh day of Christmas, technology gave to me: Seven license failures (Expired? When?) Six games a-playing (Please stop tying up the PBX to talk to each other!) Five golden SCSI contacts (What do you mean I need "wide" SCSI?) Four support calls (At least the Muzak is different this time...) Three French Users (Well, monsieur, there really isn't an "any" key, but...) Two transceiver failures (SQE? What is that? If I knew I would set it myself!) And a database with a broken b-tree (No, I really need to talk to Lars - NOW!) Hancock Informational [Page 2] RFC 1882 12-Days of Technology Before Christmas December 1995 On the eighth day of Christmas, technology gave to me: Eight MODEMs dialing (Who bought these? They're a security violation!) Seven license failures (How many WEEKS to get a license?) Six games a-playing (What do you mean one pixel per packet on updates?!?) Five golden SCSI contacts (Fast SCSI? It's supposed to be fast, isn't it?) Four support calls (I already told them that! Don't transfer me back - DAMN!) Three French users (No, CTL-ALT-DEL is not the proper way to end a program) Two transceiver failures (What do you mean "babbling transceiver"?) And a database with a broken b-tree (Does anyone speak English in Oslo?) On the ninth day of Christmas, technology gave to me: Nine lady executives with attitude (She said do WHAT with the servers?) Eight MODEMs dialing (You've been downloading WHAT?) Seven license failures (We sent the P.O. two months ago!) Six games a-playing (HOW many people are doing this to the network?) Five golden SCSI contacts (What do you mean two have the same ID?) Four support calls (No, I am not at the console - I tried that already.) Three French users (No, only one floppy fits at a time? Why do you ask?) Two transceiver failures (Spare? What spare?) And a database with a broken b-tree (No, I am trying to find Lars! L-A-R-S!) Hancock Informational [Page 3] RFC 1882 12-Days of Technology Before Christmas December 1995 On the tenth day of Christmas, technology gave to me: Ten SNMP alerts flashing (What is that Godawful beeping?) Nine lady executives with attitude (No, it used to be a mens room? Why?) Eight MODEMs dialing (What Internet provider? We don't allow Internet here!) Seven license failures (SPA? Why are they calling us?) Six games a-playing (No, you don't need a graphics accelerator for Lotus! ) Five golden SCSI contacts (You mean I need ANOTHER cable?) Four support calls (No, I never needed an account number before...) Three French users (When the PC sounds like a cat, it's a head crash!) Two transceiver failures (Power connection? What power connection?) And a database with a broken b-tree (Restore what index pointers?) On the eleventh day of Christmas, technology gave to me: Eleven boards a-frying (What is that terrible smell?) Ten SNMP alerts flashing (What's a MIB, anyway? What's an extension?) Nine lady executives with attitude (Mauve? Our computer room tiles in mauve?) Eight MODEMs dialing (What do you mean you let your roommate dial-in?) Seven license failures (How many other illegal copies do we have?!?!) Six games a-playing (I told you - AFTER HOURS!) Five golden SCSI contacts (If I knew what was wrong, I wouldn't be calling!) Four support calls (Put me on hold again and I will slash your credit rating!) Three French users (Don't hang your floppies with a magnet again!) Two transceiver failures (How should I know if the connector is bad?) And a database with a broken b-tree (I already did all of that!) Hancock Informational [Page 4] RFC 1882 12-Days of Technology Before Christmas December 1995 On the twelfth day of Christmas, technology gave to me: Twelve virtual pipe connections (There's only supposed to be two!) Eleven boards a-frying (What a surge suppressor supposed to do, anyway?) Ten SNMP alerts flashing (From a distance, it does kinda look like XMas lights.) Nine lady executives with attitude (What do you mean aerobics before backups?) Eight MODEMs dialing (No, we never use them to connect during business hours.) Seven license failures (We're all going to jail, I just know it.) Six games a-playing (No, no - my turn, my turn!) Five golden SCSI contacts (Great, just great! Now it won't even boot!) Four support calls (I don't have that package! How did I end up with you!) Three French users (I don't care if it is sexy, no more nude screen backgrounds!) Two transceiver failures (Maybe we should switch to token ring...) And a database with a broken b-tree (No, operator - Oslo, Norway. We were just talking and were cut off...) Security Considerations Security issues are not discussed in this memo. Author's Address Bill Hancock, Ph.D. Network-1 Software & Technology, Inc. DFW Research Center 878 Greenview Dr. Grand Prairie, TX 75050 EMail: hancock at network-1.com Phone: (214) 606-8200 Fax: (214) 606-8220 Hancock Informational [Page 5] From mohta at necom830.hpcl.titech.ac.jp Sat Dec 24 17:33:03 2011 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sun, 25 Dec 2011 08:33:03 +0900 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <1324724731.2763.26.camel@karl> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF4E24D.4020107@cis.vutbr.cz> <4EF4EBE0.4050609@necom830.hpcl.titech.ac.jp> <4EF58B34.6000904@rancid.berkeley.edu> <4EF59438.8040505@necom830.hpcl.titech.ac.jp> <1324724731.2763.26.camel@karl> Message-ID: <4EF6612F.2070901@necom830.hpcl.titech.ac.jp> Karl Auer wrote: >> Not necessarily. You can use ARP and DHCPv6 and you don't have >> to waste time and power for DAD. > IPv6 does not do ARP, it does ND. First of all, ND use is optional and, if ND is used, RA must be used. It means that, if RA is not used, ND can't be used. Then, the only reasonable protocol for address resolution is ARP. > Even if you use DHCv6, you still need > ND. DAD is still performed on addresses assigned via DHCPv6. That is a requirement by SLAAC because SLAAC has distributed states, which can be inconsistent. If RA is not used, there is no such requirement. Masataka Ohta From joelja at bogus.com Sat Dec 24 17:42:00 2011 From: joelja at bogus.com (Joel jaeggli) Date: Sat, 24 Dec 2011 15:42:00 -0800 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EF6612F.2070901@necom830.hpcl.titech.ac.jp> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF4E24D.4020107@cis.vutbr.cz> <4EF4EBE0.4050609@necom830.hpcl.titech.ac.jp> <4EF58B34.6000904@rancid.berkeley.edu> <4EF59438.8040505@necom830.hpcl.titech.ac.jp> <1324724731.2763.26.camel@karl> <4EF6612F.2070901@necom830.hpcl.titech.ac.jp> Message-ID: <4EF66348.8040500@bogus.com> On 12/24/11 15:33 , Masataka Ohta wrote: > Karl Auer wrote: > >>> Not necessarily. You can use ARP and DHCPv6 and you don't have >>> to waste time and power for DAD. > >> IPv6 does not do ARP, it does ND. > > First of all, ND use is optional and, if ND is used, RA > must be used. > > It means that, if RA is not used, ND can't be used. Finding and maintaining the l2 address for a device on a subnet where RA is not used is a pretty common activity so I'm not sure how your would conclude that. 2461/4861/5942 certainly don't preclude that. > Then, the only reasonable protocol for address resolution > is ARP. > >> Even if you use DHCv6, you still need >> ND. DAD is still performed on addresses assigned via DHCPv6. > > That is a requirement by SLAAC because SLAAC has distributed > states, which can be inconsistent. > > If RA is not used, there is no such requirement. > > Masataka Ohta > From mohta at necom830.hpcl.titech.ac.jp Sat Dec 24 18:36:41 2011 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sun, 25 Dec 2011 09:36:41 +0900 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EF66348.8040500@bogus.com> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF4E24D.4020107@cis.vutbr.cz> <4EF4EBE0.4050609@necom830.hpcl.titech.ac.jp> <4EF58B34.6000904@rancid.berkeley.edu> <4EF59438.8040505@necom830.hpcl.titech.ac.jp> <1324724731.2763.26.camel@karl> <4EF6612F.2070901@necom830.hpcl.titech.ac.jp> <4EF66348.8040500@bogus.com> Message-ID: <4EF67019.1000309@necom830.hpcl.titech.ac.jp> Joel jaeggli wrote: >> First of all, ND use is optional and, if ND is used, RA >> must be used. >> >> It means that, if RA is not used, ND can't be used. > > Finding and maintaining the l2 address for a device on a subnet where RA > is not used is a pretty common activity so I'm not sure how your would > conclude that. 2461/4861/5942 certainly don't preclude that. RFC6434 has contradictory statements: Neighbor Discovery SHOULD be supported. and Hosts MUST support IPv6 Stateless Address Autoconfiguration as defined in [RFC4862]. and a reasonable interpretation is SLAAC MUST be supported if ND is supported. Or, we shouldn't expect IPv6 specifications reasonable, which means reasonable operation is impossible. Masataka Ohta From glen.kent at gmail.com Sun Dec 25 04:18:00 2011 From: glen.kent at gmail.com (Glen Kent) Date: Sun, 25 Dec 2011 15:48:00 +0530 Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: References: Message-ID: Hi Ray, > prefixes on the same link. ?Choosing to make use of a 120-bit prefix > (for example) will do nothing to protect against a rogue RA announcing > its own 64-bit prefix with the A flag set. > I could not find any "A flag" in the RA. Am i missing something? >From http://www.iana.org/assignments/icmpv6-parameters: Registry: RA Option Bit Description Reference ------------- --------------------------------------- --------- 0 M - Managed Address Configuration Flag [RFC2461] 1 O - Other Configuration Flag [RFC2461] 2 H - Mobile IPv6 Home Agent Flag [RFC3775] 3 Prf - Router Selection Preferences [RFC4191] 4 Prf - Router Selection Preferences [RFC4191] 5 P - Neighbor Discovery Proxy Flag [RFC4389] 6-53 R - Reserved; Available for assignment [RFC5175] 54-55 Private Experimentation [RFC5175] Glen From sthaug at nethelp.no Sun Dec 25 04:26:08 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sun, 25 Dec 2011 11:26:08 +0100 (CET) Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: References: Message-ID: <20111225.112608.74672182.sthaug@nethelp.no> > > prefixes on the same link. ?Choosing to make use of a 120-bit prefix > > (for example) will do nothing to protect against a rogue RA announcing > > its own 64-bit prefix with the A flag set. > > > > I could not find any "A flag" in the RA. Am i missing something? It's part of the Prefix Information option. See http://tools.ietf.org/html/rfc4861#section-4.6.2 Steinar Haug, Nethelp consulting, sthaug at nethelp.no From trejrco at gmail.com Sun Dec 25 08:52:42 2011 From: trejrco at gmail.com (TJ) Date: Sun, 25 Dec 2011 09:52:42 -0500 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EF67019.1000309@necom830.hpcl.titech.ac.jp> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF4E24D.4020107@cis.vutbr.cz> <4EF4EBE0.4050609@necom830.hpcl.titech.ac.jp> <4EF58B34.6000904@rancid.berkeley.edu> <4EF59438.8040505@necom830.hpcl.titech.ac.jp> <1324724731.2763.26.camel@karl> <4EF6612F.2070901@necom830.hpcl.titech.ac.jp> <4EF66348.8040500@bogus.com> <4EF67019.1000309@necom830.hpcl.titech.ac.jp> Message-ID: I think perhaps you are confusing "what must be supported by implementations" (and ignoring the text describing the requirements) as stated in 6434, with operational usage. For example - SLAAC must be supported by the implementations, but an environment isn't required to use it. /TJ On Dec 24, 2011 7:34 PM, "Masataka Ohta" wrote: > Joel jaeggli wrote: > > >> First of all, ND use is optional and, if ND is used, RA > >> must be used. > >> > >> It means that, if RA is not used, ND can't be used. > > > > Finding and maintaining the l2 address for a device on a subnet where RA > > is not used is a pretty common activity so I'm not sure how your would > > conclude that. 2461/4861/5942 certainly don't preclude that. > > RFC6434 has contradictory statements: > > Neighbor Discovery SHOULD be supported. > > and > > Hosts MUST support IPv6 Stateless Address Autoconfiguration as > defined in [RFC4862]. > > and a reasonable interpretation is SLAAC MUST be supported if > ND is supported. > > Or, we shouldn't expect IPv6 specifications reasonable, > which means reasonable operation is impossible. > > Masataka Ohta > > From frnkblk at iname.com Sun Dec 25 19:28:24 2011 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 25 Dec 2011 19:28:24 -0600 Subject: Speed Test Results In-Reply-To: <4EF4D5E6.50705@csuohio.edu> References: <1324631920.7845.YahooMailNeo@web39508.mail.mud.yahoo.com> <4EF4D5E6.50705@csuohio.edu> Message-ID: <003101ccc36d$aaa4cb40$ffee61c0$@iname.com> We host an Ookla Speedtest server onsite and find it a very reliable means to identify throughput issues. The source of any performance issues may or may not be ours, but if a customer says things are slow we can usually identify whether it's their PC or network (browsing is slow but speed test runs fine) or a local or regional network issue (speed test runs slow). If a customer gets less than 90% of the advertised throughput, we follow up on it. Frank -----Original Message----- From: Michael Holstein [mailto:michael.holstein at csuohio.edu] Sent: Friday, December 23, 2011 1:27 PM To: jacob miller Cc: nanog at nanog.org Subject: Re: Speed Test Results > Am having a debate on the results of speed tests sites. > > Am interested in knowing the thoughts of different individuals in regards to this. > > They are excellent tools for generating user complaints. (just like the "do traceroute and count the hops" advice from gamer mags of old). (my $0.02) Michael Holstein Cleveland State University From scott at sberkman.net Sun Dec 25 20:10:17 2011 From: scott at sberkman.net (Scott Berkman) Date: Sun, 25 Dec 2011 21:10:17 -0500 Subject: Speed Test Results In-Reply-To: <003101ccc36d$aaa4cb40$ffee61c0$@iname.com> References: <1324631920.7845.YahooMailNeo@web39508.mail.mud.yahoo.com> <4EF4D5E6.50705@csuohio.edu> <003101ccc36d$aaa4cb40$ffee61c0$@iname.com> Message-ID: <06a601ccc373$83de2190$8b9a64b0$@sberkman.net> The MIT article is good read, thanks for sharing that. One thing to watch out for is if the last mile provider is the one hosting the speedtest site, that's another variable removed from the equation. In some cases that is a good thing, in others it's not, depending on what you are trying to measure. It's also theoretically possible (and in my opinion not only likely but probably fairly common) for some large residential ISP's to not rate-limit these on-net test sites (either by design or as a side result of at what point in the network they apply the rate limiting), thereby showing much higher results than the end user could ever possibly see in a real world scenario. Also, when using some of the popular public Ookla/speedtest.net sites, their FAQ clearly states that the tests are not suitable for certain connection types like high speed services and non-residential services in general. One good example is Speakeasy's site, which in my personal experience has been the one most commonly used by end users (especially those contacting us about "speed problems"): http://www.speakeasy.net/speedtest/issues.php "Our speed test is tuned to measure residential broadband services up to 20 Mbps over HTTP. It takes a very customized installation to be able to accurately measure up to 100 Mbps over HTTP." -Scott -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Sunday, December 25, 2011 8:28 PM To: 'Michael Holstein'; jacob miller Cc: nanog at nanog.org Subject: RE: Speed Test Results We host an Ookla Speedtest server onsite and find it a very reliable means to identify throughput issues. The source of any performance issues may or may not be ours, but if a customer says things are slow we can usually identify whether it's their PC or network (browsing is slow but speed test runs fine) or a local or regional network issue (speed test runs slow). If a customer gets less than 90% of the advertised throughput, we follow up on it. Frank -----Original Message----- From: Michael Holstein [mailto:michael.holstein at csuohio.edu] Sent: Friday, December 23, 2011 1:27 PM To: jacob miller Cc: nanog at nanog.org Subject: Re: Speed Test Results > Am having a debate on the results of speed tests sites. > > Am interested in knowing the thoughts of different individuals in regards to this. > > They are excellent tools for generating user complaints. (just like the "do traceroute and count the hops" advice from gamer mags of old). (my $0.02) Michael Holstein Cleveland State University From shortdudey123 at gmail.com Sun Dec 25 20:43:46 2011 From: shortdudey123 at gmail.com (Grant Ridder) Date: Sun, 25 Dec 2011 20:43:46 -0600 Subject: Speed Test Results In-Reply-To: <06a601ccc373$83de2190$8b9a64b0$@sberkman.net> References: <1324631920.7845.YahooMailNeo@web39508.mail.mud.yahoo.com> <4EF4D5E6.50705@csuohio.edu> <003101ccc36d$aaa4cb40$ffee61c0$@iname.com> <06a601ccc373$83de2190$8b9a64b0$@sberkman.net> Message-ID: Even though the faq's say they are only good for residential usage, i have had no problems with it at school. My college has 2x 100 Mb circuits from TW. When i run speed tests (I use speedtest.net) with the campus empty, i can get around 95Mb up. The bottleneck is the school's 100Mb switches. When the campus is filled (during the week) i can normally get close to 40 Mb down on a test. -Grant On Sun, Dec 25, 2011 at 8:10 PM, Scott Berkman wrote: > The MIT article is good read, thanks for sharing that. > > One thing to watch out for is if the last mile provider is the one hosting > the speedtest site, that's another variable removed from the equation. In > some cases that is a good thing, in others it's not, depending on what you > are trying to measure. It's also theoretically possible (and in my opinion > not only likely but probably fairly common) for some large residential > ISP's > to not rate-limit these on-net test sites (either by design or as a side > result of at what point in the network they apply the rate limiting), > thereby showing much higher results than the end user could ever possibly > see in a real world scenario. > > Also, when using some of the popular public Ookla/speedtest.net sites, > their > FAQ clearly states that the tests are not suitable for certain connection > types like high speed services and non-residential services in general. > One > good example is Speakeasy's site, which in my personal experience has been > the one most commonly used by end users (especially those contacting us > about "speed problems"): > > http://www.speakeasy.net/speedtest/issues.php > > "Our speed test is tuned to measure residential broadband services up to 20 > Mbps over HTTP. It takes a very customized installation to be able to > accurately measure up to 100 Mbps over HTTP." > > -Scott > > -----Original Message----- > From: Frank Bulk [mailto:frnkblk at iname.com] > Sent: Sunday, December 25, 2011 8:28 PM > To: 'Michael Holstein'; jacob miller > Cc: nanog at nanog.org > Subject: RE: Speed Test Results > > We host an Ookla Speedtest server onsite and find it a very reliable means > to identify throughput issues. The source of any performance issues may or > may not be ours, but if a customer says things are slow we can usually > identify whether it's their PC or network (browsing is slow but speed test > runs fine) or a local or regional network issue (speed test runs slow). > > If a customer gets less than 90% of the advertised throughput, we follow up > on it. > > Frank > > -----Original Message----- > From: Michael Holstein [mailto:michael.holstein at csuohio.edu] > Sent: Friday, December 23, 2011 1:27 PM > To: jacob miller > Cc: nanog at nanog.org > Subject: Re: Speed Test Results > > > > Am having a debate on the results of speed tests sites. > > > > Am interested in knowing the thoughts of different individuals in regards > to this. > > > > > > They are excellent tools for generating user complaints. > > (just like the "do traceroute and count the hops" advice from gamer mags > of old). > > (my $0.02) > > Michael Holstein > Cleveland State University > > > > > > > From sean at seanharlow.info Sun Dec 25 21:06:56 2011 From: sean at seanharlow.info (Sean Harlow) Date: Sun, 25 Dec 2011 22:06:56 -0500 Subject: Speed Test Results In-Reply-To: References: <1324631920.7845.YahooMailNeo@web39508.mail.mud.yahoo.com> <4EF4D5E6.50705@csuohio.edu> <003101ccc36d$aaa4cb40$ffee61c0$@iname.com> <06a601ccc373$83de2190$8b9a64b0$@sberkman.net> Message-ID: <35F06F98-508D-49B2-A93F-5DE9D8D74DD9@seanharlow.info> Basically it's a CYA statement on the part of Ookla/speedtest.net, since their test sites are of varying quality. The Radnor, OH test site sometimes can't even properly test a 10mbit SOHO broadband connection, where the Toledo site is consistently able to flood every available bit of capacity on my 50/5 home connection. It's just another tool that needs to be used intelligently. If I'm testing out a new ISP or a new speed level I've never had before, I wouldn't immediately complain if I didn't get the expected result on a public speed test site as it may be something outside of my ISP's control. On the other hand if things start dragging on my home connection or anywhere else that I know I can expect a certain result speedtest.net is usually my first stop. ---------- Sean Harlow sean at seanharlow.info On Dec 25, 2011, at 9:43 PM, Grant Ridder wrote: > Even though the faq's say they are only good for residential usage, i have > had no problems with it at school. My college has 2x 100 Mb circuits from > TW. When i run speed tests (I use speedtest.net) with the campus empty, i > can get around 95Mb up. The bottleneck is the school's 100Mb switches. > When the campus is filled (during the week) i can normally get close to 40 > Mb down on a test. > > -Grant From mohta at necom830.hpcl.titech.ac.jp Sun Dec 25 23:09:01 2011 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 26 Dec 2011 14:09:01 +0900 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF4E24D.4020107@cis.vutbr.cz> <4EF4EBE0.4050609@necom830.hpcl.titech.ac.jp> <4EF58B34.6000904@rancid.berkeley.edu> <4EF59438.8040505@necom830.hpcl.titech.ac.jp> <1324724731.2763.26.camel@karl> <4EF6612F.2070901@necom830.hpcl.titech.ac.jp> <4EF66348.8040500@bogus.com> <4EF67019.1000309@necom830.hpcl.titech.ac.jp> Message-ID: <4EF8016D.4060208@necom830.hpcl.titech.ac.jp> TJ wrote: > I think perhaps you are confusing "what must be supported by > implementations" (and ignoring the text describing the requirements) as > stated in 6434, with operational usage. There is not much difference. > For example - SLAAC must be supported by the implementations, but an > environment isn't required to use it. Still, if ND, which SHOULD be implemented, is not implemented, SLAAC CAN NOT be implemented. And, if RA is obsoleted, which is a point of discussion, there is no reason to keep so bloated ND only for address resolution. Masataka Ohta From trejrco at gmail.com Mon Dec 26 07:49:20 2011 From: trejrco at gmail.com (TJ) Date: Mon, 26 Dec 2011 08:49:20 -0500 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EF8016D.4060208@necom830.hpcl.titech.ac.jp> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF4E24D.4020107@cis.vutbr.cz> <4EF4EBE0.4050609@necom830.hpcl.titech.ac.jp> <4EF58B34.6000904@rancid.berkeley.edu> <4EF59438.8040505@necom830.hpcl.titech.ac.jp> <1324724731.2763.26.camel@karl> <4EF6612F.2070901@necom830.hpcl.titech.ac.jp> <4EF66348.8040500@bogus.com> <4EF67019.1000309@necom830.hpcl.titech.ac.jp> <4EF8016D.4060208@necom830.hpcl.titech.ac.jp> Message-ID: 2011/12/26 Masataka Ohta > TJ wrote: > > > I think perhaps you are confusing "what must be supported by > > implementations" (and ignoring the text describing the requirements) as > > stated in 6434, with operational usage. > > There is not much difference. > I disagree; there is a huge difference between what a node must _support_ and what an environment must _do_. The node support is meant to define what is generally possible, and an environment will use a subset of that. > > For example - SLAAC must be supported by the implementations, but an > > environment isn't required to use it. > > Still, if ND, which SHOULD be implemented, is not implemented, > SLAAC CAN NOT be implemented. > While I agree the wording is sub-optimal, this is where the descriptive text is important - the entirety of ND is "only optional" if the media has no need for discovering a MAC address (think a serial link, and NBMA link types require additional considerations as well) ... while a range of sub-categories of ND are required. > > And, if RA is obsoleted, which is a point of discussion, there > is no reason to keep so bloated ND only for address resolution. > I've been avoiding this part of the conversation, but I'll toss my unsolicited opinion in here as well; RA/SLAAC are both fine. DHCPv6 is fine. Use whichever your environment benefits from most, and having a couple choices is not a bad thing. - RA/SLAAC - I'd vote to stop extending now'ish (DNS (address + suffix) is important), but moving on I'd leave it as-is. If others really want to extend it (say, with NTP options) I wouldn't vehemently object. - DHCPv6 - I think it is fine without a default route option, but if others want to craft the standard and can get vendors to implement it so be it. *(I think a router providing information about itself is just fine ... )* /TJ From rps at maine.edu Mon Dec 26 11:32:46 2011 From: rps at maine.edu (Ray Soucy) Date: Mon, 26 Dec 2011 12:32:46 -0500 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EF8016D.4060208@necom830.hpcl.titech.ac.jp> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF4E24D.4020107@cis.vutbr.cz> <4EF4EBE0.4050609@necom830.hpcl.titech.ac.jp> <4EF58B34.6000904@rancid.berkeley.edu> <4EF59438.8040505@necom830.hpcl.titech.ac.jp> <1324724731.2763.26.camel@karl> <4EF6612F.2070901@necom830.hpcl.titech.ac.jp> <4EF66348.8040500@bogus.com> <4EF67019.1000309@necom830.hpcl.titech.ac.jp> <4EF8016D.4060208@necom830.hpcl.titech.ac.jp> Message-ID: 2011/12/26 Masataka Ohta : > And, if RA is obsoleted, which is a point of discussion, there > is no reason to keep so bloated ND only for address resolution. By who? Sources please. A few people on NANOG complaining about RA is pretty far from deprecation of RA. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From Valdis.Kletnieks at vt.edu Mon Dec 26 11:56:38 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 26 Dec 2011 12:56:38 -0500 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: Your message of "Mon, 26 Dec 2011 12:32:46 EST." References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF4E24D.4020107@cis.vutbr.cz> <4EF4EBE0.4050609@necom830.hpcl.titech.ac.jp> <4EF58B34.6000904@rancid.berkeley.edu> <4EF59438.8040505@necom830.hpcl.titech.ac.jp> <1324724731.2763.26.camel@karl> <4EF6612F.2070901@necom830.hpcl.titech.ac.jp> <4EF66348.8040500@bogus.com> <4EF67019.1000309@necom830.hpcl.titech.ac.jp> <4EF8016D.4060208@necom830.hpcl.titech.ac.jp> Message-ID: <207827.1324922198@turing-police.cc.vt.edu> On Mon, 26 Dec 2011 12:32:46 EST, Ray Soucy said: > 2011/12/26 Masataka Ohta : > > And, if RA is obsoleted, which is a point of discussion, there > > is no reason to keep so bloated ND only for address resolution. > By who? Sources please. > A few people on NANOG complaining about RA is pretty far from deprecation of RA. Especially when some of the biggest IPv6 networks out there are still using it pretty heavily. (C''mon you guys, *deploy* already. It's pretty sad when people are arguing about stuff like this, and a frikkin' cow college out in the boonies pushing 300-400mbits/sec of IPv6 off-campus is still a "large" deployment. It's embarassing for the industry as a whole) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From mark at amplex.net Mon Dec 26 12:23:46 2011 From: mark at amplex.net (Mark Radabaugh) Date: Mon, 26 Dec 2011 13:23:46 -0500 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <207827.1324922198@turing-police.cc.vt.edu> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF4E24D.4020107@cis.vutbr.cz> <4EF4EBE0.4050609@necom830.hpcl.titech.ac.jp> <4EF58B34.6000904@rancid.berkeley.edu> <4EF59438.8040505@necom830.hpcl.titech.ac.jp> <1324724731.2763.26.camel@karl> <4EF6612F.2070901@necom830.hpcl.titech.ac.jp> <4EF66348.8040500@bogus.com> <4EF67019.1000309@necom830.hpcl.titech.ac.jp> <4EF8016D.4060208@necom830.hpcl.titech.ac.jp> <207827.1324922198@turing-police.cc.vt.edu> Message-ID: <4EF8BBB2.60805@amplex.net> On 12/26/11 12:56 PM, Valdis.Kletnieks at vt.edu wrote: > On Mon, 26 Dec 2011 12:32:46 EST, Ray Soucy said: >> 2011/12/26 Masataka Ohta: >>> And, if RA is obsoleted, which is a point of discussion, there >>> is no reason to keep so bloated ND only for address resolution. >> By who? Sources please. >> A few people on NANOG complaining about RA is pretty far from deprecation of RA. > Especially when some of the biggest IPv6 networks out there are still using > it pretty heavily. > > (C''mon you guys, *deploy* already. It's pretty sad when people are arguing > about stuff like this, and a frikkin' cow college out in the boonies pushing > 300-400mbits/sec of IPv6 off-campus is still a "large" deployment. It's > embarassing for the industry as a whole) > > Find me some decent consumer CPE and I would be more than happy to deploy IPv6. So far the choices I have found for consumer routers are pathetic. A fair number of them still have IPv4 issues. -- Mark Radabaugh Amplex mark at amplex.net 419.837.5015 From smb at cs.columbia.edu Mon Dec 26 13:46:06 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Mon, 26 Dec 2011 14:46:06 -0500 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EF8BBB2.60805@amplex.net> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF4E24D.4020107@cis.vutbr.cz> <4EF4EBE0.4050609@necom830.hpcl.titech.ac.jp> <4EF58B34.6000904@rancid.berkeley.edu> <4EF59438.8040505@necom830.hpcl.titech.ac.jp> <1324724731.2763.26.camel@karl> <4EF6612F.2070901@necom830.hpcl.titech.ac.jp> <4EF66348.8040500@bogus.com> <4EF67019.1000309@necom830.hpcl.titech.ac.jp> <4EF8016D.4060208@necom830.hpcl.titech.ac.jp> <207827.1324922198@turing-police.cc.vt.edu> <4EF8BBB2.60805@amplex.net> Message-ID: On Dec 26, 2011, at 1:23 46PM, Mark Radabaugh wrote: > On 12/26/11 12:56 PM, Valdis.Kletnieks at vt.edu wrote: >> On Mon, 26 Dec 2011 12:32:46 EST, Ray Soucy said: >>> 2011/12/26 Masataka Ohta: >>>> And, if RA is obsoleted, which is a point of discussion, there >>>> is no reason to keep so bloated ND only for address resolution. >>> By who? Sources please. >>> A few people on NANOG complaining about RA is pretty far from deprecation of RA. >> Especially when some of the biggest IPv6 networks out there are still using >> it pretty heavily. >> >> (C''mon you guys, *deploy* already. It's pretty sad when people are arguing >> about stuff like this, and a frikkin' cow college out in the boonies pushing >> 300-400mbits/sec of IPv6 off-campus is still a "large" deployment. It's >> embarassing for the industry as a whole) >> >> > Find me some decent consumer CPE and I would be more than happy to deploy IPv6. So far the choices I have found for consumer routers are pathetic. A fair number of them still have IPv4 issues. Not quite what you're asking for, but I was very pleasantly surprised to see that some (at least) Brother printers support IPv6. Progress... --Steve Bellovin, https://www.cs.columbia.edu/~smb From seth.mos at dds.nl Mon Dec 26 14:42:55 2011 From: seth.mos at dds.nl (Seth Mos) Date: Mon, 26 Dec 2011 21:42:55 +0100 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF4E24D.4020107@cis.vutbr.cz> <4EF4EBE0.4050609@necom830.hpcl.titech.ac.jp> <4EF58B34.6000904@rancid.berkeley.edu> <4EF59438.8040505@necom830.hpcl.titech.ac.jp> <1324724731.2763.26.camel@karl> <4EF6612F.2070901@necom830.hpcl.titech.ac.jp> <4EF66348.8040500@bogus.com> <4EF67019.1000309@necom830.hpcl.titech.ac.jp> <4EF8016D.4060208@necom830.hpcl.titech.ac.jp> <207827.1324922198@turing-police.cc.vt.edu> <4EF8BBB2.60805@amplex.net> Message-ID: Op 26 dec 2011, om 20:46 heeft Steven Bellovin het volgende geschreven: > Not quite what you're asking for, but I was very pleasantly surprised to see > that some (at least) Brother printers support IPv6. Progress... Indeed, my Mac has no issues printing or scanning to my MFC-9465DCN I purchased recently. I was pleasantly surprised, only SLAAC though, but it does register through mDNS and bonjour. Cheers, Seth From glen.kent at gmail.com Mon Dec 26 18:55:44 2011 From: glen.kent at gmail.com (Glen Kent) Date: Tue, 27 Dec 2011 06:25:44 +0530 Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: References: Message-ID: Sven, > also various bgp implementations will send the autoconfigure crap ip as the > next-hop instead of the session ip, resulting in all kinds of crap in your > route table (if not fixed with nasty hacks on your end ;) which doesn't > exactly make it easy to figure out which one belongs to which peer > all the more reason not to use that autoconfigure crap ;) As per RFC 2545 BGP announces a global address as the next-hop. Its only in one particular case that it advertises both global and link local addresses. So, i guess, BGP is not broken. Its only RIPng afaik that mandates using a link local address. Glen From mtinka at globaltransit.net Tue Dec 27 02:44:16 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Tue, 27 Dec 2011 16:44:16 +0800 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EF8BBB2.60805@amplex.net> References: <207827.1324922198@turing-police.cc.vt.edu> <4EF8BBB2.60805@amplex.net> Message-ID: <201112271644.20537.mtinka@globaltransit.net> On Tuesday, December 27, 2011 02:23:46 AM Mark Radabaugh wrote: > Find me some decent consumer CPE and I would be more than > happy to deploy IPv6. So far the choices I have found > for consumer routers are pathetic. A fair number of > them still have IPv4 issues. It's by no means exhaustive, but is a reasonable start: https://labs.ripe.net/Members/mirjam/ipv6-cpe-survey- updated-january-2011 https://labs.ripe.net/Members/mirjam/ipv6-cpe-surveys Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From sj_hznm at hotmail.com Tue Dec 27 05:47:10 2011 From: sj_hznm at hotmail.com (Joe) Date: Tue, 27 Dec 2011 11:47:10 +0000 Subject: overview on defending DDoS attack In-Reply-To: <4EF8BBB2.60805@amplex.net> References: , <1290980B-9003-4CD4-A713-A21111E877DA@delong.com>, <4EF23092.9090103@cis.vutbr.cz>, , <4EF4E24D.4020107@cis.vutbr.cz> <4EF4EBE0.4050609@necom830.hpcl.titech.ac.jp>, <4EF58B34.6000904@rancid.berkeley.edu>, <4EF59438.8040505@necom830.hpcl.titech.ac.jp> <1324724731.2763.26.camel@karl>, <4EF6612F.2070901@necom830.hpcl.titech.ac.jp> <4EF66348.8040500@bogus.com>, <4EF67019.1000309@necom830.hpcl.titech.ac.jp>, , <4EF8016D.4060208@necom830.hpcl.titech.ac.jp>, , <207827.1324922198@turing-police.cc.vt.edu>, <4EF8BBB2.60805@amplex.net> Message-ID: hi, is there any overview on current technology or method dealing with DDoS attack ? thanks in advance Joe From rdobbins at arbor.net Tue Dec 27 07:04:05 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 27 Dec 2011 13:04:05 +0000 Subject: overview on defending DDoS attack In-Reply-To: References: , <1290980B-9003-4CD4-A713-A21111E877DA@delong.com>, <4EF23092.9090103@cis.vutbr.cz>, , <4EF4E24D.4020107@cis.vutbr.cz> <4EF4EBE0.4050609@necom830.hpcl.titech.ac.jp>, <4EF58B34.6000904@rancid.berkeley.edu>, <4EF59438.8040505@necom830.hpcl.titech.ac.jp> <1324724731.2763.26.camel@karl>, <4EF6612F.2070901@necom830.hpcl.titech.ac.jp> <4EF66348.8040500@bogus.com>, <4EF67019.1000309@necom830.hpcl.titech.ac.jp>, , <4EF8016D.4060208@necom830.hpcl.titech.ac.jp>, , <207827.1324922198@turing-police.cc.vt.edu>, <4EF8BBB2.60805@amplex.net> Message-ID: On Dec 27, 2011, at 6:47 PM, Joe wrote: > is there any overview on current technology or method dealing with DDoS attack ? ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From tom at ninjabadger.net Tue Dec 27 07:33:02 2011 From: tom at ninjabadger.net (Tom Hill) Date: Tue, 27 Dec 2011 13:33:02 +0000 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EF8BBB2.60805@amplex.net> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF4E24D.4020107@cis.vutbr.cz> <4EF4EBE0.4050609@necom830.hpcl.titech.ac.jp> <4EF58B34.6000904@rancid.berkeley.edu> <4EF59438.8040505@necom830.hpcl.titech.ac.jp> <1324724731.2763.26.camel@karl> <4EF6612F.2070901@necom830.hpcl.titech.ac.jp> <4EF66348.8040500@bogus.com> <4EF67019.1000309@necom830.hpcl.titech.ac.jp> <4EF8016D.4060208@necom830.hpcl.titech.ac.jp> <207827.1324922198@turing-police.cc.vt.edu> <4EF8BBB2.60805@amplex.net> Message-ID: <1324992782.3698.3.camel@teh-desktop> On Mon, 2011-12-26 at 13:23 -0500, Mark Radabaugh wrote: > Find me some decent consumer CPE and I would be more than happy to > deploy IPv6. So far the choices I have found for consumer routers > are pathetic. A fair number of them still have IPv4 issues. You might find Adrian Kennard's blog to be of interest: http://revk.www.me.uk/2011/11/ipv6-for-consumers-on-dsl-at-last.html Pretty inexpensive, even here in rip-off Britain (~?32-35 inc. VAT @20%) to the point where a 'niche' ISP like A&A[1] can actually give them away for free with new lines. Tom [1] http://aa.net.uk From tpoder at cis.vutbr.cz Tue Dec 27 15:23:48 2011 From: tpoder at cis.vutbr.cz (Tomas Podermanski) Date: Tue, 27 Dec 2011 22:23:48 +0100 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF38D5A.4070003@cis.vutbr.cz> Message-ID: <4EFA3764.1040000@cis.vutbr.cz> Hi, On 12/23/11 7:48 AM, Ray Soucy wrote: > On Thu, Dec 22, 2011 at 3:04 PM, Tomas Podermanski wrote: > >> Well, then how many devices do you have in the network that uses IPv6? > Good question, and I applaud you for wanting to verify that people > talking about IPv6 have legitimate experience deploying it. > > I dug into the database I log all IPv6 traffic into. We have 8,509 > active hosts using IPv6, that's in comparison to 35,229 on the IPv4 > side, so about 24% (mind you, this is only the LAN networks we manage, > we provide IPv6 transit to other entities as the regional R&E > network). > > At this point over 95% of IPv4 LAN networks have IPv6 available, > wireless is still a challenge (which is a big part of the difference > between the host numbers you see above). > > We participate in Google's trusted IPv6 program, so Google announces > AAAA's to us for nearly all their services, so a significant amount of > bandwidth is actually over IPv6. I would say that Google does make up > the majority of IPv6 traffic though; there isn't much else out there > announcing AAAA's yet. > > We have always taken the approach that IPv6 isn't ready to be deployed > if you can't do so while maintaining the same standards you have for > IPv4 in the areas of manageability, security, availability, and > stability. And we literally spent a few years modifying internal > systems (and implementing new ones) to support IPv6 before we started > making it available. See > http://reports.informationweek.com/abstract/19/2233/Network-Infrastructure/strategy-session-ipv6.html > for the case I've been making the last few years, or listen to me > (and others) talking a little about it on Cisco's Higher Education > webcast series http://www.cisco.com/web/strategy/education/us_education/webcasts.html I've watched the webcast and I like it. It's very realistic approach and I especially agree with opinion that deploying IPv6 means going into many compromises. We have been faced with very similar (almost same) troubles that you have been talking about. > >> Do you have implemented first hop security? What will you do when some >> user runs RA flood attack > You can hear me talk a little about that in the Cisco webcast. Right > now we maintain a PACL on our switches that filter RA or DHCPv6 server > traffic originating from access ports. As you mentioned it doesn't > protect against malicious attempts to disrupt services on the network > (fragmented packets) but it does add a reasonable level of stability > (e.g. prevent Windows ICS) to levels that are similar to IPv4. In > addition, we have a process that monitors our routers for new RAs on > the network, and alerts us to that (which would let us respond to a > malicious RA that got past the PACL). We are doing things just in the same way. Using PACL where is it possible (almost nowhere) and rest of the network we are trying to monitor. In case when an invalid RA appears we tries to repair it. For that we use combination of scapy sripts and home made tools (we were not satisfied with ndpmon, rafixd, ...). My colleague had a talk at that topic that is available http://tv.funet.fi/medar/showRecordingInfo.do?id=/metadata/fi/csc/tapahtumat/2011/gn3/ipv6/Fakerouterdetectionpracticalexperience.xml, slides http://openwiki.uninett.no/_media/geantcampus:2011-gn3na3t4-ipv6-gregr.pdf . Having over 120 subnets monitoring is not the perfect solution. Requires installation of extra probes into each segment (so we do it only for some segments) and can't solve malicious attacks. But is better than nothing - for many subnets it is the only thing we can do. At least it minimizes impact of Microsoft's ICS behavior. We probably haven't see any malicious attack on that. It's quite difficult say it for sure, because is quite difficult to distinguish which RA's are originated on ICS or witch ones are "other" activity. But remains that monitoring of rogue RA shows to us sometimes a really weird traffic. I believe that is a matter of time when viruses/trojans will start using IPv6 features to perform DNS hijack as we were able to observe it in IPv4 (DNSChanger) a few years ago. Fortunately from a user perspective there is still quite easy solution how to guard against that attack in the IPv6 environment. I think we all know that solution :-) > > For neighbor table exhaustion, I've written a set of scripts that I > can use in a lab environment to perform the attacks against the > platforms we use, and test how they fair. There is a pretty wide > range of results. Most of the larger platforms that are the ones we > would be concerned about actually hit CPU limitations before neighbor > table exhaustion is accomplished, mainly because the neighbor > discovery process doesn't appear to be implemented in hardware. It > doesn't take much to pull off the attack either; a handful of > residential connections would do the trick. This isn't an IPv6 > problem so much as a vendor implementation problem, though. Like most > DoS and DDoS attack vectors, vendors will need to take extra steps to > harden equipment against these attack vectors as they become aware of > them. > > Until vendors catch up (and that includes us having the funds to > upgrade to new platforms that do a better job with it), we have opt'd > to make use of longer prefixes than 64-bit (in fact we mirror the > capacity of the IPv4 prefix; so a /24 in IPv4 would be a /120 in > IPv6). A good description of this is available in some slides by Jeff > Wheeler at http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf > > While your mileage may vary with longer prefixes, with the same > attacks we saw the impact on CPU usage to be less than half when > longer prefixes were used, and that's pretty good. You can also keep > external attacks from reaching internal routers if you don't do route > summarization internally, which sees considerable gains, as more of > that logic appears to be in hardware. In that area we also tried to use longer prefixes than /64, but we had difficulties on some devices. There was two kind of problems. Some of devices weren't able properly handle longer prefixes for example in routing protocols. The second group of devices tries to solve processing longer prefixes via software. So we had to gave up of using longer prefixes and now we uses 64-bit prefixes including point to point links (and hope that nothing will happen). But fact is that was 3 years ago, so maybe today the situation is much better. I haven't check for long time. > > On the deployment side, we make use of DHCPv6 and RA with M and O set, > and A unset. Our DHCPv6 servers only hand out IPv6 addresses to > registered systems that are in the database and have been flagged as > OK for IPv6. This has allowed us to roll out IPv6 on a host-by-host > basis, rather than a network-wide basis (as you would need to do with > SLAAC). > > This does have the consequence of excluding hosts from IPv6, > piticurally Windows XP systems, and pre-Lion OS X systems. But since > IPv6 isn't "required" yet (there is really no IPv6-only content yet), > we take the position that we only provide IPv6 to systems that support > DHCPv6 and have an adequate IPv6 host-level firewall as part of their > IPv6 implementation. This makes it easy to exclude hosts that might > be problematic to deliver IPv6 to, due to lack of security, or even > bugs (RHEL 3 can kernel panic when connected to over IPv6, for > example). It also keeps the pressure on to upgrade legacy systems. With that we had a little differed attitude. Our idea was preferring native connectivity instead of running unattended tunneled traffic and traffic forwarded by ICS. We also were not certain whether SLAAC or DHCPv6 would be widely used. So we decided to preffer SLAAC because we wanted support as much system as possible. We also tried to develop our system solving data retention with connection to privacy extension (tech report http://www.fit.vutbr.cz/research/view_pub.php?id=9840 and related presentation http://www.cesnet.cz/akce/2011/monitorovani-kampusovych-siti/p/podemanski-monitoring-ipv6-toku.pdf) . It runs quite well in our campus, it is maybye interesting research project but frankly said I have doubt whether such system is reliable to use in really large scale. Now, when apple started supporting DHCPv6 it seems to me that DHCPv6 will be a common way for configuring addresses in a enterprise environment so maybe we will start thinking about it. There is another big issue with DUIDs. Talking aboud DUIDs how do you solve that problem in your environment ? For v4 we have automatized (home made) system where users register their MAC addresses and based on it the the configuration for DHCP servers is created. In your presentation I saw that something similar is used in your environment as well. Do you use some automatized system for gathering UIDs or do you have to manually maintain a new DUID after every re-installation of OS ? > > Wireless is an area we would really like to move forward with IPv6, > but we still have concerns that need to be addressed before that can > happen. In a Cisco environment, like ours, for example. IPv6 > requires Ethernet Mode Multicast to be enabled on the WLAN. > Unfortunately it doesn't provide tools to filter which multicast > traffic is permitted, and at the scale we deploy wireless it just > isn't practical. We might be able to re-architect wireless to better > handle this, but that's a future project. > > I think the big picture here is that IPv6 isn't as "easy" as it should > be for large deployments just yet, but that's the case with any new > technology. The more people who begin to work through it, the more we > will identify problems, and work to resolve them. I agree with you. Deploying IPv6 is really not easy and not cheep as some IPv6 enthusiasts claims. Having practical experience it seems to me that many things in IPv6 that are very differed comparing to IPv4 (and I am not sure whether all this differences are really necessary) and that is the reason why many people and organizations prefer putting off deploying IPv6 instead investing effort and - of course - money. Tomas From rps at maine.edu Tue Dec 27 15:53:39 2011 From: rps at maine.edu (Ray Soucy) Date: Tue, 27 Dec 2011 16:53:39 -0500 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EFA3764.1040000@cis.vutbr.cz> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF38D5A.4070003@cis.vutbr.cz> <4EFA3764.1040000@cis.vutbr.cz> Message-ID: Much like with IPv4, we capture the DUID at the time of registration and store it in the database. We make use of a web-based registration system that allows users to register computers for network access with a valid ID (that piece is still in development, though). There is still work to be done on DHCPd for IPv6. Along with the DUID we need support for specifying and logging IAID (especially with fixed-address statements). My initial reaction to DUID was one of complete hatred at first, but like most things IPv6, having worked with it a while longer, it's actually quite useful. We just need tools and knowledge to catch up. So far the biggest "problem" was people creating system images poorly and not deleting DUID, leading to duplicates. Our systems people know better these days and it's a non-issue, though. On a side note, you can build a DHCPd config these days that uses the MAC address as an identifier, and if a DUID is based on that MAC using one of the two methods that do, then it will make the association. It's not ideal, but it is a quick fix to the "we only have a list of MAC addresses" problem. I've actually been working to start an open source (free software) group dedicated to the development of IPv6 infrastructure systems based on Linux. Hopefully this summer I'll be at a point where we have some useful technology to provide. You can either talk about the challenges of IPv6 deployment, or actively try to find solutions to them for everyone is the general idea. On Tue, Dec 27, 2011 at 4:23 PM, Tomas Podermanski wrote: > Hi, > > On 12/23/11 7:48 AM, Ray Soucy wrote: >> On Thu, Dec 22, 2011 at 3:04 PM, Tomas Podermanski wrote: >> >>> Well, then how many devices do you have in the network that uses IPv6? >> Good question, and I applaud you for wanting to verify that people >> talking about IPv6 have legitimate experience deploying it. >> >> I dug into the database I log all IPv6 traffic into. ?We have 8,509 >> active hosts using IPv6, that's in comparison to 35,229 on the IPv4 >> side, so about 24% (mind you, this is only the LAN networks we manage, >> we provide IPv6 transit to other entities as the regional R&E >> network). >> >> At this point over 95% of IPv4 LAN networks have IPv6 available, >> wireless is still a challenge (which is a big part of the difference >> between the host numbers you see above). >> >> We participate in Google's trusted IPv6 program, so Google announces >> AAAA's to us for nearly all their services, so a significant amount of >> bandwidth is actually over IPv6. ?I would say that Google does make up >> the majority of IPv6 traffic though; there isn't much else out there >> announcing AAAA's yet. >> >> We have always taken the approach that IPv6 isn't ready to be deployed >> if you can't do so while maintaining the same standards you have for >> IPv4 in the areas of manageability, security, availability, and >> stability. ?And we literally spent a few years modifying internal >> systems (and implementing new ones) to support IPv6 before we started >> making it available. See >> http://reports.informationweek.com/abstract/19/2233/Network-Infrastructure/strategy-session-ipv6.html >> ? for the case I've been making the last few years, or listen to me >> (and others) talking a little about it on Cisco's Higher Education >> webcast series http://www.cisco.com/web/strategy/education/us_education/webcasts.html > > I've watched the webcast and I like it. It's very realistic approach and > I especially agree with opinion that deploying IPv6 means going into > many compromises. We have been faced with very similar (almost same) > troubles that you have been talking about. >> >>> Do you have implemented first hop ?security? What will you do when some >>> user runs RA flood attack >> You can hear me talk a little about that in the Cisco webcast. ?Right >> now we maintain a PACL on our switches that filter RA or DHCPv6 server >> traffic originating from access ports. ?As you mentioned it doesn't >> protect against malicious attempts to disrupt services on the network >> (fragmented packets) but it does add a reasonable level of stability >> (e.g. prevent Windows ICS) to levels that are similar to IPv4. ?In >> addition, we have a process that monitors our routers for new RAs on >> the network, and alerts us to that (which would let us respond to a >> malicious RA that got past the PACL). > > We are doing things just in the same way. Using PACL where is it > possible (almost nowhere) and rest of the network we are trying to > monitor. In case when an invalid RA appears we tries to repair it. For > that we use combination of scapy sripts and home made tools (we were not > satisfied with ndpmon, rafixd, ...). ?My colleague had a talk at that > topic that is available > http://tv.funet.fi/medar/showRecordingInfo.do?id=/metadata/fi/csc/tapahtumat/2011/gn3/ipv6/Fakerouterdetectionpracticalexperience.xml, > slides > http://openwiki.uninett.no/_media/geantcampus:2011-gn3na3t4-ipv6-gregr.pdf . > > Having over 120 subnets monitoring is not the perfect solution. Requires > installation of extra probes into each segment (so we do it only for > some segments) and can't solve malicious attacks. But is better than > nothing - for many subnets it is the only thing we can do. At least it > minimizes impact of Microsoft's ICS behavior. > > We probably haven't see any malicious attack on that. It's quite > difficult say it for sure, because is quite difficult to distinguish > which RA's are originated on ICS or witch ones are "other" activity. But > remains that monitoring of rogue RA shows to us sometimes a really weird > traffic. > > I believe that is a matter of time when viruses/trojans will start using > IPv6 features to perform DNS hijack as we were able to observe it in > IPv4 (DNSChanger) a few years ago. Fortunately from a user perspective > there is still quite easy solution how to guard against that attack in > the IPv6 environment. I think we all know that solution :-) > >> >> For neighbor table exhaustion, I've written a set of scripts that I >> can use in a lab environment to perform the attacks against the >> platforms we use, and test how they fair. ?There is a pretty wide >> range of results. ?Most of the larger platforms that are the ones we >> would be concerned about actually hit CPU limitations before neighbor >> table exhaustion is accomplished, mainly because the neighbor >> discovery process doesn't appear to be implemented in hardware. ?It >> doesn't take much to pull off the attack either; a handful of >> residential connections would do the trick. ?This isn't an IPv6 >> problem so much as a vendor implementation problem, though. ?Like most >> DoS and DDoS attack vectors, vendors will need to take extra steps to >> harden equipment against these attack vectors as they become aware of >> them. >> >> Until vendors catch up (and that includes us having the funds to >> upgrade to new platforms that do a better job with it), we have opt'd >> to make use of longer prefixes than 64-bit (in fact we mirror the >> capacity of the IPv4 prefix; so a /24 in IPv4 would be a /120 in >> IPv6). ?A good description of this is available in some slides by Jeff >> Wheeler at http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf >> >> While your mileage may vary with longer prefixes, with the same >> attacks we saw the impact on CPU usage to be less than half when >> longer prefixes were used, and that's pretty good. ?You can also keep >> external attacks from reaching internal routers if you don't do route >> summarization internally, which sees considerable gains, as more of >> that logic appears to be in hardware. > > In that area we also tried to use longer prefixes than /64, but we had > difficulties on some devices. There was two kind of problems. Some of > devices weren't able properly handle longer prefixes for example in > routing protocols. The second group of devices tries to solve processing > longer prefixes via software. So we had to gave up of using longer > prefixes and now we uses 64-bit prefixes including point to point links > (and hope that nothing will happen). But fact is that was 3 years ago, > so maybe today the situation is much better. I haven't check for long time. > >> >> On the deployment side, we make use of DHCPv6 and RA with M and O set, >> and A unset. ?Our DHCPv6 servers only hand out IPv6 addresses to >> registered systems that are in the database and have been flagged as >> OK for IPv6. ?This has allowed us to roll out IPv6 on a host-by-host >> basis, rather than a network-wide basis (as you would need to do with >> SLAAC). >> >> This does have the consequence of excluding hosts from IPv6, >> piticurally Windows XP systems, and pre-Lion OS X systems. ?But since >> IPv6 isn't "required" yet (there is really no IPv6-only content yet), >> we take the position that we only provide IPv6 to systems that support >> DHCPv6 and have an adequate IPv6 host-level firewall as part of their >> IPv6 implementation. ?This makes it easy to exclude hosts that might >> be problematic to deliver IPv6 to, due to lack of security, or even >> bugs (RHEL 3 can kernel panic when connected to over IPv6, for >> example). ?It also keeps the pressure on to upgrade legacy systems. > > With that we had a little differed attitude. Our idea was preferring > native connectivity instead of running unattended tunneled traffic and > traffic forwarded by ICS. We also were not certain whether SLAAC or > DHCPv6 would be widely used. So we decided to preffer SLAAC because we > wanted support as much system as possible. We also tried to develop our > system solving data retention with connection to privacy extension > (tech report http://www.fit.vutbr.cz/research/view_pub.php?id=9840 and > related presentation > http://www.cesnet.cz/akce/2011/monitorovani-kampusovych-siti/p/podemanski-monitoring-ipv6-toku.pdf) > . It runs quite well in our campus, it is maybye interesting research > project but frankly said I have doubt whether such system is reliable to > use in really large scale. > > Now, when apple started supporting DHCPv6 it seems to me that DHCPv6 > will be a common way for configuring addresses in a enterprise > environment so maybe we will start thinking about it. There is another > big issue with DUIDs. > > Talking aboud DUIDs how do you solve that problem in your environment ? > For v4 we have automatized (home made) system where users register their > MAC addresses and based on it the the configuration for DHCP servers is > created. In your presentation I saw that something similar is used in > your environment as well. Do you use some automatized system for > gathering UIDs or do you have to manually maintain a new DUID after > every re-installation of OS ? > >> >> Wireless is an area we would really like to move forward with IPv6, >> but we still have concerns that need to be addressed before that can >> happen. ?In a Cisco environment, like ours, for example. ?IPv6 >> requires Ethernet Mode Multicast to be enabled on the WLAN. >> Unfortunately it doesn't provide tools to filter which multicast >> traffic is permitted, and at the scale we deploy wireless it just >> isn't practical. ?We might be able to re-architect wireless to better >> handle this, but that's a future project. >> >> I think the big picture here is that IPv6 isn't as "easy" as it should >> be for large deployments just yet, but that's the case with any new >> technology. ?The more people who begin to work through it, the more we >> will identify problems, and work to resolve them. > > I agree with you. Deploying IPv6 is really not easy and not cheep as > some IPv6 enthusiasts claims. Having practical experience it seems to me > that many things in IPv6 that are very differed comparing to IPv4 (and I > am not sure whether all this differences are really necessary) and that > is the reason why many people and organizations prefer putting off > deploying IPv6 instead investing effort and - of course - money. > > Tomas > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From Valdis.Kletnieks at vt.edu Tue Dec 27 15:52:49 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 27 Dec 2011 16:52:49 -0500 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: Your message of "Tue, 27 Dec 2011 22:23:48 +0100." <4EFA3764.1040000@cis.vutbr.cz> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF38D5A.4070003@cis.vutbr.cz> <4EFA3764.1040000@cis.vutbr.cz> Message-ID: <246559.1325022769@turing-police.cc.vt.edu> On Tue, 27 Dec 2011 22:23:48 +0100, Tomas Podermanski said: > I agree with you. Deploying IPv6 is really not easy and not cheep as > some IPv6 enthusiasts claims. It's probably as easy and as cheap as IPv4 is. You've just forgotten how expensive and painful it was to solve all the exact same problems on the IPv4 side when you built your IPv4 infrastructure all those years ago. Meanwhile, the IPv6 enthusasts have forgotten how hard it was to deploy their IPv6 infrastructure all those years ago. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From tpoder at cis.vutbr.cz Tue Dec 27 16:16:32 2011 From: tpoder at cis.vutbr.cz (Tomas Podermanski) Date: Tue, 27 Dec 2011 23:16:32 +0100 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF38D5A.4070003@cis.vutbr.cz> <4EFA3764.1040000@cis.vutbr.cz> Message-ID: <4EFA43C0.3030500@cis.vutbr.cz> On 12/27/11 10:53 PM, Ray Soucy wrote: > Much like with IPv4, we capture the DUID at the time of registration > and store it in the database. We make use of a web-based registration > system that allows users to register computers for network access with > a valid ID (that piece is still in development, though). > > There is still work to be done on DHCPd for IPv6. Along with the DUID > we need support for specifying and logging IAID (especially with > fixed-address statements). > > My initial reaction to DUID was one of complete hatred at first, but > like most things IPv6, having worked with it a while longer, it's > actually quite useful. We just need tools and knowledge to catch up. > So far the biggest "problem" was people creating system images poorly > and not deleting DUID, leading to duplicates. Our systems people know > better these days and it's a non-issue, though. > > On a side note, you can build a DHCPd config these days that uses the > MAC address as an identifier, and if a DUID is based on that MAC using > one of the two methods that do, then it will make the association. > It's not ideal, but it is a quick fix to the "we only have a list of > MAC addresses" problem. It was my initial idea to workaround DUID issue. But MAC address in DUID is not necessary the address of a communicating interface. It can be derived from wireless interface when a node is connected via an Ethernet adapter. So I had to leave that idea very soon. In addition, RFC refuses DUID to be treated in that way :-). There is an RFC 6221 that solves that problem, however I haven't seen any implementation yet. Tomas > > > > > I've actually been working to start an open source (free software) > group dedicated to the development of IPv6 infrastructure systems > based on Linux. Hopefully this summer I'll be at a point where we > have some useful technology to provide. You can either talk about the > challenges of IPv6 deployment, or actively try to find solutions to > them for everyone is the general idea. > > > > > > On Tue, Dec 27, 2011 at 4:23 PM, Tomas Podermanski wrote: >> Hi, >> >> On 12/23/11 7:48 AM, Ray Soucy wrote: >>> On Thu, Dec 22, 2011 at 3:04 PM, Tomas Podermanski wrote: >>> >>>> Well, then how many devices do you have in the network that uses IPv6? >>> Good question, and I applaud you for wanting to verify that people >>> talking about IPv6 have legitimate experience deploying it. >>> >>> I dug into the database I log all IPv6 traffic into. We have 8,509 >>> active hosts using IPv6, that's in comparison to 35,229 on the IPv4 >>> side, so about 24% (mind you, this is only the LAN networks we manage, >>> we provide IPv6 transit to other entities as the regional R&E >>> network). >>> >>> At this point over 95% of IPv4 LAN networks have IPv6 available, >>> wireless is still a challenge (which is a big part of the difference >>> between the host numbers you see above). >>> >>> We participate in Google's trusted IPv6 program, so Google announces >>> AAAA's to us for nearly all their services, so a significant amount of >>> bandwidth is actually over IPv6. I would say that Google does make up >>> the majority of IPv6 traffic though; there isn't much else out there >>> announcing AAAA's yet. >>> >>> We have always taken the approach that IPv6 isn't ready to be deployed >>> if you can't do so while maintaining the same standards you have for >>> IPv4 in the areas of manageability, security, availability, and >>> stability. And we literally spent a few years modifying internal >>> systems (and implementing new ones) to support IPv6 before we started >>> making it available. See >>> http://reports.informationweek.com/abstract/19/2233/Network-Infrastructure/strategy-session-ipv6.html >>> for the case I've been making the last few years, or listen to me >>> (and others) talking a little about it on Cisco's Higher Education >>> webcast series http://www.cisco.com/web/strategy/education/us_education/webcasts.html >> I've watched the webcast and I like it. It's very realistic approach and >> I especially agree with opinion that deploying IPv6 means going into >> many compromises. We have been faced with very similar (almost same) >> troubles that you have been talking about. >>>> Do you have implemented first hop security? What will you do when some >>>> user runs RA flood attack >>> You can hear me talk a little about that in the Cisco webcast. Right >>> now we maintain a PACL on our switches that filter RA or DHCPv6 server >>> traffic originating from access ports. As you mentioned it doesn't >>> protect against malicious attempts to disrupt services on the network >>> (fragmented packets) but it does add a reasonable level of stability >>> (e.g. prevent Windows ICS) to levels that are similar to IPv4. In >>> addition, we have a process that monitors our routers for new RAs on >>> the network, and alerts us to that (which would let us respond to a >>> malicious RA that got past the PACL). >> We are doing things just in the same way. Using PACL where is it >> possible (almost nowhere) and rest of the network we are trying to >> monitor. In case when an invalid RA appears we tries to repair it. For >> that we use combination of scapy sripts and home made tools (we were not >> satisfied with ndpmon, rafixd, ...). My colleague had a talk at that >> topic that is available >> http://tv.funet.fi/medar/showRecordingInfo.do?id=/metadata/fi/csc/tapahtumat/2011/gn3/ipv6/Fakerouterdetectionpracticalexperience.xml, >> slides >> http://openwiki.uninett.no/_media/geantcampus:2011-gn3na3t4-ipv6-gregr.pdf . >> >> Having over 120 subnets monitoring is not the perfect solution. Requires >> installation of extra probes into each segment (so we do it only for >> some segments) and can't solve malicious attacks. But is better than >> nothing - for many subnets it is the only thing we can do. At least it >> minimizes impact of Microsoft's ICS behavior. >> >> We probably haven't see any malicious attack on that. It's quite >> difficult say it for sure, because is quite difficult to distinguish >> which RA's are originated on ICS or witch ones are "other" activity. But >> remains that monitoring of rogue RA shows to us sometimes a really weird >> traffic. >> >> I believe that is a matter of time when viruses/trojans will start using >> IPv6 features to perform DNS hijack as we were able to observe it in >> IPv4 (DNSChanger) a few years ago. Fortunately from a user perspective >> there is still quite easy solution how to guard against that attack in >> the IPv6 environment. I think we all know that solution :-) >> >>> For neighbor table exhaustion, I've written a set of scripts that I >>> can use in a lab environment to perform the attacks against the >>> platforms we use, and test how they fair. There is a pretty wide >>> range of results. Most of the larger platforms that are the ones we >>> would be concerned about actually hit CPU limitations before neighbor >>> table exhaustion is accomplished, mainly because the neighbor >>> discovery process doesn't appear to be implemented in hardware. It >>> doesn't take much to pull off the attack either; a handful of >>> residential connections would do the trick. This isn't an IPv6 >>> problem so much as a vendor implementation problem, though. Like most >>> DoS and DDoS attack vectors, vendors will need to take extra steps to >>> harden equipment against these attack vectors as they become aware of >>> them. >>> >>> Until vendors catch up (and that includes us having the funds to >>> upgrade to new platforms that do a better job with it), we have opt'd >>> to make use of longer prefixes than 64-bit (in fact we mirror the >>> capacity of the IPv4 prefix; so a /24 in IPv4 would be a /120 in >>> IPv6). A good description of this is available in some slides by Jeff >>> Wheeler at http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf >>> >>> While your mileage may vary with longer prefixes, with the same >>> attacks we saw the impact on CPU usage to be less than half when >>> longer prefixes were used, and that's pretty good. You can also keep >>> external attacks from reaching internal routers if you don't do route >>> summarization internally, which sees considerable gains, as more of >>> that logic appears to be in hardware. >> In that area we also tried to use longer prefixes than /64, but we had >> difficulties on some devices. There was two kind of problems. Some of >> devices weren't able properly handle longer prefixes for example in >> routing protocols. The second group of devices tries to solve processing >> longer prefixes via software. So we had to gave up of using longer >> prefixes and now we uses 64-bit prefixes including point to point links >> (and hope that nothing will happen). But fact is that was 3 years ago, >> so maybe today the situation is much better. I haven't check for long time. >> >>> On the deployment side, we make use of DHCPv6 and RA with M and O set, >>> and A unset. Our DHCPv6 servers only hand out IPv6 addresses to >>> registered systems that are in the database and have been flagged as >>> OK for IPv6. This has allowed us to roll out IPv6 on a host-by-host >>> basis, rather than a network-wide basis (as you would need to do with >>> SLAAC). >>> >>> This does have the consequence of excluding hosts from IPv6, >>> piticurally Windows XP systems, and pre-Lion OS X systems. But since >>> IPv6 isn't "required" yet (there is really no IPv6-only content yet), >>> we take the position that we only provide IPv6 to systems that support >>> DHCPv6 and have an adequate IPv6 host-level firewall as part of their >>> IPv6 implementation. This makes it easy to exclude hosts that might >>> be problematic to deliver IPv6 to, due to lack of security, or even >>> bugs (RHEL 3 can kernel panic when connected to over IPv6, for >>> example). It also keeps the pressure on to upgrade legacy systems. >> With that we had a little differed attitude. Our idea was preferring >> native connectivity instead of running unattended tunneled traffic and >> traffic forwarded by ICS. We also were not certain whether SLAAC or >> DHCPv6 would be widely used. So we decided to preffer SLAAC because we >> wanted support as much system as possible. We also tried to develop our >> system solving data retention with connection to privacy extension >> (tech report http://www.fit.vutbr.cz/research/view_pub.php?id=9840 and >> related presentation >> http://www.cesnet.cz/akce/2011/monitorovani-kampusovych-siti/p/podemanski-monitoring-ipv6-toku.pdf) >> . It runs quite well in our campus, it is maybye interesting research >> project but frankly said I have doubt whether such system is reliable to >> use in really large scale. >> >> Now, when apple started supporting DHCPv6 it seems to me that DHCPv6 >> will be a common way for configuring addresses in a enterprise >> environment so maybe we will start thinking about it. There is another >> big issue with DUIDs. >> >> Talking aboud DUIDs how do you solve that problem in your environment ? >> For v4 we have automatized (home made) system where users register their >> MAC addresses and based on it the the configuration for DHCP servers is >> created. In your presentation I saw that something similar is used in >> your environment as well. Do you use some automatized system for >> gathering UIDs or do you have to manually maintain a new DUID after >> every re-installation of OS ? >> >>> Wireless is an area we would really like to move forward with IPv6, >>> but we still have concerns that need to be addressed before that can >>> happen. In a Cisco environment, like ours, for example. IPv6 >>> requires Ethernet Mode Multicast to be enabled on the WLAN. >>> Unfortunately it doesn't provide tools to filter which multicast >>> traffic is permitted, and at the scale we deploy wireless it just >>> isn't practical. We might be able to re-architect wireless to better >>> handle this, but that's a future project. >>> >>> I think the big picture here is that IPv6 isn't as "easy" as it should >>> be for large deployments just yet, but that's the case with any new >>> technology. The more people who begin to work through it, the more we >>> will identify problems, and work to resolve them. >> I agree with you. Deploying IPv6 is really not easy and not cheep as >> some IPv6 enthusiasts claims. Having practical experience it seems to me >> that many things in IPv6 that are very differed comparing to IPv4 (and I >> am not sure whether all this differences are really necessary) and that >> is the reason why many people and organizations prefer putting off >> deploying IPv6 instead investing effort and - of course - money. >> >> Tomas >> >> > > From mohta at necom830.hpcl.titech.ac.jp Tue Dec 27 16:49:21 2011 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 28 Dec 2011 07:49:21 +0900 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <207827.1324922198@turing-police.cc.vt.edu> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF4E24D.4020107@cis.vutbr.cz> <4EF4EBE0.4050609@necom830.hpcl.titech.ac.jp> <4EF58B34.6000904@rancid.berkeley.edu> <4EF59438.8040505@necom830.hpcl.titech.ac.jp> <1324724731.2763.26.camel@karl> <4EF6612F.2070901@necom830.hpcl.titech.ac.jp> <4EF66348.8040500@bogus.com> <4EF67019.1000309@necom830.hpcl.titech.ac.jp> <4EF8016D.4060208@necom830.hpcl.titech.ac.jp> <207827.1324922198@turing-police.cc.vt.edu> Message-ID: <4EFA4B71.20401@necom830.hpcl.titech.ac.jp> Valdis.Kletnieks at vt.edu wrote: >>> And, if RA is obsoleted, which is a point of discussion, there >>> is no reason to keep so bloated ND only for address resolution. > >> By who? Sources please. >> A few people on NANOG complaining about RA is pretty far from deprecation of RA. > > Especially when some of the biggest IPv6 networks out there are still using > it pretty heavily. That's not a valid counter argument against people who found problems in certain environment. IPv6, as is, might work well under some environment assumed by IPng/IPv6 WG, a committee. The environment may be large. However, as the committee made so many wrong assumptions such as: All the link layers were similar to PPP, Ethernet or ATM ATM was not broadcast capable but multicast capable Network configuration was mostly stationary Multicast was reliable Scale of multicast was not large ICMP packet too big won't be filtered A site was single homed or, if not, all the global prefixes was working IPv6 does not work well in many environments. In this case, the following statement in RFC1883: If the minimum time for rebooting the node is known (often more than 6 seconds), is the wrong assumption which made RA annoying. Masataka Ohta From glen.kent at gmail.com Tue Dec 27 17:28:19 2011 From: glen.kent at gmail.com (Glen Kent) Date: Wed, 28 Dec 2011 04:58:19 +0530 Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: References: Message-ID: It seems ISIS and OSPFv3 use the link local next-hop in their route advertisements. We discussed that SLAAC doesnt work with prefixes > 64 on the ethernet medium (which i believe is quite, if not most, prevalent). If thats the case then how are operators who assign netmasks > 64 use ISIS and OSPF, since these protocols will use the link local address? I had assumed that nodes derive their link local address from the Route Advertisements. They derive their least significant 64 bytes from their MACs and the most significant 64 from the prefix announced in the RAs. Glen On Tue, Dec 27, 2011 at 6:25 AM, Glen Kent wrote: > Sven, > >> also various bgp implementations will send the autoconfigure crap ip as the >> next-hop instead of the session ip, resulting in all kinds of crap in your >> route table (if not fixed with nasty hacks on your end ;) which doesn't >> exactly make it easy to figure out which one belongs to which peer >> all the more reason not to use that autoconfigure crap ;) > > As per RFC 2545 BGP announces a global address as the next-hop. Its > only in one particular case that it advertises both global and link > local addresses. > > So, i guess, BGP is not broken. > > Its only RIPng afaik that mandates using a link local address. > > Glen From Valdis.Kletnieks at vt.edu Tue Dec 27 17:28:40 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 27 Dec 2011 18:28:40 -0500 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: Your message of "Wed, 28 Dec 2011 07:49:21 +0900." <4EFA4B71.20401@necom830.hpcl.titech.ac.jp> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF4E24D.4020107@cis.vutbr.cz> <4EF4EBE0.4050609@necom830.hpcl.titech.ac.jp> <4EF58B34.6000904@rancid.berkeley.edu> <4EF59438.8040505@necom830.hpcl.titech.ac.jp> <1324724731.2763.26.camel@karl> <4EF6612F.2070901@necom830.hpcl.titech.ac.jp> <4EF66348.8040500@bogus.com> <4EF67019.1000309@necom830.hpcl.titech.ac.jp> <4EF8016D.4060208@necom830.hpcl.titech.ac.jp> <207827.1324922198@turing-police.cc.vt.edu> <4EFA4B71.20401@necom830.hpcl.titech.ac.jp> Message-ID: <248784.1325028520@turing-police.cc.vt.edu> On Wed, 28 Dec 2011 07:49:21 +0900, Masataka Ohta said: > Valdis.Kletnieks at vt.edu wrote: > > Especially when some of the biggest IPv6 networks out there are still using > > it pretty heavily. > That's not a valid counter argument against people who > found problems in certain environment. > > IPv6, as is, might work well under some environment assumed by > IPng/IPv6 WG, a committee. The environment may be large. > IPv6 does not work well in many environments. Feel free to try to deprecate *everything* that doesn't work well in many environments. Heck, SMTP doesn't work well in many environments (it's done in cleartext unless you deploy STARTTLS, it's subject to spamming, etc etc) - but I don't see you leading a charge to deprecate SMTP. Probably because you actually use it, even though it's totally unsuitable for many environments. It's one thing to deprecate something that's obviously a complete failure or has reached historic status - but RA isn't either of those *yet*. > In this case, the following statement in RFC1883: > > If the minimum time for rebooting the node is known (often more than > > 6 seconds), > is the wrong assumption which made RA annoying. Oddly enough, a lot of us are running on networks where assuming this about end user gear is perfectly reasonable. We haven't seen many consumer-grade Windows, Macs, or Linux boxes that are able to reboot in much under 6 seconds. Yes, I know you can do it with careful tuning and throwing SSDs and other hardware at it - doesn't mean it's common. Most of the time, any gains made in boot speed are immediately wiped out with "since it boots 10% faster, we can start 10% more stuff..." -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Tue Dec 27 17:35:42 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 27 Dec 2011 18:35:42 -0500 Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: Your message of "Wed, 28 Dec 2011 04:58:19 +0530." References: Message-ID: <248949.1325028942@turing-police.cc.vt.edu> On Wed, 28 Dec 2011 04:58:19 +0530, Glen Kent said: > I had assumed that nodes derive their link local address from the > Route Advertisements. They derive their least significant 64 bytes > from their MACs and the most significant 64 from the prefix announced > in the RAs. No, on Ethernet-ish networks the link-local is derived from an 'fe80::' and the MAC. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jmaslak at antelope.net Tue Dec 27 17:38:50 2011 From: jmaslak at antelope.net (Joel Maslak) Date: Tue, 27 Dec 2011 16:38:50 -0700 Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: References: Message-ID: <9B0FC3F2-82BE-49FA-A7AA-75229B44C370@antelope.net> On Dec 27, 2011, at 4:28 PM, Glen Kent wrote: > I had assumed that nodes derive their link local address from the > Route Advertisements. They derive their least significant 64 bytes > from their MACs and the most significant 64 from the prefix announced > in the RAs. No, link local addresses are not derived from RAs. Even a system not connected to a router will have a link local address on each ethernet (I couldn't tell you how link local works on PPP, ATM, etc, without looking it up - but it doesn't require /64 networks). From cra at WPI.EDU Tue Dec 27 19:05:34 2011 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 27 Dec 2011 20:05:34 -0500 Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: References: Message-ID: <20111228010534.GD14970@angus.ind.WPI.EDU> On Wed, Dec 28, 2011 at 04:58:19AM +0530, Glen Kent wrote: > It seems ISIS and OSPFv3 use the link local next-hop in their route > advertisements. > > We discussed that SLAAC doesnt work with prefixes > 64 on the ethernet > medium (which i believe is quite, if not most, prevalent). If thats > the case then how are operators who assign netmasks > 64 use ISIS and > OSPF, since these protocols will use the link local address? > > I had assumed that nodes derive their link local address from the > Route Advertisements. They derive their least significant 64 bytes > from their MACs and the most significant 64 from the prefix announced > in the RAs. Each prefix on an interface can have a different prefix length. Link-locals always have a prefix length of 64, even if a global address assigned to the same interface has a different length. Also, the link-local address is derived locally without any information from RAs. From mtinka at globaltransit.net Wed Dec 28 01:20:39 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Wed, 28 Dec 2011 15:20:39 +0800 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EFA3764.1040000@cis.vutbr.cz> References: <4EFA3764.1040000@cis.vutbr.cz> Message-ID: <201112281520.43806.mtinka@globaltransit.net> On Wednesday, December 28, 2011 05:23:48 AM Tomas Podermanski wrote: > In that area we also tried to use longer prefixes than > /64, but we had difficulties on some devices. There was > two kind of problems. Some of devices weren't able > properly handle longer prefixes for example in routing > protocols. The second group of devices tries to solve > processing longer prefixes via software. So we had to > gave up of using longer prefixes and now we uses 64-bit > prefixes including point to point links (and hope that > nothing will happen). But fact is that was 3 years ago, > so maybe today the situation is much better. I haven't > check for long time. Interesting. Would you be able to tell us what kit that was, if possible? Also, is this something those vendors can fix in software, or it's a hardware restriction? Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From iljitsch at muada.com Wed Dec 28 05:13:34 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 28 Dec 2011 12:13:34 +0100 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EF14814.2080709@bowenvale.co.nz> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> Message-ID: <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> Just to clear up a few misconceptions: ==== begin explanation current situation ==== Router advertisements are exactly what the name suggests, routers advertising their presence. The first function of router advertisements is to tell hosts where the routers are, so the hosts can install a default route. No RA means hosts won't send the router their packets. Of course routers that only talk to other routers don't need to send out RAs although nothing bad happens if they do so vendors may opt to send them out by default. All other functionality provided by RAs is optional. The first of those additional options the prefix option. This allows hosts to know which addresses are reachable on the local subnet so packets to those addresses don't have to go through a router but can be sent directly. Multiple prefix options may be present in an RA. Then there is the autonomous autoconfiguration (A) flag, which tells hosts that they should configure an address for themselves using the prefix in a prefix option. So only when at least one prefix option with the A flag set is present in an RA and the prefix length for that prefix is 64, stateless address autoconfiguration will be performed. Additional RA options can provide information such as a reduced MTU to be used on a subnet or a list of DNS server addresses. Unlike everything else mentioned so far, the latter is not very widely implemented. For DHCPv6, there are three variants: one that provides prefixes to routers, one that provides individual addresses (presumably) to hosts, and one that provides "additional information" such as DNS addresses. The first two require a stateful version of the DHCPv6 exchange to be performed, while the additional information can also be acquired using a lighter weight stateless exchange. Unless I'm very much mistaken, the DHCPv6 server can only perform the function the client has asked for. DHCPv6 is different from IPv4 DHCP in many ways, for instance the stateful/stateless distinction and the use of DUIDs rather than client identifiers. More importantly, DHCPv6 doesn't provide a prefix length or default gateway. This means that RAs are always necessary to provide this information (although some implementations may function without having explicitly learned the prefix length they should use). The trouble with having two mechanisms to do the same thing (stateless autoconfig and DHCPv6 address assignment) is how to decide which one to use. For this we have the M and O bits in RA. If M is set stateful DHCPv6 should be initiated for requesting an address and other information. If only the O bit is set stateless DHCPv6 should be initiated by hosts to request only other information. If both M and O are zero then no DHCPv6 should be initiated. Windows Vista and up and MacOS 10.7 support DHCPv6 address assignment. This means that as of six months ago, it became possible to assume DHCPv6 support in current versions of mainstream OSes. Before that, some of them lacked this capability so effectively, turning off stateless autoconfig and solely using DHCPv6 was impossible. ==== issues and way forward ==== Stateless autoconfig is a very nice system in un- or lightly managed environments, where it provides stable addresses to hosts without the need to have a central server keep track of those addresses using non-volatile storage. Unfortunately the DNS info isn't widely supported so at this point, at least stateless DHCPv6 is also needed to provide this information. In more tightly managed environments, stateless autoconfig has the downside that the hosts choose their addresses autonomously, so the information about which host has which address at which point in time isn't easily available to be logged. We have now reached the point were it's possible to turn off stateless autoconfig and use DHCPv6 address assignment instead to accommodate such logging. Of course none of this is bullet proof. Like with IPv4, there is some assumption that people on a shared subnet play nice. This may be an incorrect assumption. In that case, significant filtering and additional logging of L2 parameters may be necessary. Such features are not as widely available for IPv6 as for IPv4. There are some situations where it can be useful to give different hosts different information using DHCPv6, including information that is now provided using RAs, which are of course the same from the viewpoint of every host on a given subnet. In addition to that, some people just don't like RAs and want to run their network without them. These two groups want default gateway information to be added to DHCPv6 to accommodate those needs/wants. However, this has two issues. First, with RAs there are no risks that incorrect default information is propagated because the default gateway itself broadcasts its presence. With DHCP, it is possible to inject incorrect information. In my opinion, people are underestimating the problems that occur with IPv4 DHCP and the additional issues that would be introduced in IPv6 by adding this feature. Second, publishing specifications, implementing them and waiting for users to adopt them takes a very, very long time. For DHCPv6 support, the time from first publication (2003) until wide availability (2011) has been 8 years. Are we ready to live in a half-baked world for another half a decade or more just so we can add this feature, while layer 2 filtering and VLANs more easily support similar functionality? I would like to make the following suggestion: rather than having DHCPv6 impose a default gateway with all the issues that that creates, why not implement a router preference option. This way, DHCPv6 can be used to select the "correct" default gateway from the list of possible default gateways that announce their presence through RAs. This doesn't have the first issue, because dead routers can't be selected. The second issue is still there but the deployment model is much better because partial deployment provides partial benefits, On 21 Dec 2011, at 3:44 , Don Gould wrote: > I would like to see a simple presentation of the different ways of setting up a small network at the edge with the features, benefits and issues, of each method. With stateless autoconfig you have to configure very little. I don't think consumer home gateways even let you turn it off or mess with the M and O bits. So if you use that equipment, just go with the flow. Such equipment probably also has a stateless DHCPv6 server on board for DNS info. But if you run dual stack you can do DNS over IPv4 so it's not worth the time to mess with if that function isn't there for IPv6. If you have more advanced equipment you can have your router send out RAs with the M bit set and the A bit cleared and thus only use DHCPv6 for address configuration. However, that's not compatible with older hosts. Having the A bit set and thus have both types of addresses doesn't seem like a desirable configuration to me. Obviously with the M bit set you need to run a DHCPv6 server. Cisco has a good implementation but if you want control over IPv6 addressing it's probably easier to run a centralized DHCPv6 server that you can configure more easily than a bunch or routers and make the routers DHCPv6 relays. Be aware that if the DHCPv6 server is down and hosts don't have IPv6 addresses some OSes may still try to connect over IPv6 because they still have a default gateway. (I tested this way too long ago to remember which OSes.) > What I don't want is to end up with a bad name because I set up stuff 'the right way' but in such a way that the next tech the customer calls gets annoyed that what I've done is so complex that it will cost the customer $$$$$ to fix a fault. I'm not saying that DHCPv6 is immature or doesn't work, but stateless autoconfig has been in active use for 15 years so it's not going to give you any nasty surprises. Yes, you can have problems with rogue RAs, but by definition those aren't the ones YOU are sending so that problem is orthogonal to the DHCPv6/statless autoconfig decision. You can't go out and disable stateless autoconfig on all the hosts in your network. (Ok, maybe you can but then you wouldn't be asking advice on NANOG.) Iljitsch From iljitsch at muada.com Wed Dec 28 05:23:44 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 28 Dec 2011 12:23:44 +0100 Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: References: Message-ID: On 24 Dec 2011, at 6:32 , Glen Kent wrote: > I am trying to understand why standards say that "using a subnet > prefix length other than a /64 will break many features of IPv6, > including Neighbor Discovery (ND), Secure Neighbor Discovery (SEND) > [RFC3971], .. " [reference RFC 5375] For stateless autoconfig the issue is that it uses 64-bit "interface identifiers" (~ MAC addresses) that are supposed to be globally unique. You can't shave off bits and remain globally unique. With SEND a cryptographic hash that can be used to determine address ownership is stored in the interface identifier. Here shaving off addresses reduces security. Also somehow the rule that all normal address space must use 64-bit interface identifiers found its way into the specs for no reason that I have ever been able to uncover. On the other hand there's also the rule that IPv6 is classless and therefore routing on any prefix length must be supported, although for some implementations forwarding based on > /64 is somewhat less efficient. From mohta at necom830.hpcl.titech.ac.jp Wed Dec 28 05:33:23 2011 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 28 Dec 2011 20:33:23 +0900 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <248784.1325028520@turing-police.cc.vt.edu> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF4E24D.4020107@cis.vutbr.cz> <4EF4EBE0.4050609@necom830.hpcl.titech.ac.jp> <4EF58B34.6000904@rancid.berkeley.edu> <4EF59438.8040505@necom830.hpcl.titech.ac.jp> <1324724731.2763.26.camel@karl> <4EF6612F.2070901@necom830.hpcl.titech.ac.jp> <4EF66348.8040500@bogus.com> <4EF67019.1000309@necom830.hpcl.titech.ac.jp> <4EF8016D.4060208@necom830.hpcl.titech.ac.jp> <207827.1324922198@turing-police.cc.vt.edu> <4EFA4B71.20401@necom830.hpcl.titech.ac.jp> <248784.1325028520@turing-police.cc.vt.edu> Message-ID: <4EFAFE83.7060507@necom830.hpcl.titech.ac.jp> Valdis.Kletnieks at vt.edu wrote: >> IPv6 does not work well in many environments. > > Feel free to try to deprecate *everything* that doesn't work well in many > environments. Why not? > Heck, SMTP doesn't work well in many environments (it's done in > cleartext unless you deploy STARTTLS, it's subject to spamming, etc etc) Red herring. I thought all of us on some mailing list recognize SMTP working well. But, if you insist you don't, feel free not to use it, which means you leave most, if not all, mailing lists including NANOG ones. > It's one thing to deprecate something that's obviously a complete failure or > has reached historic status - but RA isn't either of those *yet*. That is not a valid counter argument against a proposal to make RA deprecated, that is, make RA reach historic status. >> In this case, the following statement in RFC1883: >>> If the minimum time for rebooting the node is known (often more than >>> 6 seconds), >> is the wrong assumption which made RA annoying. > > Oddly enough, a lot of us are running on networks where assuming this about end > user gear is perfectly reasonable. That is because, as I wrote already in the previous mail, > Network configuration was mostly stationary For example, IPv6 might work well, if most of your end users are not moving rapidly between small mobile cells. However, assuming you change the cells every 100m in average and you are moving at 100km/h, you must change the cells every 3.6 seconds in average, which means you must be able to change the cells frequently, which means each cell change take a lot less than 3.6 seconds. > We haven't seen many consumer-grade > Windows, Macs, or Linux boxes that are able to reboot in much under 6 seconds. IPv6 is wrongly architected, not because it assumes nodes are able to reboot in much under 6 seconds, but because it assumes new configurations necessary only at boot time. > Yes, I know you can do it with careful tuning and throwing SSDs and other > hardware at it - doesn't mean it's common. Obviously, the IPv6 committee and you are assuming computers of immobile main frame computers or, at least, immobile workstations. However, in the real world, commonly available mobile phones are IP capable computers which wake up from dormant state within a second and needs handover often within a second. Masataka Ohta From rps at maine.edu Wed Dec 28 06:01:37 2011 From: rps at maine.edu (Ray Soucy) Date: Wed, 28 Dec 2011 07:01:37 -0500 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EFAFE83.7060507@necom830.hpcl.titech.ac.jp> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF4E24D.4020107@cis.vutbr.cz> <4EF4EBE0.4050609@necom830.hpcl.titech.ac.jp> <4EF58B34.6000904@rancid.berkeley.edu> <4EF59438.8040505@necom830.hpcl.titech.ac.jp> <1324724731.2763.26.camel@karl> <4EF6612F.2070901@necom830.hpcl.titech.ac.jp> <4EF66348.8040500@bogus.com> <4EF67019.1000309@necom830.hpcl.titech.ac.jp> <4EF8016D.4060208@necom830.hpcl.titech.ac.jp> <207827.1324922198@turing-police.cc.vt.edu> <4EFA4B71.20401@necom830.hpcl.titech.ac.jp> <248784.1325028520@turing-police.cc.vt.edu> <4EFAFE83.7060507@necom830.hpcl.titech.ac.jp> Message-ID: Your straw man argument (which is what this has become) is just dancing around the real issue.? You're going to have to back up and make your case for us, rather than trying to respond to one-liners made (most of which were sarcastic, by the way). You have yet to identify who (beyond yourself) is calling for RA to be deprecated, though you made it sound like majority of the IETF was. You have yet to identify the problems with the design of RA that support that assertion. Taking the position that a single statement "is not a valid counter argument against a proposal to make RA deprecated" is weak at best; in actuality it wasn't a counter argument at all, but rather a statement exposing that you haven't presented an argument yet. The burden of proof lies with you, as you're the one calling for the deprecation of RA. So let's hear that, please (genuinely interested). 2011/12/28 Masataka Ohta : > Valdis.Kletnieks at vt.edu wrote: > >>> IPv6 does not work well in many environments. >> >> Feel free to try to deprecate *everything* that doesn't work well in many >> environments. > > Why not? > >> Heck, SMTP doesn't work well in many environments (it's done in >> cleartext unless you deploy STARTTLS, it's subject to spamming, etc etc) > > Red herring. > > I thought all of us on some mailing list recognize SMTP working > well. > > But, if you insist you don't, feel free not to use it, which means > you leave most, if not all, mailing lists including NANOG ones. > >> It's one thing to deprecate something that's obviously a complete failure or >> has reached historic status - but RA isn't either of those *yet*. > > That is not a valid counter argument against a proposal to > make RA deprecated, that is, make RA reach historic status. > >>> In this case, the following statement in RFC1883: >>>> ? ?If the minimum time for rebooting the node is known (often more than >>>> ? ?6 seconds), >>> is the wrong assumption which made RA annoying. >> >> Oddly enough, a lot of us are running on networks where assuming this about end >> user gear is perfectly reasonable. > > That is because, as I wrote already in the previous mail, > >> ? ? ? Network configuration was mostly stationary > > For example, IPv6 might work well, if most of your end users > are not moving rapidly between small mobile cells. > > However, assuming you change the cells every 100m in average > and you are moving at 100km/h, you must change the cells every > 3.6 seconds in average, which means you must be able to change > the cells frequently, which means each cell change take a lot > less than 3.6 seconds. > >> We haven't seen many consumer-grade >> Windows, Macs, or Linux boxes that are able to reboot in much under 6 seconds. > > IPv6 is wrongly architected, not because it assumes nodes are > able to reboot in much under 6 seconds, but because it assumes > new configurations necessary only at boot time. > >> Yes, I know you can do it with careful tuning and throwing SSDs and other >> hardware at it - doesn't mean it's common. > > Obviously, the IPv6 committee and you are assuming computers > of immobile main frame computers or, at least, immobile > workstations. > > However, in the real world, commonly available mobile phones > are IP capable computers which wake up from dormant state > within a second and needs handover often within a second. > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Masataka Ohta > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From rps at maine.edu Wed Dec 28 06:13:30 2011 From: rps at maine.edu (Ray Soucy) Date: Wed, 28 Dec 2011 07:13:30 -0500 Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: References: Message-ID: On Wed, Dec 28, 2011 at 6:23 AM, Iljitsch van Beijnum wrote: > Also somehow the rule that all normal address space must use 64-bit interface > identifiers found its way into the specs for no reason that I have ever been able > to uncover. On the other hand there's also the rule that IPv6 is classless and > therefore routing on any prefix length must be supported, although for some > implementations forwarding based on > /64 is > somewhat less efficient. This ambiguity has always bothered me. The address architecture RFC requires a 64-bit interface identifier, but it's required to be unenforced by implementation, which makes it more of a suggestion at best. I think the wording should be updated to changed MUST to SHOULD. That said, and despite my own use of prefix lengths other than 64-bit, I do believe that a 64-bit prefix for each host network is in our long-term interest. Not having to size networks based on the number of hosts is a good thing. Features made possible by a 64-bit address space is a good thing. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From mohta at necom830.hpcl.titech.ac.jp Wed Dec 28 06:21:44 2011 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 28 Dec 2011 21:21:44 +0900 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> Message-ID: <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> Iljitsch van Beijnum wrote: > Just to clear up a few misconceptions: Only to add yet another misconception without any clearing up? > Router advertisements are exactly what the name suggests, > routers advertising their presence. > The first function of router advertisements is to tell > hosts where the routers are, OK, so far. > so the hosts can install a default route. WRONG. Routers are not "a default route". If a host receives RAs only from a router, the host can do nothing other than installing the router as the default router. If not, however, the host must directly be involved in IGP activities, or, the following end to end argument is applicable: 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. Therefore, providing that questioned function as a feature of the communication system itself is not possible. Masataka Ohta PS Granted that the notion of default router of IPv4 is no better than that of IPv6. From rps at maine.edu Wed Dec 28 06:26:54 2011 From: rps at maine.edu (Ray Soucy) Date: Wed, 28 Dec 2011 07:26:54 -0500 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> Message-ID: 2011/12/28 Masataka Ohta : > Granted that the notion of default router of IPv4 is no better > than that of IPv6. Please present a reasonable alternative. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From mohta at necom830.hpcl.titech.ac.jp Wed Dec 28 06:55:57 2011 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 28 Dec 2011 21:55:57 +0900 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF4E24D.4020107@cis.vutbr.cz> <4EF4EBE0.4050609@necom830.hpcl.titech.ac.jp> <4EF58B34.6000904@rancid.berkeley.edu> <4EF59438.8040505@necom830.hpcl.titech.ac.jp> <1324724731.2763.26.camel@karl> <4EF6612F.2070901@necom830.hpcl.titech.ac.jp> <4EF66348.8040500@bogus.com> <4EF67019.1000309@necom830.hpcl.titech.ac.jp> <4EF8016D.4060208@necom830.hpcl.titech.ac.jp> <207827.1324922198@turing-police.cc.vt.edu> <4EFA4B71.20401@necom830.hpcl.titech.ac.jp> <248784.1325028520@turing-police.cc.vt.edu> <4EFAFE83.7060507@necom830.hpcl.titech.ac.jp> Message-ID: <4EFB11DD.2060608@necom830.hpcl.titech.ac.jp> Ray Soucy wrote: > Your straw man argument (which is what this has become) is just > dancing around the real issue.? You're going to have to back up and > make your case for us, rather than trying to respond to one-liners > made (most of which were sarcastic, by the way). No counter argument possible against such abstract nonsense. > You have yet to identify who (beyond yourself) is calling for RA to be > deprecated, Tomas Podermanski wrote: : from my perspective the short answer for this never-ending story is: : - SLAAC/RA is totally useless, does not bring any benefit at all : and should be removed from IPv6 specs : I personally prefer to bury SLAAC once forever for several reasons: > though you made it sound like majority of the IETF was. No, I didn't. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Wed Dec 28 06:56:19 2011 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 28 Dec 2011 21:56:19 +0900 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> Message-ID: <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> Ray Soucy wrote: >> Granted that the notion of default router of IPv4 is no better >> than that of IPv6. > > Please present a reasonable alternative. According to the end to end argument, the only possible solution to the problem, with no complete or correct alternatives, is to let hosts directly participate in IGP activities. See the paper by Saltzer et. al. Masataka Ohta From iljitsch at muada.com Wed Dec 28 06:55:40 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 28 Dec 2011 13:55:40 +0100 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> Message-ID: <0C47F961-8667-4164-8C16-E1C8B54263BB@muada.com> On 28 Dec 2011, at 13:26 , Ray Soucy wrote: >> Granted that the notion of default router of IPv4 is no better >> than that of IPv6. > Please present a reasonable alternative. Obviously reducing down the entire DFZ to a single default route is a bad case of premature optimization, which we all know is how so many engineering efforts get into trouble. The right way to handle this would be for hosts to engage in both inter and intra domain routing with local routers, and then do their own aggregation if and when desired. Iljitsch PS. :-) From mohta at necom830.hpcl.titech.ac.jp Wed Dec 28 07:05:07 2011 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 28 Dec 2011 22:05:07 +0900 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <0C47F961-8667-4164-8C16-E1C8B54263BB@muada.com> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> <0C47F961-8667-4164-8C16-E1C8B54263BB@muada.com> Message-ID: <4EFB1403.5040701@necom830.hpcl.titech.ac.jp> Iljitsch van Beijnum wrote: >>> Granted that the notion of default router of IPv4 is no better >>> than that of IPv6. > >> Please present a reasonable alternative. > > Obviously reducing down the entire DFZ to a single default route > is a bad case of premature optimization, Stop confusing "default router" and "default route". Masataka Ohta From sthaug at nethelp.no Wed Dec 28 07:10:52 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 28 Dec 2011 14:10:52 +0100 (CET) Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: References: Message-ID: <20111228.141052.104056686.sthaug@nethelp.no> > On the other hand there's also the rule that IPv6 is classless and therefore routing on any prefix length must be supported, although for some implementations forwarding based on > /64 is somewhat less efficient. Can you please name names for the "somewhat less efficient" part? I've seen this and similar claims several times, but the lack of specific information is rather astounding. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From rps at maine.edu Wed Dec 28 07:17:55 2011 From: rps at maine.edu (Ray Soucy) Date: Wed, 28 Dec 2011 08:17:55 -0500 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> Message-ID: 2011/12/28 Masataka Ohta : > According to the end to end argument, the only possible solution > to the problem, with no complete or correct alternatives, is to > let hosts directly participate in IGP activities. > > See the paper by Saltzer et. al. So your entire argument is based on an academic paper from 1981 and that host systems should participate in IGP. We tried that. It didn't scale well. The Internet today is very different than the Internet in 1981. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From rps at maine.edu Wed Dec 28 07:22:00 2011 From: rps at maine.edu (Ray Soucy) Date: Wed, 28 Dec 2011 08:22:00 -0500 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EFB11DD.2060608@necom830.hpcl.titech.ac.jp> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF4E24D.4020107@cis.vutbr.cz> <4EF4EBE0.4050609@necom830.hpcl.titech.ac.jp> <4EF58B34.6000904@rancid.berkeley.edu> <4EF59438.8040505@necom830.hpcl.titech.ac.jp> <1324724731.2763.26.camel@karl> <4EF6612F.2070901@necom830.hpcl.titech.ac.jp> <4EF66348.8040500@bogus.com> <4EF67019.1000309@necom830.hpcl.titech.ac.jp> <4EF8016D.4060208@necom830.hpcl.titech.ac.jp> <207827.1324922198@turing-police.cc.vt.edu> <4EFA4B71.20401@necom830.hpcl.titech.ac.jp> <248784.1325028520@turing-police.cc.vt.edu> <4EFAFE83.7060507@necom830.hpcl.titech.ac.jp> <4EFB11DD.2060608@necom830.hpcl.titech.ac.jp> Message-ID: On Wed, Dec 28, 2011 at 7:55 AM, Masataka Ohta wrote: > No counter argument possible against such abstract nonsense. Yes. That was my point. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From glen.kent at gmail.com Wed Dec 28 08:32:33 2011 From: glen.kent at gmail.com (Glen Kent) Date: Wed, 28 Dec 2011 20:02:33 +0530 Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: <20111228.141052.104056686.sthaug@nethelp.no> References: <20111228.141052.104056686.sthaug@nethelp.no> Message-ID: Most vendors have a TCAM that by default does IPv6 routing for netmasks <=64. They have a separate TCAM (which is usually limited in size) that does routing for masks >64 and <=128. TCAMs are expensive and increase the BOM cost of routers. Storing routes with masks > 64 takes up twice the number of TCAM entries as the routes with masks <= 64. Since IPv6 is *supposed* to work with /64 masks, most vendors (usually the not-so-expensive-routers) provide a smaller TCAM for > /64 masks. Glen On Wed, Dec 28, 2011 at 6:40 PM, wrote: >> On the other hand there's also the rule that IPv6 is classless and therefore routing on any prefix length must be supported, although for some implementations forwarding based on > /64 is somewhat less efficient. > > Can you please name names for the "somewhat less efficient" part? I've > seen this and similar claims several times, but the lack of specific > information is rather astounding. > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no > From malayter at gmail.com Wed Dec 28 08:35:11 2011 From: malayter at gmail.com (Ryan Malayter) Date: Wed, 28 Dec 2011 06:35:11 -0800 (PST) Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: <20111228.141052.104056686.sthaug@nethelp.no> References: <20111228.141052.104056686.sthaug@nethelp.no> Message-ID: <37f38f1f-369f-4056-8593-32b54e7fbc88@d8g2000yqk.googlegroups.com> On Dec 28, 7:10?am, sth... at nethelp.no wrote: > > On the other hand there's also the rule that IPv6 is classless and therefore routing on any prefix length must be supported, although for some implementations forwarding based on > /64 is somewhat less efficient. > > Can you please name names for the "somewhat less efficient" part? I've > seen this and similar claims several times, but the lack of specific > information is rather astounding. > Well, I do know if you look at the specs for most newer L3 switches, they will often say something like "max IPv4 routes 8192, max IPv6 routes 4096". This leads one to believe that the TCAMs/hash tables are only using 64 bits for IPv6 forwarding, and therefores longer prefixes must be handled in software. This may very well not be true "under the hood" at all, but the fact that vendors publish so little IPv6 specification and benchmarking information doesn't help matters. From sthaug at nethelp.no Wed Dec 28 08:41:14 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 28 Dec 2011 15:41:14 +0100 (CET) Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: References: <20111228.141052.104056686.sthaug@nethelp.no> Message-ID: <20111228.154114.112606240.sthaug@nethelp.no> > Most vendors have a TCAM that by default does IPv6 routing for netmasks <=64. > > They have a separate TCAM (which is usually limited in size) that does > routing for masks >64 and <=128. Please provide references. I haven't seen any documentation of such an architecture myself. > TCAMs are expensive and increase the BOM cost of routers. Storing > routes with masks > 64 takes up twice the number of TCAM entries as > the routes with masks <= 64. Since IPv6 is *supposed* to work with /64 > masks, most vendors (usually the not-so-expensive-routers) provide a > smaller TCAM for > /64 masks. Ah, but do the "not-so-expensive-routers" use TCAM at all? Steinar Haug, Nethelp consulting, sthaug at nethelp.no From sthaug at nethelp.no Wed Dec 28 08:50:45 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 28 Dec 2011 15:50:45 +0100 (CET) Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: <37f38f1f-369f-4056-8593-32b54e7fbc88@d8g2000yqk.googlegroups.com> References: <20111228.141052.104056686.sthaug@nethelp.no> <37f38f1f-369f-4056-8593-32b54e7fbc88@d8g2000yqk.googlegroups.com> Message-ID: <20111228.155045.85391394.sthaug@nethelp.no> > > Can you please name names for the "somewhat less efficient" part? I've > > seen this and similar claims several times, but the lack of specific > > information is rather astounding. > > Well, I do know if you look at the specs for most newer L3 switches, > they will often say something like "max IPv4 routes 8192, max IPv6 > routes 4096". This leads one to believe that the TCAMs/hash tables are > only using 64 bits for IPv6 forwarding, and therefores longer prefixes > must be handled in software. It might lead you to believe so - however, I believe this would be commercial suicide for hardware forwarding boxes because they would no longer be able to handle IPv6 at line rate for prefixes needing more than 64 bit lookups. It would also be an easy way to DoS such boxes... > This may very well not be true "under the hood" at all, but the fact > that vendors publish so little IPv6 specification and benchmarking > information doesn't help matters. Cisco actually has published quite a bit of info, e.g. http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/product_data_sheet09186a0080159856_ps4835_Products_Data_Sheet.html "Delivering scalable forwarding Performance: up to 400 Mpps IPv4 and 200 Mpps IPv6 with dCEF" They have also published EANTC tests which include IPv6 forwarding rates. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From rps at maine.edu Wed Dec 28 08:54:37 2011 From: rps at maine.edu (Ray Soucy) Date: Wed, 28 Dec 2011 09:54:37 -0500 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF4E24D.4020107@cis.vutbr.cz> <4EF4EBE0.4050609@necom830.hpcl.titech.ac.jp> <4EF58B34.6000904@rancid.berkeley.edu> <4EF59438.8040505@necom830.hpcl.titech.ac.jp> <1324724731.2763.26.camel@karl> <4EF6612F.2070901@necom830.hpcl.titech.ac.jp> <4EF66348.8040500@bogus.com> <4EF67019.1000309@necom830.hpcl.titech.ac.jp> <4EF8016D.4060208@necom830.hpcl.titech.ac.jp> <207827.1324922198@turing-police.cc.vt.edu> <4EFA4B71.20401@necom830.hpcl.titech.ac.jp> <248784.1325028520@turing-police.cc.vt.edu> <4EFAFE83.7060507@necom830.hpcl.titech.ac.jp> <4EFB11DD.2060608@necom830.hpcl.titech.ac.jp> Message-ID: I mean no disrespect. What I meant by that post was that I look forward to reading something along the lines of: ----8<---- 1. I believe RA should be moved to HISTORICAL status because of the following concerns: 2. A better way to provide routing information to host systems would be: ----8<---- This would be far more productive than arguing line-by-line against other statements without presenting what exactly it is that your arguing in favor of. Give us the big picture. After reading some of your work on end-to-end multihoming, I think I understand some of what you're trying to say. My problem is that while you seem to have a very strong academic understanding of networking, you seem to be ignoring operational realities in implementation. On Wed, Dec 28, 2011 at 8:22 AM, Ray Soucy wrote: > On Wed, Dec 28, 2011 at 7:55 AM, Masataka Ohta > wrote: >> No counter argument possible against such abstract nonsense. > > Yes. ?That was my point. > > > > > -- > Ray Soucy > > Epic Communications Specialist > > Phone: +1 (207) 561-3526 > > Networkmaine, a Unit of the University of Maine System > http://www.networkmaine.net/ -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From rps at maine.edu Wed Dec 28 09:19:54 2011 From: rps at maine.edu (Ray Soucy) Date: Wed, 28 Dec 2011 10:19:54 -0500 Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: <20111228.155045.85391394.sthaug@nethelp.no> References: <20111228.141052.104056686.sthaug@nethelp.no> <37f38f1f-369f-4056-8593-32b54e7fbc88@d8g2000yqk.googlegroups.com> <20111228.155045.85391394.sthaug@nethelp.no> Message-ID: It's fairly common knowledge that most of our systems work on 64-bit at best (and more commonly 32-bit still). If every route is nicely split at the 64-bit boundary, then it saves a step in matching the prefix. Admittedly a very inexpensive step. I expect that most hardware and software implementations store IPv6 as either a group of 4 32-bit integers or a pair of 64-bit integers, and a [ 7 or ] 8-bit prefix length field. I haven't read anything about a new 128-bit ASIC for IPv6, at least. In this context, it is perfectly reasonable, and expected, that the use of longer prefixes will have a higher cost. However, I think the number of routes, and your network architecture play a significant factor. It is a fairly standard practice to have different routes for your WAN connections (e.g. the routers you use BGP on and need to support thousands of routes) than the routers you use internally, where the routing table can be considerably smaller (and for which you can summarize). For these routers, the cost of routing is generally a non-factor as the tables are much smaller. I think a greater concern than simple routing and forwarding, would be additional services, such as queuing, or filtering. These may be implemented in hardware when a 64-bit boundary is used, but punted to CPU otherwise. Though this would be implementation specific and is something you would want to research for whatever hardware you're running. So far, the biggest performance problem I've encountered is related to neighbor discovery. It seems that in most implementations the neighbor discovery process is implemented in software. It doesn't have much to do with the boundary, but rather just that the process (e.g. solicitation for unknown entries) is expensive enough that sweeping through available address space can easily use all available CPU capacity. One [somewhat effective] solution to this is to attempt to use longer prefixes so there is much less address space where such an attack would be valid. It is much less costly for a router to discard a packet that it has no route for than it is to issue thousands of neighbor discovery solicitations per second. There are a few solutions that vendors will hopefully look into. One being to implement neighbor discovery in hardware (at which point table exhaustion also becomes a legitimate concern, so the logic should be such that known associations are not discarded in favor of unknown associations). I do think, despite these limitations, that hardware is quickly catching up to IPv6, though. I don't think it will be long before we see the major vendors have solid implementations. Some of them already may; I haven't had a chance to play with the newest stuff out there. On Wed, Dec 28, 2011 at 9:50 AM, wrote: >> > Can you please name names for the "somewhat less efficient" part? I've >> > seen this and similar claims several times, but the lack of specific >> > information is rather astounding. >> >> Well, I do know if you look at the specs for most newer L3 switches, >> they will often say something like "max IPv4 routes 8192, max IPv6 >> routes 4096". This leads one to believe that the TCAMs/hash tables are >> only using 64 bits for IPv6 forwarding, and therefores longer prefixes >> must be handled in software. > > It might lead you to believe so - however, I believe this would be > commercial suicide for hardware forwarding boxes because they would no > longer be able to handle IPv6 at line rate for prefixes needing more > than 64 bit lookups. It would also be an easy way to DoS such boxes... > >> This may very well not be true "under the hood" at all, but the fact >> that vendors publish so little IPv6 specification and benchmarking >> information doesn't help matters. > > Cisco actually has published quite a bit of info, e.g. > > http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/product_data_sheet09186a0080159856_ps4835_Products_Data_Sheet.html > > "Delivering scalable forwarding Performance: up to 400 Mpps IPv4 and > 200 Mpps IPv6 with dCEF" > > They have also published EANTC tests which include IPv6 forwarding rates. > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From trejrco at gmail.com Wed Dec 28 09:28:31 2011 From: trejrco at gmail.com (TJ) Date: Wed, 28 Dec 2011 10:28:31 -0500 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EFAFE83.7060507@necom830.hpcl.titech.ac.jp> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF4E24D.4020107@cis.vutbr.cz> <4EF4EBE0.4050609@necom830.hpcl.titech.ac.jp> <4EF58B34.6000904@rancid.berkeley.edu> <4EF59438.8040505@necom830.hpcl.titech.ac.jp> <1324724731.2763.26.camel@karl> <4EF6612F.2070901@necom830.hpcl.titech.ac.jp> <4EF66348.8040500@bogus.com> <4EF67019.1000309@necom830.hpcl.titech.ac.jp> <4EF8016D.4060208@necom830.hpcl.titech.ac.jp> <207827.1324922198@turing-police.cc.vt.edu> <4EFA4B71.20401@necom830.hpcl.titech.ac.jp> <248784.1325028520@turing-police.cc.vt.edu> <4EFAFE83.7060507@necom830.hpcl.titech.ac.jp> Message-ID: 2011/12/28 Masataka Ohta > Valdis.Kletnieks at vt.edu wrote: > > > > >> In this case, the following statement in RFC1883: > >>> If the minimum time for rebooting the node is known (often more than > >>> 6 seconds), > >> is the wrong assumption which made RA annoying. > > > > Oddly enough, a lot of us are running on networks where assuming this > about end > > user gear is perfectly reasonable. > > That is because, as I wrote already in the previous mail, > > > Network configuration was mostly stationary > > For example, IPv6 might work well, if most of your end users > are not moving rapidly between small mobile cells. > > However, assuming you change the cells every 100m in average > and you are moving at 100km/h, you must change the cells every > 3.6 seconds in average, which means you must be able to change > the cells frequently, which means each cell change take a lot > less than 3.6 seconds. > To me, that sounds like an argument in favor of SLAAC. SLAAC is noticeably faster in my experience than DHCP (v4 or v6). Also, RAs can be sent in the ms range - for environments that expect that type of attachment-point-churn ... Also: Isn't 100m an arbitrarily tight range for a cel tower? And for cellular, isn't the real churn happening more at the Layer2 side ... no L3/IPv6/IPv4 interaction? > > We haven't seen many consumer-grade > > Windows, Macs, or Linux boxes that are able to reboot in much under 6 > seconds. > > IPv6 is wrongly architected, not because it assumes nodes are > able to reboot in much under 6 seconds, but because it assumes > new configurations necessary only at boot time. > Boot time, or anytime a change in network attachment point is detected ... is that not sufficient? > Yes, I know you can do it with careful tuning and throwing SSDs and other > > hardware at it - doesn't mean it's common. > > Obviously, the IPv6 committee and you are assuming computers > of immobile main frame computers or, at least, immobile > workstations. > > However, in the real world, commonly available mobile phones > are IP capable computers which wake up from dormant state > within a second and needs handover often within a second. > Again, if we are arguing about simple speed of address attainment - SLAAC wins. > Masataka Ohta > /TJ From malayter at gmail.com Wed Dec 28 09:30:51 2011 From: malayter at gmail.com (Ryan Malayter) Date: Wed, 28 Dec 2011 07:30:51 -0800 (PST) Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: <20111228.155045.85391394.sthaug@nethelp.no> References: <20111228.141052.104056686.sthaug@nethelp.no> <37f38f1f-369f-4056-8593-32b54e7fbc88@d8g2000yqk.googlegroups.com> <20111228.155045.85391394.sthaug@nethelp.no> Message-ID: On Dec 28, 8:50?am, sth... at nethelp.no wrote: > It might lead you to believe so - however, I believe this would be > commercial suicide for hardware forwarding boxes because they would no > longer be able to handle IPv6 at line rate for prefixes needing more > than 64 bit lookups. It would also be an easy way to DoS such boxes... That's just what I'm arguing here: no vendor info I've seen positively says they *can* handle line-rate with longer IPv6 prefixes. The other information available leads one to believe that all the published specs are based on /64 prefixes. Even a third-party test reports don't mention IPv6 or prefix length at all: http://www.aristanetworks.com/media/system/pdf/LippisTestReportMay2011.pdf > Cisco actually has published quite a bit of info, e.g. > > http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod... > > "Delivering scalable forwarding Performance: up to 400 Mpps IPv4 and > 200 Mpps IPv6 with dCEF" > > They have also published EANTC tests which include IPv6 forwarding rates. Except nowhere in there is the prefix length for the test indicated, and the exact halving of forwarding rate for IPv6 leads one to believe that there are two TCAM lookups for IPv6 (hence 64-bit prefix lookups) versus one for IPv4. For example, what is the forwarding rate for IPv6 when the tables are filled with /124 IPv6 routes that differ only in the last 60 bits? Even then EANTC test results you reference make no mention of the prefix length for IPv4 or IPv6, or even the number of routes in the lookup table during the testing: http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd800c958a.pdf From rps at maine.edu Wed Dec 28 09:44:01 2011 From: rps at maine.edu (Ray Soucy) Date: Wed, 28 Dec 2011 10:44:01 -0500 Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: References: <20111228.141052.104056686.sthaug@nethelp.no> <37f38f1f-369f-4056-8593-32b54e7fbc88@d8g2000yqk.googlegroups.com> <20111228.155045.85391394.sthaug@nethelp.no> Message-ID: For what its worth I haven't stress tested it or anything, but I haven't seen any evidence on any of our RSP/SUP 720 boxes that would have caused me to think that routing and forwarding isn't being done in hardware, and we make liberal use of prefixes longer than 64 (including 126 for every link network). They might just be under capacity to the point that I haven't noticed, though. I have no problem getting muti-gigabit IPv6 throughput. On Wed, Dec 28, 2011 at 10:30 AM, Ryan Malayter wrote: > > > On Dec 28, 8:50?am, sth... at nethelp.no wrote: > >> It might lead you to believe so - however, I believe this would be >> commercial suicide for hardware forwarding boxes because they would no >> longer be able to handle IPv6 at line rate for prefixes needing more >> than 64 bit lookups. It would also be an easy way to DoS such boxes... > > That's just what I'm arguing here: no vendor info I've seen positively > says they *can* handle line-rate with longer IPv6 prefixes. The other > information available leads one to believe that all the published > specs are based on /64 prefixes. > > Even a third-party test reports don't mention IPv6 or prefix length at > all: > http://www.aristanetworks.com/media/system/pdf/LippisTestReportMay2011.pdf > >> Cisco actually has published quite a bit of info, e.g. >> >> http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod... >> >> "Delivering scalable forwarding Performance: up to 400 Mpps IPv4 and >> 200 Mpps IPv6 with dCEF" >> >> They have also published EANTC tests which include IPv6 forwarding rates. > > Except nowhere in there is the prefix length for the test indicated, > and the exact halving of forwarding rate for IPv6 leads one to believe > that there are two TCAM lookups for IPv6 (hence 64-bit prefix lookups) > versus one for IPv4. > > For example, what is the forwarding rate for IPv6 when the tables are > filled with /124 IPv6 routes that differ only in the last 60 bits? > > Even then EANTC test results you reference make no mention of the > prefix length for IPv4 or IPv6, or even the number of routes in the > lookup table during the testing: > http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd800c958a.pdf > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From sthaug at nethelp.no Wed Dec 28 09:45:44 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 28 Dec 2011 16:45:44 +0100 (CET) Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: References: <37f38f1f-369f-4056-8593-32b54e7fbc88@d8g2000yqk.googlegroups.com> <20111228.155045.85391394.sthaug@nethelp.no> Message-ID: <20111228.164544.39172608.sthaug@nethelp.no> > If every route is nicely split at the 64-bit boundary, then it saves a > step in matching the prefix. Admittedly a very inexpensive step. My point here is that IPv6 is still defined as "longest prefix match", so unless you *know* that all prefixes are <= 64 bits, you still need the longer match. > In this context, it is perfectly reasonable, and expected, that the > use of longer prefixes will have a higher cost. In a way I agree with you. However, if I put my purchasing hat on, I would refuse to buy equipment that could only forward on the first 64 bits, *or* where the forwarding decision was much slower (hardware vs software) for prefixes longer than 64 bits. I would not be surprised if vendors decide that it is a *commercial* necessity to support full 128 bit matches. > However, I think the number of routes, and your network architecture > play a significant factor. Absolutely. In our network by far the largest number of IPv6 prefixes are EBGP prefixes in the 32 to 48 bit range. However, we also have for instance our own 128 bit loopbacks - they are obviously only in our IGP. > I think a greater concern than simple routing and forwarding, would be > additional services, such as queuing, or filtering. These may be > implemented in hardware when a 64-bit boundary is used, but punted to > CPU otherwise. Though this would be implementation specific and is > something you would want to research for whatever hardware you're > running. Again, that would be an excellent reason *not* to buy such equipment. And yes, we know equipment that cannot *filter* on full IPv6 + port number headers exists (e.g. Cisco 6500/7600 with 144 bit TCAMs) - my original point was that I still haven't seen equipment with forwarding problems for prefixes > 64 bits. > There are a few solutions that vendors will hopefully look into. One > being to implement neighbor discovery in hardware (at which point > table exhaustion also becomes a legitimate concern, so the logic > should be such that known associations are not discarded in favor of > unknown associations). I'm afraid I don't believe this is going to happen unless neighbor discovery based attacks become a serious problem. And even then it would take a long time. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From bicknell at ufp.org Wed Dec 28 09:47:43 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 28 Dec 2011 07:47:43 -0800 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EFAFE83.7060507@necom830.hpcl.titech.ac.jp> References: <4EF6612F.2070901@necom830.hpcl.titech.ac.jp> <4EF66348.8040500@bogus.com> <4EF67019.1000309@necom830.hpcl.titech.ac.jp> <4EF8016D.4060208@necom830.hpcl.titech.ac.jp> <207827.1324922198@turing-police.cc.vt.edu> <4EFA4B71.20401@necom830.hpcl.titech.ac.jp> <248784.1325028520@turing-police.cc.vt.edu> <4EFAFE83.7060507@necom830.hpcl.titech.ac.jp> Message-ID: <20111228154743.GA59760@ussenterprise.ufp.org> In a message written on Wed, Dec 28, 2011 at 08:33:23PM +0900, Masataka Ohta wrote: > However, assuming you change the cells every 100m in average > and you are moving at 100km/h, you must change the cells every > 3.6 seconds in average, which means you must be able to change > the cells frequently, which means each cell change take a lot > less than 3.6 seconds. Moble networks do not today, and should not in the future expose those handoffs to the IP layer. Even WiFi networks are moving from the per-cell (AP) model you describe to a controller based infrastructure that seeks to avoid exposing L3 changes to the client. You do not want to get a new L3 address every 3.6 seconds. Worse, if in the case of VoIP you need a cell handoff to take < 25ms or so, which could never happen with new L3 addresseing and then renegotating the session to a new L3 address. Moble networks are designed to provide a L1/L2 fast switching path back to a controller infrastructure which then provides the L3 handoff. This properly decouples the layers and allows normal LAN based timing for the L3 system. The short version is, the cell to cell handoff time, or the cell dwell time is irrelevant for any L3 addressing problem. -- 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 cb.list6 at gmail.com Wed Dec 28 09:50:20 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Wed, 28 Dec 2011 07:50:20 -0800 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF4E24D.4020107@cis.vutbr.cz> <4EF4EBE0.4050609@necom830.hpcl.titech.ac.jp> <4EF58B34.6000904@rancid.berkeley.edu> <4EF59438.8040505@necom830.hpcl.titech.ac.jp> <1324724731.2763.26.camel@karl> <4EF6612F.2070901@necom830.hpcl.titech.ac.jp> <4EF66348.8040500@bogus.com> <4EF67019.1000309@necom830.hpcl.titech.ac.jp> <4EF8016D.4060208@necom830.hpcl.titech.ac.jp> <207827.1324922198@turing-police.cc.vt.edu> <4EFA4B71.20401@necom830.hpcl.titech.ac.jp> <248784.1325028520@turing-police.cc.vt.edu> <4EFAFE83.7060507@necom830.hpcl.titech.ac.jp> Message-ID: On Wed, Dec 28, 2011 at 7:28 AM, TJ wrote: > 2011/12/28 Masataka Ohta > >> Valdis.Kletnieks at vt.edu wrote: >> > > >> >> >> >> In this case, the following statement in RFC1883: >> >>> ? ?If the minimum time for rebooting the node is known (often more than >> >>> ? ?6 seconds), >> >> is the wrong assumption which made RA annoying. >> > >> > Oddly enough, a lot of us are running on networks where assuming this >> about end >> > user gear is perfectly reasonable. >> >> That is because, as I wrote already in the previous mail, >> >> > ? ? ? Network configuration was mostly stationary >> >> For example, IPv6 might work well, if most of your end users >> are not moving rapidly between small mobile cells. >> >> However, assuming you change the cells every 100m in average >> and you are moving at 100km/h, you must change the cells every >> 3.6 seconds in average, which means you must be able to change >> the cells frequently, which means each cell change take a lot >> less than 3.6 seconds. >> > > To me, that sounds like an argument in favor of SLAAC. ?SLAAC is noticeably > faster in my experience than DHCP (v4 or v6). ?Also, RAs can be sent in the > ms range - for environments that expect that type of attachment-point-churn > ... > > Also: > Isn't 100m an arbitrarily tight range for a cel tower? > And for cellular, isn't the real churn happening more at the Layer2 side > ... no L3/IPv6/IPv4 interaction? > > Correct. Cellular network mobility at the cell site level is all L1 and L2 magic. GSM / UTMS / LTE will never engage in SLAAC churn as a result of a normal mobility event. > >> > We haven't seen many consumer-grade >> > Windows, Macs, or Linux boxes that are able to reboot in much under 6 >> seconds. >> >> IPv6 is wrongly architected, not because it assumes nodes are >> able to reboot in much under 6 seconds, but because it assumes >> new configurations necessary only at boot time. >> > > Boot time, or anytime a change in network attachment point is detected ... > is that not sufficient? > > >> Yes, I know you can do it with careful tuning and throwing SSDs and other >> > hardware at it - doesn't mean it's common. >> >> Obviously, the IPv6 committee and you are assuming computers >> of immobile main frame computers or, at least, immobile >> workstations. >> >> However, in the real world, commonly available mobile phones >> are IP capable computers which wake up from dormant state >> within a second and needs handover often within a second. >> > > Again, if we are arguing about simple speed of address attainment - SLAAC > wins. > > > >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Masataka Ohta >> > > > /TJ From bicknell at ufp.org Wed Dec 28 09:57:12 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 28 Dec 2011 07:57:12 -0800 Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: References: <20111228.141052.104056686.sthaug@nethelp.no> <37f38f1f-369f-4056-8593-32b54e7fbc88@d8g2000yqk.googlegroups.com> <20111228.155045.85391394.sthaug@nethelp.no> Message-ID: <20111228155712.GB59760@ussenterprise.ufp.org> In a message written on Wed, Dec 28, 2011 at 10:19:54AM -0500, Ray Soucy wrote: > If every route is nicely split at the 64-bit boundary, then it saves a > step in matching the prefix. Admittedly a very inexpensive step. > > I expect that most hardware and software implementations store IPv6 as > either a group of 4 32-bit integers or a pair of 64-bit integers, and > a [ 7 or ] 8-bit prefix length field. I haven't read anything about a > new 128-bit ASIC for IPv6, at least. > > In this context, it is perfectly reasonable, and expected, that the > use of longer prefixes will have a higher cost. The routers are already having to do a 128-bit lookup under the hood. Consider you have a /48 routed in your IGP (to keep things simple). When you look up the /48 in a router you will see it has a next hop. A 128 bit next hop. This may be a link local, it may be a global unicast (depending on your implementation). This next hop has to be resolved, in the case of Ethernet as an example to a 48 bit MAC address. So a typical forwarding step is already a two step process: Look up variable length prefix to get next hop. Look up 128 bit next hop to get forwarding information. Once the vendor has built a 128-bit TCAM for step #2, there's no reason not to use it for step #1 as well. AFAIK, in all recent products this is how all vendors handle the problem (at a high level). Sadly, this is all a case where mind share is hobbled by a few early adopter problems. If you look at the first IPv6 images for platforms like the Cisco 7500 (in the VIP-2 days) that hardware was built to IPv4 criteria, and had 32 bit TCAM's. To make IPv6 work they did multiple TCAM lookups, some the simple 32 bits x 4, others fancy things trying to guess prefix lengths that might likley be used. All took a substantial line rate hit moving IPv6 as a result. Those problems simply don't exist in modern gear. Once products were designed to support native IPv6 rational design decisions were made. I don't know of any _current generation_ core router that has any performance difference based on prefix length. That's why prefix length isn't in the test criteria, it simply doesn't matter. I say this as a proud user of /128's, /126's, and /112's in a multi-vendor network, as well. -- 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 glen.kent at gmail.com Wed Dec 28 10:36:19 2011 From: glen.kent at gmail.com (Glen Kent) Date: Wed, 28 Dec 2011 22:06:19 +0530 Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: <20111228155712.GB59760@ussenterprise.ufp.org> References: <20111228.141052.104056686.sthaug@nethelp.no> <37f38f1f-369f-4056-8593-32b54e7fbc88@d8g2000yqk.googlegroups.com> <20111228.155045.85391394.sthaug@nethelp.no> <20111228155712.GB59760@ussenterprise.ufp.org> Message-ID: > > So a typical forwarding step is already a two step process: > > ?Look up variable length prefix to get next hop. > ?Look up 128 bit next hop to get forwarding information. Wrong. You only do a lookup once. You look up a TCAM or a hash table that gives you the next hop for a route. You DONT need to do another TCAM lookup to get the egress encapsulation information. You get the egress encapsulation after your TCAM lookup. It typically gives you an index that stores this information. All routes pointing to one nexthop will typically point to the same index. > Once the vendor has built a 128-bit TCAM for step #2, there's no > reason not to use it for step #1 as well. ?AFAIK, in all recent products > this is how all vendors handle the problem (at a high level). You only use the TCAM for #1, not for #2. Glen From malayter at gmail.com Wed Dec 28 11:51:18 2011 From: malayter at gmail.com (Ryan Malayter) Date: Wed, 28 Dec 2011 09:51:18 -0800 (PST) Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: References: <20111228.141052.104056686.sthaug@nethelp.no> <37f38f1f-369f-4056-8593-32b54e7fbc88@d8g2000yqk.googlegroups.com> <20111228.155045.85391394.sthaug@nethelp.no> Message-ID: <06fa9147-3447-4e3d-9a8f-da53b409fca2@u32g2000yqe.googlegroups.com> On Dec 28, 9:44?am, Ray Soucy wrote: > For what its worth I haven't stress tested it or anything, but I > haven't seen any evidence on any of our RSP/SUP 720 boxes that would > have caused me to think that routing and forwarding isn't being done > in hardware, and we make liberal use of prefixes longer than 64 > (including 126 for every link network). ?They might just be under > capacity to the point that I haven't noticed, though. ?I have no > problem getting muti-gigabit IPv6 throughput. > You can get >10GbE *throughput* from a Linux box doing all forwarding in software as well. That's easy when the packets are big and the routing tables are small, and the hash tables all fit in high-speed processor cache. The general lack of deep information about how the switching and routing hardware really works for IPv6 is my main problem. It's not enough to make informed buying or design decisions. Unfortunately, I have over the course of my career learned that a "trust but verify" policy is required when managing vendors. Especially vendors that have a near-monopoly market position. The problem, of course, is that verifying this sort of thing with realistic worst-case benchmarks requires some very expensive equipment and a lot of time, which is why the lack of solid information from vendors and 3rd-party testing labs is worrying. Surely some engineers from the major switch/router vendors read the NANOG list. Anybody care to chime in with "we forward all IPv6 prefix lengths in hardware for these product families"? From Valdis.Kletnieks at vt.edu Wed Dec 28 13:04:45 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 28 Dec 2011 14:04:45 -0500 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: Your message of "Wed, 28 Dec 2011 21:56:19 +0900." <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> Message-ID: <14160.1325099085@turing-police.cc.vt.edu> On Wed, 28 Dec 2011 21:56:19 +0900, Masataka Ohta said: > According to the end to end argument, the only possible solution > to the problem, with no complete or correct alternatives, is to > let hosts directly participate in IGP activities. That's only for hosts that are actively trying to communicate on more than one interface at a time, and even then quite often the *actual* right answer isn't "run an IGP", it's "insert static routes for the subnets you need to reach via the other interface"(*). Meanwhile, out in the real world, 98% of actual hosts have a *really* easy routing decision - they can make a choice of any of one routers to reach the destination. If it's a laptop that has both a wireless and a wired connection active, usually a simple "prefer wired" or "prefer wireless" is sufficient. Quick sanity check on the hypothesis: Does Windows ship with an IGP enabled by default? If not, why does the net continue to function just fine without it? Hmm.. Thought so. Maybe an IGP on end hosts isn't quite as needed on production networks as an academic paper from years ago might suggest. (*) If you think I'm going to run an IGP on some of my file servers when "default route to the world out the public 1G interface, and 5 static routes describing the private 10G network" is actually the *desired* semantic because if anybody re-engineers the 10G net enough to make me change the routes, I have *other* things to change as well, like iptables entries and /etc/exports and so on. I don't *want* an IGP changing that stuff around wiithout the liveware taking a meeting to discuss deployment of the change. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From rps at maine.edu Wed Dec 28 13:14:14 2011 From: rps at maine.edu (Ray Soucy) Date: Wed, 28 Dec 2011 14:14:14 -0500 Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: <06fa9147-3447-4e3d-9a8f-da53b409fca2@u32g2000yqe.googlegroups.com> References: <20111228.141052.104056686.sthaug@nethelp.no> <37f38f1f-369f-4056-8593-32b54e7fbc88@d8g2000yqk.googlegroups.com> <20111228.155045.85391394.sthaug@nethelp.no> <06fa9147-3447-4e3d-9a8f-da53b409fca2@u32g2000yqe.googlegroups.com> Message-ID: I did look into this a bit before. To be more specific: IPv6 CEF appears to be functioning normally for prefixes longer than 64-bit on my 720(s). I'm not seeing evidence of unexpected punting. The CPU utilization of the software process that would handle IPv6 being punted to software, "IPv6 Input", is at a steady %0.00 average (with spikes up to 0.02%). So there would seem to be at least one major platform that is OK. On Wed, Dec 28, 2011 at 12:51 PM, Ryan Malayter wrote: > > > On Dec 28, 9:44?am, Ray Soucy wrote: >> For what its worth I haven't stress tested it or anything, but I >> haven't seen any evidence on any of our RSP/SUP 720 boxes that would >> have caused me to think that routing and forwarding isn't being done >> in hardware, and we make liberal use of prefixes longer than 64 >> (including 126 for every link network). ?They might just be under >> capacity to the point that I haven't noticed, though. ?I have no >> problem getting muti-gigabit IPv6 throughput. >> > > You can get >10GbE *throughput* from a Linux box doing all forwarding > in software as well. That's easy when the packets are big and the > routing tables are small, and the hash tables all fit in high-speed > processor cache. > > The general lack of deep information about how the switching and > routing hardware really works for IPv6 is my main problem. It's not > enough to make informed buying or design decisions. Unfortunately, I > have over the course of my career learned that a "trust but verify" > policy is required when managing vendors. Especially vendors that have > a near-monopoly market position. > > The problem, of course, is that verifying this sort of thing with > realistic worst-case benchmarks requires some very expensive equipment > and a lot of time, which is why the lack of solid information from > vendors and 3rd-party testing labs is worrying. > > Surely some engineers from the major switch/router vendors read the > NANOG list. Anybody care to chime in with "we forward all IPv6 prefix > lengths in hardware for these product families"? > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From sthaug at nethelp.no Wed Dec 28 13:46:48 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 28 Dec 2011 20:46:48 +0100 (CET) Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: References: <06fa9147-3447-4e3d-9a8f-da53b409fca2@u32g2000yqe.googlegroups.com> Message-ID: <20111228.204648.74712906.sthaug@nethelp.no> > IPv6 CEF appears to be functioning normally for prefixes longer than > 64-bit on my 720(s). > > I'm not seeing evidence of unexpected punting. > > The CPU utilization of the software process that would handle IPv6 > being punted to software, "IPv6 Input", is at a steady %0.00 average > (with spikes up to 0.02%). > > So there would seem to be at least one major platform that is OK. And there are other platforms, e.g. Juniper M/MX/T, where there is no concept of "punt a packet to software to perform a forwarding decision". The packet is either forwarded in hardware, or dropped. IPv6 prefixes > 64 bit are handled like any other IPv6 prefixes, i.e. they are forwarded in hardware. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From jmaslak at antelope.net Wed Dec 28 14:00:58 2011 From: jmaslak at antelope.net (Joel Maslak) Date: Wed, 28 Dec 2011 13:00:58 -0700 Subject: Speed Test Results In-Reply-To: References: <1324631920.7845.YahooMailNeo@web39508.mail.mud.yahoo.com> Message-ID: On Fri, Dec 23, 2011 at 10:13 AM, Livingood, Jason wrote: > If you want to understand the issue in detail, check out the report from > MIT this year, written by Steve Bauer and available at > http://mitas.csail.mit.edu/papers/Bauer_Clark_Lehr_Broadband_Speed_Measurem > ents.pdf. They should have put a date on their paper, including when the measurements were done. It appears to me to have been done sometime after or around June of 2010. From jsw at inconcepts.biz Wed Dec 28 15:08:27 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Wed, 28 Dec 2011 16:08:27 -0500 Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: References: <20111228.141052.104056686.sthaug@nethelp.no> <37f38f1f-369f-4056-8593-32b54e7fbc88@d8g2000yqk.googlegroups.com> <20111228.155045.85391394.sthaug@nethelp.no> Message-ID: On Wed, Dec 28, 2011 at 10:19 AM, Ray Soucy wrote: > There are a few solutions that vendors will hopefully look into. ?One > being to implement neighbor discovery in hardware (at which point > table exhaustion also becomes a legitimate concern, so the logic > should be such that known associations are not discarded in favor of > unknown associations). Even if that is done you are still exposed to attacks -- imagine if a downstream machine that is under customer control (not yours) has a whole /64 nailed up on its Ethernet interface, and happily responds to ND solicits for every address. Your hardware table will fill up and then your network has failed -- which way it fails depends on the table eviction behavior. Perhaps this is not covered very well in my slides. There are design limits here that cannot be overcome by any current or foreseen technology. This is not only about what is broken about current routers but what will always be broken about them, in the absence of clever work-arounds like limits on the number of ND entries allowed per physical customer port, etc. We really need DHCPv6 snooping and ND disabled for campus access networks, for example. Otherwise you could give out addresses from a limited range in each subnet and use an ACL (like Owen DeLong suggests for hosting environments -- effectively turning the /64 into a /120 anyway) but this is IMO much worse than just not configuring a /64. On Wed, Dec 28, 2011 at 10:45 AM, wrote: > I'm afraid I don't believe this is going to happen unless neighbor > discovery based attacks become a serious problem. And even then it would > take a long time. The vendors seem to range from "huh?" to "what is everyone else doing?" to Cisco (the only vendor to make any forward progress at all on this issue.) I think that will change as this topic is discussed more and more on public mailing lists, and as things like DHCPv6 snooping, and good behavior when ND is disabled on a subnet/interface, begin to make their way into RFPs. As it stands right now, if you want to disable the IPv6 functionality (and maybe IPv4 too if dual-stacked) of almost any datacenter / hosting company offering v6, it is trivial to do that. The same is true of every IXP with a v6 subnet. I think once some bad guys figure this out, they will do us a favor and DoS some important things like IXPs, or a highly-visible ISP, and give the vendors a kick in the pants -- along with operators who still have the "/64 or bust" mentality, since they will then see things busting due to trivial attacks. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From mmcbride7 at gmail.com Wed Dec 28 15:48:19 2011 From: mmcbride7 at gmail.com (Mike McBride) Date: Wed, 28 Dec 2011 13:48:19 -0800 Subject: IPTV and ASM Message-ID: Anyone using ASM (versus SSM) for IPTV? If so why? thanks, mike From marshall.eubanks at gmail.com Wed Dec 28 15:50:58 2011 From: marshall.eubanks at gmail.com (Marshall Eubanks) Date: Wed, 28 Dec 2011 16:50:58 -0500 Subject: IPTV and ASM In-Reply-To: References: Message-ID: Dear Mike; On Wed, Dec 28, 2011 at 4:48 PM, Mike McBride wrote: > Anyone using ASM (versus SSM) for IPTV? If so why? > >From what I understand, the answer is likely to be "yes" and the reason is likely to be "deployed equipment only supports IGMP v2." Regards Marshall > thanks, > mike > From rps at maine.edu Wed Dec 28 16:07:40 2011 From: rps at maine.edu (Ray Soucy) Date: Wed, 28 Dec 2011 17:07:40 -0500 Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: References: <20111228.141052.104056686.sthaug@nethelp.no> <37f38f1f-369f-4056-8593-32b54e7fbc88@d8g2000yqk.googlegroups.com> <20111228.155045.85391394.sthaug@nethelp.no> Message-ID: You will always be exposed to attacks if you're connected to the Internet. (Not really sure what you were trying to say there.) My primary concerns are attacks originated from external networks. Internal network attacks are a different issue altogether (similar to ARP attacks or MAC spoofing), which require different solutions. As previously discussed in a recent thread, the attack vector you describe (in a service provider environment) can be mitigated though architecture simply by effective CPE design (isolated link network to CPE, L3 hand-off at CPE, with stateful packet inspection; and small or link-local prefixes for link networks). Thankfully, this isn't a model that is anything new; many networks are already built in this way. The only point contested is the validity of longer-than 64-bit prefixes; which I think I've spoken enough on. Enterprise and Data Center environments have a different set of [similar] concerns. Which is where the most concern on exploitation of ND and large prefixes comes into play. I think most of us have been at this for long enough to have given up on the one-configuration-fits-all school of network design. A stateful firewall internally can be a strong tool to mitigate this attack vector in such environments, depending on their size. For networks where a stateful firewall isn't practical, though, that is where stronger router implementation comes into play. The suggestion of disabling ND outright is a bit extreme. We don't need to disable ARP outright to have functional networks with a reasonable level of stability and security. The important thing is that we work with vendors to get a set of tools (not just one) to address these concerns. As you pointed out Cisco has already been doing quite a bit of work in this area, and once we start seeing the implementations become more common, other vendors will more than likely follow (at least if they want our business). Maybe I'm just a glass-half-full kind of guy. ;-) I think being able to use longer prefixes than 64-bit helps considerably. I think that seeing routers that can implement ND in hardware (or at least limit its CPU usage), and not bump known associations for unknown ones will help considerably. Stateful firewalls (where appropriate) will help considerably. And L2 security features (ND inspection with rate-limiting, RA guard, DHCPv6 snooping) will all help -- considerably. Combined, they make for an acceptable solution by current standards. As was also pointed out, though, many networks don't even implement this level of security for IP internally; the difference is that many of them haven't needed to for external attacks because of the widespread use of NAT, stateful firewalls, and much smaller address space. That is a little different in the IPv6 world, and why there is concern being expressed on this list. The most important thing is that network operators are aware of these issues, have a basic understanding of the implications, and are provided with the knowledge and tools to address them. This really isn't much different than IPv4. On Wed, Dec 28, 2011 at 4:08 PM, Jeff Wheeler wrote: > On Wed, Dec 28, 2011 at 10:19 AM, Ray Soucy wrote: >> There are a few solutions that vendors will hopefully look into. ?One >> being to implement neighbor discovery in hardware (at which point >> table exhaustion also becomes a legitimate concern, so the logic >> should be such that known associations are not discarded in favor of >> unknown associations). > > Even if that is done you are still exposed to attacks -- imagine if a > downstream machine that is under customer control (not yours) has a > whole /64 nailed up on its Ethernet interface, and happily responds to > ND solicits for every address. ?Your hardware table will fill up and > then your network has failed -- which way it fails depends on the > table eviction behavior. > > Perhaps this is not covered very well in my slides. ?There are design > limits here that cannot be overcome by any current or foreseen > technology. ?This is not only about what is broken about current > routers but what will always be broken about them, in the absence of > clever work-arounds like limits on the number of ND entries allowed > per physical customer port, etc. > > We really need DHCPv6 snooping and ND disabled for campus access > networks, for example. ?Otherwise you could give out addresses from a > limited range in each subnet and use an ACL (like Owen DeLong suggests > for hosting environments -- effectively turning the /64 into a /120 > anyway) but this is IMO much worse than just not configuring a /64. > > On Wed, Dec 28, 2011 at 10:45 AM, ? wrote: >> I'm afraid I don't believe this is going to happen unless neighbor >> discovery based attacks become a serious problem. And even then it would >> take a long time. > > The vendors seem to range from "huh?" to "what is everyone else > doing?" to Cisco (the only vendor to make any forward progress at all > on this issue.) ?I think that will change as this topic is discussed > more and more on public mailing lists, and as things like DHCPv6 > snooping, and good behavior when ND is disabled on a subnet/interface, > begin to make their way into RFPs. > > As it stands right now, if you want to disable the IPv6 functionality > (and maybe IPv4 too if dual-stacked) of almost any datacenter / > hosting company offering v6, it is trivial to do that. ?The same is > true of every IXP with a v6 subnet. ?I think once some bad guys figure > this out, they will do us a favor and DoS some important things like > IXPs, or a highly-visible ISP, and give the vendors a kick in the > pants -- along with operators who still have the "/64 or bust" > mentality, since they will then see things busting due to trivial > attacks. > > -- > Jeff S Wheeler > Sr Network Operator? /? Innovative Network Concepts > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From mmcbride7 at gmail.com Wed Dec 28 16:19:14 2011 From: mmcbride7 at gmail.com (Mike McBride) Date: Wed, 28 Dec 2011 14:19:14 -0800 Subject: IPTV and ASM In-Reply-To: References: Message-ID: Marshall, On Wed, Dec 28, 2011 at 1:50 PM, Marshall Eubanks wrote: > Dear Mike; > > On Wed, Dec 28, 2011 at 4:48 PM, Mike McBride wrote: >> Anyone using ASM (versus SSM) for IPTV? If so why? >> > > From what I understand, the answer is likely to be "yes" and the > reason is likely to be "deployed equipment only > supports IGMP v2." Agreed. I'm seeking confirmation, from IPTV implementers, that non igmpv3 support is the reason for using ASM with IPTV. Versus other reasons such as reducing state. Or is this a non issue and everyone is using SSM with IPTV? thanks, mike > Regards > Marshall > >> thanks, >> mike >> From jsw at inconcepts.biz Wed Dec 28 16:39:55 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Wed, 28 Dec 2011 17:39:55 -0500 Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: References: <20111228.141052.104056686.sthaug@nethelp.no> <37f38f1f-369f-4056-8593-32b54e7fbc88@d8g2000yqk.googlegroups.com> <20111228.155045.85391394.sthaug@nethelp.no> Message-ID: On Wed, Dec 28, 2011 at 5:07 PM, Ray Soucy wrote: > The suggestion of disabling ND outright is a bit extreme. ?We don't > need to disable ARP outright to have functional networks with a > reasonable level of stability and security. ?The important thing is I don't think it's at all extreme. If you are dealing with an access network where DHCPv6 is the only legitimate way to get an address on a given LAN segment, there is probably no reason for the router to use ND to learn about neighbor L3<>L2 associations. With DHCPv6 snooping the router can simply not use ND on that segment, which eliminates this problem. However, this feature is not yet available. It would also be difficult to convince hosting customers to use a DHCPv6 client to populate their gateway's neighbor table. However, if this feature comes along before other fixes, it will be a good option for safely deploying /64s without ND vulnerabilities. > that we work with vendors to get a set of tools (not just one) to > address these concerns. ?As you pointed out Cisco has already been > doing quite a bit of work in this area, and once we start seeing the > implementations become more common, other vendors will more than > likely follow (at least if they want our business). > > Maybe I'm just a glass-half-full kind of guy. ;-) I think your view of the Cisco work is a little optimistic. :) What they have done so far is simply acknowledge that, yes, ND exhaustion is a problem, and give the customer the option to mitigate damage to individual interfaces / VLANs, on the very few platforms that support the feature. Cisco has also given the SUP-2T independent policers for ARP and ND, so if you have a SUP-2T instead of a SUP720 / RSP720, your IPv4 won't break when you get an IPv6 ND attack. Unfortunately, there are plenty of people out there who are running IPv6 /64s on SUP720s, most who do not know that an attacker can break all their IPv4 services with an IPv6 ND attack. > The most important thing is that network operators are aware of these > issues, have a basic understanding of the implications, and are > provided with the knowledge and tools to address them. We certainly agree here. I am glad the mailing list has finally moved from listening to Owen DeLong babble about this being a non-problem, to discussing what work-arounds are possible, disadvantages of them, and what vendors can do better in the future. My personal belief is that DHCPv6 snooping, with ND disabled, will be the first widely-available method of deploying /64s "safely" to customer LAN segments. I'm not saying this is good but it is a legitimate solution. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From asusag at ifncom.net Wed Dec 28 16:59:35 2011 From: asusag at ifncom.net (Andy Susag) Date: Wed, 28 Dec 2011 17:59:35 -0500 Subject: Notifying customers of upstream modifications Message-ID: <01245B4ABF809743A84B2F16C6598FEABCFBA0@hydrogen> Hi All, Just a quick question for those of you running ISPs with BGP downstreams. If you add or remove an upstream provider to your network, do you provide notification to your downstream customers? Likely, it would cause a shift in their traffic. If they are peering with multiple ISPs themselves, they may see a traffic flux. I know for a fact that our upstreams do not notify us of events so we tend to not send out these sort of notifications. Just wonder what everyone else does or if anyone happens to know "best practice" Thanks, Andy From rps at maine.edu Wed Dec 28 17:08:32 2011 From: rps at maine.edu (Ray Soucy) Date: Wed, 28 Dec 2011 18:08:32 -0500 Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: References: <20111228.141052.104056686.sthaug@nethelp.no> <37f38f1f-369f-4056-8593-32b54e7fbc88@d8g2000yqk.googlegroups.com> <20111228.155045.85391394.sthaug@nethelp.no> Message-ID: As much as I argue with Owen on-list, I still enjoy reading his input. It's a little uncalled for to be so harsh about his posts. A lot of us are strong-willed here, and many of us read things we've posted in the past and ask "what was I thinking, that's ridiculous"; and perhaps I'm just saying that because I do so more than most. But really, let's stay civil. I don't disagree with your other comments much, but I do think (hope actually) that DHCPv6 snooping will not filter link-local traffic. That would be a job for an ND inspection kind of technology, and one I would hope was configurable. There is no DHCPv6 for link-local so it would be kind of silly to have DHCPv6 snooping restrict that traffic completely. It will be a little less straight forward than DHCP snooping is, no doubt. And I will admit I can be a Cisco fanboy at times, but only because they've consistently been able to deliver on IPv6 more that other vendors I've worked with. Like any vendor it can be hard to get through to the people who matter, but Cisco has been pretty good at responding to us when we poke them on these matters. Surprisingly, most of the time the delay is waiting on a standard to be established so they can implement that rather than their own thing. On Wed, Dec 28, 2011 at 5:39 PM, Jeff Wheeler wrote: > On Wed, Dec 28, 2011 at 5:07 PM, Ray Soucy wrote: >> The suggestion of disabling ND outright is a bit extreme. ?We don't >> need to disable ARP outright to have functional networks with a >> reasonable level of stability and security. ?The important thing is > > I don't think it's at all extreme. ?If you are dealing with an access > network where DHCPv6 is the only legitimate way to get an address on a > given LAN segment, there is probably no reason for the router to use > ND to learn about neighbor L3<>L2 associations. ?With DHCPv6 snooping > the router can simply not use ND on that segment, which eliminates > this problem. ?However, this feature is not yet available. > > It would also be difficult to convince hosting customers to use a > DHCPv6 client to populate their gateway's neighbor table. ?However, if > this feature comes along before other fixes, it will be a good option > for safely deploying /64s without ND vulnerabilities. > >> that we work with vendors to get a set of tools (not just one) to >> address these concerns. ?As you pointed out Cisco has already been >> doing quite a bit of work in this area, and once we start seeing the >> implementations become more common, other vendors will more than >> likely follow (at least if they want our business). >> >> Maybe I'm just a glass-half-full kind of guy. ;-) > > I think your view of the Cisco work is a little optimistic. :) ?What > they have done so far is simply acknowledge that, yes, ND exhaustion > is a problem, and give the customer the option to mitigate damage to > individual interfaces / VLANs, on the very few platforms that support > the feature. > > Cisco has also given the SUP-2T independent policers for ARP and ND, > so if you have a SUP-2T instead of a SUP720 / RSP720, your IPv4 won't > break when you get an IPv6 ND attack. ?Unfortunately, there are plenty > of people out there who are running IPv6 /64s on SUP720s, most who do > not know that an attacker can break all their IPv4 services with an > IPv6 ND attack. > >> The most important thing is that network operators are aware of these >> issues, have a basic understanding of the implications, and are >> provided with the knowledge and tools to address them. > > We certainly agree here. ?I am glad the mailing list has finally moved > from listening to Owen DeLong babble about this being a non-problem, > to discussing what work-arounds are possible, disadvantages of them, > and what vendors can do better in the future. > > My personal belief is that DHCPv6 snooping, with ND disabled, will be > the first widely-available method of deploying /64s "safely" to > customer LAN segments. ?I'm not saying this is good but it is a > legitimate solution. > > -- > Jeff S Wheeler > Sr Network Operator? /? Innovative Network Concepts > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From dougb at dougbarton.us Wed Dec 28 17:16:57 2011 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 28 Dec 2011 15:16:57 -0800 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> Message-ID: <4EFBA369.8090103@dougbarton.us> On 12/28/2011 03:13, Iljitsch van Beijnum wrote: > However, this has two issues. First, with RAs there are no risks that > incorrect default information is propagated because the default > gateway itself broadcasts its presence. Unless you have a malicious user on the network in which case all traffic immediately switches to the malicious user's gateway. This is in contrast to DHCP where the similar attack only affects new/renewing hosts. I'm aware that SEND is trying to solve this problem, but it's not yet deployed. > With DHCP, it is possible to > inject incorrect information. In my opinion, people are > underestimating the problems that occur with IPv4 DHCP and the > additional issues that would be introduced in IPv6 by adding this > feature. I think that people already know of and have solutions for the security issues that exist for DHCP today. > Second, publishing specifications, implementing them and waiting for > users to adopt them takes a very, very long time. For DHCPv6 support, > the time from first publication (2003) until wide availability (2011) > has been 8 years. Are we ready to live in a half-baked world for > another half a decade or more just so we can add this feature, while > layer 2 filtering and VLANs more easily support similar > functionality? 10-12 years ago I attempted to make 2 points to the IPv6 literati. First that IPv6 would not be widely adopted in the enterprise until it had full DHCP parity with v4. Second that the easiest way to do that would be to declare all existing DHCPv4 options that are relevant to IPv6 as existing in DHCPv6 by fiat, and to prevent new v6-only options from using option numbers that already exist for v4 (and vice versa). I was laughed out of the room on both counts. (If anyone wants more of the history, see https://www.ietf.org/mail-archive/web/ipv6/current/msg15129.html) The good news is that it's not too late to fix DHCPv6. We're at a watershed moment where it's just possible that we'll get the ability to assign a default gateway added to it due to, for lack of a better term, market forces. This would be a major paradigm shift. As you point out the development lead time on stuff like that is rather painful, however if we took advantage of the camel's nose under the tent and included "everything relevant that DHCPv4 can do" in that update, we'd be in a pretty good condition in a year or so. Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From imb at protected-networks.net Wed Dec 28 17:30:45 2011 From: imb at protected-networks.net (Michael Butler) Date: Wed, 28 Dec 2011 18:30:45 -0500 Subject: Notifying customers of upstream modifications In-Reply-To: <01245B4ABF809743A84B2F16C6598FEABCFBA0@hydrogen> References: <01245B4ABF809743A84B2F16C6598FEABCFBA0@hydrogen> Message-ID: <4EFBA6A5.6010302@protected-networks.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/28/11 17:59, Andy Susag wrote: > If you add or remove an upstream provider to your network, do you > provide notification to your downstream customers? Likely, it would > cause a shift in their traffic. If they are peering with multiple ISPs > themselves, they may see a traffic flux. > > I know for a fact that our upstreams do not notify us of events so we > tend to not send out these sort of notifications. Just wonder what > everyone else does or if anyone happens to know "best practice" In an ideal world, part of a good change-management process is to notify those who may see differences as a consequence of any proposed change (tell the folk that care). That way, they know something is moving and can plan accordingly. Also they can advise in a timely fashion if it either works or not and make their own changes when appropriate. Sadly, we do not live in an ideal world :-( imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk77pqUACgkQQv9rrgRC1JKChgCeOaZ4mlcZ8OzaHdeJGL8JF4B4 vooAnje3JgJLqecM1Q4SQ3F2GqP+Uhvj =hUhW -----END PGP SIGNATURE----- From jeff.tantsura at ericsson.com Wed Dec 28 17:32:38 2011 From: jeff.tantsura at ericsson.com (Jeff Tantsura) Date: Wed, 28 Dec 2011 18:32:38 -0500 Subject: IPTV and ASM In-Reply-To: References: Message-ID: Mike, To my knowledge in most today's networks even if legacy equipment don't support IGMPv3 most likely 1st hop router does static translation and SSM upstream. The reason not to migrate to SSM is usually - ASM is already there and works just fine :) Cost to support RP infrastructure is usually the main non-technical factor to not to use ASM. Would be interested to hear from the SPs on the list. Regards, Jeff On Dec 28, 2011, at 2:19 PM, "Mike McBride" wrote: > Marshall, > > On Wed, Dec 28, 2011 at 1:50 PM, Marshall Eubanks > wrote: >> Dear Mike; >> >> On Wed, Dec 28, 2011 at 4:48 PM, Mike McBride wrote: >>> Anyone using ASM (versus SSM) for IPTV? If so why? >>> >> >> From what I understand, the answer is likely to be "yes" and the >> reason is likely to be "deployed equipment only >> supports IGMP v2." > > Agreed. I'm seeking confirmation, from IPTV implementers, that non > igmpv3 support is the reason for using ASM with IPTV. Versus other > reasons such as reducing state. Or is this a non issue and everyone is > using SSM with IPTV? > > thanks, > mike > >> Regards >> Marshall >> >>> thanks, >>> mike >>> > From trejrco at gmail.com Wed Dec 28 17:43:29 2011 From: trejrco at gmail.com (TJ) Date: Wed, 28 Dec 2011 18:43:29 -0500 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EFBA369.8090103@dougbarton.us> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFBA369.8090103@dougbarton.us> Message-ID: On Wed, Dec 28, 2011 at 18:16, Doug Barton wrote: > On 12/28/2011 03:13, Iljitsch van Beijnum wrote: > > However, this has two issues. First, with RAs there are no risks that > > incorrect default information is propagated because the default > > gateway itself broadcasts its presence. > > Unless you have a malicious user on the network in which case all > traffic immediately switches to the malicious user's gateway. This is in > contrast to DHCP where the similar attack only affects new/renewing > hosts. I'm aware that SEND is trying to solve this problem, but it's not > yet deployed. > Right, the window is tighter for DHCPv4 as compared to SLAAC. That is why RA Guard is a really useful thing we should support to prevent accidental maliciousness, and perhaps enhance RA Guard to account for more skillful evasive (fragmented, etc.) malicious RAs. In the former case, a simple ARP-spoofing attack (for IPv6, ND spoofing) and you are back in ... but that is a separate paragraph :). > With DHCP, it is possible to > > inject incorrect information. In my opinion, people are > > underestimating the problems that occur with IPv4 DHCP and the > > additional issues that would be introduced in IPv6 by adding this > > feature. > > I think that people already know of and have solutions for the security > issues that exist for DHCP today. > And what is the percentage of environments that use those things? (From personal experience, 0% ... although certainly it is higher than that.) And yet, their IPv4 networks are up & running just fine ... In the big picture, this has always been fairly low on the scale. Make RA Guard a norm for "host ports" and move forward. > > Second, publishing specifications, implementing them and waiting for > > users to adopt them takes a very, very long time. For DHCPv6 support, > > the time from first publication (2003) until wide availability (2011) > > has been 8 years. Are we ready to live in a half-baked world for > > another half a decade or more just so we can add this feature, while > > layer 2 filtering and VLANs more easily support similar > > functionality? > > 10-12 years ago I attempted to make 2 points to the IPv6 literati. First > that IPv6 would not be widely adopted in the enterprise until it had > full DHCP parity with v4. Second that the easiest way to do that would > be to declare all existing DHCPv4 options that are relevant to IPv6 as > existing in DHCPv6 by fiat, and to prevent new v6-only options from > using option numbers that already exist for v4 (and vice versa). I was > laughed out of the room on both counts. (If anyone wants more of the > history, see > https://www.ietf.org/mail-archive/web/ipv6/current/msg15129.html) > > The good news is that it's not too late to fix DHCPv6. We're at a > watershed moment where it's just possible that we'll get the ability to > assign a default gateway added to it due to, for lack of a better term, > market forces. This would be a major paradigm shift. As you point out > the development lead time on stuff like that is rather painful, however > if we took advantage of the camel's nose under the tent and included > "everything relevant that DHCPv4 can do" in that update, we'd be in a > pretty good condition in a year or so. > And, FWIW, I support making DHCPv6 "more complete" as well. (Although, annoying to some, I don't mind DHCPv6 waiting for the M bit to be sent in an RA - again separate paragraph!) /TJ From brandon at rd.bbc.co.uk Wed Dec 28 17:54:04 2011 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Wed, 28 Dec 2011 23:54:04 GMT Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? Message-ID: <201112282354.XAA23921@sunf10.rd.bbc.co.uk> > Second, publishing specifications, implementing them and waiting for > users to adopt them takes a very, very long time. For DHCPv6 support, > the time from first publication (2003) until wide availability (2011) > has been 8 years. Are we ready to live in a half-baked world for > another half a decade or more just so we can add this feature enterprise: "but you want us to do v6 today, why didn't you put it in when there was time then. Let us know when it's ready, ktnxbye" > I would like to make the following suggestion: rather than having > DHCPv6 impose a default gateway with all the issues that that > creates, why not implement a router preference option. This way, > DHCPv6 can be used to select the "correct" default gateway from > the list of possible default gateways that announce their presence > through RAs sounds like the which half of the baby would you like option. I don't have a dog in this fight but understand the dhcp only option is so the dhcp guys manage * and don't have to talk to the router guys other than to tell them to fix the router when it breaks. brandon From glen.kent at gmail.com Wed Dec 28 17:58:53 2011 From: glen.kent at gmail.com (Glen Kent) Date: Thu, 29 Dec 2011 05:28:53 +0530 Subject: IPTV and ASM In-Reply-To: References: Message-ID: SSM is also used since we *know* the IP addresses of the content servers that are the sources - You dont need ASM. I dont think maintaining RP infrastructure is trivial. Who wants to deal with register packets, etc. Small routers punt all registers to CPU and them forward them in SW. In fact there was a draft which proposed using MPLS encapsulation in networks that support MPLS to replace the existing RP mechanism. http://tools.ietf.org/html/draft-bhatia-pim-mpls-register-packets-00 >From the draft: Encapsulation and Decapsulation are expensive operations for routers and the latter, especially, as it entails a double lookup that many routers cannot do in hardware. It is for this reason that several off the shelf chips do not support decapsulating the PIM Register packets. Any router that cannot decapsulate the PIM Register packet in hardware must send all this traffic to CPU, where its decapsulated, and forwarded based on the multicast forwarding table. This increases the load on the CPU and also makes the router susceptible for DoS attacks. Also, since Register packets are unicast, then can be easily spoofed and an attacker can use this to attack the router and thus the network. This document attempts to solve the above problems by doing away with the PIM Register packets. It instead proposes using an MPLS tunnel to send all multicast data traffic till an SPT is formed. This eliminates the complexity of decapsulating PIM register packets on the RP as it now only needs to pop off the MPLS labels before forwarding the native packet down the RPT. Looks like the draft died some time back .. Glen On Thu, Dec 29, 2011 at 5:02 AM, Jeff Tantsura wrote: > Mike, > > To my knowledge in most today's networks even if legacy equipment don't support IGMPv3 most likely 1st hop router does static translation and SSM upstream. > The reason not to migrate to SSM is usually - ASM is already there and works just fine :) > Cost to support RP infrastructure is usually the main non-technical factor to not to use ASM. > Would be interested to hear from the SPs on the list. > > Regards, > Jeff > > On Dec 28, 2011, at 2:19 PM, "Mike McBride" wrote: > >> Marshall, >> >> On Wed, Dec 28, 2011 at 1:50 PM, Marshall Eubanks >> wrote: >>> Dear Mike; >>> >>> On Wed, Dec 28, 2011 at 4:48 PM, Mike McBride wrote: >>>> Anyone using ASM (versus SSM) for IPTV? If so why? >>>> >>> >>> From what I understand, the answer is likely to be "yes" and the >>> reason is likely to be "deployed equipment only >>> supports IGMP v2." >> >> Agreed. I'm seeking confirmation, from IPTV implementers, that non >> igmpv3 support is the reason for using ASM with IPTV. Versus other >> reasons such as reducing state. Or is this a non issue and everyone is >> using SSM with IPTV? >> >> thanks, >> mike >> >>> Regards >>> Marshall >>> >>>> thanks, >>>> mike >>>> >> > From keegan.holley at sungard.com Wed Dec 28 18:02:04 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Thu, 29 Dec 2011 01:02:04 +0100 Subject: IPTV and ASM In-Reply-To: References: Message-ID: Isn't source discovery and efficiency a big concern for ASM? If individual streams are tied to a specific source then it's possible to live without some of the overhead involved in ASM. Joins go straight to the source, traffic is disseminated via direct paths instead of being replicated by the RP, etc etc.. Disclaimer: Other than being a lab rat I haven't done much with multicast in the wild. 2011/12/29 Jeff Tantsura > Mike, > > To my knowledge in most today's networks even if legacy equipment don't > support IGMPv3 most likely 1st hop router does static translation and SSM > upstream. > The reason not to migrate to SSM is usually - ASM is already there and > works just fine :) > Cost to support RP infrastructure is usually the main non-technical factor > to not to use ASM. > Would be interested to hear from the SPs on the list. > > Regards, > Jeff > > On Dec 28, 2011, at 2:19 PM, "Mike McBride" wrote: > > > Marshall, > > > > On Wed, Dec 28, 2011 at 1:50 PM, Marshall Eubanks > > wrote: > >> Dear Mike; > >> > >> On Wed, Dec 28, 2011 at 4:48 PM, Mike McBride > wrote: > >>> Anyone using ASM (versus SSM) for IPTV? If so why? > >>> > >> > >> From what I understand, the answer is likely to be "yes" and the > >> reason is likely to be "deployed equipment only > >> supports IGMP v2." > > > > Agreed. I'm seeking confirmation, from IPTV implementers, that non > > igmpv3 support is the reason for using ASM with IPTV. Versus other > > reasons such as reducing state. Or is this a non issue and everyone is > > using SSM with IPTV? > > > > thanks, > > mike > > > >> Regards > >> Marshall > >> > >>> thanks, > >>> mike > >>> > > > > > From mohta at necom830.hpcl.titech.ac.jp Wed Dec 28 18:11:43 2011 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 29 Dec 2011 09:11:43 +0900 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: <4EF4EBE0.4050609@necom830.hpcl.titech.ac.jp> <4EF58B34.6000904@rancid.berkeley.edu> <4EF59438.8040505@necom830.hpcl.titech.ac.jp> <1324724731.2763.26.camel@karl> <4EF6612F.2070901@necom830.hpcl.titech.ac.jp> <4EF66348.8040500@bogus.com> <4EF67019.1000309@necom830.hpcl.titech.ac.jp> <4EF8016D.4060208@necom830.hpcl.titech.ac.jp> <207827.1324922198@turing-police.cc.vt.edu> <4EFA4B71.20401@necom830.hpcl.titech.ac.jp> <248784.1325028520@turing-police.cc.vt.edu> <4EFAFE83.7060507@necom830.hpcl.titech.ac.jp> <4EFB11DD.2060608@necom830.hpcl.titech.ac.jp> Message-ID: <4EFBB03F.4090301@necom830.hpcl.titech.ac.jp> Ray Soucy wrote: > After reading some of your work on end-to-end multihoming, I think I > understand some of what you're trying to say. My problem is that > while you seem to have a very strong academic understanding of > networking, you seem to be ignoring operational realities in > implementation. To your surprise, my opinion is partially based on my experience about 10 years ago as a CTO of a commercial ISP, which offered secure public WLAN service with IP moblity. Security and mobility stacks were implemented on BSD and Windows. We successfully performed smooth handover experiment at a racing circuit with a car moving at 260km/h. http://www.root-hq.com/newsrelease/news030513.html (in Japanese) which is why I know delay caused by SLAAC is annoying. Though no commercial IPv6 service was offered, we received government funding and implemented end to end multihoming with mobility over IPv6 without ND. Public trial was offered: http://www.root-hq.com/e/newsrelease/pressrels0218.html (in English) Masataka Ohta From tom at ninjabadger.net Wed Dec 28 18:44:53 2011 From: tom at ninjabadger.net (Tom Hill) Date: Thu, 29 Dec 2011 00:44:53 +0000 Subject: Notifying customers of upstream modifications In-Reply-To: <01245B4ABF809743A84B2F16C6598FEABCFBA0@hydrogen> References: <01245B4ABF809743A84B2F16C6598FEABCFBA0@hydrogen> Message-ID: <1325119493.2769.13.camel@teh-desktop> Hi Andy, On Wed, 2011-12-28 at 17:59 -0500, Andy Susag wrote: > If you add or remove an upstream provider to your network, do you > provide notification to your downstream customers? Likely, it would > cause a shift in their traffic. If they are peering with multiple ISPs > themselves, they may see a traffic flux. We raised this question recently. The answer (from those with seniority) was that we sell "IP transit". We do not specify where it comes from or how it's made; beyond what a sales person may say to clinch a sale, the contract does not mention our upstreams, only that we agree to transit traffic to/from their ASN at an agreed rate per mbit. The point came that if anyone whom requires BGP transit also *requires* the fastest possible connectivity to a particular ASN (3356, 20940, etc.) then they can always buy transit/peer with that ASN separately. In most cases, this would also be preferable to taking blended tier-1 transit from a tier-2 (or however you describe that.) > I know for a fact that our upstreams do not notify us of events so we > tend to not send out these sort of notifications. Just wonder what > everyone else does or if anyone happens to know "best practice" *cough* Cogent. Perfect example. Automagic de-peer^H^H^H^H^H^H^Hblack-holing happens without prior warning, notification OR explanation. And it's the same answer. We buy transit, we don't specify whom they must be connected to. Morally I agree that it would be nice to tell your customers. Practically, I don't believe you can win. I mean, would you tell your downstreams every time you bring-up a new peer? That's not _always_ going to be positive for them. The answer, speaking as a downstream and a transit provider, is to just peer where you need guaranteed connectivity. If change is a problem to your customers, they don't understand how BGP works and they need to cut out the middle-man. Tom From rps at maine.edu Wed Dec 28 19:12:56 2011 From: rps at maine.edu (Ray Soucy) Date: Wed, 28 Dec 2011 20:12:56 -0500 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EFBB03F.4090301@necom830.hpcl.titech.ac.jp> References: <4EF4EBE0.4050609@necom830.hpcl.titech.ac.jp> <4EF58B34.6000904@rancid.berkeley.edu> <4EF59438.8040505@necom830.hpcl.titech.ac.jp> <1324724731.2763.26.camel@karl> <4EF6612F.2070901@necom830.hpcl.titech.ac.jp> <4EF66348.8040500@bogus.com> <4EF67019.1000309@necom830.hpcl.titech.ac.jp> <4EF8016D.4060208@necom830.hpcl.titech.ac.jp> <207827.1324922198@turing-police.cc.vt.edu> <4EFA4B71.20401@necom830.hpcl.titech.ac.jp> <248784.1325028520@turing-police.cc.vt.edu> <4EFAFE83.7060507@necom830.hpcl.titech.ac.jp> <4EFB11DD.2060608@necom830.hpcl.titech.ac.jp> <4EFBB03F.4090301@necom830.hpcl.titech.ac.jp> Message-ID: I would like to understand how you think RA is broken, and how you think that it could be improved. You have made some bold statements, but we lack the context to understand their meaning. On Wed, Dec 28, 2011 at 7:11 PM, Masataka Ohta wrote: > Ray Soucy wrote: > >> After reading some of your work on end-to-end multihoming, I think I >> understand some of what you're trying to say. ?My problem is that >> while you seem to have a very strong academic understanding of >> networking, you seem to be ignoring operational realities in >> implementation. > > > To your surprise, my opinion is partially based on my > experience about 10 years ago as a CTO of a commercial > ISP, which offered secure public WLAN service with IP > moblity. > > Security and mobility stacks were implemented on BSD and > Windows. > > We successfully performed smooth handover experiment at a > racing circuit with a car moving at 260km/h. > > ? ? ? ?http://www.root-hq.com/newsrelease/news030513.html > ? ? ? ?(in Japanese) > > which is why I know delay caused by SLAAC is annoying. > > Though no commercial IPv6 service was offered, we received > government funding and implemented end to end multihoming > with mobility over IPv6 without ND. Public trial was offered: > > ? ? ? ?http://www.root-hq.com/e/newsrelease/pressrels0218.html > ? ? ? ?(in English) > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Masataka Ohta -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From mohta at necom830.hpcl.titech.ac.jp Wed Dec 28 19:15:50 2011 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 29 Dec 2011 10:15:50 +0900 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF4E24D.4020107@cis.vutbr.cz> <4EF4EBE0.4050609@necom830.hpcl.titech.ac.jp> <4EF58B34.6000904@rancid.berkeley.edu> <4EF59438.8040505@necom830.hpcl.titech.ac.jp> <1324724731.2763.26.camel@karl> <4EF6612F.2070901@necom830.hpcl.titech.ac.jp> <4EF66348.8040500@bogus.com> <4EF67019.1000309@necom830.hpcl.titech.ac.jp> <4EF8016D.4060208@necom830.hpcl.titech.ac.jp> <207827.1324922198@turing-police.cc.vt.edu> <4EFA4B71.20401@necom830.hpcl.titech.ac.jp> <248784.1325028520@turing-police.cc.vt.edu> <4EFAFE83.7060507@necom830.hpcl.titech.ac.jp> Message-ID: <4EFBBF46.70809@necom830.hpcl.titech.ac.jp> TJ wrote: >> However, assuming you change the cells every 100m in average >> and you are moving at 100km/h, you must change the cells every >> 3.6 seconds in average, which means you must be able to change >> the cells frequently, which means each cell change take a lot >> less than 3.6 seconds. > To me, that sounds like an argument in favor of SLAAC. SLAAC is noticeably > faster in my experience than DHCP (v4 or v6). RA initiated DHCPv6 is slower than RA, of course. Note that RA initiated DHCPv6 is even required to suffer from DAD delay. > Also, RAs can be sent in the ms range Only when you are using mobile IPv6 and there still remains delay caused by DAD. > Also: > Isn't 100m an arbitrarily tight range for a cel tower? Cell size must shrink as bandwidth requirements of mobile devices increase. > And for cellular, isn't the real churn happening more at the Layer2 side > ... no L3/IPv6/IPv4 interaction? Because of large amount of traffic caused by smart phones, mobile providers, at least those in Japan, are trying to bypass traffic from 3G to WLAN/Internet with IPv4 L3. > Boot time, or anytime a change in network attachment point is detected ... > is that not sufficient? It is wrong to assume intervals between changes 6 seconds. In general, ND is wrong to specify link specific timings assuming infrequent changes. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Wed Dec 28 19:40:51 2011 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 29 Dec 2011 10:40:51 +0900 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <20111228154743.GA59760@ussenterprise.ufp.org> References: <4EF6612F.2070901@necom830.hpcl.titech.ac.jp> <4EF66348.8040500@bogus.com> <4EF67019.1000309@necom830.hpcl.titech.ac.jp> <4EF8016D.4060208@necom830.hpcl.titech.ac.jp> <207827.1324922198@turing-police.cc.vt.edu> <4EFA4B71.20401@necom830.hpcl.titech.ac.jp> <248784.1325028520@turing-police.cc.vt.edu> <4EFAFE83.7060507@necom830.hpcl.titech.ac.jp> <20111228154743.GA59760@ussenterprise.ufp.org> Message-ID: <4EFBC523.4060101@necom830.hpcl.titech.ac.jp> Leo Bicknell wrote: > Moble networks do not today, and should not in the future expose > those handoffs to the IP layer. Even WiFi networks are moving from > the per-cell (AP) model you describe to a controller based > infrastructure that seeks to avoid exposing L3 changes to the client. The reality in Japan today is that each AP used by smart phones to bypass traffic from 3G to the Internet is independently provided by small shops or individuals' households through their own Internet connectivity, there can be no central controller. > You do not want to get a new L3 address every 3.6 seconds. Worse, > if in the case of VoIP you need a cell handoff to take< 25ms or > so, which could never happen with new L3 addresseing and then > renegotating the session to a new L3 address. As voice traffic is negligible, I think it is carried over 3G only. But, if you seriously need smooth handover, you must have 2 independent WLAN receivers to simultaneously connect to two APs operating at different channels for make-before-break style handover. Or, another possibility is to use only a single channel of WLAN by all the related APs (Packet Division Multiple Access (PDMA)). I have confirmed both approaches work combined with IP mobility with applications of voice and video over IP. > Moble networks are designed to provide a L1/L2 fast switching path > back to a controller infrastructure which then provides the L3 > handoff. This properly decouples the layers and allows normal LAN > based timing for the L3 system. What's happening today is migration from 3G/4G to WLAN. Masataka Ohta From trejrco at gmail.com Wed Dec 28 19:45:29 2011 From: trejrco at gmail.com (TJ) Date: Wed, 28 Dec 2011 20:45:29 -0500 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EFBBF46.70809@necom830.hpcl.titech.ac.jp> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF23092.9090103@cis.vutbr.cz> <4EF4E24D.4020107@cis.vutbr.cz> <4EF4EBE0.4050609@necom830.hpcl.titech.ac.jp> <4EF58B34.6000904@rancid.berkeley.edu> <4EF59438.8040505@necom830.hpcl.titech.ac.jp> <1324724731.2763.26.camel@karl> <4EF6612F.2070901@necom830.hpcl.titech.ac.jp> <4EF66348.8040500@bogus.com> <4EF67019.1000309@necom830.hpcl.titech.ac.jp> <4EF8016D.4060208@necom830.hpcl.titech.ac.jp> <207827.1324922198@turing-police.cc.vt.edu> <4EFA4B71.20401@necom830.hpcl.titech.ac.jp> <248784.1325028520@turing-police.cc.vt.edu> <4EFAFE83.7060507@necom830.hpcl.titech.ac.jp> <4EFBBF46.70809@necom830.hpcl.titech.ac.jp> Message-ID: 2011/12/28 Masataka Ohta > TJ wrote: > > >> However, assuming you change the cells every 100m in average > >> and you are moving at 100km/h, you must change the cells every > >> 3.6 seconds in average, which means you must be able to change > >> the cells frequently, which means each cell change take a lot > >> less than 3.6 seconds. > > > To me, that sounds like an argument in favor of SLAAC. SLAAC is > noticeably > > faster in my experience than DHCP (v4 or v6). > > RA initiated DHCPv6 is slower than RA, of course. > I am not counting the "delay" caused by waiting for the RA against DHCPv6. Isn't the stateless operation of a router providing a prefix in a RA always going to be faster than statefully providing an address via DHCPv6 (even with rapid commit enabling 2 messages to suffice; and noting that normally DHCPv6 involves 4 messages and relaying)? Note that RA initiated DHCPv6 is even required to suffer from DAD delay. > > > Also, RAs can be sent in the ms range > > Only when you are using mobile IPv6 and there still remains delay caused > by DAD. > I would say that it is only possible on platforms that support it. You are not required to enable mobile anything in order to set the advertisement interval to be that tight. And regardless of the specified interval setting, a node sending a RS and getting back a RA is still faster than the 4-way (default) message (which may require relaying) exchange required for DHCP ... In either case, yes, DAD "must" happen ... although Optimistic DAD can help there, or perhaps other link specific solutions. > > Also: > > Isn't 100m an arbitrarily tight range for a cel tower? > > Cell size must shrink as bandwidth requirements of mobile > devices increase. > Understandable, but down to the 100m range? *(Partially tongue in cheek pre-response to your next statement: And why should they bother, if the users can just hop onto WiFi? :) )* > And for cellular, isn't the real churn happening more at the Layer2 side > > ... no L3/IPv6/IPv4 interaction? > > Because of large amount of traffic caused by smart phones, > mobile providers, at least those in Japan, are trying to > bypass traffic from 3G to WLAN/Internet with IPv4 L3. > I applaud the apparent easy access to (open?) WiFi ... and the user expecting that to work seemlessly, "at speed". > Boot time, or anytime a change in network attachment point is detected ... > > is that not sufficient? > > It is wrong to assume intervals between changes 6 seconds. > Again, IMHO, that has been addressed where relevant (IIRC, Cisco supports down to advertising every 20ms; and solicited RAs happen 'as needed'). For the enterprise side, even 6s is way too often and I believe most agree that this aspect isn't a problem. In general, ND is wrong to specify link specific timings > assuming infrequent changes. In principle I agree, but assumptions must be made somewhere or nothing can get done. If there is a change required to make it work, do so - the "IPv6 over Foo" RFCs are a good place to specify preferred values for $Foo. /TJ From mohta at necom830.hpcl.titech.ac.jp Wed Dec 28 20:51:00 2011 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 29 Dec 2011 11:51:00 +0900 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <14160.1325099085@turing-police.cc.vt.edu> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> <14160.1325099085@turing-police.cc.vt.edu> Message-ID: <4EFBD594.2000604@necom830.hpcl.titech.ac.jp> Valdis.Kletnieks at vt.edu wrote: >> According to the end to end argument, the only possible solution >> to the problem, with no complete or correct alternatives, is to >> let hosts directly participate in IGP activities. > > That's only for hosts that are actively trying to communicate on more than one > interface at a time, Note that the end to end argument has the following statement I omitted to quote: (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.) That is, there are incomplete solutions by intermediate systems which sometimes work. > and even then quite often the *actual* right answer isn't > "run an IGP", it's "insert static routes for the subnets you need to reach via > the other interface"(*). With manual configuration, you can do anything. But, aren't we talking about autoconfiguration? > If it's a laptop that has both a wireless and a wired connection > active, usually a simple "prefer wired" or "prefer wireless" is > sufficient. Usually? Can you see the word "complete" in the end to end argument? > Quick sanity check on the hypothesis: Does Windows ship with an IGP enabled by > default? Sanity check with Windows? Are you sure? > If not, why does the net continue to function just fine without it? It is often incomplete and incorrect unnecessarily requiring manual reconfigurations. > (*) If you think I'm going to run an IGP on some of my file servers when > "default route to the world out the public 1G interface, and 5 static routes > describing the private 10G network" is actually the *desired* semantic because > if anybody re-engineers the 10G net enough to make me change the routes, I have > *other* things to change as well, like iptables entries and /etc/exports and so > on. I don't *want* an IGP changing that stuff around wiithout the liveware > taking a meeting to discuss deployment of the change. If you are saying SLAAC is not enough in your case with complicated manual management, I don't think I have to argue against you on how to simplify it. Masataka Ohta From keegan.holley at sungard.com Wed Dec 28 20:51:12 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Thu, 29 Dec 2011 03:51:12 +0100 Subject: Notifying customers of upstream modifications In-Reply-To: <01245B4ABF809743A84B2F16C6598FEABCFBA0@hydrogen> References: <01245B4ABF809743A84B2F16C6598FEABCFBA0@hydrogen> Message-ID: Most transit networks have some sort of blanket notification that they can send to customers. Something like between 12AM and 6AM sometime next week you may or may not have a moderate or severe impact, but we're not going to give you details. It also depends on the peering that is being added or removed. The larger providers are mostly static. I can't imagine Level 3 permanently depeering from Verizon for example. Also, if paths change but latency and hop count are still acceptable most customers will not notice the change. The same goes for outages. Also, where do you draw the line. For example if someone severs a peering with a content network like google some of their downstreams will care others will not. If ISP's notified everyone of every change it would more or less become spam so I can see an argument for both. In large transit networks it probably comes down to the predicted impact of the a particular change versus visibility and contractual liabilities. 2011/12/28 Andy Susag > Hi All, > > > > Just a quick question for those of you running ISPs with BGP > downstreams. > > > > If you add or remove an upstream provider to your network, do you > provide notification to your downstream customers? Likely, it would > cause a shift in their traffic. If they are peering with multiple ISPs > themselves, they may see a traffic flux. > > > > I know for a fact that our upstreams do not notify us of events so we > tend to not send out these sort of notifications. Just wonder what > everyone else does or if anyone happens to know "best practice" > > > > Thanks, > > Andy > > > > > From morrowc.lists at gmail.com Wed Dec 28 21:33:32 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 28 Dec 2011 22:33:32 -0500 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EFBA369.8090103@dougbarton.us> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFBA369.8090103@dougbarton.us> Message-ID: On Wed, Dec 28, 2011 at 6:16 PM, Doug Barton wrote: > On 12/28/2011 03:13, Iljitsch van Beijnum wrote: >> Second, publishing specifications, implementing them and waiting for >> users to adopt them takes a very, very long time. For DHCPv6 support, >> the time from first publication (2003) until wide availability (2011) >> has been 8 years. Are we ready to live in a half-baked world for >> another half a decade or more just so we can add this feature, while >> layer 2 filtering and VLANs more easily support similar >> functionality? > > 10-12 years ago I attempted to make 2 points to the IPv6 literati. First > that IPv6 would not be widely adopted in the enterprise until it had > full DHCP parity with v4. Second that the easiest way to do that would +1000 > be to declare all existing DHCPv4 options that are relevant to IPv6 as > existing in DHCPv6 by fiat, and to prevent new v6-only options from > using option numbers that already exist for v4 (and vice versa). I was > laughed out of the room on both counts. (If anyone wants more of the similarly folks keep laughing (or at least harumphing loudly) when enterprise folk say: "Hey, I use dhcp today for a large number of things, I can't NOT use it going forward, support the features in v4 dhcp that I use in your new v6 thingy." anyway, it seems to be getting slightly better, bolting more crud on ND so you can continue to say: "Yea, but you SHOULD use ...." is wasted breath. -chris From mohta at necom830.hpcl.titech.ac.jp Wed Dec 28 22:50:52 2011 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 29 Dec 2011 13:50:52 +0900 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: <4EF4E24D.4020107@cis.vutbr.cz> <4EF4EBE0.4050609@necom830.hpcl.titech.ac.jp> <4EF58B34.6000904@rancid.berkeley.edu> <4EF59438.8040505@necom830.hpcl.titech.ac.jp> <1324724731.2763.26.camel@karl> <4EF6612F.2070901@necom830.hpcl.titech.ac.jp> <4EF66348.8040500@bogus.com> <4EF67019.1000309@necom830.hpcl.titech.ac.jp> <4EF8016D.4060208@necom830.hpcl.titech.ac.jp> <207827.1324922198@turing-police.cc.vt.edu> <4EFA4B71.20401@necom830.hpcl.titech.ac.jp> <248784.1325028520@turing-police.cc.vt.edu> <4EFAFE83.7060507@necom830.hpcl.titech.ac.jp> <4EFBBF46.70809@necom830.hpcl.titech.ac.jp> Message-ID: <4EFBF1AC.1020204@necom830.hpcl.titech.ac.jp> TJ wrote: >> RA initiated DHCPv6 is slower than RA, of course. > I am not counting the "delay" caused by waiting for the RA against DHCPv6. Do you count random delay between RA and DHCPv6 solicit? Do you count DAD delay after DHCPv6? > Isn't the stateless operation of a router providing a prefix in a RA always > going to be faster than statefully providing an address via DHCPv6 (even > with rapid commit enabling 2 messages to suffice; and noting that normally > DHCPv6 involves 4 messages and relaying)? As the stateless operation is actually stateful to keep address assignment states by all the related nodes, DAD is required to confirm the state is consistent, which means delay. With DHCP only, there is no DAD necessary. >> Only when you are using mobile IPv6 and there still remains delay caused >> by DAD. > I would say that it is only possible on platforms that support it. You are > not required to enable mobile anything in order to set > the advertisement interval to be that tight. Can I? I'm refering to RFC3775: One method which can provide for faster movement detection, is to increase the rate at which unsolicited Router Advertisements are sent. Mobile IPv6 relaxes this limit such that routers MAY send unsolicited multicast Router Advertisements more frequently. which is applicable only to MIPv6 routers. > In either case, yes, DAD "must" happen ... > although Optimistic DAD can help there, The straight forward solution is to remove DAD along with stateful SLAAC. > or perhaps other link specific solutions. A link specific solution is DHCPv6 without RA. >> Cell size must shrink as bandwidth requirements of mobile >> devices increase. > Understandable, but down to the 100m range? It is also a typical range for WLAN. > *(Partially tongue in cheek pre-response to your next statement: And why > should they bother, if the users can just hop onto WiFi? :) )* Moving users should be able to keep hopping onto WLANs. >> In general, ND is wrong to specify link specific timings >> assuming infrequent changes. > In principle I agree, but assumptions must be made somewhere or nothing can > get done. If there is a change required to make it work, do so - the "IPv6 > over Foo" RFCs are a good place to specify preferred values for $Foo. The fundamental problem of ND is that it tries to be the only way to have IPv6 over all the possible link layers. Instead of having "IPv6 uber Alles", the wrong goal of "ND uber Alles" was targeted. So, if we give up the goal to have "IPv6 over Foo", there is no reason to insist on "ND uber Alles". Masataka Ohta From tony at lavanauts.org Wed Dec 28 22:55:31 2011 From: tony at lavanauts.org (Antonio Querubin) Date: Wed, 28 Dec 2011 18:55:31 -1000 (HST) Subject: IPTV and ASM In-Reply-To: References: Message-ID: On Wed, 28 Dec 2011, Marshall Eubanks wrote: > From what I understand, the answer is likely to be "yes" and the > reason is likely to be "deployed equipment only > supports IGMP v2." That and numerous clients which don't know anything about SSM. Antonio Querubin e-mail: tony at lavanauts.org xmpp: antonioquerubin at gmail.com From Valdis.Kletnieks at vt.edu Thu Dec 29 00:17:17 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 29 Dec 2011 01:17:17 -0500 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: Your message of "Thu, 29 Dec 2011 11:51:00 +0900." <4EFBD594.2000604@necom830.hpcl.titech.ac.jp> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> <14160.1325099085@turing-police.cc.vt.edu> <4EFBD594.2000604@necom830.hpcl.titech.ac.jp> Message-ID: <30391.1325139437@turing-police.cc.vt.edu> On Thu, 29 Dec 2011 11:51:00 +0900, Masataka Ohta said: > Valdis.Kletnieks at vt.edu wrote: > > Quick sanity check on the hypothesis: Does Windows ship with an IGP enabled by > > default? > Sanity check with Windows? Are you sure? It's a quick sanity check to this statment: >> According to the end to end argument, the only possible solution >> to the problem, with no complete or correct alternatives, is to >> let hosts directly participate in IGP activities. If it's the "only possible spolution", how come 99.8% of the end nodes do just fine without it? Oh yeah.. > Note that the end to end argument has the following > statement I omitted to quote: > (Sometimes an incomplete version of the function provided > by the communication system may be useful as a performance > enhancement.) > That is, there are incomplete solutions by intermediate systems > which sometimes work. For "sometimes" == 99.8% of the net. > If you are saying SLAAC is not enough in your case with > complicated manual management, I don't think I have to > argue against you on how to simplify it. It got simplfied with a handful of static routes and no IGP and no SLAAC and no DHCP of any flavor. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From mohta at necom830.hpcl.titech.ac.jp Thu Dec 29 01:08:36 2011 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 29 Dec 2011 16:08:36 +0900 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <30391.1325139437@turing-police.cc.vt.edu> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> <14160.1325099085@turing-police.cc.vt.edu> <4EFBD594.2000604@necom830.hpcl.titech.ac.jp> <30391.1325139437@turing-police.cc.vt.edu> Message-ID: <4EFC11F4.2090409@necom830.hpcl.titech.ac.jp> Valdis.Kletnieks at vt.edu wrote: >>> Quick sanity check on the hypothesis: Does Windows ship with an IGP enabled by >>> default? > >> Sanity check with Windows? Are you sure? > > It's a quick sanity check to this statment: > >>> According to the end to end argument, the only possible solution >>> to the problem, with no complete or correct alternatives, is to >>> let hosts directly participate in IGP activities. > > If it's the "only possible spolution", how come 99.8% of the end nodes > do just fine without it? Oh yeah.. Because that's the Microsoft quality. PERIOD. Masataka Ohta From mtinka at globaltransit.net Thu Dec 29 02:56:46 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Thu, 29 Dec 2011 16:56:46 +0800 Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: <20111228.204648.74712906.sthaug@nethelp.no> References: <20111228.204648.74712906.sthaug@nethelp.no> Message-ID: <201112291656.47253.mtinka@globaltransit.net> On Thursday, December 29, 2011 03:46:48 AM sthaug at nethelp.no wrote: > And there are other platforms, e.g. Juniper M/MX/T, where > there is no concept of "punt a packet to software to > perform a forwarding decision". The packet is either > forwarded in hardware, or dropped. IPv6 prefixes > 64 > bit are handled like any other IPv6 prefixes, i.e. they > are forwarded in hardware. IOS XR-based systems operate the same way. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From tvhawaii at shaka.com Thu Dec 29 03:07:14 2011 From: tvhawaii at shaka.com (Michael Painter) Date: Wed, 28 Dec 2011 23:07:14 -1000 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> <14160.1325099085@turing-police.cc.vt.edu> <4EFBD594.2000604@necom830.hpcl.titech.ac.jp> <30391.1325139437@turing-police.cc.vt.edu> <4EFC11F4.2090409@necom830.hpcl.titech.ac.jp> Message-ID: Masataka Ohta wrote: > Because that's the Microsoft quality. PERIOD. "We knew it was a crooked game, but it was the only game in town." From saku at ytti.fi Thu Dec 29 03:10:15 2011 From: saku at ytti.fi (Saku Ytti) Date: Thu, 29 Dec 2011 11:10:15 +0200 Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: <201112291656.47253.mtinka@globaltransit.net> References: <20111228.204648.74712906.sthaug@nethelp.no> <201112291656.47253.mtinka@globaltransit.net> Message-ID: <20111229091015.GA19931@pob.ytti.fi> On (2011-12-29 16:56 +0800), Mark Tinka wrote: > On Thursday, December 29, 2011 03:46:48 AM sthaug at nethelp.no > wrote: > > > And there are other platforms, e.g. Juniper M/MX/T, where > > there is no concept of "punt a packet to software to > > forwarded in hardware, or dropped. IPv6 prefixes > 64 > > IOS XR-based systems operate the same way. Of course this isn't strictly true, transit might be punted in either platform for various reasons, IP(v6) options comes to mind, possibly too many IPv6 extension headers (Cisco.com claims to punt in such instance, JNPR/trio (imho incorrectly) just drops packet in hardware), glean/arp resolve, multicast learning, probably many other reasons I can't think off. -- ++ytti From mtinka at globaltransit.net Thu Dec 29 03:13:19 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Thu, 29 Dec 2011 17:13:19 +0800 Subject: IPTV and ASM In-Reply-To: References: Message-ID: <201112291713.22486.mtinka@globaltransit.net> On Thursday, December 29, 2011 05:50:58 AM Marshall Eubanks wrote: > >From what I understand, the answer is likely to be "yes" > >and the > > reason is likely to be "deployed equipment only > supports IGMP v2." This is true for us - the broadcaster whose IPTv traffic we carry supports only IGMPv2. This makes SSM a no-no, but we aren't really complaining about having to use PIM-SM either. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From fweimer at bfk.de Thu Dec 29 03:14:20 2011 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 29 Dec 2011 09:14:20 +0000 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <30391.1325139437@turing-police.cc.vt.edu> (Valdis Kletnieks's message of "Thu, 29 Dec 2011 01:17:17 -0500") References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> <14160.1325099085@turing-police.cc.vt.edu> <4EFBD594.2000604@necom830.hpcl.titech.ac.jp> <30391.1325139437@turing-police.cc.vt.edu> Message-ID: <82ipkzwxhv.fsf@mid.bfk.de> * Valdis Kletnieks: >>> According to the end to end argument, the only possible solution >>> to the problem, with no complete or correct alternatives, is to >>> let hosts directly participate in IGP activities. > > If it's the "only possible spolution", how come 99.8% of the end nodes > do just fine without it? Oh yeah.. Because there's a CPE which acts as a mediator, or the host uses some dial-up-type protocol which takes care of the IGP interaction. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From mtinka at globaltransit.net Thu Dec 29 03:15:16 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Thu, 29 Dec 2011 17:15:16 +0800 Subject: IPTV and ASM In-Reply-To: References: Message-ID: <201112291715.17149.mtinka@globaltransit.net> On Thursday, December 29, 2011 06:19:14 AM Mike McBride wrote: > Agreed. I'm seeking confirmation, from IPTV implementers, > that non igmpv3 support is the reason for using ASM with > IPTV. Versus other reasons such as reducing state. Or is > this a non issue and everyone is using SSM with IPTV? We are running NG-MVPN (BGP replaces PIM, MPLS replaces IP/GRE). We run PIM-SM, not only because our customer's STB's only support IGMPv2 (we only transport IPTv content, not generate it), but also because, well, it just works and there hasn't been any compelling need to push for PIM-SSM. It's scaling well due to the nature of the NG-MVPN infrastructure itself. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mtinka at globaltransit.net Thu Dec 29 03:42:02 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Thu, 29 Dec 2011 17:42:02 +0800 Subject: IPTV and ASM In-Reply-To: References: Message-ID: <201112291742.05697.mtinka@globaltransit.net> On Thursday, December 29, 2011 07:32:38 AM Jeff Tantsura wrote: > To my knowledge in most today's networks even if legacy > equipment don't support IGMPv3 most likely 1st hop > router does static translation and SSM upstream. Yes, SSM Mapping allows for PIM-SSM to be used in a network where the receivers don't support IGMPv3. But it tends to be static in nature, although both Juniper and Cisco suggest that dynamically-configured options are possible. I couldn't quite decode the Juniper dynamic method, but the Cisco one appears to be based on DNS. That should be interesting (and a colossal screw-up if things are poorly maintained): http://www.cisco.com/en/US/docs/ios/12_3t/12_3t2/feature/guide/gtssmma.html#wp1119180 > The > reason not to migrate to SSM is usually - ASM is already > there and works just fine :) This is our case. > Cost to support RP > infrastructure is usually the main non-technical factor > to not to use ASM. Would be interested to hear from the > SPs on the list. For us, the cost of the RP isn't an issue. The Sender PE routers (in NG-MVPN speak, the ISP's routers that are connected toward the Source) are also the RP's. But due to the use of NG-MVPN, and how we designed our Multicast backbone, there really isn't any need for the Receiver PE routers to contact the RP whenever a customer is joining a group. BGP has been extended to handle PIM messages in NG-MVPN. When a Source is discovered by the Sender PE router, it generates a Type 5 SA-AD (Source Active, Auto-discovery) BGP update route which is sent to all Receiver PE routers participating in the MVPN. This Type 5 route is generated from the PIM Register state that is created by PIM running between the Sender PE and CE routers. If the Receiver PE router is configured to operate the MVPN in the SPT-only mode, it generates a Type 7 (C-S,C-G) route for every Type 5 route it received, effectively creating the necessary state in the local Receiver PE router. Once customers send (*,G) IGMP reports requesting to join Multicast groups, that state is already present on the Receiver PE router, and traffic starts flowing immediately downstream. If the Receiver PE router is configured to operate the MVPN in RPT-SPT mode, it will follow regular PIM mecahnisms when users are trying to join groups, i.e., Join messages are forwarded toward the RP along the RPT, and then Multicast traffic forwarded along the SPT once the correct (C-S,C-G) state is created locally. The above explanation is somewhat simplified, but represents the general architecture of how things work in NG-MVPN's. For us, SPT-only mode makes sense because we have IPTv probes attached to all Receiver PE routers; and since they're collecting telemetry for all IPTv channels, no point running the RPT-SPT mode. Please note that this whole setup doesn't require MSDP, which is nice! Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mtinka at globaltransit.net Thu Dec 29 04:00:21 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Thu, 29 Dec 2011 18:00:21 +0800 Subject: IPTV and ASM In-Reply-To: References: Message-ID: <201112291800.25765.mtinka@globaltransit.net> On Thursday, December 29, 2011 07:58:53 AM Glen Kent wrote: > SSM is also used since we *know* the IP addresses of the > content servers that are the sources - You dont need > ASM. I dont think maintaining RP infrastructure is > trivial. Who wants to deal with register packets, etc. > Small routers punt all registers to CPU and them forward > them in SW. Our Sender PE routers double as our RP's. These are Juniper M320's and T320's today. Yes, a Tunnel PIC is required on the Juniper's (although you might find it interesting that if you're running PIM-SM for IPv6 on Sender PE routers, you don't need a Tunnel PIC; however, if you have an IPv6-based RP, you need a Tunnel PIC). Juniper MX routers don't require a Tunnel PIC, as those are integrated into their DPC and MPC line cards. Our customer is using Cisco ASR1000 routers as Sender CE routers, and PIM Registers are encapsulated/decapsulated in hardware on those platforms. But I do agree that it does add overhead. > In fact there was a draft which proposed using MPLS > encapsulation in networks that support MPLS to replace > the existing RP mechanism. > > http://tools.ietf.org/html/draft-bhatia-pim-mpls-register > -packets-00 This quite interesting, I hadn't heard of this one before, although I'd always wondered why something like this wasn't already implemented. My main issue with this proposal is that if the Sender CE router is not part of your network, i.e., your customer, a partner network, e.t.c., it requires that your MPLS domain be extended toward them. It's not impossible, but not typically common. Also, it would be good to support both LDP and RSVP, and not RSVP only. Maybe I should contact the author to see if the project can be revived. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mtinka at globaltransit.net Thu Dec 29 04:03:20 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Thu, 29 Dec 2011 18:03:20 +0800 Subject: IPTV and ASM In-Reply-To: References: Message-ID: <201112291803.20441.mtinka@globaltransit.net> On Thursday, December 29, 2011 08:02:04 AM Keegan Holley wrote: > Isn't source discovery and efficiency a big concern for > ASM? If individual streams are tied to a specific > source then it's possible to live without some of the > overhead involved in ASM. Joins go straight to the > source, traffic is disseminated via direct paths instead > of being replicated by the RP, etc etc.. In our case, Source discovery happens once, and BGP updates containing that information is sent to all Receiver PE routers in the MVPN. They then generate Type 7 routes locally (due to running SPT-only mode), which are essentially (S,G) routes. Once a customer sends a Join message to subscribe to a group, the Receiver PE router just serves it locally. No need to send any requests back to the RP. This breaks regular PIM mechanisms, but is a welcome deviation that makes a lot of sense. One does have the option of running RPT-SPT modes which are akin to regular IP Multicast. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mtinka at globaltransit.net Thu Dec 29 04:03:46 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Thu, 29 Dec 2011 18:03:46 +0800 Subject: IPTV and ASM In-Reply-To: References: Message-ID: <201112291803.46788.mtinka@globaltransit.net> On Thursday, December 29, 2011 12:55:31 PM Antonio Querubin wrote: > That and numerous clients which don't know anything about > SSM. With SSM Mapping, they don't need to. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From avitkovsky at emea.att.com Thu Dec 29 04:27:24 2011 From: avitkovsky at emea.att.com (Vitkovsky, Adam) Date: Thu, 29 Dec 2011 11:27:24 +0100 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> Message-ID: >... host systems should participate in IGP >We tried that. >It didn't scale well. >The Internet today is very different than the Internet in 1981. -did you? I thought CLNS with plethora of ip addresses compared to ipv4 was buried before it could be widely deployed, I was not around back than but would like to know why ES-IS did not scale well when integrated IS-IS is still used primarily for great scalability From avitkovsky at emea.att.com Thu Dec 29 05:06:15 2011 From: avitkovsky at emea.att.com (Vitkovsky, Adam) Date: Thu, 29 Dec 2011 12:06:15 +0100 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <14160.1325099085@turing-police.cc.vt.edu> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> <14160.1325099085@turing-police.cc.vt.edu> Message-ID: (*) If you think I'm going to run an IGP on some of my file servers when "default route to the world out the public 1G interface, and 5 static routes describing the private 10G network" is actually the *desired* semantic because if anybody re-engineers the 10G net enough to make me change the routes, I have *other* things to change as well, like iptables entries and /etc/exports and so on. I don't *want* an IGP changing that stuff around wiithout the liveware taking a meeting to discuss deployment of the change. Well the only reason why you still have a good night sleep with the primary path in flames and all those in stone carved static routes is that your server is connected via ether channel to a couple of boxes with dual RPs and redundant power supplies running VSS or vPC and routers running vrrp All of this just because the end station just can't route around a failed link From rps at maine.edu Thu Dec 29 05:38:13 2011 From: rps at maine.edu (Ray Soucy) Date: Thu, 29 Dec 2011 06:38:13 -0500 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> <14160.1325099085@turing-police.cc.vt.edu> Message-ID: Sounds like we have one group saying that IPv6 is too complicated and that all the "overhead" of IPv6 had resulted in slow adoption. Meanwhile we have others saying it doesn't have enough functionality, and should also include IGP. Seems like IPv6 as it is has struck a balance somewhere in the middle. It's never going to be the perfect solution for every situation. There is a lot of academic and theoretical argument being made here, but not so much on the practical application side. I think this discussion went down hill when we started seeing people point to "evidence" that IPv6 is "broken" being special use cases that IPv4 can't even handle properly. On Thu, Dec 29, 2011 at 6:06 AM, Vitkovsky, Adam wrote: > > (*) If you think I'm going to run an IGP on some of my file servers when > "default route to the world out the public 1G interface, and 5 static routes > describing the private 10G network" is actually the *desired* semantic because > if anybody re-engineers the 10G net enough to make me change the routes, I have > *other* things to change as well, like iptables entries and /etc/exports and so > on. ?I don't *want* an IGP changing that stuff around wiithout the liveware > taking a meeting to discuss deployment of the change. > > > Well the only reason why you still have a good night sleep with the primary path in flames and all those in stone carved static routes is that your server is connected via ether channel to a couple of boxes with dual RPs and redundant power supplies running VSS or vPC and routers running vrrp > All of this just because the end station just can't route around a failed link > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From mtinka at globaltransit.net Thu Dec 29 05:39:27 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Thu, 29 Dec 2011 19:39:27 +0800 Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: <20111229091015.GA19931@pob.ytti.fi> References: <201112291656.47253.mtinka@globaltransit.net> <20111229091015.GA19931@pob.ytti.fi> Message-ID: <201112291939.31414.mtinka@globaltransit.net> On Thursday, December 29, 2011 05:10:15 PM Saku Ytti wrote: > Of course this isn't strictly true,... Of course, not "strictly". What I meant was the CRS and ASR9000 don't operate like the 6500/7600 and other Cisco switches that punted packets to CPU if, for one reason or another, a bug or misconfiguration caused said packets to be sent to the CPU for forwarding. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From Valdis.Kletnieks at vt.edu Thu Dec 29 06:01:33 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 29 Dec 2011 07:01:33 -0500 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: Your message of "Thu, 29 Dec 2011 09:14:20 GMT." <82ipkzwxhv.fsf@mid.bfk.de> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> <14160.1325099085@turing-police.cc.vt.edu> <4EFBD594.2000604@necom830.hpcl.titech.ac.jp> <30391.1325139437@turing-police.cc.vt.edu> <82ipkzwxhv.fsf@mid.bfk.de> Message-ID: <38375.1325160093@turing-police.cc.vt.edu> On Thu, 29 Dec 2011 09:14:20 GMT, Florian Weimer said: > Because there's a CPE which acts as a mediator, or the host uses some > dial-up-type protocol which takes care of the IGP interaction. So what percent of the *CPE* in the average cable-internet or DSL farm *actually uses* an IGP, and how much of it just does default route and be done with it, because there's only one cable head end to talk to or one central office to talk to at the other end of that DSL? In most topologies, you've got quite a ways to go before you actually need an IGP rather than just "point default route upstream". (We've already heard somebody from the wireless world say they do all their stuff with L1/L2 games and leave L3 as static as possible). Because the last time I unhooked my home router, and connected the coax to one side of the cablemodem and an RJ-45 from the other side to my laptop, the entire routing information that I got from some Comcast server that was definitely the other side of my cablemodem was an IP, netmask, and default route via DHCP, which I don't think qualifies as an IGP. So tell me Florian, what's this magical IGP that my Belkin is doing that's invisible to my Dell when I hook it up directly? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From mohta at necom830.hpcl.titech.ac.jp Thu Dec 29 06:46:22 2011 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 29 Dec 2011 21:46:22 +0900 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> <14160.1325099085@turing-police.cc.vt.edu> Message-ID: <4EFC611E.70601@necom830.hpcl.titech.ac.jp> Ray Soucy wrote: > Sounds like we have one group saying that IPv6 is too complicated and > that all the "overhead" of IPv6 had resulted in slow adoption. > > Meanwhile we have others saying it doesn't have enough functionality, > and should also include IGP. Not at all. It is wrong that ND is so complicated that it even act as IGP proxy. To simplify the situation, let separate address resolution and IGP, which is the conventional wisdom of IPv4. ND became too complicated unnecessarily trying to offer incomplete and incorrect assistance from routers to nodes, even though the nodes should take care of themselves using information provided through IGP. Having a default router is fine if there is only one router. However, with multiple routers, default routers and ICMP redirects are nothing more than an incomplete proxy of IGP. > There is a lot of academic and theoretical argument being made here, > but not so much on the practical application side. Though NANOG may not be a good place to discuss about practical application side, it may be helpful to mention IPv6 is totally broken for the side. That is, as the length of IPv6 extension headers is unlimited and there are extension headers inserted automatically without application control, there is no guaranteed minimal payload size left for the transport layer. As PMTUD of IPv6 is proven to be inoperational: http://meetings.apnic.net/__data/assets/file/0018/38214/pathMTU.pdf we must assume MTU of 1280B. But, as IPv6 extension headers can be as lengthy as 1000B or 2000B, no applications are guaranteed to work over IPv6. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Thu Dec 29 06:53:29 2011 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 29 Dec 2011 21:53:29 +0900 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <38375.1325160093@turing-police.cc.vt.edu> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> <14160.1325099085@turing-police.cc.vt.edu> <4EFBD594.2000604@necom830.hpcl.titech.ac.jp> <30391.1325139437@turing-police.cc.vt.edu> <82ipkzwxhv.fsf@mid.bfk.de> <38375.1325160093@turing-police.cc.vt.edu> Message-ID: <4EFC62C9.9030101@necom830.hpcl.titech.ac.jp> Valdis.Kletnieks at vt.edu wrote: > So what percent of the *CPE* in the average cable-internet or DSL farm *actually > uses* an IGP, As I wrote: > If a host receives RAs only from a router, the host can do > nothing other than installing the router as the default > router. If not, however, the host must directly be involved > in IGP activities, or, the following end to end argument > is applicable: IGP snooping is not necessary if the host have only one next hop router. Masataka Ohta From cb.list6 at gmail.com Thu Dec 29 06:59:20 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Thu, 29 Dec 2011 04:59:20 -0800 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> <14160.1325099085@turing-police.cc.vt.edu> Message-ID: On Dec 29, 2011 6:38 AM, "Ray Soucy" wrote: > > Sounds like we have one group saying that IPv6 is too complicated and > that all the "overhead" of IPv6 had resulted in slow adoption. > > Meanwhile we have others saying it doesn't have enough functionality, > and should also include IGP. > > Seems like IPv6 as it is has struck a balance somewhere in the middle. > It's never going to be the perfect solution for every situation. > > There is a lot of academic and theoretical argument being made here, > but not so much on the practical application side. I think this > discussion went down hill when we started seeing people point to > "evidence" that IPv6 is "broken" being special use cases that IPv4 > can't even handle properly. > > Yep. How about you guys take this nonsense off list. The first post was well intentioned, the rest has been FUD and sour grapes. Next topic, ethernet is too chaotic and inefficient to deploy and support mission critical applications in LAN or WAN or data center. Cb. > > > On Thu, Dec 29, 2011 at 6:06 AM, Vitkovsky, Adam > wrote: > > > > (*) If you think I'm going to run an IGP on some of my file servers when > > "default route to the world out the public 1G interface, and 5 static routes > > describing the private 10G network" is actually the *desired* semantic because > > if anybody re-engineers the 10G net enough to make me change the routes, I have > > *other* things to change as well, like iptables entries and /etc/exports and so > > on. I don't *want* an IGP changing that stuff around wiithout the liveware > > taking a meeting to discuss deployment of the change. > > > > > > Well the only reason why you still have a good night sleep with the primary path in flames and all those in stone carved static routes is that your server is connected via ether channel to a couple of boxes with dual RPs and redundant power supplies running VSS or vPC and routers running vrrp > > All of this just because the end station just can't route around a failed link > > > > > > -- > Ray Soucy > > Epic Communications Specialist > > Phone: +1 (207) 561-3526 > > Networkmaine, a Unit of the University of Maine System > http://www.networkmaine.net/ > From alan at clegg.com Thu Dec 29 07:54:05 2011 From: alan at clegg.com (Alan Clegg) Date: Thu, 29 Dec 2011 08:54:05 -0500 Subject: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EFBF1AC.1020204@necom830.hpcl.titech.ac.jp> References: <4EF4E24D.4020107@cis.vutbr.cz> <4EF4EBE0.4050609@necom830.hpcl.titech.ac.jp> <4EF58B34.6000904@rancid.berkeley.edu> <4EF59438.8040505@necom830.hpcl.titech.ac.jp> <1324724731.2763.26.camel@karl> <4EF6612F.2070901@necom830.hpcl.titech.ac.jp> <4EF66348.8040500@bogus.com> <4EF67019.1000309@necom830.hpcl.titech.ac.jp> <4EF8016D.4060208@necom830.hpcl.titech.ac.jp> <207827.1324922198@turing-police.cc.vt.edu> <4EFA4B71.20401@necom830.hpcl.titech.ac.jp> <248784.1325028520@turing-police.cc.vt.edu> <4EFAFE83.7060507@necom830.hpcl.titech.ac.jp> <4EFBBF46.70809@necom830.hpcl.titech.ac.jp> <4EFBF1AC.1020204@necom830.hpcl.titech.ac.jp> Message-ID: <4EFC70FD.3020902@clegg.com> On 12/28/2011 11:50 PM, Masataka Ohta wrote: > With DHCP only, there is no DAD necessary. Plonk AlanC -- alan at clegg.com | aclegg at infoblox.com 1.919.355.8851 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From Bruce.Curtis at ndsu.edu Thu Dec 29 08:04:55 2011 From: Bruce.Curtis at ndsu.edu (Curtis, Bruce) Date: Thu, 29 Dec 2011 06:04:55 -0800 Subject: IPTV and ASM In-Reply-To: References: Message-ID: <3FB44DF0-0BCE-49CA-83A4-78B584DDC247@ndsu.edu> On Dec 28, 2011, at 10:55 PM, Antonio Querubin wrote: > On Wed, 28 Dec 2011, Marshall Eubanks wrote: > >> From what I understand, the answer is likely to be "yes" and the >> reason is likely to be "deployed equipment only >> supports IGMP v2." > > That and numerous clients which don't know anything about SSM. For example Apple products don't support IGMPv3. --- Bruce Curtis bruce.curtis at ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University From asusag at ifncom.net Thu Dec 29 08:18:57 2011 From: asusag at ifncom.net (Andy Susag) Date: Thu, 29 Dec 2011 09:18:57 -0500 Subject: Notifying customers of upstream modifications In-Reply-To: <1325119493.2769.13.camel@teh-desktop> References: <01245B4ABF809743A84B2F16C6598FEABCFBA0@hydrogen> <1325119493.2769.13.camel@teh-desktop> Message-ID: <01245B4ABF809743A84B2F16C6598FEABCFBD0@hydrogen> Ding Ding Ding! > The answer, speaking as a downstream and a transit provider, is to just > peer where you need guaranteed connectivity. If change is a problem to > your customers, they don't understand how BGP works and they need to cut > out the middle-man. > Tom From alexandru.petrescu at gmail.com Thu Dec 29 08:51:02 2011 From: alexandru.petrescu at gmail.com (Alexandru Petrescu) Date: Thu, 29 Dec 2011 15:51:02 +0100 Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: References: Message-ID: <4EFC7E56.9040102@gmail.com> Le 28/12/2011 13:13, Ray Soucy a ?crit : > On Wed, Dec 28, 2011 at 6:23 AM, Iljitsch van Beijnum > wrote: >> Also somehow the rule that all normal address space must use 64-bit >> interface identifiers found its way into the specs for no reason >> that I have ever been able to uncover. On the other hand there's >> also the rule that IPv6 is classless and therefore routing on any >> prefix length must be supported, although for some implementations >> forwarding based on> /64 is> somewhat less efficient. > > This ambiguity has always bothered me. The address architecture RFC > requires a 64-bit interface identifier, Well yes, but only if it's an address which doesn't start with 000 (3 zero bits). I understand an address which starts with 000 can have an interface id of length generic 128-n where n is prefix length. (RFC4291 "Addressing Arch", pp. 6, 1st par). Generally speaking, my mind is disturbed by suggestions that the Interface ID must always be precisely of length 64. BEcause there is no particularly valid reason to impose it so, other than the vaguely useful and semantically doubtful 'u' bit - any software ever checks it on reception? At an extreme reading, it may look as the "secure" bit. Yours, Alex > but it's required to be unenforced by implementation, which makes it > more of a suggestion at best. I think the wording should be updated > to changed MUST to SHOULD. That said, and despite my own use of > prefix lengths other than 64-bit, I do believe that a 64-bit prefix > for each host network is in our long-term interest. Not having to > size networks based on the number of hosts is a good thing. Features > made possible by a 64-bit address space is a good thing. > From alexandru.petrescu at gmail.com Thu Dec 29 08:55:40 2011 From: alexandru.petrescu at gmail.com (Alexandru Petrescu) Date: Thu, 29 Dec 2011 15:55:40 +0100 Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: <20111228.164544.39172608.sthaug@nethelp.no> References: <37f38f1f-369f-4056-8593-32b54e7fbc88@d8g2000yqk.googlegroups.com> <20111228.155045.85391394.sthaug@nethelp.no> <20111228.164544.39172608.sthaug@nethelp.no> Message-ID: <4EFC7F6C.1080109@gmail.com> Le 28/12/2011 16:45, sthaug at nethelp.no a ?crit : >> If every route is nicely split at the 64-bit boundary, then it >> saves a step in matching the prefix. Admittedly a very inexpensive >> step. > > My point here is that IPv6 is still defined as "longest prefix > match", :-) yes agree, except that it's not known what "longest prefix match" is precisely. It is widely implemented in often closed source code, there is books about it and lectures to first-year students. I have heard it named "crown jewels" of some companies. High value and no specification == speculation. Alex > so unless you *know* that all prefixes are<= 64 bits, you still need > the longer match. > >> In this context, it is perfectly reasonable, and expected, that >> the use of longer prefixes will have a higher cost. > > In a way I agree with you. However, if I put my purchasing hat on, I > would refuse to buy equipment that could only forward on the first > 64 bits, *or* where the forwarding decision was much slower (hardware > vs software) for prefixes longer than 64 bits. I would not be > surprised if vendors decide that it is a *commercial* necessity to > support full 128 bit matches. > >> However, I think the number of routes, and your network >> architecture play a significant factor. > > Absolutely. In our network by far the largest number of IPv6 > prefixes are EBGP prefixes in the 32 to 48 bit range. However, we > also have for instance our own 128 bit loopbacks - they are obviously > only in our IGP. > >> I think a greater concern than simple routing and forwarding, would >> be additional services, such as queuing, or filtering. These may >> be implemented in hardware when a 64-bit boundary is used, but >> punted to CPU otherwise. Though this would be implementation >> specific and is something you would want to research for whatever >> hardware you're running. > > Again, that would be an excellent reason *not* to buy such > equipment. > > And yes, we know equipment that cannot *filter* on full IPv6 + port > number headers exists (e.g. Cisco 6500/7600 with 144 bit TCAMs) - my > original point was that I still haven't seen equipment with > forwarding problems for prefixes> 64 bits. > >> There are a few solutions that vendors will hopefully look into. >> One being to implement neighbor discovery in hardware (at which >> point table exhaustion also becomes a legitimate concern, so the >> logic should be such that known associations are not discarded in >> favor of unknown associations). > > I'm afraid I don't believe this is going to happen unless neighbor > discovery based attacks become a serious problem. And even then it > would take a long time. > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no > > From morrowc.lists at gmail.com Thu Dec 29 09:06:55 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 29 Dec 2011 10:06:55 -0500 Subject: next-best-transport! down with ethernet! Message-ID: (you forgot to change subj:) On Thu, Dec 29, 2011 at 7:59 AM, Cameron Byrne wrote: > Next topic, ethernet is too chaotic and inefficient to deploy and support > mission critical applications in LAN or WAN or data center. yes, let's get something with say fixed sized packets, ability to have predictable jitter and also, for fun, no more STP! Ethernet is too complex, maybe something simpler? I hear there's this new tech 'ATM'? it seems to fit the bill! :) (Happy new year almost) From Valdis.Kletnieks at vt.edu Thu Dec 29 10:11:29 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 29 Dec 2011 11:11:29 -0500 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: Your message of "Thu, 29 Dec 2011 21:53:29 +0900." <4EFC62C9.9030101@necom830.hpcl.titech.ac.jp> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> <14160.1325099085@turing-police.cc.vt.edu> <4EFBD594.2000604@necom830.hpcl.titech.ac.jp> <30391.1325139437@turing-police.cc.vt.edu> <82ipkzwxhv.fsf@mid.bfk.de> <38375.1325160093@turing-police.cc.vt.edu> <4EFC62C9.9030101@necom830.hpcl.titech.ac.jp> Message-ID: <44691.1325175089@turing-police.cc.vt.edu> On Thu, 29 Dec 2011 21:53:29 +0900, Masataka Ohta said: > IGP snooping is not necessary if the host have only one next > hop router. You don't need an IGP either at that point, no matter what some paper from years ago tries to assert. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From olivier.benghozi at wifirst.fr Thu Dec 29 10:25:45 2011 From: olivier.benghozi at wifirst.fr (Olivier Benghozi) Date: Thu, 29 Dec 2011 17:25:45 +0100 Subject: IPTV and ASM In-Reply-To: <3FB44DF0-0BCE-49CA-83A4-78B584DDC247@ndsu.edu> References: <3FB44DF0-0BCE-49CA-83A4-78B584DDC247@ndsu.edu> Message-ID: <83ED2ED0-D923-4BC0-BBC4-324DCE898B28@wifirst.fr> > For example Apple products don't support IGMPv3. Implemented at last in 2011 (!) under OSX Lion, 10 years after Windows XP... $ sysctl net.inet.igmp.default_version net.inet.igmp.default_version: 3 From sfouant at shortestpathfirst.net Thu Dec 29 12:19:17 2011 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Thu, 29 Dec 2011 13:19:17 -0500 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> <14160.1325099085@turing-police.cc.vt.edu> Message-ID: <4EFCAF25.6090008@shortestpathfirst.net> On 12/29/2011 7:59 AM, Cameron Byrne wrote: > > Next topic, ethernet is too chaotic and inefficient to deploy and support > mission critical applications in LAN or WAN or data center. See IEEE1588v2 (Precision Time Protocol), SyncE, and Data center bridging (DCB) - all attempts to remedy such inefficiencies. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ER, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate From kloch at kl.net Thu Dec 29 13:03:02 2011 From: kloch at kl.net (Kevin Loch) Date: Thu, 29 Dec 2011 14:03:02 -0500 Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: References: Message-ID: <4EFCB966.4000904@kl.net> Iljitsch van Beijnum wrote: > On 24 Dec 2011, at 6:32 , Glen Kent wrote: > >> I am trying to understand why standards say that "using a subnet >> prefix length other than a /64 will break many features of IPv6, >> including Neighbor Discovery (ND), Secure Neighbor Discovery (SEND) >> [RFC3971], .. " [reference RFC 5375] > > For stateless autoconfig the issue is that it uses 64-bit "interface identifiers" (~ MAC addresses) that are supposed to be globally unique. You can't shave off bits and remain globally unique. > > With SEND a cryptographic hash that can be used to determine address ownership is stored in the interface identifier. Here shaving off addresses reduces security. > > Also somehow the rule that all normal address space must use 64-bit interface identifiers found its way into the specs for no reason that I have ever been able to uncover. On the other hand there's also the rule that IPv6 is classless and therefore routing on any prefix length must be supported, although for some implementations forwarding based on > /64 is somewhat less efficient. > The 64 bit "mattress tag" is one of the cute historical quirks of IPv6. Of course in practice we use all sorts of longer prefixes for the same reasons we do in IPv4: Loopback ips, Limiting the scope of infrastructure links and server subnets, the many uses of more specific static routes, null routes (including the very important /128 ddos blackhole). The good news is that vendors recognized the need to efficiently route all 128 bits. Is there any known platform that does not? I'm starting to think this is an ancient myth that keeps resurfacing. - Kevin From tom at ninjabadger.net Thu Dec 29 13:57:47 2011 From: tom at ninjabadger.net (Tom Hill) Date: Thu, 29 Dec 2011 19:57:47 +0000 Subject: next-best-transport! down with ethernet! In-Reply-To: References: Message-ID: <1325188667.2646.4.camel@teh-desktop> On Thu, 2011-12-29 at 10:06 -0500, Christopher Morrow wrote: > yes, let's get something with say fixed sized packets, ability to have > predictable jitter and also, for fun, no more STP! > Ethernet is too complex, maybe something simpler? I hear there's this > new tech 'ATM'? it seems to fit the bill! Pfft. Everyone knows that Fibre Channel's going to replace everything... The minute we get those 128Gbit/sec transmission characteristics, Ethernet's gonna be as good as RS-485. From dholmes at mwdh2o.com Thu Dec 29 14:06:51 2011 From: dholmes at mwdh2o.com (Holmes,David A) Date: Thu, 29 Dec 2011 12:06:51 -0800 Subject: next-best-transport! down with ethernet! In-Reply-To: <1325188667.2646.4.camel@teh-desktop> References: <1325188667.2646.4.camel@teh-desktop> Message-ID: <922ACC42D498884AA02B3565688AF9953402D4F690@USEXMBS01.mwd.h2o> If I am not mistaken the IETF efforts to standardize the TRILL spec, and IEEE efforts to standardize the DCB spec will provide the desired features to Ethernet: lossless delivery, QoS, and bringing an IS-IS layer 3 model to layer 2. I think Cisco has a pre TRILL/DCB standards feature set called Fabricpath, and Brocade has a feature set called VCS. Both, I think, will converge Ethernet data and Fibre Channel over the same wire. -----Original Message----- From: Tom Hill [mailto:tom at ninjabadger.net] Sent: Thursday, December 29, 2011 11:58 AM To: nanog at nanog.org Subject: Re: next-best-transport! down with ethernet! On Thu, 2011-12-29 at 10:06 -0500, Christopher Morrow wrote: > yes, let's get something with say fixed sized packets, ability to have > predictable jitter and also, for fun, no more STP! > Ethernet is too complex, maybe something simpler? I hear there's this > new tech 'ATM'? it seems to fit the bill! Pfft. Everyone knows that Fibre Channel's going to replace everything... The minute we get those 128Gbit/sec transmission characteristics, Ethernet's gonna be as good as RS-485. This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system. From tony.li at tony.li Thu Dec 29 14:17:35 2011 From: tony.li at tony.li (Tony Li) Date: Thu, 29 Dec 2011 12:17:35 -0800 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> Message-ID: On Dec 29, 2011, at 2:27 AM, Vitkovsky, Adam wrote: >> ... host systems should participate in IGP > >> We tried that. > >> It didn't scale well. > >> The Internet today is very different than the Internet in 1981. > > -did you? I thought CLNS with plethora of ip addresses compared to ipv4 was buried before it could be widely deployed, I was not around back than but would like to know why ES-IS did not scale well when integrated IS-IS is still used primarily for great scalability ??? CLNS carried NSAPs, not IP addresses. ES-IS was the protocol between hosts and routers, very much akin to ARP. IS-IS was the IGP used for CLNS. Yes, it's the same one that we use today for IP. Even in the ISO model, hosts did not participate in IS-IS. There was no particular scalability problem with ES-IS, other than the mcast burden that it imposed on the link layer. This is not radically different than the burden that ARP broadcasts require. Limit your broadcast domains. Tony From rps at maine.edu Thu Dec 29 15:13:57 2011 From: rps at maine.edu (Ray Soucy) Date: Thu, 29 Dec 2011 16:13:57 -0500 Subject: subnet prefix length > 64 breaks IPv6? In-Reply-To: <4EFCB966.4000904@kl.net> References: <4EFCB966.4000904@kl.net> Message-ID: On Thu, Dec 29, 2011 at 2:03 PM, Kevin Loch wrote: > The 64 bit "mattress tag" This phrase made my year. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From mohta at necom830.hpcl.titech.ac.jp Thu Dec 29 16:30:16 2011 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 30 Dec 2011 07:30:16 +0900 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <44691.1325175089@turing-police.cc.vt.edu> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> <14160.1325099085@turing-police.cc.vt.edu> <4EFBD594.2000604@necom830.hpcl.titech.ac.jp> <30391.1325139437@turing-police.cc.vt.edu> <82ipkzwxhv.fsf@mid.bfk.de> <38375.1325160093@turing-police.cc.vt.edu> <4EFC62C9.9030101@necom830.hpcl.titech.ac.jp> <44691.1325175089@turing-police.cc.vt.edu> Message-ID: <4EFCE9F8.2040604@necom830.hpcl.titech.ac.jp> Valdis.Kletnieks at vt.edu wrote: >> IGP snooping is not necessary if the host have only one next >> hop router. > You don't need an IGP either at that point, no matter what some paper from > years ago tries to assert. :) IGP is the way for routers advertise their existence, though, in this simplest case, an incomplete proxy of relying on a default router works correctly. Beyond that, if there are multiple routers, having a default router and relying on the default router for forwarding to other routers and/or supplying ICMP redirects stops working when the default router, the single point of failure, goes down, which is the incompleteness and/or incorrectness predicted by the paper of the end to end argument. Considering that the reason to have multiple routers should be for redundancy, there is no point to use one of them as the default router. Developing more complicated IGP proxy makes the incompleteness and the incorrectness not disappear but more complicated. Masataka Ohta PS Note that the paper was written in 1984, where as RFC791 was written in 1981. From smb at cs.columbia.edu Thu Dec 29 17:37:20 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Thu, 29 Dec 2011 18:37:20 -0500 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EFCE9F8.2040604@necom830.hpcl.titech.ac.jp> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> <14160.1325099085@turing-police.cc.vt.edu> <4EFBD594.2000604@necom830.hpcl.titech.ac.jp> <30391.1325139437@turing-police.cc.vt.edu> <82ipkzwxhv.fsf@mid.bfk.de> <38375.1325160093@turing-police.cc.vt.edu> <4EFC62C9.9030101@necom830.hpcl.titech.ac.jp> <44691.1325175089@turing-police.cc.vt.edu> <4EFCE9F8.2040604@necom830.hpcl.titech.ac.jp> Message-ID: <7A656097-5C49-445D-BC12-17E28EA10853@cs.columbia.edu> On Dec 29, 2011, at 5:30 16PM, Masataka Ohta wrote: > Valdis.Kletnieks at vt.edu wrote: > >>> IGP snooping is not necessary if the host have only one next >>> hop router. > >> You don't need an IGP either at that point, no matter what some paper from >> years ago tries to assert. :) > > IGP is the way for routers advertise their existence, > though, in this simplest case, an incomplete proxy of > relying on a default router works correctly. > > Beyond that, if there are multiple routers, having a default > router and relying on the default router for forwarding to > other routers and/or supplying ICMP redirects stops working > when the default router, the single point of failure, goes > down, which is the incompleteness and/or incorrectness > predicted by the paper of the end to end argument. > > Considering that the reason to have multiple routers > should be for redundancy, there is no point to use > one of them as the default router. VRRP? The Router Discovery Protocol (RFC 1256). But given how much more reliable routers are today than in 1984, I'm not convinced it's that necessary these days. > > Developing more complicated IGP proxy makes the > incompleteness and the incorrectness not disappear but > more complicated. > > Masataka Ohta > > PS > > Note that the paper was written in 1984, where as RFC791 > was written in 1981. > There was a lot less understanding of the difference between hosts and routers in 1984 than there is today -- if nothing else, note how 4.2BSD and 4.3BSD considered all multihomed machines to be routers. > --Steve Bellovin, https://www.cs.columbia.edu/~smb From randy at psg.com Thu Dec 29 18:11:24 2011 From: randy at psg.com (Randy Bush) Date: Fri, 30 Dec 2011 09:11:24 +0900 Subject: next-best-transport! down with ethernet! In-Reply-To: References: Message-ID: > yes, let's get something with say fixed sized packets, ability to have > predictable jitter and also, for fun, no more STP! > Ethernet is too complex, maybe something simpler? I hear there's this > new tech 'ATM'? it seems to fit the bill! atm-2, aka mpls From djahandarie at gmail.com Thu Dec 29 18:16:59 2011 From: djahandarie at gmail.com (Darius Jahandarie) Date: Thu, 29 Dec 2011 19:16:59 -0500 Subject: next-best-transport! down with ethernet! In-Reply-To: References: Message-ID: On Thu, Dec 29, 2011 at 19:11, Randy Bush wrote: > atm-2, aka mpls I knew MPLS was fishy... -- Darius Jahandarie From Valdis.Kletnieks at vt.edu Thu Dec 29 18:26:42 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 29 Dec 2011 19:26:42 -0500 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: Your message of "Fri, 30 Dec 2011 07:30:16 +0900." <4EFCE9F8.2040604@necom830.hpcl.titech.ac.jp> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> <14160.1325099085@turing-police.cc.vt.edu> <4EFBD594.2000604@necom830.hpcl.titech.ac.jp> <30391.1325139437@turing-police.cc.vt.edu> <82ipkzwxhv.fsf@mid.bfk.de> <38375.1325160093@turing-police.cc.vt.edu> <4EFC62C9.9030101@necom830.hpcl.titech.ac.jp> <44691.1325175089@turing-police.cc.vt.edu> <4EFCE9F8.2040604@necom830.hpcl.titech.ac.jp> Message-ID: <68424.1325204802@turing-police.cc.vt.edu> On Fri, 30 Dec 2011 07:30:16 +0900, Masataka Ohta said: > IGP is the way for routers advertise their existence, > though, in this simplest case, an incomplete proxy of > relying on a default router works correctly. Which is sufficient for 99.8% of hosts out there. > Beyond that, if there are multiple routers, having a default > router and relying Yes yes we know, and we've understood this for a quarter century or so. My disagreement is that even though 99.8% of machines *don't* have multiple routers, you seem to be pedantically insisting that some sort of IGP is mandatory for *all* end hosts, even though only 0.2% or so will actually see any benefit at all.. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From marka at isc.org Thu Dec 29 19:12:43 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 30 Dec 2011 12:12:43 +1100 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: Your message of "Thu, 29 Dec 2011 19:26:42 CDT." <68424.1325204802@turing-police.cc.vt.edu> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> <14160.1325099085@turing-police.cc.vt.edu> <4EFBD594.2000604@necom830.hpcl.titech.ac.jp> <30391.1325139437@turing-police.cc.vt.edu> <82ipkzwxhv.fsf@mid.bfk.de> <38375.1325160093@turing-police.cc.vt.edu> <4EFC62C9.9030101@necom830.hpcl.titech.ac.jp> <44691.1325175089@turing-police.cc.vt.edu> <4EFCE9F8.2040604@necom830.hpcl.titech.ac.jp> <68424.1325204802@turing-police.cc.vt.edu> Message-ID: <20111230011243.2BC201ABB7F7@drugs.dv.isc.org> In message <68424.1325204802 at turing-police.cc.vt.edu>, Valdis.Kletnieks at vt.edu writes: > On Fri, 30 Dec 2011 07:30:16 +0900, Masataka Ohta said: > > IGP is the way for routers advertise their existence, > > though, in this simplest case, an incomplete proxy of > > relying on a default router works correctly. > > Which is sufficient for 99.8% of hosts out there. > > > Beyond that, if there are multiple routers, having a default > > router and relying > > Yes yes we know, and we've understood this for a quarter century or so. My > disagreement is that even though 99.8% of machines *don't* have multiple > routers, you seem to be pedantically insisting that some sort of IGP is > mandatory for *all* end hosts, even though only 0.2% or so will actually see > any benefit at all. Well I'd like to be able to plug in the cable router and the DSL router at home and have it all just work. Just because it is 0.2% today doesn't mean that it will be 0.2% in the future. As home users get more and more dependent on the internet working having diverse, independent network connectivity will become more and more important. Mark -- 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 Thu Dec 29 19:24:59 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 29 Dec 2011 20:24:59 -0500 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: Your message of "Fri, 30 Dec 2011 12:12:43 +1100." <20111230011243.2BC201ABB7F7@drugs.dv.isc.org> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> <14160.1325099085@turing-police.cc.vt.edu> <4EFBD594.2000604@necom830.hpcl.titech.ac.jp> <30391.1325139437@turing-police.cc.vt.edu> <82ipkzwxhv.fsf@mid.bfk.de> <38375.1325160093@turing-police.cc.vt.edu> <4EFC62C9.9030101@necom830.hpcl.titech.ac.jp> <44691.1325175089@turing-police.cc.vt.edu> <4EFCE9F8.2040604@necom830.hpcl.titech.ac.jp> <68424.1325204802@turing-police.cc.vt.edu> <20111230011243.2BC201ABB7F7@drugs.dv.isc.org> Message-ID: <69748.1325208299@turing-police.cc.vt.edu> On Fri, 30 Dec 2011 12:12:43 +1100, Mark Andrews said: > Well I'd like to be able to plug in the cable router and the DSL > router at home and have it all just work. Just because it is 0.2% > today doesn't mean that it will be 0.2% in the future. As home > users get more and more dependent on the internet working having > diverse, independent network connectivity will become more and more > important. Agreed. But did you plug the cable router and the DSL router both into your PC, or into yet another box that needs routing smarts and then your PC just needs to know "talk to the smart box"? (Hint - if the cable router and the DSL router are both plugged into your PC, how do all the *other* devices in your house reach the internet? :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jeff-kell at utc.edu Thu Dec 29 20:00:01 2011 From: jeff-kell at utc.edu (Jeff Kell) Date: Thu, 29 Dec 2011 21:00:01 -0500 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <20111230011243.2BC201ABB7F7@drugs.dv.isc.org> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> <14160.1325099085@turing-police.cc.vt.edu> <4EFBD594.2000604@necom830.hpcl.titech.ac.jp> <30391.1325139437@turing-police.cc.vt.edu> <82ipkzwxhv.fsf@mid.bfk.de> <38375.1325160093@turing-police.cc.vt.edu> <4EFC62C9.9030101@necom830.hpcl.titech.ac.jp> <44691.1325175089@turing-police.cc.vt.edu> <4EFCE9F8.2040604@necom830.hpcl.titech.ac.jp> <68424.1325204802@turing-police.cc.vt.edu> <20111230011243.2BC201ABB7F7@drugs.dv.isc.org> Message-ID: <4EFD1B21.1010903@utc.edu> On 12/29/2011 8:12 PM, Mark Andrews wrote: > Well I'd like to be able to plug in the cable router and the DSL > router at home and have it all just work. Well, that's not too far removed from the plugged-in laptop with the wireless still active. Toss-up which one wins default route. What would you "like" it to do? BGP feeds from both (likely not happening)? Defaults from both? Or you just want active/passive failover? The real-world case for host routing (IMHO) is a server with a public interface, an administrative interface, and possibly a third path for data backups (maybe four if it's VMware/VMotion too). Unless the non-public interfaces are flat subnets, you need some statics (today). It can be a challenge to get SysAdmins in a co-operative mindset to route that correctly (and repetitively if you have a server farm). I would be walking the fence on the virtues of automatic route discovery in that case versus the security of static routes/configurations. But home use from a host perspective? Jeff From mohta at necom830.hpcl.titech.ac.jp Thu Dec 29 20:10:03 2011 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 30 Dec 2011 11:10:03 +0900 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <7A656097-5C49-445D-BC12-17E28EA10853@cs.columbia.edu> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> <14160.1325099085@turing-police.cc.vt.edu> <4EFBD594.2000604@necom830.hpcl.titech.ac.jp> <30391.1325139437@turing-police.cc.vt.edu> <82ipkzwxhv.fsf@mid.bfk.de> <38375.1325160093@turing-police.cc.vt.edu> <4EFC62C9.9030101@necom830.hpcl.titech.ac.jp> <44691.1325175089@turing-police.cc.vt.edu> <4EFCE9F8.2040604@necom830.hpcl.titech.ac.jp> <7A656097-5C49-445D-BC12-17E28EA10853@cs.columbia.edu> Message-ID: <4EFD1D7B.6020101@necom830.hpcl.titech.ac.jp> Steven Bellovin wrote: >> Considering that the reason to have multiple routers >> should be for redundancy, there is no point to use >> one of them as the default router. > VRRP? The Router Discovery Protocol (RFC 1256). But given > how much more reliable routers are today than in 1984, I'm > not convinced it's that necessary these days. How much, do you think, more reliability required to the Internet today than in 1984? > There was a lot less understanding of the difference between hosts > and routers in 1984 than there is today -- if nothing else, note > how 4.2BSD and 4.3BSD considered all multihomed machines to be > routers. Unlike routers, multihomed machines without forwarding should listen IGP but must not advertise routes, which was well understood very well even at that time. It is the right thing to do, as is proven by the 99.8% argument that Microsoft don't do so. :-) Masataka Ohta From jmaslak at antelope.net Thu Dec 29 20:10:45 2011 From: jmaslak at antelope.net (Joel Maslak) Date: Thu, 29 Dec 2011 19:10:45 -0700 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EFD1B21.1010903@utc.edu> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> <14160.1325099085@turing-police.cc.vt.edu> <4EFBD594.2000604@necom830.hpcl.titech.ac.jp> <30391.1325139437@turing-police.cc.vt.edu> <82ipkzwxhv.fsf@mid.bfk.de> <38375.1325160093@turing-police.cc.vt.edu> <4EFC62C9.9030101@necom830.hpcl.titech.ac.jp> <44691.1325175089@turing-police.cc.vt.edu> <4EFCE9F8.2040604@necom830.hpcl.titech.ac.jp> <68424.1325204802@turing-police.cc.vt.edu> <20111230011243.2BC201ABB7F7@drugs.dv.isc.org> <4EFD1B21.1010903@utc.edu> Message-ID: <381C923E-D67F-4C77-AC30-81580BF3EA7D@antelope.net> On Dec 29, 2011, at 7:00 PM, Jeff Kell wrote: > The real-world case for host routing (IMHO) is a server with a public > interface, an administrative interface, and possibly a third path for > data backups (maybe four if it's VMware/VMotion too). Unless the > non-public interfaces are flat subnets, you need some statics (today). > It can be a challenge to get SysAdmins in a co-operative mindset to > route that correctly (and repetitively if you have a server farm). What I've done in that case as a sysadmin was a default out the internet interface and some sort of ospf daemon to handle the rest. If I want a host to learn routing, I put a routing daemon on it. Otherwise I just use a default route. I don't see why this changes with IPv6. From marka at isc.org Thu Dec 29 20:10:28 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 30 Dec 2011 13:10:28 +1100 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: Your message of "Thu, 29 Dec 2011 20:24:59 CDT." <69748.1325208299@turing-police.cc.vt.edu> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> <14160.1325099085@turing-police.cc.vt.edu> <4EFBD594.2000604@necom830.hpcl.titech.ac.jp> <30391.1325139437@turing-police.cc.vt.edu> <82ipkzwxhv.fsf@mid.bfk.de> <38375.1325160093@turing-police.cc.vt.edu> <4EFC62C9.9030101@necom830.hpcl.titech.ac.jp> <44691.1325175089@turing-police.cc.vt.edu> <4EFCE9F8.2040604@necom830.hpcl.titech.ac.jp> <68424.1325204802@turing-police.cc.vt.edu> <20111230011243.2BC201ABB7F7@drugs.dv.isc.org> <69748.1325208299@turing-police.cc.vt.edu> Message-ID: <20111230021029.1094A1ABBE9F@drugs.dv.isc.org> In message <69748.1325208299 at turing-police.cc.vt.edu>, Valdis.Kletnieks at vt.edu writes: > On Fri, 30 Dec 2011 12:12:43 +1100, Mark Andrews said: > > > Well I'd like to be able to plug in the cable router and the DSL > > router at home and have it all just work. Just because it is 0.2% > > today doesn't mean that it will be 0.2% in the future. As home > > users get more and more dependent on the internet working having > > diverse, independent network connectivity will become more and more > > important. > > Agreed. But did you plug the cable router and the DSL router both > into your PC, or into yet another box that needs routing smarts and > then your PC just needs to know "talk to the smart box"? > > (Hint - if the cable router and the DSL router are both plugged into > your PC, how do all the *other* devices in your house reach the internet? :) I'm curious. How did you get directly connected to the PC from the above description? The routers would be connected to the internal *network*. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From rps at maine.edu Thu Dec 29 20:18:35 2011 From: rps at maine.edu (Ray Soucy) Date: Thu, 29 Dec 2011 21:18:35 -0500 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EFCE9F8.2040604@necom830.hpcl.titech.ac.jp> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> <14160.1325099085@turing-police.cc.vt.edu> <4EFBD594.2000604@necom830.hpcl.titech.ac.jp> <30391.1325139437@turing-police.cc.vt.edu> <82ipkzwxhv.fsf@mid.bfk.de> <38375.1325160093@turing-police.cc.vt.edu> <4EFC62C9.9030101@necom830.hpcl.titech.ac.jp> <44691.1325175089@turing-police.cc.vt.edu> <4EFCE9F8.2040604@necom830.hpcl.titech.ac.jp> Message-ID: OK, this is getting ridiculous. Let's assume that we have a model where host systems receive the global routing table from service providers. ?The stated reason for this is so that they could make their own routing decisions when multi-homed environment. ?Presumably with each ISP connected to a L2 device; let's say an Ethernet Switch. So now we have ISP A, B, and let's even add C. ?Each are providing all available routes in the global table, and path information, allowing the host to make intelligent routing decisions. Unfortunately, for bi-directional communication, the prefix assigned to the customer must be provider independent. ?It's a residential service so maybe they have a single 64-bit prefix. ?So we now need ISP A, B, and C to be announcing that prefix. Congratulations, you have just created a model where every customer would have their own entry in the global table (since route summarization and aggregation is now impossible), one that is exponentially greater than the production IP global table today. But that is only the case if you let customers have a PI prefix (which I think is really required in a purist end-to-end model, but for the sake of argument...). We could, of course, only provide customers with the global table, and have each ISP give hosts a different prefix. ?This would allow for the selection of the best path by the host, but once that communication is established it would be locked into that path. ?The remote host would have no knowledge of other available prefixes (even if there is a path change, and a different path becomes favorable). ?To get around this we could develop another message that allows a host to announce alternative addresses to other hosts; which means systems now also need to keep a table of alternate peer addresses, and have the ability to quickly detect changes in path availability and quality. The result is still a very large amount of overhead. ?You will still experience significant change propagation delay (slower than change propagation under the current model as it would be more complex, involve exponentially more peers, paths, etc, and be performed on commodity hardware). This all would be significantly more complex than IPv6 (which is already claimed, by the proponents of the beloved end-to-end model, to be too complex and have too much overhead), it would introduce even more delay (another complaint) than IPv6 due to that complexity. Limitations aside. ?We now know that it takes well over a decade for people to move to a protocol, even when it is almost operationally identical to its predecessor. ?Getting buy-in for such a fundamental shift in how the Internet is build would be almost impossible at this point. ?To be frank, you would have to build a completely new and parallel network and hope you could somehow convince people to adopt it (when everything they want works "just fine" on the "old" network). I honestly can't believe we're even having this discussion. ?It's really bonkers. 2011/12/29 Masataka Ohta : > Valdis.Kletnieks at vt.edu wrote: > >>> IGP snooping is not necessary if the host have only one next >>> hop router. > >> You don't need an IGP either at that point, no matter what some paper from >> years ago tries to assert. :) > > IGP is the way for routers advertise their existence, > though, in this simplest case, an incomplete proxy of > relying on a default router works correctly. > > Beyond that, if there are multiple routers, having a default > router and relying on the default router for forwarding to > other routers and/or supplying ICMP redirects stops working > when the default router, the single point of failure, goes > down, which is the incompleteness and/or incorrectness > predicted by the paper of the end to end argument. > > Considering that the reason to have multiple routers > should be for redundancy, there is no point to use > one of them as the default router. > > Developing more complicated IGP proxy makes the > incompleteness and the incorrectness not disappear but > more complicated. > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Masataka Ohta > > PS > > Note that the paper was written in 1984, where as RFC791 > was written in 1981. > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From iljitsch at muada.com Fri Dec 30 03:31:48 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 30 Dec 2011 10:31:48 +0100 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EFBA369.8090103@dougbarton.us> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFBA369.8090103@dougbarton.us> Message-ID: <0F9BE646-7D00-4425-9163-5759E01FDF02@muada.com> On 29 Dec 2011, at 0:16 , Doug Barton wrote: > On 12/28/2011 03:13, Iljitsch van Beijnum wrote: >> However, this has two issues. First, with RAs there are no risks that >> incorrect default information is propagated because the default >> gateway itself broadcasts its presence. > Unless you have a malicious user on the network in which case all > traffic immediately switches to the malicious user's gateway. This is a different issue. And although this is / has been common for RAs/stateless autoconfig beceause some idiot at Microsoft made this happen more or less automatically in some configurations, there really is no difference between DHCPv6 and stateless autoconfig here. What I'm talking about is the issue where a legitimate DHCP server gives out an incorrect default gateway addresses because of a configuration mistake. Because a DHCP server that isn't also that same router has no way of knowing that address this can't be automatically done right so mistakes happen. Especially at this point with IPv6 where most people don't notice it when it doesn't work most of the time. > I'm aware that SEND is trying to solve this problem, but it's not > yet deployed. SEND is similar to IPsec in this regard, it's not going to be deployed widely because it's too complex to do so. > I think that people already know of and have solutions for the security > issues that exist for DHCP today. Yes, for IPv4. But this is a filtering issue. If you can filter rogue DHCPv6 servers you can also filter rogue RAs. > 10-12 years ago I attempted to make 2 points to the IPv6 literati. First > that IPv6 would not be widely adopted in the enterprise until it had > full DHCP parity with v4. Second that the easiest way to do that would > be to declare all existing DHCPv4 options that are relevant to IPv6 as > existing in DHCPv6 by fiat, and to prevent new v6-only options from > using option numbers that already exist for v4 (and vice versa). I was > laughed out of the room on both counts. I agree with you that DHCPv6 doesn't deserve any prizes, not for design, implementation nor time to market. But I disagree that importing all IPv4 cruft into IPv6 for the sake of speeding up deployment that wasn't going to happen anyway would have been a good idea then, let alone now. > The good news is that it's not too late to fix DHCPv6. We're at a > watershed moment where it's just possible that we'll get the ability to > assign a default gateway added to it due to, for lack of a better term, > market forces. This would be a major paradigm shift. As you point out > the development lead time on stuff like that is rather painful, however > if we took advantage of the camel's nose under the tent and included > "everything relevant that DHCPv4 can do" in that update, we'd be in a > pretty good condition in a year or so. You are living in a fantasy world if you think that. From mohta at necom830.hpcl.titech.ac.jp Fri Dec 30 03:49:48 2011 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 30 Dec 2011 18:49:48 +0900 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> <14160.1325099085@turing-police.cc.vt.edu> <4EFBD594.2000604@necom830.hpcl.titech.ac.jp> <30391.1325139437@turing-police.cc.vt.edu> <82ipkzwxhv.fsf@mid.bfk.de> <38375.1325160093@turing-police.cc.vt.edu> <4EFC62C9.9030101@necom830.hpcl.titech.ac.jp> <44691.1325175089@turing-police.cc.vt.edu> <4EFCE9F8.2040604@necom830.hpcl.titech.ac.jp> Message-ID: <4EFD893C.8010907@necom830.hpcl.titech.ac.jp> Ray Soucy wrote: > But that is only the case if you let customers have a PI prefix (which > I think is really required in a purist end-to-end model, but for the > sake of argument...). Multihoming by routing, by the intermediate systems, is against the end to end principle, which is why it does not scale. > The remote host would > have no knowledge of other available prefixes As IP layer is connectionless, let transport or application layer carry the information on the prefixes to try to keep connections. > (even if there is a path > change, and a different path becomes favorable). The remote host can use IGP metric to know the initial best candidate and subsequent path changes. It can be assumed that default free routing table is small. In addition, the remote host may also use transport/application layer timeout to try other prefixes. > The result is still a very large amount of overhead. You will still > experience significant change propagation delay (slower than change > propagation under the current model Not at all. Transport/application timeout is no different. Route propagation is no slower. Instead, smaller default free routing table means more rapid convergence. > This all would be significantly more complex than IPv6 It was IPv6 which was expected to support multiple addresses to suppress routing table growth. The result is a complex protocol with halfhearted support for multiple addresses. > We now know that it takes well over a decade for > people to move to a protocol, even when it is almost operationally > identical to its predecessor. Unlike IPv4, IPv6 is poorly operational and still needs protocol modifications, For example, multicast PMTUD causes ICMP implosion, which means rational operators filter ICMP packet too big often including those against unicast packets, which means PMTUD won't work. Yes, fixing it requires more than a decade. Then, it may be a good idea to obsolete SLAAC, which means IPv6 address can be only 8B long. You know, remembering 16B addresses is divine, which is an operational head ache. > To be frank, you would have to build a completely new and > parallel network and hope you could somehow convince people to adopt > it Multihoming with multiple addresses works at transport/application layer over existing IPv4 and IPv6. Masataka Ohta From avitkovsky at emea.att.com Fri Dec 30 03:58:38 2011 From: avitkovsky at emea.att.com (Vitkovsky, Adam) Date: Fri, 30 Dec 2011 10:58:38 +0100 Subject: next-best-transport! down with ethernet! In-Reply-To: <1325188667.2646.4.camel@teh-desktop> References: <1325188667.2646.4.camel@teh-desktop> Message-ID: Actually an a Cisco presentation on Nexus 7k I asked whether it's possible to transport the FCoE over let's say EoMPLS or VPLS and did not get a straight answer though that was half a year ago -but it would be really cool to connect hard-drives directly over continents adam -----Original Message----- From: Tom Hill [mailto:tom at ninjabadger.net] Sent: Thursday, December 29, 2011 8:58 PM To: nanog at nanog.org Subject: Re: next-best-transport! down with ethernet! On Thu, 2011-12-29 at 10:06 -0500, Christopher Morrow wrote: > yes, let's get something with say fixed sized packets, ability to have > predictable jitter and also, for fun, no more STP! > Ethernet is too complex, maybe something simpler? I hear there's this > new tech 'ATM'? it seems to fit the bill! Pfft. Everyone knows that Fibre Channel's going to replace everything... The minute we get those 128Gbit/sec transmission characteristics, Ethernet's gonna be as good as RS-485. From oscar.vives at gmail.com Fri Dec 30 05:01:34 2011 From: oscar.vives at gmail.com (Tei) Date: Fri, 30 Dec 2011 12:01:34 +0100 Subject: next-best-transport! down with ethernet! In-Reply-To: References: <1325188667.2646.4.camel@teh-desktop> Message-ID: I am php/javascript programmer. The web used to be request/reply. With the request small (but not small enough), and the reply long. But the time for permanent connections is comming. Links from clients to server that are permanent. Or look like that in the application layer. On one sense, this is a optimization, no more pooling the server "do you have something for me?" every n seconds. But I imagine mostly make things like caching and proxies pointless. At some point, users will start getting unhappy with web pages replies slower than 100 ms. ATM my webpages takes longer to start Jquery that all the server-client interactions. Most obvious optimization is never reload the page, and run everything trough ajax calls. I am not dumb, I know turning webpages into applications make webpages to fragile. But I am scared of javascripts. Javascript is just too dawmn usefull now, browsers too broken (mostly IE), and Javascript is like a superhero that fix all. The web is going to change in a few years, from a "request" "reply" interchange network, to something more like a computer "bus". I don't know how the "wires" will react to this. On 30 December 2011 10:58, Vitkovsky, Adam wrote: > Actually an a Cisco presentation on Nexus 7k I asked whether it's possible to transport the FCoE over let's say EoMPLS or VPLS and did not get a straight answer though that was half a year ago > -but it would be really cool to connect hard-drives directly over continents > > > adam > > -----Original Message----- > From: Tom Hill [mailto:tom at ninjabadger.net] > Sent: Thursday, December 29, 2011 8:58 PM > To: nanog at nanog.org > Subject: Re: next-best-transport! down with ethernet! > > On Thu, 2011-12-29 at 10:06 -0500, Christopher Morrow wrote: >> yes, let's get something with say fixed sized packets, ability to have >> predictable jitter and also, for fun, no more STP! >> Ethernet is too complex, maybe something simpler? I hear there's this >> new tech 'ATM'? it seems to fit the bill! > > Pfft. Everyone knows that Fibre Channel's going to replace everything... > The minute we get those 128Gbit/sec transmission characteristics, > Ethernet's gonna be as good as RS-485. > > > > > -- -- ?in del ?ensaje. From rps at maine.edu Fri Dec 30 06:09:50 2011 From: rps at maine.edu (Ray Soucy) Date: Fri, 30 Dec 2011 07:09:50 -0500 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EFD893C.8010907@necom830.hpcl.titech.ac.jp> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> <14160.1325099085@turing-police.cc.vt.edu> <4EFBD594.2000604@necom830.hpcl.titech.ac.jp> <30391.1325139437@turing-police.cc.vt.edu> <82ipkzwxhv.fsf@mid.bfk.de> <38375.1325160093@turing-police.cc.vt.edu> <4EFC62C9.9030101@necom830.hpcl.titech.ac.jp> <44691.1325175089@turing-police.cc.vt.edu> <4EFCE9F8.2040604@necom830.hpcl.titech.ac.jp> <4EFD893C.8010907@necom830.hpcl.titech.ac.jp> Message-ID: Well, it seems now you've also added the requirement that we also dramatically re-write all software that makes use of networking. Seemingly for the sake of never admitting that you can be wrong. You seem to think that the OSI model is this nice and clean model that cleanly separates everything and that you can just freely replace chunks of it. That was the idea; but in practice, there is a lot more grey area, and dependencies. Again, it's like you live in a theoretical world where physical limitations and operational realities don't exist. Honestly. Here is a thought: Go off and write up the RFCs to make this all work, and come back when you have an model implementation we can all look at. I think that would be a win-win for everyone. I normally don't try to dismiss people completely, but you're exhausting. You never directly respond to anything except with a one line assertion like "not at all," or by changing the parameters of the argument to a model that doesn't exist. I could do that too: > It can be assumed that default free routing table is small. Yes, I agree completely. The default free routing table must have one route: a default route. See how frustrating that is? On Fri, Dec 30, 2011 at 4:49 AM, Masataka Ohta wrote: > Ray Soucy wrote: > >> But that is only the case if you let customers have a PI prefix (which >> I think is really required in a purist end-to-end model, but for the >> sake of argument...). > > > Multihoming by routing, by the intermediate systems, is against > the end to end principle, which is why it does not scale. > > >> The remote host would >> have no knowledge of other available prefixes > > > As IP layer is connectionless, let transport or application > layer carry the information on the prefixes to try to keep > connections. > > >> (even if there is a path >> >> change, and a different path becomes favorable). > > > The remote host can use IGP metric to know the initial best > candidate and subsequent path changes. > > It can be assumed that default free routing table is small. > > In addition, the remote host may also use transport/application > layer timeout to try other prefixes. > > >> The result is still a very large amount of overhead. You will still >> experience significant change propagation delay (slower than change >> propagation under the current model > > > Not at all. > > Transport/application timeout is no different. > > Route propagation is no slower. Instead, smaller default free > routing table means more rapid convergence. > > >> This all would be significantly more complex than IPv6 > > > It was IPv6 which was expected to support multiple addresses > to suppress routing table growth. The result is a complex > protocol with halfhearted support for multiple addresses. > > >> We now know that it takes well over a decade for >> people to move to a protocol, even when it is almost operationally >> identical to its predecessor. > > > Unlike IPv4, IPv6 is poorly operational and still needs protocol > modifications, > > For example, multicast PMTUD causes ICMP implosion, which means > rational operators filter ICMP packet too big often including > those against unicast packets, which means PMTUD won't work. > > Yes, fixing it requires more than a decade. > > Then, it may be a good idea to obsolete SLAAC, which means > IPv6 address can be only 8B long. You know, remembering 16B > addresses is divine, which is an operational head ache. > > >> To be frank, you would have to build a completely new and >> parallel network and hope you could somehow convince people to adopt >> it > > > Multihoming with multiple addresses works at transport/application > layer over existing IPv4 and IPv6. > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Masataka Ohta > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From rps at maine.edu Fri Dec 30 06:24:51 2011 From: rps at maine.edu (Ray Soucy) Date: Fri, 30 Dec 2011 07:24:51 -0500 Subject: next-best-transport! down with ethernet! In-Reply-To: References: <1325188667.2646.4.camel@teh-desktop> Message-ID: What we really need is a new method of sending data. The fact that I will never be able to send something from Maine to California in less than 15 ms is not acceptable. The speed of light is such a drag. On Fri, Dec 30, 2011 at 6:01 AM, Tei wrote: > I am php/javascript programmer. > > The web used to be request/reply. With the request small (but not > small enough), and the reply long. > But the time for permanent connections is comming. ?Links from clients > to server that are permanent. ?Or look like that in the application > layer. > > On one sense, this is a optimization, no more pooling the server "do > you have something for me?" every n seconds. ?But I imagine mostly > make things like caching and proxies pointless. > > At some point, users will start getting unhappy with web pages replies > slower than 100 ms. ? ATM my webpages takes longer to start Jquery > that all the server-client interactions. Most obvious optimization is > never reload the page, and run everything trough ajax calls. > > I am not dumb, ?I know turning webpages into applications make > webpages to fragile. But I am scared of javascripts. Javascript is > just too dawmn usefull now, browsers too broken (mostly IE), and > Javascript is like a superhero that fix all. ? The web is going to > change in a few years, from a "request" "reply" interchange network, > to something more like a computer "bus". ? ?I don't know how the > "wires" will react to this. > > > > On 30 December 2011 10:58, Vitkovsky, Adam wrote: >> Actually an a Cisco presentation on Nexus 7k I asked whether it's possible to transport the FCoE over let's say EoMPLS or VPLS and did not get a straight answer though that was half a year ago >> -but it would be really cool to connect hard-drives directly over continents >> >> >> adam >> >> -----Original Message----- >> From: Tom Hill [mailto:tom at ninjabadger.net] >> Sent: Thursday, December 29, 2011 8:58 PM >> To: nanog at nanog.org >> Subject: Re: next-best-transport! down with ethernet! >> >> On Thu, 2011-12-29 at 10:06 -0500, Christopher Morrow wrote: >>> yes, let's get something with say fixed sized packets, ability to have >>> predictable jitter and also, for fun, no more STP! >>> Ethernet is too complex, maybe something simpler? I hear there's this >>> new tech 'ATM'? it seems to fit the bill! >> >> Pfft. Everyone knows that Fibre Channel's going to replace everything... >> The minute we get those 128Gbit/sec transmission characteristics, >> Ethernet's gonna be as good as RS-485. >> >> >> >> >> > > > > -- > -- > ?in del ?ensaje. > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From avitkovsky at emea.att.com Fri Dec 30 07:00:16 2011 From: avitkovsky at emea.att.com (Vitkovsky, Adam) Date: Fri, 30 Dec 2011 14:00:16 +0100 Subject: next-best-transport! down with ethernet! In-Reply-To: References: <1325188667.2646.4.camel@teh-desktop> Message-ID: Well hopefully we won't need to worry about the speed of light anymore Just recently I heard about the experiments with "quantum nonlocality" no one seem to understand how it happens but for me it's enough it works Basically when 2 photons or electrons are emitted form the same source -they are somehow bound/entangled together -that means if we change the spin on one photon to "up" the other photon will have it's spin changed to "down" immediately -and it doesn't matter whether the photons are next to each other or light years away -this happens instantly (no energy is transferred yet the information is passed) -this was already tested between two cities Imagine that instead of sfp connectors and dark fiber between San Fran and NY node we'd install a connectors with let's say 1500k entangled photons -and if we set the spin in a way to send a 1500kbit packet to NY the NY node would see it instantly -no cables needed -also there some attempts to actually send the information 50 micro sec back in time Of course there are still these issues with probabilities at quantum level adam >What we really need is a new method of sending data. The fact that I >will never be able to send something from Maine to California in less >than 15 ms is not acceptable. >The speed of light is such a drag. From rps at maine.edu Fri Dec 30 07:04:00 2011 From: rps at maine.edu (Ray Soucy) Date: Fri, 30 Dec 2011 08:04:00 -0500 Subject: next-best-transport! down with ethernet! In-Reply-To: References: <1325188667.2646.4.camel@teh-desktop> Message-ID: Are you telling me that the 1,100 miles of fiber I just had run is already obsolete? Someone is going to get fired over this. On Fri, Dec 30, 2011 at 8:00 AM, Vitkovsky, Adam wrote: > Well hopefully we won't need to worry about the speed of light anymore > > Just recently I heard about the experiments with "quantum nonlocality" > no one seem to understand how it happens but for me it's enough it works > > Basically when 2 photons or electrons are emitted form the same source -they are somehow bound/entangled together -that means if we change the spin on one photon to "up" the other photon will have it's spin changed to "down" immediately > -and it doesn't matter whether the photons are next to each other or light years away -this happens instantly (no energy is transferred yet the information is passed) > -this was already tested between two cities > > Imagine that instead of sfp connectors and dark fiber between San Fran and NY node we'd install a connectors with let's say 1500k entangled photons > -and if we set the spin in a way to send a 1500kbit packet to NY the NY node would see it instantly -no cables needed > > -also there some attempts to actually send the information 50 micro sec back in time > > Of course there are still these issues with probabilities at quantum level > > > adam >>What we really need is a new method of sending data. ?The fact that I >>will never be able to send something from Maine to California in less >>than 15 ms is not acceptable. > >>The speed of light is such a drag. > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From aiden at sullivan.in Fri Dec 30 07:09:09 2011 From: aiden at sullivan.in (Aiden Sullivan) Date: Fri, 30 Dec 2011 05:09:09 -0800 Subject: next-best-transport! down with ethernet! In-Reply-To: References: <1325188667.2646.4.camel@teh-desktop> Message-ID: <20111230130909.GB91@hothead.caltech.edu> http://en.wikipedia.org/wiki/No-communication_theorem -- Aiden On Dec 30 14:00, Vitkovsky, Adam wrote: > Well hopefully we won't need to worry about the speed of light anymore > > Just recently I heard about the experiments with "quantum nonlocality" > no one seem to understand how it happens but for me it's enough it works > > Basically when 2 photons or electrons are emitted form the same source -they are somehow bound/entangled together -that means if we change the spin on one photon to "up" the other photon will have it's spin changed to "down" immediately > -and it doesn't matter whether the photons are next to each other or light years away -this happens instantly (no energy is transferred yet the information is passed) > -this was already tested between two cities > > Imagine that instead of sfp connectors and dark fiber between San Fran and NY node we'd install a connectors with let's say 1500k entangled photons > -and if we set the spin in a way to send a 1500kbit packet to NY the NY node would see it instantly -no cables needed > > -also there some attempts to actually send the information 50 micro sec back in time > > Of course there are still these issues with probabilities at quantum level > > > adam > >What we really need is a new method of sending data. The fact that I > >will never be able to send something from Maine to California in less > >than 15 ms is not acceptable. > > >The speed of light is such a drag. > > > From a.harrowell at gmail.com Fri Dec 30 08:15:15 2011 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Fri, 30 Dec 2011 14:15:15 +0000 Subject: L3 consequences of WLAN offload in cellular networks (was - endless DHCPv6 thread) Message-ID: <201112301415.32955.a.harrowell@gmail.com> In the DHCP v6 thread, there was some discussion of mobility and its IP layer consequences. As various people pointed out, cellular networks basically handle this in the RAN (Radio Access Network) and therefore at layer 2, transparently (well, as much as things ever are) for IP purposes. It therefore shouldn't be a problem. However, as one contributor pointed out, more and more cellular operators are migrating traffic onto WLAN for various reasons, notably: 1) Spectrum - it's unlicensed, i.e. free 2) Capex - the equipment is cheaper 3) Capacity - it's a cheap way of providing high speed 4) Signalling load - it gets rid of the signalling traffic associated with detaching and attaching devices from the core network. This is especially important in view of some smartphones' behaviour. Of course much of the signalling is associated with the Mobility Management features, and getting rid of it by punting everything to WLAN implies that you lose the benefits of this. That suggests that if you're going to do this on a big scale you need to implement Mobile IP or else keep backhauling traffic from the WLAN access points to the cellular core network (GAN/Iu interface), which has obvious effects on the economics of the whole idea. Alternatively, you can work on the assumption that the WLAN is solely for nomadic use rather than true mobility, but a lot of devices will prefer the WLAN whenever possible. Thoughts/experiences? -- The only thing worse than e-mail disclaimers...is people who send e-mail to lists complaining about them -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From cb.list6 at gmail.com Fri Dec 30 08:34:32 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Fri, 30 Dec 2011 06:34:32 -0800 Subject: L3 consequences of WLAN offload in cellular networks (was - endless DHCPv6 thread) In-Reply-To: <201112301415.32955.a.harrowell@gmail.com> References: <201112301415.32955.a.harrowell@gmail.com> Message-ID: On Dec 30, 2011 9:16 AM, "Alexander Harrowell" wrote: > > In the DHCP v6 thread, there was some discussion of > mobility and its IP layer consequences. As various people > pointed out, cellular networks basically handle this in the > RAN (Radio Access Network) and therefore at layer 2, > transparently (well, as much as things ever are) for IP > purposes. It therefore shouldn't be a problem. > > However, as one contributor pointed out, more and more > cellular operators are migrating traffic onto WLAN for > various reasons, notably: > > 1) Spectrum - it's unlicensed, i.e. free > 2) Capex - the equipment is cheaper > 3) Capacity - it's a cheap way of providing high speed > 4) Signalling load - it gets rid of the signalling traffic > associated with detaching and attaching devices from the > core network. This is especially important in view of some > smartphones' behaviour. > > Of course much of the signalling is associated with the > Mobility Management features, and getting rid of it by > punting everything to WLAN implies that you lose the > benefits of this. > > That suggests that if you're going to do this on a big > scale you need to implement Mobile IP or else keep > backhauling traffic from the WLAN access points to the > cellular core network (GAN/Iu interface), which has obvious > effects on the economics of the whole idea. > > Alternatively, you can work on the assumption that the WLAN > is solely for nomadic use rather than true mobility, but a > lot of devices will prefer the WLAN whenever possible. > > Thoughts/experiences? > > The state of the industry is the support of nomadic mobility from cellular to / from Wi-Fi , there is nearly no support of mobile IP that I have seen. It is going more and more in this direction. At T-Mobile USA we have evolved our wifi calling features from fully mobile UMA / GAN to non-mobile IMS wifi calling. Cb > > -- > The only thing worse than e-mail disclaimers...is people > who send e-mail to lists complaining about them On Dec 30, 2011 9:16 AM, "Alexander Harrowell" wrote: > In the DHCP v6 thread, there was some discussion of > mobility and its IP layer consequences. As various people > pointed out, cellular networks basically handle this in the > RAN (Radio Access Network) and therefore at layer 2, > transparently (well, as much as things ever are) for IP > purposes. It therefore shouldn't be a problem. > > However, as one contributor pointed out, more and more > cellular operators are migrating traffic onto WLAN for > various reasons, notably: > > 1) Spectrum - it's unlicensed, i.e. free > 2) Capex - the equipment is cheaper > 3) Capacity - it's a cheap way of providing high speed > 4) Signalling load - it gets rid of the signalling traffic > associated with detaching and attaching devices from the > core network. This is especially important in view of some > smartphones' behaviour. > > Of course much of the signalling is associated with the > Mobility Management features, and getting rid of it by > punting everything to WLAN implies that you lose the > benefits of this. > > That suggests that if you're going to do this on a big > scale you need to implement Mobile IP or else keep > backhauling traffic from the WLAN access points to the > cellular core network (GAN/Iu interface), which has obvious > effects on the economics of the whole idea. > > Alternatively, you can work on the assumption that the WLAN > is solely for nomadic use rather than true mobility, but a > lot of devices will prefer the WLAN whenever possible. > > Thoughts/experiences? > > > > -- > The only thing worse than e-mail disclaimers...is people > who send e-mail to lists complaining about them > From avitkovsky at emea.att.com Fri Dec 30 08:55:25 2011 From: avitkovsky at emea.att.com (Vitkovsky, Adam) Date: Fri, 30 Dec 2011 15:55:25 +0100 Subject: next-best-transport! down with ethernet! In-Reply-To: <20111230130909.GB91@hothead.caltech.edu> References: <1325188667.2646.4.camel@teh-desktop> <20111230130909.GB91@hothead.caltech.edu> Message-ID: Article by John Cramer says: At the AQRTP Workshop we considered the question of whether quantum nonlocality was a possible medium for FTL communication. In the context of standard quantum mechanics there is good reason for believing that it is not. Eberhard has proved a theorem demonstrating that the outcomes of separated measurements of the same quantum system, correlated by nonlocality though they are, cannot be used for FTL observer-to-observer communication. A possible loophole in Eberhard's theorem could arise if, following the work of Nobel Laureate Steven Weinberg, one modifies conventional quantum mechanics by introducing a small non-linear element into the standard QM formalism. It has been shown that in slightly non-linear quantum mechanics, the observable nonlinear effects that would arise would make possible FTL communication through nonlocality. The only possibility seem to be modificaiton to QM equations So fingers crossed :) adam -----Original Message----- From: Aiden Sullivan [mailto:aiden at sullivan.in] Sent: Friday, December 30, 2011 2:09 PM To: Vitkovsky, Adam Cc: Ray Soucy; Tei; nanog at nanog.org Subject: Re: next-best-transport! down with ethernet! http://en.wikipedia.org/wiki/No-communication_theorem -- Aiden On Dec 30 14:00, Vitkovsky, Adam wrote: > Well hopefully we won't need to worry about the speed of light anymore > > Just recently I heard about the experiments with "quantum nonlocality" > no one seem to understand how it happens but for me it's enough it works > > Basically when 2 photons or electrons are emitted form the same source -they are somehow bound/entangled together -that means if we change the spin on one photon to "up" the other photon will have it's spin changed to "down" immediately > -and it doesn't matter whether the photons are next to each other or light years away -this happens instantly (no energy is transferred yet the information is passed) > -this was already tested between two cities > > Imagine that instead of sfp connectors and dark fiber between San Fran and NY node we'd install a connectors with let's say 1500k entangled photons > -and if we set the spin in a way to send a 1500kbit packet to NY the NY node would see it instantly -no cables needed > > -also there some attempts to actually send the information 50 micro sec back in time > > Of course there are still these issues with probabilities at quantum level > > > adam > >What we really need is a new method of sending data. The fact that I > >will never be able to send something from Maine to California in less > >than 15 ms is not acceptable. > > >The speed of light is such a drag. > > > From jra at baylink.com Fri Dec 30 08:59:35 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 30 Dec 2011 09:59:35 -0500 (EST) Subject: next-best-transport! down with ethernet! In-Reply-To: Message-ID: <21777635.2558.1325257175245.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Adam Vitkovsky" > Article by John Cramer says: > > At the AQRTP Workshop we considered the question of whether quantum > nonlocality was a possible medium for FTL communication. In the > context of standard quantum mechanics there is good reason for > believing that it is not. Eberhard has proved a theorem demonstrating > that the outcomes of separated measurements of the same quantum > system, correlated by nonlocality though they are, cannot be used for > FTL observer-to-observer communication. A possible loophole in > Eberhard's theorem could arise if, following the work of Nobel > Laureate Steven Weinberg, one modifies conventional quantum mechanics > by introducing a small non-linear element into the standard QM > formalism. It has been shown that in slightly non-linear quantum > mechanics, the observable nonlinear effects that would arise would > make possible FTL communication through nonlocality. Wasn't this covered in an RFC I read, dated 1 April 2030? 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 http://photo.imageinc.us +1 727 647 1274 From jared at puck.nether.net Fri Dec 30 09:18:50 2011 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 30 Dec 2011 10:18:50 -0500 Subject: next-best-transport! down with ethernet! In-Reply-To: References: <1325188667.2646.4.camel@teh-desktop> Message-ID: <075202C7-F1CC-417D-AD46-E54FA6C59E55@puck.nether.net> On Dec 30, 2011, at 6:01 AM, Tei wrote: > I am not dumb, I know turning webpages into applications make > webpages to fragile. But I am scared of javascripts. Javascript is > just too dawmn usefull now, browsers too broken (mostly IE), and > Javascript is like a superhero that fix all. The web is going to > change in a few years, from a "request" "reply" interchange network, > to something more like a computer "bus". I don't know how the > "wires" will react to this. I think the challenge here is going to be the unintended interactions of the subsystems involved. Take a look at the buffer bloat research and activities. I think getting a better symmetric speed ratio to the edge will help solve this problem. Just because you have 22:5 capability at home, or 50:10 (5:1) doesn't mean it will be used that way, but being closer to 2:1 will likely cause some significant improvements in performance. The internet as the transport over the top of the physical {fiber,copper,coax} is going to continue to grow. The folks at NTT just announced their 60th 10G across the pacific. With the continued growth here and 100G out there, handling the traffic will certainly become interesting. I think the dark buffers are going to be the biggest challenge we see. (I'm hoping for some good snow storms in the midwest/north east/NoVA area to put some good stresses on the network for a week or so this winter that can be measured/observed). - Jared From rdobbins at arbor.net Fri Dec 30 09:38:19 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 30 Dec 2011 15:38:19 +0000 Subject: L3 consequences of WLAN offload in cellular networks (was - endless DHCPv6 thread) In-Reply-To: References: <201112301415.32955.a.harrowell@gmail.com> Message-ID: <3CF2FD0B-474F-4D9D-ACD2-C941F7DA3B2B@arbor.net> On Dec 30, 2011, at 9:34 PM, Cameron Byrne wrote: > The state of the industry is the support of nomadic mobility from cellular to / from Wi-Fi , there is nearly no support of mobile IP that I have seen. Concur. This .pdf preso may also be of interest: ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From thegameiam at yahoo.com Fri Dec 30 09:44:16 2011 From: thegameiam at yahoo.com (David Barak) Date: Fri, 30 Dec 2011 07:44:16 -0800 (PST) Subject: next-best-transport! down with ethernet! In-Reply-To: <075202C7-F1CC-417D-AD46-E54FA6C59E55@puck.nether.net> References: <1325188667.2646.4.camel@teh-desktop> <075202C7-F1CC-417D-AD46-E54FA6C59E55@puck.nether.net> Message-ID: <1325259856.95479.YahooMailNeo@web31803.mail.mud.yahoo.com> >From: Jared Mauch >(I'm hoping for some good snow storms in the midwest/north east/NoVA area to put some good stresses on the network for a week or so this winter that can be measured/observed). In DC and NoVA, the network which is most taxed by snow storms is the transportation network.? That's probably the one time when you really *can* overestimate the bandwidth of a station wagon full of hard drives... David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com From tal at whatexit.org Fri Dec 30 10:44:21 2011 From: tal at whatexit.org (Tom Limoncelli) Date: Fri, 30 Dec 2011 11:44:21 -0500 Subject: next-best-transport! down with ethernet! In-Reply-To: References: <1325188667.2646.4.camel@teh-desktop> Message-ID: On Fri, Dec 30, 2011 at 7:24 AM, Ray Soucy wrote: > What we really need is a new method of sending data. ?The fact that I > will never be able to send something from Maine to California in less > than 15 ms is not acceptable. > > The speed of light is such a drag. I propose that everyone on this mailing list make it their #1 New Years Resolution to fix this problem. If we all work together, we can do something about it! Tom -- http://EverythingSysadmin.com? -- my blog http://www.TomOnTime.com?-- my videos From kloch at kl.net Fri Dec 30 10:47:35 2011 From: kloch at kl.net (Kevin Loch) Date: Fri, 30 Dec 2011 11:47:35 -0500 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <7A656097-5C49-445D-BC12-17E28EA10853@cs.columbia.edu> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> <14160.1325099085@turing-police.cc.vt.edu> <4EFBD594.2000604@necom830.hpcl.titech.ac.jp> <30391.1325139437@turing-police.cc.vt.edu> <82ipkzwxhv.fsf@mid.bfk.de> <38375.1325160093@turing-police.cc.vt.edu> <4EFC62C9.9030101@necom830.hpcl.titech.ac.jp> <44691.1325175089@turing-police.cc.vt.edu> <4EFCE9F8.2040604@necom830.hpcl.titech.ac.jp> <7A656097-5C49-445D-BC12-17E28EA10853@cs.columbia.edu> Message-ID: <4EFDEB27.5090503@kl.net> Steven Bellovin wrote: > VRRP? The Router Discovery Protocol (RFC 1256). But given > how much more reliable routers are today than in 1984, I'm > not convinced it's that necessary these days. VRRP is an absolutely essential protocol in today's Internet. We use it on every non-bgp customer port. Routers still have routing and performance issues, hardware failures and routine software upgrades. The layer2 infrastructure between the routers and the customer is also susceptible to various hardware/software/maintenance problems and fiber cuts and VRRP can help work around some of those. A nice side benefit is the virtual mac addresses that allow for migration to new routers without the mac address of the default gateway changing. One key advantage of VRRP over RA's is that you can have multiple instances on the same layer2 network (vlan) with different functions. It is very common to have different "routers" (routers, firewalls or load balancers) on the same vlan with different functions in hosting environments. It is also sometimes necessary to have multiple default gateways on the same vlan for load balancing or traffic engineering. RA/auto configuration is incompatible with all but the most trivial configurations. - Kevin From rps at maine.edu Fri Dec 30 12:39:38 2011 From: rps at maine.edu (Ray Soucy) Date: Fri, 30 Dec 2011 13:39:38 -0500 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EFDEB27.5090503@kl.net> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> <14160.1325099085@turing-police.cc.vt.edu> <4EFBD594.2000604@necom830.hpcl.titech.ac.jp> <30391.1325139437@turing-police.cc.vt.edu> <82ipkzwxhv.fsf@mid.bfk.de> <38375.1325160093@turing-police.cc.vt.edu> <4EFC62C9.9030101@necom830.hpcl.titech.ac.jp> <44691.1325175089@turing-police.cc.vt.edu> <4EFCE9F8.2040604@necom830.hpcl.titech.ac.jp> <7A656097-5C49-445D-BC12-17E28EA10853@cs.columbia.edu> <4EFDEB27.5090503@kl.net> Message-ID: VRRP is still useful, and for those who find it useful it has been extended to IPv6 [RFC5798]. Vendors, such as Cisco, have already begun shipping functional implementations as well it would seem. There are certainly pieces of IPv6 that will need refinement (and we will likely see that happen over time, after it is dominant). Mobility and IPsec, for example, were touted as big benefits of IPv6, but they didn't end up being that important (or useful) in their current state. The ability to have multiple prefixes from different routers, and a failover mechanism was really a pre-NAT and pre-VRRP idea. It's not the common deployment that it was envisioned to be, and our expectations of how fast these things happen has become a lot higher. Still, minor extensions could be made to these standard to achieve a lot of the desired behavior, so I haven't given up on it all completely. It's hard to predict the future, and it's been over a decade since the design for IPv6 was solidified and began to be implemented. Let's not forget that what we call "Ethernet" today is very different from Bob Metcalfe's Ethernet. On Fri, Dec 30, 2011 at 11:47 AM, Kevin Loch wrote: > Steven Bellovin wrote: > >> VRRP? ?The Router Discovery Protocol (RFC 1256). ?But given >> how much more reliable routers are today than in 1984, I'm >> not convinced it's that necessary these days. > > > VRRP is an absolutely essential protocol in today's Internet. ?We use > it on every non-bgp customer port. ?Routers still have routing and > performance issues, hardware failures and routine software upgrades. > The layer2 infrastructure between the routers and the customer is also > susceptible to various hardware/software/maintenance problems and fiber > cuts and VRRP can help work around some of those. ?A nice side benefit > is the virtual mac addresses that allow for migration to new routers > without the mac address of the default gateway changing. > > One key advantage of VRRP over RA's is that you can have multiple > instances on the same layer2 network (vlan) with different functions. > > It is very common to have different "routers" (routers, firewalls or > load balancers) on the same vlan with different functions in hosting > environments. ?It is also sometimes necessary to have multiple default > gateways on the same vlan for load balancing or traffic engineering. > RA/auto configuration is incompatible with all but the most trivial > configurations. > > - Kevin > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From tvarriale at comcast.net Fri Dec 30 12:58:16 2011 From: tvarriale at comcast.net (Tony Varriale) Date: Fri, 30 Dec 2011 12:58:16 -0600 Subject: next-best-transport! down with ethernet! In-Reply-To: References: Message-ID: <4EFE09C8.8020505@comcast.net> On 12/29/2011 9:06 AM, Christopher Morrow wrote: > (you forgot to change subj:) > > On Thu, Dec 29, 2011 at 7:59 AM, Cameron Byrne wrote: >> Next topic, ethernet is too chaotic and inefficient to deploy and support >> mission critical applications in LAN or WAN or data center. > yes, let's get something with say fixed sized packets, ability to have > predictable jitter and also, for fun, no more STP! > Ethernet is too complex, maybe something simpler? I hear there's this > new tech 'ATM'? it seems to fit the bill! > > :) > (Happy new year almost) > > I just came up with a new way implement ATM on the LAN so we can all get along. It's called LANE. Oh wait... tv From cscora at apnic.net Fri Dec 30 13:24:54 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 31 Dec 2011 05:24:54 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201112301924.pBUJOsR5008832@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 31 Dec, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 388032 Prefixes after maximum aggregation: 168367 Deaggregation factor: 2.30 Unique aggregates announced to Internet: 190083 Total ASes present in the Internet Routing Table: 39705 Prefixes per ASN: 9.77 Origin-only ASes present in the Internet Routing Table: 32554 Origin ASes announcing only one prefix: 15514 Transit ASes present in the Internet Routing Table: 5351 Transit-only ASes present in the Internet Routing Table: 137 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 33 Max AS path prepend of ASN (56677) 25 Prefixes from unregistered ASNs in the Routing Table: 1999 Unregistered ASNs in the Routing Table: 1030 Number of 32-bit ASNs allocated by the RIRs: 2144 Number of 32-bit ASNs visible in the Routing Table: 1800 Prefixes from 32-bit ASNs in the Routing Table: 4327 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 112 Number of addresses announced to Internet: 2504923696 Equivalent to 149 /8s, 78 /16s and 26 /24s Percentage of available address space announced: 67.6 Percentage of allocated address space announced: 67.6 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 91.8 Total number of prefixes smaller than registry allocations: 164463 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 95928 Total APNIC prefixes after maximum aggregation: 31403 APNIC Deaggregation factor: 3.05 Prefixes being announced from the APNIC address blocks: 92286 Unique aggregates announced from the APNIC address blocks: 38721 APNIC Region origin ASes present in the Internet Routing Table: 4619 APNIC Prefixes per ASN: 19.98 APNIC Region origin ASes announcing only one prefix: 1249 APNIC Region transit ASes present in the Internet Routing Table: 729 Average APNIC Region AS path length visible: 4.3 Max APNIC Region AS path length visible: 18 Number of APNIC region 32-bit ASNs visible in the Routing Table: 125 Number of APNIC addresses announced to Internet: 632494720 Equivalent to 37 /8s, 179 /16s and 26 /24s Percentage of available APNIC address space announced: 80.2 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-132095, 132096-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, 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: 146775 Total ARIN prefixes after maximum aggregation: 74964 ARIN Deaggregation factor: 1.96 Prefixes being announced from the ARIN address blocks: 118927 Unique aggregates announced from the ARIN address blocks: 48922 ARIN Region origin ASes present in the Internet Routing Table: 14816 ARIN Prefixes per ASN: 8.03 ARIN Region origin ASes announcing only one prefix: 5673 ARIN Region transit ASes present in the Internet Routing Table: 1573 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 25 Number of ARIN region 32-bit ASNs visible in the Routing Table: 14 Number of ARIN addresses announced to Internet: 804638400 Equivalent to 47 /8s, 245 /16s and 206 /24s Percentage of available ARIN address space announced: 63.9 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 95203 Total RIPE prefixes after maximum aggregation: 51822 RIPE Deaggregation factor: 1.84 Prefixes being announced from the RIPE address blocks: 87230 Unique aggregates announced from the RIPE address blocks: 55392 RIPE Region origin ASes present in the Internet Routing Table: 16223 RIPE Prefixes per ASN: 5.38 RIPE Region origin ASes announcing only one prefix: 7980 RIPE Region transit ASes present in the Internet Routing Table: 2576 Average RIPE Region AS path length visible: 4.7 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1256 Number of RIPE addresses announced to Internet: 495420104 Equivalent to 29 /8s, 135 /16s and 130 /24s Percentage of available RIPE address space announced: 79.8 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 37048 Total LACNIC prefixes after maximum aggregation: 8031 LACNIC Deaggregation factor: 4.61 Prefixes being announced from the LACNIC address blocks: 36595 Unique aggregates announced from the LACNIC address blocks: 19051 LACNIC Region origin ASes present in the Internet Routing Table: 1561 LACNIC Prefixes per ASN: 23.44 LACNIC Region origin ASes announcing only one prefix: 452 LACNIC Region transit ASes present in the Internet Routing Table: 285 Average LACNIC Region AS path length visible: 4.5 Max LACNIC Region AS path length visible: 24 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 401 Number of LACNIC addresses announced to Internet: 95159432 Equivalent to 5 /8s, 172 /16s and 4 /24s Percentage of available LACNIC address space announced: 63.0 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 8588 Total AfriNIC prefixes after maximum aggregation: 2072 AfriNIC Deaggregation factor: 4.14 Prefixes being announced from the AfriNIC address blocks: 6623 Unique aggregates announced from the AfriNIC address blocks: 2091 AfriNIC Region origin ASes present in the Internet Routing Table: 504 AfriNIC Prefixes per ASN: 13.14 AfriNIC Region origin ASes announcing only one prefix: 160 AfriNIC Region transit ASes present in the Internet Routing Table: 112 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 4 Number of AfriNIC addresses announced to Internet: 30878464 Equivalent to 1 /8s, 215 /16s and 43 /24s Percentage of available AfriNIC address space announced: 46.0 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2475 11101 972 Korea Telecom (KIX) 17974 1718 503 37 PT TELEKOMUNIKASI INDONESIA 7545 1629 303 86 TPG Internet Pty Ltd 4755 1516 385 157 TATA Communications formerly 7552 1412 1064 7 Vietel Corporation 9583 1185 90 530 Sify Limited 9829 1170 989 28 BSNL National Internet Backbo 4808 1075 2034 308 CNCGROUP IP network: China169 24560 1004 383 163 Bharti Airtel Ltd., Telemedia 18101 974 131 156 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 3471 3814 220 bellsouth.net, inc. 7029 2917 1017 200 Windstream Communications Inc 18566 2094 383 177 Covad Communications 1785 1862 680 122 PaeTec Communications, Inc. 4323 1623 1065 385 Time Warner Telecom 20115 1614 1550 623 Charter Communications 22773 1517 2909 107 Cox Communications, Inc. 30036 1474 262 689 Mediacom Communications Corp 19262 1389 4683 401 Verizon Global Networks 7018 1301 7012 855 AT&T WorldNet Services 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 1547 480 15 Corbina telecom 15557 1092 2161 64 LDCOM NETWORKS 2118 672 99 14 EUnet/RELCOM Autonomous Syste 6830 642 1928 413 UPC Distribution Services 34984 637 132 199 BILISIM TELEKOM 12479 552 636 53 Uni2 Autonomous System 20940 547 176 438 Akamai Technologies European 3320 532 8162 398 Deutsche Telekom AG 3292 480 2106 407 TDC Tele Danmark 8866 465 134 27 Bulgarian Telecommunication C 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 1721 319 159 TVCABLE BOGOTA 28573 1569 1064 75 NET Servicos de Comunicao S.A 8151 1453 2981 350 UniNet S.A. de C.V. 7303 1252 755 176 Telecom Argentina Stet-France 27947 634 73 95 Telconet S.A 22047 582 322 17 VTR PUNTO NET S.A. 7738 551 1050 31 Telecomunicacoes da Bahia S.A 3816 548 237 91 Empresa Nacional de Telecomun 6503 539 434 67 AVANTEL, S.A. 11172 530 86 97 Servicios Alestra S.A de C.V Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1039 958 13 TEDATA 24863 793 146 36 LINKdotNET AS number 3741 280 939 229 The Internet Solution 6713 250 649 18 Itissalat Al-MAGHRIB 15706 242 32 6 Sudatel Internet Exchange Aut 33776 240 13 8 Starcomms Nigeria Limited 29571 216 17 13 Ci Telecom Autonomous system 12258 195 28 60 Vodacom Internet Company 24835 189 80 8 RAYA Telecom - Egypt 16637 160 664 82 MTN Network Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3471 3814 220 bellsouth.net, inc. 7029 2917 1017 200 Windstream Communications Inc 4766 2475 11101 972 Korea Telecom (KIX) 18566 2094 383 177 Covad Communications 1785 1862 680 122 PaeTec Communications, Inc. 10620 1721 319 159 TVCABLE BOGOTA 17974 1718 503 37 PT TELEKOMUNIKASI INDONESIA 7545 1629 303 86 TPG Internet Pty Ltd 4323 1623 1065 385 Time Warner Telecom 20115 1614 1550 623 Charter Communications 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 2917 2717 Windstream Communications Inc 18566 2094 1917 Covad Communications 1785 1862 1740 PaeTec Communications, Inc. 17974 1718 1681 PT TELEKOMUNIKASI INDONESIA 10620 1721 1562 TVCABLE BOGOTA 7545 1629 1543 TPG Internet Pty Ltd 8402 1547 1532 Corbina telecom 4766 2475 1503 Korea Telecom (KIX) 28573 1569 1494 NET Servicos de Comunicao S.A 22773 1517 1410 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 32873 UNALLOCATED 12.46.100.0/23 10912 InterNAP Network Ser 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.0.0/21 12654 RIPE NCC RIS Project 128.0.24.0/24 12654 RIPE NCC RIS Project 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 37.26.200.0/21 28748 AlphaCron Datensysteme AS 37.26.208.0/20 57660 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:12 /10:27 /11:81 /12:237 /13:465 /14:813 /15:1451 /16:12081 /17:6120 /18:10185 /19:20160 /20:27929 /21:28328 /22:38611 /23:35934 /24:201964 /25:1183 /26:1402 /27:779 /28:166 /29:53 /30:14 /31:0 /32:18 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 2545 2917 Windstream Communications Inc 6389 2116 3471 bellsouth.net, inc. 18566 2043 2094 Covad Communications 10620 1616 1721 TVCABLE BOGOTA 8402 1526 1547 Corbina telecom 30036 1433 1474 Mediacom Communications Corp 11492 1115 1152 Cable One 1785 1064 1862 PaeTec Communications, Inc. 7011 1051 1168 Citizens Utilities 15557 1042 1092 LDCOM NETWORKS Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:478 2:414 4:15 5:1 6:3 8:366 12:1948 13:1 14:575 15:11 16:3 17:7 20:9 23:81 24:1712 27:1127 31:770 32:67 33:2 34:2 36:4 37:10 38:791 40:114 41:3018 42:82 43:1 44:3 46:1150 47:3 49:295 50:473 52:13 55:5 56:2 57:41 58:929 59:488 60:343 61:1173 62:936 63:1969 64:4123 65:2304 66:4375 67:1986 68:1165 69:3132 70:925 71:410 72:1785 74:2644 75:431 76:319 77:933 78:871 79:494 80:1190 81:842 82:533 83:530 84:563 85:1167 86:746 87:901 88:358 89:1588 90:261 91:4382 92:532 93:1515 94:1342 95:1051 96:396 97:288 98:766 99:38 100:18 101:124 103:588 106:11 107:120 108:101 109:1424 110:676 111:830 112:432 113:509 114:593 115:702 116:864 117:719 118:899 119:1223 120:365 121:676 122:1619 123:1036 124:1330 125:1347 128:532 129:189 130:189 131:585 132:162 133:21 134:226 135:54 136:206 137:151 138:285 139:126 140:491 141:257 142:381 143:392 144:501 145:67 146:476 147:221 148:633 149:271 150:165 151:192 152:444 153:169 154:7 155:382 156:210 157:365 158:153 159:505 160:346 161:221 162:335 163:188 164:522 165:390 166:546 167:455 168:807 169:146 170:828 171:95 172:4 173:1813 174:587 175:412 176:322 177:450 178:1151 180:1210 181:43 182:677 183:264 184:424 185:1 186:1462 187:797 188:1007 189:1177 190:5339 192:5974 193:5445 194:3787 195:3182 196:1289 197:174 198:3614 199:4239 200:5567 201:1685 202:8508 203:8524 204:4341 205:2421 206:2688 207:2822 208:4016 209:3562 210:2748 211:1474 212:1955 213:1807 214:808 215:93 216:4911 217:1467 218:567 219:338 220:1253 221:560 222:324 223:267 End of report From avg at kotovnik.com Fri Dec 30 13:40:35 2011 From: avg at kotovnik.com (Vadim Antonov) Date: Fri, 30 Dec 2011 11:40:35 -0800 Subject: next-best-transport! down with ethernet! In-Reply-To: References: <1325188667.2646.4.camel@teh-desktop> Message-ID: <1325274035.16484.24.camel@kotti.kotovnik.com> On Fri, 2011-12-30 at 14:00 +0100, Vitkovsky, Adam wrote: > Well hopefully we won't need to worry about the speed of light anymore Nope. The laws of physics as currently understood prohibit sending information faster than the speed of light. (The reality of FTL neutrino thingie is still too early to tell). > Basically when 2 photons or electrons are emitted form the same source -they >are somehow bound/entangled together -that means if we change the spin >on one photon to "up" the other photon will have it's spin changed to >"down" immediately - and it doesn't matter whether the photons are next >to each other or light years away -this happens instantly (no energy is >transferred yet the information is passed) -this was already tested >between two cities That's not what happens: the entangled particles are in superposition state (i.e. they are carrying both |0> and |1> simultaneously). When the measurement on one of them is made, their common wavefunction collapses, leaving them in random specific state. I.e. if you measured one |0> the other will be |1>, or vice versa. Changing quantum state of an entangled particle to a known state will simply break entanglement (the story is more complicated, but I don't want to get into arcana). Because of that the quantum entanglement *cannot be used to transmit information* between receiving points, so this non-local action at a distance doesn't break the relativistic prohibition on FTL information transmission. However, this effect is still useful because it is a way to generate random encryption keys, which will "just happen" to be the same at both ends, hence the quantum cryptography. Anybody trying to snoop on the entangled photons in transit will cause premature wavefunction collapse which can be statistically detected (in practice sources of entanglement and phase detectors are not perfect, so quantum cryptography is not unbreakable). From joelja at bogus.com Fri Dec 30 13:42:02 2011 From: joelja at bogus.com (Joel jaeggli) Date: Fri, 30 Dec 2011 11:42:02 -0800 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EFDEB27.5090503@kl.net> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> <14160.1325099085@turing-police.cc.vt.edu> <4EFBD594.2000604@necom830.hpcl.titech.ac.jp> <30391.1325139437@turing-police.cc.vt.edu> <82ipkzwxhv.fsf@mid.bfk.de> <38375.1325160093@turing-police.cc.vt.edu> <4EFC62C9.9030101@necom830.hpcl.titech.ac.jp> <44691.1325175089@turing-police.cc.vt.edu> <4EFCE9F8.2040604@necom830.hpcl.titech.ac.jp> <7A656097-5C49-445D-BC12-17E28EA10853@cs.columbia.edu> <4EFDEB27.5090503@kl.net> Message-ID: <4EFE140A.3020604@bogus.com> On 12/30/11 08:47 , Kevin Loch wrote: > It is very common to have different "routers" (routers, firewalls or > load balancers) on the same vlan with different functions in hosting > environments. It is also sometimes necessary to have multiple default > gateways on the same vlan for load balancing or traffic engineering. > RA/auto configuration is incompatible with all but the most trivial > configurations. As someone with rather abundant experience with both vrrp6 and multiple RAs per subnet I'm going to have to disagree with your there. it's not incompatible with the all but the most trivial configurations, you're distinguishing between default and non-default behavior. much as in ipv4 I may have a distinction between statically configured hosts, hosts which have a static configuration derived from dhcp and those with a dynamically generated configuration derived from dhcp. The static configured resources can happily coexist on a network where dynamically configured devices have diffrent default behavior. > - Kevin > From Valdis.Kletnieks at vt.edu Fri Dec 30 13:52:09 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 30 Dec 2011 14:52:09 -0500 Subject: next-best-transport! down with ethernet! In-Reply-To: Your message of "Fri, 30 Dec 2011 11:40:35 PST." <1325274035.16484.24.camel@kotti.kotovnik.com> References: <1325188667.2646.4.camel@teh-desktop> <1325274035.16484.24.camel@kotti.kotovnik.com> Message-ID: <116830.1325274729@turing-police.cc.vt.edu> On Fri, 30 Dec 2011 11:40:35 PST, Vadim Antonov said: > faster than the speed of light. (The reality of FTL neutrino thingie is still > too early to tell). Especially if you actually *read* the actual journal article rather than the pop-sci interpretation of it, it basically says "our experiment had the neutrinos showing up 60ns faster than lightspeed - we can't find what we did wrong, does anybody else see what we screwed up?" - i.e. an appeal to "with enough eyeballs, all bugs are shallow". (Personally, I'm betting on a mascon somewhere in northern Italy distorting the actual path taken so the actual geodesic isn't what they thought it was..) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From iljitsch at muada.com Fri Dec 30 14:57:17 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 30 Dec 2011 21:57:17 +0100 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: <4EFC611E.70601@necom830.hpcl.titech.ac.jp> References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> <14160.1325099085@turing-police.cc.vt.edu> <4EFC611E.70601@necom830.hpcl.titech.ac.jp> Message-ID: On 29 Dec 2011, at 13:46 , Masataka Ohta wrote: > we must assume MTU of 1280B. But, as IPv6 extension headers can > be as lengthy as 1000B or 2000B, no applications are guaranteed > to work over IPv6. As IP is an unreliable datagram service, there are no guarantees, period. The presence of firewalls also removes any guarantees left in place after the previous point. From cidr-report at potaroo.net Fri Dec 30 16:00:01 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 30 Dec 2011 22:00:01 GMT Subject: BGP Update Report Message-ID: <201112302200.pBUM01L6052981@wattle.apnic.net> BGP Update Report Interval: 22-Dec-11 -to- 29-Dec-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS42116 154161 9.8% 2802.9 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 2 - AS8402 56712 3.6% 38.4 -- CORBINA-AS OJSC "Vimpelcom" 3 - AS9829 48238 3.1% 79.9 -- BSNL-NIB National Internet Backbone 4 - AS17665 46747 3.0% 615.1 -- IN2CABLE-AP AS Number of In2cable.com (India) Ltd. 5 - AS5800 27683 1.8% 96.1 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 6 - AS12479 24724 1.6% 686.8 -- UNI2-AS France Telecom Espana SA 7 - AS32528 24496 1.6% 12248.0 -- ABBOTT Abbot Labs 8 - AS7552 21085 1.3% 14.9 -- VIETEL-AS-AP Vietel Corporation 9 - AS20632 19816 1.3% 508.1 -- PETERSTAR-AS PeterStar 10 - AS24560 18722 1.2% 18.5 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 11 - AS5089 17967 1.1% 1382.1 -- NTL Virgin Media Limited 12 - AS19223 12848 0.8% 12848.0 -- NTEGRATED-SOLUTIONS - Ntegrated Solutions 13 - AS2118 11493 0.7% 17.1 -- RELCOM-AS OOO "NPO Relcom" 14 - AS34875 11283 0.7% 60.7 -- YANFES OJSC "Uralsviazinform" 15 - AS47065 10684 0.7% 381.6 -- GENI-BGPMUX - BBN Technologies Corp. - Global Environment for Network Innovations (GENI) 16 - AS39353 10361 0.7% 10361.0 -- PRINCAST-AS Gobierno del Principado de Asturias 17 - AS6072 10328 0.7% 737.7 -- UNISYS-6072 For routing issues, email hostmaster at unisys.com 18 - AS1273 9713 0.6% 186.8 -- CW Cable and Wireless Worldwide plc 19 - AS31148 9655 0.6% 23.2 -- FREENET-AS FreeNet ISP 20 - AS17639 9538 0.6% 104.8 -- COMCLARK-AS ComClark Network & Technology Corp. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS19223 12848 0.8% 12848.0 -- NTEGRATED-SOLUTIONS - Ntegrated Solutions 2 - AS32528 24496 1.6% 12248.0 -- ABBOTT Abbot Labs 3 - AS39353 10361 0.7% 10361.0 -- PRINCAST-AS Gobierno del Principado de Asturias 4 - AS10209 4859 0.3% 4859.0 -- SYNOPSYS-AS-JP-AP Japan HUB and Data Center 5 - AS17408 3265 0.2% 3265.0 -- ABOVE-AS-AP AboveNet Communications Taiwan 6 - AS27295 2942 0.2% 2942.0 -- GENICA - Genica Corporation 7 - AS42116 154161 9.8% 2802.9 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 8 - AS5089 17967 1.1% 1382.1 -- NTL Virgin Media Limited 9 - AS27458 4514 0.3% 1128.5 -- NEXTGROWTH - Next Growth, LLC 10 - AS51882 1124 0.1% 1124.0 -- GOV45-AS Government of Kurgan area 11 - AS14240 2056 0.1% 1028.0 -- PMC-AS-1 - PMC-Sierra, INC. 12 - AS53362 965 0.1% 965.0 -- MIXIT-AS - Mixit, Inc. 13 - AS22386 938 0.1% 938.0 -- SARB 14 - AS45723 805 0.1% 805.0 -- OMADATA-AS-ID Omadata Indonesia, PT 15 - AS31598 779 0.1% 779.0 -- TELECOMAX-AS TELECOMAX 16 - AS21257 1496 0.1% 748.0 -- IT-PARK-AS TOV IT-PARK 17 - AS6737 2238 0.1% 746.0 -- METAWARE-AS Valvolari S.r.l 18 - AS6072 10328 0.7% 737.7 -- UNISYS-6072 For routing issues, email hostmaster at unisys.com 19 - AS41550 2198 0.1% 732.7 -- HBUA-AS HostBizUa network 20 - AS8163 711 0.1% 711.0 -- METROTEL REDES S.A. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 84.204.132.0/24 19673 1.2% AS20632 -- PETERSTAR-AS PeterStar 2 - 67.97.156.0/24 12848 0.8% AS19223 -- NTEGRATED-SOLUTIONS - Ntegrated Solutions 3 - 130.36.34.0/24 12248 0.7% AS32528 -- ABBOTT Abbot Labs 4 - 130.36.35.0/24 12248 0.7% AS32528 -- ABBOTT Abbot Labs 5 - 88.151.16.0/22 10361 0.6% AS39353 -- PRINCAST-AS Gobierno del Principado de Asturias 6 - 62.36.252.0/22 7803 0.5% AS12479 -- UNI2-AS France Telecom Espana SA 7 - 95.78.84.0/22 6579 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 8 - 46.147.124.0/22 6562 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 9 - 95.78.88.0/22 6561 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 10 - 95.78.100.0/22 6558 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 11 - 95.78.92.0/22 6557 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 12 - 46.147.120.0/22 6554 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 13 - 46.147.108.0/22 6545 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 14 - 95.78.4.0/22 6541 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 15 - 95.78.108.0/22 6541 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 16 - 95.78.116.0/22 6525 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 17 - 176.213.100.0/22 6511 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 18 - 95.78.20.0/22 6506 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 19 - 95.78.12.0/22 6281 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 20 - 95.78.16.0/22 6278 0.4% AS42116 -- ERTH-NCHLN-AS CJSC "ER-Telecom Holding" 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 cidr-report at potaroo.net Fri Dec 30 16:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 30 Dec 2011 22:00:00 GMT Subject: The Cidr Report Message-ID: <201112302200.pBUM00bQ052976@wattle.apnic.net> This report has been generated at Fri Dec 30 21:12:17 2011 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 23-12-11 388955 227416 24-12-11 389266 227550 25-12-11 389269 227422 26-12-11 389154 227258 27-12-11 388527 227317 28-12-11 389270 227684 29-12-11 389756 227932 30-12-11 390109 227830 AS Summary 39816 Number of ASes in routing system 16743 Number of ASes announcing only one prefix 3475 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 109506048 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'). --- 30Dec11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 390175 227816 162359 41.6% All ASes AS6389 3475 219 3256 93.7% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS18566 2094 413 1681 80.3% COVAD - Covad Communications Co. AS4766 2479 994 1485 59.9% KIXS-AS-KR Korea Telecom AS7029 2958 1525 1433 48.4% WINDSTREAM - Windstream Communications Inc AS22773 1517 116 1401 92.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1513 197 1316 87.0% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS4323 1624 387 1237 76.2% TWTC - tw telecom holdings, inc. AS28573 1569 394 1175 74.9% NET Servicos de Comunicao S.A. AS1785 1865 788 1077 57.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS10620 1721 693 1028 59.7% Telmex Colombia S.A. AS7552 1412 415 997 70.6% VIETEL-AS-AP Vietel Corporation AS19262 1389 402 987 71.1% VZGNI-TRANSIT - Verizon Online LLC AS7303 1252 365 887 70.8% Telecom Argentina S.A. AS18101 976 157 819 83.9% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS8151 1455 661 794 54.6% Uninet S.A. de C.V. AS30036 1474 697 777 52.7% MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp AS8402 1492 732 760 50.9% CORBINA-AS OJSC "Vimpelcom" AS4808 1075 339 736 68.5% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS15557 1092 365 727 66.6% LDCOMNET Societe Francaise du Radiotelephone S.A AS24560 1004 282 722 71.9% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7545 1629 947 682 41.9% TPG-INTERNET-AP TPG Internet Pty Ltd AS3356 1106 459 647 58.5% LEVEL3 Level 3 Communications AS2118 672 61 611 90.9% RELCOM-AS OOO "NPO Relcom" AS17974 1718 1113 605 35.2% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS17676 677 74 603 89.1% GIGAINFRA Softbank BB Corp. AS4804 662 95 567 85.6% MPX-AS Microplex PTY LTD AS20115 1614 1061 553 34.3% CHARTER-NET-HKY-NC - Charter Communications AS3549 974 422 552 56.7% GBLX Global Crossing Ltd. AS17488 926 374 552 59.6% HATHWAY-NET-AP Hathway IP Over Cable Internet AS9498 844 294 550 65.2% BBIL-AP BHARTI Airtel Ltd. Total 44258 15041 29217 66.0% 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 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 66.129.0.0/19 AS3901 ARRAKIS - Higher Technology Services 66.175.222.0/23 AS30058 FDCSERVERS - FDCservers.net 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 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 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 80.88.10.0/24 AS33774 DJAWEB 91.234.104.0/22 AS174 COGENT Cogent/PSI 98.159.96.0/20 AS46975 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 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 Inc. 172.45.1.0/24 AS29571 CITelecom-AS 172.45.2.0/24 AS29571 CITelecom-AS 172.45.3.0/24 AS29571 CITelecom-AS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 190.104.32.0/21 AS27882 Telef?nica Celular de Bolivia S.A. 193.0.22.0/23 AS3333 RIPE-NCC-AS RIPE Network Coordination Centre 200.6.93.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.94.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.95.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.23.84.0/24 AS8151 Uninet S.A. de C.V. 200.24.73.0/24 AS26061 Equant Colombia 200.33.40.0/24 AS11172 Alestra, S. de R.L. de C.V. 200.34.0.0/20 AS6342 Instituto Tecnol?gico y de Estudios Superiores de Monterrey 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 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.9.55.0/24 AS2764 AAPT AAPT Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 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.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.160.152.0/22 AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 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.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 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 205.210.125.0/24 AS36563 TELX-DALLAS - Telx 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - KNOLOGY, Inc. 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.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.91.56.0/21 AS22241 IC2NET - IC2NET 208.91.56.0/24 AS22241 IC2NET - IC2NET 208.91.57.0/24 AS22241 IC2NET - IC2NET 208.91.58.0/24 AS22241 IC2NET - IC2NET 208.91.59.0/24 AS22241 IC2NET - IC2NET 208.91.60.0/24 AS22241 IC2NET - IC2NET 208.91.61.0/24 AS22241 IC2NET - IC2NET 208.91.62.0/24 AS22241 IC2NET - IC2NET 208.91.63.0/24 AS22241 IC2NET - IC2NET 209.133.224.0/19 AS4323 TWTC - tw telecom holdings, inc. 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 209.222.240.0/22 AS19747 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From chesteve at gmail.com Fri Dec 30 16:18:42 2011 From: chesteve at gmail.com (Christian Esteve) Date: Fri, 30 Dec 2011 20:18:42 -0200 Subject: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one? In-Reply-To: References: <1290980B-9003-4CD4-A713-A21111E877DA@delong.com> <4EF14814.2080709@bowenvale.co.nz> <4F214584-12C3-42BC-A38B-13D991B9B4A0@muada.com> <4EFB09D8.3000107@necom830.hpcl.titech.ac.jp> <4EFB11F3.1090007@necom830.hpcl.titech.ac.jp> <14160.1325099085@turing-police.cc.vt.edu> <4EFC611E.70601@necom830.hpcl.titech.ac.jp> Message-ID: > Multihoming with multiple addresses works at transport/application layer over existing IPv4 and IPv6. May be there is some light with Multipath TCP: http://www.ietf.org/proceedings/75/slides/mptcp-0.pdf http://datatracker.ietf.org/wg/mptcp/charter/ If you can live without UDP and other issues discussed in this bizarre discussion... -Christian -- Christian Esteve Rothenberg, Ph.D. Converged Networks Division (DRC) Tel.:+55 19-3705-4479 / Cel.: +55 19-8193-7087 esteve at cpqd.com.br www.cpqd.com.br From bonomi at mail.r-bonomi.com Fri Dec 30 17:39:33 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Fri, 30 Dec 2011 17:39:33 -0600 (CST) Subject: next-best-transport! down with ethernet! In-Reply-To: Message-ID: <201112302339.pBUNdXNh077085@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Fri Dec 30 07:03:54 2011 > From: "Vitkovsky, Adam" > To: Ray Soucy , Tei > Date: Fri, 30 Dec 2011 14:00:16 +0100 > Subject: RE: next-best-transport! down with ethernet! > Cc: "nanog at nanog.org" > > Well hopefully we won't need to worry about the speed of light anymore > > Just recently I heard about the experiments with "quantum nonlocality" > no one seem to understand how it happens but for me it's enough it works > > Basically when 2 photons or electrons are emitted form the same source -they are somehow bound/entangled together -that means if we change the spin on one photon to "up" the other photon will have it's spin changed to "down" immediately > -and it doesn't matter whether the photons are next to each other or light years away -this happens instantly (no energy is transferred yet the information is passed) > -this was already tested between two cities > > Imagine that instead of sfp connectors and dark fiber between San Fran and NY node we'd install a connectors with let's say 1500k entangled photons > -and if we set the spin in a way to send a 1500kbit packet to NY the NY node would see it instantly -no cables needed > > -also there some attempts to actually send the information 50 micro sec back in time > > Of course there are still these issues with probabilities at quantum level I *strongy* recommend that anyone pursuing this subject read Dr. Asimov's essays on resublimated thiotimoline. From jra at baylink.com Fri Dec 30 17:39:31 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 30 Dec 2011 18:39:31 -0500 (EST) Subject: next-best-transport! down with ethernet! In-Reply-To: <201112302339.pBUNdXNh077085@mail.r-bonomi.com> Message-ID: <27961862.2658.1325288371654.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Robert Bonomi" > > Of course there are still these issues with probabilities at quantum > > level > > I *strongy* recommend that anyone pursuing this subject read Dr. > Asimov's essays on resublimated thiotimoline. As well as Spider Robinson's codicil... 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 http://photo.imageinc.us +1 727 647 1274 From joe at nethead.com Fri Dec 30 19:10:26 2011 From: joe at nethead.com (Joe Hamelin) Date: Fri, 30 Dec 2011 17:10:26 -0800 Subject: next-best-transport! down with ethernet! In-Reply-To: <201112302339.pBUNdXNh077085@mail.r-bonomi.com> References: <201112302339.pBUNdXNh077085@mail.r-bonomi.com> Message-ID: > From: "Vitkovsky, Adam" > -also there some attempts to actually send the information 50 micro sec back in time Please don't let the high-frequency stock traders get a hold of this. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From carlos at race.com Sat Dec 31 02:54:15 2011 From: carlos at race.com (Carlos Alcantar) Date: Sat, 31 Dec 2011 08:54:15 +0000 Subject: Windows UDP packet generator software? In-Reply-To: <4EF3BC23.9040603@nac.net> Message-ID: +1 on iperf there is also jperf gui for the people that don't like iperf cli. http://code.google.com/p/xjperf/ Carlos Alcantar Race Communications / Race Team Member 101 Haskins Way, So. San Francisco, CA. 94080 Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com -----Original Message----- From: Ryan Pavely Date: Thu, 22 Dec 2011 18:24:19 -0500 To: "nanog at nanog.org" Subject: Re: Windows UDP packet generator software? If anyone needs a per-compiled iPerf.exe, no need for cygwin libraries, lemme know. It's a great tool! Ryan Pavely Director Research And Development Net Access Corporation http://www.nac.net/ On 12/22/2011 3:20 PM, Larry Blunk wrote: > On 12/22/2011 02:36 PM, Sean Harlow wrote: >> iperf might be able to do what you need and there are Windows builds >> available, but I'm not sure if it has a mode where it's not flooding >> the network trying to test maximum speed. Is there a reason that >> standard ICMP pings aren't appropriate if you just want packet loss >> info? Obviously every platform worth using has ping built in. >> ---------- >> Sean Harlow >> sean at seanharlow.info > > > In UDP mode, iperf sends at 1 Mbps by default. You change > the rate with the -b flag. There's an iperf-2.0.5-cygwin > build floating around for Windows.