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.
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
===========================================================================
-----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-----
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
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
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
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
------------------------------------------------------------
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
------------------------------------------------------------
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
------------------------------------------------------------
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