Re: LAw Enforcement Contact
Depends where they are located. I found Europol and the NHTCU somewhat helpful (but slow) to deal with some botnets controlled in Macedonia and Latvia. NHTCU were contacted because of the location of one of the attacked hosts. -- Sent from my smart phone. Please excuse my brevity On Jan 23, 2012 1:17 a.m., A. Pishdadi apishd...@gmail.com wrote: Hello, We recently tracked down a botnet that attacked our network. We found the CC server, it has approximately 40-50 servers, consisting of mostly *nix machines with high speed connections, for example AWS servers or dedicated, attack capacity is 4-5Gb/s or more. Is there any contacts with law enforcement here that I can send over the info too? .
Re: VZ FiOS DNS issues:
Christopher Morrow morrowc.li...@gmail.com writes: On Sun, Jan 22, 2012 at 11:29 AM, Brandon Kim brandon@brandontek.com wrote: I have FIOS and I have no issues. However I do know awhile back they had issues and I was affected by the outage Maybe it hasn't made its way to me yet there have been instances over the time i've been a fios customer that 'upgrades' to devices in the field have caused this problem (last was ~2wks ago? in the washington, dc area). Could be you are seeing this problem affecting you :( I'm a FIOS customer (LATA 246 not 236 like Chris), and haven't had any issues with the network. On the other hand, between my location and the fact that I'm on an old BPON build, perhaps the software upgrades haven't affected me. To further complicate things, ever suspicious of ISP nameservers that don't do DNSSEC validation and monetize rcode 3, and not a fan of the Actiontec boxes that Verizon hands out I run my own cacheing nameserver (hand-built openbsd+pf on embedded hardware with latest bind or unbound and isc dhcpd). Do things magically start working for you if you hard-code 8.8.8.8 or 4.2.2.1 or one of the other usual suspects? That would seem to be a quick way of narrowing it down a bit. -r
RE: VZ FiOS DNS issues:
I don't care for the Actiontec boxes either, but the STB program guides and other features don't work without it, so I have mine forward all IP traffic unmolested to my own as the DMZ host (thus the dual layer of [P|N]AT you see). It's just UDP/TCP 53 traffic that's not flowing for whatever reason; it's every device in the house phones, tablets, computers, you name it, so I'm not inclined to attribute it to malware. My neighbor was also seeing it (and like last time, it seems to have magically resolved itself after ~1.5h). I'm just wondering what Verizon is DOING that they are screwing up their own DNS traffic. If they were capturing my queries and sending them to their own servers (I actually have Google's public facing servers at the top of the list handed out by DHCP) that would be one thing (irritating to be sure, but they aren't, so it's not), but when I'm explicitly hitting a name server down the street in Reston that VZ run and it's failing the same way? It makes me wonder. Jamie -Original Message- From: Robert E. Seastrom [mailto:r...@seastrom.com] Sent: Monday, January 23, 2012 6:21 AM To: Christopher Morrow Cc: nanog group Subject: Re: VZ FiOS DNS issues: Christopher Morrow morrowc.li...@gmail.com writes: On Sun, Jan 22, 2012 at 11:29 AM, Brandon Kim brandon@brandontek.com wrote: I have FIOS and I have no issues. However I do know awhile back they had issues and I was affected by the outage Maybe it hasn't made its way to me yet there have been instances over the time i've been a fios customer that 'upgrades' to devices in the field have caused this problem (last was ~2wks ago? in the washington, dc area). Could be you are seeing this problem affecting you :( I'm a FIOS customer (LATA 246 not 236 like Chris), and haven't had any issues with the network. On the other hand, between my location and the fact that I'm on an old BPON build, perhaps the software upgrades haven't affected me. To further complicate things, ever suspicious of ISP nameservers that don't do DNSSEC validation and monetize rcode 3, and not a fan of the Actiontec boxes that Verizon hands out I run my own cacheing nameserver (hand-built openbsd+pf on embedded hardware with latest bind or unbound and isc dhcpd). Do things magically start working for you if you hard-code 8.8.8.8 or 4.2.2.1 or one of the other usual suspects? That would seem to be a quick way of narrowing it down a bit. -r
RE: Megaupload.com seized
From: Joly MacFie [mailto:j...@punkcast.com] Incidentally, some traffic stats on http://gigaom.com/2012/01/20/follow-the-traffic-what-megauploads-http://gigaom.com/2012/01/20/follow-the-traffic-what-megauploads-downfall-did-to-the-web/ downfall-did-to-the-web/http://gigaom.com/2012/01/20/follow-the-traffic-what-megauploads-downfall-did-to-the-web/ MegaUpload was indeed one of the more popular sites on the web for storing and sharing content. It ranked as .98 percent of the total web traffic in the U.S. and 11.39 of the total web traffic in Brazil. It garnered 1.95 percent of the traffic in Asia-Pac and a less substantial .86 percent in Europe. Our (Sandvine) reporthttp://www.sandvine.com/news/global_broadband_trends.asp shows the amounts of traffic for various storage and backup sites such as megaupload, rapidshare, etc. In the US residential ISP traffic megaupload was ~1% of downstream. Other sites are starting to 'voluntarily' shut down access to the US (e.g. filesonic), and you can see the fairly sharp cut-off as below image. [note the chart doesn't give you an absolute sense since you know neither the number of customers nor the amount of the total bandwidth used, but it gives you a relative view. In this particular chart, there was approximately 10Gbps of traffic from all protocols present, yielding the ~1% for Megaupload] Given that filesonic cut off sharing, but still allows users to fetch links they themself posted, one could make the assumption from the below that there was negligible traffic due to people re-fetching their own content. [cid:image001.png@01CCD9A8.2AB2B630] Some more stats on http://www.betterbroadbandblog.com/2012/01/megaupload-gets-shut-down/ --don inline: image001.png
Re: Megaupload.com seized
On Mon, 23 Jan 2012 13:28:49 GMT, Don Bowman said: Given that filesonic cut off sharing, but still allows users to fetch links they themself posted, one could make the assumption from the below that there was negligible traffic due to people re-fetching their own content. Note that the filesonic cutoff appears to have happened around 18:00 last night in whatever timezone the graph was made. There's a good chance that most of the customers don't *know* yet about the cutoff - what happens tonight once the news has spread will be indicative. pgpbiUnJVHkQK.pgp Description: PGP signature
Re: juniper mx80 vs cisco asr 1000
On Friday, January 20, 2012 04:34:56 AM Thomas Donnelly wrote: The warm standby IOS is a nice feature for in service upgrades and crash avoidance. Except that some times, it did lead to crash (for us anyway), because it eats up half the router's memory, and if you're running 3x full tables or more, you ran out of the other half and BOOM! And that was IOS XR 2, which is generally old now. We now turn off software redundancy now on all ASR1000 boxes that don't have a 2nd RP. Mark. signature.asc Description: This is a digitally signed message part.
Fiber outage in Miami
Was anyone impacted by a botched fiber move in Miami this weekend? I lost 2 pieces of dark fiber for over almost 24 hours due to a fiber move being performed by FiberLight. I'm curious if anyone else was impacted. Sent from mobile device
Re: juniper mx80 vs cisco asr 1000
On Friday, January 20, 2012 05:40:10 AM Leigh Porter wrote: I have not used the asr1000 but it looks like a capable box. You would do well to look at the MX80 fixed chassis, it comes with 48 1G interfaces and 4 10G interfaces. They are pretty good value, I think. The thing the MX80 has that the ASR1000 is port density. You get lots of Gig-E ports in there and a couple of 10Gbps ports too. Not too bad. The ASR1000 has an 8-port Gig-E card (called a SPA - Shared Port Adapter) that offers the most dense Gig-E port capacity in a single-height line card. There is a 10-port Gig-E SPA, but that is a double-height unit, i.e., it eats up 2x slots. 10Gbps port density on the ASR1000 sucks a bit; there is only a 1-port SPA, and no built-in 10Gbps ports unlike the MX80. But on the other hand, the ASR1000 is great if you're looking to throw in some non-Ethernet SPA's, e.g., serial, E1, T1, SONET, SDH, e.t.c. The MX80 won't do this efficiently today, and is really best deployed in Ethernet scenarios. Also, the MX80 can come with rather complicated licensing structures even for the ports you want enabled, if you want to take advantage of their cheaper offers. This can get hairy. Mark. signature.asc Description: This is a digitally signed message part.
Re: Why not to use RPKI (Was Re: Argus: a hijacking alarm system)
Hi chris, 2012/1/23 Christopher Morrow morrowc.li...@gmail.com On Fri, Jan 20, 2012 at 8:08 AM, Yang Xiang xiang...@csnet1.cs.tsinghua.edu.cn wrote: 2012/1/20 Arturo Servin aser...@lacnic.net while Argus can discover potential hijackings caused by anomalous AS path. reading the preceding section (III.B) you check 3 things in the AMM (anomaly monitoring module) 1) proper origin (based on what?) 2) anomalous neighbour (based on what?) 3) policy anomaly (where did you determine the policy?) later text seems to imply you track some history (1 months worth) and use that as a baseline, for at least the neighbour and origin data. The policy data isn't clearly outlined though, where did that come from? (there's a note about use of whois, which could cover some of this, but certainly not all) yes, we use history as a baseline for both the origin, neighbor and policy data. origin data: a history of prefix, origin_AS mappings, neighbor data: a history of every adjacent two ASes in all AS paths received from BGPmon, policy data: a history of every adjacent three ASes (AS triple) in all AS paths. origin and neighbor data is intuitive. for policy data, we do not gather the exact routing policies, since they are usually private. In Argus, we use all adjacent three ASes in all AS paths as the policy data. this is because: 1), AS triples reflect the import/export routing policies; 2), while monitoring BGP updates, we only need to discover 'possible’ hijackings, but not 'exact' hijackings. after figure out a possible hijacking, the hijacking identification process will be launched and make the final judgement. The data plane testing you propose is from the public route-servers (eyes), which don't import the path you want, well routeviews I think doesn't import routes to it's FIB (or maybe I'm mistaken...) but point being with more than one peer on the routeserver it's not clear you would be taking the path you actually want to test anyway, is it? yes, each route-server usually has several route to the target prefix. In Argus, we use the commands (i.e., show route exact active-path”) to get the 'best routes' of the prefix, and consider it as the route in FIB: -chris -- _ Yang Xiang. Ph.D candidate. Tsinghua University Argus: argus.csnet1.cs.tsinghua.edu.cn
Re: Fiber outage in Miami
Yes, quiet a few folks were affected, due to Fiberlight fiber cutover...event. But the effects were very localized Faisal Imtiaz Snappy Internet Telecom 7266 SW 48 Street Miami, Fl 33155 Tel: 305 663 5518 x 232 Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net On 1/23/2012 10:02 AM, Jimmy Changa wrote: Was anyone impacted by a botched fiber move in Miami this weekend? I lost 2 pieces of dark fiber for over almost 24 hours due to a fiber move being performed by FiberLight. I'm curious if anyone else was impacted. Sent from mobile device
Re: Why not to use RPKI (Was Re: Argus: a hijacking alarm system)
On Mon, Jan 23, 2012 at 10:19 AM, Yang Xiang xiang...@csnet1.cs.tsinghua.edu.cn wrote: Hi chris, 2012/1/23 Christopher Morrow morrowc.li...@gmail.com On Fri, Jan 20, 2012 at 8:08 AM, Yang Xiang xiang...@csnet1.cs.tsinghua.edu.cn wrote: 2012/1/20 Arturo Servin aser...@lacnic.net while Argus can discover potential hijackings caused by anomalous AS path. reading the preceding section (III.B) you check 3 things in the AMM (anomaly monitoring module) 1) proper origin (based on what?) 2) anomalous neighbour (based on what?) 3) policy anomaly (where did you determine the policy?) later text seems to imply you track some history (1 months worth) and use that as a baseline, for at least the neighbour and origin data. The policy data isn't clearly outlined though, where did that come from? (there's a note about use of whois, which could cover some of this, but certainly not all) yes, we use history as a baseline for both the origin, neighbor and policy data. origin data: a history of prefix, origin_AS mappings, neighbor data: a history of every adjacent two ASes in all AS paths received from BGPmon, policy data: a history of every adjacent three ASes (AS triple) in all AS paths. origin and neighbor data is intuitive. for policy data, we do not gather the exact routing policies, since they are usually private. In Argus, we use all adjacent three ASes in all AS paths as the policy data. this is because: 1), AS triples reflect the import/export routing policies; 2), while monitoring BGP updates, we only need to discover 'possible’ hijackings, but not 'exact' hijackings. after figure out a possible hijacking, the hijacking identification process will be launched and make the final judgement. ok, that seems squirrelly still :( The data plane testing you propose is from the public route-servers (eyes), which don't import the path you want, well routeviews I think doesn't import routes to it's FIB (or maybe I'm mistaken...) but point being with more than one peer on the routeserver it's not clear you would be taking the path you actually want to test anyway, is it? yes, each route-server usually has several route to the target prefix. In Argus, we use the commands (i.e., show route exact active-path”) to get the 'best routes' of the prefix, and consider it as the route in FIB: so, take routeviews for example, they peer almost exclusively ebgp-multi-hop, so any 'best path' you see there isn't actually usable by the route-server... all traffic has to take the local transport out of the routeviews system, off to the internet and beyond. So, your blackhole testing isn't actually testing what you want, I think :( -chris
Re: juniper mx80 vs cisco asr 1000
ASR 1000 does not run XR. You probably mean XE. The high availability features that requires maintaining state and stateful switch over never seem to work out of the box on early releases and need some time until the feature gets mature. I've found this across different vendors. The dual IOS process works best with two Routing Engines/ESPs on higher models. contact your local vendor engineering representatives asking them for more details on the the ASR1K High Availability features and they should tell you how it works in detail. Regards, Ahmed Sent using BlackBerry® from mobinil -Original Message- From: Mark Tinka mti...@globaltransit.net Date: Mon, 23 Jan 2012 22:58:45 To: nanog@nanog.org Reply-To: mti...@globaltransit.net Subject: Re: juniper mx80 vs cisco asr 1000 On Friday, January 20, 2012 04:34:56 AM Thomas Donnelly wrote: The warm standby IOS is a nice feature for in service upgrades and crash avoidance. Except that some times, it did lead to crash (for us anyway), because it eats up half the router's memory, and if you're running 3x full tables or more, you ran out of the other half and BOOM! And that was IOS XR 2, which is generally old now. We now turn off software redundancy now on all ASR1000 boxes that don't have a 2nd RP. Mark.
Re: juniper mx80 vs cisco asr 1000
On Friday, January 20, 2012 04:14:35 PM Saku Ytti wrote: MX80 is not competing against ASR1k, and JNPR has no product to compete with ASR1k. And this is something I've been telling Juniper for years (not that they don't already know). The M7i and M10i have really done all they can - but trying to get an Ethernet box to do non-Ethernet things, while possible, is simply not economically viable for operators (FlexWAN's, SIP's, MX FPC's, anyone?). They really need to solve this one. The MX80 had no competition from Cisco, until the ASR9001 came out (and it supports 40Gbps line cards when they come out). Juniper are dropping the ball on this one. But hopefully, they're busy in the lab building a decent ASR1000 challenger. Mark. signature.asc Description: This is a digitally signed message part.
Re: Why not to use RPKI (Was Re: Argus: a hijacking alarm system)
2012/1/23 Christopher Morrow morrowc.li...@gmail.com ok, that seems squirrelly still :( so, take routeviews for example, they peer almost exclusively ebgp-multi-hop, so any 'best path' you see there isn't actually usable by the route-server... all traffic has to take the local transport out of the routeviews system, off to the internet and beyond. So, your blackhole testing isn't actually testing what you want, I think :( it is not a serious problem, I think. 1). we do not use routeviews-like routeservers for hijacking identification, we only use router. 2). there is a high possibility that, the 'best path' is the path in FIB table. 3). if the 'best path' is not the path in FIB, there is still a high possibility that the 'best path' is the path in the FIB of other routes in the same AS. 4), our criterion is a threshold of a fingerprint, not a extremum. the fingerprint evaluated the possibility. hope I'm not wrong. :) -chris -- _ Yang Xiang. Ph.D candidate. Tsinghua University Argus: argus.csnet1.cs.tsinghua.edu.cn
Re: How are you doing DHCPv6 ?
This is a problem that would be nice for ISC to resolve (or another dependable FOSS implementation). For a while now (about 20 years I believe) we've used ISC DHCPd in a distributed model for our public IPv4 space. In a nutshell, each DHCP server is configured only with static assignments, their log files are monitored (simple event correlator), and scripts are fired off to perform tasks like new assignments against a centralized database (MySQL). The database is responsible for keeping track of address assignments centrally and is used to generate configuration files for DHCPd. Dynamic updates are made using OMAPI. Unfortunately, the ISC DHCPv6 implementation makes replicating this impossible due to the lack of information logged. Another problem with the ISC DHCPv6 implementation is that it doesn't allow you to assign fixed-address information based on the DUID _and_ IAID, which becomes a problem when a host has more than one active adapter. The only options are hacking the source code if you feel comfortable doing so, or waiting for ISC to make the change (if they ever plan to). For now, we get by with static assignments made in the database and no dynamic allocation via DHCPv6, which does OK in a dual-stack environment where IPv6 isn't considered necessary yet, but in the near future that will change. On Tue, Jan 17, 2012 at 5:04 PM, Randy Carpenter rcar...@network1.net wrote: I am wondering how people out there are using DHCPv6 to handle assigning prefixes to end users. We have a requirement for it to be a redundant server that is centrally located. DHCPv6 will be relayed from each customer access segment. We have been looking at using ISC dhcpd, as that is what we use for v4. However, it currently does not support any redundancy. It also does not do very much useful logging for DHCPv6 requests. Certainly not enough to keep track of users and devices. So, my questions are: How are you doing DHCPv6 with Prefix Delegation? What software are you using? When DHCPv6 with Prefix Delegation seems to be about the only way to deploy IPv6 to end users in a generic device-agnostic fashion, I am wondering why it is so difficult to find a working solution. thanks, -Randy -- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1 -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: VZ FiOS DNS issues:
Jamie Bowden ja...@photon.com writes:
I don't care for the Actiontec boxes either, but the STB program
guides and other features don't work without it, so I have mine
forward all IP traffic unmolested to my own as the DMZ host
Actually this can be worked around. My config has SA, er, Cisco STBs
and a Netgear MCAB1001 MOCA to Ethernet bridge. This configuration is
very unsupported, which is why I keep a completely unmolested
Actiontec around to plug in if I have to have the guys at Verizon take
a look at it.
A little magic in dhcpd.conf:
subnet 192.168.1.0 netmask 255.255.255.0 {
option routers 192.168.1.1 ;
option domain-name-servers 71.252.0.12 ;
default-lease-time 86400 ;
max-lease-time 172800 ;
host stb100 { hardware ethernet 0:23:be:xx:xx:xx ; fixed-address
192.168.1.100 ; }
host stb101 { hardware ethernet 0:21:be:xx:xx:xx ; fixed-address
192.168.1.101 ; }
host stb102 { hardware ethernet 0:25:2e:xx:xx:xx ; fixed-address
192.168.1.102 ; }
host stb103 { hardware ethernet 0:21:be:xx:xx:xx ; fixed-address
192.168.1.103 ; }
}
and then some appropriate holes in the firewall (/etc/pf.conf):
# for STBs
pass in quick on $extif inet proto tcp from any to ($extif) port 35000 rdr-to
192.168.1.100 port 7547
pass in quick on $extif inet proto tcp from any to ($extif) port 35001 rdr-to
192.168.1.101 port 7547
pass in quick on $extif inet proto udp from any to ($extif) port 63145 rdr-to
192.168.1.100 port 63145
(I only have one DVR and one STB - the definitions for extra STBs came
out of the Actiontek. Not sure what I'll end up needing to do if I
get another DVR or STB in order to get them properly provisioned...)
Guide and VOD work fine. I don't feel like playing stuff from a PC on
the STBs badly enough to be willing to cram my whole life into a flat
192.168.1/24, so I give those up.
I've often wondered whether the boxes care about double-hopped NAT.
Perhaps one of these days I'll try putting the Actiontek and some new
pf.conf rules in place of the Netgear and give that a try.
(thus
the dual layer of [P|N]AT you see). It's just UDP/TCP 53 traffic
that's not flowing for whatever reason; it's every device in the
house phones, tablets, computers, you name it, so I'm not inclined
to attribute it to malware. My neighbor was also seeing it (and
like last time, it seems to have magically resolved itself after
~1.5h). I'm just wondering what Verizon is DOING that they are
screwing up their own DNS traffic. If they were capturing my
queries and sending them to their own servers (I actually have
Google's public facing servers at the top of the list handed out by
DHCP) that would be one thing (irritating to be sure, but they
aren't, so it's not), but when I'm explicitly hitting a name server
down the street in Reston that VZ run and it's failing the same way?
It makes me wonder.
No idea, just a datapoint that we're Not Seeing That Here... but if
it is failing on google's public dns servers that's troubling to say
the least.
-r
Re: Fiber outage in Miami
On 01/23/2012 10:02 AM, Jimmy Changa wrote: Was anyone impacted by a botched fiber move in Miami this weekend? I lost 2 pieces of dark fiber for over almost 24 hours due to a fiber move being performed by FiberLight. I'm curious if anyone else was impacted. Sent from mobile device Yes many people were affected. Many carriers who thought they had redundancy found out fast they did not...
Re: juniper mx80 vs cisco asr 1000
On Monday, January 23, 2012 11:29:57 PM ama...@gmail.com wrote: ASR 1000 does not run XR. You probably mean XE. Indeed, I did, as I clarified in some private responses as well. I thought it would be obvious so I decided not to publicly correct it :-). The high availability features that requires maintaining state and stateful switch over never seem to work out of the box on early releases and need some time until the feature gets mature. I've found this across different vendors. To be fair, I've only ever used SSO on the CRS and ASR1000; fairly happy with those jobs. The same on a 6500 was an utter fail, but we mostly kit those out with single SUP720's anyway, so no point for SSO. The rest of our Cisco is 7200's, which are just a single control plane. GRES on Juniper works pretty well, provided you understand the caveats, e.g., Multicast isn't maintained across failovers, e.t.c. Other kinky HA features like ISSU for this or that protocol is too sexy for us. BFD is as exotic as we'll get, plus a little bit of IETF Graceful Restart (not NSR here). The dual IOS process works best with two Routing Engines/ESPs on higher models. Well, if you have dual RP's, you don't need the dual IOS XE software process then :-). Mark. signature.asc Description: This is a digitally signed message part.
Re: Why not to use RPKI (Was Re: Argus: a hijacking alarm system)
On 1/23/2012 7:28 AM, Christopher Morrow wrote: On Mon, Jan 23, 2012 at 10:19 AM, Yang Xiang xiang...@csnet1.cs.tsinghua.edu.cn wrote: Hi chris, 2012/1/23 Christopher Morrow morrowc.li...@gmail.com On Fri, Jan 20, 2012 at 8:08 AM, Yang Xiang xiang...@csnet1.cs.tsinghua.edu.cn wrote: 2012/1/20 Arturo Servin aser...@lacnic.net while Argus can discover potential hijackings caused by anomalous AS path. reading the preceding section (III.B) you check 3 things in the AMM (anomaly monitoring module) 1) proper origin (based on what?) 2) anomalous neighbour (based on what?) 3) policy anomaly (where did you determine the policy?) later text seems to imply you track some history (1 months worth) and use that as a baseline, for at least the neighbour and origin data. The policy data isn't clearly outlined though, where did that come from? (there's a note about use of whois, which could cover some of this, but certainly not all) yes, we use history as a baseline for both the origin, neighbor and policy data. origin data: a history of prefix, origin_AS mappings, neighbor data: a history of every adjacent two ASes in all AS paths received from BGPmon, policy data: a history of every adjacent three ASes (AS triple) in all AS paths. origin and neighbor data is intuitive. for policy data, we do not gather the exact routing policies, since they are usually private. In Argus, we use all adjacent three ASes in all AS paths as the policy data. this is because: 1), AS triples reflect the import/export routing policies; 2), while monitoring BGP updates, we only need to discover 'possible’ hijackings, but not 'exact' hijackings. after figure out a possible hijacking, the hijacking identification process will be launched and make the final judgement. ok, that seems squirrelly still :( The data plane testing you propose is from the public route-servers (eyes), which don't import the path you want, well routeviews I think doesn't import routes to it's FIB (or maybe I'm mistaken...) but point being with more than one peer on the routeserver it's not clear you would be taking the path you actually want to test anyway, is it? yes, each route-server usually has several route to the target prefix. In Argus, we use the commands (i.e., show route exact active-path”) to get the 'best routes' of the prefix, and consider it as the route in FIB: so, take routeviews for example, they peer almost exclusively ebgp-multi-hop, so any 'best path' you see there isn't actually usable by the route-server... all traffic has to take the local transport out of the routeviews system, off to the internet and beyond. So, your blackhole testing isn't actually testing what you want, I think :( -chris Minor correction there. If you are talking about our IX collectors (LINX, PAIX, EQIX Ashburn, SYDNEY, etc.) those are at exchanges and peering directly. The collectors at Univ of Oregon (rv,rv2,rv3,rv4, rv6), yeah, those are multi-hop. Doesn't detract from your point, but I think it helps if people are aware of whether they are on the exchange or on a multihop when using routeviews collectors. Only other thing to add, I don't think anyone mentioned Cyclops in this thread. Just as another data point, see also: http://cyclops.6watch.net or http://cyclops.cs.ucla.edu John Kemp (k...@routeviews.org)
ATT and IPv6 Launch
Is there someone who can talk about how to get IPv6 on ATT residential:? Thanks, - Jared -- snip -- ISPs participating in World IPv6 Launch will enable IPv6 for enough users so that at least 1% of their wireline residential subscribers who visit participating websites will do so using IPv6 by 6 June 2012. These ISPs have committed that IPv6 will be available automatically as the normal course of business for a significant portion of their subscribers. Committed ISPs are: • ATT -- snip --
Re: How are you doing DHCPv6 ?
We have also recently realized that the DUID is pretty much completely random, and there is no way to tie the MAC address to a client. This pretty much makes it impossible to manage a large customer base. -Randy - Original Message - This is a problem that would be nice for ISC to resolve (or another dependable FOSS implementation). For a while now (about 20 years I believe) we've used ISC DHCPd in a distributed model for our public IPv4 space. In a nutshell, each DHCP server is configured only with static assignments, their log files are monitored (simple event correlator), and scripts are fired off to perform tasks like new assignments against a centralized database (MySQL). The database is responsible for keeping track of address assignments centrally and is used to generate configuration files for DHCPd. Dynamic updates are made using OMAPI. Unfortunately, the ISC DHCPv6 implementation makes replicating this impossible due to the lack of information logged. Another problem with the ISC DHCPv6 implementation is that it doesn't allow you to assign fixed-address information based on the DUID _and_ IAID, which becomes a problem when a host has more than one active adapter. The only options are hacking the source code if you feel comfortable doing so, or waiting for ISC to make the change (if they ever plan to). For now, we get by with static assignments made in the database and no dynamic allocation via DHCPv6, which does OK in a dual-stack environment where IPv6 isn't considered necessary yet, but in the near future that will change. On Tue, Jan 17, 2012 at 5:04 PM, Randy Carpenter rcar...@network1.net wrote: I am wondering how people out there are using DHCPv6 to handle assigning prefixes to end users. We have a requirement for it to be a redundant server that is centrally located. DHCPv6 will be relayed from each customer access segment. We have been looking at using ISC dhcpd, as that is what we use for v4. However, it currently does not support any redundancy. It also does not do very much useful logging for DHCPv6 requests. Certainly not enough to keep track of users and devices. So, my questions are: How are you doing DHCPv6 with Prefix Delegation? What software are you using? When DHCPv6 with Prefix Delegation seems to be about the only way to deploy IPv6 to end users in a generic device-agnostic fashion, I am wondering why it is so difficult to find a working solution. thanks, -Randy -- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1 -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Populating BGP from Connected or IGP routes
Hi all, I'm looking for a best practice sort of answer, plus maybe comments on why your network may or may not follow this. First, when running a small ISP with about the equivilent of a /18 or /19 in different blocks, how should you decide what should be in the IGP and what should be in BGP? I assume that it's somewhere between all and none, and one site that I found made some good sense saying something to the following, Use a link-state protocol to track interconnections and loopbacks only, and place all of the networks including customer networks into BGP. Secondly, when is it ok, or preferable to utilize redistribute connected for gathering networks for BGP over using a network statement? I know that this influences the origin code, but past that, why else? Would it ever be permissible to redistribute from the IGP into BGP? Thanks for everyone's input! Eric Miller
Re: Fiber outage in Miami
We are still impacted from what I understand. On 01/23/2012 10:02 AM, Jimmy Changa wrote: Was anyone impacted by a botched fiber move in Miami this weekend? I lost 2 pieces of dark fiber for over almost 24 hours due to a fiber move being performed by FiberLight. I'm curious if anyone else was impacted. Sent from mobile device
Re: Populating BGP from Connected or IGP routes
On Mon, Jan 23, 2012 at 12:46 PM, Eric C. Miller e...@ericheather.com wrote: Hi all, I'm looking for a best practice sort of answer, plus maybe comments on why your network may or may not follow this. First, when running a small ISP with about the equivilent of a /18 or /19 in different blocks, how should you decide what should be in the IGP and what should be in BGP? I assume that it's somewhere between all and none, and one site that I found made some good sense saying something to the following, Use a link-state protocol to track interconnections and loopbacks only, and place all of the networks including customer networks into BGP. Secondly, when is it ok, or preferable to utilize redistribute connected for gathering networks for BGP over using a network statement? I know that this influences the origin code, but past that, why else? Would it ever be permissible to redistribute from the IGP into BGP? This is one of those questions where the answer will depend heavily on who you ask. In my opinion, I would - Keep externally-learned eBGP routes in one table. The Internet table. - Keep internal links (loopbacks, single-homed (to me) customers, networks containing next-hops outside your AS) in an IGP (like OSPF or IS-IS). These routes should very rarely get exchanged outside the AS. - Where possible, have multi-homed customers speak BGP to your AS and just treat those routes as those you'll provide transit for (re-announcing them to other external peers) -- In cases where customers multi or single-home with their own address space that they'd like you to address, put very specific filters and tagging on the routes. This way, you can perform careful filtering on allowing those routes to cross the boundary from IGP to EGP (and onto your external peers). Cheers, jof
Re: LAw Enforcement Contact
On Jan 23, 2012, at 2:46 AM, Chris wrote: The appropriately named SS mainly deals with counterfeit currency, widespread ID theft (See also: Ryan1918) and threats to the President. Actually, they have statutory authority to deal with computer crime, too; see http://www.secretservice.gov/criminal.shtml and http://www.law.cornell.edu/uscode/18/1030.html --Steve Bellovin, https://www.cs.columbia.edu/~smb
Re: LAw Enforcement Contact
From memory Ameen Pishdadi is the owner of GIGENET, run by Paul Ashley (Aka XEROX), and comprised of the IP space and assets of FOONET. One would think that he has much contact with law enforcement. Or does my memory fail me? Andrew On 1/22/2012 8:16 PM, A. Pishdadi wrote: Hello, We recently tracked down a botnet that attacked our network. We found the CC server, it has approximately 40-50 servers, consisting of mostly *nix machines with high speed connections, for example AWS servers or dedicated, attack capacity is 4-5Gb/s or more. Is there any contacts with law enforcement here that I can send over the info too? .
Re: Populating BGP from Connected or IGP routes
On Mon, 23 Jan 2012, Eric C. Miller wrote: I'm looking for a best practice sort of answer, plus maybe comments on why your network may or may not follow this. First, when running a small ISP with about the equivilent of a /18 or /19 in different blocks, how should you decide what should be in the IGP and what should be in BGP? I assume that it's somewhere between all and none, and one site that I found made some good sense saying something to the following, Use a link-state protocol to track interconnections and loopbacks only, and place all of the networks including customer networks into BGP. That depends on your architecture. There are several ways to deploy sane/scalable IGP and EGP architectures. Secondly, when is it ok, or preferable to utilize redistribute connected for gathering networks for BGP over using a network statement? I know that this influences the origin code, but past that, why else? Would it ever be permissible to redistribute from the IGP into BGP? Keep in mind that redistribute connected and a network statement in your IGP do two different things. For example, in OSPF, adding a network statement for an interface will enable OSPF on that interface, and your router will try to find other OSPF speaking devices that are connected to that interface and form an adjacency with them, unless you make the interface passive, which would negate the network statement. Routes for connected interfaces that are imported/redistributed into your IGP might carry a different origin, LSA type and/or metric, depending on how you import them. passive-interface default is your friend :) jms
Re: Populating BGP from Connected or IGP routes
On Mon, 23 Jan 2012, Eric C. Miller wrote: First, when running a small ISP with about the equivilent of a /18 or /19 in different blocks, how should you decide what should be in the IGP and what should be in BGP? I assume that it's somewhere between all and none, and one site that I found made some good sense saying something to the following, Use a link-state protocol to track interconnections and loopbacks only, and place all of the networks including customer networks into BGP. The simple answer, for an ISP of small size, is use a traditional IGP such as OSPF or ISIS for internal routing (if any dynamic routing is even needed), and BGP for internet routing, with iBGP between your transit routers if you have more than one transit router. Secondly, when is it ok, or preferable to utilize redistribute connected for gathering networks for BGP over using a network statement? I know that this influences the origin code, but past that, why else? Would it ever be permissible to redistribute from the IGP into BGP? I haven't seen one. It's too easy to screw up and let routes out that shouldn't if you redistribute into BGP...the only exception being a well filtered setup for real time blackhole routing. For a small ISP, I'd suggest just using network statements and high metric static routes to null0 to make those network statements always advertise. If you're a little bigger and have BGP customers, then I highly recommend use of BGP communities to control your outbound route filtering. By defining and setting communties on received customer routes, you can turn up new BGP customers without having to modify anything beyond the router they're connected to. It amazes me that there are large networks still not setup this way. You need an after hours maintenance window to turn up a BGP customer? Yeah, we have to modify the prefix list filters on all our backbone routers. WTF? -- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: ATT and IPv6 Launch
On 1/23/12 11:23 AM, Jared Mauch wrote: Is there someone who can talk about how to get IPv6 on ATT residential:? Thanks, - Jared -- snip -- ISPs participating in World IPv6 Launch will enable IPv6 for enough users so that at least 1% of their wireline residential subscribers who visit participating websites will do so using IPv6 by 6 June 2012. These ISPs have committed that IPv6 will be available automatically as the normal course of business for a significant portion of their subscribers. Committed ISPs are: • ATT -- snip -- I'm interested too and willing to experiment, although I suspect my city is too small to make the first cut. ~Seth
Re: How are you doing DHCPv6 ?
In message CALFTrnMXzdoS=-B=wt1hvfgkvdrqzdz8konhopgu1joqxo9...@mail.gmail.com , Ray Soucy writes: This is a problem that would be nice for ISC to resolve (or another dependable FOSS implementation). For a while now (about 20 years I believe) we've used ISC DHCPd in a distributed model for our public IPv4 space. In a nutshell, each DHCP server is configured only with static assignments, their log files are monitored (simple event correlator), and scripts are fired off to perform tasks like new assignments against a centralized database (MySQL). The database is responsible for keeping track of address assignments centrally and is used to generate configuration files for DHCPd. Dynamic updates are made using OMAPI. Unfortunately, the ISC DHCPv6 implementation makes replicating this impossible due to the lack of information logged. Another problem with the ISC DHCPv6 implementation is that it doesn't allow you to assign fixed-address information based on the DUID _and_ IAID, which becomes a problem when a host has more than one active adapter. The only options are hacking the source code if you feel comfortable doing so, or waiting for ISC to make the change (if they ever plan to). I can't see any request to add this feature to ISC DHCPv6 so I've opened 27564 request for duid+iaid as selection criteria If we don't know you need a feature we can't put it on the roadmap. For now, we get by with static assignments made in the database and no dynamic allocation via DHCPv6, which does OK in a dual-stack environment where IPv6 isn't considered necessary yet, but in the near future that will change. On Tue, Jan 17, 2012 at 5:04 PM, Randy Carpenter rcar...@network1.net wrote : I am wondering how people out there are using DHCPv6 to handle assigning pr efixes to end users. We have a requirement for it to be a redundant server that is centrally loc ated. DHCPv6 will be relayed from each customer access segment. We have been looking at using ISC dhcpd, as that is what we use for v4. How ever, it currently does not support any redundancy. It also does not do very much useful logging for DHCPv6 requests. Certainly not enough to keep track o f users and devices. So, my questions are: How are you doing DHCPv6 with Prefix Delegation? What software are you using? When DHCPv6 with Prefix Delegation seems to be about the only way to deploy IPv6 to end users in a generic device-agnostic fashion, I am wondering why i t is so difficult to find a working solution. thanks, -Randy -- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1 -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: How are you doing DHCPv6 ?
On Mon, 2012-01-23 at 14:44 -0500, Randy Carpenter wrote: We have also recently realized that the DUID is pretty much completely random, and there is no way to tie the MAC address to a client. This pretty much makes it impossible to manage a large customer base. Not sure about that. The DUID is not random, at least not if it is being generated according to RFC 3315, which it probably should be. A DUID should be generated by a client[1] the first time it needs one, then be stored and never change[2]. All clients are supposed to provide a mechanism for setting the DUID to a specific value. Once generated, the DUID is indeed tied to the client unless something intervenes. In particular, a DUID is not affected by a change of NIC and is identical for all connected interfaces. I have to confess that we are not actually doing it, but the plan[3] is to capture new DUIDs as they happen and record the address-DUID mapping in our database. That's pretty much what we do now for boxes where the MAC address is not printed on the outside! But only where we need a reservation. The servers we use will always give the same address to the same DUID. Since we do not expect to use actual reserved addresses very much, this should be all we need. We are a) not really a large enterprise and b) not an ISP or carrier, so perhaps our needs are not the same as those you envisage. Vendors delivering pre-installed operating systems can set up vendor-assigned unique DUIDs and print them on the box, much as MAC addresses now are. It seems to me that DUIDs are better handles for clients than MAC addresses, but will require a change in the way people do things. Regards, K. [1] The algorithm for generating the DUID can include the MAC of any available interface, the time of day etc, but is supposed to be treated as opaque (RFC3315, section 9). Since RFC 3315 defines precisely how the DUIDs are to be generated, it should be very easy to extract the MAC address part, but given that the MAC address used may not actually exist on the device any more, I'm not sure that's very useful. It might be useful the first time a new DUID is seen, on the assumption that the NIC was not changed before the machine was first run. Then one could note the MAC address when provisioning the machine, and recognise the DUID of that machine when it pops up on the network. Mind you, the assumption is not foolproof. [2] Obviously devices with no long-term storage (or no storage at al! - will use a different generation algorithm than ones that do have storage. [2] No battle plan survives contact with the enemy - Helmuth von Moltke the Elder. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Re: How are you doing DHCPv6 ?
The requirement of the DUID is a big hurdle to DHCPv6 adoption, I agree. Currently, a DUID can be generated in 1 of 3 ways, 2 of which include _any_ MAC address of the system at the time of generation. After that, the DUID is stored in software. The idea is that the DUID identifies the system and the IAID identifies the interface, and that over time, the system will keep its DUID even if the network adapter changes. This is obviously different from how we use DHCP for legacy IP. There are a few problems as a result: 1. Systems that are built using disk images can all have the same DUID unless the admin takes care to remove any generated DUID on the image (already see this on Windows 7 and even Linux). 2. Networks where the MAC addresses for systems are already known can’t simply build a DHCPv6 configuration based on those MACs. If someone were to modify DHCPv6 to address these concerns, I think the easiest way to do so would be to extend DHCPv6 relay messages to include the MAC address of the system making the request (DHCPv6 servers on local sub-networks would be able to determine the MAC from the packet). This would allow transitional DHCPv6 configurations to be built on MAC addresses rather than DUID without client modification (which is key). Perhaps this is already possible through the use of RFC 6422 (which shouldn’t break anything). I think more important, though, is a good DHCPv6 server implementation with verbose logging capabilities, and the ability to specify a DUID, DUID+IAID, or MAC for static assignments. I know there are people from ISC on-list. It would be great to hear someone who works on DHCPd chime in. How about we start with modifying ISC DHCPd for IPv6 to have proper logging and support for configuring IAID, then work on the MAC awareness piece. ISC DHCPd makes use of RAW sockets, so it should always have the MAC for a non-relayed request. Then we just need to work with router vendors on adding MACs as a relay option. On Mon, Jan 23, 2012 at 2:44 PM, Randy Carpenter rcar...@network1.net wrote: We have also recently realized that the DUID is pretty much completely random, and there is no way to tie the MAC address to a client. This pretty much makes it impossible to manage a large customer base. -Randy - Original Message - This is a problem that would be nice for ISC to resolve (or another dependable FOSS implementation). For a while now (about 20 years I believe) we've used ISC DHCPd in a distributed model for our public IPv4 space. In a nutshell, each DHCP server is configured only with static assignments, their log files are monitored (simple event correlator), and scripts are fired off to perform tasks like new assignments against a centralized database (MySQL). The database is responsible for keeping track of address assignments centrally and is used to generate configuration files for DHCPd. Dynamic updates are made using OMAPI. Unfortunately, the ISC DHCPv6 implementation makes replicating this impossible due to the lack of information logged. Another problem with the ISC DHCPv6 implementation is that it doesn't allow you to assign fixed-address information based on the DUID _and_ IAID, which becomes a problem when a host has more than one active adapter. The only options are hacking the source code if you feel comfortable doing so, or waiting for ISC to make the change (if they ever plan to). For now, we get by with static assignments made in the database and no dynamic allocation via DHCPv6, which does OK in a dual-stack environment where IPv6 isn't considered necessary yet, but in the near future that will change. On Tue, Jan 17, 2012 at 5:04 PM, Randy Carpenter rcar...@network1.net wrote: I am wondering how people out there are using DHCPv6 to handle assigning prefixes to end users. We have a requirement for it to be a redundant server that is centrally located. DHCPv6 will be relayed from each customer access segment. We have been looking at using ISC dhcpd, as that is what we use for v4. However, it currently does not support any redundancy. It also does not do very much useful logging for DHCPv6 requests. Certainly not enough to keep track of users and devices. So, my questions are: How are you doing DHCPv6 with Prefix Delegation? What software are you using? When DHCPv6 with Prefix Delegation seems to be about the only way to deploy IPv6 to end users in a generic device-agnostic fashion, I am wondering why it is so difficult to find a working solution. thanks, -Randy -- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1 -- 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
Re: How are you doing DHCPv6 ?
One major issue is that there is no way to associate a user's MAC (for IPv4) with their DUID. I haven't been able to find a way to account for this without making the user authenticate once for IPv4, and then again for IPv6. This is cumbersome to the user. Also, in the past there have been various reason why we want to pre-authenticate a client's MAC address (mostly for game consoles, and such, which have the MAC written on the outside of the machine). How can this be done with IPv6, which the DUID is not constant? -Randy - Original Message - On Mon, 2012-01-23 at 14:44 -0500, Randy Carpenter wrote: We have also recently realized that the DUID is pretty much completely random, and there is no way to tie the MAC address to a client. This pretty much makes it impossible to manage a large customer base. Not sure about that. The DUID is not random, at least not if it is being generated according to RFC 3315, which it probably should be. A DUID should be generated by a client[1] the first time it needs one, then be stored and never change[2]. All clients are supposed to provide a mechanism for setting the DUID to a specific value. Once generated, the DUID is indeed tied to the client unless something intervenes. In particular, a DUID is not affected by a change of NIC and is identical for all connected interfaces. I have to confess that we are not actually doing it, but the plan[3] is to capture new DUIDs as they happen and record the address-DUID mapping in our database. That's pretty much what we do now for boxes where the MAC address is not printed on the outside! But only where we need a reservation. The servers we use will always give the same address to the same DUID. Since we do not expect to use actual reserved addresses very much, this should be all we need. We are a) not really a large enterprise and b) not an ISP or carrier, so perhaps our needs are not the same as those you envisage. Vendors delivering pre-installed operating systems can set up vendor-assigned unique DUIDs and print them on the box, much as MAC addresses now are. It seems to me that DUIDs are better handles for clients than MAC addresses, but will require a change in the way people do things. Regards, K. [1] The algorithm for generating the DUID can include the MAC of any available interface, the time of day etc, but is supposed to be treated as opaque (RFC3315, section 9). Since RFC 3315 defines precisely how the DUIDs are to be generated, it should be very easy to extract the MAC address part, but given that the MAC address used may not actually exist on the device any more, I'm not sure that's very useful. It might be useful the first time a new DUID is seen, on the assumption that the NIC was not changed before the machine was first run. Then one could note the MAC address when provisioning the machine, and recognise the DUID of that machine when it pops up on the network. Mind you, the assumption is not foolproof. [2] Obviously devices with no long-term storage (or no storage at al! - will use a different generation algorithm than ones that do have storage. [2] No battle plan survives contact with the enemy - Helmuth von Moltke the Elder. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Re: How are you doing DHCPv6 ?
Thanks, Mark. The ISC website isn't very clear on how to make such requests unless you have a support contract. Also make note of my last response to the thread on logging and MAC awareness, as it may also be worth consideration. On Mon, Jan 23, 2012 at 5:05 PM, Mark Andrews ma...@isc.org wrote: In message CALFTrnMXzdoS=-B=wt1hvfgkvdrqzdz8konhopgu1joqxo9...@mail.gmail.com , Ray Soucy writes: This is a problem that would be nice for ISC to resolve (or another dependable FOSS implementation). For a while now (about 20 years I believe) we've used ISC DHCPd in a distributed model for our public IPv4 space. In a nutshell, each DHCP server is configured only with static assignments, their log files are monitored (simple event correlator), and scripts are fired off to perform tasks like new assignments against a centralized database (MySQL). The database is responsible for keeping track of address assignments centrally and is used to generate configuration files for DHCPd. Dynamic updates are made using OMAPI. Unfortunately, the ISC DHCPv6 implementation makes replicating this impossible due to the lack of information logged. Another problem with the ISC DHCPv6 implementation is that it doesn't allow you to assign fixed-address information based on the DUID _and_ IAID, which becomes a problem when a host has more than one active adapter. The only options are hacking the source code if you feel comfortable doing so, or waiting for ISC to make the change (if they ever plan to). I can't see any request to add this feature to ISC DHCPv6 so I've opened 27564 request for duid+iaid as selection criteria If we don't know you need a feature we can't put it on the roadmap. For now, we get by with static assignments made in the database and no dynamic allocation via DHCPv6, which does OK in a dual-stack environment where IPv6 isn't considered necessary yet, but in the near future that will change. On Tue, Jan 17, 2012 at 5:04 PM, Randy Carpenter rcar...@network1.net wrote : I am wondering how people out there are using DHCPv6 to handle assigning pr efixes to end users. We have a requirement for it to be a redundant server that is centrally loc ated. DHCPv6 will be relayed from each customer access segment. We have been looking at using ISC dhcpd, as that is what we use for v4. How ever, it currently does not support any redundancy. It also does not do very much useful logging for DHCPv6 requests. Certainly not enough to keep track o f users and devices. So, my questions are: How are you doing DHCPv6 with Prefix Delegation? What software are you using? When DHCPv6 with Prefix Delegation seems to be about the only way to deploy IPv6 to end users in a generic device-agnostic fashion, I am wondering why i t is so difficult to find a working solution. thanks, -Randy -- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1 -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: How are you doing DHCPv6 ?
On Mon, 2012-01-23 at 17:26 -0500, Randy Carpenter wrote: One major issue is that there is no way to associate a user's MAC (for IPv4) with their DUID. I haven't been able to find a way to account for this without making the user authenticate once for IPv4, and then again for IPv6. This is cumbersome to the user. Also, in the past there have been various reason why we want to pre-authenticate a client's MAC address (mostly for game consoles, and such, which have the MAC written on the outside of the machine). How can this be done with IPv6, which the DUID is not constant? Perhaps I misunderstand you (or the RFCs) but it seems to me that the DUID *is* constant. Reading section 9 of RFC 3315, it's pretty clear that a DUID is generated once, according to simple rules, and does not change once it has been generated. Barring intervention, of course. The problem is how to either find out ahead of time what DUID a client has OR how to impose a specific DUID on a client as part of provisioning it. Neither of those issues looks particularly intractable, especially if vendors start shipping with pre-configured DUIDs that are written on the boxes. What do you mean by authenticate? Do you mean something like 802.1x? Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 signature.asc Description: This is a digitally signed message part
Re: How are you doing DHCPv6 ?
Yes, DUID and IAID should be persistent on systems. If they are not then they are not following the RFC. Note that bad practices, though, can remove that persistence (e.g. deleting the DUID, or replicating the DUID on other systems). On Mon, Jan 23, 2012 at 5:56 PM, Karl Auer ka...@biplane.com.au wrote: On Mon, 2012-01-23 at 17:26 -0500, Randy Carpenter wrote: One major issue is that there is no way to associate a user's MAC (for IPv4) with their DUID. I haven't been able to find a way to account for this without making the user authenticate once for IPv4, and then again for IPv6. This is cumbersome to the user. Also, in the past there have been various reason why we want to pre-authenticate a client's MAC address (mostly for game consoles, and such, which have the MAC written on the outside of the machine). How can this be done with IPv6, which the DUID is not constant? Perhaps I misunderstand you (or the RFCs) but it seems to me that the DUID *is* constant. Reading section 9 of RFC 3315, it's pretty clear that a DUID is generated once, according to simple rules, and does not change once it has been generated. Barring intervention, of course. The problem is how to either find out ahead of time what DUID a client has OR how to impose a specific DUID on a client as part of provisioning it. Neither of those issues looks particularly intractable, especially if vendors start shipping with pre-configured DUIDs that are written on the boxes. What do you mean by authenticate? Do you mean something like 802.1x? Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: How are you doing DHCPv6 ?
Controlled by software = not constant. It is also not likely to be something that is knowable on a piece of electronic gear that is not a PC, nor will it be something that can be printed on the outside of the device, like most today. -Randy - Original Message - Yes, DUID and IAID should be persistent on systems. If they are not then they are not following the RFC. Note that bad practices, though, can remove that persistence (e.g. deleting the DUID, or replicating the DUID on other systems). On Mon, Jan 23, 2012 at 5:56 PM, Karl Auer ka...@biplane.com.au wrote: On Mon, 2012-01-23 at 17:26 -0500, Randy Carpenter wrote: One major issue is that there is no way to associate a user's MAC (for IPv4) with their DUID. I haven't been able to find a way to account for this without making the user authenticate once for IPv4, and then again for IPv6. This is cumbersome to the user. Also, in the past there have been various reason why we want to pre-authenticate a client's MAC address (mostly for game consoles, and such, which have the MAC written on the outside of the machine). How can this be done with IPv6, which the DUID is not constant? Perhaps I misunderstand you (or the RFCs) but it seems to me that the DUID *is* constant. Reading section 9 of RFC 3315, it's pretty clear that a DUID is generated once, according to simple rules, and does not change once it has been generated. Barring intervention, of course. The problem is how to either find out ahead of time what DUID a client has OR how to impose a specific DUID on a client as part of provisioning it. Neither of those issues looks particularly intractable, especially if vendors start shipping with pre-configured DUIDs that are written on the boxes. What do you mean by authenticate? Do you mean something like 802.1x? Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: How are you doing DHCPv6 ?
On Mon, 2012-01-23 at 18:12 -0500, Randy Carpenter wrote: Controlled by software = not constant. OK - fair point. But these days many MACs can be controlled by software too. In the world of virtual computing they don't exist in hardware at all. The world hasn't ended. Examples abound of codes that are software controlled but long-lived. SSIDs and other access codes on commodity wifi routers, for example. Or licence numbers for some operating systems e.g., Windows. Written on the box, too. It is also not likely to be something that is knowable on a piece of electronic gear that is not a PC, nor will it be something that can be printed on the outside of the device, like most today. Well, that's not really true. There is nothing stopping OEMs shipping equipment with preconfigured DUIDs and printing those DUIDs on the side of the box or the bottom of the device or whatever. As to being knowable, well, neither is a MAC. Short of starting up a device and seeing what MAC it uses, there is no way to know ahead of time what MAC addresses a device has unless the manufacturer was kind enough to print them on the box. Don't get me wrong; I'm not trying to be an apologist for DUIDs. But I think we do need to see the problems clearly in order to solve them. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 signature.asc Description: This is a digitally signed message part
Re: How are you doing DHCPv6 ?
In message calftrnmr7uc4fxex0dacg0v-fcukvccumbg5etlexoj4hrp...@mail.gmail.com , Ray Soucy writes: Thanks, Mark. The ISC website isn't very clear on how to make such requests unless you have a support contract. For reference email to dhcp-sugg...@isc.org (or even dhcp-b...@isc.org) well get it logged. Also make note of my last response to the thread on logging and MAC awareness, as it may also be worth consideration. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: ATT and IPv6 Launch
So i have been privately referred to att.com/ipv6 where you can find supporting CPE devices. It sounds like if you have equipment supporting ipv6 it may just appear one day soon. Jared Mauch On Jan 23, 2012, at 2:23 PM, Jared Mauch ja...@puck.nether.net wrote: Is there someone who can talk about how to get IPv6 on ATT residential:? Thanks, - Jared -- snip -- ISPs participating in World IPv6 Launch will enable IPv6 for enough users so that at least 1% of their wireline residential subscribers who visit participating websites will do so using IPv6 by 6 June 2012. These ISPs have committed that IPv6 will be available automatically as the normal course of business for a significant portion of their subscribers. Committed ISPs are: • ATT -- snip --
RE: ATT and IPv6 Launch
-Original Message- From: Jared Mauch [mailto:ja...@puck.nether.net] Sent: Monday, January 23, 2012 5:52 PM To: Jared Mauch Cc: nanog@nanog.org Group Subject: Re: ATT and IPv6 Launch So i have been privately referred to att.com/ipv6 where you can find supporting CPE devices. It sounds like if you have equipment supporting ipv6 it may just appear one day soon. Jared Mauch On Jan 23, 2012, at 2:23 PM, Jared Mauch ja...@puck.nether.net wrote: Is there someone who can talk about how to get IPv6 on ATT residential:? Thanks, - Jared -- snip -- ISPs participating in World IPv6 Launch will enable IPv6 for enough users so that at least 1% of their wireline residential subscribers who visit participating websites will do so using IPv6 by 6 June 2012. These ISPs have committed that IPv6 will be available automatically as the normal course of business for a significant portion of their subscribers. Committed ISPs are: • ATT -- snip -- I am still waiting for our switched Ethernet circuits (Opt-E-MAN) to be supported. Curtis
Re: Megaupload.com seized
On 21/01/12 11:20 PM, George Bonser wrote: This is what disaster simulations are for, to suss out these problems before a disaster and put in systems to avoid the mess. In the real world, while a city might keep the digital documents in the cloud they would also (always) have paper copies, because in a big emergency their computers (local mail/file servers or internet access to the cloud) are likely to be unavailable, power or internet access is likely to be disrupted. Nope, no paper copies. I personally know Lynn Brown, OES (Office of Emergency Services) Coordinator for the City of Mountain View, CA[1]. I asked Lynn about the status of the maps the MV EOC (Emergency Operations Center) uses. Here is the reply: While we rely on electronic and digital information a lot more these days, the City of Mountain View still has printed maps on hand. I just updated the master map in our EOC, in fact. The computerized maps are great but we also plan for the worst case scenario with no access to them. I don't think paper will ever go away completely. Lynn Brown OES Coordinator Mountain View Fire Department 650-903-6825 lynn(dot)brown(at)mountainview(dot)gov If you believe that this is not the norm for EOCs across the country, I suggest you personally ask the OES Coordinator for whatever city you think is putting everything in the computer and no longer keeping any paper copies. You may be surprised to learn how well they have indeed thought this thru, and that they do maintain paper maps in the EOC, just as Mountain View does. jc [1] Given that Google has wired MV with free public WiFi, if there were ever a city that would be in a good position to use and rely on Google's cloud services for data storage, Mountain View would be it.
is it -really- global?
anyone keeping track of their RTTs? i'm finishing up some work on latency and all i have are my numbers. its going to be highly variable based on where you are and where you go, but it would be nice to have other sets of numbers. roughly my targets are :: 43% are cloud oriented - CBN stuff that tried to place bits near me 22% are US/CA targets 14% are kcj 12% are eu 4% are africaan 5% are other and the source moves, East/Best coast of the US, Africa, Japan, NZ /bill
Re: LAw Enforcement Contact
Andrew , it does fail you. The 35+ employees that work for GigeNET would be really insulted by you insinuating that there job roles have no merit. The combination of all the things they do is what makes the company run. So no Paul does not run the company, put down the crack pipe. Why don't you find something else to troll beside a mailing list of industry professionals and a legitimate request for help. On Mon, Jan 23, 2012 at 3:21 PM, Andrew D Kirch trel...@trelane.net wrote: From memory Ameen Pishdadi is the owner of GIGENET, run by Paul Ashley (Aka XEROX), and comprised of the IP space and assets of FOONET. One would think that he has much contact with law enforcement. Or does my memory fail me? Andrew On 1/22/2012 8:16 PM, A. Pishdadi wrote: Hello, We recently tracked down a botnet that attacked our network. We found the CC server, it has approximately 40-50 servers, consisting of mostly *nix machines with high speed connections, for example AWS servers or dedicated, attack capacity is 4-5Gb/s or more. Is there any contacts with law enforcement here that I can send over the info too? .
Re: Why not to use RPKI (Was Re: Argus: a hijacking alarm system)
2012/1/24 John Kemp k...@network-services.uoregon.edu Minor correction there. If you are talking about our IX collectors (LINX, PAIX, EQIX Ashburn, SYDNEY, etc.) those are at exchanges and peering directly. The collectors at Univ of Oregon (rv,rv2,rv3,rv4, rv6), yeah, those are multi-hop. Doesn't detract from your point, but I think it helps if people are aware of whether they are on the exchange or on a multihop when using routeviews collectors. We talk about routeservers, not collectors. Argus doesn't use routeservers in RouteViews to identify hijacking. Only other thing to add, I don't think anyone mentioned Cyclops in this thread. Just as another data point, see also: http://cyclops.6watch.net or http://cyclops.cs.ucla.edu John Kemp (k...@routeviews.org) -- _ Yang Xiang. Ph.D candidate. Tsinghua University Argus: argus.csnet1.cs.tsinghua.edu.cn
Re: is it -really- global?
only intl links on which smokeping shows anything is ashburn to tokyo. but that only covers us, joburg, linx, tokyo inline: ash-tok-400-days.jpg
