- Test - lists.nanog.org

IPTV, Multicast, and IPv6 Transition
by Tom Taylor 08 Aug '12

08 Aug '12

This may be way off in the future for some of you, or others may be past it. In support of possible work on IPv6 transition in the IETF MBONED Working Group, I'm looking for an indication of what use cases are realistic for operators who: -- deliver IPTV to their customers -- use multicast for the purpose, either now or in the near future -- are making the transition from IPv4 to IPv6. First question: does anyone anticipate a situation where you will have to translate multicast content from a IPv4-only source so it can be delivered to an IPv6-only receiver, or vice versa? Second question: the current official view is that dual stack is the sensible way to transition your network, and failing that, you can use Automatic Multicast Tunneling, an almost-ready Internet Draft available at http://datatracker.ietf.org/doc/draft-ietf-mboned-auto-multicast/ to tunnel multicast packets through a single-stack network when necessary. Do you consider your requirements adequately addressed by this view? People who really want to be helpful can comment on the problem statement and use cases documented in http://datatracker.ietf.org/doc/draft-ietf-mboned-v4v6-mcast-ps/ Thanks for your attention. Privacy will be respected if people want to reply privately. Tom Taylor Consultant

1 0

MXLogic outage
by Duane Toler 08 Aug '12

08 Aug '12

Probably old news by now, but MXLogic folks are having some major issues today and not reliably receiving inbound mail. Several of our customers are talking with MXLogic about it. FYI. -- Duane Toler detoler(a)gmail.com

3 3

raging bulls
by Eugen Leitl 08 Aug '12

08 Aug '12

http://www.wired.com/business/2012/08/ff_wallstreet_trading/all/ Some interesting, network-relevant content there (but for the neutrino and drone rubbish).

12 21

RE: raging bulls
by Naslund, Steve 08 Aug '12

08 Aug '12

Are there not mechanisms to handle replay attacks? There is also the minor matter of fraud and regulatory concerns. You might get away with it a few times but not often enough to avoid a potential death penalty of being disconnected. Steve -----Original Message----- From: Alexandre Snarskii [mailto:snar@snar.spb.ru] Sent: Wednesday, August 08, 2012 9:46 AM To: Naslund, Steve Cc: Alexandre Snarskii Subject: Re: raging bulls On Wed, Aug 08, 2012 at 09:08:18AM -0500, Naslund, Steve wrote: > Also, we are only talking about a delay long enough to satisfy the > longest circuit so you could not push your timestamp very far back and > would have to get the fake one done pretty quickly in order for it to > be worthwhile. The real question is could you fake a cryptographic > timestamp fast enough to actually gain time on the system. Possibly > but it would be a very tall order. Looks like replay attack works here: "attacker" can easily record encrypted timestamps and reuse them some milliseconds later, claiming "I had no knowledge on how market changed during this time, it's my provider had to re-route my traffic!!" > > Steve > > -----Original Message----- > From: Chu, Yi [NTK] [mailto:Yi.Chu@sprint.com] > Sent: Wednesday, August 08, 2012 9:01 AM > To: Naslund, Steve; nanog(a)nanog.org > Subject: RE: raging bulls > > What prevents someone to fake an earlier timestamp? Money can bend > light, sure can a few msec. > > yi > > -----Original Message----- > From: Naslund, Steve [mailto:SNaslund@medline.com] > Sent: Wednesday, August 08, 2012 9:53 AM > To: nanog(a)nanog.org > Subject: RE: raging bulls > > It seems to me that all the markets have been doing this the wrong way. > Would it now be more fair to use some kind of signed timestamp and > process all transactions in the order that they originated? Perhaps > each trade could have a signed GPS tag with the absolute time on it. > It would keep everyone's trades in order no matter how latent their > connection to the market was. All you would have to do is introduce a > couple of seconds delay to account for the longest circuit and then > take them in order. They could certainly use less expensive > connections and ensure that international traders get a fair shake. > > Steven Naslund > > -- In theory, there is no difference between theory and practice. But, in practice, there is.

1 0

RE: raging bulls
by Ryan Malayter 08 Aug '12

08 Aug '12

"Naslund, Steve" <SNaslund () medline com> wrote: > It seems to me that all the markets have been doing this the wrong way. > Would it now be more fair to use some kind of signed timestamp and > process all transactions in the order that they originated? Perhaps > each trade could have a signed GPS tag with the absolute time on it. It > would keep everyone's trades in order no matter how latent their > connection to the market was. All you would have to do is introduce a > couple of seconds delay to account for the longest circuit and then take > them in order. They could certainly use less expensive connections and > ensure that international traders get a fair shake. I can't see any incentive for any *influential* party involved (the big firms or the exchanges) to make the process "fair". The exchange gets more money for low-latency network access and expensive co-location. The moneyed firms with HFT capability of course do not want anyone else to have their advantage. Even governments don't want long-distance traders to have "fair" access, as that reduces the advantage of local tax-paying firms, thereby reducing tax revenue, jobs, etc. HFT is not just a US phenomenon; all major exchanges have basically the same sort of phenomenon. So UK-based trading firms with HFT setups very close to the FTSE exchanges have advantage over US-based firms that don't have HFT setups in London. -- RPM

