This is probably appropriate for NZNOG as well, as there are no doubt
many operators wanting to learn IPv6 who are not on the IPv6 techsig
list at present.
Begin forwarded message:
> Dear all,
>
> The New Zealand IPv6 Steering Group, in conjunction with InternetNZ,
> Cisco, Braintrust and Victoria University, is hosting an IPv6
> technical
> workshop in Auckland from Monday 7 December to Friday 11 December.
>
> Attendence is limited to 28, and registration is on a first come,
> first
> served basis.
>
> Please see the attached document for details, and feel free to
> contact me if you would any further information.
>
> Regards
>
> Campbell Gardiner
> InternetNZ
> DDI: 04 495 2332
>
> www.internetnz.net.nz
>
Cheers!
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:AS18353
descr: advertised to AS9439 by Revera Limited - AS18353
members: 192.88.85.0/24^24-29,
202.55.99.0/24^24-29,
202.55.100.96/27^27-29,
202.55.96.176/28^28-29
admin-c: RPA1-NZRR
tech-c: RPA1-NZRR
notify: rpsl-admin(a)nzix.net
notify: nznog(a)list.waikato.ac.nz
notify: networkteam(a)revera.co.nz
mnt-by: MAINT-NZRR-NZ
changed: rpsl-admin(a)nzix.net 20070524
source: NZRR
REPLACED BY:
route-set: AS9439:RS-ROUTES:AS18353
descr: advertised to AS9439 by Revera Ltd - AS18353
members: 202.55.100.0/23^23-29,
192.88.85.0/24^24-29,
202.37.205.0/24^24-29,
202.55.99.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: networkteam(a)revera.co.nz
mnt-by: MAINT-NZRR-NZ
changed: rpsl-admin(a)nzix.net 20091105
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-ROUTES6:AS9503
descr: Route set advertised to AS9560 by FX Networks - AS9503
mp-members: 2402:6000:0:0:0:0:0:0/32^32-64,
2404:3800:0:0:0:0:0:0/32^32-64,
2001:0dce:0:0:0:0:0:0/48^48-64,
2001:0dce:e000:0:0:0:0:0/48^48-64,
2001:0df0:004a:0:0:0:0:0/48^48-64
admin-c: RPA1-NZRR
tech-c: RPA1-NZRR
notify: rpsl-admin(a)nzix.net
notify: nznog(a)list.waikato.ac.nz
notify: peering(a)fx.net.nz
mnt-by: MAINT-NZRR-NZ
changed: rpsl-admin(a)nzix.net 20090923
source: NZRR
REPLACED BY:
route-set: AS9560:RS-ROUTES6:AS9503
descr: Route set advertised to AS9560 by FX Networks - AS9503
mp-members: 2402:6000:0:0:0:0:0:0/32^32-64,
2404:3800:0:0:0:0:0:0/32^32-64,
2001:0dce:0:0:0:0:0:0/48^48-64,
2001:0dce:e000:0:0:0:0:0/48^48-64,
2001:0df0:004a:0:0:0:0:0/48^48-64,
2404:1800:0:0:0:0:0:0/32^32-64
admin-c: RPA1-NZRR
tech-c: RPA1-NZRR
notify: rpsl-admin(a)nzix.net
notify: nznog(a)list.waikato.ac.nz
notify: peering(a)fx.net.nz
mnt-by: MAINT-NZRR-NZ
changed: rpsl-admin(a)nzix.net 20091105
source: NZRR
------------------------------------------------------------
I keep getting asked about whether to use technology X or Y when
deploying an IPv6 network, especially
'transition'/'tunneling'/'coexistence' technologies.
Copypasta from a post I mate to NANOG just now. Sorry if you've read
this before, but I think it'll be a useful resource for people:
Instead of explaining the options over and over and hoping people can
make sense of the complexities of it, become experts, and make good
informed decisions, I've made a flow chart. Feel free to ask about
details and I can get in to the ranting part, this is really a place
to start.
Right now it assumes people only provide DSL or other dynamic sort of
services.
It also assumes DS-Lite people are insane, so probably need better
language there.
Also the first question is not necessarily about who you are, but who
is driving the IPv6 'build' - which is why native, 6rd and ds-lite are
not appropriate for the customer-driven side. I hope that makes sense.
No talk about ISATAP and stuff for inside the customer network either.
And before you ask no ISATAP is not appropriate for ISPs, doesn't work
through NAT.
Anyway:
- 6RD is used by free.fr. Not widely implemented by anyone yet.
- DS-Lite is something some guys at Comcast and others are talking
about. Not widely implemented by anyone yet.
- The rest you can figure out from wikipedia and stuff.
Please email me with any corrections, complaints, or threats if you're
a DS-Lite fan. I'll always keep old versions in this directory, and
the latest version will always have this filename, so please link to
it instead of copying it, etc. etc.:
http://www.braintrust.co.nz/resources/ipv6_flow_chart/ipv6_flow_chart-curre…
--
Nathan Ward
SP-NAT doesn't have to scale to 300 customers per IP. Just more than
1-1.
One IP address may only support 4-20 customers with SP-NAT. But
that's 4-6x what I currently get per IP. ie. take one of the /15s I
use now for dynamic addresses - we've gone from 132k (1-1) to as many
as a few million.
SP-NAT is inevitable - at some point we'll have no more IPs to have
and more customers than we have IPs requiring IPv4 connectivity.
IPv6 is a way of diverting traffic away from SP-NAT and having to only
ever buy SP-NAT boxes once.
MMC
On 01/11/2009, at 6:49 PM, jamie baddeley wrote:
> On Sun, 2009-11-01 at 15:15 +1030, Matthew Moyle-Croft wrote:
>> On 31/10/2009, at 5:58 PM, TreeNet Admin wrote:
>>
>>> The huge problem is all the home customers with ancient second-hand
>>> CPE.
>>>
>>>
>>
>> I don't think they're a huge problem as they're the least likely to
>> notice the implementation of SP-NAT in front of their connection. I
>> know at least one large ISP in our region considering this as phase
>> #1
>> of an SP-NAT implementation.
>
> I saw a great presentation at the IPv6 Hui that were held in
> Christchurch, Auckland and Wellington recently.
>
> It was presented by Dr Hiroshi Esaki from the WIDE project in Japan.
>
> He made it pretty clear that SP-NAT does not scale. See here:
> http://www.ipv6.org.nz/02C%20-%20Hiroshi%20Esaki%20keynote%20-%20IPv6%
> 20Hui.pdf
>
> Start at Page 9 :-)
>
> The point he makes is this. TCP has a limited numberspace. Stuff on
> the
> internet in terms of number of connections per session can be large
> (and
> unknown frankly).
>
> iTunes has in excess of 200 connections per session. Divide 65K by 200
> connections and you're left with an equation that says you can only
> serve iTunes to about 300 odd users from one NAT box.
>
> But you know that :-)
>
>
> jamie
>
>
>
>
>>
>> The big issue right now is: the lack of IPv6 native support in CPE
>> at
>> all. If we had the larger CPE vendors starting to implement (*)
>> then
>> with a 2 year replacement time for most CPE we'd be fine by the
>> time a
>> lack of v4 addresses starts to pinch.
>>
>> In NZ at the moment with VDSL2 starting to be rolled out it'd be a
>> PERFECT time to start squirrelling (or whatever marsuipal/mammal you
>> guys have) it into people's houses as people replace CPE. But I'm
>> guessing that it's not happening that way alas.
>>
>> We need to start getting IPv6 out there to end-customers to start the
>> ball rolling to start shaking the problems down. (And believe me
>> there a whole LOT of problems with IPv6 in actual real production to
>> DSL customers ...)
>>
>> (*) Let's face it - given that almost all the CPE is Linux based it's
>> just laziness on the CPE vendor's part as it's already bloody well
>> done for them.
>>
>> MMC
>
>
--
Matthew Moyle-Croft
Peering Manager and Team Lead - Commercial and DSLAMs
Internode /Agile
Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia
Email: mmc(a)internode.com.au Web: http://www.on.net
Direct: +61-8-8228-2909 Mobile: +61-419-900-366
Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
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:AS9503
descr: advertised to AS9560 by FX Networks - AS9503
members: 130.123.0.0/16^16-29,
131.203.0.0/16^16-29,
161.29.0.0/16^16-29,
161.65.0.0/16^16-29,
166.65.0.0/16^16-29,
119.15.0.0/19^19-29,
202.14.32.0/19^19-29,
112.109.64.0/20^20-29,
114.134.160.0/20^20-29,
119.47.112.0/20^20-29,
124.248.128.0/20^20-29,
202.46.160.0/20^20-29,
202.53.176.0/20^20-29,
202.86.96.0/20^20-29,
202.160.48.0/20^20-29,
210.48.160.0/20^20-29,
112.109.80.0/21^21-29,
117.18.80.0/21^21-29,
120.89.80.0/21^21-29,
192.173.16.0/21^21-29,
202.37.32.0/21^21-29,
202.46.176.0/21^21-29,
202.49.0.0/21^21-29,
202.78.240.0/21^21-29,
202.126.80.0/21^21-29,
202.160.112.0/21^21-29,
203.190.208.0/21^21-29,
110.232.144.0/22^22-29,
113.197.64.0/22^22-29,
202.37.48.0/22^22-29,
202.89.4.0/22^22-29,
203.99.132.0/22^22-29,
202.36.218.0/23^23-29,
202.49.164.0/23^23-29,
203.84.134.0/23^23-29,
203.217.142.0/23^23-29,
192.88.85.0/24^24-29,
192.88.99.0/24^24-29,
192.105.10.0/24^24-29,
192.122.171.0/24^24-29,
192.133.31.0/24^24-29,
192.195.219.0/24^24-29,
202.8.13.0/24^24-29,
202.12.0.0/24^24-29,
202.12.91.0/24^24-29,
202.20.97.0/24^24-29,
202.27.83.0/24^24-29,
202.36.33.0/24^24-29,
202.36.75.0/24^24-29,
202.36.119.0/24^24-29,
202.36.154.0/24^24-29,
202.36.162.0/24^24-29,
202.37.93.0/24^24-29,
202.37.168.0/24^24-29,
202.37.205.0/24^24-29,
202.46.188.0/24^24-29,
202.46.190.0/24^24-29,
202.49.106.0/24^24-29,
202.49.144.0/24^24-29,
202.49.168.0/24^24-29,
202.50.247.0/24^24-29,
202.55.99.0/24^24-29,
202.55.105.0/24^24-29,
202.55.107.0/24^24-29,
202.89.57.0/24^24-29,
203.89.178.0/24^24-29,
203.89.181.0/24^24-29,
203.89.187.0/24^24-29,
202.89.43.0/25^25-29,
123.100.117.192/27^27-29
admin-c: RPA1-NZRR
tech-c: RPA1-NZRR
notify: rpsl-admin(a)nzix.net
notify: nznog(a)list.waikato.ac.nz
notify: peering(a)fx.net.nz
mnt-by: MAINT-NZRR-NZ
changed: rpsl-admin(a)nzix.net 20091028
source: NZRR
REPLACED BY:
route-set: AS9560:RS-ROUTES:AS9503
descr: advertised to AS9560 by FX Networks - AS9503
members: 130.123.0.0/16^16-29,
131.203.0.0/16^16-29,
161.29.0.0/16^16-29,
161.65.0.0/16^16-29,
166.65.0.0/16^16-29,
119.15.0.0/19^19-29,
202.14.32.0/19^19-29,
112.109.64.0/20^20-29,
114.134.160.0/20^20-29,
119.47.112.0/20^20-29,
124.248.128.0/20^20-29,
202.46.160.0/20^20-29,
202.53.176.0/20^20-29,
202.86.96.0/20^20-29,
202.160.48.0/20^20-29,
210.48.160.0/20^20-29,
112.109.80.0/21^21-29,
117.18.80.0/21^21-29,
120.89.80.0/21^21-29,
192.173.16.0/21^21-29,
202.37.32.0/21^21-29,
202.46.176.0/21^21-29,
202.49.0.0/21^21-29,
202.78.240.0/21^21-29,
202.126.80.0/21^21-29,
202.160.112.0/21^21-29,
203.190.208.0/21^21-29,
110.232.144.0/22^22-29,
113.197.64.0/22^22-29,
202.37.48.0/22^22-29,
202.89.4.0/22^22-29,
203.99.132.0/22^22-29,
202.36.218.0/23^23-29,
202.49.164.0/23^23-29,
203.84.134.0/23^23-29,
203.217.142.0/23^23-29,
192.88.85.0/24^24-29,
192.88.99.0/24^24-29,
192.105.10.0/24^24-29,
192.122.171.0/24^24-29,
192.133.31.0/24^24-29,
192.195.219.0/24^24-29,
202.8.13.0/24^24-29,
202.12.0.0/24^24-29,
202.12.91.0/24^24-29,
202.20.97.0/24^24-29,
202.27.83.0/24^24-29,
202.36.33.0/24^24-29,
202.36.75.0/24^24-29,
202.36.119.0/24^24-29,
202.36.154.0/24^24-29,
202.36.162.0/24^24-29,
202.36.221.0/24^24-29,
202.37.93.0/24^24-29,
202.37.168.0/24^24-29,
202.37.205.0/24^24-29,
202.46.188.0/24^24-29,
202.46.190.0/24^24-29,
202.49.106.0/24^24-29,
202.49.144.0/24^24-29,
202.49.168.0/24^24-29,
202.50.247.0/24^24-29,
202.55.99.0/24^24-29,
202.55.105.0/24^24-29,
202.55.107.0/24^24-29,
202.89.57.0/24^24-29,
203.89.178.0/24^24-29,
203.89.181.0/24^24-29,
203.89.187.0/24^24-29,
202.89.43.0/25^25-29,
123.100.117.192/27^27-29
admin-c: RPA1-NZRR
tech-c: RPA1-NZRR
notify: rpsl-admin(a)nzix.net
notify: nznog(a)list.waikato.ac.nz
notify: peering(a)fx.net.nz
mnt-by: MAINT-NZRR-NZ
changed: rpsl-admin(a)nzix.net 20091030
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: AS45279:RS-ROUTES:AS9503
descr: advertised to AS45279 by FX Networks - AS9503
members: 130.123.0.0/16^16-29,
131.203.0.0/16^16-29,
161.29.0.0/16^16-29,
161.65.0.0/16^16-29,
166.65.0.0/16^16-29,
119.15.0.0/19^19-29,
202.14.32.0/19^19-29,
112.109.64.0/20^20-29,
114.134.160.0/20^20-29,
119.47.112.0/20^20-29,
124.248.128.0/20^20-29,
202.46.160.0/20^20-29,
202.53.176.0/20^20-29,
202.86.96.0/20^20-29,
202.160.48.0/20^20-29,
210.48.160.0/20^20-29,
112.109.80.0/21^21-29,
117.18.80.0/21^21-29,
120.89.80.0/21^21-29,
192.173.16.0/21^21-29,
202.37.32.0/21^21-29,
202.46.176.0/21^21-29,
202.49.0.0/21^21-29,
202.78.240.0/21^21-29,
202.126.80.0/21^21-29,
202.160.112.0/21^21-29,
203.190.208.0/21^21-29,
110.232.144.0/22^22-29,
113.197.64.0/22^22-29,
202.37.48.0/22^22-29,
202.89.4.0/22^22-29,
203.99.132.0/22^22-29,
202.36.218.0/23^23-29,
202.49.164.0/23^23-29,
203.84.134.0/23^23-29,
203.217.142.0/23^23-29,
192.88.85.0/24^24-29,
192.88.99.0/24^24-29,
192.105.10.0/24^24-29,
192.122.171.0/24^24-29,
192.133.31.0/24^24-29,
192.195.219.0/24^24-29,
202.8.13.0/24^24-29,
202.12.0.0/24^24-29,
202.12.91.0/24^24-29,
202.20.97.0/24^24-29,
202.27.83.0/24^24-29,
202.36.33.0/24^24-29,
202.36.75.0/24^24-29,
202.36.119.0/24^24-29,
202.36.154.0/24^24-29,
202.36.162.0/24^24-29,
202.37.93.0/24^24-29,
202.37.168.0/24^24-29,
202.37.205.0/24^24-29,
202.46.188.0/24^24-29,
202.46.190.0/24^24-29,
202.49.106.0/24^24-29,
202.49.144.0/24^24-29,
202.49.168.0/24^24-29,
202.50.247.0/24^24-29,
202.55.99.0/24^24-29,
202.55.105.0/24^24-29,
202.55.107.0/24^24-29,
202.89.57.0/24^24-29,
203.89.178.0/24^24-29,
203.89.181.0/24^24-29,
203.89.187.0/24^24-29,
202.89.43.0/25^25-29,
123.100.117.192/27^27-29
admin-c: RPA1-NZRR
tech-c: RPA1-NZRR
notify: rpsl-admin(a)nzix.net
notify: nznog(a)list.waikato.ac.nz
notify: peering(a)fx.net.nz
mnt-by: MAINT-NZRR-NZ
changed: rpsl-admin(a)nzix.net 20091028
source: NZRR
REPLACED BY:
route-set: AS45279:RS-ROUTES:AS9503
descr: advertised to AS45279 by FX Networks - AS9503
members: 130.123.0.0/16^16-29,
131.203.0.0/16^16-29,
161.29.0.0/16^16-29,
161.65.0.0/16^16-29,
166.65.0.0/16^16-29,
119.15.0.0/19^19-29,
202.14.32.0/19^19-29,
112.109.64.0/20^20-29,
114.134.160.0/20^20-29,
119.47.112.0/20^20-29,
124.248.128.0/20^20-29,
202.46.160.0/20^20-29,
202.53.176.0/20^20-29,
202.86.96.0/20^20-29,
202.160.48.0/20^20-29,
210.48.160.0/20^20-29,
112.109.80.0/21^21-29,
117.18.80.0/21^21-29,
120.89.80.0/21^21-29,
192.173.16.0/21^21-29,
202.37.32.0/21^21-29,
202.46.176.0/21^21-29,
202.49.0.0/21^21-29,
202.78.240.0/21^21-29,
202.126.80.0/21^21-29,
202.160.112.0/21^21-29,
203.190.208.0/21^21-29,
110.232.144.0/22^22-29,
113.197.64.0/22^22-29,
202.37.48.0/22^22-29,
202.89.4.0/22^22-29,
203.99.132.0/22^22-29,
202.36.218.0/23^23-29,
202.49.164.0/23^23-29,
203.84.134.0/23^23-29,
203.217.142.0/23^23-29,
192.88.85.0/24^24-29,
192.88.99.0/24^24-29,
192.105.10.0/24^24-29,
192.122.171.0/24^24-29,
192.133.31.0/24^24-29,
192.195.219.0/24^24-29,
202.8.13.0/24^24-29,
202.12.0.0/24^24-29,
202.12.91.0/24^24-29,
202.20.97.0/24^24-29,
202.27.83.0/24^24-29,
202.36.33.0/24^24-29,
202.36.75.0/24^24-29,
202.36.119.0/24^24-29,
202.36.154.0/24^24-29,
202.36.162.0/24^24-29,
202.36.221.0/24^24-29,
202.37.93.0/24^24-29,
202.37.168.0/24^24-29,
202.37.205.0/24^24-29,
202.46.188.0/24^24-29,
202.46.190.0/24^24-29,
202.49.106.0/24^24-29,
202.49.144.0/24^24-29,
202.49.168.0/24^24-29,
202.50.247.0/24^24-29,
202.55.99.0/24^24-29,
202.55.105.0/24^24-29,
202.55.107.0/24^24-29,
202.89.57.0/24^24-29,
203.89.178.0/24^24-29,
203.89.181.0/24^24-29,
203.89.187.0/24^24-29,
202.89.43.0/25^25-29,
123.100.117.192/27^27-29
admin-c: RPA1-NZRR
tech-c: RPA1-NZRR
notify: rpsl-admin(a)nzix.net
notify: nznog(a)list.waikato.ac.nz
notify: peering(a)fx.net.nz
mnt-by: MAINT-NZRR-NZ
changed: rpsl-admin(a)nzix.net 20091030
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:AS9503
descr: advertised to AS9439 by FX Networks - AS9503
members: 130.123.0.0/16^16-29,
131.203.0.0/16^16-29,
161.29.0.0/16^16-29,
161.65.0.0/16^16-29,
166.65.0.0/16^16-29,
119.15.0.0/19^19-29,
202.14.32.0/19^19-29,
112.109.64.0/20^20-29,
114.134.160.0/20^20-29,
119.47.112.0/20^20-29,
124.248.128.0/20^20-29,
202.46.160.0/20^20-29,
202.53.176.0/20^20-29,
202.86.96.0/20^20-29,
202.160.48.0/20^20-29,
210.48.160.0/20^20-29,
112.109.80.0/21^21-29,
117.18.80.0/21^21-29,
120.89.80.0/21^21-29,
192.173.16.0/21^21-29,
202.37.32.0/21^21-29,
202.46.176.0/21^21-29,
202.49.0.0/21^21-29,
202.78.240.0/21^21-29,
202.126.80.0/21^21-29,
202.160.112.0/21^21-29,
203.190.208.0/21^21-29,
110.232.144.0/22^22-29,
113.197.64.0/22^22-29,
202.37.48.0/22^22-29,
202.89.4.0/22^22-29,
203.99.132.0/22^22-29,
202.36.218.0/23^23-29,
202.49.164.0/23^23-29,
203.84.134.0/23^23-29,
203.217.142.0/23^23-29,
192.88.85.0/24^24-29,
192.88.99.0/24^24-29,
192.105.10.0/24^24-29,
192.122.171.0/24^24-29,
192.133.31.0/24^24-29,
192.195.219.0/24^24-29,
202.8.13.0/24^24-29,
202.12.0.0/24^24-29,
202.12.91.0/24^24-29,
202.20.97.0/24^24-29,
202.27.83.0/24^24-29,
202.36.33.0/24^24-29,
202.36.75.0/24^24-29,
202.36.119.0/24^24-29,
202.36.154.0/24^24-29,
202.36.162.0/24^24-29,
202.37.93.0/24^24-29,
202.37.168.0/24^24-29,
202.37.205.0/24^24-29,
202.46.188.0/24^24-29,
202.46.190.0/24^24-29,
202.49.106.0/24^24-29,
202.49.144.0/24^24-29,
202.49.168.0/24^24-29,
202.50.247.0/24^24-29,
202.55.99.0/24^24-29,
202.55.105.0/24^24-29,
202.55.107.0/24^24-29,
202.89.57.0/24^24-29,
203.89.178.0/24^24-29,
203.89.181.0/24^24-29,
203.89.187.0/24^24-29,
202.89.43.0/25^25-29,
123.100.117.192/27^27-29
admin-c: RPA1-NZRR
tech-c: RPA1-NZRR
notify: rpsl-admin(a)nzix.net
notify: nznog(a)list.waikato.ac.nz
notify: peering(a)fx.net.nz
mnt-by: MAINT-NZRR-NZ
changed: rpsl-admin(a)nzix.net 20091028
source: NZRR
REPLACED BY:
route-set: AS9439:RS-ROUTES:AS9503
descr: advertised to AS9439 by FX Networks - AS9503
members: 130.123.0.0/16^16-29,
131.203.0.0/16^16-29,
161.29.0.0/16^16-29,
161.65.0.0/16^16-29,
166.65.0.0/16^16-29,
119.15.0.0/19^19-29,
202.14.32.0/19^19-29,
112.109.64.0/20^20-29,
114.134.160.0/20^20-29,
119.47.112.0/20^20-29,
124.248.128.0/20^20-29,
202.46.160.0/20^20-29,
202.53.176.0/20^20-29,
202.86.96.0/20^20-29,
202.160.48.0/20^20-29,
210.48.160.0/20^20-29,
112.109.80.0/21^21-29,
117.18.80.0/21^21-29,
120.89.80.0/21^21-29,
192.173.16.0/21^21-29,
202.37.32.0/21^21-29,
202.46.176.0/21^21-29,
202.49.0.0/21^21-29,
202.78.240.0/21^21-29,
202.126.80.0/21^21-29,
202.160.112.0/21^21-29,
203.190.208.0/21^21-29,
110.232.144.0/22^22-29,
113.197.64.0/22^22-29,
202.37.48.0/22^22-29,
202.89.4.0/22^22-29,
203.99.132.0/22^22-29,
202.36.218.0/23^23-29,
202.49.164.0/23^23-29,
203.84.134.0/23^23-29,
203.217.142.0/23^23-29,
192.88.85.0/24^24-29,
192.88.99.0/24^24-29,
192.105.10.0/24^24-29,
192.122.171.0/24^24-29,
192.133.31.0/24^24-29,
192.195.219.0/24^24-29,
202.8.13.0/24^24-29,
202.12.0.0/24^24-29,
202.12.91.0/24^24-29,
202.20.97.0/24^24-29,
202.27.83.0/24^24-29,
202.36.33.0/24^24-29,
202.36.75.0/24^24-29,
202.36.119.0/24^24-29,
202.36.154.0/24^24-29,
202.36.162.0/24^24-29,
202.36.221.0/24^24-29,
202.37.93.0/24^24-29,
202.37.168.0/24^24-29,
202.37.205.0/24^24-29,
202.46.188.0/24^24-29,
202.46.190.0/24^24-29,
202.49.106.0/24^24-29,
202.49.144.0/24^24-29,
202.49.168.0/24^24-29,
202.50.247.0/24^24-29,
202.55.99.0/24^24-29,
202.55.105.0/24^24-29,
202.55.107.0/24^24-29,
202.89.57.0/24^24-29,
203.89.178.0/24^24-29,
203.89.181.0/24^24-29,
203.89.187.0/24^24-29,
202.89.43.0/25^25-29,
123.100.117.192/27^27-29
admin-c: RPA1-NZRR
tech-c: RPA1-NZRR
notify: rpsl-admin(a)nzix.net
notify: nznog(a)list.waikato.ac.nz
notify: peering(a)fx.net.nz
mnt-by: MAINT-NZRR-NZ
changed: rpsl-admin(a)nzix.net 20091030
source: NZRR
------------------------------------------------------------
NZNOG 2010 - Call for Participation and Papers
The next conference of the New Zealand Network Operators' Group is to be
held in Hamilton, New Zealand between 27 January and 29 January 2010. Our
host is the WAND group.
NZNOG meetings provide opportunities for the exchange of technical
information and discussion of issues relating to the operation and
support of network services, with particular emphasis on New Zealand.
The conference is low priced and has a strong technical focus with the
aim and history of getting a strong turnout of technical personal from
New Zealand Internet orientated companies.
Conference Overview
-------------------
NZNOG 2010 will consist of up to three days of workshops and tutorials
followed
by two days of conference presentations. There will also be opportunity for
more informal and small lightening talks. These are typically around five
minutes long and are organised closer to the actual conference.
Important Dates
---------------
Call for Papers opens: 29 October 2009
Deadline for speaker submissions: 1 December 2009
Responses to speaker submissions: 7 December 2009
Draft program published: 15 December 2009
Final program published: 15 January 2010
NZNOG 2009 Conference: 27 - 29 January 2010
SIG / Miniconf / Tutorials / Workshops
--------------------------------------
In previous years we have had a single day of workshops and tutorials,
this year however we are looking at having up to three days of workshops
and tutorials, if we can get the submissions.
Examples of past activities workshops include 'MPLS and fixed access
networks for beginners', 'Mikrotik RouterOS Training', 'APNIC Internet
Resource Management Essentials', and a System Administrators
mini-conference which included talks on 'Using Debian packages for
system administration' and '42 hosts in 1U: Using virtual machines'.
Conference Presentations
------------------------
The main conference program for 2010 will be made up of two days with a
single stream where possible. Presentations don't need to fit any particular
fixed length and can be from 30 minutes to 3 hours in length.
NZNOG conferences have traditionally spanned the entire operational
spectrum,
and then some. Proposals for conference presentations are invited for
virtually any topic with a degree of relevance to the NZNOG community.
Past years' talks have included the following:
- Internet exchange operations
- Global anycast networks and the building thereof
- Peering, peering, and peering
- Network security
- 10GB ethernet operations
- Advanced networks in NZ
- Current Internet research in NZ
- Wireless networking
- QOS over carrier networks
- Content distribution networks and media streaming
- How we paid the construction guys 18 pints of beer and they
gave us a free metro fibre network in Palmy North
- Open Source VoIP Platform in Carrier Environments
- Lawful Interception
- Designing networks for High Availability
Some ideas for this year also include the following:
- IPv6, been there done that
- DNS Security
- Routing Security
- Review of 2009
- IPSec
- Internet Filtering
- How Cloud Computing has impacted Network Design
If you are interested in submitting a talk please fill out the questions
at then end of this document and submit them to http://submission.nznog.org
Alternatively, you can and email them to talks(a)nznog.org
Submission Guidelines
---------------------
When considering a presentation or SIG, remember that the NZNOG audience
is mainly comprised of technical network operators and engineers with a wide
range of experience levels from beginners to multi-year experience. There is
a strong orientation to offer core skills and basic knowledge in the SIGs
and to address issues relevant to the day-to-day operations of ISPs and
network operators in the conference sessions.
The inclusion of a title, bio, topic, abstract, and slides with proposals
is not compulsory but each will help us determine the quality of your
proposal and increase the likelihood it will be accepted.
Final slides are to be provided by 15 January 2010.
Note: While the majority of speaking slots will be submitted by 15 December
2009,
a limited number of slots may be available for presentations that are
exceptionally timely, important, or of critical operational importance.
The NZNOG conference is a TECHNICAL conference so marketing and commercial
content is NOT allowed within the program. The program committee is charged
with maintaining the technical standard of NZNOG conferences, and will
therefore not accept inappropriate materials. It is expected that the
presenter be a technical person and not a sales or marketing person. The
audience is extremely technical and unforgiving, and expects that the
speakers
are themselves very knowledgeable. All sessions provide time for questions,
so presenters should expect technical questions and be prepared to deliver
insightful and technically deep responses.
Funding and Support
-------------------
NZNOG conferences are community run and funded events that try to keep the
cost to attendees as low as possible so generally we are unable to pay the
travel costs of speakers. There is a limited amount of funding available to
international speakers.
Conference presenters will not have to pay any registration fee for the day
they are presenting. Discounts for SIG and lightning talk presenters may
be available but are not automatic.
Lightning talks
---------------
Lightning talks are short talks/presentations that last no more than 10
minutes. This is a good opportunity to get your pet topic out there or
perhaps to get some experience with presenting without having to go to a
full talk. At NZNOG 2010 it is planned that there will be at least one
hour long lightning talk session.
Sponsors
--------
There are opportunities remaining for organisations to sponsor various
aspects of the NZNOG meeting.
Please contact sponsorship(a)nznog.org for more information
Contact
-------
General Enquiries
* info(a)nznog.org
Talks and Papers
* http://submission.nznog.org
* talks(a)nznog.org
Talk Proposals
--------------
Please submit all talk proposals (including lightning talks) via
http://submission.nznog.org or email talks(a)nznog.org along with the
requested information. Questions regarding talks can be sent to the same
address.
Sponsorship may be available for a limited number of overseas speakers
to attend the conference, please indicate if you require assistance
with travel and/or accommodation.
Author's Full Name:
Author's Email Address:
Author's affiliation:
Author's short biography:
Title of Talk:
Abstract:
Length of talk:
Please provide details if a version of this talk has previously been given:
Will travel and accommodation assistance be required:
