May 2008 - NZNOG - University of Waikato Mail Lists

by Philip D'Ath

Initially those transit providers and ISPs that do offer IPv6 transit will be able to charge for this service as it will be a premium value add. However I can't see this business model being able to last for more than 6 years (through to 2012), and possibly only three years. After this point in time I expect IPv6 deployment will be standard, and will no longer be a premium service offering - it will be the standard offering, like IPv4 is today. Once IPv4 has become exhausted and you can't actually give a customer an IPv4 address then you definitely wont be able to charge more for IPv6 - otherwise the customer will walk. So do providers start implementing slowly now, and recoup some of their investment while they can, or wait till they are forced to do the upgrades and are not able to recoup any of their "new" investment. Rhetorical question.

12 years, 8 months

23
40
0 0

ReArch'08 and ACM CoNext 2008 CFPs

by Brian E Carpenter

Please excuse duplicates, and apologies if this seems too much like spam. Regards Brian Carpenter University of Auckland -------- Original Message -------- Subject: [Re-Arch'08] ReArch'08 Call For Papers Date: Thu, 29 May 2008 12:30:10 -0400 From: EDAS <help(a)edas-help.com> To: Brian Carpenter <brian.e.carpenter(a)gmail.com> ReArch’08 - Re-Architecting the Internet “Exploring what is broken with the Internet architecture and how to fix it.” Madrid, Spain 9 December, 2008 co-located with ACM CoNEXT'2008 sponsored by ACM Sigcomm http://www.sigcomm.org/co-next2008/rearch.html Motivation The Internet architecture has been remarkably successful in allowing a planet-scale internetwork to form. However, this architecture is losing its original simplicity and transparency as new classes of applications, operational and management requirements, business models, security mechanisms and scalability enablers give rise to point solutions that extend the architecture without regard to the original design principles. While these mechanisms are necessary for Internet operation under current economical, technical and social conditions, their combination has significantly reduced the potential for incremental evolution of the Internet architecture. This loss of flexibility is already being felt as the number of Internet nodes grows by another order of magnitude. Several substantial Future Internet initiatives have started in Europe, the US and Asia, and the vendor and network operator communities are also actively discussing the limitations of the current Internet architecture as well as its potential evolution. This workshop will discuss what the real underlying problems are with the Internet and how we might fix them so that the Internet architecture re-gains its simplicity and transparency and is fit for another 30+ years, so that the architectural simplicity and clarity of the Internet can be regained and retained for another 30+ years. This workshop solicits original, high-quality papers that analyze, and discuss ideas for a new Internet architecture, including specific improvements to current Internet protocols, especially at the internetworking, transport and application layers, new internetworking components that integrate into the existing architecture and ideas for clean-slate internetworking architectures. Topics ReArch'08 covers all aspects related to the current and future Internet architecture including, but not limited to, how the following impact on that architecture: New networking paradigms New business models New routing architectures New traffic engineering and congestion control mechanisms Measurements and analysis that characterize the real architectural limitations New architecture proposals and their implications for research New protocols that address the limitations Studies of interactions between stakeholders of the Internet and the architecture itself Design principles and interfaces to accommodate the conflicting interests of stakeholders in the architecture Principles of evolving future architectures Requirements for interworking with the existing Internet, and for deployability. Papers that present interesting, fresh ideas at an early stage are more suitable for this workshop than highly polished results or incremental refinements of previous work. Submissions may include position papers that point out new directions and stimulate discussion; position papers should be clearly marked. Submissions must be original and not already published in any other conference proceedings or journal. Proceedings of the workshop will be published in the ACM Digital Library. Submissions Submitted papers must be at most 6 pages long (including figures, tables, references, etc.) in the standard ACM double column format. All text must use font sizes of 10 points or larger. Longer submissions will not be reviewed. The review process is single-blind. Submissions will be done via EDAS. Submission Deadline: 15 August 2008 Notification: 10 October 2008 Workshop Co-Chairs Olivier Bonaventure - UCLouvain Marcelo Bagnulo - UC3M Joe Touch - USC/ISI Technical Program Committee Mark Allman ICIR Jari Arkko Ericsson Bob Briscoe BT Group Ken Calvert University of Kentucky Brian Carpenter University of Auckland Maoke Chen Tsinghua University Kenjiro Cho IIJ Jon Crowcroft University of Cambridge Philip Eardley BT Group Lars Eggert Nokia Research Center Kevin Fall Intel Research Pierre Francois UCLouvain Robert Hancock Roke Manor Research Mark Handley University College London Christian Huitema Microsoft Daniel Massey Colorado State University Martin May ETH Zurich Pekka Nikander Ericsson Research Nomadiclab Craig Partridge BBN Technologies Peter Steenkiste Carnegie Mellon University Iljitsch van Beijnum IMDEA Metworks Tilman Wolf University of Massachusetts -------- Original Message -------- Subject: [ACM CoNext 2008] ACM CoNext 2008 CFP Date: Thu, 29 May 2008 04:56:53 -0400 From: EDAS <help(a)edas-help.com> To: Brian Carpenter <brian.e.carpenter(a)gmail.com> [We apologize in advance if you receive multiple copies of this message] [Please distribute it where you feel appropriate] ========================================================================== ACM CoNEXT 2008: Call for Papers The 4th ACM International Conference on emerging Networking EXperiments and Technologies (ACM CoNEXT 2008) Organized by IMDEA Networks and University Carlos III of Madrid, sponsored by ACM SIGCOMM 9-12 December 2008 Leganes, Madrid, SPAIN http://www.co-next.net CALL FOR PAPERS The 4th ACM International Conference on emerging Networking EXperiments and Technologies (ACM CoNEXT), to be held in Madrid, will have the primary goal of promoting stimulating exchanges between various international research communities. The main conference will be preceded by a one-day workshop, and will be a major forum for presentations and discussions of novel networking technologies that will shape the future of Internetworking. The conference is single-track and will feature a high-quality technical program with significant opportunities for individual and small-group technical and social interactions. ACM CoNEXT seeks to foster open discussions on technology alternatives and to be a forum accommodating multiple viewpoints, and is committed to a fair, timely, and thorough review process providing authors of submitted papers with sound and detailed feedback. As its name suggests, ACM CoNEXT 2008 solicits papers on emerging networking experiments, measurements, paradigms, with particular emphasis on creative, out-of-the-box thinking. Additionally, papers reporting on the deployment and performance of services or exploring network functionality aimed at better supporting new services are also welcome. We welcome submissions based on implementation and experimentation, as well as simulation and analytical approaches. Relevant topics for the conference include, but are not limited to the following: o Internet measurement and modeling o Wireless and mobile networks o Ad hoc and sensors networks o Economic aspects of the Internet o Network security issues o Multimedia networking o Peer-to-peer and overlay networks o Routing and traffic engineering o Delay and disruption tolerant networks o New networking protocols and architectures o Autonomic and dependable communications o Networked systems applications and services SUBMISSION INSTRUCTIONS Submissions must be original, unpublished work, and not under consideration at another conference or journal. Conformance to the 12 pages, 10pts ACM SIGCOMM format will be strictly enforced. Electronic proceedings will be published by ACM, and the best papers forwarded to the IEEE/ACM Transactions on Networking for possible fast-track publication. Travel grants will be available to support student attendance at the conference. IMPORTANT DATES Abstract submission deadline: 30th June 2008 Submission Deadline: 7th July 2008 Notification: 25th September 2008 Conference Chairs Arturo Azcorra, U. Carlos III and IMDEA Networks, Spain Gustavo de Veciana, U. Texas at Austin, USA Program Chairs Keith W. Ross, Polytechnic University, USA Leandros Tassiulas, University of Thessaly, Greece Steering Committee Arturo Azcorra, U. Carlos III and IMDEA Networks, Spain Kenjiro Cho, IIJ Research Labs, Japan Serge Fdida, Universiy Pierre and Marie Curie, France Roch Guιrin, University of Pennsylvania, USA Jim Kurose, University of Massachusetts, USA Laurent Mathy, Lancaster University, UK Publications Chair Hassnaa Moustafa, France Telecom R&D (Orange Labs), France Local Arrangements Chairs Maria Calderon, U. Carlos III, Spain Carlos J. Bernardos, U. Carlos III, Spain ===========================================================================

12 years, 10 months

1
0
0 0

112/8 and 113/8 allocated to APNIC

by Leo Vegoda

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, The IANA IPv4 registry has been updated to reflect the allocation of two /8 IPv4 blocks to APNIC in May 2008: 112/8 and 113/8. You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space We have also updated the Sample XML Registry for IPv4 Address Space, which can be found at: http://www.iana.org/reports/2008/xml-registry-sample.html Please update your filters as appropriate. Regards, Leo Vegoda Manager, Number Resources - IANA -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFIPpkqvBLymJnAzRwRAgsYAJ9b7EumlIisvK2HvYuIpcnACzYr/wCgwS1s Km3F9ujlFdL9VbXPVTghWsU= =FcpK -----END PGP SIGNATURE-----

12 years, 10 months

1
0
0 0

Email issues from users of the global-gateway

by Chris Hodgetts

Hello We have reports today (starting at about 3am this morning) that mail is being rejected by us. Postfix errors out: May 29 14:15:22 app02 postfix/smtpd[22437]: lost connection after DATA from [host here] I can only see 4 companies so far today that have been having issues, but the common factor is they all are connected to global-gateway.net.nz Is anyone else seeing similar issues, am I being too simplistic in saying they are all connected there, but at the moment that's the common thread. Many[1] other uses who are successfully sending are not going through them. [1] Many because I have not checked all obviously

12 years, 10 months

2
3
0 0

DROA

by Tim John - Domainz

To Registrars and domain name agents. Heads up ... Domain Registry of America (DROA) appear to be sending out bogus renewal notices again. We've had several queries from customers today and had one or two 'renewal invoices' ourselves. It seems they are targeting people with .nz names but offering the same third level with a gTLD extension. FYI, Domain Registry of America operate out of Melbourne, AU. Funny that ! Regards, Tim

12 years, 10 months

1
0
0 0

XTRA(yahoo) automatically tagging legitimate mail as Spam

by Michael Hutchinson

Hi All, We are currently having an issue with one of our Exchange servers sending email to user mailboxes on Xtra. We have tracked the email leaving the server, and have EventID's from logs on the Exchange server telling us that delivery is successful. However, when we log into any of the Xtra mail accounts, we can see the emails are automatically being put into the Spam folder of those accounts. There is nothing about the emails to suggest they are spam, and the final received headers say nothing about Spam, let alone even that it has been checked for Spam. As far as I can see it is only affecting one of our domains. We have several other domains with exchange servers that deliver to Xtra mailboxes just fine. I have contacted support at Xtra about this, as well as Ted Grenfell (who got back to me straight away) and we're trying to collate enough data to attack the problem. Is anyone else having this issue? (It would be nice to know that we're not the only ones being picked on by Yahoo.) Cheers, Michael Hutchinson Manux Solutions Ltd

12 years, 10 months

18
26
0 0

NZRR Route Registry Update

by NZRR Database Notifications

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS4770 descr: advertised to AS9560 by ICONZ - AS4770 members: 210.48.0.0/17^17-29, 210.185.0.0/18^18-29, 210.54.160.0/19^19-29, 202.55.96.0/20^20-29, 202.174.160.0/20^20-29, 210.56.32.0/20^20-29, 117.18.80.0/21^21-29, 202.12.248.0/21^21-29, 202.37.144.0/21^21-29, 202.37.224.0/21^21-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 205.233.128.0/21^21-29, 202.36.36.0/22^22-29, 202.37.140.0/22^22-29, 202.37.200.0/22^22-29, 202.41.136.0/22^22-29, 203.80.60.0/22^22-29, 210.54.136.0/22^22-29, 210.55.24.0/22^22-29, 199.212.92.0/23^23-29, 202.21.136.0/23^23-29, 202.36.44.0/23^23-29, 202.36.76.0/23^23-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.61.2.0/23^23-29, 202.174.6.0/23^23-29, 205.233.136.0/23^23-29, 192.88.85.0/24^24-29, 192.107.113.0/24^24-29, 198.32.66.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.27.208.0/24^24-29, 202.36.119.0/24^24-29, 202.36.183.0/24^24-29, 202.37.57.0/24^24-29, 202.37.73.0/24^24-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.37.163.0/24^24-29, 202.37.232.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.159.0/24^24-29, 202.49.249.0/24^24-29, 202.50.87.0/24^24-29, 202.50.139.0/24^24-29, 205.233.243.0/24^24-29, 210.54.140.0/24^24-29, 210.54.211.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: deon(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080318 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS4770 descr: advertised to AS9560 by ICONZ - AS4770 members: 210.48.0.0/17^17-29, 210.185.0.0/18^18-29, 210.54.160.0/19^19-29, 202.55.96.0/20^20-29, 202.174.160.0/20^20-29, 210.56.32.0/20^20-29, 117.18.80.0/21^21-29, 120.138.16.0/21^21-29, 202.12.248.0/21^21-29, 202.37.144.0/21^21-29, 202.37.224.0/21^21-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 205.233.128.0/21^21-29, 202.36.36.0/22^22-29, 202.37.140.0/22^22-29, 202.37.200.0/22^22-29, 202.41.136.0/22^22-29, 203.80.60.0/22^22-29, 210.54.136.0/22^22-29, 210.55.24.0/22^22-29, 199.212.92.0/23^23-29, 202.21.136.0/23^23-29, 202.36.44.0/23^23-29, 202.36.76.0/23^23-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.61.2.0/23^23-29, 202.174.6.0/23^23-29, 205.233.136.0/23^23-29, 192.88.85.0/24^24-29, 192.107.113.0/24^24-29, 198.32.66.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.27.208.0/24^24-29, 202.36.119.0/24^24-29, 202.36.183.0/24^24-29, 202.37.57.0/24^24-29, 202.37.73.0/24^24-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.37.163.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.159.0/24^24-29, 202.49.249.0/24^24-29, 202.50.87.0/24^24-29, 202.50.139.0/24^24-29, 205.233.243.0/24^24-29, 210.54.140.0/24^24-29, 210.54.211.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: deon(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080529 source: NZRR ------------------------------------------------------------

12 years, 10 months

1
0
0 0

NZRR Route Registry Update

by NZRR Database Notifications

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS18119 descr: advertised to AS9560 by ACSData - AS18119 members: 202.46.160.0/20^20-29, 117.18.80.0/21^21-29, 202.126.80.0/21^21-29, 202.21.136.0/23^23-29, 202.61.2.0/23^23-29, 192.107.113.0/24^24-29, 202.36.44.0/24^24-29, 202.49.144.0/24^24-29, 202.49.249.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: lincoln(a)acsdata.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070706 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS18119 descr: advertised to AS9560 by ACSData - AS18119 members: 202.46.160.0/20^20-29, 114.110.32.0/21^21-29, 117.18.80.0/21^21-29, 202.126.80.0/21^21-29, 202.21.136.0/23^23-29, 202.61.2.0/23^23-29, 192.107.113.0/24^24-29, 202.36.44.0/24^24-29, 202.49.144.0/24^24-29, 202.49.249.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: lincoln(a)acsdata.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080523 source: NZRR ------------------------------------------------------------

12 years, 11 months

1
0
0 0

NZRR Route Registry Update

by NZRR Database Notifications

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS18119 descr: advertised to AS9439 by ACSData - AS18119 members: 202.46.160.0/20^20-29, 117.18.80.0/21^21-29, 202.126.80.0/21^21-29, 202.21.136.0/23^23-29, 202.61.2.0/23^23-29, 192.107.113.0/24^24-29, 202.36.44.0/24^24-29, 202.49.144.0/24^24-29, 202.49.249.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: lincoln(a)acsdata.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070706 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS18119 descr: advertised to AS9439 by ACSData - AS18119 members: 202.46.160.0/20^20-29, 114.110.32.0/21^21-29, 117.18.80.0/21^21-29, 202.126.80.0/21^21-29, 202.21.136.0/23^23-29, 202.61.2.0/23^23-29, 192.107.113.0/24^24-29, 202.36.44.0/24^24-29, 202.49.144.0/24^24-29, 202.49.249.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: lincoln(a)acsdata.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080523 source: NZRR ------------------------------------------------------------

12 years, 11 months

1
0
0 0

2mbps symmetric VSAT for Disaster Recovery

by Jonathan Brewer

Hi Folks, We're looking for anyone out there with 2mbps symmetric VSAT (or even an asymmetric service with minimum 2mbps up) that could be used for disaster recovery purposes. The link will sit idle until something major happens, and then will need to be turned up and used immediately. After checking with all the usual suspects, I was disappointed by all. None of the quotes I have received to date have had more than 1mbps contested upload. Anyone out there know something I don't? Thanks, Jon

12 years, 11 months

1
0
0 0

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

NZNOG May 2008