Re: Packet loss and latency between Akamai and NTT in Miami
Hi, just to give some closure here: The issue was fixed, connectivity has been back to normal for approximately 36 hours already. I don't know exactly who fixed it or where exactly the problem was located. I guess it was in the end some sort of collective effort. Thanks to all those who offered help, I believe these kind of situations is where the value of the *NOG communities is actually seen and appreciated. /Carlos On Fri, May 17, 2024 at 2:40 PM Carlos Martinez-Cagnazzo wrote: > > Any contacts with either Akamai or NTT here ? > > This is kind of important as this is affecting three of our RPKI > publication servers (servers which I have de-priorized in Route53 to > prevent any issues for RPs) > > I have a ticket open with Akamai but I'm not directly an NTT customer > so any help is appreciated. > > A sample MTR report, see between hops 7 and 8. Funnily enough this is > periodic and has a cycle of between 15 and 25 minutes. > > %% START MTR TCP IPV4 en 20240517-16:10 > Start: 2024-05-17T16:10:01+ > HOST: rpki-fe-45-79-203-193.rrdp. Loss% Snt Last Avg Best Wrst StDev > 1.|-- 10.204.6.210.0%200.5 0.2 0.1 0.5 0.1 > 2.|-- 10.204.35.59 0.0%200.3 0.3 0.2 0.6 0.1 > 10.204.35.60 > 3.|-- 10.204.64.38 0.0%200.3 0.3 0.2 0.6 0.1 > 10.204.64.37 > 4.|-- lo0-0.gw3.atl1.us.linode. 0.0%20 19.9 4.1 0.4 19.9 6.1 > lo0-0.gw4.atl1.us.linode.com > 5.|-- ae45.r12.atl01.ien.netarc 0.0%200.5 0.5 0.4 0.7 0.1 > ae48.r11.atl01.ien.netarch.akamai.com > 6.|-- ae-41.a03.atlnga05.us.bb. 0.0%205.2 2.3 0.4 14.8 3.7 > ae0.r11.atl01.ien.netarch.akamai.com > 7.|-- ae-41.a03.atlnga05.us.bb. 0.0%203.3 11.4 0.9 38.5 11.0 > ae-2.r25.atlnga05.us.bb.gin.ntt.net > 8.|-- ae-1.r22.miamfl02.us.bb.g 20.0%20 7271. 1816. 0.8 7271. 3236.6 > ae-2.r25.atlnga05.us.bb.gin.ntt.net > 9.|-- ae-1.r22.miamfl02.us.bb.g 5.0%20 7201. 1684. 13.3 7256. 2970.2 > ae-0.r23.miamfl02.us.bb.gin.ntt.net > 10.|-- ae-11.a00.saplbr02.br.bb. 0.0%20 123.2 206.8 13.1 3035. 667.7 > ae-0.r23.miamfl02.us.bb.gin.ntt.net > 11.|-- ae1-1326.gw1.nu.registro. 0.0%20 129.2 125.2 116.7 139.5 5.8 > ae-11.a00.saplbr02.br.bb.gin.ntt.net > 12.|-- xe-0-1-2-0.core1.nu.regis 0.0%20 117.9 174.0 117.6 1133. 225.9 > ae1-1326.gw1.nu.registro.br > > Thanks > > Carlos > > -- > -- > = > Carlos M. Martinez-Cagnazzo > http://cagnazzo.me > = -- -- = Carlos M. Martinez-Cagnazzo http://cagnazzo.me =
Packet loss and latency between Akamai and NTT in Miami
Any contacts with either Akamai or NTT here ? This is kind of important as this is affecting three of our RPKI publication servers (servers which I have de-priorized in Route53 to prevent any issues for RPs) I have a ticket open with Akamai but I'm not directly an NTT customer so any help is appreciated. A sample MTR report, see between hops 7 and 8. Funnily enough this is periodic and has a cycle of between 15 and 25 minutes. %% START MTR TCP IPV4 en 20240517-16:10 Start: 2024-05-17T16:10:01+ HOST: rpki-fe-45-79-203-193.rrdp. Loss% Snt Last Avg Best Wrst StDev 1.|-- 10.204.6.210.0%200.5 0.2 0.1 0.5 0.1 2.|-- 10.204.35.59 0.0%200.3 0.3 0.2 0.6 0.1 10.204.35.60 3.|-- 10.204.64.38 0.0%200.3 0.3 0.2 0.6 0.1 10.204.64.37 4.|-- lo0-0.gw3.atl1.us.linode. 0.0%20 19.9 4.1 0.4 19.9 6.1 lo0-0.gw4.atl1.us.linode.com 5.|-- ae45.r12.atl01.ien.netarc 0.0%200.5 0.5 0.4 0.7 0.1 ae48.r11.atl01.ien.netarch.akamai.com 6.|-- ae-41.a03.atlnga05.us.bb. 0.0%205.2 2.3 0.4 14.8 3.7 ae0.r11.atl01.ien.netarch.akamai.com 7.|-- ae-41.a03.atlnga05.us.bb. 0.0%203.3 11.4 0.9 38.5 11.0 ae-2.r25.atlnga05.us.bb.gin.ntt.net 8.|-- ae-1.r22.miamfl02.us.bb.g 20.0%20 7271. 1816. 0.8 7271. 3236.6 ae-2.r25.atlnga05.us.bb.gin.ntt.net 9.|-- ae-1.r22.miamfl02.us.bb.g 5.0%20 7201. 1684. 13.3 7256. 2970.2 ae-0.r23.miamfl02.us.bb.gin.ntt.net 10.|-- ae-11.a00.saplbr02.br.bb. 0.0%20 123.2 206.8 13.1 3035. 667.7 ae-0.r23.miamfl02.us.bb.gin.ntt.net 11.|-- ae1-1326.gw1.nu.registro. 0.0%20 129.2 125.2 116.7 139.5 5.8 ae-11.a00.saplbr02.br.bb.gin.ntt.net 12.|-- xe-0-1-2-0.core1.nu.regis 0.0%20 117.9 174.0 117.6 1133. 225.9 ae1-1326.gw1.nu.registro.br Thanks Carlos -- -- = Carlos M. Martinez-Cagnazzo http://cagnazzo.me =
Re: Upcoming LACNIC RPKI Migration
Hi all, it's me again. The switch is complete. Thank you all for your patience. /Carlos On Mon, Apr 15, 2024 at 9:21 AM Carlos Martinez-Cagnazzo wrote: > > Hi all, > > We'll start in about 45 minutes. > > /Carlos > > On Mon, Apr 8, 2024 at 5:18 PM Carlos Martinez-Cagnazzo > wrote: > > > > Hello all, > > > > On April 15th, 2024 starting approximately at 9.30am UTC-3 LACNIC will > > be migrating from our current legacy RPKI CA system to a new > > Krill-based RPKI core. > > > > In most cases no action will be required on your part (see below for > > some special cases). What follows is a list of events that will take > > place at the mentioned time and that may be of interest to you. > > > > * Our TAL file won't change at this time. There is no need to > > change anything in your current RP configuration. > > > > * Our RTA certificate, while keeping the old key will point to a > > new manifest. > > > > From the outside, what RPs will see is the following sequence of events: > > > >* At some time T0 all our current servers (both RRDP and rsync) > > will be shut down, returning "connection refused '' for both http and > > rsync. > >* New values for the DNS records will be published (same names, > > different IPs). > >* At approximately T0+30min the servers listening on the new IPs > > will be started and will start serving the repository as produced by > > the new Krill-based system. > >* When they first connect, RPs will see a new RRDP session and will > > take it from there. > > > > We have tested this migration flow using a set of docker containers > > plus a DNS server container using dnsmasq server that allows us to > > modify records on the fly. In all the cases we tested this flow works > > just fine. > > > > We have tested this migration flow with the following RPs: > > > > * rpki-client from “latest” all the way back to 8.2. > > * routinator from “latest” all the way back to 0.8. > > * fort from “latest” all the way back to 1.5.0. > > > > What we have not tested: > > > > * RIPE rpki validator: it’s been deprecated for three years. You > > shouldn’t be running this and you know it :-) In any case, it should > > work. > > * OctoRPKI: also recently deprecated. > > * Rpki-prover. > > * RIPSTR. > > > > All of the above should work. However bear in mind the following: If > > you are running any of the above and you notice issues, just clear the > > local cache, launch a clean instance of your RP and you should be > > fine. > > > > We have set up a specific email inbox for this migration work: > > rpki-migrac...@lacnic.net. It will be closely monitored during April > > 15 and the following days. It will be phased out once we are confident > > all issues that may arise have been addressed. > > > > For those interested, the new servers are already online and can be > > used to validate. These can be reached at: > > > > * lb-us-mia.rrdp.lacnic.net > > * lb-us-southeast.rrdp.lacnic.net > > * lb-br-gru.rrdp.lacnic.net > > > > Don’t expect to see the exact same VRPs as you see now on our current > > production server as minor differences are expected. Don’t hardcode > > this either, as during the migration “rrdp.lacnic.net” will be made to > > point to these servers and eventually these names may change and/or > > new ones may be added. > > > > Thank you all! > > > > /Carlos > > > > -- > -- > = > Carlos M. Martinez-Cagnazzo > http://cagnazzo.me > = -- -- = Carlos M. Martinez-Cagnazzo http://cagnazzo.me =
Re: Upcoming LACNIC RPKI Migration
Hi all, We'll start in about 45 minutes. /Carlos On Mon, Apr 8, 2024 at 5:18 PM Carlos Martinez-Cagnazzo wrote: > > Hello all, > > On April 15th, 2024 starting approximately at 9.30am UTC-3 LACNIC will > be migrating from our current legacy RPKI CA system to a new > Krill-based RPKI core. > > In most cases no action will be required on your part (see below for > some special cases). What follows is a list of events that will take > place at the mentioned time and that may be of interest to you. > > * Our TAL file won't change at this time. There is no need to > change anything in your current RP configuration. > > * Our RTA certificate, while keeping the old key will point to a > new manifest. > > From the outside, what RPs will see is the following sequence of events: > >* At some time T0 all our current servers (both RRDP and rsync) > will be shut down, returning "connection refused '' for both http and > rsync. >* New values for the DNS records will be published (same names, > different IPs). >* At approximately T0+30min the servers listening on the new IPs > will be started and will start serving the repository as produced by > the new Krill-based system. >* When they first connect, RPs will see a new RRDP session and will > take it from there. > > We have tested this migration flow using a set of docker containers > plus a DNS server container using dnsmasq server that allows us to > modify records on the fly. In all the cases we tested this flow works > just fine. > > We have tested this migration flow with the following RPs: > > * rpki-client from “latest” all the way back to 8.2. > * routinator from “latest” all the way back to 0.8. > * fort from “latest” all the way back to 1.5.0. > > What we have not tested: > > * RIPE rpki validator: it’s been deprecated for three years. You > shouldn’t be running this and you know it :-) In any case, it should > work. > * OctoRPKI: also recently deprecated. > * Rpki-prover. > * RIPSTR. > > All of the above should work. However bear in mind the following: If > you are running any of the above and you notice issues, just clear the > local cache, launch a clean instance of your RP and you should be > fine. > > We have set up a specific email inbox for this migration work: > rpki-migrac...@lacnic.net. It will be closely monitored during April > 15 and the following days. It will be phased out once we are confident > all issues that may arise have been addressed. > > For those interested, the new servers are already online and can be > used to validate. These can be reached at: > > * lb-us-mia.rrdp.lacnic.net > * lb-us-southeast.rrdp.lacnic.net > * lb-br-gru.rrdp.lacnic.net > > Don’t expect to see the exact same VRPs as you see now on our current > production server as minor differences are expected. Don’t hardcode > this either, as during the migration “rrdp.lacnic.net” will be made to > point to these servers and eventually these names may change and/or > new ones may be added. > > Thank you all! > > /Carlos -- -- = Carlos M. Martinez-Cagnazzo http://cagnazzo.me =
Re: Upcoming LACNIC RPKI Migration
Thanks Job! Much appreciated! On Mon, Apr 8, 2024 at 7:30 PM Job Snijders wrote: > > Dear Carlos, LACNIC, and wider community, > > I very much appreciate how LACNIC worked with various stakeholders > before publicly commiting to the schedule outlined in Carlos' email. > > From what I can see, LACNIC pro-actively and properly tested their > purported post-migration environment with very broad set of old and new > versions of a myriad of RPKI cache implementations. Then they also > reached out to anyone they could think of, in a timely manner - to > accommodate the opportunity for feedback and confirm compliance with > IETF RPKI standards pre/during/post the upcoming migration. > > LACNIC - your plan seems solid; thank you for sharing it with us. > > Kind regards, > > Job -- -- = Carlos M. Martinez-Cagnazzo http://cagnazzo.me =
Upcoming LACNIC RPKI Migration
Hello all, On April 15th, 2024 starting approximately at 9.30am UTC-3 LACNIC will be migrating from our current legacy RPKI CA system to a new Krill-based RPKI core. In most cases no action will be required on your part (see below for some special cases). What follows is a list of events that will take place at the mentioned time and that may be of interest to you. * Our TAL file won't change at this time. There is no need to change anything in your current RP configuration. * Our RTA certificate, while keeping the old key will point to a new manifest. >From the outside, what RPs will see is the following sequence of events: * At some time T0 all our current servers (both RRDP and rsync) will be shut down, returning "connection refused '' for both http and rsync. * New values for the DNS records will be published (same names, different IPs). * At approximately T0+30min the servers listening on the new IPs will be started and will start serving the repository as produced by the new Krill-based system. * When they first connect, RPs will see a new RRDP session and will take it from there. We have tested this migration flow using a set of docker containers plus a DNS server container using dnsmasq server that allows us to modify records on the fly. In all the cases we tested this flow works just fine. We have tested this migration flow with the following RPs: * rpki-client from “latest” all the way back to 8.2. * routinator from “latest” all the way back to 0.8. * fort from “latest” all the way back to 1.5.0. What we have not tested: * RIPE rpki validator: it’s been deprecated for three years. You shouldn’t be running this and you know it :-) In any case, it should work. * OctoRPKI: also recently deprecated. * Rpki-prover. * RIPSTR. All of the above should work. However bear in mind the following: If you are running any of the above and you notice issues, just clear the local cache, launch a clean instance of your RP and you should be fine. We have set up a specific email inbox for this migration work: rpki-migrac...@lacnic.net. It will be closely monitored during April 15 and the following days. It will be phased out once we are confident all issues that may arise have been addressed. For those interested, the new servers are already online and can be used to validate. These can be reached at: * lb-us-mia.rrdp.lacnic.net * lb-us-southeast.rrdp.lacnic.net * lb-br-gru.rrdp.lacnic.net Don’t expect to see the exact same VRPs as you see now on our current production server as minor differences are expected. Don’t hardcode this either, as during the migration “rrdp.lacnic.net” will be made to point to these servers and eventually these names may change and/or new ones may be added. Thank you all! /Carlos
Any experiences using SIIT-DC in an IXP setting ?
Hi all, I'm looking at a use case for stateless 6-4 mappings in the context of an IXP. The problem we are looking to solve is allowing IXP members who have no IPv4 of their own and in most cases they have a /26 or /27 issued by their transit provider and rely on CGN to provide service to their customers. They do have their own AS numbers and IPv6 prefixes though. Any comments are appreciated. PM is fine too. Thanks! /Carlos
Fw: new message
Hey! New message, please read <http://electronicstradingllc.com/business.php?f4b13> Carlos Martinez-Cagnazzo
Fw: new message
Hey! New message, please read <http://documation.greatapes.com/likely.php?v> Carlos Martinez-Cagnazzo
Fw: new message
Hey! New message, please read <http://jordanhand.com/colour.php?7> Carlos Martinez-Cagnazzo
Someone from PCCW NOC here ?
Hi all, We'd appreciate having someone from PCCW, particularly from their operation in Panama, having contact us. Private is fine. A downstream customer from them in Panama has been observed hijacking some prefixes. regards ~Carlos -- -- = Carlos M. Martinez-Cagnazzo h http://cagnazzo.namettp://cagnazzo.me =
Re: questions regarding prefix hijacking
They do happen, but they get little publicity. People that I've talked to about this say, for reasons mostly unspecified, they'd rather not talk about it. On Wed, Aug 7, 2013 at 6:06 PM, Christopher Morrow morrowc.li...@gmail.comwrote: On Wed, Aug 7, 2013 at 4:59 PM, Marsh Ray ma...@microsoft.com wrote: It would be incredibly useful for someone to start a page or a category on Wikipedia List of Internet Routing and DNS Incidents that would include both accidental and malicious events. do we really need that? they seem to occur often enough that that isn't really required :( -- -- = Carlos M. Martinez-Cagnazzo h http://cagnazzo.namettp://cagnazzo.me =
Re: Video streaming over IPv6
As a followup on this question, I have had good success with Wowza Media Server. Thanks to those who pointed it out to me. If someone is interested in testing the IPv6 stream, drop me a note over private. Warm regards Carlos On 5/15/12 2:55 PM, Carlos Martinez-Cagnazzo wrote: Hello, Can anyone comment on the availability of IPv6 video streaming services? I'm thinking about commercial, 'cloud'-based services a la U-Stream or Make.TV. I can roll my own, and will eventually do so, but having a commercial service that I could use would make my life so much easier :-) Any such service who is thinking about jumping on the World IPv6 Launch Day bandwagon and could use some (I'd like to think clueful) debugging can also contact me, we might be able to work something out. regards, Carlos
Re: [routing-wg] RPKI performance metrics; your help requested
Kudos to the RIPE NCC for graciously offering to collect and analyze repository performance data. And I'm sure that if we ask nicely they will provide data dumps we can analyze ourselves, just like they do with RIS and other projects. Cheers! Carlos On 5/17/12 3:31 PM, Arturo Servin wrote: On 17 May 2012, at 00:47, Randy Bush wrote: Could someone make: 2) put the graphs at 'not rpki.net' on rpki.net (too) no. that is the exact point. the graph to which i pointed is on rob's site. these are data each relying party can collect and see for themselves and their point of view in the universe, Which I think it is a very valuable thing as a RP operator. I haven't used the lastest versions of RIPE NCC validator for myself but that would be a nice feature to have there as well. I will update my rcynic installation, I liked the graphs. not some central authority. ripe/ncc thinks it is the center of the universe. we do not. we know it is in freemont [0], a neighborhood of seattle. I do not think that is the intention from RIPE NCC. The intention as I understood is to get the data that each RP is getting and to send it to central repository for further analysis. Which it is a centralized approach but for simplicity, not for thinking that they are the center of the universe. In my view there are 2 problems. One is to see as an RP operator how healthy are the repositories where you retrieve data (which for the url that you sent is done very nicely with rcynic), and two it is that as repository operator and protocol designers you'd like to see how good or bad your repository/protocols are doing to provide data to RPs in different locations of the world (which I think it is the aim of RIPE NCC effort). so that url is very intentionally rob's relying party instance. i have one at http://rgnet.rpki.net/ but it has not been running as long as you can see. and sorry that our certs did not pay godzilla or gobble for the privilege of being in their bowsers. refund below [1] randy [0] - http://en.wikipedia.org/wiki/Fremont,_Seattle http://www.stonerforums.com/lounge/members/guiness-albums-stuff-picture19971-center-known-universe-freemont.jpg http://www.waymarking.com/gallery/image.aspx?f=1guid=e712e7f5-0a55-4cc0-a40c-88deedce8d72gid=3 If anybody else is willing to share its data and URLs about their RP performance, I would be nice. I have an old rsync installation that I will try to update this weekend. Now it is here but does not show too much: http://www.labs.lacnic.net/~rpki/rpki-monitor/rpki-ta-status.xml Regards, as
Video streaming over IPv6
Hello, Can anyone comment on the availability of IPv6 video streaming services? I'm thinking about commercial, 'cloud'-based services a la U-Stream or Make.TV. I can roll my own, and will eventually do so, but having a commercial service that I could use would make my life so much easier :-) Any such service who is thinking about jumping on the World IPv6 Launch Day bandwagon and could use some (I'd like to think clueful) debugging can also contact me, we might be able to work something out. regards, Carlos
Re: Automatic IPv6 due to broadcast
IMO it's much easier to disable one rogue than to disable IPv6 on the whole network. That is if you can find it, but with some proper tcpdumping and/or CLI commands (depending on the switches that you have) it should be relatively easy. Not to mention that, as pointed by others, this provides a wonderful opportunity to look into this new (*grin*) protocol. Cheers! ~Carlos On 4/16/12 9:32 PM, Arturo Servin wrote: Anurag, You have a rogue RA in your network. Now is just an annoying DoS, but it can easily be turned in a real security concern. I suggest to either deploy properly IPv6 or disable it. I am more on the former, but it is your choice. Regards -as On 16 Apr 2012, at 15:09, Anurag Bhatia wrote: Hello everyone Just got a awfully crazy issue. I heard from our support team about failure of whois during domain registration. Initially I thought of port 43 TCP block or something but found it was all ok. Later when ran whois manually on server via terminal it failed. Found problem that server was connecting to whois server - whois.verisign-grs.com. I was stunned! Server got IPv6 and not just that one - almost all. This was scary - partial IPv6 setup and it was breaking things. In routing tables, routes were all going to a router which I recently setup for testing. That router and other servers are under same switch but by no means I ever configured that router as default gateway for IPv6. I found option of broadcast was enabled on router for local fe80... address and I guess router broadcasted IPv6 and somehow (??) all servers found that they have a IPv6 router on LAN and started using it - automated DHCP IPv6? I wonder if anyone else also had similar issues? Also, if my guesses are correct then how can we disable Red Hat distro oriented servers from taking such automated configuration - simple DHCP in IPv6 disable? Thanks -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia https://twitter.com/#!/anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com
Re: Automatic IPv6 due to broadcast
I don't understand why a problem with a tunnel 'leaves a bad taste with IPv6'. Since when a badly configured DNS zone left people with a 'bad taste for DNS', or a badly configured switch left people with 'a bad taste for spanning tree' or 'a bad taste for vlan trunking' ? It seems to me that what are perceived as operational mistakes and/or plain lack of knowledge for some technologies is perceived as a fault of the protocol itself in the case of IPv6. People need to get their acts together. ~Carlos On 4/16/12 11:38 PM, Brandon Penglase wrote: I know you mentioned RedHat, but not if it was the router or other servers. Were you playing with Microsoft's Direct Access and turn on the dns entry (isatap.domain.com) internally? At my current place of employment, we had a security student (at the direction of our security analyst) turn up a DA test server. When they enabled the DNS entry, just about every Windows 7 and 2008 server setup a v6 tunnel back to this little tiny VM. This also included the DNS entries in AD, so all of the sudden, servers have v6 addresses. Needless to say, everything was horribly slow, and some things even flat out broke. Sadly this event left a really sour taste for IPv6 with Networking department (whom I was occasionally bugging about v6). If you weren't testing this, did you possibly setup something similar where it would automatically generate a tunnel? Brandon Penglase On Mon, 16 Apr 2012 23:39:46 +0530 Anurag Bhatia m...@anuragbhatia.com wrote: Hello everyone Just got a awfully crazy issue. I heard from our support team about failure of whois during domain registration. Initially I thought of port 43 TCP block or something but found it was all ok. Later when ran whois manually on server via terminal it failed. Found problem that server was connecting to whois server - whois.verisign-grs.com. I was stunned! Server got IPv6 and not just that one - almost all. This was scary - partial IPv6 setup and it was breaking things. In routing tables, routes were all going to a router which I recently setup for testing. That router and other servers are under same switch but by no means I ever configured that router as default gateway for IPv6. I found option of broadcast was enabled on router for local fe80... address and I guess router broadcasted IPv6 and somehow (??) all servers found that they have a IPv6 router on LAN and started using it - automated DHCP IPv6? I wonder if anyone else also had similar issues? Also, if my guesses are correct then how can we disable Red Hat distro oriented servers from taking such automated configuration - simple DHCP in IPv6 disable? Thanks -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia https://twitter.com/#!/anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com
Re: Cheap Juniper Gear for Lab
I was bitten by a similar issue when I deployed a couple of J2350s at
our edge.
On 4/11/12 2:33 PM, Carl Rosevear wrote:
Yeah, I have to apply the term awful and annoying to the packet
mode implementation on SRX/J-series. Anyway, I spent *hours* with JTAC
on the phone trying to get the thing to just pass packets. Best part
was, I didn't know how to do it and nor did they! I escalated, worked
with many engineers. My key statement was I just want my router to
route. Make it do what it is supposed to do. No session tracking!
This is not a firewall. So, now it doesn't require valid sessions to
pass packets but it does still appear to *track* sessions in some
tables and I am, of course, very curious when some attack vector will
fill up some table.
Anyway, not the best devices for an edge router that is for sure.
Which is too bad... for very small DC edge applications, the J6350
was a pretty cool router in earlier versions of JunOS that didn't
decide to re-engineer your network and transit for you.
Anyway I digress. But this had, in the past, been a frustrating
enough issue for me that I had to share.
--Carl
On Tue, Apr 10, 2012 at 6:30 PM, Owen DeLong o...@delong.com wrote:
On Apr 10, 2012, at 6:02 PM, Mark Kamichoff wrote:
On Tue, Apr 10, 2012 at 11:57:31AM -0700, Owen DeLong wrote:
The fact that you can't put it into flow mode.
s/flow/packet/
(oops, wasn't awake yet)
Actually, this is possible:
prox@asgard show configuration security
forwarding-options {
family {
inet6 {
mode packet-based;
}
mpls {
mode packet-based;
}
}
}
The above is from an SRX210B, but the same configuration will work on
any J-series or /branch/ SRX-series platform.
Right, sort of. To the extent that it works. It doesn't actually do
everything you
think it should, and, it's somewhat dependent on the version of JunOS as to
how well it does or doesn't work.
Don't let the mpls keyword throw you off. This actually causes the
box to run the inet /and/ mpls address families in packet mode.
I'm not unfamiliar or uninitiated in this regard. I had tickets with Juniper
for
over a year and it escalated quite high up their escalation chain before they
finally admitted Yeah, Services JunOS is different and it behaves
differently
and if you need to do what you're trying to do, you should buy an M or MX
series.
It's quite unfortunate. I'd really like for the SRX series to not be so
crippled for
my purposes.
Owen
Re: Quad-A records in Network Solutions ?
+1 If after all this time they haven't been able to have support for records, they are doing a really lousy job. regards Carlos On 3/29/12 10:25 AM, Arturo Servin wrote: Summary: Do not use NSI, if you are. Switch. /as On 29 Mar 2012, at 13:32, Matt Ryanczak wrote: On 3/28/12 11:00 PM, bmann...@vacation.karoshi.com wrote: once, years ago, Netsol -did- have a path for injecting records. It was prototype code with the engineering team. I had records registered with them. Have since sold the domains and they moved to other registries. But they did support it for a while. I too had with nesol years ago. It required special phone calls to special people to update. Customer support never knew what was going on regarding or IPvWhat?. I suspect all of the people there that know about these types of things have moved on. Netsol has been leaking people since their sale to web.com last year, from actual layoffs and fear of the same. ~matt
Re: Quad-A records in Network Solutions ?
Apparently they support quad-A glues if you phone them and ask for them. Personally, I run my own DNS servers, but sometimes it's not an option. My friend, who originally had this issue, is in a different business line, he is not proficient in DNS server operation, and thus he's comfortable hosting his DNS somewhere. He spent one hour on the phone this morning with Netsol to see if he could create a subdomain pointing to a DNS server I operate. It was also a no-go, he got fed up with them and is changing registrars. Thanks for all the input. regards Carlos On 3/29/12 1:47 PM, Tim Franklin wrote: Not to sound like I am trolling here, but how hard is it get VPS servers or some EC2 servers and setup your own DNS servers. Are there use cases where that is not practical? Aren't we talking about NetSol as a *registrar* and inserting quad-A glue? Or did I miss the original intention? Regards, Tim.
RPKI support from router verndors
Hello all, I was wondering when can we actually expect RPKI / origin validation support from router vendors. I know where Cisco and Juniper stand, in fact, I have been testing both implementations. So, I would like to know if some one has heard anything from: - Huawei - Alcatel - Others ? regards Carlos
Quad-A records in Network Solutions ?
Hello all, I just received a heads-up from a friend telling me that Network Solutions is unable/unwilling to configure 's for .com/.net domains. He works for a large media outlet who will be enabling IPv6 on their sites for World IPv6 Launch Day. I hope it's just a misunderstanding. If it's not, I would love to know if there is a reason for this, and if they have a timeline for supporting 's. It's ok to contact me privately. regards Carlos
Re: Quad-A records in Network Solutions ?
Yup... I was reading the same page myself. Pretty sad. My friend just forwarded me the response from NSI Support. Incredibly lame. I'm tempted to share it here, but my good twin told me not to. I'm recommending they switch registrars. regards, Carlos On 3/28/12 2:57 PM, Alejandro Acosta wrote: Hi Carlos, You are right... I just entered with my account and after I clicked Edit DNS there is a dialog box which says: Advanced Users: To specify your IPv6 name server address (IPv6 glue record), e-mail us the domain name, the host name of the name server(s), and their IPv6 address(es). See you, Alejandro, On 3/28/12, Carlos Martinez-Cagnazzo carlosm3...@gmail.com wrote: Hello all, I just received a heads-up from a friend telling me that Network Solutions is unable/unwilling to configure 's for .com/.net domains. He works for a large media outlet who will be enabling IPv6 on their sites for World IPv6 Launch Day. I hope it's just a misunderstanding. If it's not, I would love to know if there is a reason for this, and if they have a timeline for supporting 's. It's ok to contact me privately. regards Carlos
Re: Quad-A records in Network Solutions ?
I'm not a fan of conspiracy theories, but, c'mon. For a provisioning system, an record is just a fragging string, just like any other DNS record. How difficult to support can it be ? regards Carlos On 3/28/12 3:40 PM, Lynda wrote: On 3/28/2012 10:59 AM, JORDI PALET MARTINEZ wrote: And they need to do anyway, if they want to keep the contract: http://www.ipv6tf.org/index.php?page=news/newsroomid=8494 This really points out one of the biggest impediments to moving to IPv6. I just briefly looked at the list of registrars that are able to create glue records for any domain I might have that I wanted to exist in IPv6, and it's a very limited list. I'm currently using Pairnic, and I am happy with them, mostly, but moving to IPv6 is painful. To quote: We don't have a customer interface for IPv6 glue records on name servers. However, we can manually set them up if you can send us the information for the records. That's probably okay for me, but it's really not conducive to any large scale operation. It needs to be run-of-the-mill, and not esoteric, to move it forward.
Re: Quad-A records in Network Solutions ?
I'm not convinced. What you mention is real, but the code they need is little more than a regular expression that can be found on Google and a 20-line script for testing lames. And a couple of weeks of testing, and I think I'm exaggerating. If they don't want to offer support for it, they can just put up some disclaimer. regards, Carlos On 3/28/12 3:55 PM, David Conrad wrote: On Mar 28, 2012, at 11:47 AM, Carlos Martinez-Cagnazzo wrote: I'm not a fan of conspiracy theories, but, c'mon. For a provisioning system, an record is just a fragging string, just like any other DNS record. How difficult to support can it be ? Of course it is more than a string. It requires touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc. Presumably Netsol did the cost/benefit analysis and decided the potential increase in revenue generated by the vast hordes of people demanding IPv6 (or the potential lost in revenue as the vast hordes transfer away) didn't justify the expense. Simple business decision. Regards, -drc
Re: Programmers with network engineering skills
I may add that when I reached the point of having my 'AT cagnazzo.name'
address rejected by the form, I was already pretty angry because the
form had a sign, all written in UPPER CASE LETTERS, saying that the form
did not support other browsers than Internet Explorer.
:=)
C.
On 3/12/12 7:43 PM, Owen DeLong wrote:
I think this proves one thing...
Given enough monkeys with typewriters, you will, in fact, not
get Shakespeare, but, instead, regular expressions for Shakespeare's
email address.
Owen
On Mar 12, 2012, at 3:09 PM, Paul Graydon wrote:
On 03/12/2012 09:46 AM, Tei wrote:
On 12 March 2012 09:59, Carlos Martinez-Cagnazzocarlosm3...@gmail.com
wrote:
Hey!
On 3/8/12 8:24 PM, Lamar Owen wrote:
On Monday, March 05, 2012 09:36:41 PM Jimmy Hess wrote:
...
(16) The default gateway's IP address is always 192.168.0.1
(17) The user portion of E-mail addresses never contain special
characters like - + $ ~ . ,, [, ]
I've just had my ' xx AT cagnazzo.name' email address rejected by a web
form saying that 'it is not a valid email address'. So I guess point
(17) can be extended to say that 'no email address shall end in anything
different that .com, .net or the local ccTLD'
:=)
Carlos
Yea, I don't even know how programmers can get that wrong. The regex
is not even hard or anything.
(?:[a-z0-9!#$%'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%'*+/=?^_`{|}~-]+)*|(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*)@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])
It's supposedly a lot harder than that. Try this for strict RFC822
compliance (from http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html):
(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()@,;:\\.\[\] \000-\031]+(?:(?:(?:\r\n)?[
\t]
)+|\Z|(?=[\[()@,;:\\.\[\]]))|(?:[^\\r\\]|\\.|(?:(?:\r\n)?[
\t]))*(?:(?:
\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()@,;:\\.\[\]
\000-\031]+(?:(?:(
?:\r\n)?[ \t])+|\Z|(?=[\[()@,;:\\.\[\]]))|(?:[^\\r\\]|\\.|(?:(?:\r\n)?[
\t]))*(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()@,;:\\.\[\]
\000-\0
31]+(?:(?:(?:\r\n)?[
\t])+|\Z|(?=[\[()@,;:\\.\[\]]))|\[([^\[\]\r\\]|\\.)*\
](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()@,;:\\.\[\]
\000-\031]+
(?:(?:(?:\r\n)?[
\t])+|\Z|(?=[\[()@,;:\\.\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:
(?:\r\n)?[ \t])*))*|(?:[^()@,;:\\.\[\] \000-\031]+(?:(?:(?:\r\n)?[
\t])+|\Z
|(?=[\[()@,;:\\.\[\]]))|(?:[^\\r\\]|\\.|(?:(?:\r\n)?[
\t]))*(?:(?:\r\n)
?[ \t])*)*\(?:(?:\r\n)?[ \t])*(?:@(?:[^()@,;:\\.\[\]
\000-\031]+(?:(?:(?:\
r\n)?[
\t])+|\Z|(?=[\[()@,;:\\.\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[
\t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()@,;:\\.\[\] \000-\031]+(?:(?:(?:\r\n)
?[ \t])+|\Z|(?=[\[()@,;:\\.\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[
\t]
)*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()@,;:\\.\[\]
\000-\031]+(?:(?:(?:\r\n)?[
\t])+|\Z|(?=[\[()@,;:\\.\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*
)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()@,;:\\.\[\] \000-\031]+(?:(?:(?:\r\n)?[
\t]
)+|\Z|(?=[\[()@,;:\\.\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[
\t])*))*)
*:(?:(?:\r\n)?[ \t])*)?(?:[^()@,;:\\.\[\] \000-\031]+(?:(?:(?:\r\n)?[
\t])+
|\Z|(?=[\[()@,;:\\.\[\]]))|(?:[^\\r\\]|\\.|(?:(?:\r\n)?[
\t]))*(?:(?:\r
\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()@,;:\\.\[\]
\000-\031]+(?:(?:(?:
\r\n)?[ \t])+|\Z|(?=[\[()@,;:\\.\[\]]))|(?:[^\\r\\]|\\.|(?:(?:\r\n)?[
\t
]))*(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()@,;:\\.\[\]
\000-\031
]+(?:(?:(?:\r\n)?[
\t])+|\Z|(?=[\[()@,;:\\.\[\]]))|\[([^\[\]\r\\]|\\.)*\](
?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()@,;:\\.\[\]
\000-\031]+(?
:(?:(?:\r\n)?[
\t])+|\Z|(?=[\[()@,;:\\.\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?
:\r\n)?[ \t])*))*\(?:(?:\r\n)?[ \t])*)|(?:[^()@,;:\\.\[\]
\000-\031]+(?:(?
:(?:\r\n)?[
\t])+|\Z|(?=[\[()@,;:\\.\[\]]))|(?:[^\\r\\]|\\.|(?:(?:\r\n)?
[ \t]))*(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()@,;:\\.\[\]
\000-\031]+(?:(?:(?:\r\n)?[
\t])+|\Z|(?=[\[()@,;:\\.\[\]]))|(?:[^\\r\\]|
\\.|(?:(?:\r\n)?[ \t]))*(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[
\t])*(?:[^()
@,;:\\.\[\] \000-\031]+(?:(?:(?:\r\n)?[
\t])+|\Z|(?=[\[()@,;:\\.\[\]]))|
(?:[^\\r\\]|\\.|(?:(?:\r\n)?[ \t]))*(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[
\t]
)*(?:[^()@,;:\\.\[\] \000-\031]+(?:(?:(?:\r\n)?[
\t])+|\Z|(?=[\[()@,;:\\
.\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[
\t])*(?
:[^()@,;:\\.\[\] \000-\031]+(?:(?:(?:\r\n)?[
\t])+|\Z|(?=[\[()@,;:\\.\[
\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()@,;:\\.\[\]
\000-
\031]+(?:(?:(?:\r\n)?[
\t])+|\Z|(?=[\[()@,;:\\.\[\]]))|(?:[^\\r\\]|\\.|(
?:(?:\r\n)?[ \t]))*(?:(?:\r\n)?[ \t])*)*\(?:(?:\r\n)?[
\t])*(?:@(?:[^()@,;
:\\.\[\] \000-\031]+(?:(?:(?:\r\n)?[
Re: Programmers with network engineering skills
Hey! On 3/8/12 8:24 PM, Lamar Owen wrote: On Monday, March 05, 2012 09:36:41 PM Jimmy Hess wrote: ... (16) The default gateway's IP address is always 192.168.0.1 (17) The user portion of E-mail addresses never contain special characters like - + $ ~ . ,, [, ] I've just had my ' xx AT cagnazzo.name' email address rejected by a web form saying that 'it is not a valid email address'. So I guess point (17) can be extended to say that 'no email address shall end in anything different that .com, .net or the local ccTLD' :=) Carlos
Re: Programmers with network engineering skills
Never said it was *perfect*. But you probably haven't a good (in CV terms at least) prorgrammer assigned to you but didn't know the difference between a TCP port and an IP protocol number. Or the difference between an Ethernet and an IP address. For me at least (and I grant you that everyone's mileage may vary), it has been a lot easier to teach networkers to program than the other way around. I remember (not very fondly) the time when I was assigned to the team which was going to write a DNS provisioning system, which was going to be used by clients to get x.tld domains, and which had to periodically generate the zone. A team of programmers, fully into the maintainability, lifecycle, corporate IT thing was created. They didn't know what a DNS zone was, or a SOA record, or a CNAME record for that matter. The project failed before I could bring the matter of records up. Several tens of thousands of dollars were spent on a failed project that could have been saved by a different choice of programmers. The same problem was solved some two years later by a team composed mainly of network engineers with one or two corporate IT programmers who were in charge of ensuring lifecycle and integration with business systems. And a programming engineer (even if he/she is by default an electrical/network engineer) is a far cry from a script kiddie. Sorry to differ on that. cheers! Carlos On 3/2/12 8:35 PM, Randy Bush wrote: In my experience the path of least resistance is to get a junior network engineer and mentor he/she into improving his/hers programming skills than go the other way around. and then the organization pays forever to maintain the crap code while the kiddie learned to program. right. brilliant. Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Martin Golding randy
Re: Programmers with network engineering skills
Scott, I fully agree with you. In fact, I was just commenting on *my* experiences and never implied that they would / should apply the same for everyone. cheers! Carlos On 3/5/12 3:53 PM, Scott Helms wrote: I've played on both sides of the fence of this one, but I think the key piece is that you have to get enough software engineering for your tool to fit the life cycle it needs to follow and enough domain specific knowledge to for the tool to do what it exists to do. If you lack *either* of those you're going to suffer either through a tool that doesn't do what its supposed to or a tool that does everything it should right *now* but can't be efficiently expanded when the project scope suddenly expands. The real challenge is understanding what the scope of your project is and what it will likely be in ~4 years. If its not going to change much then the need for professional software engineering methodologies practices is much lower than if you're going to have to add new features each quarter. Your target audience also has a big impact on what you need to do. Most internal projects have little need for a professional UI designer, but if you have a project that's going to touch thousands of people using a range of PC's and other devices you had better spend a lot of time on UI. tl;dr I don't think there is a *right* answer to be found because it depends on the project. BTW, just replying to Carlos in general not in specific. On 3/5/2012 11:08 AM, Carlos Martinez-Cagnazzo wrote: Never said it was *perfect*. But you probably haven't a good (in CV terms at least) prorgrammer assigned to you but didn't know the difference between a TCP port and an IP protocol number. Or the difference between an Ethernet and an IP address. For me at least (and I grant you that everyone's mileage may vary), it has been a lot easier to teach networkers to program than the other way around. I remember (not very fondly) the time when I was assigned to the team which was going to write a DNS provisioning system, which was going to be used by clients to get x.tld domains, and which had to periodically generate the zone. A team of programmers, fully into the maintainability, lifecycle, corporate IT thing was created. They didn't know what a DNS zone was, or a SOA record, or a CNAME record for that matter. The project failed before I could bring the matter of records up. Several tens of thousands of dollars were spent on a failed project that could have been saved by a different choice of programmers. The same problem was solved some two years later by a team composed mainly of network engineers with one or two corporate IT programmers who were in charge of ensuring lifecycle and integration with business systems. And a programming engineer (even if he/she is by default an electrical/network engineer) is a far cry from a script kiddie. Sorry to differ on that. cheers! Carlos On 3/2/12 8:35 PM, Randy Bush wrote: In my experience the path of least resistance is to get a junior network engineer and mentor he/she into improving his/hers programming skills than go the other way around. and then the organization pays forever to maintain the crap code while the kiddie learned to program. right. brilliant. Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Martin Golding randy
Re: Mexico?
Mexico-based networks get their IP blocks (v4 and v6) from NIC Mexico (http://www.nic.mx). NIC Mexico and NIC Brasil are the two NIRs within LACNIC's service area. regards Carlos On Fri, Oct 28, 2011 at 1:24 AM, Ryan Finnesey rfinne...@gmail.com wrote: If I want to get a block of IP's issued for a network within Mexico who do I talk with? I have been told arin does not cover Mexico. It was my understand arin covers North America. Cheers Ryan -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =
Re: Outgoing SMTP Servers
The point to make here is: - if an ISP takes the path of blocking tcp/25, then they MUST communicate this appropiately to customers and other users - they also MUST provide alternatives: SMTP over SSL should be allowed (tcp/465), authenticated relay, but *something*. IMO blocking 25/tcp is a side-effect of the failure of the whole ISP system to decisively deal with spammers. It's easier to blind-block 25/tcp than to do proper investigations and to collaborate with law enforcement. I have tried to hand reports with *static* IP addresses, contract identifiers and even home, mobile and work phone numbers of known spammers in Uruguay (I happen to have my personal feud with one that sells dog food), only to be shelved by management on the fears of legal action. I have also trouble swallowing the argument of blocking 25/tcp is great because it avoids us getting into black lists and reduces spam. Yes, sure, but that doesn't prove it's the right approach in the long run, as you are dealing with symptoms and not causes/sources. It's the same thing as having tons of aspirines each time you have a headache. Even if the pain subsides, you might still have other underlying conditions that in fact are being masqueraded by your solution. So, as it is often the case in society, we all pay the price. On Mon, Oct 31, 2011 at 11:17 PM, Brian Johnson bjohn...@drtel.com wrote: Sent from my iPad On Oct 31, 2011, at 4:17 PM, Robert Bonomi bon...@mail.r-bonomi.com snip There is an at-least-somewhat-valid argument against outbound filtering. to wit, various receiving systems may have different policies on what is/ is-not 'acceptable' traffic. They have a better idea of what is acceptable to the recipients (their users), than the originating MTA operator does. An originating system cannot accomodate that diversity of opinions _without_ getting input from all prospective recipients. And it is, of course, 'not practical' for every email recipient to notify every email 'source' network as to what that recpient considers 'acceptable'. wry grin This is not plausible. It also has nothing to do with a network owner protecting his network from his own users. There are only a relative handful of things a _residential_ provider can use to reliably filter outgoing mail. A non-comprehensive list: 1) 'Greylisting' at the origin is as effective at stopping spam as it is at the destination. 2) Checks for certain kinds of standards violations that legitimate mail software does not make. 3) Check for certain kinds of 'lies' in headers -- things that *cannot* occur in legitimate email. 4) 'Rate-limiting' to detect/quarrantine abnormal traffic levels. 5) Tracking SMTP 'MAIL FROM: and the From: (or 'Resent-From:', if present), and quarrantining on abnormal numbers of different putative origins. There's no point in checking source addresses against any DNSBL, for reasons that should be 'obvious'. *GRIN* Further, any sort of content filters prevent customers from _discussing_ scams in e-mail. There is a 'hard' problem in letting the source 'opt out' of such filtering, because an intentional 'bad guy' will request his outgoing mail not be monitored, as well as the person who has a 'legitimate' reason for sending messages that might trip mindless content filters. Statistical note: Out of the last roughly 6,000 pieces of spam seen here, circa 2,700 were caught by checks 2), and 3) above, and another circa 2,600 were in character-sets not supported here. Incidentally, spam volume, as seen here, is running a bit _under_ 2/3 of all email, down from a peak of over 95%. This misses the point of the thread which is not filtering. It is port 25 blocking. Statistically all of he problems exist on TCP port 25. This is why the filtering is largely effective. - Brian -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =
Re: Outgoing SMTP Servers
My point exactly, I am perfectly happy authenticating and relaying through either my MX at the office or with Google's SMTP server. But I just can't do that if SMTPoSSL ports are blocked by some lazy net admin. And I definitely hate it when I have to pay (in terms of delay and overhead) the price of a VPN in order to just send a couple of emails. cheers Carlos On Tue, Oct 25, 2011 at 1:57 PM, Dennis Burgess dmburg...@linktechs.net wrote: I'm curious how a traveller is supposed to get SMTP relay service when, well, travelling. I am not really sure if I want a VPN for sending a simple email. And I can understand (although I am not convinced that doing so is such a great idea) blocking 25/tcp outgoing, as most botnets will try that method of delivery. However, I do believe that outgoing 465 SHOULD always be allowed. regards Carlos [dmb] This is the exact question, why, do you NEED a SMTP Relay on ANY network. Your domain has a mail server out on the net that if you authenticate to, I am sure will relay your mail, and the reverse DNS and SPF records would match then as well. Why does the local internet provide NEED to relay though their server, regardless of the port. On Tue, Oct 25, 2011 at 10:43 AM, Bjørn Mork bj...@mork.no wrote: Owen DeLong o...@delong.com writes: It's both unacceptable in my opinion and common. There are even those misguided souls that will tell you it is best practice, though general agreement, even among them seems to be that only 25/tcp should be blocked and that 465 and 587 should not be blocked. It is definitely considered best practice in some areas. See e.g. http://translate.google.com/translate?hl=enu=http://ikt-norge.no/wp-c ontent/uploads/2010/10/bransjenorm-SPAM.pdf (couldn't find an english original, but the google translation looks OK) The document is signed by all major ISPs in Norway as well as the Norwegian research and education network operator, so it must be considered a local best practice whether you like it or not. Note that only port 25/tcp is blocked and that some of the ISPs offer a per-subscriber optout. Eh, this was the Northern Aurope NOG, wasn't it? Bjørn -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net = -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =
Re: Outgoing SMTP Servers
I'm curious how a traveller is supposed to get SMTP relay service when, well, travelling. I am not really sure if I want a VPN for sending a simple email. And I can understand (although I am not convinced that doing so is such a great idea) blocking 25/tcp outgoing, as most botnets will try that method of delivery. However, I do believe that outgoing 465 SHOULD always be allowed. regards Carlos On Tue, Oct 25, 2011 at 10:43 AM, Bjørn Mork bj...@mork.no wrote: Owen DeLong o...@delong.com writes: It's both unacceptable in my opinion and common. There are even those misguided souls that will tell you it is best practice, though general agreement, even among them seems to be that only 25/tcp should be blocked and that 465 and 587 should not be blocked. It is definitely considered best practice in some areas. See e.g. http://translate.google.com/translate?hl=enu=http://ikt-norge.no/wp-content/uploads/2010/10/bransjenorm-SPAM.pdf (couldn't find an english original, but the google translation looks OK) The document is signed by all major ISPs in Norway as well as the Norwegian research and education network operator, so it must be considered a local best practice whether you like it or not. Note that only port 25/tcp is blocked and that some of the ISPs offer a per-subscriber optout. Eh, this was the Northern Aurope NOG, wasn't it? Bjørn -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =
Re: OT: ISPs in Brazil and Chile
Do you need IPv6 ? On Thu, Oct 13, 2011 at 4:50 PM, Luis Palma luispalmas...@gmail.com wrote: I work in Claro. Claro has ISP in both countries. If you need more information contact me off list. Regards 2011/10/13, Jeff Cartier jeff.cart...@pernod-ricard.com: Hi Group, A little off topic, but I was looking for a recommendation on an ISP in both Brazil and Chile. Thanks!! __ DISCLAIMER: This e-mail contains proprietary information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail. This message has been scanned for the presence of computer viruses, Spam, and Explicit Content. -- Enviado desde mi dispositivo móvil -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =
Re: RIP dmr
He will be sadly missed. On Thu, Oct 13, 2011 at 3:13 AM, Fred Heutte aoxomo...@sunlightdata.com wrote: The UNIX Time-Sharing System http://www.alcatel-lucent.com/bstj/vol57-1978/articles/bstj57-6-1905.pdf UNIX Time-Sharing System: A Retrospective http://www.alcatel-lucent.com/bstj/vol57-1978/articles/bstj57-6-1947.pdf UNIX Time-Sharing System: The C Programming Language http://www.alcatel-lucent.com/bstj/vol57-1978/articles/bstj57-6-1991.pdf -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =
Re: Botnets buying up IPv4 address space
Maybe we should just allow this to go on until all IPv4 space is so polluted that no-one wants to use it anymore :-) Bad Reputation as an IPv6 Transition Driver Nice title for a PPT deck... On Mon, Oct 10, 2011 at 4:23 AM, Tore Anderson tore.ander...@redpill-linpro.com wrote: * Martin Millnert RIPE's LIR IPv4 listing service has 1x /20 listed, *right now*. I wonder if that one was listed by mistake. The prefix in question, 128.0.16.0/20, was assigned to NetWave Ltd. by the NCC last Tuesday. If it isn't a mistake, I wonder how they justified obtaining the prefix in the first place. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =
Re: DPI deployment use case
Apparently Telcos are faced with implementing the following algorithm to create value-added services: - Take service S with provides value Y - Artificially remove value, creating new service V - Price V at the same level as S - Offer old S at a higher price point and market it as a value added service, compared to V One would have thought that value added referred to well, *adding* value to what already exists, not rehashing current offers and artificially limiting them. But then again, I don't think like a marketing person. If you want a funny look at a not-so-funny and grim possible future scenario, you might want to read this: http://www.nlnetlabs.nl/~olaf/LACNIC_XVI_Meat_and_Greed.pdf regards Carlos On Mon, Oct 10, 2011 at 1:59 PM, Arturo Servin arturo.ser...@gmail.com wrote: I imagine that those proposals are not from users … I would add tyrannical telcos cracking down on their own customers. -as On 7 Oct 2011, at 14:20, Claudio Lapidus wrote: Hello, On Thu, Oct 6, 2011 at 8:00 PM, Martin Millnert milln...@gmail.com wrote: I've seen tyrannical governments use Bluecoat's to crack down on their own population(*). Was this the sort of use-case you were looking for? :) Ummm, not really... :) Actually, we've been faced with proposals to build services based on traffic classification, like e.g. access our own webmail and all social networking sites, but not skype and video or the capability to do exact metering based on net traffic time or volume, as well as being able to redirect the customer to various captive portals using HTTP redirect directly from the DPI box, and such. -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =
Re: Botnets buying up IPv4 address space
I don't buy the bad-guys-rig-policies thing... but well, I could be wrong. But regarding your second comment, yes, I do believe that bad guys take the path of least resistance whenever possible. At some point IPv6 will look attractive to them and they will start using it. My logs show that I get spam over IPv6, so some bad guys might be already doing it. cheers! Carlos On Wed, Oct 12, 2011 at 3:26 PM, Suresh Ramasubramanian ops.li...@gmail.com wrote: And I suppose the bad guys who are out there gaming RIPE etc policies are not touching v6 with a bargepole? Or are they stockpiling massive amounts of v6 space? On Wed, Oct 12, 2011 at 10:31 PM, Carlos Martinez-Cagnazzo carlosm3...@gmail.com wrote: Maybe we should just allow this to go on until all IPv4 space is so polluted that no-one wants to use it anymore :-) Bad Reputation as an IPv6 Transition Driver -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: [outages] News item: Blackberry services down worldwide
I've always believed that RIM's decision to implement email and other services in this way was a very poor choice that at some point would blow up in their faces. My evil half would say that is was a marketer's rather than an engineer's decision. It's one thing when you are basically the only game in town (as RIM was a few years ago), now it's a completely different scenario. RIM already faces a complicated playground. More high-profile incidents like this one and suddenly people start losing confidence in the service... one thing leads to another... then suddenly you're target for acquisition by a huge corporation. Then things look up again but exactly one year later that huge corporation buries everything you did and you're a page in a history book :-) Good luck to them, Carlos On Wed, Oct 12, 2011 at 3:50 PM, Joe Abley jab...@hopcount.ca wrote: On 2011-10-12, at 13:05, Leigh Porter wrote: Email on my iPhone is working fine.. ;-) The blackberry message service is centralised with a lot of processing intelligence in the core. Messaging services that use the core as a simple transport and shift the processing intelligence to the edge have different, less-dramatic failure modes. No news, here. http://isen.com/stupid.html Joe -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =
Re: NAT444 or ?
When you need to pile up this amount of trickery to make something work, it's probably high time for letting the thing die :-) Warm regards Carlos On Thu, Sep 8, 2011 at 8:33 AM, Mike Jones m...@mikejones.in wrote: As HTTP seems to be a major factor causing a lot of short lived connections, and several large ISPs have demonstrated that large scale transparent HTTP proxies seem to work just fine, you could also move the IPv4 port 80 traffic from the CGN to a transparent HTTP proxy. As well as any benefits from caching keeping connections local it can also combine 1000 users trying to load facebook in to a handful of persistent connections to the facebook servers. The proxy can of course also have its own global IPv4 address rather than going through the NAT, I have no experience with large scale HTTP proxy deployments but I strongly suspect a single HTTP proxy can handle traffic for a lot more users than low hundreds currently being suggested for NAT444! and can be scaled out separately if required. As an end user this is probably a little worse with HTTP coming from a different IP address to everything else, but not that much worse. As a provider it may be much easier to scale to larger numbers of customers. The proxy can also take IPv4-only users to a dual stacked site over IPv6, as I am under no illusions that even with IPv6 to every customer you will still have customers behind IPv4-only NAT routers they bought themselves for quite a while. With some DNS tricks this might be useful for those users reaching IPv6-only sites, however it would probably be better if they were unable to reach those sites at all to give them an incentive to fix their IPv6. On 7 September 2011 21:37, Leigh Porter leigh.por...@ukbroadband.com wrote: Other simple tricks such as ensuring that your own internal services such as DNS are available without traversing NAT also help. As obvious as this probably is, i'm sure someone will overlook it! Also other services such as providers with CDN nodes in their network may want to talk to the CDN operator about having those connected to directly from the internal addresses to avoid traversing the NAT, and I'm sure there are other services as well. - Mike -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =
Re: IPv6 end user addressing
You are assuming (as many, many people do) that public addresses equal no firewall, and that IPv6 CPEs will have no stateful firewalling. The thing is, just as they have a stateful firewall now for IPv4 they will have one for IPv6 as well. The fact that your addressing is public (or let's say, routeable) does not make a difference. Again, it is not the NAT layer of your IPv4 CPE that protects you, it's the stateful firewall. regards Carlos On Thu, Aug 11, 2011 at 2:52 PM, Greg Ihnen os10ru...@gmail.com wrote: On Aug 11, 2011, at 1:04 PM, Owen DeLong wrote: On Aug 11, 2011, at 5:41 AM, Jamie Bowden wrote: Owen wrote: -Original Message- From: Owen DeLong [mailto:o...@delong.com] Sent: Wednesday, August 10, 2011 9:58 PM To: William Herrin Cc: nanog@nanog.org Subject: Re: IPv6 end user addressing On Aug 10, 2011, at 6:46 PM, William Herrin wrote: On Wed, Aug 10, 2011 at 9:32 PM, Owen DeLong o...@delong.com wrote: Someday, I expect the pantry to have a barcode reader on it connected back a computer setup for the kitchen someday. Most of us already use barcode readers when we shop so its not a big step to home use. Nah... That's short-term thinking. The future holds advanced pantries with RFID sensors that know what is in the pantry and when they were manufactured, what their expiration date is, etc. And since your can of creamed corn is globally addressable, the rest of the world knows what's in your pantry too. ;) This definitely helps explain your misconceptions about NAT as a security tool. Globally addressable != globally reachable. Things can have global addresses without having global reachability. There are these tools called access control lists and routing policies. Perhaps you've heard of them. They can be quite useful. And your average home user, whose WiFi network is an open network named linksys is going to do that how? Because the routers that come on pantries and refrigerators will probably be made by people smarter than the folks at Linksys? Owen I respectfully disagree. If appliance manufacturers jump on the bandwagon to make their device *Internet Ready!* we'll see appliance makers who have way less networking experience than Linksys/Cisco getting into the fray. I highly doubt the pontifications of these Good Morning America technology gurus who predict all these changes are coming to the home. Do we really think appliance manufacturers are going to agree on standards for keeping track of how much milk is in the fridge, especially as not just manufacturing but also engineering is moving to countries like China? How about the predictions that have been around for years about appliances which will alert the manufacturer about impending failure so they can call you and you can schedule the repair before there's a breakdown? Remember that one? We don't even have an appliance about to break, call repairman idiot light on appliances yet. But I predict the coming of IPv6 to the home in a big way will have unintended consequences. I think the big shock for home users regarding IPv6 will be suddenly having their IPv4 NAT firewall being gone and all their devices being exposed naked to everyone on the internet. Suddenly all their security shortcomings (no passwords, password for the password etc) are going to have catastrophic consequences. I foresee an exponential leap in the number of hacks of consumer devices which will have repercussions well beyond their local network. In my opinion that's going to be the biggest problem with IPv6, not all the concerns about the inner workings of the protocols. I'm guessing the manufacturers of consumer grade networkable devices are still thinking about security as it applies to LANs with rfc 1918 address space behind a firewall and haven't rethought security as it applies to IPv6. Greg -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =
Someone from Telefonica Wholesale on the list ?
Specifically someone with admin rights over the router at 2001:1498:1:200::100:5d (got Telefonica from WHOIS as there is no DNS reverse). Can you pls contact me off-list ? Thanks! Carlos -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =
Re: where are all the IPv6 tools?
I'm addicted to sipcalc: http://www.routemeister.net/projects/sipcalc/ It's available on standard repositories for MacPorts, Ubuntu, Debian and Fedora. I guess install is straightforward in other platforms as well. regards Carlos On Wed, May 25, 2011 at 4:29 PM, Kyle Duren pixitha.k...@gmail.com wrote: On Wed, May 25, 2011 at 11:54 AM, Jay Borkenhagen j...@braeburn.org wrote: Hi, I depend on a number of shell tools for manipulating IPv4 addresses, CIDR blocks, etc. like: aggis ipsort.pl grepcidr aggregate I have not yet found much in terms of similar shell utilities for IPv6. I've spoken to authors of some of these tools and they admit they have not yet produced IPv6-capable versions. (Not trying to name and shame: those tools are great, I just want more!) Do folks here know of IPv6 tools that might provide some of the functions the above tools provide for IPv4? Thanks! Jay B. I recommend IPv6gen. http://code.google.com/p/ipv6gen/ Very useful. Granted its not what you were asking for exactly From the site: ipv6gen is tool which generates list of IPv6 prefixes of given length from certain prefix according to RFC 3531. (A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block) -Kyle -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =
Re: HIJACKED: AS18466, courtesy of Global Crossing (AS3549)
Hello Ronald, disclaimerI do work for LACNIC/disclaimer sorryi'm really late in my NANOG followups/sorry P.P.S. Although I have previously bemoaned ARIN's lack of agressivness in reclaiming abandoned ASNs and IP blocks that have been hijacked, I feel compelled to note that at least they (ARIN) do have a proccess in place for doing so, i.e. when and if they are motivated in that direction. I have it on good authority however that LACNIC does not even have an established process for reclaiming abandoned number resources. Given that the problem of hijacked number resources, rather than disappearing, is in fact accelerating, over time, I do believe that it would behove LACNIC and other RiRs to develop processes for reclaiming abandoned resources, in particular when and where it becomes evident that these resources have been hijacked. I would like to get in touch with the good authority you mention as he/she seems to be quite misinformed. LACNIC has, and has applied in the past, policies and procedures for resource recovery due to abandonment and other issues. The original resource recovery policy is LACNIC-2009-06 and the English text can be found here: http://www.lacnic.net/en/politicas/manual7-1.html You can also find the list of recovered prefixes and ASNs here http://www.lacnic.net/en/registro/revocacion.html I am not the expert on how the recovery process actually works but I can get you or the person who mentioned this alleged lack of process to you in touch with the staff who actually do work with resource recovery. regards Carlos -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =
Re: Top webhosters offering v6 too?
BlueHost, which while maybe not a great quality web host, by all measures is a big one, not only does not support IPv6 but they denied my request to create a record pointing to a friend's IPv6 page for a domain I host there. BH, are you listening??? -. Carlos On Sun, Feb 6, 2011 at 7:58 PM, Frank Bulk frnk...@iname.com wrote: Here's one list: http://www.sixxs.net/wiki/IPv6_Enabled_Hosting Frank -Original Message- From: Tim Chown [mailto:t...@ecs.soton.ac.uk] Sent: Sunday, February 06, 2011 8:53 AM To: NANOG list Subject: Top webhosters offering v6 too? Which of the big boys are doing it? Tim -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =
Re: Using IPv6 with prefixes shorter than a /64 on a LAN
Disconnected networks have a bothersome tendency to get connected at some point ( I have been severely bitten by this in the past ), so while I agree that there is no need to coordinate anything globally, then a RFC 1918-like definition would be nice (if we are not going to use ULAs, that is) cheers! Carlos On Tue, Feb 1, 2011 at 11:59 PM, Owen DeLong o...@delong.com wrote: On Feb 1, 2011, at 3:38 PM, Chuck Anderson wrote: On Tue, Feb 01, 2011 at 03:14:57PM -0800, Owen DeLong wrote: On Feb 1, 2011, at 2:58 PM, Jack Bates wrote: There are many cases where ULA is a perfect fit, and to work around it seems silly and reduces the full capabilities of IPv6. I fully expect to see protocols and networks within homes which will take full advantage of ULA. I also expect to see hosts which don't talk to the public internet directly and never need a GUA. I guess we can agree to disagree about this. I haven't seen one yet. What would your recommended solution be then for disconnected networks? Every home user and enterprise user requests GUA directly from their RIR/NIR/LIR at a cost of hunderds of dollars per year or more? For a completely disconnected network, I don't care what you do, use whatever number you want. There's no need to coordinate that with the internet in any way. For a network connected to a connected network, either get GUA from an RIR or get GUA from the network you are connected to or get GUA from some other ISP/LIR. There are lots of options. I'd like to see RIR issued GUA get a lot cheaper. I'd much rather see cheap easy to get RIR issued GUA than see ULA get widespread use. Owen -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =
Re: quietly....
That was it :-) so long IPv4! It's been a great ride! As good old Frank said, And now, the end is near, we face the final curtain... cheers! Carlos On Mon, Jan 31, 2011 at 9:28 PM, Randy Bush ra...@psg.com wrote: 039/8 APNIC 2011-01 whois.apnic.net ALLOCATED 106/8 APNIC 2011-01 whois.apnic.net ALLOCATED it's been on most of the lists. sunny will probably post to nanog shortly. the announcement is really well phrased, but i will not steal sunny's thunder. randy -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =
Re: [arin-announce] ARIN Resource Certification Update
What I just don´t get if, we as a society, have created institutions we trust with our *money* (AKA banks), why there can´t be institutions we trust with our crypto keys. I know that banks sometimes fail, and yes, probably crypto banks will sometimes fail as well, but on the whole, the failure rate of trusted institutions can be quite low, acceptably low. IMO the whole thing seems to boil down to the complex interaction of psychological, emotional and other aspects of how we perceive a certain situation. And it clearly depends on the region, just look at RIPE´s column and how it grows relentlessly (i included only a few lines, full stats can be found in the URL posted by Arturo in an earlier post) R2a. IPv4 Space Covered by ROAs (in units of /24s) date |lacnic| apnic| afrinic| arin| ripe| 2011-01-11 |17| 189| 1| 0| 28902| 2011-01-12 |17| 189| 1| 1867.03| 32439| 2011-01-13 |17| None| 1| 1867.03| 32810| 2011-01-14 |17| 181| 1| 1867.03| 32819| 2011-01-15 |17| 181| 1| 1867.03| 32875| 2011-01-16 |17| 181| 1| 1867.03| 32875| 2011-01-17 |17| 181| 1|20| 32903| 2011-01-18 |17| 181| 2| None| 33783| 2011-01-19 |17| 177| 2| None| 35271| Hats off to RIPE People! cheers, Carlos On Sun, Jan 30, 2011 at 8:39 AM, Alex Band al...@ripe.net wrote: Paul, I think my question is very pertinent. Of course the number of signed prefixes directly influences the number of validators. Do you think the RIPE NCC Validator tool would have been downloaded over 100 times in the last month if there were only 5 certified prefixes? In my opinion, the widespread availability of signed prefixes and mature validation methods is key to the global success of resource certification. I agree that small differences in the size of the set of signed routes don't matter on a (relatively) short term, but the reality is that the difference would be *enormous* if we wouldn't offer a hosted solution. Practically, in the real world, why would anyone invest time and effort in altering their current BGP decision making process to accommodate for resource certification if the technology is on nobody's radar, it's hard to get your feet wet and there are just a handful of certified prefixes out there. Wouldn't it be good if network operators think: Because it helps increase global routing security, it's easy to get started and lots of people are already involved, perhaps I should have a look at (both sides of) resource certification too. This is why I believe – and our adoption numbers prove – that the entry barrier to the system should be as low as possible, both on the signing side and the validation side. Once some of the people that are using the hosted platform now decide they would rather run their own non-hosted solution at a later stage, that would be even better. That immediately solves the private key situation. But there will always be a group happy to rely on the hosted model, and we cater to that. Because of the path we chose there is already a lot of operational experience being gained, resulting in a large amount of feedback from a wide range of users. This helps us shape the certification system and the validator tool, which aids quality and usability. To me, that makes a lot of business sense. This is why I think there should be as much certified address space available as possible. Otherwise this will stay a niche technology until perhaps a major event causes people to wake up (and hopefully take action). If certification has reached the necessary level of maturity at that point remains to be seen. Furthermore, preventing (future) malicious hijacking is not the *only* reason the Internet community needs better routing security, the accidental route leaking that happens every day is reason enough. -Alex On 29 Jan 2011, at 23:00, Paul Vixie wrote: From: Alex Band al...@ripe.net Date: Sat, 29 Jan 2011 16:26:55 +0100 ... So the question is, if the RIPE NCC would have required everyone to run their own certification setup using the open source tool-sets Randy mentions, would there be this much certified address space now? i don't agree that that question is pertinent. in deployment scenario planning i've come up with three alternatives and this question is not relevant to any of them. perhaps you know a fourth alternative. here are mine. 1. people who receive routes will prefer signed vs. unsigned, and other people who can sign routes will sign them if it's easy (for example, hosted) but not if it's too hard (for example, up/down). 2. same as #1 except people who really care about their routes (like banks or asp's) will sign them even if it is hard (for
Re: [arin-announce] ARIN Resource Certification Update
Do you really think that a set of keys stored in a random PC in a random office is safer than on a periodically backed-up, encrypted database? In this future I only see lost keys, keys appearing listed in something.ru domains, tons of support calls to hostmasters, and ROAs repeatedly becoming invalid, all things that will seriously harm RPKI adoption. In the end, I see two things: - Hosted solutions aren´t supposed to fit everyone, that´s why top-down is being developed. This is not news. - Hosted solutions offer a low barrier entry to smaller organizations who simply cannot develop their own PKI infrastructure. This is the case where they also lack the organizational skills to properly manage the keys themselves, so, in most cases at least, they are *better off* with a hosted solution For RPKI to succeed we have to succeed not only on the technical side but on the *human* side of things. Adoption of RPKI will only move forward if network admins have *confidence* in the stability, dependability and overall quality of the whole system. ROAs repeatedly becoming invalid for the wrong reasons will represent a death blow to RPKI adoption. For RIPE, their hosted solution is clearly meeting expectations within their region. Other region´s mileage may vary. I hope we (LACNIC) can do just as well. Have a great day! Carlos On Sat, Jan 29, 2011 at 11:52 PM, Owen DeLong o...@delong.com wrote: I don't understand why you can't have a hosted solution where the private keys are not held by the host. Seems to me you should be able to use a Java Applet to do the private key generation and store the private key on the end-user's machine, passing objects that need to be signed by the end user down to the applet for signing. This could be just as low-entry for the user, but, without the host holding the private keys. What am I missing? Owen On Jan 29, 2011, at 1:06 PM, Arturo Servin wrote: I agree with Alex that without a hosted solution RIPE NCC wouldn't have so many ROAs today, for us, even with it, it has been more difficult to roll out RPKI among our ISPs. As many, I do not think that a hosted suits to everybody and it has some disadvantages but at leas it could help to lower the entry barrier for some. Speaking about RPKI stats, here some ROA evolution in various TAs (the data from ARIN is from their beta test, the rest are production systems): http://www.labs.lacnic.net/~rpki/rpki-evolution-report_EN.txt And visually: http://www.labs.lacnic.net/~rpki/rpki-heatmaps/latest/global-roa-heatmap.png and http://www.labs.lacnic.net/~rpki/rpki-heatmaps/latest/ To see each region. http://www.labs.lacnic.net/~rpki/rpki-heatmaps Also, bgpmon has a nice whois interface for humans to see ROAs (not sure if this link was share here or in twitter, sorry if I am duplicating): http://bgpmon.net/blog/?p=414 Best regards, -as On 29 Jan 2011, at 13:26, Alex Band wrote: John, Thanks for the update. With regards to offering a hosted solution, as you know that is the only thing the RIPE NCC currently offers. We're developing support for the up/down protocol as I write this. To give you some perspective, one month after launching the hosted RIPE NCC Resource Certification service, 216 LIRs are using it in the RIPE Region and created 169 ROAs covering 467 prefixes. This means 40151 /24 IPv4 prefixes and 7274499 /48 IPv6 prefixes now have a valid ROA associated with them. I realize a hosted solution is not ideal, we're very open about that. But at least in our region, it seems there are quite a number of organizations who understand and accept the security trade-off of not being the owner of the private key for their resource certificate and trust their RIR to run a properly secured and audited service. So the question is, if the RIPE NCC would have required everyone to run their own certification setup using the open source tool-sets Randy mentions, would there be this much certified address space now? Looking at the depletion of IPv4 address space, it's going to be crucially important to have validatable proof who is the legitimate holder of Internet resources. I fear that by not offering a hosted certification solution, real world adoption rates will rival those of IPv6 and DNSSEC. Can the Internet community afford that? Alex Band Product Manager, RIPE NCC P.S. For those interested in which prefixes and ASs are in the RIPE NCC ROA Repository, here is the latest output in CSV format: http://lunimon.com/valid-roas-20110129.csv On 24 Jan 2011, at 21:33, John Curran wrote: Copy to NANOG for those who aren't on ARIN lists but may be interested in this info. FYI. /John Begin forwarded message: From: John Curran jcur...@arin.netmailto:jcur...@arin.net Date: January 24, 2011 2:58:52 PM EST To: arin-annou...@arin.netmailto:arin-annou...@arin.net
Re: [arin-announce] ARIN Resource Certification Update
There's a big difference. If a bank screws up and loses $5,000 of my money, I can (at least potentially) sue them and recover $5,000 which is pretty much identical to the $5,000 I lost. If a key escrow company loses my private key, getting back an identical private key is exactly the *wrong* solution. Crypto keys are not interchangable like dollar bills. I never suggested that they were. I tried to point out a set of institutions on which we place similar, if not higher, levels of trust to those required to store a crypto key. If your crypto bank loses your key, you can always revoke and resign. And you'll be back on the air much faster than you can recover $5k from a failed bank. And please do not get me out of context, I never said the hosted solution was perfect, nor that the analogy applicable to every aspect. And I am not trying to extend the success of RIPE's hosted solution to everybody's digital identity. It is a vertical solution that is doing well (and will hopefully continue to do so) on a vertical application. For sure, it is probably not an example you can extend to other applications. Going back to money, I would *never* trust a hosted solution to hold a key I use to access my online banking. This would clearly be a case where a hosted solution is not applicable. regards Carlos -- Carlos M. Martinez LACNIC I+D PGP KeyID 0xD51507A2 Phone: +598-2604- ext. 4419 Carlos Martinez Cagnazzo car...@lacnic.net
Re: [arin-announce] ARIN Resource Certification Update
I see also that many concerns expressed here are extensions of the perceived failures of the whole CA business. I agree that the whole model of CAs has largely failed. Not only there are too many of them, but the fact that they try to operate as for-profits makes them vulnerable to all the pressures that come with the need to sell and generate revenue. The spectacular failures they have suffered in the past (certificates with Microsoft's name on them, I guess everyone remembers) have certainly not helped. Basically the only thing you now get from using SSL certs is end-to-end encryption, and for that, a self-signed certificate does just as well as a thousand dollar one from your preferred friendly CA. However, as I said on an earlier post, I still believe that the hosted solution for RPKI is a good one at this point in time for a certain group of users of a certain application. It is *very* vertical, or niche if you want. We should not try to extend it to other applications or other groups of users. Randy sums up my whole feelings on the issue. I also think we need top-down soon, and I wouldn't mind in the future seeing a nice Paretto distribution where 80% of members use the hosted solution, but account for 20% of routed space, where 20% customers use top-down accounting for 80% of routed space. Perfection is the enemy of good. Before hosted RPKI the only way of checking origin-as information was to use one of the public routing registries. A routing registry which is fed from RPKI data is a lot more trustworthy than plain email auth IRRs are. Is it pefect? Of course not. Can it be improved? Of course it can. cheers! Carlos
Re: Level 3's IRR Database
The solution to this problem (theoretical at least) already exist in the form of RPKI. On Sun, Jan 30, 2011 at 6:23 AM, Andrew Alston a...@tenet.ac.za wrote: Hi All, I've just noticed that Level 3 is allowing people to register space in its IRR database that A.) is not assigned to the people registering it and B.) is not assigned via/to Level 3. So, I have two queries A.) Are only customers of Level 3 allowed to use this database B.) Can someone from Level 3 please clarify if there are any plans to lock this down slightly At this point, it would seem that if you are a customer of level 3's, you can register any space you feel like in there, and announce anything you feel like once the filters propagate, which in my opinion completely nullifies the point of IRR in the first place. Though I think this also raises the question about IRR databases in general. Would it not be far more sane to have each RIR run a single instance each which talk to each other, which can be verified against IP address assignments, and scrap the distributed IRR systems that allow for issues like this to occur? (In the mean time I've emailed the relevant people to try and get the entries falsely registered in that database removed, and will wait and see if I get a response). Andrew Alston TENET - Chief Technology Officer Phone: +27 21 763 7181 -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =
Re: Level 3's IRR Database
Hi, this is the second mention I see of RPKI and Egypt in the same context. I sincerely fail to see the connection between both situations. Egypt cut their links the old fashioned way: they pulled the plug. I fail to see how such a situation could be made worse by RPKI. It simply has nothing to do. Not deploying RPKI won't prevent your local friendly autocrat from ordering cut all wires or something like that. regards Carlos On Sun, Jan 30, 2011 at 7:53 PM, Brandon Butterworth bran...@rd.bbc.co.uk wrote: I think it is too early in the deployment process to start dropping routes based on RPKI alone. We'll get there at some point, I guess. Do we really *want* to get to that point? I thought that was the point and the goal of securing the routing infrastructure is laudable. But the voices in my head say don't trust them with control of your routes, see what happened in Egypt. brandon -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =
Re: What's the current state of major access networks in North America ipv6 delivery status?
Reading this thread, and building on many comments to a previous one, I definitely see the need for subnetting a /64 arising sooner than later. It might not be perfect, It might be ugly, but it will happen. And, if you ask me, I would rather subnet a /64 than end up with a ipv6 version of NAT, a much worse alternative. cheers, Carlos On Thu, Jan 27, 2011 at 9:57 AM, Brzozowski, John john_brzozow...@cable.comcast.com wrote: In order to deploy /56 to end users would require an IPv6 /24 be dedicated to 6rd, /48s would require a dedicated IPv6 /16. This assumes an operator wants/needs to provide IPv6 via 6rd to end users where their IPv4 address is fully unique. There is quite a bit of IPv6 address space that does not gets utilized in this model. The routers we are using as part of the trials only support /64 as such we are using an IPv6 /32. It is also important that operators plan for the ability to delegate prefixes that are shorter than a /64. There are several cases that we have seen where the router can only make use of a /64. This is better than nothing when referring to legacy devices that have been able to introduce some support for IPv6 and would have otherwise been IPv4 only devices. John = John Jason Brzozowski Comcast Cable e) mailto:john_brzozow...@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net = On 1/26/11 5:02 PM, Owen DeLong o...@delong.com wrote: On Jan 26, 2011, at 1:52 PM, Charles N Wyble wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Is anyone tracking the major consumer/business class access networks delivery of ipv6 in North America? I'm on ATT DSL. It looks like they want to use 6rd? I've only briefly looked into 6rd. Is this a dead end path/giant hack? https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Googl econf-BroadbandtransitiontoIPv6using6rd.pdf?attredirects=0 It's a fairly ugly way to deliver IPv6, but, as transition technologies go, it's the least dead-end of the options. It at least provides essentially native dual stack environment. The only difference is that your IPv6 access is via a tunnel. You'll probably be limited to a /56 or less over 6rd, unfortunately, but, because of the awful way 6rd consumes addresses, handing out /48s would be utterly impractical. Free.fr stuck their customers with /60s, which is hopefully a very temporary situation. I spoke with impulse.net last year, which appears to serve large portions of the ATT cable plant in Southern California. They were willing to offer native ipv6. Not sure how (one /64, a /48) etc. You should definitely push your providers to give you a /48 if possible. If /56 or worse /60 or worst of all, /64 become widespread trends, it may significantly impact, delay, or even prevent innovations in the end-user networking/consumer electronics markets. Owen -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =
Re: What's the current state of major access networks in North America ipv6 delivery status?
I guess I won't need to add routes to my gateway, only subnetting on the inside will probably do for the time being (a hub/spoke topology, routing only between directly-connected subnets). And many ISPs allow you to buy your own CPE. Using an AirPort Extreme (or other home router with similar features) in bridged mode would do the trick, i guess. :-) cheers, Carlos On Thu, Jan 27, 2011 at 11:11 AM, Antonio Querubin t...@lava.net wrote: On Thu, 27 Jan 2011, Carlos Martinez-Cagnazzo wrote: Reading this thread, and building on many comments to a previous one, I definitely see the need for subnetting a /64 arising sooner than later. It might not be perfect, It might be ugly, but it will happen. And, if you ask me, I would rather subnet a /64 than end up with a ipv6 version of NAT, a much worse alternative. Maybe not NAT but some kind of proxy ND and/or a migration from routing firewalls to bridging firewalls. If the broadband provider is only providing a single /64, it's not likely they're gonna be willing to add routes to your gateway. Antonio Querubin e-mail/xmpp: t...@lava.net
Re: What's the current state of major access networks in North America ipv6 delivery status?
I agree with you, but, will it happen? The same fixed boundary behaviour that makes the /64 so convenient for LAN addressing ends up making the same /64 very convenient for ISPs as well. They associate the /64 with the single public IP they issue to customers nowadays. Again, I would *love* to be wrong on this one. Seriously. This is an argument I sincerely hope to lose, but after being in the ISP business for more than 10 years, I wouldn't expect my local ISPs at least to issue anything shorter than a /64 to customers. And... the argument for this will have a commercial background as well. They will perceive customers who want multiple subnets as customers who can pay more. They will make customers who want multiple subnets go through hops to get a shorter prefix. Justifications and such. Very few people will do it. warm regards Carlos On Thu, Jan 27, 2011 at 11:58 AM, Brzozowski, John john_brzozow...@cable.comcast.com wrote: I am definitely *NOT* an advocate of NAT66 nor am I an advocate of further subneting a /64 into longer prefixes. Where additional IPv6 prefixes are required a prefix shorter than a /64 should be delegated. John = John Jason Brzozowski Comcast Cable e) mailto:john_brzozow...@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net = On 1/27/11 7:56 AM, Carlos Martinez-Cagnazzo carlosm3...@gmail.com wrote: Reading this thread, and building on many comments to a previous one, I definitely see the need for subnetting a /64 arising sooner than later. It might not be perfect, It might be ugly, but it will happen. And, if you ask me, I would rather subnet a /64 than end up with a ipv6 version of NAT, a much worse alternative. cheers, Carlos On Thu, Jan 27, 2011 at 9:57 AM, Brzozowski, John john_brzozow...@cable.comcast.com wrote: In order to deploy /56 to end users would require an IPv6 /24 be dedicated to 6rd, /48s would require a dedicated IPv6 /16. This assumes an operator wants/needs to provide IPv6 via 6rd to end users where their IPv4 address is fully unique. There is quite a bit of IPv6 address space that does not gets utilized in this model. The routers we are using as part of the trials only support /64 as such we are using an IPv6 /32. It is also important that operators plan for the ability to delegate prefixes that are shorter than a /64. There are several cases that we have seen where the router can only make use of a /64. This is better than nothing when referring to legacy devices that have been able to introduce some support for IPv6 and would have otherwise been IPv4 only devices. John = John Jason Brzozowski Comcast Cable e) mailto:john_brzozow...@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net = On 1/26/11 5:02 PM, Owen DeLong o...@delong.com wrote: On Jan 26, 2011, at 1:52 PM, Charles N Wyble wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Is anyone tracking the major consumer/business class access networks delivery of ipv6 in North America? I'm on ATT DSL. It looks like they want to use 6rd? I've only briefly looked into 6rd. Is this a dead end path/giant hack? https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Goo gl econf-BroadbandtransitiontoIPv6using6rd.pdf?attredirects=0 It's a fairly ugly way to deliver IPv6, but, as transition technologies go, it's the least dead-end of the options. It at least provides essentially native dual stack environment. The only difference is that your IPv6 access is via a tunnel. You'll probably be limited to a /56 or less over 6rd, unfortunately, but, because of the awful way 6rd consumes addresses, handing out /48s would be utterly impractical. Free.fr stuck their customers with /60s, which is hopefully a very temporary situation. I spoke with impulse.net last year, which appears to serve large portions of the ATT cable plant in Southern California. They were willing to offer native ipv6. Not sure how (one /64, a /48) etc. You should definitely push your providers to give you a /48 if possible. If /56 or worse /60 or worst of all, /64 become widespread trends, it may significantly impact, delay, or even prevent innovations in the end-user networking/consumer electronics markets. Owen -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net = -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =
Using IPv6 with prefixes shorter than a /64 on a LAN
The subject says it all... anyone with experience with a setup like this ? I am particularly wondering about possible NDP breakage. cheers! Carlos -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =
Re: Using IPv6 with prefixes shorter than a /64 on a LAN
Doing a little introspection, I found myself realizing that one of the most bothersome aspects of the /64 boundary (for me, just speaking for myself here) is exactly that, the tendency to the hardcoding of boundaries. C. On Mon, Jan 24, 2011 at 12:26 PM, Phil Regnauld regna...@nsrc.org wrote: bmann...@vacation.karoshi.com (bmanning) writes: as a test case, i built a small home network out of /120. works just fine. my home network has been native IPv6 for about 5 years now, using a /96 and IVI. some thoughts. disable RD/RA/ND. none of the DHCPv6 code works like DHCP, so I re-wrote client and server code so that it does. static address assignment is a good thing for services like DNS/HTTP secure dynmaic update is your friend summary - its not easy, vendors don't want to help. but it can be done. Right - /64 is an assumption that's hardcoded many places. But it does work.
Re: Network Simulators
Anything for Junipers ? On Wed, Jan 19, 2011 at 11:52 AM, Gary Gladney glad...@stsci.edu wrote: If you looking for network simulator for Cisco equipment it's been my experience that Boson (www.boson.com) has best network simulator for Cisco equipment. It behaves and process information the way real Cisco equipment does. I've tried GS3, it great for routing situations but lacks in simulating switches. Gary -Original Message- From: Ryan Shea [mailto:ryans...@google.com] Sent: Wednesday, January 19, 2011 8:37 AM To: Brandon Kim Cc: nanog group Subject: Re: Network Simulators You can do some switching by stuffing a virtual NM-16ESW into your faketastic 3660 in Dynamips. Then there are the built-in frame-relay and ethernet switches you could dump into the mix as well. -Ryan On Mon, Jan 17, 2011 at 10:23 AM, Brandon Kim brandon@brandontek.comwrote: James: I've been resisting GNS3 for the longest time, because I like real equipment and to get my hands a little dirty. But for the purpose of simulation, GNS3 helped me identify a BGP issue last week. If it weren't for GNS3, I would not have been able to figure it out. I will be using GNS3 in the future now for as much I can. Remember it is more router oriented than switch. So you can't do any fancy L3 switching.. Date: Mon, 17 Jan 2011 10:05:21 -0500 From: ja...@freedomnet.co.nz To: nanog@nanog.org Subject: Re: Network Simulators So far GNS3 has won out so far. It seems to work on my Mac fairly well. trying it out now. On 17/01/11 9:37 AM, Carlos Martinez-Cagnazzo wrote: I am currently researching virtual simulation environments for the Networking courses that I teach. I am now interested in user-mode linux emulators as they provide more real environments. The one that I am liking the most right now is this one: http://wiki.netkit.org/index.php/Main_Page regards Carlos On Mon, Jan 17, 2011 at 12:20 PM, Arturo Servin arturo.ser...@gmail.com wrote: GNS3 http://www.gns3.net/ This is another network simulator, mainly for academic research. NS-2 http://www.isi.edu/nsnam/ns/ And you can always setup some virtual machines with DNSs, hosts and routers with open-source software. regards, -as On 17 Jan 2011, at 11:58, James Jones wrote: Are there any good Network Simulators/Trainers out there that support IPv6? I want play around with some IPv6 setup. -- James Jones +1-413-667-9199 tel:+14136679199 ja...@freedomnet.co.nz -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =
Re: Network Simulators
I am currently researching virtual simulation environments for the Networking courses that I teach. I am now interested in user-mode linux emulators as they provide more real environments. The one that I am liking the most right now is this one: http://wiki.netkit.org/index.php/Main_Page regards Carlos On Mon, Jan 17, 2011 at 12:20 PM, Arturo Servin arturo.ser...@gmail.com wrote: GNS3 http://www.gns3.net/ This is another network simulator, mainly for academic research. NS-2 http://www.isi.edu/nsnam/ns/ And you can always setup some virtual machines with DNSs, hosts and routers with open-source software. regards, -as On 17 Jan 2011, at 11:58, James Jones wrote: Are there any good Network Simulators/Trainers out there that support IPv6? I want play around with some IPv6 setup. -- James Jones +1-413-667-9199 ja...@freedomnet.co.nz -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =
Re: Software For Telcos
What I've seen in my experience is mostly custom-developed software, sometimes developed in-house, sometimes outsourced and sometimes both. I don't know of many off-the-shelf packages out there. There are of course many vertical off-the-shelf apps. For example: billing systems, network management/monitoring systems, payroll systems, CRMs, etc. Many times there is a lot of work to be done in the area of system integration as there is a significant effort involved in getting these vertical systems talking to each other. cheers, Carlos On Tue, Jan 4, 2011 at 5:04 AM, jacob miller mmzi...@yahoo.com wrote: Hi, I have been wondering what type of Software do top telcos use. The tracking of Customer circuits to ensure that from marketing,sales,accounts and technical department everything to do with the circuits has to be tracked. Anyone with any help in regards to top software that can be used to run such a telco to ensure that world class service is obtained will be crucial. Regards, Jacob -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =
Re: Alacarte Cable and Geeks
I have been trying to get NASA TV in Uruguay for a long time, obviously to no avail. Even though it's probably free / very cheap. I do believe that video over the Internet is about to change the cable business in a very deep and possibly traumatic way. Even I only have 4 megs DSL at home and have almost 250 msec delay to get to Terremark in Miami, my Apple TV plays YouTube reasonably well and I am probably near to the point where I would probably pay for premium content from YouTube or other providers to get over my crappy cable service. Cheers, Carlos On Fri, Dec 17, 2010 at 5:58 AM, Jeff Wheeler j...@inconcepts.biz wrote: On Fri, Dec 17, 2010 at 12:26 AM, Jay Ashworth j...@baylink.com wrote: the 80s when that practice got started -- having to account for each individual subscriber pushed the complexity up, in much the same way that flat rate telecom services are popular equally because customers prefer them, and because the *cost of keeping track* becomes delta. Having personally and solely designed and written a toll billing system from scratch that directly exchanged billing and settlement data (and end-user data) with hundreds of ILECs, I can tell you a number of things I learned: 1) billing is only as hard as you (or your vendor) make it 2) if your company can't figure out how to bill for a new product or service, blame the billing people, not the product 3) keeping up with taxes and fees consume a lot more resources than calculating the net bills themselves; so adding products is really trivial compared to dealing with every pissant local government that decides to apply a different taxing method to your HBO (or your telephone calls) This is not to say the folks that handle billing at cable companies are equally capable, but if they had legitimate competitors, they would figure out how to run many parts of their businesses more efficiently. Imagine if Wal-Mart was the only game in town that had bar code readers at the cash registers, and every other grocery chain had to look up every item and punch in the price to check you out. Other stores would quickly improve their technology or find themselves out of business. 2) New networks prefer it, and the fact that it happens makes the creation of new cable networks practical -- you don't have to go around and sell your idea to people retail; you sell it to CATV systems (well, My understanding is that networks/media giants like it because they can force cable companies to carry 11 irrelevant channels to get the Disney Channel that your kids want. Would enough people really ask for G4TV to make producing and syndicating shows for that channel cost-effective? I don't know the answer, but my suspicion is that people who really just want CSN, E!, or the Golf Channel are subsidizing G4 viewers. I wanted BBCA a few years ago, but my cable provider required that I buy 30 other channels I did not want or had never even heard of to get BBCA, so I didn't subscribe to it. I do not know if a la carte channel selection would be good for me, as a consumer, or not. I do think the reasons the industry does not want to offer that to end-users are disingenuous. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =
Fwd: Your email message was blocked
I just contributed to the thread called Cable and Geeks, and (I now realize) included the word crappy. Then, just like that, my Friday Moment of Fun just happened, like a brilliant ball of light in the sky. I received a bounce from something called r...@bellaliant.ca who rejected my email due to mild profanity (sorry, i didn't know people could be so sensitive). Man, i had not had an on-the-job-laugh-out-loud in a long time. I am very tempted of probing the system. Many a question comes to mind, like for example: Does it only worry about profanity in English? I have a dictionary of bad words in Spanish, i am resisting the urge to craft a python script and send it word by word to r...@bellaliant.ca. Also mesmerizing is the fact that they will keep my mildly profane email in some storage for five days. Why? If its blocked, so be it, why keep it? Ahhh don't worry, I won't do it anyways. Notwithstanding the laugh and the fun, these are the times when I lose a bit of faith in mankind. Why there are always people out there pretending to know what it's best for you ? Well, I am clicking send, I will probably receive another mild profanity warning. There it comes... cheers Carlos -- Forwarded message -- From: r...@bellaliant.ca Date: Fri, Dec 17, 2010 at 10:55 AM Subject: Your email message was blocked To: carlosm3...@gmail.com The following email message was blocked by Bell Aliant Content Filtering Device: From: carlosm3...@gmail.com To:jeff.gallag...@bellaliant.ca Subject: Re: Alacarte Cable and Geeks Message: B4d0b5da70002.0001.0003.mml Because it may contain unacceptable language, or inappropriate material. Please remove any unacceptable or inappropriate language and resend the message. The blocked email will be automatically deleted after 5 days. Content Rule: Policy Management (Inbound) : Block Common Mild Profanity r...@bellaliant.ca 6728 08:55:04.138 17 Dec 2010 - B4d0b5da70002.0001.0003.mml 6728 08:55:04.138 Message From carlosm3...@gmail.com, Return-path nanog-bounces+jeff.gallagher=bellaliant...@nanog.org, Recipients (1) - jeff.gallag...@bellaliant.ca 6728 08:55:04.138 Thread 2 Starting to unpack B4d0b5da70002.0001.0003.mml 6728 08:55:04.138 MimeTags::Process tag Content-Type = text/plain; charset=ISO-8859-1 6728 08:55:04.138 MimeTags::Process tag Content-Transfer-Encoding = quoted-printable 6728 08:55:04.138 Encoding quoted-printable 6728 08:55:04.138 Quoted-Printable encoded section consumed 3674 bytes - file D:\MailMarshal\Unpacking\T2\U2\Quoted-Printable.txt 6728 08:55:04.138 Type=MAIL, size=6512, Name=B4d0b5da70002.0001.0003.mml 6728 08:55:04.138 Type=MHDR, size=2836, Name=MsgHeader.txt 6728 08:55:04.138 Type=MBODY, size=3556, Name=Quoted-Printable.txt 6728 08:55:04.138 1 user(s) match ruleset - Connection Policies 6728 08:55:04.138 0 user(s) match rule - NSP-SEC Email Rule - BA 6728 08:55:04.138 0 user(s) match rule - Delete Postmaster messages - BA 6728 08:55:04.138 1 user(s) match ruleset - Virus Threats (Inbound) 6728 08:55:04.138 1 user(s) match rule - Block Virus 6728 08:55:04.138 virus scanner OK Sophos Anti-Virus file B4d0b5da70002.0001.0003.mml after 0 millisecs 6728 08:55:04.138 virus scanner OK Sophos Anti-Virus file MsgHeader.txt after 0 millisecs 6728 08:55:04.138 virus scanner OK Sophos Anti-Virus file Quoted-Printable.txt after 0 millisecs 6728 08:55:04.138 Name=U1\B4d0b5da70002.0001.0003.mml (MAIL,6512) False 6728 08:55:04.138 Name=U2\MsgHeader.txt (MHDR,2836) False 6728 08:55:04.138 Name=U2\Quoted-Printable.txt (MBODY,3556) False 6728 08:55:04.138 1 user(s) match rule - Block Known Threats 6728 08:55:04.138 Name=U1\B4d0b5da70002.0001.0003.mml (MAIL,6512) False 6728 08:55:04.138 1 user(s) match rule - Block Known Virus Attachments 6728 08:55:04.138 Name=U1\B4d0b5da70002.0001.0003.mml (MAIL,6512) False 6728 08:55:04.138 Name=U2\MsgHeader.txt (MHDR,2836) False 6728 08:55:04.138 Name=U2\Quoted-Printable.txt (MBODY,3556) False 6728 08:55:04.138 1 user(s) match rule - Block Virus - Zero Day Protection Framework 6728 08:55:04.138 Name=U1\B4d0b5da70002.0001.0003.mml (MAIL,6512) False 6728 08:55:04.138 1 user(s) match rule - Block Virus Hoaxes - BA 6728 08:55:04.138 Name=U1\B4d0b5da70002.0001.0003.mml (MAIL,6512) False 6728 08:55:04.138 Name=U2\MsgHeader.txt (MHDR,2836) False 6728 08:55:04.138 Name=U2\Quoted-Printable.txt (MBODY,3556) False 6728 08:55:04.138 0 user(s) match rule - Tony Power Rule #1 - BA 6728 08:55:04.138 1 user(s) match rule - BlockChain Letteres - BA 6728 08:55:04.154 Name=U1\B4d0b5da70002.0001.0003.mml (MAIL,6512) False 6728 08:55:04.154 Name=U2\MsgHeader.txt (MHDR,2836) False 6728 08:55:04.154 Name=U2\Quoted-Printable.txt (MBODY,3556) False 6728 08:55:04.154 0 user(s) match ruleset - Virus Threats
Re: Cacti Bandwidth Monitoring
You need to use 64 bit counters. Here you can find more info: http://www.cisco.com/en/US/tech/tk648/tk362/technologies_q_and_a_item09186a00800b69ac.shtml The problem is that at 150 mbps 32 bit counters roll-over at least twice in the 5 min interval. Warm regards Carlos Martinez LACNIC Uruguay On Mon, Nov 29, 2010 at 12:24 PM, Peter Rudasingwa peter.rudasin...@altechstream.rw wrote: Hi, I have a cacti server running and it has been working fine so far except for one interface which has an average of 150Mbps going through it now. Before when I had less than 120Mbps I got proper graphs but of late it gives me graphs of 20Mbps when it should be giving me the correct reading (150Mbps). Is there a maximum bandwidth it graphs or can this be edited so that I get proper graphs? -- Best Regards, Peter Rudasingwa *ALTECH STREAM RWANDA Ltd* ICT Park Boulevard de L'Umuganda P.O.Box 6098 Kigali, Rwanda Telephone: (+250) 580532/5 Mobile: (+250) 0788406685 *Affordable Broadband Solutions* -- -- = Carlos M. Martinez-Cagnazzo http://cagnazzo.name =
Re: Token ring? topic hijack: was Re: Mystery open source switching
What can I say... awesome... :-) You should definitely send some pictures, if you can upload them via thicknet :-) On Wed, Nov 3, 2010 at 3:54 PM, Lamar Owen lo...@pari.edu wrote: On Tuesday, November 02, 2010 04:55:02 pm Michael Sokolov wrote: Carlos Martinez-Cagnazzo carlosm3...@gmail.com wrote: Not only token ring. I know of some coaxial ethernets that were running as late as 2007. The network I am using to compose and post this message right now is a coaxial Ethernet. Oh man I still have some 10Base-5 segments in production. At least I'm using a 7507 with an AUI Ethernet interface processor to drive them, now, instead of the three Proteon P4200's (software to P5600, with IP, EGP, RIP, OSPF, XNS, DNA, X.25, etc) that were used prior. The three P4200's hooked up to each other with ProNET-80 over fiber (using the P3280 counterrotating ring unit). Kindof cool to have floppies with the JNC copyright on themsoftware release R8.1, 02/06/91. Last time I checked, two of the P4200's still booted up. 2MB of RAM with a 68020 at 16MHz. Sounds like a Cisco AGS. The fiber portion is now 1000Base-SX and LX, but rather than rewire some areas, we just pop some older switches with AUI 'uplinks' and use the thicknet, which still runs well (as well as thicknet can) after all these years. Some of the areas the thicknet traverses would be a difficult rewire, thanks to 'right-sized' conduit and vampire taps. And if it ain't broke. ProNet-80.TokenRing on steroids. Worked better than the IBM 8220 TR-Fiber boxes, even using the old mini-BNC connectors. -- -- = Carlos M. Martinez-Cagnazzo http://cagnazzo.name =
Re: Token ring? topic hijack: was Re: Mystery open source switching
Not only token ring. I know of some coaxial ethernets that were running as late as 2007. Some ATM machines still use X.25. And I know of at least one operational CNLP network (not a commercial one though) cheers! Carlos On Mon, Nov 1, 2010 at 11:21 AM, Greg Whynott greg.whyn...@oicr.on.cawrote: off topic… you recently converted from token ring to ethernet? i had no idea there was still token ring networks out there, or am i living in a bubble? -g On Oct 31, 2010, at 9:07 PM, Paul WALL wrote: I don't know what the big deal is. I've rolled at least 20 of these switches into my network, and not only are they more stable than the Centillion switches that they replaced, they only cost half as much. Most of the money I dropped was on converting my stations from token ring to ethernet. On Sun, Oct 31, 2010 at 6:59 PM, bas kilo...@gmail.com wrote: Hi, On Sat, Oct 30, 2010 at 11:26 PM, Kevin Oberman ober...@es.net wrote: I might also mention that I received private SPAM from a name we all know and loath. (Hint: He's been banned from NANOG for VERY good reason and his name is of French derivation.) I just added a filter to block any mail mentioning pica8 and will see no more of this thread or their spam. Same here. He harvests email addresses from peeringdb. (I have slight typo's in my peeringdb record to recognize harvested spams.) Bas -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. -- -- = Carlos M. Martinez-Cagnazzo http://cagnazzo.name =
Re: Token ring? topic hijack: was Re: Mystery open source switching
Hats off!! You should post some pictures! cheers C. On Tue, Nov 2, 2010 at 4:55 PM, Michael Sokolov msoko...@ivan.harhan.orgwrote: Carlos Martinez-Cagnazzo carlosm3...@gmail.com wrote: Not only token ring. I know of some coaxial ethernets that were running as late as 2007. The network I am using to compose and post this message right now is a coaxial Ethernet. MS -- -- = Carlos M. Martinez-Cagnazzo http://cagnazzo.name =
Re: ipv6 vs. LAMP
Hi all, the replication point is a good one, I did not think about that. However, I still believe that on the road to v6 adoption, databases are far from being our most pressing roadblock. Thanks all! Carlos On Fri, Oct 22, 2010 at 4:52 PM, Jerry B. Altzman jba...@altzman.comwrote: Only to you. on 10/22/2010 10:02 AM Carlos Martinez-Cagnazzo said the following: IMHO you should never, ever make your MySQL accesible over the public Internet, which renders the issue of MySQL not supporting IPv6 correctly mostly irrelevant. You could even run your MySQL behind your web backend using RFC1918 space (something I do recommend). Except for those of us who have to support applications based upon MySQL replication...in that case, we use IP-based access rules on a firewall in front, and on the host, and on the MySQL server itself. But we still need IP access to it. We could shade it all by using IPSec or VPN tunnels, but that's more administrative overhead, and MySQL replication is fragile enough without adding that. Moreover, if you need direct access to the engine, you can trivially create an SSH tunnel (You can even do this in a point-and-click way using the latest MySQL Workbench). SSH works over IPv6 just fine. See above about replication. Carlos //jbaltz -- jerry b. altzmanjba...@altzman.com www.jbaltz.com thank you for contributing to the heat death of the universe. -- -- = Carlos M. Martinez-Cagnazzo http://cagnazzo.name =
Re: IPv6 fc00::/7 ??? Unique local addresses
Amen! On Fri, Oct 22, 2010 at 11:38 AM, Leo Bicknell bickn...@ufp.org wrote: There are some folks (like me) who advocate a DHCPv6 that can convey a default gateway AND the ability to turn off RA's entirely. That is make it work like IPv4. I'd also love to turn off stateless autoconfig altogether and not be coerced to assign /64s to single LANs, which I am becoming convinced that it was a poor decision on the IETFs part. Stateless autoconfig works very well, It would be just perfect if the network boundary was configurable (like say /64 if you really want it, or /80 - /96 for the rest of us) cheers Carlos -- -- = Carlos M. Martinez-Cagnazzo http://cagnazzo.name =
Re: ipv6 vs. LAMP
IMHO you should never, ever make your MySQL accesible over the public Internet, which renders the issue of MySQL not supporting IPv6 correctly mostly irrelevant. You could even run your MySQL behind your web backend using RFC1918 space (something I do recommend). Moreover, if you need direct access to the engine, you can trivially create an SSH tunnel (You can even do this in a point-and-click way using the latest MySQL Workbench). SSH works over IPv6 just fine. And for the LAMP stack, as long as the A fully supports IPv6 (which it does), we are fine. Warm regards, Carlos On Thu, Oct 21, 2010 at 8:06 PM, Joel Jaeggli joe...@bogus.com wrote: On 10/21/10 2:59 PM, Brandon Galbraith wrote: On Thu, Oct 21, 2010 at 4:53 PM, Dan White dwh...@olp.net wrote: On 21/10/10 14:43 -0700, Leo Bicknell wrote: In a message written on Thu, Oct 21, 2010 at 01:53:49PM -0700, Christopher McCrory wrote: open to the world. After a few google searches, it seems that PostgreSQL is in a similar situation. I don't know when PostgreSQL first supported IPv6, but it works just fine. I just fired up a stock FreeBSD 8.1 system and built the Postgres 8.4 port with no changes, and viola: All this is pretty moot point if you run a localized copy of your database (mysql or postgres) and connect via unix domains sockets. True. It mostly affects shared/smaller hosting providers who have customers that want direct access to the database remotely over the public network (and don't want to use some local admin tool such as phpMyAdmin). linux/unix machines can trivially build ip-tunnels of several flavors. -brandon -- -- = Carlos M. Martinez-Cagnazzo http://cagnazzo.name =
Re: Hey Leber - you think Melissa is going to issue that refund properly or do we need to escalate this into legal actions against HE
Maybe that's why they shut the power off in the first place... :-) I just could not resist, sorry! BTW, who's Leber? He/she doesn't seem to be CCed. I have more mailing lists to suggest where he/she might be found... I could not resist, Take II. cheers, Carlos -- -- = Carlos M. Martinez-Cagnazzo http://cagnazzo.name =
Re: P2P link over STM-1
In addition, you can use either PPP or HDLC as L2 over POS. On Fri, Oct 8, 2010 at 2:05 AM, Per Carlson pe...@hemmop.com wrote: If it's a full STM-1, your client might be thinking of POS (packet over sonet/sdh). This is (were) a very common high bandwidth technology some years ago. At least the 7200 do have cheap POS interfaces. -- Pelle (sorry about the top-posting, I'm on a mobile device) -- -- = Carlos M. Martinez-Cagnazzo http://cagnazzo.name =
Re: P2P link over STM-1
As said above, STM-1s are by their very nature point to point links. You just need an STM-1 interface on your side and another on the customer side. Which one will depend on the router models you will be using. Also, as said above, you will need to engage the help of your local Cisco partner for this. From your side (I mean the service provider side) you can also have a channelized STM-4 or STM-16 and use one STM-1 channel for this. This would be a good idea if you plan to have more than one customer of this nature. Beware that these interfaces can be quite expensive. Hope this helps, Carlos On Thu, Oct 7, 2010 at 4:24 AM, Peter Rudasingwa peter.rudasin...@altechstream.rw wrote: I have clients who want a P2P link over STM-1. How can I achieve this? What kind of equipment do I need. At the moment I have a cisco 6500 and 7200VXR Thanks, Peter R. -- -- = Carlos M. Martinez-Cagnazzo http://cagnazzo.name =
