However, making it available as experimental-private-unicast gives vendors a reason to introduce support, and operators some flexibility to request it.
In a closed ecosystem it isn't terribly hard to deploy - managed gateways and BNGs are relatively easy to upgrade.
aj
(A Vendor. Who would introduce support for it.)
------Original Message------
From: Brian E Carpenter
To: aj(a)sneep.net
Cc: NZNOG(a)list.waikato.ac.nz
Subject: Re: [nznog] Bogan Lists?
Sent: 21 Oct 2011 17:23
On 2011-10-22 12:59, Alastair Johnson wrote:
> Personally I'd like to see 240/4 reclassified as experimental private addressing (ie. not Internet unicast), because that allows use in closed environments with a single administrative domain... Whether it ever happens or not depends on how enthusiastic people get about it, I suppose...
That was of course discussed but the conclusion was that it's hard-coded into many
IP stacks as invalid, so it would be pretty much unusable in practice.
Brian
--- aj(a)sneep.net wrote:
From: "Alastair Johnson" <aj(a)sneep.net>
Not so 10/8 related, but there are still possibilities for prefixes to change status
draft-fuller-240space
draft-wilson-class-e
And of course draft-weil-shared-transition-space-request may also impact with a classification of a prefix from public to "shared transition".
Oh and anyone using multicast might think carefully about filtering 224/4 depending on their network :-)
------------------------------------------------------------------------
I just copied the IPs from CYMRU and I didn't think of inter-AS multicast. DOH! Definitely gotta know your network before putting the bogon list in your routers! However, do you think the others have an actual chance to be implemented? (OS issues with those IP spaces and all that) Got any idea where IANA will pull the CGN /10 described in draft-weil-shared-transition-space-request from? If it's from one of those 'weird' spaces, then the above applies to that as well.
scott
-----------------------
--------------------
-------------------
_______________________________________________
NZNOG mailing list
NZNOG(a)list.waikato.ac.nz
http://list.waikato.ac.nz/mailman/listinfo/nznog
--- bmanning(a)vacation.karoshi.com wrote:
net 10 has flipped before, as has 192.0.0.0, and there remains flareups surrounding
the 224.0.0.0 block.
-----------------------------------------------
Can you elaborate? I don't seem to find much on search engines, except for these:
http://www.faqs.org/rfcs/rfc3330.html
" 192.0.0.0/24 - This block, corresponding to the numerically lowest of
the former Class C addresses, was initially and is still reserved by
the IANA."
I also just finished detail-scanning rfc1597 and rfc1627 but found nothing regarding it. I also found
http://ask.metafilter.com/111834/How-did-the-private-ip-address-ranges-get-…
which says:
"10.0.0.0/8 was the old ARPANET, which they picked up on 01-Jan-1983. When they shut down the ARPANET in 1990, the 10.0.0.0/8 block was freed. There was much argument about if there should ever be private IP spaces, given that a goal of IPv4 was universal to all hosts on the net.
In then end, practicality won out, and RFC 1597 reserved the now well known private address spaces. When ARPANET went away, the 10.0.0.0/8 allocation was marked as reserved and since it was known that the ARPANET was truly gone (the hosts being moved to MILNET, NSFNET or the Internet) it was decided that this was the best Class A block to allocate.
Note Class A. This was before CIDR. So, the Class A, B and C private address netblocks needed to come out of the correct IP ranges.
I know that 172.16.0.0/12 was picked because it offered the most continuous block of Class B (/16) addresses in the IP space that was in a reserved block. 192.0.0.0/24 was always reserved for the same reason that 0.0.0.0/8 and 128.0.0.0/16 were reserved (first blocks of the old Class C, A and B network blocks) so assigning 192.168.0.0/24 out as private fit well -- 192.0.2.0/24 was already TEST-NET, where you could use them in public documentation without fear of someone trying it (see example.com for another example.)"
However, I don't know the validity of that. You've been around the IP block a time or two... ;-) Can you point me in the right direction?
scott
-----------------------
--------------------
-------------------
--- bmanning(a)vacation.karoshi.com wrote:
On Fri, Oct 21, 2011 at 10:21:11AM -0700, Scott Weeks wrote:
>
> As a side note for admins that use the bogon list, for IPv4 you might as well go to the end state:
: End state? Heard that a couple of times before...
------------------------------------------------------------
I'm not following. Do you mean you think they'll allocate IPv4 from these to the RIRs?
> 0.0.0.0 255.0.0.0
> 10.0.0.0 255.0.0.0
> 127.0.0.0 255.0.0.0
> 169.254.0.0 255.255.0.0
> 172.16.0.0 255.240.0.0
> 192.0.0.0 255.255.255.0
> 192.0.2.0 255.255.255.0
> 192.168.0.0 255.255.0.0
> 198.18.0.0 255.254.0.0
> 198.51.100.0 255.255.255.0
> 203.0.113.0 255.255.255.0
> 224.0.0.0 224.0.0.0
scott
As a side note for admins that use the bogon list, for IPv4 you might as well go to the end state:
0.0.0.0 255.0.0.0
10.0.0.0 255.0.0.0
127.0.0.0 255.0.0.0
169.254.0.0 255.255.0.0
172.16.0.0 255.240.0.0
192.0.0.0 255.255.255.0
192.0.2.0 255.255.255.0
192.168.0.0 255.255.0.0
198.18.0.0 255.254.0.0
198.51.100.0 255.255.255.0
203.0.113.0 255.255.255.0
224.0.0.0 224.0.0.0
unless you want to do fullbogons: www.team-cymru.org/Services/Bogons
scott
------------
-------------
------------
Thanks for everyone that responded help. I think I have found the problem. Dose anyone have a NOC contact for xtra.co.nz all the number I call go to there helpdesk and they don't know what I'm talking about.
Thank you
Andrew Paternoster
[cid:image001.png(a)01CC9004.44A08060]
Andrew Paternoster
Screwloose
Tel: (03) 9095-7290
Email: Andrew(a)screwloose.com.au<mailto:Andrew(a)screwloose.com.au>
Site: http://www.screwloose.com.au
You can now log faults by logging in to http://support.screwloose.com.au or just by simply emailing support(a)screwloose.com.au<mailto:support(a)screwloose.com.au>
From: Daniel Lawson [mailto:daniel(a)meta.net.nz]
Sent: Friday, 21 October 2011 2:38 PM
To: Andrew Paternoster
Subject: Re: [nznog] Bogan Lists?
tr.meta.net.nz<http://tr.meta.net.nz> is a somewhat neglected multi-view traceroute server.
http://tr.meta.net.nz/display.php/2011-10-21_16:31_103.4.122.20-2
It's missing a bgp feed at the moment, which is why if you use it directly most of the graphs don't look too pretty (it normally throws AS information in)
Hi Guys
We have moved a customers server over to our new ip range and now we are having reports that some customers in NZ can no longer reach the hosted site.
If any one has some spare time can they please ping 103.4.122.20 and if the ping fails send me a trace route. That would be very much appreciated.
Thank you
Andrew Paternoster
<image001.png>
Andrew Paternoster
Screwloose
Tel: (03) 9095-7290
Email: Andrew(a)screwloose.com.au<mailto:Andrew(a)screwloose.com.au>
Site: http://www.screwloose.com.au
You can now log faults by logging in to http://support.screwloose.com.au or just by simply emailing support(a)screwloose.com.au<mailto:support(a)screwloose.com.au>
_______________________________________________
NZNOG mailing list
NZNOG(a)list.waikato.ac.nz<mailto:NZNOG(a)list.waikato.ac.nz>
http://list.waikato.ac.nz/mailman/listinfo/nznog
Has any one else been having issues with Telstraclear blocking outgoing
mail from clients not connected to a Telstraclear service?
We have a number of customers who have kept their Telstra email address
and settings and this has worked fine up till now. Nothing listed on the
TC website.
cheers
Hi,
ICANN is currently conducting a public comment period on six case studies of individual scripts to investigate any issues that need to be resolved to facilitate a good user experience for IDN variant TLDs. The public comments received will inform the formulation of the combined issues report.
If you have an interest in the possibility of IDN variant TLDs, please provide comments by 14 November. The Latin Case Study Team Issues Report and public comment forum can be found at:
http://www.icann.org/en/public-comment/idn-vip-latin-07oct11-en.htm
Regards,
Leo
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,
114.110.32.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,
202.134.48.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 20100804
source: NZRR
REPLACED BY:
route-set: AS9439:RS-ROUTES:AS18119
descr: advertised to AS9439 by ACSData - AS18119
members: 114.110.32.0/21^21-29,
202.126.80.0/21^21-29,
103.5.156.0/22^22-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,
202.134.48.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 20111020
source: NZRR
------------------------------------------------------------