1 0

RE: Wanted: Asia bandwidth test files
by David Wilde 07 Aug '12

07 Aug '12

Hi Micah, > From: micah anderson [mailto:micah@riseup.net] > > Thanks for the suggestion. Do you know what their bandwidth is? I can > easily pull a .iso or similar from there to do some tests. > There's some info at http://mirror.aarnet.edu.au/indexabout.html - it's connected at 10Gbps. Naturally what throughput you're able to get will depend on how you arrive on the AARNet network - there is unfortunately less bandwidth into the west of Australia from Asia is than there is into the east coast from the United States. David

1 0

Prefix Size Distribution in multiple flavors, on RIPEstat
by Vesna Manojlovic 07 Aug '12

07 Aug '12

Dear colleagues, thanks to the feedback we received after we've published the interactive widget for querying "RIR prefix size distribution" in RIPEstat, we created a follow-up: a dynamically updated web page that gives an overview of IPv4 address space prefix size distribution, per /8: https://stat.ripe.net/specials/registered-ipv4-prefix-size-distribution This page is updated once a day, and is based on statistics published by all 5 RIRs. Possible usage is general research about the distribution of address space, or prefix filtering based on minimum allocation size. If you want to query any other prefix size, and not only /8, or if you want to query for IPv6 space, here is the link to the widget: https://stat.ripe.net/widget/rir-prefix-size-distribution For the background, please find more information in RIPE Labs article about the widget: https://labs.ripe.net/Members/becha/rir-prefix-size-distribution-in-ripestat Looking forward to your comments or questions, regards, Vesna -- Vesna Manojlovic BECHA(a)ripe.net Senior Community Builder +31205354444 for Measurements Tools RIPE NCC http://ripe.net

1 0

IPv6 Toolkit v1.2.2 released
by Fernando Gont 07 Aug '12

07 Aug '12

Folks, We've released IPv6 toolkit version 1.2.2. It is available at: <http://www.si6networks.com/tools> (tarball and git repository). This version is meant to be fully-portable to Mac OS (the list of supported systems now including, at the very least, FreeBSD, NetBSD, OpenBSD, Linux, and Mac OS), and also incorporates a number of patches send by the community. Any feedback on the tools will be welcome (either unicast to me, or on the ipv6hackers mailing-list <http://lists.si6networks.com/listinfo/ipv6hackers/>). P.S.: If you've sent patches and your patches have not yet been applied, most likely it just means that I'm catching-up with them (feel free to resend!). Thanks! Best regards, -- Fernando Gont e-mail: fernando(a)gont.com.ar || fgont(a)si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

1 0

Cisco 7200 PCI Limitations
by shthead 07 Aug '12

07 Aug '12

Hi all, I have a 7200 series router (7204) here and I am trying to figure out something with it. Currently the router has a NPE-G1 card in it, giving it 3 gig interfaces but I need an extra gig interface on it to make 4. Having a look around the available options are either get a PA-GE card that fits into one of the slots on the router or to get a C7200-I/O-GE+E (I/O controller with a gbit port on it). The PA-GE wouldn't be suitable as looking at the Cisco site the PCI bus will limit it to 300mbit full duplex (and it goes on further to say it will be limited to approx 200mbit in best case scenario due to the design of the card) [1]. The other option left is the I/O controller. I found that you can get a port adaptor jacket card [2] for the 7200's that let you stick a normal interface card into the I/O controller slot (instead of the I/O controller itself). My main concern is if the jacket card uses its own PCI bus I am assuming the C7200-I/O-GE+E also connects via PCI which means it would be subject to the same limitations as the PA-GE. Does anyone have any idea if that would be correct and the only option for another gbit port would be to get another device? Thanks for the help [1] http://www.cisco.com/en/US/products/hw/routers/ps341/products_tech_note0918… [2] http://www.cisco.com/en/US/prod/collateral/routers/ps341/prod_qas0900aecd80…

6 6

Wanted: Asia bandwidth test files
by Micah Anderson 07 Aug '12

07 Aug '12

Hi, I'm sitting on what is advertised as a 100mbit/sec connection in Cambodia. I have been trying to verify that, because I do not believe it is valid. I did iperf tests from a number of network locations, and at one point I did get 71mbit/sec (most of the results were around 20-25mbit/sec or less). But I dont think 30 second iperf tests are particularly revealing when the bandwith rate might change drastically over the day. I considered doing a 3 day iperf test, but somehow this seems not how the tool was designed. Someone suggested I find test files from various Asian locations to download via wget. I found a bunch of 100mb test files for various providers in N. America and Europe on webhostingtalk, which were interesting, but I never got more than around 5mbit/sec with them. Does anyone have any machines in Japan, S. Korea, or other asian locations with good bandwidth. where they can host a 100mbit file so I can attempt to download it to test this? Other suggestions for reliable tests would also be welcome! Please, dont suggest some flash garbage :) thanks! micah --

7 6