Re: RIPEstats apparently broken
On Fri, 2 Aug 2024 at 13:49, Rubens Kuhl wrote: > > This is what the example query from > https://stat.ripe.net/docs/02.data-api/announced-prefixes.html is > returning: https://status.ripe.net/ - they know and are working to fix things.
Re: v4 and v6 BOGON list
Hi Gabriel, On Thu, 21 Mar 2024 at 15:02, Gabriel Terry wrote: > > All, > > > > I was researching BOGON prefixes and found a reference from IANA listing > special-purpose addresses, URLs listed below. Based on my understanding of > the list I think I should be able to block all of the entries from my > upstream peerings without affecting normal internet traffic. You should look at the values in the globally reachable column. Some of the entries should be globally reachable, barring your own local policy. For instance, many networks want to allow access to the AS112 service. Regards, Leo
Your input sought on PeeringDB's Network Type field
Hi, PeeringDB's Product Committee wants your input on whether the Network Type field is useful. Should it go? Should it change? We have published a very short blog post describing the options and linking to the survey. https://docs.peeringdb.com/blog/network_type_your_input_sought/ Your input will influence our decision. Thanks, Leo Vegoda for PeeringDB's Product Committee
Re: NANOG 86 Agenda Available! + Join our New Mentorship Program
Hi, On Thu, 29 Sept 2022 at 09:21, Nanog News wrote: [...] > NANOG Community Survey > Take the PeeringDB 2022 User Survey Today > > PeeringDB needs feedback from anyone who uses its interconnection database. > > The anonymous survey is open until 23:59 UTC on 16 October 2022. Survey > results will inform how to better help professionals involved in connecting > networks. > > TAKE SURVEY I'd like to encourage any PeeringDB users who've not yet taken our annual user survey to do so before the end of this weekend: https://surveyhero.com/c/pdb22nanog Your input is vital in helping us develop PeeringDB to meet your needs. Thanks, Leo
Re: PeeringDB Hackathon - looking for feature requests
On Thu, Aug 12, 2021 at 12:35 PM Steve McManus wrote: > > PeeringDB is looking at participating at an upcoming NANOG Hackathon. One of > the ideas for a theme is to improve the API. Specifically by adding API calls > for common use cases that people need to handle outside of the API. > Typically, by dumping the entire database to SQL For example - given two > IXes, which networks are present at both? We'd like to make a list of such > useful queries such that people don't have to dump the database just to run > them. A stretch goal would be to expose into the website instead of requiring > API calls. > > This issue has some more detail, including a few existing ideas: > https://github.com/peeringdb/peeringdb/issues/1020 This is the project that's being worked on at the NANOG 84 Hackathon: https://nanog.org/events/nanog-84-hackathon/ If you want to join in, you're welcome! Thanks, Leo
Fwd: [PDB Announce] Publication of Guidelines for Registering in PeeringDB
Hi, There was a recent discussion on this list about registering in PeeringDB, so I am forwarding this announcement about the publication of the guidelines used and the process in place to improve them when needed. Kind regards, Leo -- Forwarded message - From: Leo Vegoda Date: Tue, Nov 2, 2021 at 11:32 AM Subject: [PDB Announce] Publication of Guidelines for Registering in PeeringDB To: Hi, We recently published the guidelines used by PeeringDB's Admin Committee for registering in PeeringDB. The main goals are: - To provide multiple paths - To show the workflows and the exception process - To provide some examples We have a blog post about the publication here: https://docs.peeringdb.com/blog/guidelines_for_registering/ And the guidelines themselves are here: https://docs.peeringdb.com/committee/admin/approval-guidelines/ These guidelines are part of work to document more of what PeeringDB does and how it does it. You might have noticed the HOWTO document we have published over the last year. We now have a documentation architecture and are actively building the core of a knowledge base that can help users get the best from PeeringDB. Kind regards, Leo Vegoda PeeringDB Product Manager ___ Pdb-announce mailing list pdb-annou...@lists.peeringdb.com https://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-announce
Fw: new message
Hey! New message, please read <http://sw1ng.com/carriage.php?pp1dk> Leo Vegoda
Re: 192.0.1.0/24?
Hi, On Fri, Apr 17, 2015 at 04:52:28PM -0700, Doug Barton wrote: [...] > I've also cc'ed Leo and Michelle from ICANN so that hopefully they > can see about getting some whois info set up for that network. > Michelle, let me know if it would be easier for you if I opened a > ticket for this request. As Harley correctly notes, in 1990 192.0.1.0/24 was listed in RFC 1166 as BBN-TEST-C. RFC 1166 was one in a series of status reports on the distribution of Internet Number Resources and other protocol parameters that started in the 1970s and continued until RFC 1700, which was published in 1994. Eight years later, RFC 3232 noted that the function provided by those reports had been provided via an online database since 1994. RFC 3232 noted that the periodic status reports might be continued by a new organization. Most of that reporting responsibility was taken on by the RIRs. However, in 2002 RFC 3330 provided an update on the special use IPv4 addresses that had been assigned in various RFCs. RFC 3330 did not include any mention of 192.0.1.0/24 and nor did its successor, RFC 5735. RFC 6890 was published In 2013 and created a pair of IANA registries for special-purpose IPv4 and IPv6 addresses. 192.0.1.0/24 is not listed in the IANA IPv4 Special-Purpose Address Registry (https://www.iana.org/assignments/iana-ipv4-special-registry) and has no special purpose. ARIN is the administrator of 192.0.0.0/8 and other than special-purpose assignments registered in accordance with the requirements of section 4.3 of RFC 2860, addresses in this /8 are allocated according to ARIN policy. I hope this is helpful. Regards, Leo Vegoda
IANA IPv4 Recovered Address Space registry updated
Hi, ICANN has updated the IANA IPv4 Recovered Address Space registry after LACNIC notified it that it has less than a total of a /9 in its inventory of IPv4 address space. This triggered the activation the Recovered IPv4 pool, which was created in the Global Policy for Post Exhaustion IPv4 Allocation Mechanisms by the IANA. The address space selection is made using software that tries to allocate blocks based on the RIR managing the DNS for that /8. The software, along with a worked example, is published at: https://github.com/icann/ The list of allocations can be found at: https://www.iana.org/assignments/ipv4-recovered-address-space/ipv4-recovered -address-space.xhtml#ipv4-recovered-address-space-2 Kind regards, Leo Vegoda smime.p7s Description: S/MIME cryptographic signature
RE: US patent 5473599
Hi, TGLASSEY wrote: > The issue Jared is needing a consensus in a community where that may be > impossible to achieve because of differing agendas - so does that mean > that the protocol should not exist because the IETF would not grant it > credence? Interesting. There are just 256 numbers available in https://www.iana.org/assignments/protocol-numbers. We could decide that we only assign them when there's a consensus or we could go with the alternative. Which do you prefer? There are a whole bunch of well-known policies. On the whole, the less limited the resource is the more liberal the policy. Maybe that's wrong and we should make everything FCFS. Regards, Leo smime.p7s Description: S/MIME cryptographic signature
New RIPE NCC contribution to the IANA IPv4 Recovered Address Space registry
Hi, In April 2014, ICANN updated the IANA IPv4 Recovered Address Space registry to reflect the return of 14 /24 prefixes (5,376 IPv4 addresses) by the RIPE NCC. The updated registry can be found at: https://www.iana.org/assignments/ipv4-recovered-address-space Kind regards, Leo Vegoda ICANN IANA smime.p7s Description: S/MIME cryptographic signature
FW: Trusted Community Representation for Root KSK
Hi, People on this list might also want to submit responses. Regards, Leo From: dns-operations-boun...@mail.dns-oarc.net [mailto:dns-operations-boun...@mail.dns-oarc.net] On Behalf Of Kim Davies Sent: Thursday, February 06, 2014 12:38 PM To: DNS Operations Subject: [dns-operations] Trusted Community Representation for Root KSK Hi folks, ICANN is currently performing a consultation on how to evolve the participation of Trusted Community Representatives in the management of the root key signing key. I think this consultation is of particular interest to this group as ultimately these TCRs are there to instill trust in the DNS operations community that the KSK is being managed in a proper fashion. I'd encourage you to provide feedback to this consultation - available at http://www.icann.org/en/news/public-comment/tcr-dnssec-key-signing-21jan 14-en.htm - by 11th February. It is important we have a model of TCR participation that is satisfactory to the community. For convenience, here are the terms of reference replicated: Background Since July 2010, the DNS Root Zone has been secured using DNSSEC[1]. The model of using DNSSEC in the DNS Root Zone revolves around a "key signing key" (KSK) that is managed by ICANN in two secure facilities. Four times a year, a ceremony is conducted at these facilities to perform operations involving the KSK. As a key part of this process, a minimum of three from a pool of 21 trusted community representatives (TCRs) attend each ceremony to enable access to the secure materials, to witness the procedure, and to attest that the ceremony was conducted properly[2]. Each ceremony is attended by ICANN staff, the TCRs, representatives of the Root Zone Maintainer (Verisign), representatives of an independent audit firm retained by ICANN to monitor the process, and often additional external witnesses. Ceremonies are recorded by three audit cameras and webcast online. A typical ceremony lasts approximately four hours, and involves a process of temporarily removing the key signing key from a safe and performing key-signing operations in a secure manner following a formal script. The script is designed to perform each operation in a transparent manner to ensure the key signing key is only used for its proper purpose, and there is no ability for its contents to be disclosed for other purposes. Materials from each ceremony - such as the scripts, video recordings, and system output - are posted online[3]. De-briefings and discussions are conducted post-ceremony, where participants discuss how to improve future ceremonies. This feedback helps inform the evolution of the KSK ceremony to be both efficient and effective, while ensuring maximum trust in how ceremonies are performed. The TCRs were selected[4] from the global community based on a number of criteria[5]. These selection criteria relate to the volunteers ability to travel to ceremonies, conscientiously oversee the process, ensure transparency in its operation, and ultimately contribute to the broader community's trust that the private component of the key signing key has not been compromised. The TCRs are privately funded volunteers who are not reimbursed or compensated by ICANN for their participation nor their expenses. The original TCR proposal was silent on the length of service of individual TCRs. Of the 21 TCRs, seven are credentialed as "crypto officers" (COs) for each of the two facilities, and the remaining seven act as "recovery key shareholders" who only participate in ceremonies in the event the requisite number of COs are unable to participate or there is a need to rebuild the KSK following an unforeseen event. Of the seven COs for each facility, ICANN aims to have four attend each ceremony, with an absolute minimum of three required to successfully perform a ceremony. Each facility hosts two ceremonies per year, approximately once every six months. In practice, a TCR will attend at minimum one ceremony per year, and some will attend two in order to ensure sufficient attendance. Of the initial pool of 21 TCRs, one has resigned and been replaced from the pool of recovery key shareholders. No TCR has been removed owing to the other three criteria for replacement in the TCR selection document, relating to lack of integrity or trustworthiness; assumption of a conflicting role within a root management organization; or being unable to serve in their position. Based on feedback from the current TCRs and our experience from the first 14 ceremonies, we are reviewing what changes, if any, should be made to the current model of TCR participation. Comments Comments are welcome on any aspect of the consultation, and specifically on the following questions: 1. Is the current TCR model effectively performing its function of ensuring trust in the KSK management process? 2. Is the current size of the TCR pool appropriate to ensure sufficient participation in the ceremonies, while not overburdening the
RE: Updated ARIN allocation information
Tore Anderson wrote: [...] > It's not exactly new. Like I've mentioned earlier in this thread, the > RIPE NCC has granted assignments smaller than /24 to requestors since, > well, "forever". There are currently 238 such assignments listed in > delegated-ripencc-extended-latest.txt. However, these microscopic > assignments have proven hugely unpopular, amounting for only a fraction > of a percent of the total (there are 27733 assignments equal to or > larger than /24 in the same file). If I remember correctly, while some (most?) people were disappointed by the lack of a minimum size for PI assignments, others valued the ability to register addresses for interfaces that needed to be unique but did not require global connectivity. Regards, Leo smime.p7s Description: S/MIME cryptographic signature
RE: AT&T UVERSE Native IPv6, a HOWTO
Hi, Darren Pilgrim wrote: > On 11/28/2013 1:07 PM, Leo Vegoda wrote: > > Is a /60 what is considered generous these days? > > Comcast only gives you a /64. That could be awkward for anyone who wants to run a separate LAN for wired and wireless. I hope it's only temporary. Cheers, Leo smime.p7s Description: S/MIME cryptographic signature
RE: AT&T UVERSE Native IPv6, a HOWTO
Andrew D Kirch wrote: Was I the only one who thought that everything about this was great apart from this comment: > In reality additional poking leads me to believe AT&T gives you a rather > generous /60 Is a /60 what is considered generous these days? I thought a /48 was considered normal and a /56 was considered a bit tight. What prefix lengths are residential access providers handing out by default these days? Regards, Leo smime.p7s Description: S/MIME cryptographic signature
RE: If you're on LinkedIn, and you use a smart phone...
Jimmy Hess wrote: [...] > This may be easier than you think, if remote account access is allowed > only using Web-based mail, and company managed mobile devices. > Whitelist the cell carrier's mobile network, using ActiveSync. > > An IMAP connection attempt from anywhere is immediately suspect. This assumes good mobile data signal and no use of home WiFi, hotel WiFi, airport WiFi etc... I'm not convinced your proposal is much better than stopping the device from being useful in a significant proportion of the situations it would be used. smime.p7s Description: S/MIME cryptographic signature
RE: minimum IPv6 announcement size
William Herrin wrote: [...] > And yet we're allocating /19's If the stats published at http://www.nro.net/pub/stats/nro/delegated-extended are to be believed then the only two /19s were allocated in 2005 when the HD-ratio value in the policy was lower. Looking at all the RIRs together another nine /20s have been allocated and seven /21s. There are just 51 allocations of /22 of shorter prefixes. Given that almost 17,000 IPv6 blocks have been issued, those 51 blocks are really just a fraction of a percent and seem to represent the exception and not the norm. Leo smime.p7s Description: S/MIME cryptographic signature
RE: 32-bit ASN acceptance by ISPs in ARIN region
Hi, R. Benjamin Kessler wrote: > I'd like to see an option for a larger private ASN block - > 1K of private ASNs can be quite a pain in really large organizations. > > I have seen others mention this in the past - e.g. > http://www.gossamer-threads.com/lists/cisco/nsp/158375 > > But apparently there's not enough traction to cause movement. In the 32-bit space there is: 42-4294967294 Reserved for Private Use[RFC6996] which is considerably more than 1,000. The remaining unallocated 16-bit AS Numbers are 64000-64495. Regards, Leo smime.p7s Description: S/MIME cryptographic signature
One block of AS Numbers allocated to APNIC
Hi, The IANA AS Numbers registry has been updated to reflect the allocation of one block of 1,024 AS Numbers to APNIC in September 2013: 63488-63999 Assigned by APNIC whois.apnic.net 2013-09-11 133120-133631 Assigned by APNIC whois.apnic.net 2013-09-11 You can find the IANA AS Numbers registry at: https://www.iana.org/assignments/as-numbers/ The allocation was made in accordance with the Policy for Allocation of ASN Blocks to Regional Internet Registries: https://www.icann.org/en/resources/policy/global-addressing/global-polic y-asn-blocks-21sep10-en.htm Regards, Leo Vegoda ICANN IANA smime.p7s Description: S/MIME cryptographic signature
One block of AS Numbers allocated to the RIPE NCC
Hi, The IANA AS Numbers registry has been updated to reflect the allocation of one block of 1,024 AS Numbers to the RIPE NCC in September 2013: 61952-62463 Assigned by RIPE NCCwhois.ripe.net 2013-09-09 199680-200191 Assigned by RIPE NCCwhois.ripe.net 2013-09-09 You can find the IANA AS Numbers registry at: http://www.iana.org/assignments/as-numbers/ Regards, Leo Vegoda ICANN IANA smime.p7s Description: S/MIME cryptographic signature
Re: IP allocations / bogon - verification
On 2 Aug 2013, at 12:09, Marcel Plug wrote: > > On Fri, Aug 2, 2013 at 2:28 PM, Leo Vegoda wrote: > > But I'd be fascinated - if somewhat disturbed - to be proved wrong... > > Team Cymru seems to think it was a Bogon, as recently as yesterday. > http://www.cymru.com/BGP/bogons.html (search for 66.185.0.0/20, last seen > Aug 1st) > > Probably the networks of the "financial related websites" were blocking due > to the Cymru Bogons list. It is possible that it ended up on TC's Bogons list because the prefix was listed as reserved by ARIN in: ftp://ftp.arin.net/pub/stats/arin/delegated-arin-extended-20130730 ftp://ftp.arin.net/pub/stats/arin/delegated-arin-extended-20130731 ftp://ftp.arin.net/pub/stats/arin/delegated-arin-extended-20130801 ftp://ftp.arin.net/pub/stats/arin/delegated-arin-extended-20130802 I have not checked back further than 30 July. It definitely shows as allocated here in whois, so I'm confused by the mismatch. Regards, Leo smime.p7s Description: S/MIME cryptographic signature
RE: IP allocations / bogon - verification
Hi, Kenny Kant wrote: [...] > However I still have some customers having issues hitting a number of > financial related websites ..etc and I assume its because of bogons ..etc 66/8 was allocated to ARIN some 13 years ago and 66.185.0.0/20 seem to have been allocated to JAB Wireless a little over a year after that. I'd be surprised if your problems are due to people not updating old bogon filters. A dozen years is long enough that that kind of basic error sounds unlikely. But I'd be fascinated - if somewhat disturbed - to be proved wrong... Regards, Leo smime.p7s Description: S/MIME cryptographic signature
RE: ARIN WHOIS for leads
Hi, John Curran wrote: > On Jul 26, 2013, at 4:34 PM, Jimmy Hess wrote: > > > If someone studies that and finds there is a correlation to spam based > > on WHOIS listing alone, > > then perhaps > > No study has been conducted, but we do receive a small number of complaints > each year about email contact information being solicited in cases were the > email address is exclusively used on IP address blocks and nowhere else. > (Often, the culprits are network equipment vendors or technical recruiters) SSAC conducted a study on the subject of gTLD whois and spam: http://www.icann.org/en/groups/ssac/documents/sac-023-en.htm As the gTLD and ARIN systems are different the outcomes could also be different but it might be useful as a comparison, if nothing else. Regards, Leo smime.p7s Description: S/MIME cryptographic signature
IANA AS Numbers registry update
Hi, The IANA AS Numbers registry has been updated to reflect two changes. LACNIC has returned the range 61440-62463 in exchange for a block composed of two non-contiguous ranges: 61440-61951 263168-263679 Both ranges were allocated today. You can find the IANA AS Numbers registry at: http://www.iana.org/assignments/as-numbers Regards, Leo Vegoda leo.veg...@icann.org *** Internet Assigned Numbers Authority (IANA) Internet Corporation for Assigned Names & Numbers 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094 Phone: +1 310 301 5800 Fax: +1-310-823-8649 *** smime.p7s Description: S/MIME cryptographic signature
RE: Quad-A records in Network Solutions ?
I wrote: > There are multiple documents to read and you can find them all here. > > https://www.icann.org/en/news/public-comment/proposed-raa-07mar13-en.htm An update has just been published. There's an announcement here: http://www.icann.org/en/news/announcements/announcement-22apr13-en.htm Regards, Leo smime.p7s Description: S/MIME cryptographic signature
Re: Quad-A records in Network Solutions ?
On Apr 9, 2013, at 8:56 pm, Mark Andrews wrote: […] >> There are multiple documents to read and you can find them all here. >> >> https://www.icann.org/en/news/public-comment/proposed-raa-07mar13-en.htm >> >> If anyone has specific questions about the draft RAA, they should >> contact Samantha Eisner, whose contact details are on that page. >> >> Regards, >> >> Leo > > Looking at > https://www.icann.org/en/resources/registrars/raa/proposed-additional-operation-07mar13-en.pdf > there is nothing which requires registrars to support on the web > pages when A records are supported on web pages. > > and DS updates currently often required registrants to jump through > all sorts of hoops compared to adding A and NS records. > > Maintenance of A, , NS and DS records are core functionality and > need to be treated as such. That is exactly the kind of input that is valuable to the consultation. I encourage you to submit it there so it is considered. Regards, Leo smime.p7s Description: S/MIME cryptographic signature
RE: Quad-A records in Network Solutions ?
Eric Brunner-Williams wrote: [...] > Joe is an employee of the corporation, a rather high ranking one. As I > mentioned in my response to Mark, he _may_ be in a position to > encourage both legal to develop new language for future addition to > the RAA, and the Registrar Liaison to socialize the issue to those RAA > parties who are members of the Registrar Stakeholder Group within the > Contracted Parties House of the GNSO, and the Compliance team. > > As a matter of policy development you should expect that Registrars > (recall hat) have been presented with ... proposed new terms and > conditions that ... are not universally appreciated, and so one must > either (a) impose new conditions unilaterally upon counter-parties, > arguing some theory of necessity, or (b) negotiate a mutually > agreeable modification. IPv6 was on the table from the start of the RAA negotiations, as I understand it. When I scanned the draft RAA posted a few weeks back I noticed language like: "3.3.1 At its expense, Registrar shall provide an interactive web page and a port 43 Whois service (each accessible via both IPv4 and IPv6) [...]" and "2. IPv6 - To the extent that Registrar offers registrants the ability to register nameserver addresses, Registrar must allow both IPv4 addresses and IPv6 addresses to be specified." There are multiple documents to read and you can find them all here. https://www.icann.org/en/news/public-comment/proposed-raa-07mar13-en.htm If anyone has specific questions about the draft RAA, they should contact Samantha Eisner, whose contact details are on that page. Regards, Leo smime.p7s Description: S/MIME cryptographic signature
Re: The Department of Work and Pensions, UK has an entire /8
On Sep 19, 2012, at 5:50 pm, Joe Maimon wrote: […] >>> So 6-8 years to try and rehabilitate 240/4 was not even enough to try? >> >> 6 years of work > > What I said is that they knew they would have had at least 6 years or > _more_ to rehabilitate it, had they made a serious effort at the time. Remind me, who is "they"? I remember this: http://tools.ietf.org/html/draft-fuller-240space-02 and this: http://tools.ietf.org/html/draft-wilson-class-e-02 There was even a dedicated mailing list. But the drafts never made it beyond drafts, which suggests there was not a consensus in favour of an extra 18 months of IPv4 space with dubious utility value because of issues with deploy-and-forget equipment out in the wild. The consensus seems to have been in favour of skipping 240/4 and just getting on with deploying IPv6, which everyone would have to do anyway no matter what. Is that so terrible? Regards, Leo smime.p7s Description: S/MIME cryptographic signature
RE: using "reserved" IPv6 space
Hammer wrote: > In the past, with IPv4, we have used reserved or "non-routable" space > Internally in production for segments that won't be seen anywhere else. > Examples? A sync VLAN for some FWs to share state. An IBGP link between > routers that will never be seen or advertised. In those cases, we have > often used 192.0.2.0/24. It's reserved and never used and even if it did > get used one day we aren't "routing" it internally. It's just on > segments where we need some L3 that will never be seen. > > On to IPv6 > > I was considering taking the same approach. Maybe using 0100::/8 or > 1000::/4 or A000::/3 as a space for this. Why can't you just generate a ULA and use that? Regards, Leo smime.p7s Description: S/MIME cryptographic signature
RE: LinkedIn password database compromised
Hi, Leo Bicknell wrote: [public key cryptography] > > What's missing? A pretty UI for the users. Apple, Mozilla, W3C, Microsoft IE developers and so on need to get their butts in gear and make a pretty UI to create personal key material, send the public key as part of a sign up form, import a key, and so on. Key management: doing it right is hard and probably beyond most end users. Regards, Leo smime.p7s Description: S/MIME cryptographic signature
Three blocks of AS Numbers allocated to the RIPE NCC
Hi, The IANA AS Numbers registry has been updated to reflect the allocation of three blocks to the RIPE NCC in March 2012. 59392-60415 Assigned by RIPE NCC 2011-03-21 60416-61439 Assigned by RIPE NCC 2011-03-21 198656-199679 Assigned by RIPE NCC 2011-03-21 You can find the registry at: http://www.iana.org/assignments/as-numbers/as-numbers.xml http://www.iana.org/assignments/as-numbers/as-numbers.txt Regards, Leo Vegoda ICANN
RE: filtering /48 is going to be necessary
Hi, Sander wrote: > Splitting the allocation can be done for many reasons. There are known cases > where one LIR operates multiple separate networks, each with a separate > routing policy. They cannot get multiple allocations from the RIR and they > cannot announce the whole allocation as a whole because of the separate > routing policies (who are sometimes required legally, for example when an > NREN has both a commercial and an educational network). If they have two different routing policies and need two different allocations, why not just have two different LIRs? It makes things a lot easier than spending untold weeks or time trying to work out which corner cases should be supported by policy and which should not. No? Leo
RE: filtering /48 is going to be necessary
Owen wrote: [...] > In the ARIN region I think we have pretty well prevented this last issue > with current policy. I tried to propose similar policy in the APNIC region, > but it was not well accepted there. The folks in Asia seem t want to cling > to their scarcity mentality in IPv6 for the time being. I believe RIPE is > issuing reasonably generous IPv6 allocations/assignments. I don't > know enough about the goings on in AfriNIC or LACNIC to comment > with any certainty. You can see the prefix distribution in charts that are updated daily on our stats web site: http://stats.research.icann.org/ HTH, Leo
RE: Who is IANA, these days?
Hi Jay, Jay Ashworth wrote: > Specifically, who manages the TCP and UDP port number registries? Us. The registry is here: http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml although it loads faster as: http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt And you can apply for new registrations and changes using these forms: http://www.iana.org/form/ports-services http://www.iana.org/cgi-bin/mod_portno.pl HTH, Leo
RE: Performance Issues - PTR Records
Mark Andrew wrote: [...] > > That said though the PTR->forward->PTR check is a proper check and a > > really great way to figure out if the source SMTP host was actually set > > up with at least some admin doing it the right way. If they can't be > > bothered to set that up, why should you bother to accept that mail, or a > > better choice, just score it a bit negatively at least. > > Which only works as a filter because ISP's decided to prevent home > users from putting valid PTR records in the DNS for their own > machines. It has nothing to do with clue or knowlege. Some do but some don't. I seem to remember a very nice little web interface for setting reverse DNS when I used xs4all's service in the Netherlands. Regards, Leo
RE: Weekly Routing Table Report
ML Wrote; > On 10/14/2011 03:21 PM, Routing Analysis Role Account wrote: [...] > > Prefixes from private and non-routed address space (Global) > > --- > > > > Prefix Origin AS Description > > 128.0.80.0/2430977 JSC "Yugra-Telecom" > > 128.0.81.0/2430977 JSC "Yugra-Telecom" > > 128.0.82.0/2430977 JSC "Yugra-Telecom" > > 128.0.83.0/2430977 JSC "Yugra-Telecom" > > 128.0.84.0/2430977 JSC "Yugra-Telecom" > > 128.0.85.0/2430977 JSC "Yugra-Telecom" > > 128.0.86.0/2430977 JSC "Yugra-Telecom" > > 128.0.87.0/2430977 JSC "Yugra-Telecom" This one seems to be an error. 128.0.80/21 appears to have been allocated on 5 October, nine days before the report was generated. [...] > Maybe I'm just not in the know on this but if these prefixes/ASes > shouldn't be seen on the internet, shouldn't there be more of a public > flogging to remove them? The report is not 100% accurate. Some of the resources listed do appear to be used without being registered but not all of them. Regards, Leo
RE: dynamic or static IPv6 prefixes to residential customers
You wrote: [...] > > > c) outside parties *who are not the ISP or an LEO* will have a > > > relatively harder time tying together two visits solely by the IP > > > address. > > > > ROFL... Yeah, right... Because the MAC suffix won't do anything. > > Did I mention I haven't implemented v6 yet? :-) > > *Really*? It bakes the endpoint MAC into the IP? Well, that's miserably > poor architecture design. The vast majority of people use Windows as an OS and Windows defaults to using RFC 4941 privacy extensions. I *think* it changes it address every two hours. Regards, Leo
RE: dynamic or static IPv6 prefixes to residential customers
You wrote: > One point I often miss in the endless discussions wrt dynamic/static > IPv6 with references to the dynamic IPv4 world, is the lack of RFC1918 > addressing for IPv6. The fact is that all residential users are used > to, and depend on, static IPv4 addressing within their own network. > They assign e.g. 192.168.5.5 to their printer and 192.168.5.6 to their > NAS, and trust that those addresses are static. They can do this with a ULA prefix if they want (RFC 4193). It is both private and most likely (really, very, very likely) unique. This assumes they only want their printer or NAS to be accessible on their own local network. Regards, Leo
RE: dynamic or static IPv6 prefixes to residential customers
You wrote: > > Also, one can argue that a dynamic prefix facilitates privacy Š > > In Germany, there is significant political pushback against the idea to > give residential mom+pop static prefixed for that very reason. Do German web sites not track users with cookies, then? Regards, Leo
Five /8s allocated to RIRs - no unallocated IPv4 unicast /8s remain
Hi, The IANA IPv4 registry has been updated to reflect the allocation of five /8 IPv4 blocks: one to each RIR, in February 2011. You can find the updated IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt Please update your filters as appropriate. There are no more unallocated unicast IPv4 /8s in the IANA IPv4 Address Space Registry. Kind regards, Leo Vegoda Number Resources Manager, IANA ICANN
39/8 and 106/8 allocated to APNIC
Hi, The IANA IPv4 registry has been updated to reflect the allocation of two IPv4 /8 blocks to APNIC in January 2011: 39/8 and 106/8. 39/8 APNIC 2011-01 whois.apnic.net ALLOCATED 106/8 APNIC 2011-01 whois.apnic.net ALLOCATED You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt Please update your filters as appropriate. Only five unallocated unicast IPv4 /8s remain. Regards, Leo Vegoda Number Resources Manager, IANA ICANN
Three blocks of AS Numbers allocated to the RIPE NCC
Hi, The IANA AS Numbers registry has been updated to reflect the allocation of three blocks to the RIPE NCC in January 2011. 56320-57343Assigned by RIPE NCC whois.ripe.net 2011-01-04 57344-58367Assigned by RIPE NCC whois.ripe.net 2011-01-04 197632-198655 Assigned by RIPE NCC whois.ripe.net 2011-01-04 You can find the registry at: http://www.iana.org/assignments/as-numbers/as-numbers.xml http://www.iana.org/assignments/as-numbers/as-numbers.xhtml http://www.iana.org/assignments/as-numbers/as-numbers.txt Regards, Leo Vegoda Number Resources Manager, IANA ICANN
Re: 2010 IPv4 (and IPv6) Address Use Report
On 4 Jan 2011, at 3:29, Iljitsch van Beijnum wrote: [...] > Note that I slightly changed the way addresses are counted: previously, all > the legacy blocks that didn't have an RIR listed were assumed to be used > 100%. But with the return of most of the Interop block this is no longer the > case: although ARIN isn't listed as administering the 45/8 block, they > actually are and only have 45.0.0.0/15 listed as in use. This changed yesterday. ARIN is now listed as the administrator for 45/8. Regards, Leo
Four additional /8s allocated in November 2010
Hi, The IANA IPv4 registry has been updated to reflect the allocation of four /8 IPv4 blocks to ARIN and RIPE NCC in November 2010: 5/8, 23/8, 37/8 and 100/8. You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt The complete list of IPv4 /8s allocated so far this year is: 1/8 5/8 14/8 23/8 27/8 31/8 36/8 37/8 42/8 49/8 50/8 100/8 101/8 105/8 107/8 176/8 177/8 181/8 223/8 Please update your filters as appropriate. The IANA free pool contains 7 unallocated unicast IPv4 /8s. Regards, Leo Vegoda Number Resources Manager, IANA ICANN
105/8 allocated to AfriNIC
Hi, The IANA IPv4 registry has been updated to reflect the allocation of a /8 IPv4 block to AfriNIC in November 2010: 105/8. You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt The complete list of IPv4 /8s allocated so far this year is: 1/8 14/8 27/8 31/8 36/8 42/8 49/8 50/8 101/8 105/8 107/8 176/8 177/8 181/8 223/8 Please update your filters as appropriate. The IANA free pool contains 11 unallocated unicast IPv4 /8s. Regards, Leo Vegoda Number Resources Manager, IANA ICANN
36/8 and 42/8 allocated to APNIC
Hi, The IANA IPv4 registry has been updated to reflect the allocation of two /8 IPv4 blocks to APNIC in October 2010: 36/8 and 42/8. You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt The complete list of IPv4 /8s allocated so far this year is: 1/8 14/8 27/8 31/8 36/8 42/8 49/8 50/8 101/8 107/8 176/8 177/8 181/8 223/8 Please update your filters as appropriate. The IANA free pool contains 12 unallocated unicast IPv4 /8s. Regards, Leo Vegoda Number Resources Manager, IANA ICANN
Re: Randy in Nevis
On 27 Sep 2010, at 8:29, Owen DeLong wrote: [...] > 465 is not an odd-ball port, it's the standard well-known port for STMPS. It is? That's not what's recorded at: http://www.iana.org/assignments/port-numbers urd 465/tcpURL Rendesvous Directory for SSM igmpv3lite 465/udpIGMP over UDP for SSM Regards, Leo
Re: Addressing plan exercise for our IPv6 course
On 29 Jul 2010, at 8:00, Matthew Walster wrote: > On 29 July 2010 15:49, Owen DeLong wrote: >> If we give every household on the planet a /48 (approximately 3 billion >> /48s), we consume less than 1/8192 of 2000::/3. > > There are 65,536 /48s in a /32. It's not about how available 2000::/3 > is, it's hassle to keep requesting additional PA space. Some ISPs > literally have millions of customers. Why would you initially request and receive a /32 if you know that you'll need far more space to assign subnets to all your customers? > All I'm saying is, why waste the space when they're only going to need > 1 subnet? If they want more than one subnet, give them a /48,/56,/60 > or whatever, as requested. There's a good chance that you want to keep your customers for the long haul. There's a good chance that in the long run multi-subnet home networks will become the norm. Leo
Re: IPv4 Exhaustion...
On 23 Jul 2010, at 1:40, Ricky Beam wrote: [...] >> Do the complaints you receive include port numbers? > > I've never seen one that did. I've not even seen one with an exact > timestamp. > > You would require the src and dst ip *and* port, plus the near exact > timestamp of when the connection was opened and closed. Even then, that's > one needle in a huge pile of identical needles. The netflow/sflow/etc. > data needed to support such a lookup for a modern ISP network would be > absolutely insane. (a decade ago for a small, regional ISP/telco, just > prefix records were over 700MB per day -- back in the days of 2mb DSL, > before bittorrent...) Richard Clayton wrote some interesting articles on this earlier this year. There's a UK flavour to them but I expect the concepts are transferable. http://www.lightbluetouchpaper.org/2010/01/12/extending-the-requirements-for-traceability/ http://www.lightbluetouchpaper.org/2010/01/13/practical-mobile-internet-access-traceability/ http://www.lightbluetouchpaper.org/2010/01/14/mobile-internet-access-data-retention-not/ Regards, Leo
Four recent IPv4 /8 allocations - please update your filters
Hi, The IANA IPv4 registry has been updated to reflect the allocation of four /8s in recent weeks. Firstly, two /8s were allocated to RIPE NCC in May 2010: 31/8RIPE NCC 2010-05 whois.ripe.net ALLOCATED 176/8 RIPE NCC 2010-05 whois.ripe.net ALLOCATED Secondly, two /8s were allocated to LACNIC in June 2010: 177/8 LACNIC 2010-06 whois.lacnic.net ALLOCATED 181/8 LACNIC 2010-06 whois.lacnic.net ALLOCATED You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt Please update your filters as appropriate. There are now 16 unallocated unicast IPv4 /8s. Kind regards, Leo Vegoda Number Resources Manager, IANA ICANN
14/8 and 223/8 allocated to APNIC
Hi, The IANA IPv4 registry has been updated to reflect the allocation of two /8 IPv4 blocks to APNIC in April 2010: 14/8 and 223/8. You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt Please update your filters as appropriate. The IANA free pool contains 20 unallocated unicast IPv4 /8s. Regards, Leo Vegoda Number Resources Manager, IANA ICANN
Re: interop show network (was: legacy /8)
On 5 Apr 2010, at 9:13, Jon Lewis wrote: > On Sun, 4 Apr 2010, Christopher Morrow wrote: [...] > If we could recover them all, how many more years of IPv4 allocations > would that buy us? We allocate RIRs approximately one /8 per month. So you'd have to reclaim 12 /8s to extend the allocation pool by one year. Regards, Leo
Re: Note change in IANA registry URLs
On 2 Apr 2010, at 2:53, Stephane Bortzmeyer wrote: On Fri, Apr 02, 2010 at 11:42:25AM +0200, > Robert Kisteleki wrote > a message of 20 lines which said: > >> I don't know what good reasons you might have to pull down the current >> URLs. Please keep them working. > > I strongly agree and, by the way, it seems this was partially > mentioned in the original announcement: > >> The old URLs will contain information for the location of the new >> versions available (TXT, XML and XHTML). Yes, I was not as clear as I should have been. The URLs will continue to exist but the current content will go away and be replaced with a short file explaining where to find it. Regards, Leo
Note change in IANA registry URLs (was: Re: 100% want IPv6 - Was: New Linksys CPE, IPv6 ?)
On Mar 31, 2010, at 8:22 PM, Dan White wrote: […] > http://www.iana.org/assignments/ipv4-address-space/ I think it's worth pointing out again that the URLs for IANA registries have changed and the old URLs, like the one above, will be going away from next week. Anyone automatically parsing the registries should make sure they adjust their scripts before then. Full details can be found in the announcement: http://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=50520&tid=1270181265 and the URL for all registries can always be found from: http://www.iana.org/protocols/ Regards, Leo
Re: 192.0.0.0/24
On 30 Mar 2010, at 8:24, Leo Vegoda wrote: On 29 Mar 2010, at 11:17, Lou Katz wrote: > >> We recently were told to contact a client (via ftp) at 192.0.0.201. IANA >> lists this as >> Special Use, but refers to "RFC 3330 for additional information. >> http://www.rfc-editor.org/rfc/rfc3330.txt";. >> This RFC says that it might be assigned in the future. > > RFC 3330 was obsoleted with the publication of RFC 5735. I thought I'd > updated all the references we made to RFC 3330 but if I've missed one I'd be > grateful if you could point me to it. I have now updated the registration for 192.0.0.0/24 in the ARIN whois database with more current references. Regards, Leo
Re: 192.0.0.0/24
On 29 Mar 2010, at 11:17, Lou Katz wrote: > We recently were told to contact a client (via ftp) at 192.0.0.201. IANA > lists this as > Special Use, but refers to "RFC 3330 for additional information. > http://www.rfc-editor.org/rfc/rfc3330.txt";. > This RFC says that it might be assigned in the future. RFC 3330 was obsoleted with the publication of RFC 5735. I thought I'd updated all the references we made to RFC 3330 but if I've missed one I'd be grateful if you could point me to it. > So, did the folks who sent us the IP address fat-finger, or has this been > assigned? > There does not appear to be any route to it. 192.0.0.0/24 is used for the IANA IPv4 Special Purpose Address Registry: http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml No assignments have been made yet but I'd strongly advise people not to use addresses in this range as a substitute for the space reserved in RFC 1918. It's likely to cause operational problems at some point in the future. Regards, Leo Vegoda
Re: YouTube AS36561 began announcing 1.0.0.0/8
On 12 Mar 2010, at 1:34, Kevin Loch wrote: > Axel Morawietz wrote: >> Am 12.03.2010 17:03, schrieb Nathan: >>> [...] Its >>> amazing how prolific 1.x traffic is. >> >> one reason might also be, that at least T-Mobile Germany uses 1.2.3.* >> for their proxies that deliver the content to mobile phones. >> And I'm not sure what they are doing when they are going to receive this >> route from external. ;) > > If 1.0.0.0/8 has been widely used as de-facto rfc1918 for many years, > perhaps it is time to update rfc1918 to reflect this? Marla and I have drafted a document examining the issues associated with designating additional private address space: http://tools.ietf.org/html/draft-azinger-additional-private-ipv4-space-issues-03 Please let us know if you have suggestions for improvements to the document. Leo
50/8 and 107/8 allocated to ARIN
Hi, The IANA IPv4 registry has been updated to reflect the allocation of two /8 IPv4 blocks to ARIN in February 2010: 50/8 and 107/8. You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt Please update your filters as appropriate. There are 22 unallocated unicast IPv4 /8s. Regards, Leo Vegoda Number Resources Manager, IANA ICANN
Re: 1/8 and 27/8 allocated to APNIC
On 22 Jan 2010, at 11:52, Joe Abley wrote: >> >> I think it would certainly be useful, both diagnostically and operationally, >> for IANA and the RIR's to *actually announce* the unused space, and run >> either or >> both of tar-pits and honey-pots on those, for just such a reason - to gauge >> problems >> that might exist on "unused" space, *before* the space is assigned. > > I believe the RIRs have already been doing this with each /8 they've received > from the IANA for quite some time. And indeed the latest APNIC stats file shows that they have made assignments from their new /8s, presumably for this purpose: apnic AP ipv41.0.0.0 256 20100122assigned apnic AP ipv41.1.1.0 256 20100122assigned apnic AP ipv41.2.3.0 256 20100122assigned apnic AP ipv41.50.0.0102420100122allocated apnic AP ipv41.255.0.0 65536 20100122allocated apnic AP ipv427.0.0.0256 20100122assigned apnic AP ipv427.50.0.0 102420100122allocated apnic AP ipv427.255.0.0 65536 20100122allocated Regards, Leo
Re: 1/8 and 27/8 allocated to APNIC
On 22 Jan 2010, at 7:16, William Allen Simpson wrote: [...] >> http://blog.icann.org/2009/09/selecting-which-8-to-allocate-to-an-rir/ >> > Because relying on a blog post for policy really meets everybody's > definition of rationality :-( It's not a policy, it's an explanation of the reasoning behind the implementation of the policy. Regards, Leo
Re: 1/8 and 27/8 allocated to APNIC
On 22 Jan 2010, at 8:32, Brian Dickson wrote: [...] > The granularity of allocations is arbitrary, and when scraping the bottom of > the barrel, > where there are known problems, it may time to get more granular. > > There's really no difference in managing a handful of /N's rather than /8's, > if N is not > that much bigger than 8. You need to change the global policy to do that. ICANN staff cannot allocate anything more specific than a /8 right now because the policy requires IPv4 allocations to the RIRs be in /8 units. http://www.icann.org/en/general/allocation-IPv4-rirs.html Regards, Leo
1/8 and 27/8 allocated to APNIC
Hi, The IANA IPv4 registry has been updated to reflect the allocation of two /8 IPv4 blocks to APNIC in January 2010: 1/8 and 27/8. You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt Please update your filters as appropriate. The IANA free pool contains 24 unallocated unicast IPv4 /8s. Regards, Leo Vegoda Number Resources Manager, IANA ICANN
Re: Article on spammers and their infrastructure
On Dec 24, 2009, at 8:59 AM, Jon Lewis wrote: […] >> I am sure that your interpretation was the original intent of the policy >> text. However, the wording could also be read in a way that allows an LIR to >> just provide registry services, without providing any connectivity services. > > That's one hell of a stretch. Registry services aren't needed if they > don't have the IP space, so saying that the service the end user is buying > that justifies the IP assignment is 'registration services' is a circular > argument. Of course - but if you wanted to provide services to spammers and their friends it's the sort of stretch you'd find yourself making. Regards, Leo
Re: Article on spammers and their infrastructure
On 22/12/2009 3:36, "Jon Lewis" wrote: [...] > They may be. I don't agree that it's relevant. You can disagree with the > RIPE wording or with RIPE policies, or maybe I'm misinterpreting > > ASSIGNED PA: This address space has been assigned to an End User for use > with services provided by the issuing LIR. It cannot be kept when > terminating services provided by the LIR. > > My interpretation of the above is ASSIGNED PA is the equivalent of my > assigning IP space to a customer who either buys transit (connectivity) > from us or colo's or buys server hosting from us where they will use that > IP space. We don't simply lease out IP space for "customers" to use as > they please on other networks. I am sure that your interpretation was the original intent of the policy text. However, the wording could also be read in a way that allows an LIR to just provide registry services, without providing any connectivity services. Regards, Leo
Re: 109/8 - not a BOGON
On 09/10/2009 4:22, "Matthew Walster" wrote: > A customer of mine is reporting that there are a large number of addresses > he can not reach with his addresses in the 109/8 range. This was > declassified as a BOGON and assigned by IANA to RIPE in January 2009. > > If you have a manually updated BOGON list, can I please ask that you review > it and update it as soon as possible please? His addresses in 89/8 and 83/8 > work just fine, hence this presumption of BOGON filtering. This might be a good moment to list all the /8s allocated so far this year. 046/8RIPE NCC2009-09whois.ripe.net ALLOCATED 002/8RIPE NCC2009-09whois.ripe.net ALLOCATED 182/8APNIC 2009-08whois.apnic.netALLOCATED 175/8APNIC 2009-08whois.apnic.netALLOCATED 183/8APNIC 2009-04whois.apnic.netALLOCATED 180/8APNIC 2009-04whois.apnic.netALLOCATED 178/8RIPE NCC2009-01whois.ripe.net ALLOCATED 109/8RIPE NCC2009-01whois.ripe.net ALLOCATED Also, I'd like to mention that if you ever want to check your filters against the registry, we have made the columns sortable. It's now nice and easy to identify newly allocated /8s. http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml Regards, Leo Vegoda
Re: Minimum IPv6 size
On 04/10/2009 4:49, "Kevin Oberman" wrote: [...] >>> So, if I need to break up my /32 into 4 /34s to cover different geographical >>> regions, I should instead renumber into a new range set aside for /34s >>> and give back the /32? Sure seems like a lot of extra overhead. >>> Perhaps we should give everyone an allocation out of each filter >>> range, so that they can simply number from the appropriately-classed >>> range; when you apply for space, you'd get a /32, a /33, a /34, a /35, >>> a /36, etc. all from the appropriate, statically defined ranges. >> >> I think ARIN proposal 2009-5 >> (https://www.arin.net/policy/proposals/2009_5.html) is designed to cope with >> the situation you describe. I understand that it's on the agenda for the >> meeting in Dearborn. > > I don't think so. I believe the statement is not in regard to separate, > discrete networks bu to a network with a national footprint which must > deaggregate to do traffic engineering by region. Item 2 clearly makes > 2009-5 non-applicable to this case. I thought that "Geographic distance and diversity between networks" covered the case above but I could well be wrong. > This issue will be discussed in a Mark Kosters moderated panel at NANOG > in Dearborn. Hey, why not attend both meetings? I won't be there in person but look forward to watching the video feed. Regards, Leo
Re: Minimum IPv6 size
On 03/10/2009 8:19, "Matthew Petach" wrote: [...] > So, if I need to break up my /32 into 4 /34s to cover different geographical > regions, I should instead renumber into a new range set aside for /34s > and give back the /32? Sure seems like a lot of extra overhead. > Perhaps we should give everyone an allocation out of each filter > range, so that they can simply number from the appropriately-classed > range; when you apply for space, you'd get a /32, a /33, a /34, a /35, > a /36, etc. all from the appropriate, statically defined ranges. I think ARIN proposal 2009-5 (https://www.arin.net/policy/proposals/2009_5.html) is designed to cope with the situation you describe. I understand that it's on the agenda for the meeting in Dearborn. Regards, Leo
Re: Minimum IPv6 size
On Oct 3, 2009, at 1:28 AM, "James Aldridge" wrote: [...] > It might be worth relaxing filtering within 2001::/16. The RIPE NCC > appears to be making /48 PI assignments from within 2001:678::/29 > (e.g. the > RIPE Meeting next week will be using 2001:67c:64::/48) Why the whole /16 rather than just that /29 and a few other blocks set aside for /48s? There are a lot of /48s in a /16, so protecting against someone accidentally deaggregating their allocated /32 into / 48s seems legitimate. Regards, Leo
2/8 and 46/8 allocated to the RIPE NCC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, The IANA IPv4 registry has been updated to reflect the allocation of two /8 IPv4 blocks to the RIPE NCC in September 2009: 2/8 and 46/8. You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt Please update your filters as appropriate. The IANA free pool contains 26 unallocated unicast IPv4 /8s. Regards, Leo Vegoda Number Resources Manager, IANA -BEGIN PGP SIGNATURE- Version: 9.10.0.500 wj8DBQFKt6AdvBLymJnAzRwRAiscAKDaqyQYv8YLcXsg/tubUBe1THTNIACfQ0iP 23SVpODdlrWi0qEuEHVbi5c= =DVak -END PGP SIGNATURE-
Re: Repeated Blacklisting / IP reputation
On 09/09/2009 8:48, "Mark Andrews" wrote: [...] > What a load of rubbish. How is ARIN or any RIR/LIR supposed to > know the intent of use? In my limited experience, requesting address space from ARIN involved describing what I would be doing with it. YMMV. Leo
Re: Repeated Blacklisting / IP reputation
On Sep 9, 2009, at 7:18 PM, Alex Lanstein wrote: > Along the same lines, I noticed that the worst Actor in recent > memory (McColo - AS26780) stopped paying their bills to ARIN and > their addresses have been returned to the pool. > > It's my opinion that a very select number of CIDR blocks (another > example being the ones belonging to Cernel/InternetPath/Atrivo/etc, > if it were ever fully extinguished) are, and forever will be, > completely toxic and unusable to any legitimate enterprise. > Arguments could be made that industry blacklists can and should be > more flexible, but from the considerably more innocuous case in this > thread, that is apparently not the modus operandi Putting these addresses back into use does not mean that they have to be allocated to networks where they'll number mail servers. ARIN staff is doubtless aware of the history of these blocks and will presumably do their best to allocate them to networks that aren't intended to host mail servers. Regards, Leo
Block of AS Numbers allocated to APNIC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, The IANA AS Numbers registry has been updated to reflect the allocation of a block of AS Numbers to APNIC. 55296-56319Assigned by APNICwhois.apnic.net2009-09-02 The registry can be found at: http://www.iana.org/assignments/as-numbers/as-numbers.xml http://www.iana.org/assignments/as-numbers/as-numbers.xhtml http://www.iana.org/assignments/as-numbers/as-numbers.txt Regards, Leo Vegoda Number Resources Manager, IANA -BEGIN PGP SIGNATURE- Version: 9.10.0.500 wj4DBQFKpohJvBLymJnAzRwRAncHAJiRWENmmK+qwpvAZIaPrs/urIa/AJ9f1A05 PM9TJWxzbAxpSiXyIgzvfA== =MGZ2 -END PGP SIGNATURE-
175/8 and 182/8 allocated to APNIC
-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 August 2009: 175/8 and 182/8. You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt Please update your filters as appropriate. Regards, Leo Vegoda Number Resources Manager, IANA -BEGIN PGP SIGNATURE- Version: 9.10.0.500 wj8DBQFKguZyvBLymJnAzRwRAmDCAKCCnxLNmk32v+sm786x5RyVLnLBDACcCu5I zCs7FdAdkIZRnfNtuVyVB0s= =6huK -END PGP SIGNATURE-
Re: Where to buy Internet IP addresses
On May 4, 2009, at 6:21 AM, "Jack Bates" wrote: [...] >> > Then tell RIR's to quit insisting that /56's have SWIP's. They can't > very well be dynamic in nature via PD if they are being SWIP'd. If you are referring to section 6.5.4.4 of ARIN's NRPM, it does not require you to use SWIP. It requires that an ISP have records which allow ARIN to evaluate a request for a subsequent allocation. SWIP would work if ARIN wanted potentially 10s of millions of /56s in its whois database but it is not explicitly required and ARIN staff can presumably advise on suitable alternatives. Regards, Leo
180/8 and 183/8 allocated to APNIC
-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 April 2009: 180/8 and 183/8. You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt Please update your filters as appropriate. Regards, Leo Vegoda Number Resources Manager, IANA -BEGIN PGP SIGNATURE- Version: 9.10.0.500 wj8DBQFJ+iBAvBLymJnAzRwRAq59AKDYIE9QGQAAJQDuqfQ5Qqo5YiZwWwCg1RNg wwnJkpL3STZw9fDOM7zUToM= =PtJl -END PGP SIGNATURE-
Two blocks of AS Numbers allocated
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, The IANA AS Numbers registry has been updated to reflect the allocation of two blocks of AS Numbers recently. 53248-54271Assigned by ARIN whois.arin.net 2009-04-21 54272-55295Assigned by ARIN whois.arin.net 2009-04-21 The registry can be found at: http://www.iana.org/assignments/as-numbers/as-numbers.xml Regards, Leo Vegoda Number Resources Manager, IANA -BEGIN PGP SIGNATURE- Version: 9.10.0.500 wj8DBQFJ78q5vBLymJnAzRwRAsxhAKCvxeFIPNw/gZnUDnH0Q51wWR7fiACeMKe+ XnUY36jXeaFRj2Ecn+4ZgFE= =cnqY -END PGP SIGNATURE-
Re: eGLOP and/or 232/8 question (SSM)
Hi Ryan, On 06/04/2009 10:51, "Ryan Landry" wrote: > i apologize if this has been discussed...searching mboned/nanog/ietf/arin/etc > archives doesn't give me the clarification i hoped for. > > is there a defined method to request eGLOP space? does anyone really care > what people use internally for mcast? i see mr. eubanks submitted a proposal > back in 2007 for eGLOP assignment process and ARIN shot it down, but i can't > seem to find current status. If you need additional IPv4 multicast address space you can request it using the form on this page: http://www.iana.org/protocols/apply/ The EGLOP space is set to become additional AD-HOC multicast space. The draft for this can be found at: http://tools.ietf.org/id/draft-ietf-mboned-rfc3171bis Hope this helps, Leo
Four blocks of AS Numbers allocated
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, The IANA AS Numbers registry has been updated to reflect the allocation of four blocks of AS Numbers recently. 49152-50175Assigned by RIPE NCC whois.ripe.net 2009-03-06 50176-51199Assigned by RIPE NCC whois.ripe.net 2009-03-06 51200-52223Assigned by RIPE NCC whois.ripe.net 2009-03-06 52224-53247Assigned by LACNIC whois.lacnic.net 2009-03-11 The registry can be found at: http://www.iana.org/assignments/as-numbers/as-numbers.xml Regards, Leo Vegoda Number Resources Manager, IANA -BEGIN PGP SIGNATURE- Version: 9.9.1.287 wj8DBQFJuUXxvBLymJnAzRwRAkgiAJ4gPAIF9egizyMbGGB/2MAciOCsdQCfXQfX N4gRb5lyNjDDcKZ4bhf5AqY= =LKc/ -END PGP SIGNATURE-
Re: do I need to maintain with RADB?
On 19/02/2009 12:09, "Zaid Ali" wrote: > Hi, need some advise here. Do I still need to maintain my objects (and pay) > RADB? I use ARIN as source and all my route objects can be verified with a > whois. If you are happy using a RR which appears to only rely on a MAIL-FROM auth scheme then the ARIN RR is fine. If you'd like to have a stronger auth scheme available you might want to look at RADB. Leo
Re: Private use of non-RFC1918 IP space
On 02/02/2009 10:45, "Dorn Hetzel" wrote:
> On a related note, do you think that 0.0.0.0/8 <http://0.0.0.0/8> (excluding
> 0.0.0.0/32 <http://0.0.0.0/32> , of course :) ) will be feasible for
> allocation and use ?
0.0.0.0/8 is reserved for self-identification. See RFC 1700:
(b) {0, }
Specified host on this network. Can only be used as a
source address.
Regards,
Leo Vegoda
Re: Private use of non-RFC1918 IP space
On 02/02/2009 8:10, "Bruce Grobler" wrote: > Most ISP's, if not all, null route 1.0.0.0/8 therefore you shouldn't > encounter any problems using it in a private network. 1.0.0.0/8 will be allocated in the not too distant future. All currently unallocated unicast IPv4 /8s will be allocated in the not too distant future. Regards, Leo Vegoda
Re: Leap second tonight
On 05/01/2009 6:01, "Nick Hilliard" wrote: [...] > But seriously. Leap seconds occur every couple of years, either on July > 30th and Dec 31. Sometimes both. And sometimes every consecutive year for > a couple of years on the run. It's theoretically possible for leap seconds to be introduced at the end of March and September. It's never happened but it might, so I suppose software should allow for the possibility. Regards, Leo
108/8 and 184/8 allocated to ARIN
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, The IANA IPv4 registry has been updated to reflect the allocation of two /8 IPv4 blocks to ARIN in December 2008: 108/8 and 184/8. You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt Please update your filters as appropriate. Regards, Leo Vegoda Number Resources Manager, IANA -BEGIN PGP SIGNATURE- Version: 9.9.0.397 wj8DBQFJYcuzvBLymJnAzRwRAiHoAJ9ElxHBdXiQEYcWTE+QMKIA4+0rpwCgmbTy w5fYf3la3xtY5SjT5w+dS/w= =xUKB -END PGP SIGNATURE-
Re: NAT66 and the subscriber prefix length
On 19/11/2008 4:27, "Eugeniu Patrascu" <[EMAIL PROTECTED]> wrote: [...] > My gripe was that I wanted to get an IPv6 allocation from RIPE to start > testing how IPv6 would fit in the company that I work for and build a > dual stack network so that when the time comes, just switch on IPv6 BGP > neighbors and update the DNS. > > But at almost 10.000 EUR per year it's an experiment I can't afford. Where did the 10k come from? According the the 2009 billing scheme (http://www.ripe.net/ripe/docs/ripe-437.html) the highest annual fee is €5,500. The FAQ makes it clear that new members are automatically assigned to the Extra Small billing category (http://www.ripe.net/info/faq/membership/newlir-billing.html#2), putting membership and the sign-up fee at €3,300. I don't remember the RIPE NCC trying to sell expensive extras like a car dealership. I'd be surprised if the prices quoted aren't the prices that everyone pays. Regards, Leo
110/8 and 111/8 allocated to APNIC
Hi, The IANA IPv4 registry has been updated to reflect the allocation of two /8 IPv4 blocks to APNIC in November 2008: 110/8 and 111/8. You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt Please update your filters as appropriate. Regards, Leo Vegoda Number Resources Manager, IANA PGP.sig Description: This is a digitally signed message part
197/8 allocated to AfriNIC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, The IANA IPv4 registry has been updated to reflect the allocation of one /8 IPv4 block to AfriNIC in October 2008: 197/8. You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt Please update your filters as appropriate. Regards, Leo Vegoda Number Resources Manager, IANA -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFJCBdMvBLymJnAzRwRApYGAJ9DfmQ2fvbfMgCVW1M8ZfiMnqSvgACgrCha /biQ/NJ9HS09avyV3UTRlRY= =wQ6t -END PGP SIGNATURE-
New (2-byte) ASN Allocation for RIPE NCC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, This is to confirm that the IANA has allocated one 2-byte ASN block to the RIPE NCC: 48128-49151 Assigned by RIPE NCC whois.ripe.net 2008-09-09 A note of the allocation has been made at: http://www.iana.org/assignments/as-numbers/as-numbers.xml http://www.iana.org/assignments/as-numbers/as-numbers.xhtml http://www.iana.org/assignments/as-numbers/as-numbers.txt Thank you and best regards, Leo Vegoda [EMAIL PROTECTED] *** Internet Assigned Numbers Authority (IANA) 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 Phone: +1-310-823-9358 Fax: +1-310-823-8649 *** -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFIx9suvBLymJnAzRwRAgnkAKDDxJCilYy0aErDQtQQFEcsCKG/QwCgi+Ao 029EI3Ful4LKPXMJEUGKs3g= =7EeD -END PGP SIGNATURE-
Re: was bogon filters, now "Brief Segue on 1918"
On 06/08/2008 4:44, "Matthew Kaufman" <[EMAIL PROTECTED]> wrote: [...] > Well, you can always do what one of the companies I work with does: > allocate from 42.0.0.0/8 for networks that might need to interoperate > with 1918 space and hope that it is "forever" before we run so low on > IPv4 space that 42.0.0.0/8 needs to be taken out of reserved status. I'm very confident that 42.0.0.0/8 will be allocated within the next three years. Leo
AS Numbers registry updated
Hi, This is to let you know that we have updated the AS Numbers registry in cooperation with the RIRs. It now shows which RIR currently provides Whois service for an AS Number instead of the RIR to which the AS Number was originally allocated. The updated registry is now over 2000 lines long but the format has not changed. In addition to the current format, the AS Numbers registry will be made available in XML during July. The updated registry will shortly be available at: http://www.iana.org/assignments/as-numbers Kind regards, Leo Vegoda IANA
IPv6 Deployment Panel at ICANN San Juan meeting
Hi, I've set the reply-to address to me as this message has gone to several lists. There will be an IPv6 Deployment Panel discussion at the ICANN meeting in San Juan, Puerto Rico on Sunday 24 June between 3pm and 4.30pm (UTC -4). The session will focus on the issues associated with deploying IPv6 on a network designed for IPv4. Session information can be found on the meeting web site at: http://sanjuan2007.icann.org/node/16 The session will be webcast and the ICANN public participation site lets registered users ask questions and comment in chatrooms and forums. If you have any particular questions then please submit questions to the panel in advance or during the session. You can also use the blog facility to write about the session afterwards. The site can be found at: http://public.icann.org/ Video and a session transcript will be made available as soon as possible after the session has closed. Regards, -- Leo Vegoda IANA Numbers Liaison
Re: IPv6 Advertisements
On 29 May 2007, at 6:23pm, Donald Stahl wrote: [...] RIPE may only give out /32's but ARIN gives out /48's so there wouldn't be any deaggregation in that case. The RIPE NCC assign /48s from 2001:0678::/29 according to ripe-404: http://www.ripe.net/ripe/docs/ripe-404.html Regards, Leo
Re: NANOG 40 agenda posted
On 29 May 2007, at 5:22pm, David Conrad wrote: [...] they should not notice it. They shouldn't, but they will. Having had the fun of trying to figure out why I lost connectivity to a site (then realizing it was because I had connected via IPv6 instead of IPv4 and IPv6 routing ... changed), the current IPv6 infrastructure is, shall we say, not quite production ready. They already do. This popped up in my feed reader today: http://ask.metafilter.com/63532/Trouble-with-Firefox it ends with this comment: "If your hosting provider is serving your domain with IPv6, then it is time to find a new provider." Regards, Leo
